홈
topics
서비스 수준 목표
서비스 수준 목표(SLO)는 일정 기간 동안 특정 서비스에 대해 합의된 성능 목표입니다. SLO는 예상되는 서비스의 상태를 정의하고, 이해관계자가 특정 서비스의 상태를 관리하고 혁신과 안정성의 균형을 맞춘 의사 결정을 최적화하는 데 도움이 됩니다.1
SLO는 서비스의 일부 측면에 대한 정량적 메트릭인 서비스 수준 지표(SLI)를 사용하여 측정합니다. SLO는 서비스 제공자와 고객 간의 보다 광범위한 계약인 서비스 수준 계약(SLA)의 일부로, 고객이 제공자에게 기대할 수 있는 서비스 수준을 간략히 설명하고, 해당 목표를 달성하지 못할 경우 부과되는 위약금을 설정합니다.
서비스 수준이 비즈니스 요구 사항 및 고객의 요구와 일치하도록 하려면 사이트 안정성 엔지니어링(SRE) 팀, DevOps, IT 및 기타 관련 팀은 각 애플리케이션의 중요한 사용자 여정, 즉 최종 사용자가 원하는 결과를 얻을 수 있도록 하는 상호 작용을 파악해야 합니다.
SLO(즉, SLA)를 성공적으로 달성하려면 내부 합의가 매우 중요하므로 제품 관리자, DevOps 및 문제 관리 팀, 인프라 엔지니어를 비롯한 여러 이해관계자가 SLO 결정에 참여해야 합니다. 외부 고객은 포커스 그룹, 연구, 고객 불만 및 소셜 미디어를 통해 논의에 참여합니다.
SLO의 핵심 논리는 서비스 안정성이 사용자 만족으로 이어져 더 큰 사업 기회를 제공한다는 것입니다. 측정 가능한 안정성 목표를 설정하면 조직은 IT 예산을 초과하지 않으면서 필요하거나 기대되는 수준을 넘어서는 수준의 서비스를 제공하여 즐겁고 효율적인 사용자 경험과 합리적인 비용 사이에서 균형을 맞출 수 있습니다.
SLO가 필요한 이유는 서비스 품질(QoS) 및 안정성 목표를 구체적이고 측정 가능하며 객관적인 용어로 정의하기 때문입니다. 최고의 성능 수준을 정의하기 위한 것이 아니라, 가능한 최고의 성능 표준 및 용납 가능한 최소한의 성능 표준 범위를 정의하기 위한 것입니다.1개
O`Reilly Media의 97 Things Every Cloud Engineer Should Know(ibm.com 외부 링크)에 SLO의 목표가 잘 요약되어 있습니다. "어떻게 하면 경영진이 안정성, 혁신 속도, 비용 간의 상충 관계를 즉각적으로 이해할 수 있는 쉬운 방법을 제공할 수 있을까요? SLO가 그 해답입니다. SLO는 클라우드 비용, 변경 속도 및 외부 위험 간의 균형을 맞추는 명확한 안정성 가이드라인을 설정합니다.”
본 eBook은 관측 가능성을 둘러싼 오해를 바로잡고 디지털 세계에서 관측 가능성의 역할을 보여주는 것을 목표로 합니다.
SLO는 서비스 성능 추적 및 평가와 관련된 여러 상호 관련된 용어 중 하나입니다.
SLI는 서비스의 일부 측면을 정량적으로 측정한 것입니다. SLI는 오류율, 배치 처리량 또는 요청 대기 시간과 같은 시스템 성능의 측정 기준이 되는 실제 수치를 제공합니다. 집계된 측정값은 일반적으로 비율, 평균 또는 백분위수로 표시됩니다.
SLO는 서비스 수준 협약(SLA)을 준수하기 위해 반드시 충족해야 하는 측정값(예: 응답 시간 200밀리초 미만 유지)의 목표값입니다. 이 값은 보통 일정 기간 동안의 백분율로 표시됩니다.
공급업체와 고객 간의 계약인 SLA는 서비스 활동, 기능 또는 프로세스에 대해 특정 수준을 보장하는 개별 SLO로 구성됩니다. 또한 계약을 이행하지 않을 경우의 위약금도 정하고 있습니다.
SLO의 한 요소인 오류 예산은 계약이 파기되기 전에 용납 가능한 장애 정도를 정의합니다. 오류 예산을 사용하면 실제 상황에서 불가피하게 일어나거나 계획되지 않은 서비스 가동 중지 시간을 통합할 수 있습니다. 가동 중지 시간을 확보해두면 개발 팀이 새로운 개발, 운영 및 설치된 소프트웨어 업데이트 또는 수정과 관련해 정보에 입각한 결정을 내릴 수 있습니다.
안정성과 응답성은 종종 90%, 99%, 99.9% 등과 같이 '100%로 가는 길에 있는 숫자 9'로 측정됩니다. 예를 들어 CPU 가용성에 대한 목표는 다음과 같이 표시될 수 있습니다.
신뢰성 수준 | 허용된 비신뢰성 기간 | ||
|
|
| |
연간 | 분기당 | 30일당 | |
90% | 36.5일 | 9일 | 3일 |
95% | 18.25일 | 4.5일 | 1.5일 |
99% | 3.65일 | 21.6시간 | 7.2시간 |
99.5% | 1.83일 | 10.8시간 | 3.6시간 |
99.9% | 8.76시간 | 2.16시간 | 43.2분 |
99.95% | 4.38시간 | 1.08시간 | 21.6분 |
99.99% | 52.6분 | 12.96분 | 4.32분 |
99.999% | 5.26분 | 1분 30초 | 26.9초 |
|
|
| |
일반적으로 소수점이 100에 가까워질수록 이를 달성하는 데 더 큰 비용과 복잡성이 따릅니다. 내부 및 외부 고객 모두 특정 수준의 응답성을 요구할 수 있으며, 그 이후에는 더 이상 차이를 감지하지 못할 수 있습니다. SLO를 설정하는 것은 과학이자 예술이며, 통계적 완벽성과 비용 효율적이고 현실적인 목표 간의 균형을 유지하는 것입니다.
개발팀은 새로운 기능을 제공하고자 할 수 있고, 운영팀은 안정성과 품질을 유지하면서 통제된 방식으로 변경 사항을 도입하고자 할 수 있습니다. 비즈니스는 내부 및 외부 고객에게 제품이나 서비스를 제공하는 것이므로 고객의 관점에서 서비스 수준을 측정하는 것이 중요합니다.
SLO는 신뢰성을 중심으로 조직을 하나로 모으는 데 도움이 됩니다. 궁극적으로 이해관계자는 속도와 서비스 품질 간의 효과적인 균형을 이루는 고객을 위한 측정 가능한 SLO에 동의해야 합니다.
서비스 수준 목표는 서비스 안정성을 보장하고 서비스 수준 계약을 충족하기 때문에 중요합니다. SLA를 충족하면 고객 만족도가 높아지고 비즈니스에도 도움이 됩니다.
SLO는 외부 고객뿐만 아니라 내부 고객에게도 귀중한 인사이트를 제공합니다. SLO는 다양한 팀이 서비스 및 애플리케이션의 성능을 측정하고 개선할 방법을 결정하는 데 도움이 됩니다. SLO는 다음과 같은 이점을 제공합니다.
SLO와 SLI는 서비스 및 애플리케이션의 성능에 대한 인사이트를 제공하고 팀이 가동 중지 시간 및 기타 잠재적 문제를 정확히 측정할 수 있도록 지원합니다. 이 정보는 기존 제품을 업데이트하고 새로운 기능을 출시할 때 혁신과 안정성 사이에서 균형을 유지하고자 하는 DevOps, IT 및 기타 팀에 유용합니다.
고객이 경험한 마이크로서비스의 상황을 측정하는 잘 고려된 SLO는 제품 성능과 사용자 경험에 대한 귀중한 인사이트를 제공합니다.
SLO를 설정하고 추적하면 조직 전반의 팀이 서비스 및 관련 기대치에 대한 이해를 중심으로 단합하는 데 도움이 됩니다. SLO를 철저하게 고려하면 모든 이해관계자가 자신의 소속 부서가 서비스에 대해 기대하는 바를 평가하고 SLA를 충족하는 데 있어 자신의 역할을 이해하는 커뮤니케이션 문화를 조성할 수 있습니다.
또한 SLO를 사용해 보고서 및 자동화를 만들면 팀의 각 구성원이 인시던트에 대한 질문에 더 빨리 답변할 수 있습니다. SLO는 DevOps, 인프라 및 SRE 팀에 중요하지만, 회사의 거의 모든 측면을 혁신하는 데도 도움이 될 수 있습니다. 관측 가능성을 통해 수집된 데이터는 접근 가능하고 맥락에 맞으며 실행 가능한 정보로 변환될 수 있습니다. 이러한 인사이트는 팀이 시기적절하고 비용 효율적인 결정을 내리는 데 필요한 가시성을 제공합니다.
목표를 명확하게 설정한 조직은 자동화를 통해 SLI를 모니터링하고 측정할 수 있습니다. 이 접근 방식은 모니터링을 넘어 엔드투엔드 프로세스를 완전히 자동화하는 것을 목표로 목표를 달성하는 데 도움이 될 수 있습니다.
자동화된 모니터링 시스템은 서비스 성능이 실제로 SLO에 명시된 목표를 달성하지 못하거나 SLA를 위반하기 전에 잠재적인 문제를 감지하는 데 유용합니다. SLO를 충족하는 프로세스가 확립되면 워크로드 수요에 따라 리소스 할당을 자동화하는 플랫폼을 사용하는 등 일관된 성능을 보장하기 위해 자동화를 구현할 수 있습니다.
SLO는 잠재적인 문제가 발생하기 전에 식별할 수 있는 인사이트를 DevOps 팀에 제공합니다. 이러한 예측을 통해 최종 사용자에게 부정적인 영향을 미치거나 회사에 비용을 초래할 수 있는 용납 불가능한 가동 중지 시간 또는 기타 이벤트를 방지할 수 있습니다.
SLA는 종종 월별 가동 중지 시간 또는 가용성 비율을 사용하여 청구 금액을 계산합니다. 가동 중지 시간 기간은 시스템이 주요 기능을 수행하지 못하는 기간입니다. 예를 들어 통신 장애로 인해 네트워크 가동 중지 시간이 발생할 수 있습니다. 업계의 가용성 표준은 여전히 높게 유지되고 있으며 가동 중지 시간으로 인한 비용도 계속 증가하고 있습니다. SLO를 위반하면 금전적인 영향 외에도 고객 불만족으로 이어질 수 있습니다.
많은 조직이 사후 대응적 인시던트 관리 프로세스를 기반으로 운영됩니다. 그러나 인시던트가 발생할 때까지 기다리면 시스템 내에서 문제를 완화하고 해결하는 데 시간이 더 오래 걸리므로 평균 복구 시간(MTTR)이 늘어납니다.1 SLO를 적절하게 수립하면 관측 가능성을 개선하고 인시던트 관리에 보다 능동적으로 접근할 수 있습니다.
관련 없는 경고는 운영 비용을 증가시키기도 하지만, 존재하지 않는 경고에 응답하느라 엔지니어가 시간을 낭비하고 생산성이 떨어져 직원의 번아웃 비율이 높아질 수 있습니다. 경고와 관련해 가장 큰 어려움 중 하나는 너무 많은 경고와 너무 적은 경고 사이에서 적절한 균형을 찾는 것입니다.
관련 있는 경고는 성능 저하로 인해 신뢰성 목표를 달성하지 못할 가능성이 있는 경우 엔지니어에게 알리는 증상 기반 경고입니다. 예를 들어, 지난 한 시간 동안 서비스의 응답 지연으로 인해 이번주의 지연 시간 SLO를 준수하지 못할 수 있다면 이는 심각한 문제입니다.
현업에 종사하는 사람들에게 시스템 가동 시간 목표가 무엇인지 물어보면 많은 사람들이 100% 달성이 목표라고 이야기할 것입니다. 매우 야심찬 목표이지만, 비용이 많이 들기 때문에 IT 예산의 대부분을 소모할 수 있습니다. SLO는 자랑하기 위한 것이 아니라 고객의 기대치를 파악하고 이를 충족하여 고객 만족과 재구매를 이끌어내기 위해서 설계되었습니다. 신뢰성은 목적이 아니라 수단입니다.
성과 메트릭이 측정 가능하다고 해서 그 메트릭이 고객의 만족 또는 회사의 수익에 중요하다는 의미는 아닙니다. 우선 순위를 지정하세요. 긍정적인 고객 경험을 가장 잘 보여주는 메트릭에 집중하세요.
Foundations of Service Level Management(ibm.com 외부 링크)에서 릭 스텀(Rick Sturm)과 웨인 모리스(Wayne Morris)는 현실적인 SLO를 설정하기 위한 체크리스트를 제시합니다.
SLO는 다음과 같아야 합니다.
· 달성 가능
· 반복 가능
· 측정 가능
· 쉽게 이해 가능
· 유의미
· 제어 가능
· 경제적
· 상호 수용 가능
이 목록의 첫 번째 항목이 '달성 가능'이라는 점에 유의하시기 바랍니다. 실현 불가능한 목표를 세우면 비용이 많이 들 뿐만 아니라 고객이 예상하는 것보다 더 많은 가동 시간을 제공할 수 있을지도 모릅니다. SLO 목표를 달성하는 데 도움이 되는 몇 가지 중요한 모범 사례는 다음과 같습니다.
SLA 또는 비즈니스 목표를 지원하는 SLO를 정의합니다. 20개의 SLO가 5개의 SLO보다 실제로 4배 더 나은가요? 아니면 단순히 IT 팀의 업무량을 늘리고 고객에게 혼란을 줄 뿐 의미 있는 이점을 제공하지 못하는 것은 아닐까요? 측정할 수 있는 모든 항목에 점수를 매겨야 한다고 생각하지 마세요.
지나친 약속을 했다가 약속을 지키지 못하면 위약금이 발생하고 심지어 고객을 잃을 수도 있습니다. 현실적인 SLO 목표를 설정하세요. 내부 이해관계자 및 고객에게 현실적인 정보를 제공하면 모든 사람이 정보에 입각한 결정을 내릴 수 있습니다. 비현실적으로 높은 SLO 목표는 장기적으로 더 많은 비용을 초래할 뿐입니다.
현실적인 기대치에 미리 합의하면 내부 팀과 고객 사이의 혼란과 갈등을 피할 수 있습니다.
수동으로 메트릭을 수집하면 수정 속도가 느려질 수 있고 근본 원인 분석을 활성화하지 못할 수 있습니다. 관련 SLI를 수집하여 SLO를 자동으로 평가하고 SLO를 위반하기 전에 자동 알림을 구축하세요 문제가 심각해지기 전에 해결할 수 있도록 직원에게 필요한 컨텍스트와 종속성을 포함하세요.
IBM Instana는 DevOps, SRE, 플랫폼, ITOps, 개발 전반에서 누구나 필요한 컨텍스트에 따라 원하는 데이터를 얻을 수 있는 솔루션을 제공함으로써 관측 가능성을 대중화합니다. 클라우드 네이티브용으로 구축되었지만 기술에 구애받지 않는 이 플랫폼은 모바일, 웹, 애플리케이션 및 인프라 전반에 걸친 논리적, 물리적 종속성의 컨텍스트에서 고충실도 데이터(1초 단위 세분화 및 엔드투엔드 추적)를 자동으로 지속적으로 제공합니다.
IBM Turbonomic 하이브리드 클라우드 비용 최적화 플랫폼을 사용하면 중요한 작업을 실시간으로 지속적으로 자동화하여 스택의 모든 레이어에서 앱에 컴퓨팅, 스토리지 및 네트워크 리소스를 가장 효율적으로 사용할 수 있도록 선제적으로 제공할 수 있습니다.
각주
1"Service level objectives", IBM, 2023년 9월 6일.