주요 SRE 원칙 및 사례: 선순환

어떤 의미에서든 "무엇을 하는지가 그 사람을 규정한다"라는 점이 이 모듈의 핵심입니다. 이 단원에서는 SRE 사례의 핵심으로 간주되는 두 가지 사례를 살펴보겠습니다. 두 사례는 모두 “선순환”을 만드는 것이 중요하다는 원칙에서 시작됩니다. 이 컨텍스트에서의 선순환은 조직이 지속적으로 발전하는 데 도움이 되는 조직 내 피드백 루프를 빌드하는 일입니다. 정확히 이 두 가지 사례만 다루는 전체 후속 모듈이 있으므로, 여기서는 각 사례의 개요를 통해 일반적인 내용만 살펴보겠습니다.

선순환 #1: SLI 및 SLO

이 모듈의 앞부분에서는 “적절한 수준의 안정성” 지향을 중점적으로 다루었습니다. 이 개념이 영향을 미치는 곳이 정확히 이 섹션입니다.

프로덕션에 도입하려는 새 서비스(구성된 서비스 또는 아직 계획 프로세스 중인 서비스)가 있다고 가정해 봅시다. 해당 프로세스의 일부로 원하는 안정성에 대한 몇 가지 결정을 내리는 것이 중요합니다. 일부 코드만 직접 작성하는 경우 작업을 수행하는 개발자와 협업하여 이러한 결정을 내리게 됩니다(공동 결정이 중요함).

첫 번째로 결정해야 할 사항은 무엇을 서비스 상태의 지표(서비스 수준 지표 또는 SLI)로 사용할 것인가입니다. 이 질문을 달리 표현한다면, “제대로 시작 및 작동하는지 어떻게 알 수 있나요?”입니다. SLI를 추적하는 방법에는 여러 가지가 있으며 나중에 자세히 살펴보겠습니다. 그러나 이러한 지표는 일반적으로 다음과 같습니다.

• 성공 및 실패 측정값: 서비스가 작업의 일부 비율을 성공적으로 완료하나요?
• 타이밍 측정값: 특정 시간 임계값 내에서 답변을 반환했나요?
• 처리량 측정값: 일정량의 데이터를 처리했나요?

또는 이러한 측정값의 일부 조합.

간단한 예로, 서비스에 대한 SLI를 HTTP 200 코드(500 또는 기타 코드와 대응)로 표시되는 성공 반환 빈도라고 가정할 수 있습니다.

이제 서비스가 어떻게 진행되고 있는지 알려 주는 명확한 표시기가 생겼으므로, 해당 서비스에 대해 기대하거나 원하는 수준의 안정성을 결정해야 합니다. 예를 들어 하루에 예상하는 서비스 실패율이 20%인가요? 여기서는 처음에 추론이 용이한 큰 어림수를 사용하고 있습니다. 이후 모듈에서는 “어떤 사용자에게 해당 오류율이 발생하나요? 일부인가요? 대부분인가요?” 등과 같은 문장의 복잡도와 정밀도를 향상시키겠습니다. 서비스 개발자와 협업으로 만든 이 예상치가 SLO(서비스 수준 목표)입니다.

SLO는 모니터링 시스템에서 정확하게 측정하고 표시할 수 있어야 합니다. 이는 서비스의 안정성을 위한 객관적이고 잘 이해되는 목표가 되어야 합니다. 어느 정도의 목표치가 좋을까요? “지난주에는 서비스가 잘 진행되었다고 생각하지만 설명하기는 어렵다”라는 표현은 여기서 사용할 수 없습니다. 서비스가 SLO를 충족하고 있거나 충족하지 못하고 있습니다. 데이터는 명확해야 합니다. SLO를 충족하지 않는 경우(특히 일정 기간 반복해서), 문제가 있는 것이면 문제를 해결해야 합니다.

오류 예산

서비스가 해당 SLO를 충족하지 않는 경우 조직이 동작에 들어갈 수 있음을 이해할 수 있습니다. 하지만 SRE는 이 개념을 한 단계 더 발전시켜 SLO를 달성 또는 초과 달성한 경우를 대상으로 합니다. 일부 조직에서는 SLO를 사용하여 “오류 예산”이라는 것을 구성합니다.

이 아이디어를 설명하기 위해, 샘플 서비스와 80% 성공 SLO(“전체 시간의 80% 동안 가동해야 함”으로 간주)를 사용하겠습니다. 80% 작동 시간의 SLO를 통해 서비스가 전체 시간의 80% 동안 가동해야 한다고 선언했습니다. 그러나 나머지 20%는 어떻게 해야 할까요? 서비스가 나머지 20%로 다운될 경우 추가 20%를 달성하는 것이 서비스 목표로 중요하지 않다고 결정했기 때문에 “상관”하지 않습니다.

이 시간에 발생하는 상황을 상관하지 않을 경우 서비스에 대해 무엇을 할 수 있을까요? 한 가지 확실한 작업은 일부 기능을 추가하는 새 릴리스로 서비스를 업그레이드하여 실행 중인 서비스를 불안정하게 만드는 것입니다. 새 릴리스가 안정적으로 가동하고 가동 중지 시간이 추가되지 않으면 좋은 일입니다. 새 릴리스로 인해 서비스가 안정적이지 않고 디버그되면서 전체 시간의 10% 동안 오류가 반환되어도 여전히 괜찮습니다. 허용되는 불안정성의 예산 이내에 있기 때문입니다.

오류 예산은 서비스의 잠재적인 완벽한 안정성과 원하는 안정성 간의 차이(100% - 80% = 20%)입니다. 이 경우 오류 예산은 20% 불안정성, 즉 “사양 이내에 있기 때문에 가동 여부를 상관하지 않는” 20% 시간이라는 자금을 제공합니다. 다른 예산과 마찬가지로, 20% 시간을 완전히 고갈될 때까지 원하는 방식(추가 릴리스)으로 계속 지출할 수 있습니다.

일부 조직에서는 SLO를 정하지 않는 덜 만족스러운 사례에도 오류 예산을 사용합니다. 이 경우 단순히 “조치를 수행”하는 대신 좀 더 엄격한 작업을 하도록 선택할 수 있습니다. 서비스에 몇 가지 문제가 있으며 앞에서 선택한 SLI에 60% 가동 시간이 표시되었다고 가정해 보겠습니다. 목표(SLO)는 정하지 않았습니다. 서비스의 오류 예산이 모두 사용되었습니다. 조직은 이 시점에서 시스템을 더 불안정하게 만들 경우 안정성을 악화시킬 뿐이라는 것을 알고 있으므로 계획된 릴리스를 보류할 수 있습니다. 오류 예산은 일반적으로 설정된 시간(월, 분기 등) 동안 계산됩니다. 이는 지속적으로 계산되므로 결국 서비스 안정성이 개선되면 해당 예산이 반환됩니다.

릴리스가 제어된 이 시간 동안 조직은 일부 엔지니어링 리소스를 기능 개발에서 안정성 작업으로 돌립니다. 서비스가 SLO를 충족하지 못하게 하는 문제의 원인을 발견하고 개선하는 것이 목적입니다.

오류 예산과 관련해서 “일부 조직”이라고 말하는 이유는 특히 릴리스 제어에 사용되는 경우 해당 구현에 특정 조직 승인이 필요하기 때문입니다. 릴리스 결정에 직면했을 때 현재까지 서비스의 안정성이 부족한 경우 조직은 릴리스를 보류해야 합니다. 이러한 결정은 모든 조직이 기꺼이 내리는 결정이 아닙니다. 오류 예산 고갈에 대응하는 유일한 방법일 뿐 아니라 가장 많이 이야기되는 대응책입니다.

별도의 모듈에서는 SLA, SLO 및 오류 예산에 대해 자세히 설명합니다. 그러나 이러한 관행의 선순환 측면을 강조하는 것이 좋습니다. 이론상, 조직이 서비스의 안정성을 설명하고 전달하며 실현하는 방법을 제공합니다. 모든 사람이 더 나은 안정성을 위해 작업할 수 있도록 하는 방식으로 작업을 수행합니다. 이 피드백 루프는 매우 중요할 수 있습니다.

선순환 주기 #2: 비난 없는 사후 분석

일반적으로 원하지 않은 중대한 이벤트에 대한 회고 분석인 사후 분석의 아이디어는 사이트 안정성 엔지니어링에만 한정되는 것은 아닙니다. 운영 분야에서도 자주 사용됩니다. 한 가지 특별한 점이라면, SRE에서는 “비난 없는” 사후 분석이어야 한다고 주장하는 것입니다. 특정 사용자의 작업이 아니라 인시던트 동안 발생하는 프로세스 또는 기술 실패에 중점을 두어야 합니다. “적용한 프로세스에서 X가 실패를 초래한 작업을 수행하도록 허용한 것이 무엇이었나요? 이 사용자가 잘못된 결론으로 유도된 순간에 사용할 수 없었거나 눈에 띄지 않았던 정보는 무엇이었나요? 이러한 치명적인 실패가 발생할 수 없도록 하려면 어떤 보호 조치를 구현해야 하나요?” 비난 없는 사후 분석에서는 이러한 종류의 질문이 제기됩니다.

질문의 취지와 방향이 중요합니다. 시스템 또는 프로세스 중단을 초래한 작업을 좋은 의도로 사용한 개인을 처벌하는 방법이 아니라 시스템 또는 프로세스를 개선하는 방법을 모색해야 합니다. “개인을 해고하여 안정성을 얻을 수는 없다”라는 것을 명심해야 합니다. 경험상, 프로덕션 인시던트가 발생할 때마다 개인을 해고(예외가 거의 없음)하는 조직은 이러한 인시던트로부터 교훈을 얻지 못합니다. 대신, 구석에서 흔들리고 있는 개인이 남아 있을 것이며, 두려워서 아무것도 변경하지 못할 것입니다.

그러나 조직의 효과적인 사후 분석 프로세스는 선순환을 만듭니다. 이를 통해 조직은 시스템 중단에서 교훈을 얻고 지속적으로 시스템을 개선할 수 있습니다(적절한 분석 제공 및 후속 조치 수행).

조직이 교훈을 얻고 개선할 수 있는 기회로 수용하는 실패와 오류에 대한 이 관계가 사이트 안정성 엔지니어링의 핵심 원칙입니다. 또 다른 원칙은 이러한 기회를 활용하고 조직을 더 높은 안정성으로 안내하는 선순환을 구성하는 것입니다.

다음 단원에서는 SRE의 사용자 측면을 중심으로 몇 가지 다른 원칙과 사례를 살펴보겠습니다.