모니터링의 중요성
모니터링?
IT 업무를 하면서 모니터링이라는 용어를 접해보지 않은 사람은 없을 것이다.
사놓기만 하고 아직 제대로 읽어보지 못한 사이트 신뢰성 엔지니어링 에서는 모니터링에 대한 정의를 아래와 같이 말하고 있다.
쿼리의 수와 종류, 에러의 수와 종류, 처리 시간 및 서버의 활동 시간 등 시스템에 대한 정량적 실시간 데이터를 모으고 처리하고 집계해서 보여주는 것을 말한다. (참고: 사이트 신뢰성 엔지니어링. 64p. 제이펍출판사)
필자는 특정 기능에 대한 구현과 전반적인 아키텍처 설계만큼이나 모니터링이 정말로 중요하다고 생각하는데, 이는 자신이 구현하고 관리하는 시스템의 상태를 지속적으로 관찰하고, 문제가 발견될 때마다 능동적으로 대응하는 것은 서비스 운영의 필수 요소라고 생각하기 때문이다.
그렇기 때문에 실력이나 경력을 막론하고 자신이 맡은 서비스와 회사의 전반적인 시스템에 대한 모니터링을 열심히 하는 개발자에게 애정이 큰 편이다. 자기 서비스에 대한 모니터링도 안하는 인간들하고는 같이 일하기 싫은 것이 당연지사
작전의 실패는 용서할 수 있어도, 경계의 실패는 용서할 수 없다 는 더글러스 맥아더의 말이 없더라도.. 모니터링은 너무도 당연하고 중요한 업무가 아니던가?
그런데.. 현실은?
개발자는 항상 바쁘다. 같이 일하는 디자이너와 PO 도 바쁘고 모두 바쁘다. 그리고 일은 항상 많다. 눈 앞의 업무, 이번 스프린트 안에 끝내야 하는 업무, 분기 안에 달성해야 하는 업무 등등을 생각하면.. 일은 항상 많고 바쁜 것이 IT 쪽의 현실이 아닐까 한다.
그래도 쿠팡이나 토스처럼 모니터링 시스템이 이미 잘 구축되어 있고, 이를 전담하는 팀이 별도로 존재한다면 모니터링 구축에 대한 부담은 없기 때문에, 이슈 발생 시마다 모니터링에 기반한 알람을 바탕으로 이슈를 대응하거나, 지속적으로 매트릭의 추이를 관찰하면서 서비스 안정성을 유지하기 위한 next action item 을 도출할 수 있겠지만..
문제는 모니터링의 중요성을 아예 모르거나 현재 일하는 회사에서 모니터링 시스템이 구축되어 있지 않고, 그것을 구축하기에는 리소스가 너무 부족한 상황이 아닐까 한다.
멀리 볼 것도 없이 필자가 19년 8월부터 겪게 되었던 상황이 바로 그 상황이었다. 신규 시스템에서 기능을 구현하고 운영해야 하는 상황이었는데 - 워낙 빠르고 바쁘게 돌아가는 상황 속에서 시스템에 대한 모니터링 구축이 가능한 리소스가 전혀 없었고, 그랬기 때문에 로그 및 메트릭 수집, 이를 기반한 알림이 미흡한 상황이었다.
결국 10월에 성능 이슈와 함께 시스템이 급격히 느려진 때가 있었는데, 메트릭 수집과 모니터링이 있었다면 단숨에 이슈를 잡았거나 이슈 발생 전에 미리 대응이 가능했겠지만 - 그 때는 그게 없었고 조금 긴 시간 후에 원인을 찾아 대응할 수 있었다.
구축에 대한 원칙과 실행 계획
1주일 정도의 리소스를 사용하여 모니터링 시스템을 구축하기로 결정한 후에, 아래와 같은 원칙을 세우고 관련한 stack 을 찾아봤다.
- 널리 쓰이고 검증된 기술을 사용하고 싶다
- 구축과 유지보수에 큰 노력이 들지 않았으면 한다
- 메트릭 수집과 로그 수집, 그것에 기반한 알림 기능이 가능해야 한다.
- 보기에 예뻐야 한다.
예뻐야 자주 본다
그에 따라 이미 적당히 익숙하고 검증된 elastic stack 에 kafka 를 이용한 로그 및 메트릭 수집 을 구축하기로 하였다.
참고로.. AWS 나 google cloud, azure 와 같은 클라우드 기반에서 업무가 가능하다면 당연히 그 쪽의 서비스를 이용했겠지만, 필자가 근무하는 회사는 금융을 다루는 곳이기에 자체적인 서버 내에서 모니터링을 구축해야 하는 상황이었다. (회사 좋아요. 지원 강추)
사실 elastic stack 은 14년부터 지속적으로 사용해왔고, 해당 stack 에 대한 기술적인 지식이 약간은 있었기 때문에 선택에 있어서 크게 고민되는 점은 없었다. 다만, 과거에는 이미 누군가가 만들어놓은 elastic stack 을 활용하면서 모니터링에 참여했었다면, 지금은 내가 나와 동료를 위해 이것을 만들고 사용하고 운영해야 하는 것에서 기존과 다른 차이점이 있었다.
elastic stack & kafka
운영 시스템의 규모와 각 stack 의 특징, 모니터링에 투입 가능한 시스템 자원 등을 고려하여 구상한 전반적인 아키텍처는 아래와 같다.
/elastic_kafka_architecture.png "elasticsearch & kafka Architecture")
| 설치1 | 설치2 | |
|---|---|---|
| 서버1 | zookeeper1 | elasticsearch1 |
| 서버2 | zookeeper2 | elasticsearch2 |
| 서버3 | zookeeper3 | elasticsearch3 |
| 서버4 | zookeeper4 | elasticsearch4 |
| 서버5 | zookeeper5 | kibana |
| 서버6 | kafka1 | logstash1 |
| 서버7 | kafka2 | logstash2 |
| 서버8 | kafka3 | logstash3 |
서버 사양은 모두 cpu: 8 core / mem: 8G / disk: SSD 30G
구성의 근거
비교적 적은 리소스로 메트릭과 로그 수집이 가능한 시스템을 만들고 싶지만, 카프카 클러스터의 복제(replication)와 브로커 서버들의 물리적인 위치를 고려하면서 구축하는 수준은 고려하지 않았다. 추후 확장이 필요한 상황이 생긴다면 그 때 처리하는 것으로…
시스템에 할당된 리소스마다 다르겠지만 해당 구성에서 초당 800여건 / 분당 5만여건의 메시지를 무리없이 처리하는 것을 확인하였다. 현재는 그 이상의 메시지 처리를 받을 일은 없기 때문에 적절한 수준의 성능이라고 생각하고 있다.
zookeeper
주키퍼의 클러스터를 앙상블(ensemble) 이라고 하며, 하나의 앙상블은 여러 개의 서버(노드)를 맴버로 가질 수 있다. 주키퍼 앙상블은 다섯 개의 서버 노드로 구성하는 것을 추천한다. 그 이유는 다음과 같다.
앙상블의 구성을 변경(ex. 노드 교체) 하려면 한 번에 하나의 서버 노드를 중단했다가 다시 로딩해야 한다. 그러나 만일 하나 이상의 노드를 중단할 수 없는 앙상블이라면 유지보수 작업에 위험이 따르게 된다.
그리고 서버가 너무 많으면 오히려 성능이 저하될 수 있으므로 노드를 다섯 개보다 많게 구성하는 것은 바람직하지 않다. (참고: 카프카 핵심 가이드. 22p. 제이펍출판사)
kafka
카프카의 브로커 및 파티션 개수 산정은 당연히 단위 시간당 메시지 처리량을 고려하여 산정되어야 한다. 허나 시스템의 전반적인 메시지 처리량에 대한 예측이 어렵다면 우선은 메트릭과 로그 수집에 대한 시스템을 구축하여 사용하면서, 필요 시 브로커의 수를 늘리는 것도 방법이 될 수 있다. (클러스터에 브로커를 추가하는 것은 전혀 어려운 것이 아니기 때문에)
하나의 카프카 서버로도 잘 동작할 수 있지만, 다수의 브로커로 하나의 클러스터를 구성하면 장점이 많다. 다수의 서버로 처리량을 분산시켜 확장할 수 있고, 각 서버의 장애에 따른 데이터 유실을 막기 위해 복제(replication)를 사용 할 수도 있다. 복제를 사용하면 현재 사용 중인 카프카 시스템을 중단시키지 않고 유지보수 작업을 수행할 수도 있다.
필자의 경우는 큰 고민 없이 브로커 3개를 하나의 클러스터로 구성하였다.
elasticsearch
엘라스틱서치에 관한 설치와 설정은 엘라스틱서치에서 일하고 계신 김종민님의 블로그 를 적극 활용하였다. 엘라스틱서치의 경우는 구글링하면 공식 사이트와 여러 곳에서 다양한 인사이트를 쉽게 얻을 수 있기 때문에 마음만 먹으면 쉽게 활용이 가능하다고 생각한다.
필자의 경우는 김종민님의 블로그의 내용 그대로 - 3개의 데이터 전용 노드, 1개의 마스터 전용 노드로 클러스터를 구성하였다.
다음 포스팅부터는 실제의 설치와 구성에 대해 이야기하겠다.
