가용성 측정
앞서 살펴본 것처럼 분산 시스템을 위한 미래 지향적인 가용성 모델을 만드는 것은 어려운 일이며 원하는 통찰력을 제공하지 못할 수도 있습니다. 워크로드의 가용성을 측정하는 일관된 방법을 개발하는 것이 유용성을 더할 수 있습니다.
가용성을 가동 시간과 가동 중지로 정의하면 워크로드가 증가하든 그렇지 않든 고장을 이분법적으로 나타냅니다.
하지만 이런 경우는 거의 없습니다. 고장은 상당한 영향을 미치며 워크로드의 일부 하위 집합에서 발생하는 경우가 많으며, 이는 사용자 또는 요청의 비율, 위치의 백분율 또는 지연 시간의 백분위수에 영향을 미칩니다. 이는 모두 부분적 고장 모드입니다.
MTTR과 MTBF는 결과적으로 시스템의 가용성을 좌우하는 요소와 이를 개선하는 방법을 이해하는 데 유용하지만 가용성을 실증적으로 측정할 수 있는 척도로는 유용하지 않습니다. 또한 워크로드는 여러 구성 요소로 구성되어 있습니다. 예를 들어 결제 처리 시스템과 같은 워크로드는 여러 애플리케이션 프로그래밍 인터페이스(API)와 하위 시스템으로 구성됩니다. 따라서 “전체 워크로드의 가용성은 어떻게 됩니까?”와 같은 질문은 사실 복잡하고 미묘한 질문입니다.
이 항목에서는 가용성을 경험적으로 측정할 수 있는 세 가지 방법, 즉 서버 측 요청 성공률, 클라이언트 측 요청 성공률, 연간 가동 중지를 살펴보겠습니다.
서버 측 및 클라이언트 측 요청 성공률
처음 두 가지 방법은 매우 유사하지만 측정이 취해지는 관점에서만 다릅니다. 서버 측 지표는 서비스의 계측에서 수집할 수 있습니다. 하지만 아직 완전하지는 않습니다. 클라이언트가 서비스에 도달할 수 없는 경우 해당 지표를 수집할 수 없습니다. 클라이언트 경험을 이해하려면 실패한 요청에 대한 클라이언트의 원격 분석에 의존하는 대신 정기적으로 서비스를 조사하고 지표를 기록하는 소프트웨어인 canary를 사용하여 고객 트래픽을 시뮬레이션하는 것이 클라이언트 측 지표를 수집하는 더 쉬운 방법입니다.
이 두 방법은 서비스가 수신한 총 유효 작업 단위와 성공적으로 처리한 작업 단위의 비율로 가용성을 계산합니다. 이렇게 하면 404 오류가 발생하는 HTTP 요청과 같은 잘못된 작업 단위는 무시됩니다.
방정식 8
요청 기반 서비스의 경우 작업 단위는 HTTP 요청과 마찬가지로 요청입니다. 이벤트 기반 또는 작업 기반 서비스의 경우 작업 단위는 대기열에서 메시지를 처리하는 것과 같은 이벤트 또는 작업입니다. 이 가용성 측정은 1분 또는 5분과 같은 짧은 시간 간격에서 의미가 있습니다. 또한 요청 기반 서비스의 API 수준과 같이 세분화된 관점에서도 가장 적합합니다. 다음 그림은 이러한 방식으로 계산했을 때 시간 경과에 따른 가용성을 보여줍니다. 그래프의 각 데이터 포인트는 방정식 (8)을 사용하여 5분 동안 계산됩니다(1분 또는 10분 간격과 같은 다른 시간 차원을 선택할 수 있음). 예를 들어, 데이터 포인트 10은 94.5%의 가용성을 보여줍니다. 즉, 서비스가 1,000개의 요청을 받은 경우 t+45에서 t+50분 동안 이 중 945개만 성공적으로 처리된 것입니다.
단일 API의 시간 경과에 따른 가용성 측정 예제
그래프에는 API의 가용성 목표, 99.5% 가용성, 고객에게 제공하는 서비스 수준에 관한 계약(SLA), 99% 가용성, 심각도가 높은 경보의 임계값인 95%도 표시됩니다. 이러한 다양한 임계값을 고려하지 않으면 가용성 그래프로는 서비스 운영 방식에 대한 중요한 통찰력을 제공하지 못할 수 있습니다.
목표는 컨트롤 플레인 같은 대규모 하위 시스템이나 전체 서비스의 가용성을 추적하고 설명하는 것입니다. 이를 위한 한 가지 방법은 각 하위 시스템에 대해 각 5분 데이터 포인트의 평균을 구하는 것입니다. 그래프는 이전 그래프와 비슷해 보이지만 더 큰 입력 집합을 나타냅니다. 또한 서비스를 구성하는 모든 하위 시스템에 동일한 가중치를 부여합니다. 또 다른 방법은 서비스의 모든 API에서 수신되고 성공적으로 처리된 모든 요청을 합산하여 5분 간격으로 가용성을 계산하는 것입니다.
하지만 이 후자의 방법을 사용하면 처리량이 낮고 가용성이 좋지 않은 개별 API를 숨길 수 있습니다. 간단한 예로 두 개의 API가 있는 서비스를 생각해 봅시다.
첫 번째 API는 5분 내에 1,000,000개의 요청을 수신하고 그 중 999,000개를 성공적으로 처리하여 99.9%의 가용성을 제공합니다. 두 번째 API는 동일한 5분 내에 100개의 요청을 수신하고 그 중 50개만 성공적으로 처리하여 50%의 가용성을 제공합니다.
각 API의 요청을 합산하면 총 1,000,100개의 유효한 요청이 있고 그 중 999,050개가 성공적으로 처리되어 전체 서비스에 대해 99.895%의 가용성이 제공됩니다. 그러나 전자의 방법인 두 API의 가용성을 평균하면 74.95%의 가용성이 나오는데, 이는 실제 경험을 더 잘 설명해 줄 수 있습니다.
두 접근 방식 모두 잘못된 것은 아니지만 가용성 지표가 무엇을 알려주는지 이해하는 것이 중요하다는 것을 알 수 있습니다. 워크로드가 각 하위 시스템에서 비슷한 요청을 받는 경우 모든 하위 시스템에 대해 요청을 합산하는 것을 선호할 수 있습니다. 이 접근 방식은 가용성과 고객 경험의 척도로서 “요청”과 성공에 초점을 맞춥니다. 또는 요청량 차이에도 불구하고 하위 시스템의 중요도를 동일하게 나타내기 위해 평균 하위 시스템 가용성을 선택할 수도 있습니다. 이 접근 방식은 하위 시스템과 고객 경험을 위한 프록시 역할을 하는 각 하위 시스템의 기능에 초점을 맞춥니다.
연간 가동 중지
세 번째 접근 방식은 연간 가동 중지를 계산하는 것입니다. 이러한 형태의 가용성 지표는 장기 목표 설정 및 검토에 더 적합합니다. 가동 중지가 워크로드에 미치는 영향을 정의해야 합니다. 그런 다음 해당 워크로드가 “중단” 상태가 아닌 시간(분)을 해당 기간의 총 시간(분)과 비교하여 가용성을 측정할 수 있습니다.
일부 워크로드는 1분 또는 5분 간격으로 단일 API 또는 워크로드 함수의 가용성이 95% 미만으로 떨어지는 것과 같이 가동 중지를 정의할 수 있습니다(이전 가용성 그래프에서 발생). 또한 가동 중지는 중요한 데이터 영역 작업의 일부에 적용되므로 가동 중지만 고려할 수도 있습니다. 예를 들어, SQS 가용성에 대한 Amazon 메시징(SQS, SNS) 서비스 수준에 관한 계약
더 크고 복잡한 워크로드에는 시스템 전반의 가용성 지표를 정의해야 할 수 있습니다. 대규모 전자 상거래 사이트의 경우 시스템 전반의 지표는 고객 주문률과 같을 수 있습니다. 여기서 5분 동안 예상 수량에 비해 주문이 10% 이상 감소하면 가동 중지가 발생할 수 있습니다.
어느 방법을 사용하든 운영 중단 기간을 모두 합산하여 연간 가용성을 계산할 수 있습니다. 예를 들어, 한 해 동안 모든 데이터 영역 API의 가용성이 95% 미만으로 떨어지는 것으로 정의되는 5분 가동 중지가 27번 발생한 경우 전체 가동 중지는 135분(일부 5분 기간은 연속적이었을 수도 있고 다른 기간은 분리되었을 수도 있음)이었으며, 이는 연간 가용성이 99.97%에 달합니다.
가용성을 측정하는 이 추가 방법을 사용하면 클라이언트 측 및 서버 측 지표에서 누락된 데이터와 통찰력을 얻을 수 있습니다. 예를 들어, 워크로드가 손상되어 오류율이 크게 높아진 경우를 생각해 보세요. 이 워크로드의 고객은 해당 서비스에 대한 호출을 완전히 중단할 수 있습니다. 회로 차단기를 활성화했거나 재해 복구 계획
지연 시간
마지막으로, 워크로드 내에서 작업 단위 처리의 지연 시간을 측정하는 것도 중요합니다. 가용성 정의의 일부는 설정된 SLA 내에서 작업을 수행하는 것입니다. 응답을 반환하는 데 클라이언트 제한 시간보다 오래 걸리는 경우 클라이언트는 요청이 실패하고 워크로드를 사용할 수 없다고 인식합니다. 하지만 서버 측에서는 요청이 성공적으로 처리된 것처럼 보일 수 있습니다.
지연 시간 측정은 가용성을 평가할 수 있는 또 다른 관점을 제공합니다. 이 측정에는 백분위수와 절삭 평균을 사용하는 것이 좋습니다. 일반적으로 50번째 백분위수(P50 및 TM50)와 99번째 백분위수(P99 및 TM99)로 측정됩니다. 클라이언트 경험을 나타내는 canary와 서버 측 지표를 사용하여 지연 시간을 측정해야 합니다. P99 또는 TM99.9와 같은 일부 백분위수 지연 시간의 평균이 목표 SLA를 초과할 때마다 해당 가동 중지 시간을 고려할 수 있으며, 이는 연간 가동 중지 시간 계산에 반영됩니다.
