한빛출판네트워크

구글의 SRE팀은 성공적인 모니터링 및 경보 시스템 구축을 위한 몇가지 기본적인 원칙과 최고의 실례를 보유하고 있습니다. 본 글에서는 어떤 이슈가 사람들을 호출해서 방해하는지, 그리고 호출이 필요할만큼 충분히 심각하지 않은 이슈들을 어떻게 처리할 지에 대한 가이드라인을 제공합니다.

 

용어 정의

모니터링과 관련된 모든 주제를 논의하기 위해서 일관되게 공유할 용어는 존재하지 않습니다. 심지어 구글 내부에서도 다음의 용어들이 다양하게 사용되고 있습니다만, 가장 공통적인 해석을 소개합니다.

 

모니터링(Monitoring)

쿼리 수 및 타입, 에러 수 및 타입, 연산시간 및 서버의 활성시간과 같은 시스템의 정량적 수치를 실시간으로 수집하고, 처리하고 조합하여 보여주는 것

 

화이트박스 모니터링(White-box monitoring)

로그, JVM의 프로파일링과 같은 인터페이스류, 또는 내부 통계정보를 보내주는 HTTP 핸들러를 포함한 시스템의 내부에 의해 노출된 측정 기준에 근거한 모니터링

 

블랙박스 모니터링(Black-box monitoring)

사용자로서 관찰하듯 보이는 현상을 외부에서 테스팅하는 것

 

대쉬보드(Dashboard)

서비스의 핵심 계측 정보를 요약한 것을 (주로 웹기반의) 애플리케이션을 통해 제공하는 것. 대쉬보드는 필터나 셀렉터 등의 기능도 있지만 핵심은 사용자에게 꼭 제공해야 할 계측 정보를 갖고 있다는 것입니다. 대쉬보드는 현재 티켓큐의 길이, 고빈도의 버그 목록, 현재 지역의 당직 엔지니어, 최근 푸시내역 등의 팀정보를 제공할 수도 있습니다.

 

경보(Alert)

사람이 읽을 수 있게 의도된 알림. 이는 시스템에 버그나 티켓큐, 이메일, 또는 호출 시스템에 전달됩니다. 각각 이러한 경보는 티켓, 이메일 경보, 및 호출 시스템으로 분류 됩니다. 

 

근본 원인(Root cause)

수리하면 동일한 방식으로 재현되지 않을 것이라는 확신을 줄 수 있는 소프트웨어 시스템 또는 인간 체계 내의 결함. 주어진 사건은 여러가지 근본적인 이유를 내포할 수 있는데 아마도 불충분한 프로세스 자동화의 결합, 가짜 입력으로 깨진 소프트웨어 때문이거나 설정정보를 생성하는데 쓰이는 스크립트의 불충분한 테스팅 때문일 수 있습니다. 이러한 요소들은 각각 독립적으로 근본 요인이 될 수 있으며 수리할 수 있습니다.

 

노드와 머신(Node and machine)

물리적인 서버 혹은 가상 머신 또는 컨테이너 안에서 실행중인 단일 커널 인스턴스를 나타내는 말로 교환해서 사용 가능합니다. 하나의 머신위에 모니터링 할만한 복수의 서비스들이 있을 수 있습니다. 서비스들은 캐쉬서버와 웹서버와 같이 상고 연관이 있을 수도 있고, 아니면 코드 리파지토리나 Puppet, Chef와 같은 설정 시스템을 위한 마스터의 예와 같이 하드웨어만 공유할 뿐 연관이 없을 수도 있습니다. 

 

푸쉬(Push)

실행중인 서비스의 소프트웨어나 설정에 가하는 변화

 

왜 모니터링이 필요한가?

다음의 이유를 포함하여 시스템을 모니터링 해야하는 이유는 많이 있습니다.

 

장기적인 트렌드 분석

사용중인 데이터베이스의 규모가 얼마나 되며 얼마나 빨리 커지고 있는지? 일간 액티브 사용자의 수가 얼마나 빠르게 증가하는지?

 

시간 순이나 실험 그룹에 따른 비교

Acme Bucket of Bytes 2.72와 DB 3.14 중 어느 쿼리가 더 빠른가? 추가 노드에 따른 맴케쉬 적중률이 얼마나 더 좋은가? 지난주 대비 사이트가 더 느려졌는가?

 

경보

문제가 발생했을 시 누군가 당장 고칠 수 있어야 합니다. 또는 무언가가 곧 발생할 것 같으므로 누군가가 확인을 곧 해야합니다.

 

대쉬보드 만들기

대쉬보드는 사용중인 서비스의 이 장의 후반부에서 다룰 4가지 골든 신호의 형태를 포함하여 기본적인 질문들에 답할 수 있어야 합니다. 

 

디버깅과 같은 임시의 회고 분석을 수행

시스템의 레이턴시가 갑자기 튀어 올랐을 경우, 동시에 무슨 일이 있었는지?

 

시스템 모니터링은 비즈니스 분석도구나 보인 취약점 분석을 용이하게 하기 위하여 원천 입력값을 공급할 때에도 도움이 됩니다. 이 책은 SRE 분야의 특별한 전문성을 기반으로 하는 공학분야에 집중하기 때문에 모니터링 애플리케이션에 대해서 다루지 않습니다.

 

모니터링 및 경보를 하는 것은 시스템이 우리에게 언제 고장이 났는지 전달해 줄 수 있으며, 무슨 일이 벌어지려고 하는지도 말해 줄 수 있습니다. 시스템이 자동으로 문제를 해결할 수 없다면, 우리는 경보를 살펴볼 사람이 필요하고, 문제의 근원을 파악해야 합니다. 시스템 내 매우 협소한 범위의 컴포넌트 보안성 감사를 하는 것이 아니라면 “무언가 이상한 증상이 보인다”는 이유로 단순히 경보를 호출해서는 안 됩니다.

 

직원을 호출하는 것은 직원의 시간을 고려할 때 기회비용이 큰 일입니다. 직원이 근무 중인 상태에서의 호출은 근무자의 작업 흐름을 방해할 것입니다. 만약 직원이 집에 있다면 호출은 그의 개인 시간, 심지어 수면까지 방해합니다. 호출이 너무 빈번하게 일어나면 직원은 호출에 대해서 한번 더 추측하거나, 지나치거나, 심지어 들어오는 경보까지 무시할 수 있기 때문에, 가끔 노이즈로 인해 숨겨진 진짜 호출까지 무시하게 됩니다. 노이즈가 빠른 진단과 수리를 방해할 수 있기 때문에 중단사태가 더 연장될 수도 있습니다. 효과적인 경보시스템은 좋은 신호와 매우 낮은 노이즈를 가지고 있어야 합니다.

 

모니터링에 적당한 기대값 설정하기

복잡한 애플리케이션을 모니터링하는 것은 의미 있는 공학적 노력일 뿐 아니라 모니터링 자체로도 의미가 있습니다. 구글은 계측, 수집, 표현, 적절한 경보를 위해서 기존 인프라스트럭쳐가 상당합니다. 하지만 구글의 SRE팀은 10~12명의 멤버가 모니터링 서비스를 빌드하고 유지하기 위해서 전담 팀을 1명에서 때론 2명가지 일반적으로 할당하고 있습니다. 멤버의 수는 모니터링 인프라스트럭쳐가 중앙으로 공통화되고 일반화되면 점차 줄겠지만, 모든 SRE팀은 언제나 적어도 한명의 모니터링 요원을 갖추고 있습니다. (트래픽 그래프의 대쉬보드에 접근할 수 있다는 것은 신나고 원하는 바일 수도 있습니다. 그러나, SRE팀은 조심스럽게 “문제를 발견하기 위해 화면만 응시하는 행위”를 누군가에게 요구하는 상황은 무엇이라도 피하려고 합니다.)

 

구글은 개선된 도구와 사후 분석을 통해서 간소하고 신속한 모니터링 시스템으로 전환 하고 있는 중입니다. 우리는 임계값을 학습하고 자동으로 인과관계를 찾아내는 마법같은 시스템은 회피합니다. 가능한 단순하게 규칙들을 유지하려고 하면서 매우 간단하고, 구체적인 심각한 변칙 사례를 최대한 빠르게 발견하게끔 합니다. 그러나 하나의 반례로 최종 사용자의 요청 비율에서 예측 못한 변화를 찾는 규칙이 있습니다. 트래픽 예측과 용량 산정 등의 모니터링 데이터는 시스템의 취약성이나 더 나아가 복잡성을 묵인하는데도 사용할 수 있습니다. 시간 또는 일 단위의 매우 낮은 샘플링 비율로 월 또는 연단위의 매우 긴 시간동안 수행하는 관찰실험을 진행하면 간헐적으로 유실된 샘플들이 누락될 수 없기에 더욱 취약성에 견딜수 있게 해줄수도 있습니다.

 

구글의 SRE팀은 복잡한 의존관계의 계층 속에서 매우 제한적인 성공을 이루어 왔습니다. 우리는 “만약 내가 데이터베이스가 느리다는 것을 안다면, 데이터베이스가 느리다고 경보를 내릴거야. 아니면 웹사이트가 점차 느려질거라고 경보할거야”라는 식의 규칙은 좀처럼 사용하지 않습니다. 의존관계 정보를 신뢰하는 규칙은 우리 시스템을 위해 데이터센터로부터 나가는 사용자 트래픽처럼 매우 안정적인 부분과 잘 어울립니다. 예를 들면 “데이터센터에서 트래픽이 나오는 경우의 레이턴시로 나에게 경보하지 말아”는 데이터센터의 일반적인 경보 규칙 중 하나 입니다. 구글의 인프라스트럭쳐는 꾸준한 비율로 지속적으로 리팩토링되어 왔기에 복잡한 의존관계를 유지하는 팀이 거의 없습니다.

 

이번 장에서 기술한 몇가지 의견은 여전히 요원할 수 있습니다. 다만 특별히 계속해서 빠르게 변화하는 시스템에서는 증상에서 근본 원인으로 좀 더 신속하게 이동할 여지가 언제나 있습니다. 이번 장에서 제시한 몇가지 목표를 정해서 모니터링 시스템에 설정한 후 이 목표를 달성하기 위한 몇가지 방법을 정할 수 있습니다. 그리고 모니터링 시스템을 실제 환경의 문제에서도 호출이나 기본적인 선별 및 심도 있는 디버깅을 진행하면서도 간단하고 팀 내 모든 이들이 이해할 수 있도록 유지하는 것이 중요합니다.

 

마찬가지로, 노이즈는 낮추면서 신호를 높이기 위해서 직접 호출하는 여러분의 모니터링 시스템의 요소는 매우 간단하고 견고해야 합니다. 사람들에게 경보를 발생시키는 규칙은 살마들이 이해하고 명백하게 문제를 재현할 수 있을 만큼 간단한 것이 좋습니다.

 

증상과 원인

여러분의 모니터링 시스템은 다음의 두가지 질문에 응답할 수 있어야 합니다.

 

무엇이 고장났는가? 그렇다면 왜 고장났는가?

 

“무엇이 고장났는가?”라는 질문은 증상을 나타냅니다. “왜 고장났는가?”는 중간단계일 원인을 나타낼 것입니다. 아래 표는 몇가지 가상의 증상과 이에 상응하는 원인을 연결한 예입니다.

 

[표] 예시 증상과 원인

증상	원인
HTTP 500번대  혹은 404 등의 에러	데이터베이스 서버에서 커넥션 요청을 거절
시스템의 응답이 느림	비효율적인 로직에 의한 CPU 리소스 과용, 서버 랙 하단의 이더넷 케이블의 파손으로 부분적인 패킷 감소
남극대륙의 사용자는 GIF 타입의 고양이 애니메이션 이미지를 받지 못함	여러분의 CDN 서비스가 과학자나 고양이과 동물을 싫어하든지 결과적으로 몇몇 사용자 IP를 블랙리스트로 등록했음
사적인 컨테츠가 공개가 되어버림	새로운 소프트웨어 추진에 다른 변화로 ACL 설정을 놓쳐서 모든 요청을 받아버림

 

“무엇”과 “왜”는 최대한의 신호와 최소한의 노이즈로 좋은 모니터링 정보를 만드는데 있어 중요한 차이 중 하나가 됩니다.

 

블랙박스와 화이트박스

우리는 활발하게 화이트박스 모니터링을 진행하면서 신중하면서도 결정적인 순간에 블랙박스 모니터링을 혼합하여 진행합니다. 블랙박스 모니터링과 화이트 박스 모니터링을 비교한다고 할 때 가장 단순한 비교는 블랙박스 모니터링은 증상에 기반하며, “시스템이 지금 정상작동 하지 않는다”는 예측할 수 없지만 문제상태를 재현하는 것입니다. 화이트박스 모니터링은 로그나 계측장비를 통한 HTTP의 종단점등 시스템의 내부를 조사할 수 있는 능력에 의존합니다. 그러므로 화이트박스 모니터링은 재시도를 통해서 사라질 수 일촉 즉발의 문제나 실패 정보 등을 확인하는 경우에 허용됩니다.

 

다중 계층 시스템에서 누군가의 증상이 다른 누군가의 원인이 되기도 합니다. 예를 들어 데이터베이스의 퍼포먼스가 느리다고 해봅시다. 데이터베이스 읽기속도 저하는 이를 발견한 데이터베이스 SRE 팀에게는 증상이 됩니다. 그러나 프론트엔드 SRE팀에게 웹사이트의 낮은 반응성은 데이터베이스의 읽기속도 저하가 원인이 됩니다. 그러므로 화이트 박스 모니터링을 통해서 어떤 정보를 얻느냐에 따라 증상에 초점을 맞출 수도 있고, 원인에 초점을 맞출수도 있습니다.

 

원격으로 디버깅을 수행할 때, 화이트박스 모니터링은 필수적입니다. 만약 웹서버가 데이터베이스에 요청이 몰려 느린 것처럼 보인다면, 여러분은 반드시 웹서버가 얼마 만에 데이터베이스의 병목 상황을 인식할지와 얼마만에 데이터베이스 서버에서 스스로 병목상황을 파악하게 될지 둘 다 알아야 합니다. 그렇지 않으면 여러분은 웹서버와 데이터베이스 사이의 네트워크 문제로부터 실제 데이터베이스 서버의 속도 저하를 구별할 수 없을 것입니다.

 

블랙박스 모니터링은 이미 진행 중이고 실제 증상을 일으키는 문제의 경우에만 사람들을 호출하여 성가시게 하도록 강제로 규정하는데 유용한 이점을 갖습니다. 반면에 아직 발생하지 않지만 곧 닥쳐올 문제의 경우 블랙박스 모니터링은 거의 쓸모가 없습니다.

 

***

번역 : 조우진

원문 : Monitoring distributed systems