day-log

지난주에 롤링 업데이트 도중 5분 동안 502가 쭉쭉 떨어졌다. 트래픽 피크 시간대였고, 알림 채널이 몇 초 간격으로 울렸다. 새벽도 아닌 오후 3시였는데, 오히려 그게 더 뼈아팠다. 다들 사무실에 있었으니까.우리 팀은 EKS 위에 AWS Load Balancer Controller로 ALB를 붙여서 쓴다. 노드 24대, 파드 수는 서비스마다 다르지만 문제가 된 서비스는 파드 12개짜리였다. 배포 스크립트도 평범한 Deployment 롤링 업데이트, maxSurge: 25%, maxUnavailable: 0. 이론적으로는 무중단이어야 하는데, 현실은 그렇지 않았다.처음 의심한 건 헬스체크였다로그를 열어보니 502가 뜬 요청들은 전부 upstream connect error 계열이었다. ALB는 살아있다고..

오늘 알게 된 건데, 의외로 모르는 분 꽤 많더라. Pod의 graceful shutdown 늘리려고 PreStop hook에 sleep 박는 그 패턴 말이다. 우리도 한참 그렇게 썼는데, 사실 1.29부터는 그럴 필요가 없어졌다.기존 방식의 함정전형적인 zero-downtime 배포 트릭이다. Service에서 endpoint가 빠지는 동안에도 잠깐 트래픽이 계속 들어오니까, SIGTERM 받기 전에 몇 초 버텨주자는 거다.lifecycle: preStop: exec: command: ["/bin/sh", "-c", "sleep 10"]근데 이거 distroless 이미지 쓰는 순간 깨진다. sh도 없고 sleep도 없으니까. 우리 팀은 작년에 보안팀이 모든 이미지를 distroless..

지난주 화요일 오전이었다. 평소처럼 백오피스 서비스 배포를 돌렸는데, 운영팀 슬랙에 "1분쯤 전에 잠깐 페이지가 안 떴어요"라는 메시지가 떴다. 처음 듣는 얘기는 아니다. 사실 우리 팀에서는 배포할 때 5xx가 한두 건 튀는 걸 그냥 "Kubernetes의 미세한 빈틈"이라고 부르며 넘기고 있었다. 근데 이번엔 운영팀 화면에 명확히 보일 정도로 길었다는 게 문제였다.Grafana로 들어가서 Ingress 컨트롤러의 5xx 그래프를 봤다. 배포 시점에 503이 약 7초간 spike. 평소에는 1초 미만이었는데 이번엔 길었다. 우리 환경은 EKS 1.32, NGINX Ingress Controller, replicas 6짜리 평범한 Deployment. 이쯤이면 "또 종료 시퀀스 문제겠지" 싶었지만, 막상 ..