SLO 방법론에서 실무까지: Part1 효과적인 SLO 수립하기¶
최근 들어 조직들은 SLO(서비스 수준 목표)를 SRE(사이트 신뢰성 엔지니어링) 실무의 핵심 요소로 채택하는 사례가 늘고 있습니다. Google은 SLO 관련 모범 사례를 개척했으며, Google SRE 서적에서 이 개념을 잘 소개하고 있습니다. 기본적으로 SLO는 서비스 안정성과 사용자 만족도가 함께 간다는 철학에 뿌리를 두고 있습니다. 구체적이고 측정 가능한 안정성 목표를 설정하면 조직이 제품 개발과 운영 작업 간에 적절한 균형을 유지하여 궁극적으로 긍정적인 최종 사용자 경험을 제공할 수 있습니다.
SLO를 이해하기 위해 세 가지 파트로 나누어 학습합니다:
SLO 방법론에서 실무까지: Part1 효과적인 SLO 수립하기
SLO 방법론에서 실무까지: Part2 SLO 도구 선정
SLO 방법론에서 실무까지: Part3 Guance을 사용한 SLO 관리 모범 사례
핵심 용어¶
본격적으로 시작하기에 앞서, 이 시리즈 전반에서 사용될 핵심 용어를 먼저 살펴보겠습니다:
- SLI(서비스 수준 지표) 는 최종 사용자에게 제공되는 서비스 수준을 측정하는 데 사용되는 지표입니다(예: 가용성, 지연 시간, 처리량).
- SLO(서비스 수준 목표) 는 SLI로 측정된 목표 서비스 수준입니다. 일반적으로 일정 기간 동안의 백분율로 표시됩니다.
- SLA(서비스 수준 계약) 는 최종 사용자가 서비스 제공자로부터 받을 수 있는 서비스 수준을 개괄적으로 설명하는 계약입니다. 이러한 약속이 이행되지 않을 경우 공급자는 일반적으로 금전적 성격(예: 서비스 크레딧, 구독 연장)의 중대한 결과를 초래할 수 있습니다.
- 오류 예산 은 서비스가 SLO를 위반하기 전까지 허용 가능한 불안정성 수준입니다. 간단히 말해, 100% 안정성과 SLO 목표 간의 차이입니다. 오류 예산을 재정 예산처럼 생각할 수 있습니다. 다만 이 경우 개발자는 예산을 새로운 기능 구축, 시스템 아키텍처 재설계 또는 기타 제품 개발 작업에 사용합니다.
서비스 수준 목표가 중요한 대상은 누구인가요?¶
조직 전체의 주요 이해관계자가 SLO를 채택하려면 비즈니스 우선순위와 추진하려는 프로젝트를 고려하여 실제로 달성 가능한 안정성 목표에 합의해야 합니다. 이 섹션에서는 최종 사용자, 개발자 및 운영 엔지니어가 관심을 두는 사항과 SLO 설정 시 목표와 우선순위를 어떻게 고려해야 하는지 자세히 살펴보겠습니다.
최종 사용자¶
어떤 제품이든 최종 사용자는 제공받는 서비스 품질에 대한 기대치를 가지고 있습니다. 사용자는 애플리케이션이 언제든지 액세스 가능하고, 빠르게 로드되며, 올바른 데이터를 반환하기를 원합니다. 지원 티켓이나 인시던트 페이지를 사용하여 고객의 불만족 수준을 측정할 수 있지만, 이에만 의존하여 제품 결정을 내려서는 안 됩니다. 최종 사용자 경험을 완전히 포착하지 못하기 때문입니다. 예를 들어, 모든 장애 티켓을 해결한다고 해서 반드시 최종 사용자가 기대하는 서비스 수준에 도달했다는 의미는 아닙니다.
실제로 100% 안정성을 항상 달성하는 것은 불가능합니다. SLO는 제품 혁신(최종 사용자에게 더 큰 가치를 제공하지만 무언가를 망가뜨릴 위험이 있음)과 안정성(사용자를 만족시키는 요소) 사이에서 올바른 균형을 찾는 데 도움을 줍니다. 오류 예산은 최종 사용자가 서비스 품질 저하를 경험하기 전까지 개발 작업이 감당할 수 있는 불안정성의 수준을 결정합니다.
개발자 및 운영 엔지니어¶
전통적으로 개발자와 운영 엔지니어 간의 불일치는 상반된 목표와 책임에서 비롯됩니다. 개발자는 서비스에 더 많은 기능을 추가하는 데 중점을 두는 반면, 운영 엔지니어는 이러한 서비스의 안정성을 유지하는 역할을 담당합니다. SLO는 긍정적인 비즈니스 성과를 촉진할 뿐만 아니라, 개발팀과 운영팀이 애플리케이션의 안정성에 대한 공동 책임 의식을 갖도록 하는 문화적 변화를 촉진합니다.
SLO와 그에 따른 오류 예산을 통해 팀은 어떤 프로젝트나 계획에 우선순위를 둘지 객관적으로 결정할 수 있습니다. 오류 예산이 남아 있는 한 개발자는 제품 전반적인 품질을 향상시키기 위해 새로운 기능을 출시할 수 있고, 운영 엔지니어는 데이터베이스 유지 관리 및 프로세스 자동화와 같은 장기적인 안정성 프로젝트에 더 집중할 수 있습니다. 그러나 오류 예산이 소진되기 시작하면 개발자는 기능 작업 속도를 늦추거나 중단하고, 운영팀과 긴밀히 협력하여 SLA나 SLO를 위반하기 전에 시스템을 다시 안정화해야 합니다. 간단히 말해, 오류 예산은 개발자와 운영 엔지니어의 작업과 목표를 조정하는 정량화 가능한 방법입니다.
SLI에서 SLO로¶
이제 SLO와 관련된 몇 가지 핵심 개념을 정의했으므로, 이를 어떻게 구성할지 고민해 볼 차례입니다. 사용자가 제품을 어떻게 경험하는지, 그리고 어떤 사용자 여정이 가장 중요한지 깊이 이해하는 것이 유용한 SLO를 만드는 첫 번째이자 가장 중요한 단계입니다. 고려해야 할 몇 가지 질문은 다음과 같습니다:
- 사용자는 애플리케이션과 어떻게 상호작용하나요?
- 애플리케이션을 통한 사용자의 여정은 무엇인가요?
- 이러한 여정은 인프라의 어떤 부분과 상호작용하나요?
- 사용자는 시스템에 대해 어떤 기대를 하고 있으며, 무엇을 완료하기를 원하나요?
이 시리즈에서는 귀하가 전자상거래 기업에서 근무하고 있으며, 이러한 기업이 어떻게 SLO를 설정할지 고려해 보겠습니다. 고객이 웹사이트와 어떻게 상호작용하는지, 그리고 처음 웹사이트에 진입하여 나갈 때까지의 경로를 파악해야 합니다. 기본적인 수준에서 고객은 로그인, 상품 검색, 개별 상품 상세 정보 확인, 장바구니에 상품 추가, 결제를 할 수 있어야 합니다. 이와 같은 핵심 사용자 여정은 사용자 경험과 직접적으로 연결되므로 SLO를 설정하는 것이 중요합니다.
이 작업을 완료한 후에는 이러한 핵심 사용자 여정에서 제공되는 서비스 수준을 정량화할 지표 또는 SLI를 선택할 수 있습니다.
좋은 SLI 선택하기¶
인프라가 점점 더 복잡해짐에 따라 모든 데이터베이스, 메시지 큐, 로드 밸런서에 대해 외부 SLO를 설정하는 것은 점점 더 번거로워집니다. 대신 시스템 구성 요소를 몇 가지 주요 범주(예: 응답/요청, 스토리지, 데이터 파이프라인)로 구성하고 각 범주 내에서 SLI를 지정하는 것이 좋습니다.
SLI를 선택하기 시작할 때는 짧지만 중요한 명언을 기억하세요: "모든 SLI는 지표이지만, 모든 지표가 좋은 SLI는 아닙니다." 즉, 수백 또는 수천 개의 지표를 추적할 수 있지만, 가장 중요한 지표, 즉 사용자 경험을 가장 잘 포착하는 지표에 집중해야 합니다.
Google SRE 서적의 아래 표를 참고 자료로 사용할 수 있습니다.
이제 쇼핑객이 결제 페이지에서 느린 결제 엔드포인트의 응답을 기다리며 막혀 있는 상황을 상상해 보세요. 기다리는 시간이 길어질수록 비즈니스에 대한 부정적인 인상을 받을 가능성이 높아집니다. 평판 손상 외에도 고객이 장바구니를 포기하면 비용이 많이 드는 결과를 초래할 수 있습니다. 실제로 가장 크고 성공적인 조직 중 일부는 1초의 지연이 수익의 현저한 감소와 상관관계가 있음을 발견했습니다. 이 예에서 응답 지연 시간은 온라인 소매업체가 고객이 중요한 비즈니스 트랜잭션을 신속하게 완료할 수 있도록 보장하기 위해 추적해야 하는 특히 중요한 SLI임을 알 수 있습니다.
이를 좋은 SLI가 될 가능성이 거의 없는 지표인 CPU 사용률과 비교해 보세요. 서버에서 CPU 사용량이 급증하고 인프라 팀이 이러한 높은 사용률 알림을 더 자주 받더라도, 최종 사용자는 여전히 문제 없이 결제를 완료할 수 있습니다. 여기서 중요한 점은 지표가 내부 팀에 아무리 중요하더라도 그 값이 사용자 만족도에 직접적인 영향을 미치지 않는다면 SLI로서의 유용성이 없다는 것입니다.
좋은 SLI를 식별한 후에는 모니터링 시스템의 데이터를 사용하여 이를 측정해야 합니다. 마찬가지로, 사용자에게 가장 가까운 구성 요소에서 데이터를 추출하는 것이 좋습니다. 예를 들어, 결제 서비스의 일부로 신용카드 거래를 승인하는 결제 API를 사용할 수 있습니다. 이 서비스를 구성하는 다른 많은 내부 구성 요소(예: 서버, 백그라운드 작업 프로세서)가 있지만, 일반적으로 사용자 관점에서는 추상화되어 있습니다. SLI는 최종 사용자 경험을 정량화하는 데 사용되므로, 사용자에게 기능을 노출하는 결제 엔드포인트에서만 데이터를 수집하는 것으로 충분합니다.
SLI를 SLO로 변환하기¶
마지막으로 SLI에 목표값(또는 값 범위)을 설정하여 SLO로 변환해야 합니다. 최상 및 최악의 기준이 무엇인지, 그리고 해당 조건이 얼마나 오래 유효해야 하는지 명시해야 합니다. 예를 들어, 요청 지연 시간을 추적하는 SLO는 "30일 동안 인증 서비스 요청의 99%가 250밀리초 미만의 지연 시간을 가져야 함"과 같을 수 있습니다.
SLO 생성을 시작할 때 다음 사항을 염두에 두어야 합니다.
현실적으로 설정하세요 SLO를 100%로 설정하는 것이 아무리 유혹적일지라도, 실제로는 달성이 거의 불가능합니다. 오류 예산을 고려하지 않으면 개발팀이 새로운 기능을 시도할 때 지나치게 신중해져 제품 성장을 저해할 수 있습니다. 일반적인 업계 표준은 SLO 목표를 여러 개의 9(예: 99.9%는 "3-nine", 99.95%는 "3.5-nine")로 설정하는 것입니다.
일반적인 원칙으로, SLO는 SLA에 명시된 내용보다 더 엄격해야 합니다. 지속적으로 미달하는 것보다는 항상 신중하게 접근하여 SLA를 충족하는 것이 더 좋습니다.
실험해 보세요 SLO를 완성하는 데 정해진 규칙은 없습니다. 각 조직의 SLO는 제품의 특성, 이를 관리하는 팀의 우선순위, 최종 사용자의 기대에 따라 달라집니다. 최적의 값을 찾을 때까지 계속 목표를 최적화할 수 있다는 점을 기억하세요. 예를 들어, 팀이 지속적으로 목표를 크게 초과 달성한다면, 해당 값을 더 강화하거나 사용하지 않은 오류 예산을 제품 개발에 더 투자하는 것을 고려할 수 있습니다. 반대로 팀이 지속적으로 목표를 달성하지 못한다면, 달성하기 더 쉬운 수준으로 낮추거나 제품 안정화에 더 많은 시간을 투자하는 것이 현명할 수 있습니다.
복잡하게 만들지 마세요 마지막으로, SLO 목표를 정의할 때 너무 많은 SLO를 설정하거나 SLI 집계를 지나치게 복잡하게 만들고 싶은 유혹을 물리치세요. 핵심 여정을 구성하는 모든 클러스터, 호스트 또는 구성 요소에 대해 개별 SLI를 설정하는 대신 의미 있는 방식으로 단일 SLI로 집계해 보세요. 일반적으로 SLO와 SLI는 최종 사용자 경험에 중요한 것으로 제한해야 합니다. 이렇게 하면 노이즈를 제거하고 진정으로 중요한 것에 집중할 수 있습니다.
이제 SLO를 알게 되었습니다¶
이 블로그 게시물에서는 올바른 SLI를 선택하고 이를 명확하게 정의된 SLO로 변환하는 방법이 조직을 성공으로 이끌 수 있는지 살펴보았습니다. SLI를 사용하여 사용자에게 제공하는 서비스 수준을 측정하고, 실제 SLO를 기준으로 성능을 추적하면 기능 속도와 시스템 안정성을 개선하기 위한 더 나은 결정을 내릴 수 있습니다. 이 가이드를 간단한 체크리스트로 요약했으니, SLO 생성을 시작하고 더 많은 팀 구성원을 참여시킬 때 참고하시기 바랍니다.
이 시리즈의 다음 부분에서는 기술 및 비즈니스 팀이 Guance을 사용하여 SLO와 기타 모니터링 데이터를 관리함으로써 더 효과적으로 협업하는 방법을 알아보세요.