day-log

지난주 화요일 새벽 3시 12분. 폰이 진동했다. PagerDuty다.알림 내용은 단순했다. "checkout-api 50x error rate spike". 처음에는 트래픽 이슈인가 싶었는데, 그래프를 열어보니 패턴이 이상했다. 트래픽은 평소 새벽 수준 그대로인데 5xx만 튀고 있었다. P99 레이턴시도 2초를 넘기고 있었다.결론부터 말하면 Karpenter consolidation 정책을 잘못 건드린 게 원인이었다. WhenEmptyOrUnderutilized를 그대로 두고 consolidateAfter를 30초로 줄였더니, 새벽 트래픽이 잠깐 빠질 때마다 노드가 통째로 갈리면서 stateful한 워크로드들이 같이 흔들렸다.우리가 뭘 바꿨길래며칠 전에 비용 최적화 한답시고 NodePool 설정을 손봤..

지난달에 우리 팀이 운영하던 EKS 클러스터 두 개를 Auto Mode로 갈아탔다. "노드 관리 안 해도 된다", "Karpenter 직접 안 만져도 된다", 이런 얘기 듣고 한 달만에 슬쩍 옮긴 건데, 첫 달 청구서 받고 멘탈이 살짝 나갔다. 결론부터 말하면 망한 건 아니다. 다만 예상하고 옮긴 그림이랑은 꽤 달랐다는 얘기다.어떻게 옮겼나원래 우리 클러스터는 Karpenter 0.37로 NodePool 4개 돌리고 있었다. 일반 워크로드, batch job용 spot, GPU 추론, 그리고 좀 큰 메모리 잡아먹는 streaming consumer용. 인스턴스 타입은 직접 골랐다. m6i.2xlarge, r6i.4xlarge, g5.xlarge 이런 식으로. 한 1년 운영하면서 어떤 패밀리가 어디에 잘 ..

NAT Gateway egress 비용 폭탄 맞고 깨달은 것들지난달 AWS 청구서를 보고 멘탈이 나갔다. NAT Gateway 한 줄에 $4,200. 평소의 3배다. 우리 팀 인프라 전체 비용에서 NAT Gateway가 차지하는 비중이 갑자기 28%까지 치솟았다는 뜻이다.처음엔 누가 큰 데이터셋이라도 외부에 올렸나 싶었다. 근데 트래픽 패턴을 까보니 그게 아니었다. 범인은 ECR이었다. 정확히는, 우리가 6개월 전에 추가한 워커 노드 그룹이 ECR public 이미지를 NAT Gateway 통해서 매번 끌어다 쓰고 있었던 것.처음 본 게 다가 아니었다처음엔 VPC Flow Logs를 켜고 NAT EIP의 destination port를 분석했다. 결과를 보고 좀 당황했는데, 443 트래픽이 전체의 87%..

월요일 아침에 출근하니 재무팀에서 슬랙이 와있었다. "지난달 AWS 비용 한 번만 확인 부탁드려요." 평소엔 무시할 만한 변동이었는데 이번엔 NAT Gateway 라인 하나만 전월 대비 3.2배가 찍혀 있었다. 다른 항목은 거의 그대로였다. 보자마자 멘탈이 살짝 흔들렸다. 우리 팀은 분기 비용 가이드라인이 있어서 한 항목이 갑자기 튀면 그게 곧 회고 거리다.여기에 진단부터 해결까지 일주일 동안 삽질한 기록을 남긴다. 결론부터 말하면 범인은 단순했고, 우리가 그동안 NAT Gateway 트래픽 구성을 너무 안 들여다본 게 진짜 문제였다.첫 번째 가설: 누가 풀데이터를 빨아 가나처음엔 누군가 새 워크로드 띄우면서 외부 데이터셋이라도 받아오는 줄 알았다. 그런데 워크로드 추가된 거 없었다. 노드 수도 그대로(..