사이트 신뢰성 엔지니어링(SRE): 희망 대신 필요한 7가지 전략

사이트 신뢰성 엔지니어링(SRE)은 운영 문제를 소프트웨어 문제처럼 다루는 접근 방식입니다. 이 용어는 2003년 구글 엔지니어 벤 트레이너 슬로스(Ben Treynor Sloss)에 의해 처음 명명되고 설명되었습니다. 기본적으로 SRE는 특정 시스템의 가용성, 성능 및 효율성을 유지하는 것을 목표로 합니다.

SRE는 정의하기 어려울 수 있습니다. 이는 정해진 작업의 집합이라기보다 접근 방식 또는 학문에 가깝고, 조직의 필요에 따라 다양한 형태를 취합니다. 다행히도 SRE 팀이 성공할 수 있도록 돕는 사이트 안정성 엔지니어링의 일곱 가지 원칙이 있습니다.

소프트웨어 개발의 상당 부분은 당연하게도 새롭게 만들어 내는 것에 집중되어 있으며, 이와 관련되지만 별개의 분야인 DevOps 역시 제품의 전체 수명 주기에 더 관심을 둡니다. 하지만 시스템이 출시된다고 해서 끝난 것은 아닙니다. 구글의 SRE 가이드 서문에서 저자들은 “시스템 총 비용의 40~90%가 출시 이후에 발생한다”고 언급하였습니다. SRE는 출시 후 어떤 일이 일어나는지에 관심을 갖고 있으며, 제품이 가능한 한 사용 가능한 상태를 유지하도록 돕는 것을 목표로 합니다.

SRE의 가장 중요한 요소는 시스템 안정성과 가동 시간입니다. 아무리 훌륭한 서비스도 운영이 제대로 되지 않으면 아무 소용이 없기에 SRE는 다운타임을 최소화하고 안정적인 시스템을 구축하는 데 중점을 두고 있습니다.

또한 SRE 팀은 소프트웨어 및 보안 업데이트를 신중하게 관리하여 제품의 모든 요소를 최신 상태로 유지합니다. 표준과 규정은 변경될 수 있으며 엔지니어링 팀은 지속적인 규정 준수를 보장합니다.

SRE를 통해 재정적 절감 효과도 얻을 수 있습니다. SRE의 핵심 원칙 중 다수는 자동화 및 리소스 관리를 포함하여 비용과 노력을 크게 절감할 수 있는 효율성과 관련이 있습니다.

SRE의 7가지 원칙은 다음과 같습니다.    

• 위험 수용
• 서비스 수준 목표
• 반복 업무 제거
• 모니터링
• 자동화
• 릴리스 엔지니어링
• 간소화

SRE는 다운타임 관리 및 제한에 중점을 두지만, 이러한 경향이 서비스가 완벽한 100% 가용성 신뢰성을 유지하는 것을 목표로 한다는 의미는 아닙니다. 실제로 SRE의 핵심 기둥 중 하나는 100% 신뢰성이 비현실적일 뿐만 아니라 반드시 선호되는 결과도 아니라는 것입니다.

SRE에서는 위험은 지속되는 것으로 이해하며, 100% 신뢰성에 가까워질수록 위험을 줄이는 것이 기하급수적으로 더 어렵고 비용이 많이 듭니다. 99.99%의 신뢰도에서 99.999%의 신뢰도로 올리는 것은 80%에서 99%로 올리는 것보다 훨씬 더 어렵습니다. 100에 점점 더 가까워지는 데 필요한 리소스는 새로운 기능 및 업데이트 혁신과 같은 개발팀의 다른 업무 수행 능력을 저하시킵니다. 대신 팀은 적절한 수준의 실패를 나타내기 위해 오류 예산을 설정합니다.

전체 신뢰성에 반하는 또 다른 점은, 비록 직관적이지 않아 보일지라도, 고객들은 일반적으로 특정 기준을 넘어선 신뢰성 개선을 알아채지 못한다는 것입니다. 이는 비용이 많이 들 뿐만 아니라 보상도 거의 없습니다. 따라서 이상적으로는 목표를 설정하고 이를 달성하는 것이 좋지만, 과도하게 초과하지 않는 것이 바람직합니다.

대신 SRE는 가용성 지표를 사용하여 다운타임 위험의 수용 가능성을 측정합니다. 한 지표에 따르면 연간 99.99% 신뢰도성을 달성할 때 52.6분의 다운타임이 발생할 수 있습니다. 더 복잡한 지표는 서비스의 일부 요소나 특정 지역에서만 다운타임이 발생하고, 다른 부분은 계속 정상적으로 동작하는 가능성까지 고려합니다.

SRE 팀은 다음 질문들을 통해 각 서비스를 평가하고 허용 가능한 불안정성 수준을 결정해야 합니다. 다운타임은 어느 정도까지 허용되는가? 서로 다른 근원적 요인으로 인해 발생하는 다양한 유형의 장애가 사용자 경험에 미치는 영향이 다른가? 이를 초과할 경우 인건비와 재무적 측면에서 얼마나 많은 비용이 드는가? 이들 사이에 균형을 맞추기 위해선 어떻게 해야 하는가?

목표를 설정하고 그 목표가 얼마나 효과적으로 달성되었는지, 그리고 그 이유를 측정하는 것은 SRE 팀에 매우 중요합니다. 서비스 수준 목표(SLO)는 SRE 팀이 목표로 설정한 특정한, 측정 가능한 품질 수준을 나타냅니다. 이러한 SLO는 다양한 지표의 형태를 취할 수 있지만, 가용성, 쿼리 속도, 오류율, 응답 시간 등이 일반적입니다.

이러한 목표는 서비스 수준 지표(SLI)를 사용하여 측정되며, 이는 지연 시간과 같은 성능의 원시 측정값입니다. 따라서 이 경우 SLI는 지연 시간 지표이고, SLO는 해당 지표가 특정 임계값 이하로 유지되는 것입니다. SLO는 서비스 수준 계약(SLA)의 일부가 될 수 있으며, 이는 제공자와 사용자 간의 계약으로, SLO와 이를 충족하지 못했을 때의 결과를 명시합니다.

SLO를 선택하는 것은 까다로울 수 있습니다. 이상적으로는, SLO는 사용자에게 가장 중요한 것을 중심으로 구성되어야 합니다. 예를 들어 클라우드 게임 서비스의 경우 SLO는 낮은 지연 시간을 중심으로 할 수 있지만, 회계 서비스에서는 지연 시간이 그다지 중요하지 않을 수 있습니다.

이상적으로 사이트 안정성 엔지니어는 이러한 목표를 달성하는 데 집중하기 위해 상대적으로 적은 수의 SLO를 사용합니다. 주요 작업을 올바르게 수행하는 것이 가장 중요합니다. 현실적인 목표를 설정하는 것도 중요합니다. 앞서 논의했듯이, 완벽은 현실적이지도 바람직하지도 않습니다.

SRE의 창시자들은 '반복 업무(toil)'를 일과 겹치지만 동일하지는 않은 노동 범주로 정의해야 한다는 점을 강조합니다. 반복 작업은 선형적으로 확장되는 수작업 업무를 의미하며, 일반적으로 수동적이고 반복적이며, 자동화로 수행 가능한 경우가 많습니다.

반복해서 수행해야 하는 작업은 ‘반복 업무(toil)’로 분류됩니다. 이상적으로는 개별 작업은 한두 번의 실행만으로 끝날 수 있어야 합니다. 제품을 개선하지 못하는 작업도 반복 업무에 해당합니다. Google의 비벡 라우(Vivek Rau)는 “작업을 마친 후에도 서비스가 이전과 동일한 상태라면, 그 작업은 아마 반복 업무일 것”이라고 말합니다. 버그 수정, 기능 개선 및 최적화는 반복 업무가 아니지만 메트릭을 수동으로 다운로드하는 것은 반복 업무에 해당합니다. 엔지니어와 운영팀 간의 긴밀한 협력이 필요한 경우도 있는 인시던트 대응(incident response)은 반복 업무가 아니며 릴리스 전에 인시던트 관리 전략을 계획해야 합니다.

인지적 반복 업무(cognitive toil)라는 것도 있습니다. 가끔 사용하지만 매번 재료와 분량을 다시 찾아야 하는 기본 레시피가 있다고 해봅시다. 매번 무언가를 다시 배우거나 기억해내야 하는 것은 시간과 노력을 낭비하는 일입니다. 대신 SRE는 반복적으로 방법론이나 작업을 기억하거나 다시 배울 필요가 없도록 가이드와 표준을 더 많이 만드는 것을 권장합니다.

사이트 신뢰성 엔지니어링(SRE)의 가장 중요한 부분 중 하나는 도구를 사용하여 핵심 기능과 성능을 지속적으로 측정, 분석 및 개선하는 모니터링입니다. 이러한 핵심 기능은 흔히 모니터링의 ‘4대 황금 지표(four golden signals)’라 불립니다.

지연 시간: 가장 기본적으로, 요청을 처리하는 데 얼마나 시간이 걸리는지에 대한 지표입니다. 요청이 성공했는지 실패했는지에 따라 시간이 달라질 수 있는데, 예를 들어 오류 메시지를 반환하는 데 오히려 더 많은 시간이 걸릴 수도 있습니다.

트래픽: 서비스에 가해지는 부하나 수요는 얼마나 되나요? 구체적인 단위는 다양할 수 있습니다. 페이지뷰일 수도 있고, 트랜잭션일 수도 있으며, HTTP 요청일 수도 있습니다.

오류: 일반적으로 비율로 측정되며, 잘못된 데이터를 가져오거나, SLA에 명시된 것보다 느리게 데이터를 가져오거나, 아예 가져오지 못하는 경우가 포함됩니다.

포화도: 본질적으로 포화도는 서비스가 용량에 얼마나 가까운지를 측정한 것입니다. 포화도를 이해하는 것은 중요합니다. 일부 서비스는 100%에 가까워질수록 실패하거나 느려지거나 오류가 더 많이 발생하기 때문입니다.

많은 모니터링 툴은 데이터를 수집하고, 벤치마크를 설정하며, 문제를 디버깅 및 분석하고, 유용한 관측 가능성 대시보드를 제공하고, 잠재적 장애나 기타 문제를 SRE에게 경고할 수 있습니다. 또한 인시던트가 해결된 후에는 인시던트의 맥락, 근본 원인과 유발 요인, 영향, 해결 방법론, 향후 교훈을 설명하는 강력한 사후 보고서를 제공하는 것이 중요합니다. 상세하고 객관적인 사후 보고서는 동일한 실수를 반복하지 않도록 하는 데 매우 유용할 수 있습니다.

현대 기술의 다른 많은 요소와 마찬가지로 자동화를 워크플로우에 통합하는 목표는 엔지니어가 가치를 창출하지 못하는 반복적인 작업에 매달리지 않도록 하는 것입니다. 새롭게 확보된 자유 시간을 통해 엔지니어는 자동화가 완료할 수 없는 작업(생성, 아이디어 구상, 대규모 지침 수립 등)을 수행할 수 있습니다.

자동화는 다음과 같은 목표를 달성하는 데 특히 유용할 수 있습니다.

일관성: 반복적이고 수동적인 작업의 단점은 더 가치 있는 작업을 뒤로 하고 단순히 지루하고 시간을 잡아먹는 데 그치지 않습니다. 사용자 계정 생성과 같은 작업이 자동화 도구를 통해 수행된다면, 실수와 불일치를 거의 제거할 수 있습니다. 신규 직원은 기존 직원과 다르게 일을 처리할 수 있고, 사용자가 값을 잘못된 필드에 입력할 수도 있습니다. 그러나 자동화된 프로세스는 일반적으로 이런 문제를 일으키지 않습니다.

확장성: 확장성은 장기적으로 볼 때 자동화의 주요 이점 중 하나입니다. 앞서 든 사용자 계정 생성 예시를 다시 살펴보겠습니다. 계정 생성 수가 기하급수적으로 증가하면, 계정 설정을 담당한 사람의 업무량도 기하급수적으로 늘어나 다른 더 중요한 업무에 집중하기 어렵습니다. 하지만 자동화된 시스템은 이러한 문제를 겪지 않습니다.

속도: 코드에서 버그를 찾고 수정하는 것과 같은 특정 작업을 사람이 수행하면 많은 시간이 소요될 수 있습니다. 자동화된 소프트웨어 시스템은 방대한 데이터를 모니터링할 수 있으며, 고급 패턴 인식이나 기타 도구를 활용해 사람보다 더 빠르게 오류를 감지할 수 있습니다. 수정 사항은 사람의 개입 없이도 마찬가지로 신속하게 적용할 수 있습니다.

물론 어떤 자동화 프로세스에도 잠재적인 위험이 존재합니다. 그 예는 다음과 같습니다.

초기 비용: 자동화를 배포하려면 먼저 자동화를 만들어야 합니다. 이는 상당한 시간, 노력, 심지어 하드웨어 비용을 요구할 수 있습니다. 자동화의 가치는 자동화를 만드는 데 드는 노력과 자동화가 시작되면 절약할 수 있는 실제 리소스 간의 균형을 고려해야 합니다.

유지 관리: 자동화된 작업은 영원히 실행될 것처럼 보일 수 있지만, 실제로는 그렇지 않은 경우가 많습니다. 자동화 코드는 최신 상태로 유지되어야 하며 다른 코드 및 시스템 업데이트와 동기화되어야 합니다. 새로운 기능이 추가되면 새로운 작업을 포함하거나 오류를 방지하기 위해 자동화 코드도 사람의 개입을 통해 업데이트해야 할 수도 있습니다.

인공 지능은 SRE에 새롭고 흥미로운 몇 가지 가능성을 제시하는데, 가장 눈에 띄는 것은 자동화 영역입니다. 초기 비용과 유지 관리 모두 새로운 AI 모델에 의해 조정될 수 있습니다. 그러나 AI는 또한 할루시네이션, 보안, 개인정보 보호 등 새로운 잠재적 문제점을 가져올 수 있습니다.

릴리스 엔지니어링은 소프트웨어 엔지니어링의 하위 분야로, 특히 소프트웨어를 릴리스하는 데 필요한 단계에 중점을 둡니다. 이러한 단계에는 버전 관리, 릴리스 일정, 연속 또는 주기적 빌드, 릴리스 지표 선택 및 수집 등이 포함됩니다. SRE에서는 릴리스 엔지니어링을 사후 고려사항이 아닌 초기 단계부터 구축하는데, 릴리스 엔지니어링 작업이 막판에 무작위로 배정되는 것을 방지하는 위한 것입니다.

릴리스 엔지니어링에는 몇 가지 주요 원칙이 있는데, 그 예는 다음과 같습니다.

자동화 및 셀프 서비스: 이상적으로는 많은 릴리스 프로세스가 자동화될 수 있으며, 엔지니어의 개입이 거의 필요 없거나 전혀 필요하지 않습니다. 이를 통해 빠르고 안정적인 릴리스가 보장됩니다.

속도(Velocity): 릴리스 엔지니어링의 기본 철학은 신속하고 빈번한 릴리스입니다. 출시 초기에는 심지어 매시간 단위로 릴리스를 배포할 수도 있는데, 이를 통해 버전 간 변경 사항이 줄어들고 테스트와 문제 해결이 더 쉬워집니다.

밀폐형 빌드(Hermetic builds): 빌드 프로세스는 가장 널리 사용되는 컴파일러, 라이브러리 및 도구를 사용하여 빌드 머신 자체와 완전히 독립적이어야 합니다. Google의 디나 맥넛(Dinah McNutt)은 “서로 다른 머신에서 두 사람이 소스 코드 저장소의 동일한 리비전 번호로 동일한 제품을 빌드하려 한다면, 우리는 동일한 결과가 나와야 한다고 기대합니다”고 말합니다.

표준 및 정책: 보안상의 이유로, 배포, 소스 코드 변경, 새로운 릴리스, 빌드 구성 변경과 같은 특정 작업에는 반드시 검증 절차가 필요합니다.

사이트 신뢰성 엔지니어링의 상당 부분은 단순성을 추구합니다. Google의 맥스 루베(Max Luebbe)는 소프트웨어가 "본질적으로 역동적이고 불안정하다"고 말합니다. 이를 고려해 볼 때 단순성은 잠재적인 문제를 최소화하고 내재한 불안정성을 억제할 수 있는 핵심 요소라고 할 수 있습니다.

이를 위해 사이트 신뢰성 엔지니어링은 프로젝트를 단순화하고 명확히 할 수 있는 다양한 작업을 촉진합니다.

1. 포함할 기능을 신중하게 선택하는 것도 도움이 되지만, 제품의 유용성에 크게 기여하지 않는 모든 기능을 단순히 삭제하는 것 역시 마찬가지로 유용할 수 있습니다. 더 많은 기능은 더 복잡하다는 것을 의미합니다.
2. 더 작고 빈번한 릴리스로 훨씬 더 쉽게 디버깅하고 문제를 해결할 수 있습니다. 수십 가지의 새로운 기능을 포함한 새 릴리스는 추적하기 매우 어려운 오류를 유발할 수 있습니다. 단 하나의 새로운 기능만 포함된 릴리스라면 잠재적인 문제는 오직 한 곳에서만 발생한다는 것을 의미합니다.
3. 마찬가지로, 여러 엔드포인트, 마이크로서비스 등을 사용하여 API에 복잡성을 추가하고 싶은 유혹이 있을 수 있습니다. 그러나 이는 피해야 합니다. 단순한 API는 더 빨리 설정할 수 있고, 문서화가 덜 필요하며, 통합 시간과 비용을 줄여줍니다.