New Relic Now+ 뉴렐릭의 혁신적인 플랫폼 업데이트에는 20여 개의 새로운 기능이 포함되었습니다.
이벤트의 온디맨드 동영상을 시청하세요.

서비스 수준은 일정 기간 내에 사용자에게 제공되는 서비스를 측정 가능한 용어로 설명합니다.

  • 서비스 수준 목표(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)으로 인해, 분산 시스템의 업타임과 안정성을 유지하기 위한 모범 사례들이 보편화되었습니다. 서비스 수준 목표부터 시작해 메트릭을 모델링, 선택 및 분석하는 프레임워크를 자세히 설명한 Google의 전자책 “사이트 안정성 엔지니어링: Google이 프로덕션 시스템을 운영하는 방법”을 확인해 보시기 바랍니다.

SLO, SLI, SLA: 차이점

SLO, SLI, SLA는 여러 면에서 다르지만, 함께 결합되어 효과적인 운영과 고객 만족을 보장하도록 설계된 일관된 스택을 구성합니다. 각각을 더 자세히 살펴보겠지만, 아래 표는 기둥이 되는 이 세 가지 요소에 대한 개요를 제공합니다.

SLA SLO SLI
목적 고객과 서비스 제공업체가 합의한 서비스 품질 수준 확립. SLA를 충족하는 최소 수준의 성능, 가용성 및 기타 품질(예: 복구 가능성) 식별. 각 SLO를 충족할 수 있는 시스템의 능력을 보여주는 특정 파라미터의 측정 및 보고.
제공되는 사항: 99.99% 업타임; 해결 시간 2시간. 데이터 손실 시 최소 12시간 소요. 성능 실패: 시간 단위당 결제 크레딧. 응답 시간은 300ms 이하, 오류율은 2% 미만, 데이터 사본은 3개. 평균 응답 시간= 250.1ms.업타임 비율 = 98.9%
일반적으로 영향을 주는 당사자 고객, 사업 그룹, 법무부 시스템 아키텍트, 시스템 통합업체, 안정성 엔지니어링 팀 안정성 엔지니어링 팀
사용 시기 유료 서비스 무료 및 유료 서비스 모두 안정성 엔지니어링 팀
중점 범위, 메트릭, 법적 및 재정적 결과 SLA를 만족시키기 위한 구체적인 목표 성능 평가를 위한 실제 데이터
유연성 덜 유연함. 여러 당사자 간의 합의 필요: 서비스 공급업체, 법률 팀 및 고객 더 유연함. 목표는 기술 및 서비스 역량과 요구 사항에 따라 업데이트될 수 있습니다. 가장 유연함. 지표는 새로운 계측 및 머신 러닝 관행 등 기술의 발전에 따라 조정될 수 있습니다.

SLA는 일반적으로 비즈니스 및 법무팀이 고객(특정 계약)과 협력하여 생성합니다. 공급업체는 자사 서비스에 대한 일반적인 SLA를 제시합니다. 예를 들어 클라우드 서비스 공급업체는 다양한 인스턴스 유형에 대해 SLA를 제공할 수 있습니다. SLA에는 여러 SLO와 적용되는 서비스 범위, 성능 측정에 사용되는 SLI가 포함될 수 있습니다.

SLO, SLI, SLA는 일련의 기술에서 서비스 품질을 보장하는 데 도움이 됩니다. SLO, SLI, SLA에 영향을 미치는 모든 당사자와 협의하여 목표 달성이 가능한지 또 고객이 만족하는지 확인해야 합니다.

서비스 수준 목표(SLO)란?

서비스 수준 목표는 시스템에서 기대하는 가용성을 설정한 목표로, 일정 기간 동안의 백분율로 표시됩니다.

서비스 수준 목표는 ‘가용성’과 ‘업타임’이라는 공통된 의미를 기반으로 팀들이 협업하는 데 도움이 됩니다. SLO를 안정성과 가용성을 측정하는 표준으로 사용할 수 있습니다. 이전 예시에서 설명한 것처럼, SLO는 1주일 중 99%의 시간 동안 웹 애플리케이션의 비디오가 2초 이내에 재생되어야 한다는 것입니다.

SLO의 예

이전에 언급한 바와 같이 SLO는 고객과 합의된 광범위한 서비스 수준 계약(SLA)과 기술 메트릭을 연결하는 역할을 합니다. 몇 가지 예를 더 살펴보겠습니다.

업타임/가용성 SLO

  • 30일 동안 99.9%의 업타임 제공
  • 일주일 동안 시스템 오류로 인해 요청이 실패하는 비율이 0.1% 미만

레이턴시 SLO

  • 웹 페이지 로드의 95%가 2초 이내에 완료
  • API 요청의 99%가 300밀리초 이내에 반환

오류율 SLO

  • 모든 트랜잭션의 0.05% 미만에서 오류 발생
  • 데이터베이스 쓰기 중 실패가 1% 미만

처리량 SLO

  • 시스템이 피크 타임 중 초당 10,000개의 요청 처리 가능
  • 속도 저하 없이 일일 5TB의 데이터 수집 가능

용량 및 사용량 SLO

  • 중요 시스템의 디스크 사용률이 상시 80% 미만으로 유지됨
  • 모든 서비스 인스턴스에서 총 RAM 사용량은 70%를 넘지 않음

데이터 무결성 및 일관성 SLO

  • 5분 안에 클러스터 간 데이터 복제 완료
  • 1차 및 2차 스토리지 시스템 간의 데이터 불일치가 0.01% 미만

내구성 SLO

  • 1년 간 99.9999999%의 데이터 내구성 제공
  • 백업 복원 성공률은 99.5%

변경 관리 및 배포 SLO

  • 배포의 98%가 롤백 없이 수행
  • 99%의 변경 사항은 계획되지 않은 중단으로 이어지지 않음

SLO를 설정하는 방법

올바른 SLO를 설정하는 것은 전략적인 과정이지만 올바르게 수행하면 서비스 안정성이 향상되고 탁월한 고객 경험을 제공할 수 있습니다.

  1. 사용자의 기대치와 요구사항을 이해해야 합니다. 애플리케이션의 성능과 안정성에 중요한 것이 무엇인지 파악하기 위해 고객 및 내부 팀을 비롯해 모든 이해관계자와 협력해야 합니다.
  2. 시스템의 과거 성능을 분석하여 현재 동작을 이해하고 반복되는 문제나 주의를 기울여야 하는 영역을 파악합니다. 이 정보를 이용하면 레이턴시, 오류율, 업타임 등 서비스의 상태를 실질적으로 보여주는 구체적이고 측정 가능한 지표를 설정할 수 있습니다.
  3. 이러한 지표가 마련되면 바로 타깃 목표를 정의합니다. 목표는 어렵지만 달성 가능해야 하며 더 광범위한 비즈니스 목표에 부합해야 합니다. 

SLO는 사용자 기대치, 시스템 동작 또는 비즈니스 우선순위의 변화를 반영하기 위해 주기적으로 검토 및 조정되어야 합니다. 또한 균형을 맞추는 것이 중요합니다. 높은 안정성이 중요하지만, 지나치게 엄격한 SLO는 민첩성과 혁신을 저해할 수 있습니다. 뉴렐릭 같은 협업 툴과 옵저버빌리티 플랫폼은 시스템과 비즈니스가 발전함에 따라 SLO를 지속적으로 모니터링하고 조정하는 데 도움을 줄 수 있습니다.

공격적인 SLO와 현실적인 SLO 간에 어떻게 균형을 맞출 수 있을까요?

균형을 맞추려면 사용자의 기대치와 시스템의 기술적 기능을 이해해야 합니다. 어렵지만 실행 가능한 SLO를 설정하려면 비즈니스 측과 기술 측 이해 관계자 모두를 관여시키는 것이 중요합니다.

SLO가 지속적으로 충족되지 않으면 어떻게 될까요?

SLO가 지속적으로 충족되지 않는 경우 서비스에 근본적인 문제가 있음을 알 수 있습니다. 근본 원인 분석을 수행하여 문제를 파악하고 개선 작업을 수행해야 합니다. SLA의 경우, SLO가 충족되지 않으면 계약에 정의된 벌금이나 기타 결과가 초래될 수 있습니다.

서비스 수준 지표(SLI)란?

서비스 수준 지표는 사용자가 시스템의 가용성을 경험하는 방식을 정량적으로 측정한 것입니다. 서비스 레벨의 성공 비율을 백분율로 나타냅니다.

SLI는 SLO와 관련해 설명이 되지만, SLI는 시스템 안정성에 대한 실시간 신호를 제공합니다. SLI는 임계치보다 빠른 요청의 비율 또는 파이프라인으로 들어오는 기록의 비율을 측정하여 정확한 값을 산출할 수 있습니다. 앞의 예시의 경우, SLI는 웹사이트에서 2초 이내에 재생을 시작한 비디오의 비율을 측정합니다. 이를 통해 SLO와 얼마나 차이가 나는지 알 수 있습니다. SLI는 임계치보다 빠른 요청의 비율 또는 파이프라인으로 들어오는 기록의 비율을 측정하여 정확한 값을 산출할 수 있습니다. 앞의 예시의 경우, SLI는 웹사이트에서 2초 이내에 재생을 시작한 비디오의 비율을 측정합니다. 이를 통해 SLO와 얼마나 차이가 나는지 알 수 있습니다.

SLI의 예

SLI는 SLO와 SLA의 기반이 됩니다. 몇 가지 예를 살펴보겠습니다.

가용성/업타임

  • 총 요청 대비 성공한 요청의 비율
  • 전체 기간 중 시스템 업타임의 비율

레이턴시

  • API 요청이 응답을 반환하는 데 걸리는 시간
  • 최종 사용자에게 웹 페이지가 로드되는 데 걸리는 시간

처리량

  • 초당 처리되는 요청 수입니다.
  • 특정 기간 내에 처리되는 데이터의 양

오류율

  • 총 요청 대비 실패한 요청의 비율
  • 반환된 4xx 또는 5xx HTTP 상태 코드의 수

포화도

  • CPU나 RAM 같은 리소스 활용률
  • 사용 가능한 총 저장 공간 대비 사용된 저장 공간의 양

커버리지

  • 정해진 기간 내에 새로운 기능 업데이트를 받은 사용자의 비율
  • 총 전달된 응답 대비 캐시된 응답의 비율

선도(Freshness)

  • 데이터가 쓰여진 시점을 기준으로 읽기되는 데이터의 수명
  • 여러 데이터베이스나 시스템에 걸쳐 데이터를 복제하는 데 걸리는 시간

용량

  • 시스템이 동시에 처리할 수 있는 최대 사용자 또는 세션 수
  • 시스템이 성능 저하 없이 처리할 수 있는 최대 데이터 볼륨

서비스에 적합한 SLI를 어떻게 선택할까요?

SLI는 사용자/고객에게 가장 중요한 사항을 기준으로 선택해야 합니다. 일반적인 SLI에는 레이턴시, 오류율, 처리량, 가용성이 포함됩니다. 사용자의 기대치와 비즈니스 우선순위를 이해하는 것이 중요합니다.

SLI를 정확하게 측정하려면 어떻게 해야 할까요?

정확한 측정을 위해서는 모니터링 및 로깅 시스템을 구현해야 합니다. 관련 데이터 포인트를 수집하고 SLI에 인사이트를 제공하는 툴을 사용합니다. 정확성을 보장하기 위해 측정 시스템을 정기적으로 검증하고 조율해야 합니다.

서비스 수준 계약(SLA)이란?

서비스 수준 계약은 고객이 서비스를 사용할 때 기대하는 서비스 수준을 정의합니다.

서비스 수준 계약은 서비스 제공업체와 고객 간의 계약으로, 공급업체가 제공할 서비스를 문서화하고 공급업체가 충족해야 하는 서비스 표준을 정의합니다. SLA에는 SLO를 위반할 경우 어떤 구제책이나 페널티가 있는지를 설명합니다.

앞의 예시의 경우, SLA에는 웹 애플리케이션에 대한 모든 SLO는 물론 포함될 서비스 범위, SLO에 대한 성능 측정에 사용되는 모든 SLI가 포함됩니다. 계약에는 또한 서비스 제공업체와 고객의 책임도 포함됩니다.

SLO와 비교하여 실시간 사용자 경험을 측정하는 SLI의 더 많은 예시를 살펴봅니다.

SLI, SLO, SLA는 옵저버빌리티에 매우 중요합니다. 뉴렐릭으로 서비스 수준 관리를 시작하십시오.

SLA의 예

SLA는 회사와 고객마다 다르며 제공되는 서비스에 따라 달라질 수 있습니다. 다음은 주요 비즈니스 리더의 SLA 사례를 보여주는 링크입니다.

SLA를 작성할 때 참고할 수 있는 선도적인 기업들의 SLA 사례가 많이 나와 있습니다.

우수한 SLA를 작성하는 방법

SLA를 작성하려면 고객, 공급업체의 법률 고문, 사업부, 안정성 팀을 포함한 다양한 분야의 이해관계자들의 의견을 취합할 필요가 있습니다. 이는 법적 구속력이 있는 계약이므로 SLA의 항목은 팀의 모든 구성원이 철저하고 솔직하게 논의해 결정해야 합니다.

SLA는 법적 계약이므로 포괄적인 문서입니다. 따라서 SLA에는 다음 조항이 포함될 수 있습니다.

  • 소개 정보, 법률 용어의 정의, 계약 범위, 목적, 검토 기간, 계약 파라미터 등에 대한 개요가 포함됩니다.
  • 본문에는 고객이 기대할 수 있는 서비스 품질, 해당 품질을 제공하기 위한 목표, 모니터링 및 추적될 메트릭, 발생할 수 있는 문제 유형과 이를 해결하기 위한 대응 시간이 포함됩니다.
  • 응답 시간에 고객의 응답으로 인한 지연은 포함되지 않는다는 것 등 계약에서 제외되는 항목이나 이벤트를 예외 사항으로 명시합니다.
  • SLA를 충족하기 위해 누가 무엇을 할 것인지를 의무와 책임으로 명시합니다. 여기에는 문제를 해결하기 위한 공급업체와 고객의 대응이 포함됩니다.
  • 서비스 담당자가 응답 가능한 시간, 어떤 유형의 서비스를 제공할지(현장, 전화 지원, 온라인/채팅 지원 등), 응답 시간에 영향을 미치는 기타 측면 등 서비스 가용성을 정의합니다.
  • 개요에 포함된 법률 용어 외에도 용어의 의미를 정의하는 데 도움이 되는 자료와 용어집을 포함할 수 있습니다.
  • 다양한 서비스에 대한 요금 체계가 포함됩니다.
  • SLA를 충족하지 못할 경우 고객에게 제공되는 보상을 명시합니다. 이는 종종 크레딧이라는 용어로 설명됩니다.
  • 기타 주제를 다루기 위해 부록을 첨부할 수도 있습니다.

SLA를 위반하면 어떻게 될까요?

SLA는 법적 구속력이 있는 계약이므로 당사자 중 한 쪽 또는 양쪽이 의무를 이행하지 못하면 그에 따른 불이익이 따릅니다. 이에 따른 구제책(보상)이 SLA에 정의되어야 합니다. 위반이 의심되는 경우, 고객부터 안정성 엔지니어링 팀에 이르기까지 관련된 모든 당사자 간에 명확하고 빈번하고 전문적인 의사소통이 먼저 이루어져야 합니다.

SLA 위반을 관리하는 데 있어 가장 중요한 원칙은 사람이 아니라 문제를 비난해야 한다는 것입니다. 문제를 해결하면 위기를 피할 수 있습니다. 

서비스 수준, SLO, SLI 및 SLA는 누가 사용할까요?

법률, 비즈니스, 안정성 엔지니어링을 포함한 기능 간 팀은 SLO, SLI, SLA를 활용해 고품질 서비스를 정의하고 제공합니다. 반면, 고객들은 SLA를 서비스 제공업체가 기대하는 서비스 수준과 관련해 행한 약속으로 간주합니다. 여러 이해관계자들이 얽혀 있기 때문에 서비스 수준 스택을 정의하기가 쉽지 않습니다. 이해관계자들은 종종 서비스 "안정성"을 정의하고 측정하는 데 어려움을 겪습니다. 

서비스 수준은 팀이 메트릭을 집계하고 전체 조직에서 업타임, 성능 및 안정성을 투명하게 파악할 수 있도록 해줍니다. 비즈니스 리더들은 서비스 수준을 사용해, 한눈에 여러 팀, 애플리케이션, 서비스 등의 규정 준수 여부를 모니터링하고 시스템 상태를 포괄적으로 파악할 수 있습니다.

서비스 수준 지표는 SRE 팀과 안정성 엔지니어가 애플리케이션과 인프라에서 주요 구성 요소를 식별하는 데 도움을 줍니다. 이들은 하나 이상의 구성 요소가 외부 고객들에게 기능을 노출시키는 경우 알아야 합니다. 이러한 교차점을 시스템 경계라고 합니다. 

SLI이 사용되는 경우

설정된 SLO에 대해 서비스를 정량화해야 할 때마다 SLI를 사용합니다. 목표를 설정하면 성과를 보여주기 위해 목표를 검증할 필요가 있습니다. 이를 염두에 두고 안정성 엔지니어와 SRE 팀은 전체 스택에서 가용성 및 업타임에 대한 기준 SLO를 설정할 수 있도록 과거 시스템 성능을 기반으로 한 정확한 SLI가 필요합니다. 

시스템 경계는 사이트 안정성 엔지니어가  시스템의 성능 및 안정성의 실제 상황을 설명하기 위해 서비스 수준 지표와 목표를 측정 지표에 적용하는 지점입니다

SLO가 사용되는 경우

SLO는 시스템에서 원하는 서비스 수준을 달성해야 할 때마다 적용될 수 있습니다. 소규모 사업체부터 대기업까지 보통 기대되는 최소한의 서비스 수준이 존재합니다. SLO는 서비스 품질을 달성하는 방법을 정의합니다.

SRE 팀은 고객에게 어느 정도 수준의 SLA를 보장해야할지 더 잘 이해하기 위해, 애플리케이션과 서비스 내의 핵심 구성 요소에 대해 보통 엄격한 SLO를 설정합니다. 여기에서 팀은 SLO를 준수하기 위해 얼마나 신속하게 문제를 해결해야 하는지 이해하기 위한 방편으로 오류 한도를 적용할 수 있습니다.

SLA가 사용되는 경우

유료 고객에게는 항상 SLA를 사용합니다. 일부 SLA는 고객이나 필요한 서비스에 따라 달라질 수 있습니다. 클라우드나 기타 IT 서비스에 대한 일반 SLA는 고객이 공급업체의 시스템에서 무엇을 기대할 수 있는지 정의합니다. SLA를 제공하지 않고 고객에게 동의를 요구하지 않으면 모호함이 야기되고, 이는 고객 불만과 법적 문제로 이어질 수 있습니다.

SLA, SLO, SLI의 도전과제

SLA, SLO, SLI의 도전과제를 인지하는 것은 더 효과적인 서비스 수준을 수립하는 데 도움이 될 수 있습니다. 각각 사전에 해결해야 할 몇 가지 도전과제는 다음과 같습니다.

SLO의 도전과제

  • 효과적인 메트릭 선택: 메트릭(SLI)은 비즈니스 목표(SLO)와 부합해야 하며 고객 기대치(SLA)를 보장해야 합니다. 그러므로 올바른 메트릭을 선택하는 것은 매우 중요하면서도 어려울 수 있습니다.
  • 균형 유지: 균형 잡힌 SLO를 정의하는 것은 어려울 수 있습니다. 측정 가능한 SLO를 정의합니다. 달성 가능성이 입증되지 않은 SLI와 잘 정의되지 않은 SLO에 시간을 낭비하면 안됩니다. 하지만, SLO가 쉽게 충족된다면 경쟁업체와 차별화를 꾀하는 것이 힘들 수 있습니다.
  • 외부 종속성 유지: 서비스 안정성에 중요한 타사 서비스를 최신 상태로 유지해야 합니다.외부 서비스에 장애가 발생하면 내부 구성 요소가 완벽하게 작동하더라도 SLO를 준수하는 능력이 저하될 수 있습니다.

SLI의 도전과제

  • 너무 많은 메트릭: 데이터가 너무 많아 측정이 복잡해지면 사이트 안정성 팀에 부담이 갑니다. 팀이 모니터링, 해석 및 유지 관리하는 데 필요한 투자 수익을 파악할 수 있도록 각 메트릭을 평가해야 합니다.
  • 측정이 어려운 메트릭: 사용자 참여도, 실시간 성능 레이턴시, 사용자 만족도 등 일부 성능 메트릭은 정확하게 측정하기 어렵습니다. 머신 러닝이나 기타 AI 툴 등의 자동화된 방법을 사용하면 이러한 메트릭을 보다 정확하게 정의하고 측정하는 데 도움이 될 수 있습니다.

SLA의 도전과제

  • 모든 이해관계자의 관여: 협력이 관건입니다. SLA를 달성하기 위해 무엇이 왜 필요하고 어떻게 해야 하는지를 정의하고 이해하는 데 충분한 시간을 들여야 합니다. SLA는 고객과의 관계를 정의합니다. SLA를 제공할 때 안정성 엔지니어링부터 고객까지 모든 이해관계자를 포함시키지 않으면 비현실적인 SLO가 생겨나고 예상된 서비스 품질이 제공되지 않을 수 있습니다.
  • 고객 요구 사항과 새로운 기술에 적응: 기술이 빠르게 발전하고 있어 안정성 엔지니어링을 위한 새로운 툴을 따라잡기가 어려워졌습니다. 고객의 요구가 변하는 경우에도 마찬가지이며, 이를 위해서는 빈번한 조정과 재협상이 필요할 수 있습니다.
  • 비용: 비용과 이익 간의 균형을 맞추는 것은 항상 어려운 일입니다. SLA는 모든 관점에서 고려되어야 하며, 이는 여러 다른 팀들이 인적 자원을 투자해야 한다는 것을 의미합니다. 이 부분을 소홀히 하면 더 많은 비용이 드는 소송으로 이어질 수 있고, 최악의 경우 고객의 신뢰를 잃을 수도 있습니다.

서비스 수준 관리란?

서비스 수준 관리는 고객에게 제공되는 서비스 수준에 대한 모든 프로세스와 운영 계약이 적절한지 확인하는 것을 의미합니다. 여기에는 서비스 수준에 대한 모니터링 및 보고, SLO 설정 및 조정, SLI 결정, SLA 준수 확인, 고객 리뷰 유지 등이 포함됩니다. 

중요한 점은 SLO의 경우 팀 간에 ‘가용성’의 의미를 공유해야 한다는 것이며, 이는 SLA를 통해 파악할 수도 있습니다. 이러한 서비스 수준 계약을 충족하거나 초과 충족하려면, 교차 기능 팀이 내부 SLO를 관리하는 것이 중요합니다.

다음 비디오는 팀들이 뉴렐릭의 서비스 수준 관리를 어떻게 사용하는지 보여줍니다.

서비스 수준 관리의 이점

팀 전체에 SLO 모범 사례를 구현하는 것은 쉽지 않은 일입니다. 팀 간에 공유되는 용어를 정확히 정의하려면 올바른 데이터가 필요합니다.

안정성 엔지니어는 전체 스택과 팀 전체의 가용성 및 업타임에 대한 기준을 신속하게 설정해야 합니다. 서비스 경계를 결정하고 서비스 안정성을 투명하게 파악할 수 있는 SLO와 SLI가 있어야, 고객과의 약속인 SLA를 보다 효과적으로 준수할 수 있습니다. 환경 전반을 개선하려면 안정성, SLO 준수 메트릭 및 오류 예산을 보고할 수 있어야 합니다.

SLI, SLO 및 SLA에 대한 모범 사례와 서비스 수준 관리를 위한 플랫폼은 다음과 같은 혜택을 제공합니다.

  • 간편한 설정: 간단하면서 안내가 포함된 흐름으로 원클릭 설정을 할 수 있으며 권장 사항과 사용자 정의를 통해 모든 서비스의 성능 및 안정성 기준을 자동으로 구축할 수 있습니다.
  • 팀 간의 안정성 정의: SLO 및 SLI 권장 사항이 서비스 경계를 결정하는 데 도움을 주기 때문에 복잡한 조정 과정이 필요하지 않습니다. 모든 엔터티의 최신 성능 메트릭을 기반으로 안정성 벤치마크를 자동으로 설정할 수 있습니다.
  • 반복 및 개선: Terraform처럼 코드로 제공되는 오픈소스 인프라 툴을 사용한 자동화와 전체 스택의 컨텍스트를 통해, 특정 노드나 서비스가 시스템 안정성에 미치는 영향을 파악하고 성능을 신속하게 제어할 수 있습니다. 서비스 소유자와 비즈니스 리더 모두를 위한 맞춤형 뷰를 통해, 운영 효율성을 높이고 보고, 알람 및 인시던트 관리 프로세스를 향상할 수 있습니다.
  • 안정성 표준화: 조직 간 팀은 서비스 안정성에 대해 통합되고 투명한 관점을 갖게 되고, 고객 중심 SLA를 보다 잘 준수하여 SLA 위반을 방지할 수 있습니다. SLO 준수 메트릭과 오류 예산은 안정성을 보고하고 애플리케이션, 인프라 및 팀 전반에 걸쳐 일관된 방식으로 변경 사항을 구현할 수 있도록 해줍니다.

자세한 팁은 뉴렐릭의 블로그 복잡한 현대 시스템을 위한 SLO 및 SLI 설정 모범 사례와 서비스 수준 관리 소개를 참조하십시오.