SLO, SLI 및 SLA란?
서비스 레벨은 일정 기간 내에 사용자에게 제공되는 서비스를 측정 가능한 용어로 설명합니다. 서비스 레벨 목표(Service-level objectives, SLO)는 시스템에서 기대되는 가용성을 설정한 목표입니다. 서비스 레벨 지표(Service-level indicators, SLI)는 시스템의 가용성을 파악하기 위한 핵심 측정치와 지표입니다. 서비스 레벨 계약(Service-level agreements, SLA)은 시스템이 SLO를 충족하지 못할 경우 발생하는 상황과 합의된 내용을 설명하는 법적 계약입니다.
예를 들어, 웹 애플리케이션의 SLO가 1주일 중 99%에 해당하는 시간 동안 2초 이내에 비디오 재생을 시작하는 것이라고 가정하겠습니다. SLI는 웹사이트에서 2초 이내에 재생을 시작한 비디오의 비율을 측정합니다. SLA에는 이러한 SLO와 고객과 서비스 공급업체가 합의한 기타 SLO와 적용되는 서비스 범위, 그리고 성능을 측정하는 데 사용되는 메트릭인 SLI가 모두 포함됩니다.
서비스의 성능과 안정성을 측정하는 방법에 초점을 맞추는 사이트 안정성 엔지니어링(Site Reliability Engineering, SRE)으로 인해, 분산 시스템의 업타임과 안정성을 유지하기 위한 모범 사례들이 보편화되었습니다. 2016년 3월, Google은 서비스 레벨 목표부터 시작해 메트릭을 모델링, 선택 및 분석하는 프레임워크에 대해 설명하는 '사이트 안정성 엔지니어링: Google이 프로덕션 시스템 운영하는 방법(Site Reliability Engineering: How Google Runs Production Systems)'을 발표했습니다.
그렇다면, SLO, SLI 및 SLA는 서로 어떤 관계이며, 사용자가 기대하는 서비스 레벨을 관리하는 방법과는 어떤 관련이 있을까요? 각 용어에 대해 보다 자세히 알아보겠습니다.
| SLA | SLO | SLI | |
|---|---|---|---|
| Purpose | Establish a level of service quality agreed upon by the customer and provider. | Identify the minimum levels of performance, availability, and other qualities (for example, recoverability) that will satisfy the SLAs. | Measure and report the specific parameters that show the system’s ability to meet each SLO. |
| Examples | Will deliver: 99.99% uptime; two hour resolution time. Minimum 12-hour recovery from data loss. Failure to perform: Payment credits per unit of time. | Response time less than or equal to 300ms; error rate less than 2%; 3 copies of data. | Average response time = 250.1ms. Uptime percentage = 98.9% |
| Typical influencers | Customer, business group, legal department | System architect, system integrator, reliability engineering team | Reliability engineering team |
| When to use | Paid services | Both free and paid services | Reliability engineering team |
| Focus | Scope, metrics, legal and financial consequences | Specific targets to satisfy SLAs | Actual data to assess performance |
| Flexibility | Less flexible. Requires agreement amongst multiple parties: service providers, legal teams, and clients | More flexible. Objectives can be updated according to technological and service capabilities and requirements | Most flexible. Indicators can be adapted according to evolution of technologies, such as new instrumentation and machine learning practices. |
An SLA is typically created by the business and legal teams, working with the customer (for specific contracts). Providers also present general SLAs for their services, such as cloud service providers for their different instance types. SLAs can include multiple SLOs, the scope of services that will be covered, and the SLIs used to measure performance.
SLOs, SLIs, and SLAs help ensure a quality of service from a set of technologies. All influencers of SLOs, SLIs, and SLAs should be consulted to help be sure goals are attainable and customers are satisfied.
SLO란?
SLO(서비스 레벨 목표)는 시스템에서 기대하는 가용성을 설정한 목표로, 일정 기간 동안의 백분율로 표시됩니다.
서비스 레벨 목표는 ‘가용성’과 ‘업타임’이라는 공통된 의미를 기반으로 팀들이 협업하는 데 도움이 됩니다. SLO를 안정성과 가용성을 측정하는 표준으로 사용할 수 있습니다. 이전 예시에서 설명한 것처럼, SLO는 1주일 중 99%의 시간 동안 웹 애플리케이션의 비디오가 2초 이내에 재생되어야 한다는 것입니다.
SLI란?
SLI(서비스 레벨 지표)는 사용자가 시스템의 가용성을 경험하는 방식을 정량적으로 측정한 것입니다. 서비스 레벨의 성공 비율을 백분율로 나타냅니다.
서비스 레벨 지표는 SLO와 관련해 설명이 되지만, SLI는 시스템 안정성에 대한 실시간 신호를 제공합니다. SLI는 임계치보다 빠른 요청의 비율 또는 파이프라인으로 들어오는 기록의 비율을 측정하여 정확한 값을 산출할 수 있습니다. 앞의 예시의 경우, SLI는 웹사이트에서 2초 이내에 재생을 시작한 비디오의 비율을 측정합니다. 이를 통해 SLO와 얼마나 차이가 나는지 알 수 있습니다. SLI는 임계치보다 빠른 요청의 비율 또는 파이프라인으로 들어오는 기록의 비율을 측정하여 정확한 값을 산출할 수 있습니다. 앞의 예시의 경우, SLI는 웹사이트에서 2초 이내에 재생을 시작한 비디오의 비율을 측정합니다. 이를 통해 SLO와 얼마나 차이가 나는지 알 수 있습니다.
SLA란?
SLA(서비스 레벨 계약 또는 협약)는 고객이 서비스를 사용할 때 기대하는 서비스 레벨을 정의합니다.
서비스 레벨 계약은 서비스 제공업체와 고객 간의 계약으로, 공급업체가 제공할 서비스를 문서화하고 공급업체가 충족해야 하는 서비스 표준을 정의합니다. SLA에는 SLO를 위반할 경우 어떤 구제책이나 페널티가 있는지를 설명합니다.
앞의 예시의 경우, SLA에는 웹 애플리케이션에 대한 모든 SLO는 물론 포함될 서비스 범위, SLO에 대한 성능 측정에 사용되는 모든 SLI가 포함됩니다. 계약에는 또한 서비스 제공업체와 고객의 책임도 포함됩니다.
SLO와 비교하여 실시간 사용자 경험을 측정하는 SLI의 더 많은 예시를 살펴봅니다.
서비스 레벨, SLO, SLI 및 SLA는 누가 사용할까요?
SRE 팀, 안정성 엔지니어 및 교차 기능 팀은 서비스의 ‘안정성’을 정의하고 측정하는 데 어려움을 겪는 경우가 많습니다. 교차 기능 팀은 서비스나 시스템의 모든 측면에서 중요한 메트릭에 대한 포괄적인 뷰를 생성하여 업타임과 성능을 쉽게 측정할 수 있어야 합니다.
서비스 레벨은 SRE 팀과 안정성 엔지니어가 애플리케이션과 인프라에서 주요 구성 요소를 식별하는 데 도움이 됩니다. 이들은 하나 이상의 구성 요소가 외부 고객들에게 기능을 노출시키는 경우 알아야 하기 때문입니다. 이러한 교차점을 시스템 경계라고 합니다. 시스템 경계는 사이트 안정성 엔지니어가 시스템의 성능 및 안정성의 실제 상황을 설명하기 위해 서비스 레벨 지표와 목표를 측정 지표에 적용하는 지점입니다.
서비스 범위를 설정하고 어떤 메트릭이 SLI이 되어야 하고, SLO 준수 요구 사항이 무엇인지를 결정하려면 많은 노력이 필요합니다. 복잡하기 때문에 아예 시도하지 않고 포기하는 경우도 많습니다. 안정성 엔지니어와 SRE 팀은 모든 팀을 위해 전체 스택에서 가용성 및 업타임에 대한 기준을 신속하게 설정할 수 있도록, 시스템의 성능 이력을 기반으로 맞춤화된 정확한 SLI 및 SLO가 필요합니다.
SRE 팀이 항상 서비스 레벨 관리에 대한 책임을 지는 것은 아니지만, 서비스 레벨이 책임 범위에 포함되는 경우가 많습니다. SLI를 추적하고 SLO에 연결하면, 시스템 성능에 대한 목표를 설정할 수 있습니다. Google의 SRE 지침은 레이턴시, 트래픽, 오류 및 포화를 서비스 레벨의 4가지 황금 신호로 정의하고 있습니다. 예를 들어, API 호출을 확인하고 고객이 좋은 경험을 하기 위해 성공해야 하는 일반적인 요청의 비율(예: SLO 95%)을 기준으로 성공/실패 요청 수(SLI)를 추적할 수 있습니다.
SRE 팀은 고객에게 어느 정도 레벨의 SLA를 보장해 줘야 할지 보다 잘 이해하기 위해, 애플리케이션과 서비스 내의 핵심 구성 요소에 대해 엄격한 SLO를 설정합니다. 이를 기준으로 팀은 SLO를 준수하려면 얼마나 신속하게 문제를 해결해야 하는지 이해하기 위한 방법으로 오류 예산을 적용할 수 있습니다. 서비스 레벨은 팀이 메트릭을 집계하고 전체 조직에서 업타임, 성능 및 안정성을 투명하게 파악할 수 있도록 해줍니다. 비즈니스 리더들은 서비스 레벨을 사용해 여러 팀, 애플리케이션, 서비스 등의 규정 준수 여부를 한눈에 모니터링하고 시스템 상태를 포괄적으로 파악할 수 있습니다.
서비스 레벨 관리란?
서비스 레벨 관리는 고객에게 제공되는 서비스 레벨에 대한 모든 프로세스와 운영 계약이 적절한지 확인하는 것을 의미합니다. 여기에는 서비스 레벨에 대한 모니터링 및 보고, SLO 설정 및 조정, SLI 결정, SLA 준수 확인, 고객 리뷰 유지 등이 포함됩니다.
중요한 점은 SLO의 경우 팀 간에 ‘가용성’의 의미를 공유해야 한다는 것이며, 이는 SLA를 통해 파악할 수도 있습니다. 이러한 서비스 레벨 계약을 충족하거나 초과 충족하려면, 교차 기능 팀이 내부 SLO를 관리하는 것이 중요합니다.
다음 비디오는 팀들이 뉴렐릭의 서비스 레벨 관리를 어떻게 사용하는지 보여줍니다.
서비스 레벨 관리의 혜택
팀 전체에 SLO 모범 사례를 구현하는 것은 쉽지 않은 일입니다. 팀 간에 공유되는 용어를 정확히 정의하려면 올바른 데이터가 필요합니다.
안정성 엔지니어는 전체 스택과 팀 전체의 가용성 및 업타임에 대한 기준을 신속하게 설정해야 합니다. 서비스 경계를 결정하고 서비스 안정성을 투명하게 파악할 수 있는 SLO와 SLI가 있어야, 고객과의 약속인 SLA를 보다 효과적으로 준수할 수 있습니다. 환경 전반을 개선하려면 안정성, SLO 준수 메트릭 및 오류 예산을 보고할 수 있어야 합니다.
SLI, SLO 및 SLA에 대한 모범 사례와 서비스 레벨 관리를 위한 플랫폼은 다음과 같은 혜택을 제공합니다.
- 간편한 설정: 간단하면서 안내가 포함된 흐름으로 원클릭 설정을 할 수 있으며 권장 사항과 사용자 정의를 통해 모든 서비스의 성능 및 안정성 기준을 자동으로 구축할 수 있습니다.
- 팀 간의 안정성 정의: SLO 및 SLI 권장 사항이 서비스 경계를 결정하는 데 도움을 주기 때문에 복잡한 조정 과정이 필요하지 않습니다. 모든 엔터티의 최신 성능 메트릭을 기반으로 안정성 벤치마크를 자동으로 설정할 수 있습니다.
- 반복 및 개선: Terraform 처럼 코드로 제공되는 오픈소스 인프라 툴을 사용한 자동화와 전체 스택의 컨텍스트를 통해, 특정 노드나 서비스가 시스템 안정성에 미치는 영향을 파악하고 성능을 신속하게 제어할 수 있습니다. 서비스 소유자와 비즈니스 리더 모두를 위한 맞춤형 뷰를 통해, 운영 효율성을 높이고 보고, 알람 및 인시던트 관리 프로세스를 향상할 수 있습니다.
- 안정성 표준화: 조직 간 팀은 서비스 안정성에 대한 투명한 통합된 뷰를 확보하고, 고객에게 적용되는 SLA를 보다 효과적으로 준수할 수 있습니다. SLO 준수 메트릭과 오류 예산은 안정성을 보고하며 애플리케이션, 인프라 및 팀 전반에 걸쳐 일관된 방식으로 변경 사항을 구현할 수 있도록 해줍니다.
자세한 팁은 뉴렐릭의 블로그 복잡한 현대 시스템을 위한 SLO 및 SLI 설정 모범 사례와 서비스 레벨 관리 소개를 참조하십시오.
다음 단계
서비스 레벨 관리, New Relic One으로 시작해보십시오.
서비스 레벨 관리와 옵저버빌리티에 대해 더 자세히 알 수 있는 가장 좋은 방법은 무료로 뉴렐릭 계정을 만들어 옵저버빌리티 솔루션을 직접 경험해보는 것입니다. 뉴렐릭 계정을 신청하십시오. 무료 계정에는 매월 100GB의 무료 데이터 수집과 1명의 무료 전체 액세스 사용자 및 무제한 무료 기본 사용자가 포함됩니다. 로그인 후, 서비스 레벨 관리 문서를 살펴보고 뉴렐릭이 어떻게 시스템의 성능 이력을 바탕으로 SLI와 SLO를 권장해주는지 알아보시기 바랍니다.
이 블로그에 표현된 견해는 저자의 견해이며 반드시 New Relic의 견해를 반영하는 것은 아닙니다. 저자가 제공하는 모든 솔루션은 환경에 따라 다르며 New Relic에서 제공하는 상용 솔루션이나 지원의 일부가 아닙니다. 이 블로그 게시물과 관련된 질문 및 지원이 필요한 경우 Explorers Hub(discuss.newrelic.com)에서만 참여하십시오. 이 블로그에는 타사 사이트의 콘텐츠에 대한 링크가 포함될 수 있습니다. 이러한 링크를 제공함으로써 New Relic은 해당 사이트에서 사용할 수 있는 정보, 보기 또는 제품을 채택, 보증, 승인 또는 보증하지 않습니다.
