아침 7시 40분쯤 메신저에서 긴급이라는 메세지가 보였습니다. 서비스 장애가 생겼다는 메세지였습니다. 출근하기 위해 현관문 앞까지 나갔는데 장애라는 키워드를 보자마자 다시 집에 들어가서 노트북을 열었습니다.
실제 서비스 장애가 있었지만 애플리케이션 에러가 없어 조금 늦게 장애를 발견했습니다. 장애가 난 아키텍처는 아래 그림과 같습니다. 애플리케이션은 스프링부트이고 EKS pod에서 실행되고 있었습니다. 클라이언트는 on premise에 위치하고 EKS pod API를 호출하기 위해 public ALB를 사용합니다.
몇십분이 지나서야 EKS에는 이상이 없는 것을 확인했습니다. 대신 ALB에 메트릭 이상현상이 있었습니다. ALB requests가 어느 순간부터 0이었습니다. ALB설정은 수정을 안했는데 어느 순간 트래픽이 안들어왔습니다. ALB 메트릭이 이상하다고 생각한순간 데이터독에서 트래픽 급감 알람이 울렸습니다. 데이터독은 지난 글에 설명한 것처럼 cloudwatch 실시간 알람을 보장하지 않기 때문에 한참뒤 알람이 울렸습니다.
Datadog cloudwatch 메트릭기반 알람의 주의사항
주의사항Datadog에서 cloudwatch 메트릭기반으로 알람을 설정하면 실시간이 보장이 되지 않습니다. 그 이유를 예제와 함께 살펴보시죠.예제Datadog에서 AWS Cloudwatch ALB메트릭을 기반으로 알람을 설정했
malwareanalysis.tistory.com
그래서 on premise에 문제가 있지 않을까 의심했습니다. 시간이 지나서야 on-premise의 아웃바운드 방화벽에서 트래픽이 차단되는 것을 알았습니다. 많은 on-premise는 아웃바운드 방화벽을 사용하기 때문에 방화벽 설정이 잘못되면 on premise에서 public 불가능합니다.
'회고모음' 카테고리의 다른 글
회고: 시간안에 많은 것을 할 수 없다면 일부는 포기해야 한다(feat: istio 제거) (1) | 2025.06.15 |
---|---|
AWS Certified AI Practitioner (AIF-C01) 취득 (0) | 2025.04.29 |
2025년 4월 기준 요즘 공부하는 것들 (2) | 2025.04.20 |
25년 건강에 대한 회고 - 혼자사는 집에서 기절 3번 (4) | 2025.04.10 |
음.. 약 50시간정도 AWS Site to Site VPN(+BGP) 구축 연습하려다가 실패 (1) | 2025.03.23 |