서비스 수준 목표 개발을 위한 프레임워크: 효과적인 신뢰성 목표를 설정하기 위한 필수 지침과 모범 사례

튜토리얼

편집자 주: 다음은 DZone의 2024 트렌드 보고서를 위해 작성 및 게시된 기사입니다.가시성과 성능: 고성능 소프트웨어 시스템 구축의 선순위.

“품질은 행동이 아니라 습관이다,”라고 아리스토텔레스가 말했습니다. 이는 소프트웨어 세계에서도 사실임을 의미합니다. 특히 개발자들에게는 사용자 만족을 제공하는 것이 일회성 노력이 아니라 지속적인 약속이라는 뜻입니다. 이 약속을 이행하기 위해 엔지니어링 팀은 사용자가 기대할 수 있는 기본 성능을 명확히 정의하는 신뢰성 목표가 필요합니다. 여기서 서비스 수준 목표(SLO)가 정확히 필요합니다.

간단히 말해, SLO는 제품이 사용자를 만족시키기 위해 달성해야 하는 신뢰성 목표입니다. 이들은 추상적인 품질 목표와 데브옵스 팀이 일상적으로 내려야 하는 운영적 결정 사이의 측정 가능한 다리 역할을 합니다. 이러한 중요성 때문에 서비스를 위해 효과적으로 정의하는 것이 매우 중요합니다. 본 기사에서는 예제를 통해 SLO를 정의하는 단계별 접근 방법을 살펴보고, SLO에 대한 일부 도전 과제를 소개할 것입니다.

서비스 수준 목표(SLO) 정의 단계

다른 모든 과정과 마찬가지로, SLO를 정의하는 것은 처음에는 압도적으로 보일 수 있지만, 몇 가지 간단한 단계를 따르면 효과적인 목표를 설정할 수 있습니다. SLO는 설정하고 잊는 지표가 아닌 것으로 기억하는 것이 중요합니다. 대신, SLO는 시스템에 대한 통찰을 얻을 때마다 진화하는 반복적인 과정의 일부입니다. 따라서 초기 SLO가 완벽하지 않더라도 괜찮습니다. 시간이 지남에 따라 보완되어야 하며 그렇게 될 수 있습니다.

그림 1. SLO를 정의하는 단계

단계 1: 중요한 사용자 여정 선택

중요한 사용자 여정은 사용자가 시스템이나 서비스 내에서 특정 목표를 달성하기 위해 취하는 상호 작용의 일련의 순서를 의미합니다. 이러한 여정의 신뢰성을 보장하는 것은 고객 경험에 직접적인 영향을 미치기 때문에 중요합니다. 중요한 사용자 여정을 식별하는 몇 가지 방법은 특정 워크플로가 실패할 때 수익/비즈니스 영향을 평가하고 사용자 분석을 통해 빈번한 흐름을 식별하는 것입니다.

예를 들어, 가상 머신(VM)을 생성하는 서비스를 고려해보겠습니다. 이 서비스에서 사용자가 수행할 수 있는 일부 작업은 사용 가능한 VM 형태를 찾아보기, VM을 생성할 지역 선택하기, VM 시작하기 등입니다. 개발팀이 비즈니스 영향에 따라 순서를 정렬한다면 다음과 같을 것입니다:

  1. VM 시작하기 이것은 직접적인 매출 영향이 있습니다. 사용자가 VM을 시작할 수 없는 경우 서비스의 핵심 기능이 실패하게 되어 고객 만족도와 매출에 직접적으로 영향을 미칩니다.
  2. 리전 선택해서 VM을 만드세요. 사용자는 다른 리전에서도 VM을 만들 수 있지만, 리전 선호도가 있다면 사용자 경험이 저하될 수 있습니다. 이 선택은 성능과 규정 준수에 영향을 줄 수 있습니다.
  3. VM 카탈로그를 찾아보세요. 이것은 결정을 내리는 데 중요하지만, 사용자는 나중에 VM 모양을 변경할 수 있기 때문에 비즁니스에 직접적인 영향을 미칩니다.

단계 2: 사용자 여정을 추적할 수 있는 서비스 수준 지표 결정

이제 사용자 여정이 정의되었으므로, 다음 단계는 효과적으로 이를 측정하는 것입니다. 서비스 수준 지표(SLIs)는 개발자가 시스템 성능과 신뢰성을 측정하는 데 사용하는 메트릭스입니다. 엔지니어링 팀에게 SLIs는 두 가지 목적을 제공합니다: 시스템 저하를 감지할 수 있는 실행 가능한 데이터를 제공하고, 아키텍처 결정을 안내하며, 인프라 변경을 검증합니다. 또한, 신뢰성 대상을 설정하고 추적하기 위해 필요한 양적 측정치를 제공하여 의미 있는 SLO의 기반이 됩니다.

예를 들어, VM을 시작할 때 일부 SLIs는 가용성과 지연 시간일 수 있습니다.

가용성: VM을 시작하는 데 X개의 요청 중 몇 개가 성공했습니까? 이를 계산하는 간단한 공식은 다음과 같습니다:

만약 1,000개의 요청이 있고, 그 중 998개의 요청이 성공했다면, 가용성은 = 99.8%입니다.

지연 시간: VM을 시작하는 데 총 요청 중 50번째, 95번째 또는 99번째 백분위의 요청이 VM을 시작하는 데 얼마나 걸렸습니까? 여기서의 백분위는 예시이며, 구체적인 사용 사례나 서비스 수준 기대에 따라 다를 수 있습니다.

  • 1,000개의 요청이 있는 시나리오에서 900개의 요청이 5초 안에 완료되고 나머지 100개는 10초가 걸렸다면, 95번째 백분위 지연 시간은 10초가 됩니다.
  • 평균도 지연 시간을 계산하는 데 사용할 수 있지만, 백분위수는 일반적으로 권장됩니다. 이는 꼬리 지연 시간을 고려하여 사용자 경험을 보다 정확하게 나타내기 때문입니다.

3단계: SLO의 목표 숫자 식별하기

간단히 말해, SLO는 특정 시간 창에서 SLIs가 달성해야 하는 목표 숫자입니다. VM 시나리오의 경우, SLO는 다음과 같을 수 있습니다:

  • 서비스의 가용성은 30일 롤링 윈도우에서 99% 이상이어야 합니다.
  • VM을 시작할 때 95번째 백분위 지연 시간은 8초를 초과해서는 안 됩니다.

이 목표를 설정할 때 유의해야 할 사항은:

  • 이전 데이터 사용하기. 30일 롤링 기간을 기준으로 SLO를 설정해야 하는 경우, 여러 30일 윈도우의 데이터를 수집하여 목표를 정의하십시오. 

    • 이러한 이전 데이터가 부족하다면, 매일 99%의 가용성을 목표로 하는 것과 같이 더 관리 가능한 목표로 시작하고, 정보를 더 많이 수집함에 따라 점차 조정하십시오. 
    • 기억하세요, SLO는 고정된 것이 아니며, 서비스와 고객의 변화하는 요구를 반영하기 위해 지속적으로 발전해야 합니다.

  • 종속 SLO 고려하기. 서비스는 일반적으로 데이터베이스 및 로드 밸런서와 같은 다른 서비스 및 인프라 구성 요소에 의존합니다.

    • 예를 들어, 귀하의 서비스가 99.9% 가용성 SLO를 가진 SQL 데이터베이스에 의존하는 경우, 귀하의 서비스 SLO는 99.9%를 초과할 수 없습니다. 이는 최대 가용성이 그 기반 종속 요소의 성능에 의해 제한되기 때문에 더 높은 신뢰성을 보장할 수 없습니다.

SLO의 도전 과제

SLO를 100%로 설정하는 것은 흥미로울 수 있지만, 이는 불가능합니다. 예를 들어, 100% 가용성은 기능을 배포하거나 패치하거나 테스트하는 것과 같은 중요한 활동을 위한 여지가 없다는 것을 의미하며, 이는 비현실적입니다. SLO를 정의하는 것은 다양한 팀 간의 협업이 필요합니다, 여기에는 엔지니어링, 제품, 운영, QA 및 리더십이 포함됩니다. 모든 이해관계자가 조정되고 목표에 대해 동의하는 것이 SLO가 성공적이고 실행 가능하도록 하는 데 필수적입니다.

4단계: 오류 예산 고려하기

오류 예산은 시스템이 고객을 불만족시키거나 계약 의무를 위반하지 않고도 감당할 수 있는 다운타임의 측정입니다. 다음은 이를 바라보는 한 가지 방법입니다:

  • 만약 오류 예산이 거의 소진되었다면, 엔지니어링 팀은 새로운 기능을 출시하기보다는 신뢰성을 개선하고 사건을 줄이는 데 집중해야 합니다.
  • 만약 오류 예산이 충분히 남아 있다면, 엔지니어링 팀은 시스템이 신뢰성 목표 내에서 잘 작동하고 있으므로 새로운 기능을 배포하는 것을 우선시할 수 있습니다.

오류 예산을 측정하는 두 가지 일반적인 접근 방식이 있습니다: 시간 기반과 이벤트 기반입니다. “서비스의 가용성은 30일 롤링 윈도우에서 99%를 초과해야 한다”는 진술이 각각에 어떻게 적용되는지 살펴보겠습니다.

시간 기반 측정

시간 기반 오류 예산에서는 위의 진술이 서비스가 한 달에 43분 50초 동안 중단될 수 있음을 의미합니다. 또는 연간 7시간 14분 동안 중단될 수 있습니다. 계산하는 방법은 다음과 같습니다:

  1. 데이터 포인트 수를 결정합니다. SLO 시간 창 내에서 시간 단위(데이터 포인트) 수를 결정하여 시작합니다. 예를 들어, 기본 시간 단위가 1분이고 SLO 창이 30일인 경우:

  1. 에러 버젯을 계산합니다. 다음으로 “실패”할 수 있는 데이터 포인트 수(다운타임)를 계산합니다. 에러 버젋은 허용 가능한 실패의 비율입니다.

시간으로 변환하면:

이는 30일 동안 7시간 14분의 다운타임을 경험할 수 있다는 것을 의미합니다.

마지막으로, 남은 에러 버젯은 총 가능한 다운타임과 이미 사용된 다운타임의 차이입니다.

이벤트 기반 측정

이벤트 기반 측정에서 에러 버젯은 백분율로 측정됩니다. 앞서 언급한 문장은 30일 롤링 창에서 1%의 에러 버젯으로 해석됩니다.

30일 창에 43,200개의 데이터 포인트가 있고, 100개가 나쁘다고 가정해 봅시다. 이 공식을 사용하여 이미 사용된 에러 버젯을 계산할 수 있습니다:

이제 남은 에러 버젯을 찾으려면, 이 값을 총 허용된 에러 버젯(1%)에서 빼면 됩니다:

따라서, 서비스는 여전히 0.77%의 불량 데이터 포인트를 더 견딜 수 있습니다.

오류 예산의 장점

오류 예산은 개발 팀에 예산이 고갈될 위험이 있을 때 자동 모니터 및 알림을 설정하는 데 활용될 수 있습니다. 이러한 알림은 팀이 프로덕션에 변경 사항을 배포할 때 더 많은 주의가 필요할 때를 인식하도록 돕습니다. 팀은 기능과 운영의 우선 순위를 정할 때 종종 모호함에 직면합니다. 오류 예산은 이러한 문제를 해결하는 한 가지 방법이 될 수 있습니다. 명확하고 데이터 기반의 지표를 제공함으로써, 엔지니어링 팀은 필요할 때 새로운 기능보다 신뢰성 작업을 우선시할 수 있습니다. 오류 예산은 엔지니어링 팀 내에서 책임성과 성숙도를 향상시키기 위한 잘 확립된 전략 중 하나입니다.

오류 예산을 사용할 때 주의할 점

추가 예산이 있을 때, 개발자는 이를 적극적으로 활용해야 합니다. 이는 카오스 엔지니어링과 같은 기술을 실험하여 서비스를 더 깊이 이해할 수 있는 좋은 기회입니다. 엔지니어링 팀은 서비스가 어떻게 반응하는지 관찰하고 정상 운영 중에는 명확하지 않을 수 있는 숨겨진 종속성을 발견할 수 있습니다. 마지막으로, 개발자는 예기치 않은 사건이 예산을 빠르게 소진시킬 수 있기 때문에 오류 예산 고갈을 면밀히 모니터링해야 합니다.

결론

서비스 수준 목표는 신뢰성 엔지니어링에서 목적지가 아니라 여정을 나타냅니다. 이들은 서비스 신뢰성을 측정하는 중요한 지표를 제공하지만, 그 진정한 가치는 조직 내 신뢰성 문화를 만드는 데 있습니다. 팀은 완벽을 추구하기보다는 SLO를 그들의 서비스와 함께 발전하는 도구로 받아들여야 합니다. 앞으로 AI와 머신러닝의 통합은 SLO를 반응적인 측정에서 예측 가능한 도구로 변모시킬 것으로 기대되며, 이를 통해 조직은 사용자에게 영향을 미치기 전에 실패를 예상하고 방지할 수 있게 됩니다.

추가 자료:

이것은 DZone의 2024 트렌드 보고서 가시성과 성능: 고성능 소프트웨어 시스템 구축의 벼랑에서 발췌한 내용입니다.

무료 보고서 읽기

Source:
https://dzone.com/articles/framework-for-service-level-objectives