SRE(Site Reliability Engineering)는 웹 프로젝트의 가용성을 보장하는 접근 방식입니다. DevOps를 위한 프레임워크로 간주되며 DevOps 방식을 성공적으로 적용하는 방법에 대해 설명합니다. 이 기사의 번역 6장 분산 시스템 모니터링 книги 사이트 신뢰성 공학 Google에서. 나는 이 번역을 직접 준비했으며 모니터링 프로세스를 이해하는 데 있어 내 경험을 바탕으로 했습니다. 텔레그램 채널에서 @monitorim_it и Medium의 블로그 또한 서비스 수준 목표에 관한 같은 책의 4장 번역에 대한 링크도 게시했습니다.

고양이 번역. 즐겁게 읽으세요!

Google의 SRE팀에는 성공적인 모니터링 및 알림 시스템을 만들기 위한 기본 원칙과 권장사항이 있습니다. 이 장에서는 웹 페이지 방문자에게 발생할 수 있는 문제와 웹 페이지 표시를 어렵게 만드는 문제를 해결하는 방법에 대한 지침을 제공합니다.

정의

모니터링과 관련된 주제를 논의하는 데 사용되는 단일 어휘는 없습니다. 구글에서도 아래의 용어는 일반적으로 사용되지 않지만, 가장 일반적으로 해석되는 내용을 나열해 보겠습니다.

모니터링

시스템에 대한 실시간 정량적 데이터 수집, 처리, 집계 및 표시: 요청 수 및 요청 유형, 오류 수 및 오류 유형, 요청 처리 시간 및 서버 가동 시간.

화이트박스 모니터링

로그, Java Virtual Machine 프로파일링 지표 또는 내부 통계를 생성하는 HTTP 처리기 지표를 포함하여 내부 시스템 구성 요소에 표시되는 지표를 기반으로 모니터링합니다.

블랙박스 모니터링

사용자 관점에서 애플리케이션 동작을 테스트합니다.

계기반

서비스의 주요 상태 지표에 대한 개요를 제공하는 인터페이스(일반적으로 웹)입니다. 대시보드에는 필터, 표시되는 지표를 선택하는 기능 등이 있을 수 있습니다. 인터페이스는 사용자에게 가장 중요한 지표를 식별하도록 설계되었습니다. 대시보드에는 요청 대기열, 우선순위가 높은 오류 목록, 특정 책임 영역에 할당된 엔지니어 등 기술 지원 직원을 위한 정보도 표시될 수 있습니다.

경고(알림)

이메일이나 기타 수단을 통해 개인이 수신하도록 의도된 알림으로, 오류나 요청 대기열의 증가로 인해 트리거될 수 있습니다. 알림은 티켓, 이메일 알림, 인스턴트 메신저 메시지로 분류됩니다.

근본 원인

한 번 수정되면 다시 발생해서는 안 되는 소프트웨어 결함이나 사람의 실수입니다. 문제에는 불충분한 프로세스 자동화, 소프트웨어 결함, 불충분한 애플리케이션 로직 정교화 등 여러 가지 주요 원인이 있을 수 있습니다. 이러한 각 요인은 근본 원인일 수 있으므로 각각 제거해야 합니다.

노드와 머신(노드와 머신)

물리적 서버, 가상 머신 또는 컨테이너에서 실행 중인 애플리케이션의 단일 인스턴스를 나타내는 상호 교환 가능한 용어입니다. 하나의 시스템이 여러 서비스를 호스팅할 수 있습니다. 서비스는 다음과 같습니다.

• 예를 들어 캐싱 서버와 웹 서버가 서로 연결되어 있습니다.
• 단일 하드웨어의 관련 없는 서비스(예: 코드 저장소 및 구성 시스템용 마법사) 인형 또는 요리사.

푸시

소프트웨어 구성이 변경되었습니다.

모니터링이 필요한 이유는 무엇입니까?

애플리케이션을 모니터링해야 하는 몇 가지 이유는 다음과 같습니다.

장기 추세 분석

데이터베이스의 크기는 얼마나 되고, 얼마나 빠르게 성장하고 있나요? 일일 이용자 수는 어떻게 변하나요?

성능 비교

Ajax DB 2.72에 비해 Acme Bucket of Bytes 3.14의 요청이 더 빠르나요? 추가 노드가 나타난 후 요청이 얼마나 더 잘 캐시됩니까? 지난 주에 비해 사이트 운영 속도가 느려졌나요?

경고(알림)

뭔가 고장났고 누군가 그것을 고쳐야 합니다. 아니면 뭔가가 곧 고장나서 누군가가 빨리 확인해야 할 수도 있습니다.

대시보드 만들기

대시보드는 기본적인 질문에 답하고 다음 내용을 포함해야 합니다. "4개의 황금 신호" — 지연(대기 시간), 트래픽(traffic), 오류(errors) 및 로드 크기(포화).

회고적 분석 수행(디버깅)

요청 처리 지연이 늘어났는데 같은 시간에 또 무슨 일이 일어났나요?
모니터링 시스템은 비즈니스 인텔리전스 시스템의 데이터 소스로 유용하고 보안 사고 분석을 용이하게 합니다. 이 책은 SRE가 전문 지식을 갖고 있는 엔지니어링 분야에 중점을 두기 때문에 여기서는 모니터링 기술에 대해 논의하지 않습니다.

모니터링 및 경고를 통해 시스템은 고장이 났거나 고장이 나려고 하는 시기를 알려줍니다. 시스템이 자동으로 자체적으로 복구할 수 없는 경우 사람이 경고를 분석하고 문제가 여전히 활성 상태인지 확인하고 해결하고 근본 원인을 파악하기를 원합니다. 시스템 구성 요소를 감사하지 않으면 단순히 "뭔가 조금 이상해 보인다"는 이유로 경고를 받지 못할 것입니다.

알림으로 인해 사람에게 부담을 주는 것은 직원의 시간을 상당히 많이 사용하는 것입니다. 직원이 작업 중인 경우 경고로 인해 작업 프로세스가 중단됩니다. 직원이 집에 있으면 알림이 개인 시간을 방해하고 수면을 방해할 수도 있습니다. 경고가 너무 자주 발생하면 직원은 경고를 훑어보거나 미루거나 들어오는 경고를 무시합니다. 때때로 그들은 소음으로 인해 가려지는 실제 경보를 무시합니다. 소음으로 인해 문제가 신속하게 진단되고 수정되지 않으므로 서비스 중단이 오랜 시간 지속될 수 있습니다. 효과적인 경고 시스템은 신호 대 잡음비가 좋습니다.

모니터링 시스템에 대한 합리적인 기대치 설정

복잡한 애플리케이션에 대한 모니터링을 설정하는 것은 그 자체로 복잡한 엔지니어링 작업입니다. 수집, 표시, 알림 도구로 구성된 중요한 인프라가 있음에도 불구하고 10~12명의 구성원으로 구성된 Google SRE 팀에는 일반적으로 모니터링 시스템을 구축하고 유지하는 것이 주요 목적인 한두 명의 인력이 포함됩니다. 모니터링 인프라를 통합하고 중앙화함에 따라 이 숫자는 시간이 지남에 따라 감소했지만 각 SRE 팀에는 일반적으로 모니터링 전담 인력이 한 명 이상 있습니다. 모니터링 시스템 대시보드는 보기에 매우 흥미롭지만 SRE 팀은 문제를 모니터링하기 위해 누군가가 화면을 봐야 하는 상황을 조심스럽게 피합니다.

전반적으로 Google은 최적의 사후 분석 도구를 갖춘 간단하고 빠른 모니터링 시스템으로 전환했습니다. 우리는 임계값을 예측하거나 근본 원인을 자동으로 감지하려는 "마법의" 시스템을 피합니다. 최종 사용자 요청에서 의도하지 않은 콘텐츠를 감지하는 센서가 유일한 반례입니다. 이러한 센서는 단순하기만 하면 심각한 이상 현상의 원인을 빠르게 감지할 수 있습니다. 용량 계획이나 트래픽 예측 등 모니터링 데이터를 사용하는 다른 형식은 더 복잡합니다. 낮은 샘플링 속도(시간 또는 일)로 매우 오랜 기간(개월 또는 년) 동안 관찰하면 장기적인 추세가 드러납니다.

Google SRE 팀은 복잡한 종속성 계층 구조로 인해 복합적인 성공을 거두었습니다. 우리는 "데이터베이스가 느리다는 것을 알게 되면 데이터베이스가 느리다는 경고를 받고, 그렇지 않으면 사이트가 느리다는 경고를 받습니다."와 같은 규칙을 거의 사용하지 않습니다. 종속성 기반 규칙은 일반적으로 데이터 센터에 대한 사용자 트래픽을 필터링하는 시스템과 같이 시스템의 변경할 수 없는 부분을 나타냅니다. 예를 들어, "데이터 센터에 대한 트래픽 필터링이 구성된 경우 사용자 요청 처리 지연에 대해 경고하지 않음"은 데이터 센터의 경고에 대한 일반적인 규칙 중 하나입니다. Google의 인프라는 지속적인 리팩토링 속도를 유지하기 때문에 복잡한 종속성 계층 구조를 지원하는 팀은 거의 없습니다.

이 장에 설명된 아이디어 중 일부는 여전히 관련이 있습니다. 특히 끊임없이 변화하는 시스템에서는 증상에서 근본 원인으로 더 빠르게 이동할 수 있는 기회가 항상 있습니다. 따라서 이 장에서는 모니터링 시스템의 몇 가지 목표와 이러한 목표를 달성하는 방법을 간략하게 설명하지만 모니터링 시스템을 팀의 모든 사람이 간단하고 이해할 수 있도록 하는 것이 중요합니다.

마찬가지로 소음 수준은 낮게, 신호 수준은 높게 유지하려면 경보가 발생한 자산을 모니터링하는 접근 방식이 매우 간단하고 안정적이어야 합니다. 사람들에게 경고를 생성하는 규칙은 이해하기 쉽고 명확한 문제를 제시해야 합니다.

증상과 원인

모니터링 시스템은 "무엇이 고장났는가"와 "왜 고장났는가"라는 두 가지 질문에 답해야 합니다.
What broken은 증상을 말하고, Why it broken은 원인을 말합니다. 아래 표에는 이러한 연결의 예가 나와 있습니다.

증상
이유

HTTP 오류 500 또는 404 발생
데이터베이스 서버가 연결을 거부합니다.

느린 서버 응답
높은 CPU 사용률 또는 손상된 이더넷 케이블

남극 사용자는 고양이 GIF를 받지 못합니다.
귀하의 CDN은 과학자와 고양이를 싫어하므로 일부 IP 주소가 블랙리스트에 올랐습니다.

비공개 콘텐츠를 어디에서나 사용할 수 있게 되었습니다.
새로운 소프트웨어 릴리스가 출시되면서 방화벽은 모든 ACL을 잊어버리고 모든 사람이 ACL에 액세스할 수 있게 되었습니다.

"무엇"과 "이유"는 신호를 최대화하고 노이즈를 최소화하는 우수한 모니터링 시스템을 만드는 데 가장 중요한 구성 요소 중 일부입니다.

블랙박스 vs 화이트박스

우리는 중요한 지표에 대해 광범위한 화이트박스 모니터링과 적당한 블랙박스 모니터링을 결합합니다. 블랙박스와 화이트박스를 비교하는 가장 쉬운 방법은 블랙박스가 증상 중심이고 사전 모니터링이 아닌 대응적이라는 것입니다. 즉, "시스템이 지금 제대로 작동하지 않습니다." 화이트박스는 시스템의 내부 검증 기능(이벤트 로그 또는 웹 서버)에 따라 달라집니다. 따라서 화이트박스를 사용하면 임박한 문제, 요청 재전송으로 나타나는 오류 등을 감지할 수 있습니다.

다층 시스템에서는 한 엔지니어의 책임 영역의 증상이 다른 엔지니어의 책임 영역의 증상이라는 점에 유의하세요. 예를 들어 데이터베이스 성능이 저하되었습니다. 느린 데이터베이스 읽기는 이를 감지하는 데이터베이스 SRE의 증상입니다. 그러나 느린 웹 사이트를 관찰하는 프런트 엔드 SRE의 경우 동일한 데이터베이스 읽기 속도 저하의 원인은 느린 데이터베이스입니다. 따라서 화이트박스 모니터링은 범위에 따라 증상 중심인 경우도 있고 원인 중심인 경우도 있습니다.

디버깅을 위해 원격 측정을 수집할 때 화이트박스 모니터링이 필요합니다. 웹 서버가 데이터베이스 쿼리에 응답하는 속도가 느린 경우 웹 서버가 데이터베이스와 통신하는 속도와 응답 속도를 알아야 합니다. 그렇지 않으면 느린 데이터베이스 서버와 웹 서버와 데이터베이스 간의 네트워크 문제를 구별할 수 없습니다.

블랙박스 모니터링은 경고를 보낼 때 중요한 이점이 있습니다. 즉, 문제로 인해 이미 실제 증상이 발생했을 때 수신자에게 알림을 보냅니다. 반면, 아직 발생하지 않았지만 임박한 블랙박스 문제에는 모니터링이 소용이 없습니다.

XNUMX개의 황금 신호

XNUMX가지 골든 모니터링 신호는 대기 시간, 트래픽, 오류 및 포화입니다. 사용자 시스템 측정항목 XNUMX개만 측정할 수 있다면 이 XNUMX개에 집중하세요.

지연

요청을 처리하는 데 필요한 시간입니다. 성공한 요청과 실패한 요청의 대기 시간을 구별하는 것이 중요합니다. 예를 들어, 데이터베이스 또는 기타 백엔드에 대한 연결 끊김으로 인해 발생하는 HTTP 500 오류는 매우 빠르게 진단될 수 있지만, HTTP 500 오류는 실패한 요청을 나타낼 수 있습니다. 500 오류가 전체 대기 시간에 미치는 영향을 판단하면 잘못된 결론을 내릴 수 있습니다. 반면에 느린 오류는 빠른 오류이기도 합니다! 따라서 단순히 오류를 필터링하는 것보다 오류 대기 시간을 모니터링하는 것이 중요합니다.

교통

시스템에 대한 요청 수는 상위 수준 시스템 지표로 측정됩니다. 웹 서비스의 경우 이 측정값은 일반적으로 초당 HTTP 요청 수를 요청 특성(예: 정적 또는 동적 콘텐츠)으로 나눈 값을 나타냅니다. 오디오 스트리밍 시스템의 경우 이 측정은 네트워크 I/O 속도 또는 동시 세션 수에 중점을 둘 수 있습니다. 키-값 저장 시스템의 경우 이 측정값은 초당 트랜잭션 또는 검색 결과일 수 있습니다.

오류

이는 명시적(예: HTTP 500), 암시적(예: HTTP 200이지만 유효하지 않은 콘텐츠와 결합) 또는 정책(예: "XNUMX초 안에 응답을 캡처한 경우 XNUMX초는 오류입니다")의 실패한 요청 비율입니다. HTTP 응답 코드가 모든 실패 조건을 표현하기에 충분하지 않은 경우 부분 실패를 감지하기 위해 보조(내부) 프로토콜이 필요할 수 있습니다. 실패한 요청을 모두 모니터링하는 것은 유익하지 않을 수 있지만, 엔드투엔드 시스템 테스트는 잘못된 콘텐츠를 처리하고 있음을 감지하는 데 도움이 됩니다.

포화

측정항목은 서비스가 얼마나 집중적으로 사용되는지 보여줍니다. 이는 가장 제한된 리소스를 식별하는 시스템 모니터링 측정입니다(예: 메모리가 제한된 시스템에서는 메모리를 표시하고, I/O 제한된 시스템에서는 I/O 수를 표시함). 많은 시스템이 100% 활용도에 도달하기 전에 성능이 저하되므로 활용도 목표를 세우는 것이 중요합니다.

복잡한 시스템에서 포화도는 더 높은 수준의 로드 측정으로 보완될 수 있습니다. 귀하의 서비스가 이중 트래픽을 적절하게 처리할 수 있습니까, 10% 더 많은 트래픽만 처리할 수 있습니까, 아니면 현재보다 더 적은 트래픽을 처리할 수 있습니까? 요청의 복잡성을 변경하는 매개 변수(예: "아무것도 주지 마세요" 또는 "고유한 단일 단조 정수가 필요합니다")가 없고 구성이 거의 변경되지 않는 간단한 서비스의 경우 정적 부하 테스트 값이 적절할 수 있습니다. 그러나 이전 단락에서 설명한 것처럼 대부분의 서비스는 알려진 상한이 있는 CPU 사용률이나 네트워크 대역폭과 같은 간접적인 신호를 사용해야 합니다. 대기 시간 증가는 포화 상태를 나타내는 주요 지표인 경우가 많습니다. 작은 창(예: 99분)에서 XNUMX번째 백분위수 응답 시간을 측정하면 매우 조기에 포화 신호를 제공할 수 있습니다.

마지막으로 포화는 임박한 포화에 대한 예측과도 연관되어 있습니다. 예를 들어 "4시간 안에 데이터베이스가 하드 드라이브를 가득 채울 것 같습니다."

XNUMX개의 골든 신호를 모두 측정하고 측정항목 중 하나에 문제가 있는 경우(또는 포화 상태의 경우 문제에 가까운 경우) 사람에게 경고하면 서비스가 어느 정도 모니터링으로 처리됩니다.

"꼬리"(또는 계측 및 성능)에 대한 걱정

모니터링 시스템을 처음부터 생성할 때 평균 대기 시간, 노드의 평균 CPU 사용률 또는 평균 데이터베이스 가득 참과 같은 평균 값을 기반으로 시스템을 개발하려는 유혹이 있습니다. 마지막 두 가지 예의 위험은 명백합니다. 프로세서와 데이터베이스는 매우 예측할 수 없는 방식으로 폐기됩니다. 지연에도 동일하게 적용됩니다. 초당 100개의 요청으로 평균 대기 시간이 1000ms인 웹 서비스를 실행하는 경우 요청의 1%에 5초가 걸릴 수 있습니다. 사용자가 이러한 여러 웹 서비스에 의존하는 경우 한 백엔드의 99번째 백분위수가 쉽게 프런트엔드의 중앙 응답 시간이 될 수 있습니다.

요청의 느린 평균과 매우 느린 꼬리를 구별하는 가장 간단한 방법은 실제 대기 시간(서비스가 제공한 요청 수, 0ms 사이에 걸린 요청 수)보다는 통계로 표현된 요청 측정값(표시하기에 좋은 도구는 히스토그램)을 수집하는 것입니다. 및 10ms, 10ms와 30ms 사이, 30ms와 100ms 사이, 100ms와 300ms 사이 등. 히스토그램 경계를 대략 지수적으로(대략 3배로) 확장하는 것은 분포를 시각화하는 간단한 방법인 경우가 많습니다. 요청의.

측정에 적합한 세부 수준 선택

시스템의 다양한 요소는 다양한 세부 수준에서 측정되어야 합니다. 예를 들어:

• 일정 기간 동안 CPU 사용률을 모니터링하면 대기 시간이 길어지는 장기적인 스파이크가 표시되지 않습니다.
• 반면, 연간 9시간 이하의 가동 중지 시간(연간 가동 시간 99,9%)을 목표로 하는 웹 서비스의 경우 HTTP 200 응답을 분당 XNUMX~XNUMX회 이상 확인하는 일은 불필요하게 빈번할 가능성이 높습니다.
• 마찬가지로 99,9% 가용성을 위해 하드 드라이브 공간을 1~2분마다 한 번 이상 확인하는 것은 아마도 필요하지 않을 것입니다.

측정값을 세분성 있게 구성하는 방법에 주의하세요. 초당 한 번씩 CPU 로드를 수집하면 흥미로운 데이터를 얻을 수 있지만 이렇게 자주 측정하면 수집, 저장 및 분석하는 데 비용이 많이 들 수 있습니다. 모니터링 목표에 높은 세분성이 필요하고 높은 응답성이 필요하지 않은 경우 서버에서 메트릭 수집을 설정한 다음 해당 메트릭을 수집하고 집계하도록 외부 시스템을 설정하여 이러한 비용을 줄일 수 있습니다. 당신은:

1. 매초마다 CPU 로드를 측정합니다.
2. 디테일을 5%로 줄입니다.
3. 매분 측정항목을 집계합니다.

이 전략을 사용하면 높은 분석 및 저장 오버헤드를 발생시키지 않고 높은 세분성으로 데이터를 수집할 수 있습니다.

최대한 간단하지만 단순하지는 않습니다.

서로 다른 요구 사항이 중첩되면 모니터링 시스템이 매우 복잡해질 수 있습니다. 예를 들어 시스템에 다음과 같은 복잡한 요소가 있을 수 있습니다.

• 모든 유형의 다양한 지표에 대해 다양한 백분위수로 요청 처리 대기 시간에 대한 다양한 임계값에 따라 경고합니다.
• 가능한 원인을 감지하고 식별하기 위한 추가 코드를 작성합니다.
• 문제의 가능한 원인 각각에 대해 관련 대시보드를 만듭니다.

잠재적인 합병증의 원인은 끝이 없습니다. 모든 소프트웨어 시스템과 마찬가지로 모니터링도 너무 복잡해지기 쉬우며 변경 및 유지 관리가 어려울 수 있습니다.

따라서 모니터링 시스템을 최대한 단순화하도록 설계하십시오. 추적할 항목을 선택할 때 다음 사항에 유의하세요.

• 실제 사고를 가장 자주 포착하는 규칙은 최대한 단순하고 예측 가능하며 신뢰할 수 있어야 합니다.
• 자주 수행되지 않는(예: 일부 SRE 팀의 경우 분기별 미만) 수행되는 데이터 수집, 집계 및 경고에 대한 구성을 제거해야 합니다.
• 수집되었지만 미리 보기 대시보드에 표시되지 않거나 경고에서 사용되는 측정항목은 삭제 후보입니다.

Google에서는 알림 및 대시보드와 결합된 기본 측정항목 수집 및 집계가 상대적으로 독립형 시스템으로 잘 작동합니다. Google의 모니터링 시스템은 실제로 여러 하위 시스템으로 분류되지만 사람들은 일반적으로 이러한 하위 시스템의 모든 측면을 알고 있습니다. 복잡한 시스템을 검사하기 위해 자세한 시스템 프로파일링, 프로세스 디버깅, 예외 또는 오류에 대한 세부 정보 추적, 로드 테스트, 로그 수집 및 분석, 트래픽 검사 등 다른 기술과 모니터링을 결합하고 싶을 수도 있습니다. 이들 중 대부분은 기본 모니터링과 공통점이 있지만, 이를 혼합하면 너무 많은 결과가 발생하고 복잡하고 취약한 시스템이 만들어집니다. 소프트웨어 개발의 다른 많은 측면과 마찬가지로 명확하고 단순하며 느슨하게 결합된 통합 지점으로 다양한 시스템을 지원하는 것이 최선의 전략입니다. 예를 들어 웹 API를 사용하여 장기간 일관성을 유지할 수 있는 형식으로 집계된 데이터를 검색합니다. ).

원칙을 함께 묶기

이 장에서 논의된 원칙은 Google SRE 팀이 지지하고 따르는 모니터링 및 알림 철학으로 결합될 수 있습니다. 이러한 모니터링 철학을 고수하는 것이 바람직하며, 이는 경고 방법을 생성하거나 수정하기 위한 좋은 출발점이 되며, 조직의 규모나 서비스 또는 시스템의 복잡성에 관계없이 운영 기능에 대해 올바른 질문을 하는 데 도움이 될 수 있습니다.

모니터링 및 경고 규칙을 생성할 때 다음 질문을 하면 오탐지와 불필요한 경고를 방지하는 데 도움이 될 수 있습니다.

• 이 규칙은 긴급하고 조치를 취해야 하며 필연적으로 사용자에게 영향을 미치는 시스템의 다른 방법으로는 감지할 수 없는 상태를 감지합니까?
• 이 경고가 양성이라는 것을 알면서 무시해도 됩니까? 언제, 왜 이 경고를 무시할 수 있으며 이 시나리오를 방지하려면 어떻게 해야 합니까?
• 이 경고는 사용자가 부정적인 영향을 받고 있음을 의미합니까? 트래픽 필터링을 통하거나 경고를 필터링해야 하는 테스트 시스템을 사용할 때와 같이 사용자가 부정적인 영향을 받지 않는 상황이 있습니까?
• 이 경고에 대응하여 조치를 취할 수 있습니까? 이러한 조치가 시급한가요, 아니면 아침까지 기다릴 수 있나요? 작업을 안전하게 자동화할 수 있나요? 이 조치가 장기적인 해결책이 될까요, 아니면 단기적인 해결 방법이 될까요?
• 어떤 사람들은 이 문제에 대해 여러 개의 경고를 받고 있는데, 경고 수를 줄이는 방법이 있습니까?

이러한 질문은 경보 및 경고 시스템에 대한 기본 철학을 반영합니다.

• 경고가 올 때마다 즉시 대응해야 합니다. 피곤해지기 전에 하루에도 몇 번씩 급하게 반응할 수 있다.
• 각 경고는 관련성이 있어야 합니다.
• 경고에 대한 모든 대응에는 사람의 개입이 필요합니다. 알림이 자동으로 처리될 수 있다면 알림이 도착하지 않아야 합니다.
• 경고는 이전에 존재하지 않았던 새로운 문제나 이벤트에 대한 것이어야 합니다.

이 접근 방식은 특정 구분을 모호하게 만듭니다. 즉, 경고가 이전 네 가지 조건을 충족하는 경우 경고가 화이트박스 또는 블랙박스 모니터링 시스템에서 전송되는지 여부는 중요하지 않습니다. 이 접근법은 또한 특정 차이점을 강화합니다. 원인보다 증상을 식별하는 데 훨씬 더 많은 노력을 기울이는 것이 좋습니다. 원인에 관해서는 피할 수 없는 원인에 대해서만 걱정하면 됩니다.

장기 모니터링

오늘날의 생산성 환경에서 모니터링 시스템은 소프트웨어 아키텍처, 작업 부하 특성 및 성능 목표가 변화하면서 끊임없이 진화하는 생산 시스템을 모니터링합니다. 현재 자동화하기 어려운 경고가 일반화되어 해결될 가치가 있을 수도 있습니다. 이 시점에서 누군가는 문제의 근본 원인을 찾아서 제거해야 합니다. 그러한 해결이 불가능할 경우 경고에 대한 대응에는 완전 자동화가 필요합니다.

장기적인 목표를 염두에 두고 모니터링 결정을 내리는 것이 중요합니다. 오늘 실행되는 모든 경고는 내일 시스템을 개선하는 데 방해가 되므로 장기적으로 모니터링 시스템을 개선하는 데 필요한 시간 동안 생산 시스템의 가용성이나 성능이 저하되는 경우가 많습니다. 이 현상을 설명하기 위해 두 가지 예를 살펴보겠습니다.

Bigtable SRE: 과잉 경고 이야기

Google의 내부 인프라는 일반적으로 서비스 수준(SLO)에 따라 프로비저닝되고 측정됩니다. 수년 전 Bigtable의 서비스 SLO는 라이브 클라이언트를 시뮬레이션하는 합성 트랜잭션의 평균 성능을 기반으로 했습니다. Bigtable 및 낮은 수준의 스토리지 스택 문제로 인해 평균 성능은 "큰" 꼬리에 의해 좌우되었습니다. 즉, 최악의 5% 쿼리는 나머지 쿼리보다 훨씬 느린 경우가 많았습니다.

SLO 임계값에 도달하면 이메일 알림이 전송되고 SLO가 초과되면 메신저 알림이 전송됩니다. 두 가지 유형의 경고 모두 매우 자주 전송되어 허용할 수 없을 만큼 많은 양의 엔지니어링 시간을 소비했습니다. 팀에서는 실제로 관련된 몇 가지 경고를 찾기 위해 경고를 정렬하는 데 상당한 시간을 소비했습니다. 경고 중 일부만 해당 특정 문제에 대한 것이기 때문에 실제로 사용자에게 영향을 미치는 문제를 놓친 경우가 많았습니다. 대부분의 알림은 인프라의 이해할 수 있는 문제로 인해 긴급하지 않았으며 표준 방식으로 처리되었거나 전혀 처리되지 않았습니다.

상황을 해결하기 위해 팀에서는 세 가지 접근 방식을 취했습니다. Bigtable의 성능을 개선하기 위해 열심히 노력하는 동시에 SLO 목표를 쿼리 응답 지연 시간의 75번째 백분위수로 일시적으로 설정했습니다. 또한 이메일 알림이 너무 많아서 진단하는 데 시간을 할애할 수 없었기 때문에 이메일 알림을 껐습니다.

이 전략을 통해 우리는 지속적으로 전술적 문제를 해결하는 대신 Bigtable과 낮은 수준의 스토리지 스택에서 장기적인 문제를 해결하기 시작할 수 있었습니다. 엔지니어는 항상 경고를 받지 않고도 실제로 작업을 완료할 수 있습니다. 궁극적으로 경보 처리를 일시적으로 연기함으로써 서비스 품질을 향상할 수 있었습니다.

Gmail: 예측 가능한 알고리즘 기반 인간 응답

처음에 Gmail은 검색 색인의 일괄 처리 청크를 처리하도록 설계된 수정된 Workqueue 프로세스 관리 시스템을 기반으로 구축되었습니다. Workqueue는 수명이 긴 프로세스에 맞춰 조정되었으며 이후 Gmail에 적용되었지만 불투명한 스케줄러 코드의 일부 버그는 수정하기가 매우 어려웠습니다.

당시 Gmail 모니터링은 Workqueue를 사용하여 개별 작업이 취소되면 알림이 발생하도록 구성되었습니다. 이 접근 방식은 이상적이지 않았습니다. 그 당시에도 Gmail은 수천 가지 작업을 수행했으며 각 작업은 일부 사용자에게만 제공되었기 때문입니다. 우리는 Gmail 사용자에게 좋은 사용자 경험을 제공하는 것에 대해 매우 걱정했지만 너무 많은 알림을 처리하는 것이 불가능했습니다.

이 문제를 해결하기 위해 Gmail SRE는 스케줄러를 최대한 디버깅하여 사용자에게 미치는 영향을 최소화하는 데 도움이 되는 도구를 만들었습니다. 팀에서는 문제 발견부터 해결에 이르기까지 장기적인 해결책을 찾을 때까지 전체 주기를 단순히 자동화할지에 대해 논의했지만 일부에서는 그러한 솔루션으로 인해 실제로 문제 해결이 지연될 것이라는 우려도 있었습니다.

이러한 긴장은 팀에서 흔히 발생했으며 종종 자기 훈련에 대한 신뢰 부족을 반영했습니다. 일부 팀 구성원은 올바른 수정을 위한 시간을 허용하고 싶어하는 반면 다른 구성원은 최종 수정이 잊혀지고 임시 수정이 영원히 걸릴 것이라고 걱정합니다. 이 문제는 상황을 영구적으로 만드는 대신 일시적으로 문제를 해결하는 것이 너무 쉽기 때문에 주의를 기울일 가치가 있습니다. 관리자와 기술 직원은 초기 "고통"이 가라앉은 후에도 장기적인 수정을 구현하고 잠재적인 장기 수정을 지원하고 우선순위를 지정하는 데 핵심적인 역할을 합니다.

정기적이고 반복적인 경고 및 알고리즘 응답은 위험 신호입니다. 팀이 이러한 경고 자동화를 꺼린다는 것은 팀이 알고리즘을 신뢰할 수 있다는 확신이 부족하다는 것을 의미합니다. 이는 해결해야 할 심각한 문제입니다.

장기간

Bigtable과 Gmail의 예를 연결하는 공통 주제는 단기 가용성과 장기 가용성 간의 경쟁입니다. 종종 강력한 노력은 취약한 시스템이 고가용성을 달성하는 데 도움이 될 수 있지만 이 경로는 일반적으로 수명이 짧고 팀 소진과 동일한 영웅 팀의 소수 구성원에 대한 의존으로 가득 차 있습니다.

가용성을 제어하고 단기적으로 줄이는 것은 종종 고통스러운 일이지만 시스템의 장기적인 안정성을 위해서는 전략적으로 중요합니다. 각 경고를 개별적으로 살펴보는 것이 아니라, 경고 볼륨의 전체 수준이 실행 가능한 팀과 유리한 예후를 갖춘 건강하고 적절하게 액세스 가능한 시스템으로 이어지는지 여부를 고려하는 것이 중요합니다. 우리는 경영진에 대한 분기별 보고서에서 경고 빈도 통계(일반적으로 교대조당 사건으로 표시되며 사건은 여러 관련 사건으로 구성될 수 있음)를 분석하여 의사 결정자가 경고 시스템 부하 및 전반적인 팀 상태를 지속적으로 확인할 수 있도록 합니다.

결론

정상적인 모니터링 및 경고를 향한 길은 간단하고 명확합니다. 이는 경고를 유발하는 문제의 증상에 초점을 맞추고 원인을 모니터링하는 것은 문제 디버깅에 도움이 됩니다. 데이터베이스의 로드 및 성능 모니터링은 데이터베이스 자체에서 직접 수행해야 하지만 제어하는 ​​스택이 높을수록 증상을 모니터링하는 것이 더 쉽습니다. 이메일 알림은 유용성이 매우 제한되어 있으며 쉽게 소음이 되는 경향이 있습니다. 대신 이메일 경고를 유발하는 모든 현재 문제를 모니터링하는 대시보드를 사용해야 합니다. 대시보드를 이벤트 로그와 결합하여 과거 상관관계를 분석할 수도 있습니다.

장기적으로는 증상과 임박한 실제 문제에 대한 경고를 성공적으로 순환시켜 모니터링이 신속한 진단을 지원하도록 목표를 조정하는 것이 필요합니다.

번역을 끝까지 읽어주셔서 감사합니다. 모니터링에 대한 내 전보 채널을 구독하십시오. @monitorim_it и Medium의 블로그.

출처 : habr.com