CloudWatch
Log & Metrics Collection
- CloudWatch agent container 로 Systemd log와 Custom log를 CloudWatch로 수집합니다.
- Request id, Execution id 등 AWS에서 부여한 UUID들을 기준으로 DB를 설계하고 로그에 포함시켜 Tracing을 용이하게 합니다.
- Subscription filter 기능으로 서비스에서 발생한 중요 로그를 전파합니다.
- EC2, RDS 등의 AWS 서비스에서 기본으로 제공하는 CloudWatch metrics 외에도 Custom metrics를 정의해 관심 대상으로 설정합니다.
Monitoring
- SNS topic에 email subscription 을 추가해 서비스에서 직접 Topic에 메시지를 발송합니다.
- Metric에 Anomaly condition을 정의하고 CloudWatch alarm 을 설정합니다.
- AWS Chatbot Slack App
을 도입해 사내 메신저로 알림을 수신했습니다.
- CloudWatch alarm state 변경 시
- EC2 Instance state change event
EC2 state change event -> EventBridge -> SNS -> AWS ChatBot
- HTTP를 사용하는 서비스의 Status code 모니터링
- CloudFront metrics 의 Error rates
- Lambda function URL metrics 의 4xx, 5xx count
- Naimy 프로젝트 에서는 배포와 운영 이슈 해결을 맡았었습니다. 크롤링 작업에 대한 모니터링 을 구축한 경험을 참조하실 수 있습니다.
Action Items
- 이상 상태가 나타난 시점을 특정하고 가능하다면 이상 상태를 추적할 수 있는 id를 획득합니다.
- CloudWatch log stream을 특정하고 S3, DB, Redis 등의 Storage를 조사해 원인을 파악하고 적절한 조치를 수행합니다.
- 필요한 경우 Lambda versions , Container image digest 등을 이용해 과거 버전으로 서비스를 롤백합니다.
On-Premise
Log & Metrics Collection
- 컨테이너들의 로그를 별도의 설정 없이 통일된 형식으로 수집할 수 있도록
docker compose log를 기본으로 선정했습니다. - 들어온 데이터에 따라서 처리 결과를 개발자와 비개발자가 직접 검증해야 하는 경우에는 Tracing이 용이하도록 입력을 기준으로 UUID를 부여했습니다.
- Sentry SDK 를 주요 서비스에 적용해 오류 원인 파악에 필요한 배경 정보를 수집했습니다.
Monitoring
- 클라우드에서와는 달리, 인프라가 이상 상태를 보일 수 있다는 가정 하에 컨테이너 별 Health check를 보다 꼼꼼하게 작성했습니다.
- Redis 등 핵심 서비스에 대한 Reachability를 확인합니다.
- 작업을 처리하지 않고 대기 상태에 있는 경우 카메라, GPU 등 특수한 하드웨어가 정상 작동하는지 확인합니다.
- 정형화된 형태의 서비스라고 할 수 있는 서버 형태의 번호판 인식 시스템의 모니터링에는 Kibana , Influx DB 를 적용해 각각 로그와 지표를 관리할 수 있도록 했습니다.
- 특수한 환경에서의 모니터링을 위해서 SSH 터널링 기반의 자체 인프라와 툴 을 개발해 2년 이상 꾸준히 유지보수하며 사용했습니다.
Action Items
- autoheal 이라는 컨테이너는 Docker socket을 모니터링해 Unhealthy한 컨테이너를 자동으로 재시작합니다.
docker inspect를 통해 최근 Health check log들을 조회해 원인을 파악합니다.
TODOs
최근 관심을 두고 있는 기술들입니다.