이 페이지는 Cloud Translation API를 통해 번역되었습니다.

SLO 및 알림

Last reviewed 2023-11-08 UTC

Google Cloud 아키텍처 프레임워크: 신뢰성 섹션의 이 문서에서는 SLO 관련 알림에 대해 자세히 설명합니다.

SLO 등의 새로운 관측 시스템을 도입할 때 이 시스템으로 이전 시스템을 완전히 교체하는 것은 잘못된 접근 방법입니다. 오히려 SLO를 보완적인 시스템으로 여겨야 합니다. 예를 들어 기존 알림을 삭제하는 대신 여기에 설명된 SLO 알림과 함께 알림을 실행하는 것이 좋습니다. 이 접근 방식을 사용하면 SLO 알림을 예측할 수 있는 기존 알림, SLO 알림과 함께 실행되는 알림, 실행되지 않는 알림을 확인할 수 있습니다.

SRE의 원칙은 원인이 아닌 증상을 기반으로 알리는 것입니다. 본질적으로 SLO는 증상을 측정한 것입니다. SLO 알림을 채택하면 증상 알림이 다른 알림과 함께 실행되는 것을 확인할 수 있습니다. 기존 오류 기반 알림이 SLO 또는 증상 없이 실행되는 경우 이러한 알림을 완전히 끄거나, 티켓팅 알림으로 바꾸거나, 나중에 참조용으로 로깅하는 것이 좋습니다.

자세한 내용은 SRE 워크북 5장을 참조하세요.

SLO 소진율

SLO의 소진율은 서비스 중단으로 얼마나 빨리 사용자가 오류에 노출되고 오류 예산을 소진하는지에 대한 측정값입니다. 소진율을 측정하면 서비스가 SLO를 위반할 때까지의 시간을 결정할 수 있습니다. SLO 소진율에 기반한 알림은 유용한 접근 방법입니다. SLO는 기간을 기준으로 하며 이 기간은 몇 주나 몇 개월까지 길어질 수도 있습니다. 하지만 실제로 위반이 발생하기 전에 SLO 위반으로 이어질 조건을 빠르게 감지하는 것이 목표입니다.

다음 표에서는 초당 쿼리 수(QPS)가 일정하다는 가정하에 지정된 기간 동안 요청이 100% 실패하는 경우 목표를 초과하는 데 걸리는 시간을 보여줍니다. 예를 들어 30일 동안 99.9%의 SLO를 측정한 경우 30일 동안 43.2분의 전체 다운타임을 견딜 수 있습니다. 예를 들어 다운타임은 모두 한 번에 발생하거나 여러 이슈에 걸쳐 간격을 두고 발생할 수 있습니다.

목표	90일	30일	7일	1일
90%	9일	3일	16.8시간	2.4시간
99%	21.6시간	7.2시간	1.7시간	14.4분
99.9%	2.2시간	43.2분	10.1분	1.4분
99.99%	13분	4.3분	1분	8.6초
99.999%	1.3분	25.9초	6초	0.9초

실제로는 높은 성공율을 달성하고 싶다면 100% 중단 이슈를 감당할 수 없습니다. 그러나 많은 분산 시스템은 부분적으로 실패하거나 단계적으로 저하시킬 수 있습니다. 그런 경우에도 이러한 실패에 사람이 개입해야 하는지 여전히 알고 싶을 수 있으며 SLO 알림은 이를 판단할 방법을 제공합니다.

알림 시기

중요한 질문은 SLO 소진율을 기반으로 언제 조치를 취할 것인지입니다. 일반적으로 24시간 이내에 오류 예산이 소진된다면 즉시 이 문제를 해결하기 위해 다른 사람을 호출해야 합니다.

실패율을 판단하는 것이 항상 간단한 것은 아닙니다. 잠시 동안은 일련의 작은 오류가 두려울 수 있으나 사실은 단기적이고 SLO에 미치는 영향도 미미할 수 있습니다. 마찬가지로 시스템이 오랫동안 미세하게 손상되었다면 이런 오류가 SLO 위반으로 이어질 수도 있습니다.

일반적으로 팀은 이러한 신호에 반응하여 주어진 기간 동안 오류 예산을 거의 대부분 소비합니다(그러나 초과하지는 않음). 너무 많은 금액을 소비하면 SLO를 위반하게 됩니다. 너무 적은 금액을 소비하면 위험을 충분히 감수하지 않거나 긴급 대응팀을 혹사시키고 있는지도 모릅니다.

언제 인간이 개입해야 할 정도로 시스템이 망가졌는지 판단할 방법이 필요합니다. 다음 섹션에서는 이 질문에 대한 몇 가지 접근 방식을 설명합니다.

빠른 소진

SLO 소진의 한 가지 유형은 빠른 SLO 소진입니다. 이는 오류 예산을 빠르게 소진하고 SLO 위반을 방지하기 위해 사용자의 개입을 요구하기 때문입니다.

서비스가 일반적으로 초당 쿼리 수(QPS) 1,000개로 작동하며 7일 동안 측정했을 때 99% 가용성을 유지하기를 바란다고 가정해 봅시다. 오류 예산은 약 6억 개 요청 중에서 약 600만 개의 허용 가능 오류입니다. 예를 들어 오류 예산 소진까지 24시간이 있다면 초당 약 70개의 오류 또는 시간당 252,000개의 오류 한계가 있는 셈입니다. 이러한 매개변수는 호출 가능 이슈가 분기별 오류 예산의 최소 1% 이상을 소비해야 한다는 일반 규칙을 기반으로 합니다.

1시간이 지나기 전에 이 오류율을 감지하도록 선택할 수 있습니다. 예를 들어 초당 오류 70개의 속도를 15분 동안 관찰한 후에 다음 다이어그램과 같이 긴급 대기 엔지니어를 호출할지 결정할 수 있습니다.

이상적으로는 24시간 예산 중에서 1시간을 사용하기 전에 문제가 해결되는 것이 가장 좋습니다. 더 짧은 기간(예: 1분)에 이 속도를 감지하도록 선택하면 오류가 발생하기가 지나치게 쉽습니다. 감지 목표 시간이 15분보다 짧으면 이 숫자를 조정할 수 있습니다.

느린 소진

다른 유형의 소진율은 느린 소진입니다. 주별 오류 예산을 5~6일째에 또는 월 오류 예산을 2주째에 소진하는 버그가 발생했다고 가정해 봅시다. 어떤 대응이 가장 좋을까요?

이 경우 알림 기간이 끝나기 전에 전체 오류 예산을 모두 소진할 가능성이 있음을 알려주는 느린 SLO 소진 알림을 도입할 수 있습니다. 물론 이 알림은 많은 거짓 양성을 반환할 수도 있습니다. 예를 들어 오류의 발생 시간은 짧지만 오류 예산을 재빨리 소비할 정도의 속도로 발생하는 경우도 있습니다. 이러한 경우 오류가 짧은 시간만 지속되고 장기적으로 오류 예산을 위협하지 않으므로 거짓양성 조건에 해당합니다. 목표는 모든 오류 소스를 제거하는 것이 아니라 오류 예산을 초과하지 않도록 허용 가능한 범위 안에 머무르는 것임을 기억하세요. 오류 예산을 합법적으로 위협하지 않는 이벤트에 대해서는 사람의 개입을 요청하는 알림을 보내지 않는 것이 좋습니다.

페이징이나 이메일이 아닌 티켓 큐에 느린 소진 이벤트를 알리는 것이 좋습니다. 느린 소진 이벤트는 긴급 상황이 아니지만 예산이 만료되기 전에 사람의 개입이 필요합니다. 이러한 알림은 금방 무시해도 되는 알림이 되며 팀 목록으로 발송되는 이메일이 아니어야 합니다. 티켓은 추적 가능하고 할당 가능하며 전송할 수 있어야 합니다. 팀은 티켓 로드, 폐쇄율, 작업 가능성, 중복에 대한 보고서를 개발해야 합니다. 작업을 수행할 수 없는 과도한 티켓은 과중한 업무의 좋은 예시입니다.

SLO 알림을 적절하게 사용하려면 시간이 걸릴 수 있고 팀의 문화와 기대치에 따라 달라집니다. 시간이 지남에 따라 SLO 알림을 미세 조정할 수 있습니다. 또한 필요에 따라 다양한 알림 기간을 가지는 여러 알림 방법이 있을 수 있습니다.

지연 시간 알림

가용성 알림 외에 지연 시간 알림도 사용할 수 있습니다. 지연 시간 SLO를 사용하면 지연 시간 목표를 충족하지 않는 요청 비율을 측정할 수 있습니다. 이 모델을 사용하면 오류 예산의 빠른 소진 또는 느린 소진을 감지하는 데 사용하는 것과 동일한 알림 모델을 활용할 수 있습니다.

앞에서 설명한 중간 지연 시간 SLO과 같이 요청의 절반만 SLO가 될 수 있습니다. 즉, 사용자가 장기적인 오류 예산에 미치는 영향을 감지하기 전에 잘못된 지연 시간을 겪을 수 있습니다. 대신 서비스는 꼬리 지연 시간 목표와 일반적인 지연 시간 목표를 정의해야 합니다. 이전 90번째 백분위수를 사용하여 일반적인 지연 시간 목표를 정의하고 이전 99번째 백분위수를 사용하여 꼬리 지연 시간 목표를 정의하는 것이 좋습니다. 이러한 목표를 설정한 후 각 지연 시간 카테고리에서 예상되는 요청 수와 지나치게 느린 요청 수를 기반으로 SLO를 정의할 수 있습니다. 이 접근 방식은 오류 예산과 동일한 개념이며 동일하게 취급해야 합니다. 따라서 '일반적인 지연 시간 내에서 요청의 90%가 처리되고 꼬리 지연 시간 내에서 요청의 99.9%가 처리'됩니다. 이러한 목표를 통해 대부분의 사용자는 일반적인 지연 시간을 경험하고 꼬리 지연 시간 목표보다 느린 요청 수를 추적할 수 있습니다.

일부 서비스에는 변동이 심한 예상된 런타임이 있을 수 있습니다. 예를 들어 Datastore 시스템에서 데이터를 읽을 때와 쓸 때의 성능 예상이 크게 다를 수 있습니다. 가능한 모든 예상을 열거하는 대신 다음 표와 같이 런타임 성능 버킷을 사용할 수 있습니다. 이 방식은 이러한 유형의 요청이 식별 가능하다고 여기며 각 버킷으로 사전에 분류됩니다. 요청을 즉시 분류해서는 안 됩니다.

사용자에게 표시되는 웹사이트
버킷	예상 최대 런타임
읽기	1초
쓰기 / 업데이트	3초

데이터 처리 시스템
버킷	예상 최대 런타임
작게	10초
중간	1분
크게	5분
대형	1시간
초대형	8시간

현재 사용 중인 시스템을 측정하면 일반적으로 이러한 요청이 실행되는 데 걸리는 시간을 파악할 수 있습니다. 예를 들어 동영상 업로드를 처리하는 시스템을 가정해 보겠습니다. 동영상이 매우 긴 경우 처리 시간이 더 오래 걸릴 수 있습니다. 다음 표와 같이 동영상 길이(초)를 사용하여 이 작업을 버킷으로 분류할 수 있습니다. 표에는 버킷당 요청 수와 한 주 동안의 런타임 분포에 대한 다양한 백분위가 기록됩니다.

동영상 길이	1주 동안 측정된 요청 수	10%	90%	99.95%
작게	0	-	-	-
중간	190만	864밀리초	17초	86초
크게	2,500만	1.8초	52초	9.6분
대형	430만	2초	43초	23.8분
초대형	81,000	36초	1.2분	41분

이러한 분석에서 다음과 같은 몇 가지 매개변수를 추출할 수 있습니다.

fast_typical: 최대 10%의 요청이 이 시간보다 빠릅니다. 너무 많은 요청이 이 시간보다 빠르면 목표가 잘못되었거나 시스템에서 무언가가 변경되었을 수 있습니다.
slow_normal: 최소 90%의 요청이 이 시간보다 빠릅니다. 이 한도는 기본 지연 시간 SLO를 유도합니다. 이 매개변수는 대부분의 요청이 충분히 빠른지 여부를 나타냅니다.
slow_tail: 최소 99.95%의 요청이 이 시간보다 빠릅니다. 이 제한은 느린 요청이 너무 많지 않게 합니다.
deadline: 사용자 RPC 또는 백그라운드 처리가 시간 초과되어 실패하는 지점입니다(일반적으로 이미 시스템에 하드 코딩된 제한). 이 요청들은 실제로 느리지는 않지만 오류와 함께 실제로 실패하게 되며 대신 가용성 SLO으로 포함됩니다.

버킷을 정의할 때 가이드라인은 버킷의 fast_typical, slow_typical, slow_tail이 서로의 자릿수 내에 유지되도록 하는 것입니다. 이 가이드는 버킷을 너무 광범위하게 잡지 않습니다. 버킷 간에는 겹침이나 공백이 없도록 하는 것이 좋습니다.

버킷	fast_typical	slow_typical	slow_tail	deadline
작게	100밀리초	1초	10초	30초
중간	600밀리초	6초	60초(1분)	300초
크게	3초	30초	300초(5분)	10분
대형	30초	6분	60분(1시간)	3시간
초대형	5분	50분	500분(8시간)	12시간

이렇게 하면 api.method: SMALL => [1s, 10s]와 같은 규칙이 적용됩니다. 이 경우 SLO 추적 시스템은 요청을 확인하고, 버킷을 결정하고(메서드 이름 또는 URI를 분석하고 조회 테이블과 이름을 비교하는 방식) 해당 요청의 런타임을 기반으로 통계를 업데이트합니다. 여기서 700밀리초가 소요되었으면 slow_typical 목표 내에 포함됩니다. 3초이면 slow_tail 이내입니다. 22초라면 slow_tail을 넘어서지만 오류는 아닙니다.

사용자 만족이라는 측면에서는 사라진 꼬리 지연 시간은 서비스를 사용할 수 없다는 의미로 생각해도 무방합니다. 즉, 응답이 너무 느려서 실패로 간주됩니다. 따라서 다음과 같이 가용성에 사용하는 것과 동일한 비율을 사용하는 것이 좋습니다.

전체 요청의 99.95%가 10초 이내에 충족됩니다.

일반 지연 시간은 개발자가 결정합니다. Google 내 일부 팀은 90%를 적합한 목표로 간주합니다. 이는 분석 및 slow_typical 기간을 선택한 방법과 관련이 있습니다. 예를 들면 다음과 같습니다.

전체 요청의 90%가 1초 이내에 처리됩니다.