
트위터는 왜 두번이나 모니터링 시스템을 직접 개발 하였을까요? 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만개로 증가.
marshal / unmarshal – encode / decode에 대한 go의 개념들
Marshal 이란?
구조체 또는 객체의 데이터를 json으로 byte[]로 만드는 것이 json.Marshal의 역할입니다. 여기까지는 그냥 string이며 http상에서는 문서로써 바로 전달이 가능하지요. http상에서는 모든게 문서이니깐요 🙂
(marshalling의 원래의미 – 군대에서 준비태세를 갖추는것을 말하는 것인데, 네트워크-전쟁으로 나아가기 전에 어떤 포멧- 무기로 싸울지 준비태세를 갖추는 것으로 이해하면 됩니다)
Serialization 이란?
하지만 일정한 크기로 잘게 나누어서 물 흐르듯이 계속 보내기 위해서는 stream 형태로 전달할 필요가 있습니다. node.js가 서버 사이드 언어이므로 최상위 객체 EventEmitter바로 밑에 stream 으로 흐르게 딱 박혀있습니다 (왜 갑자기 node.js 이야기를 하냐면 stream이 그만큼 서버 사이트 프로그래밍에 중요하다는 의미이고 node.js 도 stream 형태로 데이터를 전송하는 것이 기본 골격이라는 의미입니다)
golang에서는 Encode (Serialization) 라 불러주세요
golang에서는 serialization, 즉 byte[] 데이터를 stream화 하는 녀석의 이름이 encode라고 부르네요.

json.Marshal , Encode 의 개념도