Ch16. 시스템 중단 추적하기

지속적으로 신뢰성을 개선하는 것은 기준을 명확히 하고 절차를 추적할 수 있을 때만 가능하다. 이를 위해 구글에서는 '아우터레이터'라고 부르는 서비스 중단 현상 추적 도구를 사용한다. 이번 장에서는 아우터레이터를 통해 시스템 중단 추적에 대해서 알아보도록 하자.

 

1. 에스컬레이터

구글에서는 SRE를 위한 모든 알림은 사람이 알림의 수신을 확인했는지 여부를 추적하는 중앙 응답 시스템을 공유하고 있다. 설정된 시간이 지나도 아무도 수신을 확인하지 않으면 시스템은 설정된 다음 단계로 알림을 격상한다. '에스컬레이터'라고 부르는 이 시스템은 비상 대기 엔지니어에게 전달된 이메일의 복사본을 수신하는 투명한 도구로 기획된 것이다. 이 기능 덕분에 사용자의 반응이 없어도 에스컬레이터가 손쉽게 기존의 업무 흐름에 통합될 수 있다.

 

2. 아우터레이터

아우터레이터는 개별적인 알림의 격상뿐만 아니라 그다음 단계의 추상화, 즉 시스템 중단 장애(outage)까지도 처리할 수 있는 시스템이다. 여러 큐에 보관된 알림을 시간별로 한 번에 확인할 수 있어, 여러 큐를 사용자가 직접 전환해 가며 확인하지 않아도 된다. 슬랙이나 힙챗 혹은 IRC 등의 시스템은 아우터레이터를 대체하기에 손색이 없는 훌륭한 도구라고 한다.

 

2.1 수집

여러 개의 알림을 하나의 장애로 합치는 것은 중복을 다루기 위한 핵심 기능이다. 알림이 발생할 때마다 "이 메일은 앞서 보낸 메일의 내용과 동일한 원인에 의해 발송되었습니다."라는 메일을 보내는 것도 가능하다. 이를 통해 같은 디버깅 절차를 반복하는 것을 피할 수 있다. 그러나 각 알림마다 메일을 보내는 것은 실용적이지 않을뿐더러 한 팀에 중복된 알림을 보내는 것은 효과적인 해결책도 아니다. 여러 팀에 한 번만 보내거나 한 번 보낸 후에는 일정 시간 동안 다시 보내지 않는 것이 좋다.

 

2.2 태깅

알림에 대한 메타데이터를 추가하기 위해 범용 목적의 태깅(tagging)을 지원한다. 태그를 파싱해서 의미 있는 링크를 만들어낼 수도 있고 혹은 각 팀별로 원하는 태그나 표준 태그들을 구성해서 유용하게 활용할 수 있다.

 

2.3 분석

축적된 장애 처리 데이터를 분석하여 시스템 중단 장애 추적에 도움을 줄 수 있다.

 

분석 기능의 가장 아래쪽 계층에는 보고서를 위한 기본적인 산술, 통계 및 집계 기능이 포함된다. 세부 내용은 팀마다 다르지만 주/월/분기별 장애와 장애별 알림 수 같은 정보들이 이에 해당된다. 그 위의 계층은 이보다 더 중요하면서도 조금 더 쉽게 제공할 수 있는 데이터들이다. 즉, 팀 혹은 서비스의 시간별 데이터를 비교함으로써 최초의 패턴과 추이를 찾아내는 계층이다. 각 팀은 이 데이터를 통해 현재 발생하는 알림의 수가 담당하는 서비스 혹은 다른 서비스들에 대한 지금까지의 추적 기록과 비교해 '보통'의 수준인지 여부를 판단할 수 있다.

 

3. 결론

음,, 이번 장에서는 사실 바로 적용할만한 내용은 없었던 것 같다. 역시 구글답게 필요한 것은 자체적으로 개발하는 것이 멋있는 것 같다. 시스템 중단과 관련된 내용을 위 도구를 통해 어느 정도 도움을 받을 수는 있지만 어디까지나 도움만 주는 것 같다. 분석에서는 알림의 수를 비교해서 현재 상태를 파악하는 예시가 있었는데, 개인적으로 시기마다 알림의 수는 충분히 바뀔 수 있는 가능성이기 때문에 해당 정보가 정말 도움이 되는지는 의문이 있다. 그래도 참고 용도로는 아주 좋은 도구라고 생각한다.