모니터링 시스템에 대한 이야기

오늘은 모니터링 시스템에 관련하여 좋은 내용을 발견하여, 읽고 나서 느낀 흥미로운 내용들을 추려 보았다. 사실 출처의 내용도 이미 추려진 내용이라, 간추려진 내용을 또 주관적 생각을 담아 간추리는 꼴이라서 제대로 된 이야기를 읽으려면 원문을 참조하는 것이 제일 좋다

거대한 프로그램이든 아니면 조그마한 프로그램들이 모여 만들어진 하나의 거대한 시스템이든, 규모가 커지면 커질수록 단순 로그를 남기기만 해서는 문제 분석이 어려워지는 경우가 많기 때문에, 이렇게 다른 빅테크 기업에서 문제 해결을 위해 고민한 이야기는 읽어두면 큰 도움이 된다고 생각한다.

패턴 찾기

먼저 모니터링 시스템이 존재하는 이유는 패턴을 찾기 위함이다. 하지만 실제 발생하는 수많은 이벤트들을 보고 있으면 어떤 식으로 패턴을 찾아내야 할 지 감을 잡기가 어렵다. 넷플릭스에서는 DRUI라는 자체적인 통합 UI 모니터링 시스템을 만들었으며, 아래와 같은 방식을 이용하여 문제 패턴을 찾아내고 대응하고 있다.

필터링

각종 이벤트들의 홍수에서 필요한 이벤트만 볼 수 있도록 하는 필터링 기능은 중요하다.

하지만 개발 과정에서 충분한 이벤트, 적절한 tagging을 남기고 있는지 또한 고려해야 할 요소이다. 의외로 production에서 많이 놓치는 포인트였다 개인적으로는 event replay에 준하는 정도로 남겨놓아야 이후 분석에 도움이 된다고 생각한다.

그룹화

특정 경고가 발생하면 해당 경고를 그룹화하기 위해 태깅(tagging) 작업을 수행합니다. tagging 되는 내용은 현재 실행중인 맥락 등의 정보가 포함될 수 있을 것입니다. 이후 동일 경고가 발생할 경우, 이전 경고에서 동일 tag를 가지고 있다면 연관지어 분석할 수 있는 근거가 됩니다.

자동화된 분석과 알림 시스템

시스템이 이벤트를 기반으로 분석을 수행하고 알림을 보내줄 수 있다.

예컨데, 특정 패턴이 많이 발생하는 상황이 발생하면 이에 대한 상황을 알림으로 보내주어 관리자가 빠르게 상황을 분석하거나 대처할 수 있도록 도울 수 있을 것이다.

더 심층적인 패턴 분석을 제공하는 Winston과 같은 툴도 있다.

알람에는 위에서 분석한 내용 (발생 이유/근거)를 달아주어, 분석에 큰 도움을 줄 수 있다.

모니터링 시스템의 스케일링

극단적인 경우이긴 한데, 트위터와 같이 분당 메트릭이 4 Billion이 넘어가는 상황에서는 기존의 단순한 아키텍처를 사용할 수 없었다. 솔직히 아키텍처 생긴것만 봐서는 이미 아주 무난한 high-throughput 모니터링 시스템 같아 보이는데...

이유는 아래와 같다고 한다.

• 트래픽의 급증 (4B) 및 Alert 10배 이상 증가
• Alert 시스템의 결함 - Alert 설정과 Dashboard 설정의 불일치, 이중 알림 발생

인터페이스 문제 분석 / 개선을 위한 노력

가장 흥미로운 점이 답을 정해놓고 시작하지 않았다는 것이다. 사용자에게 "질문"을 하면서 필요 요소를 찾아나갔다. 페르소나를 만들어서 연구하기도 하였다고 한다.

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

뭐, 이로서 위에서 제시한 문제는 아무튼 잘 해결된 것으로 보인다.

새 아키텍처

보다 비대해진 모니터링 데이터를 처리하기 위한 새 아키텍처에 대한 이야기이다.

대략 대규모 데이터를 담기 위해서 HDFS 구조의 파일시스템 도입, 그리고 분석 행위에 단계를 두어 시간/분마다 배치로 별도의 분석 작업을 수행, Alerting 하도록 한 것으로 보인다.

그리고 클라우드의 상태가 좋지 않은 경우 Alert이 오지 않을 수 있는 문제가 있었는데, Alert system이 위치한 서버의 상태가 좋지 않으면 아예 서버를 이사(Rebalancing)하는 정책을 도입했다. replicate 대신 선택지로 사용했다는 점에서 눈여겨볼만한 것 같다. replicate 하면 alert이 중복으로 와서 client에서 추가 처리를 해줘야 했었다

그리고 Alert의 신속한 전달을 위해서 Rule을 Sharding했다고도 한다.

문제에 대한 성숙한 고민과 접근법, 이를 해결하기 위한 고수준의 아키텍처 제시 그리고 이를 실행할 수 있는 기술력. 역시 빅테크 기업답다.

응대 시스템 재구축

또 상당히 인상깊은 점 중 하나가, 개발을 넘어서 업무 프로세스까지 재정비하는 모습을 보여준 것이다. 어떤 프로젝트를 진행함에 있어 개선이 필요한 분야를 제한되지 않았다는 점이 흥미로웠다.

첫 단계로 Interaction 접점(유저 가이드, 서포트 등) 개선, 두번째로 Documentation (특히 코드레벨 일치) 개선, 세번째로 당번제 도입을 수행하는 방식을 만들었다고 하였다.

이게 제대로 안되면 문제 발생시 고객 대응팀에서 해줄 수 있는 게 없다 보니, 자연스럽게 그 부담이 개발자한테 오롯이 넘어가게 되고, 개발자는 그러면 효율 감소와 함께 의욕을 잃는다.

출처

• Netflix는 어떻게 수 백만 개의 디바이스를 모니터링 하나?
• 트위터는 왜 모니터링을 2번이나 만들었을까? IMQA