트위터는 왜 두번이나 모니터링 시스템을 직접 개발 하였을까요?   Monitorama 에서 발표한 Building Twitter Next-Gen Alerting System과  여러 컨퍼러스에서 발표한 내용을 정리해서 공유해 드리고자 합니다.

Twitter 모니터링 초창기 시스템 아키텍처

첫 모니터링 솔루션은 위와 같이 아키텍처를 수립하였습니다. (현재 오픈소스 솔루션과 유사하죠)     1.0 시스템은 다음과 같은 컴포넌트로 구성되어 있습니다.  (트위터의 모니터링 시스템이 오픈소스로 공개되지 않아서, 전적으로 발표자료에 의존해 설명이 구체적이지 않습니다. )

• Agent  – 데이터를 수집하는 Agent로 시스템 성능에 필요한 여러 지표를 수집.
• Collector & Storage API – 수집부에서 데이터를  모아  Storage API 를 통해 Time Series Database( Manhattan으로 추정)에 저장하고, 그정보를 Cassandra에 저장.
• Monitoring – Query 엔진으로 데이터를 긁어와 여러 지표를 모니터링.
• Dashboard –  Alert 과 Dashboard 를 쉽게 구성할수 있는 Config, DSL을 제공.
• Ad Hoc Queries – 상황에 따라 적합한 쿼리를 던질수 있음.

트위터는 왜 모니터링 2.0 시스템을 만들어야 했나?

하지만 트위터의 급격한 성장으로 인해, 위 아키텍처로는 더 이상 모니터링을 할수 없는 상황이 되었습니다.

• 1분당 수집되는 메트릭이 3년 만에 3억개(300M)-> 14배로 43억개(4.3B)으로 증가.
• 발생하는 알럿의 증가 –  1분당 2500개 -> 1분당 3만개로 증가.

• 기존 시스템 Alert Config 간단하게 만들어서 올리는 형태를 제공, Alert config와 dashboard 구성 DSL 간의 관리가 잘 되지 않음 -> 알럿을 설정했지만 대시보드 구성에 빠져서 정작 데이터는 못보는 문제들이 발생

• Alert 시스템을 한 존에서만 운영했는데, 존 자체가 안 좋아져서 알럿이 안 온 사례도 많아.  Alert 시스템을 멀티 존에 이중화 함.  이에 동일한 알럿을 두번 받게 되더라도, 예외처리하는 코드등이 필요하게 되었음.

더 나은 모니터링 솔루션 2.0을 만들기 위한 노력들

새로운 모니터링 시스템을 만들기 위해 인터뷰를 비롯하여, 고객의 페르소나 분석등, 어떻게 개선할지 많은 이야기를 나누었습니다 .  고객의 요구를 정확히 파악하기 위해 원하는 Feature에 대해 계속 질문을 하였으며,  답은 유도하거나 제시하지 않기 위해서 많은 노력을 했습니다.

• Usage – 화면을 보게 되었을때 무엇을 하는가?
• Motivation – 1.0에서 알럿(이벤트)를 받았을때 왜 반응하거나/ 반응하지 않았는가?
• Pain Point – 사용하면서 좌절하거나, 힘들게 만들었던 요인들은 무엇이냐?

개선된 2.0을 만들기 위해, 2.0에 도움이 될 페르소나 등을 도출하는 등의 노력도 했구요

개선된 모니터링 2.0

실제적으로 어떠한 개선이 이루어졌는지 보도록 하시죠. 모니터링 솔루션을 제작하거나/사용하는 입장에서 충분히 공감할 부분들이 많았습니다.

1. 알럿과 대시보드와의 통합

1.0에는 알럿과 차트가 분리되어 있어서 알럿이 발생해도, 어느 대시보드에서 있는지 찾기가 어려웠습니다.  

2.0에서는 알럿과 해당 차트가 맵핑됨으로써,  차트에서 좋고 나쁜 상태를 또 반대로 알럿이 발생한 차트가 무엇인지 쉽게 찾을수 있게 UI가 개선되었습니다.

2. 설정 언어에 대한 변경

기존 대시 보드 구성을 DSL대신,  python으로 변경하여 더 유연하게, 사전 검증 가능하게 만들었습니다.

모니터링 하는 대상들을 Python 모듈로만들어서 쉽게 대시보드에 addin되는 형태로 만들었으며, 배포 전에 server side validator를 통해서 안정성을 검증하는 로직을 강화했습니다.  실수하지 않게 만드는 것이지요. 

3. 알럿 신뢰성 확보 문제

1.0에서는 알럿 신뢰성을 위해 멀티 존에서 알럿을 보냈으나,  클라이언트 쪽에서는 두번 메세지를  체크하는 등에 대한 여러 번거로움이 있었습니다.  그래서 zone의 건강 상태를 체크하고, 상태가 좋은 zone으로  alert 시스템을 rebalnacing하게 만들었습니다.

Twitter 모니터링 2.0 시스템 아키텍처

위에 대한 고민들을 반영하여, 새로운 모니터링 시스템을 만들었습니다.

• Agent – Python으로 만들어진 Agent로 부터 데이터를 수집한다.
• Ingestion Service – 데이터를 저장및 조회하는  엔진인 Cuckoo를 별도로 제공합니다. 내부적으로는 트위터가 만든 Time Series DB인 Manhattan에 정보를 저장합니다.
• Time Series DB Query Engine – Cuckoo를 통해 원하는 데이터를 조회할수 있는 CQL을 별도로 제공합니다.   CQL은 내부적으로 다음과 같이 동작합니다.

• Parser는 쿼리를 파싱하여 AST (Abstract Syntax Trees)로 만들고, Rewriter는 성능 향상을 위하여,  AST 노드를  프로세싱 하고, 성능 향상을 위해 후처리 작업을 합니다. 그리고 Executor는 Rewriter의 작업 결과물을 실행하고,  output을 도출합니다.
• Time Based Aggregation  – 입력받은 데이터를 가공하여 분단위, 시간 단위로 쪼개어 저장됩니다.
• Temporal Indexing Service –  서비스, 소스 및 메트릭을 신속하게 탐색 할 수 있는 색인 서비스를 제공합니다. 지표의 메타 데이터 / 타임 스탬프등을 추적하고, 맴버 셋(redis 의 smember와 유사한 것으로 추정)에 대한 키 값을 관리합니다.
• CLI (command line interface) / Visualization – 고객은 CLI 와 를 시각화할 수 있는 UI를 사용하므로, 이에 적합하게 데이터를 전송 .

클라우드 존의 건강 상태를 보고 이사가는 알럿 시스템 구축

모니터링에서 핵심 킬러 서비스인 알럿의 비용 절감 및 관리 효율화를  위해,  두개의 Zone에서 이중화 하여 사용하는 것 보다는, Zone의 상태 (사견 : 네트워크 latency, IOPS, CPU StealTime 등을)가 좋지 않다면, 다른 Zone으로 알럿 시스템을 이사(ReBalancing) 할수 있게 만들었습니다.

성능이 나오지 않는 존에서 scale out으로 처리하기 보다는,  상태가 건강한 존으로 이사를 간다는 것이 눈여겨 볼만한 상황입니다.   이렇게 하기 위해서는 stateless process 기반으로 시스템이 구축되어야 한다는 점입니다. 그리고  상태정보가 저장되는 DB는 두 존에 다 배포되어 동기화 된다는 것이 위 아키첵처의 핵심이라고 발수 있습니다.

• 알럿을 빠르게 전송하기 위해 RuleSet들을 Shard로 나누어 전송.  

한 서버에 모든 Rule들을 다 저장한 것이 아니라,   Rule들을 샤딩을 했다는 것입니다.  트위터 알럿 시스템 2.0 아키텍처에서 Balancer가  적절하게 샤드를 나누어서 배분한 것으로 보입니다.

Human Reasoning (장애가 발생하면 합리적인 판단이 가능하게 만든다..)

고객이 솔루션을 사용할때, 합리적으로 판단하고 추론할수 있도록 만드는데 많은 고민을 한 것이 발표에서 느껴졌습니다.

1. 장애 발생시 Context를 고민해야 한다.  발생한 장애의 Root Cause를 찾는 것이 중요하며 그 유형을 다음과 같이  분류했습니다. 

• Global context : backbone componet(network.) 장애,  전체에 영향을 주는 장애.   
• Peer context : peer들간의 의존관계로 발생하는 장애. (Storage Layer의 문제)
• Local context : 배포를 잘못한 경우등.

2. 시스템을 다시 안정화 시킬 필요가 있는데, 다음과 같이 구성하여 해결.  실행 지침(list of steps)과 해결이 힘들경우 escalation할 컨텍 포인트(link)를 제공.

3. 알럿이 발생한 곳과 연관된 차트에 표현하기

Empower Human  – 어떻게 사용자에게 더 도움을 줄까?

2.0을 만들고 나서, 사용자들이 잘 사용할수 있게 전방위 적으로 다양한 점접을 만들었습니다.

• 1차 지원  –  Interaction 접점들을  다양히 제공 / 특히 세번째 Configuration Libraries 많은 시간을 투자 하였습니다.

• 2차 지원 : Documentation을 업데이트하기 위해 많은 노력을 했습니다. 특히 코드와 일치가 유지되도록 많은 노력을 진행하였습니다. 

• 3차 지원 :  당번(On Call)을 두어 직접 응대를 함.

맺음

클라우드 상황에서 서비스의 안정성을 유지하기 위해서 모니터링은 필수이며, 모니터팅의 핵심인 알럿의 높은 성능을 유지하기 위해 zone 의 상태를 보고 이사를 갈수 있는 시스템을 만들었다는 것이 매우 인상적이었습니다.  그리고 내부 시스템이지만 1.0 사용자를 인터뷰하면서 2.0 개선안을 도출해내는 점진적 개선하는 모습들. 그리고 이 컨셉들이 향후 와탭 제품에 많이 도움이 될듯 하네요.

이 내용인 모니터링 컨퍼러스인 monitorama 2017년도에 Building Twitter Next-Gen Alerting System 내용과 여러 블로그 글들을 찾아 요약한 것입니다.