들어가는 말
안녕하세요.
주식회사 스푼 라디오에서 데브옵스 엔지니어 역할을 맡고 있는 Paschal(김현)입니다.
모니터링 시스템은 안정적인 서비스 운영과 신속한 서비스 전개를 위한 전제 조건입니다.
가장 이상적인 상황은 장애를 만들지 않는 것이지만 사용자가 많고 트래픽 규모가 크고 복잡한 비지니스 로직의 서비스일 수록 장애가 여러 포인트에서 발생할 수 밖에 없습니다.
따라서 장애가 발생하지 않도록 하는 것도 중요하지만 장애가 발생했을때 이를 빨리 감지하고 신속히 장애 대응을 하는 것이 매우 중요합니다.
이렇듯 안정적인 서비스 운영의 근간이 되는 모니터링 시스템 구축을 위해서 스푼 라디오에서는 어떤 고민을 했는지에 대해 말씀드리고자 합니다.
아울러 스푼 서비스 특성 및 서비스 구조에 따른 요구사항 정리 과정과 실제 구축시 문제가 되었던 사항들에 대해 회고해 보도록 하겠습니다.
지금까지는
현재 스푼라디오 서비스 모니터링은 아래 세가지의 모니터링 솔루션으로 파편화 되어 있습니다.
- New Relic : AWS 클라우드 인프라 모니터링, Alert, APM, AWS Log
- Zabbix : 중요 서비스 메트릭 모니터링, Alert
- InfluxDB/Grafana : 서비스 커스텀 메트릭 모니터링
기존의 모니터링 시스템을 사용성 측면에서 보면 인프라 모니터링을 하기 위해서 여러 솔루션의 다중 대쉬보드를 일일히 확인해야 하는 번거로움이 있습니다.
그리고 관리적인 측면에서도 다중 메트릭 저장소(New Relic, Zabbix/MySQL, InfluxDB) 와 다중 솔루션 및 모니터링 서버들에 대한 유지 보수 부담이 있습니다.
따라서 하나의 대쉬보드 시스템으로 통합 모니터링이 가능하고 파편화된 메트릭 저장소를 통합하여 유지 보수가 용이한 모니터링 시스템이 필요하게 되었습니다.
부수적으로 라이선스 비용이 꽤 드는 New Relic을 대체함으로써 비용 절감 효과에 대한 기대도 있습니다.
모니터링 시스템 요구 사항
스푼라디오 서비스는 AWS 클라우드상에서 6개 국가를 대상으로 서비스를 하기 때문에Multi-Country, Multi-Account, Multi-Region 환경을 고려해야 합니다.
또한 아직까지는 EC2 인스턴스 기반의 legacy 서비스가 많은 특징도 있습니다.
이러한 스푼라디오 서비스 특성을 고려하여 아래와 같은 모니터링 시스템 요구 사항을 정리해 보았습니다.
- 여러 국가(Multi-Account, Multi-Region)를 하나의 모니터링 시스템으로 통합 모니터링 할 수 있어야 한다.
- 메트릭 저장소를 한 곳으로 모아서 통합 관리 및 분석 할 수 있어야 한다.
- AWS CloudWatch 통합이 가능해야 한다.
- Dashboard에서 여러 국가의 지표를 통합하여 모니터링 할 수 있어야 한다.
- 서비스 구조 변경에 유연하게 대응할 수 있어야 한다.
- 모니터링 시스템에 대한 관리가 용이해야 한다.
- HA, Scale 하면 좋음.
요구사항에 맞는 여러 모니터링 시스템 구성을 검토하면서 legacy 시스템이 많고 적은 인원으로 관리해야 하기 때문에 가능한 관리형 서비스를 이용한 단순한 구조에 중점을 두었습니다.
결국은 데이타 저장소는 Cloudwatch로 통합하고 이를 Grafana를 통해 Dashboard를 구성하는 것이 가장 효율적이지 않냐는 의견이 우세했습니다.
아래와 같이 AWS Cloudwatch + Grafana 의 단순한 조합의 장점과 단점에 대한 검토를 거쳐 현 단계에서는 가장 합리적인 선택으로 결론을 내었습니다.
Pros
- 요구 사항 만족
- 여러 국가(Multi-Account, Multi-Region)를 하나의 모니터링 시스템으로 통합 모니터링 할 수 있어야 한다.
=> CloudWatch + Grafana 의 조합으로 통합 모니터링 가능 - 메트릭 저장소를 한 곳으로 모아서 통합 관리 및 분석 할 수 있어야 한다.
- AWS CloudWatch 통합이 가능해야 한다.
=> CloudWatch 로 메트릭 저장소 통합 관리 - Dashboard에서 여러 국가의 지표를 통합하여 모니터링 할 수 있어야 한다.
=> Grafana Dashboard 로 구성 가능 - 서비스 구조 변경에 유연하게 대응할 수 있어야 한다.
=> Cloudwatch 메트릭 이외의 메트릭 수집이 필요한 경우 별도의 모니터링 솔루션을 추가하는데 어려움이 없으며 다른 모니터링 시스템으로의 마이그레이션 작업도 용이함. - HA, Scale 하면 좋음
=> Grafana 클러스터링 구성
2. 빠른 Deploy 가능
- 기존 Cloudwatch metric을 Grafana Dashboard 로 시각화하는 작업이외에 추가 작업 없음.
3. 관리 포인트가 적다
- 메트릭 저장소를 Cloudwatch로 하기 때문에 Grafana 서비스관련 인스턴스만 관리하면 된다.
4. 비용
- Cloudwatch 관련 추가 비용이외의 Extra비용(라이선스비) 없음.
Cons
- Custom Metric이 많아질 수록 비용이 많이 든다.
- Cloudwatch 메트릭 데이터는 15개월까지만 저장
=> 별도의 백업 필요 - Grafana alarm 관련해서는 클러스터링은 되지만 모든 grafana서버에서 중복 실행이 된다.
중복실행이 되어도 동일한 내용의 alert에 대해서는 1번만 alarm 가능.
비용 문제가 있음
=> alarm 서버는 별도로 분리하고 별도 모니터링 필요. - AWS Dependency로 인하여 멀티 클라우드 및 하이브리드 모니터링이 어렵다.
=> 이를 위해서는 하이브리드 모니터링 솔루션을 추가로 도입해야 한다.
다음장에서는 Cloudwatch + Grafana 조합의 모니터링 시스템을 구축하고 이를 실무에 적용하면서 겪었던 다양한 경험에 대해 이야기 해보고자 합니다.
Cloudwatch + Grafana 모니터링 시스템 구축
AWS에서 기본적으로 제공하는 메트릭외에 EC2 Node에 대한 커스텀 메트릭(CPU,Memory,FileSystem,Docker Metric등등)은 Telegraf Agent를 사용했습니다.
Telegraf Agent로 커스텀 메트릭을 수집하고 Cloudwatch에 저장하는 방식입니다.
전체적인 구성도는 대략 아래와 같이 단순한 구조입니다.
단순한 구조이기 때문에 구축자체는 크게 어려운점이 없었지만 구축 과정에서 이슈가 되었던 사항은 대부분 AWS Cloudwatch의 제한 조건에 대한 것이었습니다.
따라서 제가 겪었던 Cloudwatch 제한 사항을 극복 혹은 회피하는 과정을 소개하고자 합니다.
참고) AWS CloudWatch Limitations, AWS CloudWatch 비용
- AWS Cloudwatch Data Source 인증은 AWS Key 방식이 좋다.
AWS key를 발급하는 것은 보안상 좋지 않기 때문에 처음에는 Role 인증 방식을 선택했습니다.
그러나 Role 인증 방식의 경우 Cloudwatch 접속 인증에 시간이 오래 걸리는 단점(길게는 30초) 이 있습니다.
때문에 AWS Key 인증 방식을 사용해야만 했습니다.
2. Cloudwatch GetDataMetric API Request는 1024 Byte를 넘어서는 안된다.
GetMetricData API Request 사이즈가 1024 Byte를 넘는 경우는 여러개의 인스턴스에 대한 메트릭을 한꺼번에 호출하는 경우입니다.
Grafana에서 EC2 인스턴스를 template variable로 구성을 해서 사용을 했는데 인스턴스 갯수를 많이 선택할 경우 발생을 했었습니다.
Grafana Template Variable을 사용하여 EC2 인스턴스를 멀티로 선택했을때 실제 Grafana에서 Cloudwatch query는 아래와 같은 포맷으로 실행됩니다.
REMOVE_EMPTY(SEARCH(‘{AWS/EC2,”InstanceId”} MetricName=”CPUUtilization” “InstanceId”=(“i-00xxxxxxxxxxxx” OR “i-007yyyyyyyyyyyyyyy” OR “i-009zzzzzzzzzzzzz” OR :i-xxxxxxxxxx)’, ‘Average’, 60))
Grafana에서 GetMetricData API를 호출할때 위와 같이 선택된 EC2 인스턴스 id를 모두 인수로 넘겨주기 때문에 인스턴스 갯수가 많아 지면 1024 바이트를 넘겨 되어 Grafana에서는 아래와 같이 에러가 표시됩니다.
이런 경우를 피하려면 template variable에서 전체를 선택하는 “*”를 설정하여 사용하거나 EC2 인스턴스 선택 갯수를 줄이는 방법이 있기는 합니다.
보다 근본적인 해결책으로는 모니터링 대상의 EC2 인스턴스를 여러 군으로 분류하여 메트릭 조회를 분산 실행하는 방식이 좋습니다.
예를 들면 API,Batch..등등의 서비스 군으로 분류하여 서비스별 Grafana Panel을 구성하면 서비스별 모니터링하기도 좋고 Cloudwatch query가 분산되는 효과가 있습니다.
3. GetMetricData API의 DPS(Data Point per Second) throttling
Cloudwatch query시 초당 처리할 수 있는 data point 갯수가 500개로 제한되어 있으며 변경이 어렵습니다.
변경을 요청하더라도 실제 throttling 발생 이력이 있어야 하고 서비스 쿼터를 요구한 대로 늘려 주지 않으며 늘려주는 폭도 제한이 있습니다.
따라서 한꺼번에 많은 Data point query를 하지 않도록 해야 하는데 모니터링 메트릭 period를 늘려서 data point를 줄여서 Query를 해야할 경우가 있습니다.
(예를 들면 60초 주기에서 5분주기로 변경하거나 Query 시간 범위를 줄여서 query)
이 문제 역시 EC2 인스턴스를 여러 군으로 분류하여 메트릭 조회를 분산 실행하는 방식으로 어느 정도 문제점을 해소할 수 있습니다.
4. PutMetricData API의 call count throttling
커스텀 메트릭을 사용하는 경우 PutMetricData API는 150건의 초당 트랜잭션(TPS) 까지만 처리가 됩니다.
트랙잭션 제한을 넘어서는 PutMetricData API는 실패하기 때문에 과도한 메트릭 수집은 지양하는 것이 좋습니다.
할당량 증가를 요청할 수는 있지만 API 호출 비용이 만만치 않습니다.
예를 들어 1달(30일) 기준 PutMetricData API 제한 사항인 150 TPS를 사용할 경우 $3,888의 추가 비용이 발생합니다.150/1000*0.01*3600*24*30 = $3,888
아래 그림은 50여대의 EC2 인스턴스에서 메트릭 수집 주기인 10초마다 100여개의 커스텀 메트릭을 Cloudwatch에 저장하면서 150 TPS 제한 조건을 넘어서는 경우입니다.
그림의 수치만으로 계산하면 90 TPS근방으로 보이지만 아마도 Maximum값으로는 150 TPS를 넘는 상황인 것으로 보입니다.
(Maximum값에 대한 PutMetricData API call count 는 확인할 방법이 없었습니다.)
실제 프로덕션에 적용할 때에는 불필요한 커스텀 메트릭은 수집을 하지 않고 Cloudwatch 저장 주기도 10초->1분으로 변경을 했고 PutMetricData API를 호출하는 시간도 겹치지 않도록 설정을 하였습니다.
결론
지금까지 Cloudwatch기반의 모니터링 시스템 구축시 문제가 되는 사항들에 대해 살펴 보았는데 이러한 제한 사항들을 해결하기 위한 방안을 다시 정리해 보면 아래와 같습니다.
- Cloudwatch Data Source인증은 AWS 키를 사용하는 것이 좋습니다.
- EC2 인스턴스를 서비스 군으로 분류하여 Cloudwatch Query(GetMetricData)를 분산 실행하는 구조로 가는 것이 좋습니다.
- 커스텀 메트릭을 적용할 경우에도 CloudWatch의 Namespace를 서비스 별로 여러개로 정의하여 Cloudwatch Query를 분산 실행하는 구조로 가는 것이 좋습니다.
- 커스텀 메트릭의 경우 Cloudwatch 비용에 대한 부담이 있기 때문에 꼭 필요한 메트릭을 선별적으로 수집하는 것이 좋습니다.
현재의 단순한 모니터링 시스템은 당면한 문제점을 해소하는데 중점을 두었기 때문에 최종적인 모니터링 시스템 구조는 아닙니다.
현재의 모니터링 시스템을 구성하기 까지 다양한 모니터링 솔루션에 대한 검토가 있었고 향후의 모니터링 시스템으로의 확장성까지 고려한 기술 검토가 있었습니다.
서비스 구조가 현재의 Legacy한 구조에서 모두 컨테이너 기반으로 변경됨에 따라 조금은 더 복잡한 형태의 모니터링 시스템 구축 계획이 있고 부가적인 모니터링 기능도 추가할 예정입니다.
다음에는 이러한 주제로 다시 찾아 뵙도록 하겠습니다.
