Design Metric Monitoring & Alert - 장애 대응 시스템을 그냥 로그로만 설계하면 면접에서 왜 감점되는가
메트릭 모니터링 및 알림 시스템을 설계합니다.
확장 가능한 메트릭 모니터링 및 알림 시스템의 설계를 배워봅니다. 잘 설계된 모니터링 및 알림 시스템은 인프라의 상태를 명확하게 보여 주는 가시성을 제공함으로써 높은 가용성과 신뢰성을 보장하는 데 핵심적인 역할을 할 수 있어서 시스템 디자인 인터뷰의 마무리로 잡아준다면 더 점수를 얻을 수 있을 것 입니다.
가장 널리 사용되는 메트릭 모니터링 및 알림 서비스 몇 가지를 보여 줍니다. 빅테크가 내부적으로 사용할 수 있는 유사한 서비스를 설계합니다.
대표적인 메트릭 모니터링 / 알림 서비스들
- Datadog
- InfluxDB
- New Relic
- Nagios
- Prometheus
- Munin
- Grafana
- Graphite1. 문제를 이해하고 설계 범위를 정하기
메트릭 모니터링 및 알림 시스템은 회사마다 전혀 다른 의미를 가질 수 있으므로, 면접관과 먼저 정확한 요구사항을 확실히 정하는 것이 중요하다. 예를 들어, 면접관이 인프라 메트릭만 염두에 두고 있는데 지원자가 웹 서버 에러 로그나 액세스 로그 같은 로그 중심 시스템을 설계해 버리면 곤란하다.
세부 사항으로 들어가기 전에 먼저 문제를 정확히 이해하고 설계 범위를 정해 보자.
지원자
이 시스템은 누구를 위한 것인가요? 페이스북이나 구글 같은 대기업을 위한 사내 시스템을 만드는 건가요, 아니면 Datadog나 Splunk 같은 SaaS 서비스를 설계하는 건가요?
면접관
좋은 질문입니다. 우리는 내부 전용 시스템을 만든다고 가정하겠습니다.
지원자
어떤 메트릭을 수집하길 원하나요?
면접관
운영 시스템 메트릭을 수집하길 원합니다. 여기에는 CPU 부하, 메모리 사용량, 디스크 사용량 같은 운영체제 수준의 저수준 메트릭이 포함될 수 있습니다. 또한 서비스의 초당 요청 수나 웹 풀에서 실행 중인 서버 수 같은 고수준 개념도 포함될 수 있습니다. 비즈니스 메트릭은 이 설계 범위에 포함되지 않습니다.
지원자
이 시스템으로 모니터링할 인프라의 규모는 어느 정도인가요?
면접관
일간 활성 사용자 1억 명, 서버 풀 1,000개, 그리고 각 풀마다 100대의 머신이 있다고 합시다.
지원자
데이터를 얼마나 오래 보관해야 하나요?
면접관
1년 보관한다고 가정합시다.
지원자
장기 저장을 위해 메트릭 데이터의 해상도를 낮춰도 되나요?
면접관
아주 좋은 질문입니다. 새로 유입되는 데이터는 7일 동안 원본 그대로 보관할 수 있기를 바랍니다. 7일 이후에는 30일 동안 1분 단위 해상도로 롤업하고, 30일 이후에는 1시간 단위 해상도로 더 롤업해도 됩니다.
지원자
지원해야 하는 알림 채널은 무엇인가요?
면접관
이메일, 전화, PagerDuty, 또는 웹훅(HTTP 엔드포인트)입니다.
지원자
에러 로그나 액세스 로그 같은 로그도 수집해야 하나요?
면접관
아닙니다.
지원자
분산 시스템 트레이싱도 지원해야 하나요?
면접관
아닙니다.
Functional Requirements - 기능적 요구사항
이제 면접관에게서 요구사항을 충분히 수집했고, 설계 범위도 명확해졌다.
요구사항은 다음과 같다.
모니터링 대상 인프라는 대규모다. 일간 활성 사용자 수는 1억 명이다. 서버 풀은 1,000개이고, 풀마다 100대의 머신이 있으며, 머신당 100개의 메트릭이 있다고 가정하면 총 약 1천만 개의 메트릭이 존재한다. 데이터 보관 기간은 1년이다. 데이터 보관 정책은 원본 형태로 7일, 1분 해상도로 30일, 1시간 해상도로 1년이다.
모니터링할 수 있는 메트릭은 다양하다. 예를 들면 CPU 사용량, 요청 수, 메모리 사용량, 메시지 큐의 메시지 수 등이 있다.
Non-Functional Requirements - 비기능 요구사항
시스템은 증가하는 메트릭 수와 알림 수를 감당할 수 있도록 확장 가능해야 한다. 대시보드와 알림을 위해 낮은 질의 지연 시간이 필요하다. 중요한 알림을 놓치지 않도록 시스템은 매우 높은 신뢰성을 가져야 한다. 기술은 계속 변하므로, 파이프라인은 미래의 새로운 기술을 쉽게 통합할 수 있을 만큼 유연해야 한다.
이 범위에서 제외되는 요구사항도 있다. 로그 모니터링은 범위 밖이다. Elasticsearch, Logstash, Kibana로 구성되는 ELK 스택은 로그 수집과 모니터링에 매우 널리 쓰인다. 분산 시스템 트레이싱도 범위 밖이다. 분산 트레이싱은 서비스 요청이 분산 시스템을 통과하면서 어떻게 흐르는지 추적하는 솔루션을 의미하며, 요청이 한 서비스에서 다른 서비스로 이동할 때의 데이터를 수집한다.