day-log

배포는 빨라졌는데, 왜 그래프가 자꾸 뻘겋게 되나배포 시간이 오래 걸리는 게 싫어서 ALB target group의 deregistration_delay를 30초까지 내렸다가, 몇 주 동안 배포 때마다 5xx가 조용히 튀는 걸 뒤늦게 알아챈 이야기다. 뭐 그렇게 대단한 사건은 아닌데, 원인이 좀 얄궂어서 기록으로 남긴다.우리 팀은 ECS on EC2로 앱을 굴린다. 배포는 하루에 5~7번, 카나리 없이 rolling update. 처음에는 deregistration_delay=300 (기본값 5분)이었는데, 배포가 뭘 하나만 바꿔도 10분씩 걸리는 게 아까워서 30초로 내렸다. task 자체는 gracefully shutdown 잘 하니까 30초면 넉넉하다고 판단했다.며칠 뒤부터 CloudWatch 대시..

EKS 쓰다 보면 언젠가 한 번은 부딪히는 질문. 파드가 AWS 리소스에 접근할 때 IAM을 어떻게 붙일 것인가. 예전에는 답이 하나였다. IRSA. 근데 몇 년 전 Pod Identity가 나오고, 올해 초 우리 팀은 결국 이걸로 옮겼다. 왜 옮겼는지, 뭐가 좋고 뭐가 애매한지 정리해본다.IRSA는 그동안 잘 써왔는데솔직히 IRSA에 큰 불만은 없었다. OIDC provider 만들어놓고, ServiceAccount에 어노테이션 붙이고, IAM 역할의 trust policy에 그 SA를 넣어주면 끝. 몇 년째 잘 굴러왔다.문제는 클러스터가 늘어나면서 시작됐다. 우리 팀은 dev/staging/prod로 클러스터가 세 개, 여기에 데이터 팀이 요청한 별도 클러스터 하나가 더 붙어서 총 네 개다. 각 클러..

지난 주에 스테이지에서 결국 롤백했다. 프로덕션 붙이기 전에 걸러진 게 다행이라면 다행인데, 나흘을 매달렸으니 후련한 기분은 아니다.발단은 흔한 이유였다. 라이더팀 서비스가 시간대별로 커넥션이 폭주하면서 too many connections 로그를 하루에 몇 십건씩 뱉기 시작했다. Aurora PostgreSQL 15, max_connections 200에 라이더 API 파드가 오토스케일링으로 4개에서 20개까지 오가는 상황. HikariCP maximumPoolSize를 낮춰봐도 임계가 애매하게 겹칠 때는 여전히 튕겼다. AWS 문서에서 "RDS Proxy는 이럴 때 붙이면 된다"라고 아주 자신있게 쓰여있길래, 시니어분과 얘기해서 도입 PoC를 시작했다.붙인 순간, 왜인지 느려졌다붙이고 나서 첫 번째 ..

Kubernetes에 시크릿을 어떻게 넣을지 팀 내부에서 얘기가 몇 번 오갔다. Sealed Secrets는 GitOps랑 궁합이 좋긴 한데 로테이션이 귀찮고, kubectl create secret은 GitOps 원칙에 어긋난다. 결국 우리 팀은 External Secrets Operator(ESO) + AWS Secrets Manager 조합으로 갔다. 6개월 정도 운영해보니 손이 덜 가서 만족스럽다.이 글은 ESO를 처음 도입할 때 필요한 IRSA 설정, ClusterSecretStore/SecretStore 결정, 그리고 실무에서 자주 걸리는 몇 가지 함정을 정리했다. 최근 v0.10 대에서 문법이 조금씩 바뀐 부분도 반영했다.왜 ESO인가간단히 말하면 AWS Secrets Manager를 원본(..

옮기기 전에 체크할 것EKS Pod Identity가 GA된 게 2023년 말이니까 벌써 2년 반쯤 됐다. 처음 나왔을 때는 "굳이 IRSA에서 갈아탈 이유가 있나" 싶었는데, 클러스터 수가 10개를 넘어가면서 OIDC provider를 매번 등록하고 trust policy의 sub 클레임을 클러스터마다 갈아끼우는 게 슬슬 짜증나기 시작했다. 올해 들어 우리 팀도 본격적으로 옮기기 시작했고, 이제 절반쯤 마이그레이션한 상태다.이 글은 "왜 옮겨야 하나"보다는 "어떻게 옮기나"에 집중한다. 결론부터 말하면 한 번에 다 갈아엎을 필요는 없다. 같은 클러스터, 같은 네임스페이스에서 IRSA와 Pod Identity가 공존한다.먼저 마이그레이션을 시작하기 전에 확인해야 할 게 몇 가지 있다.EKS 클러스터 버전..

지난주 화요일 새벽 두 시, 휴대폰이 울렸다. P0 알람. 결제 API의 P99 레이턴시가 1.2초를 넘기고 있었고, 50x 비율이 3분 동안 8%까지 올라갔다 떨어졌다. 잠이 확 깼다.대시보드를 열어보니 노드가 한꺼번에 세 대가 빠지고 있었다. 우리 클러스터는 노드 24대 규모인데, Karpenter consolidation이 동시에 세 대를 cordoning + draining 중이었다. Pod Disruption Budget도 걸어뒀고, terminationGracePeriodSeconds도 충분히 잡아뒀는데도 결제 서비스 두 개 인스턴스가 같은 노드에 몰려 있던 게 문제였다. 새벽 2시는 트래픽이 낮긴 해도 결제는 0이 아니다. 일본/동남아 유저들이 깨어 있다.왜 새벽에 한꺼번에 빠졌나Karpen..

Access Key를 GitHub Secrets에 박아두는 거, 이제 진짜 그만할 때가 됐다. 우리 팀도 작년에 한 번 키가 외부로 새서 식겁한 적이 있는데, 그 사건 이후로 모든 리포지토리를 OIDC로 옮겼다. 사실 옮기는 작업 자체가 어렵진 않다. 어려운 건 신뢰 정책(trust policy)을 너무 느슨하게 잡거나, 반대로 너무 빡빡하게 잡아서 워크플로우가 자꾸 깨지는 거다.이번 글에선 GitHub Actions의 OIDC 토큰으로 AWS IAM Role을 assume하는 과정을 실전 기준으로 정리한다. 처음 세팅하는 사람도 따라할 수 있게 단계별로 적었다.왜 OIDC인가장기 credential(Access Key/Secret Key)을 Secrets에 저장하면 두 가지가 걸린다. 하나는 키가 유출..

Terraform 1.10에서 use_lockfile = true 옵션이 추가됐고, 1.11에 와서는 experimental 딱지가 떨어졌다. DynamoDB 테이블 없이 S3만으로 state lock을 거는 기능이다.처음 봤을 때 솔직히 좀 의심스러웠다. lock 메커니즘이라는 게 결국 "동시에 한 명만 쓰게" 만드는 건데, S3는 object storage고 트랜잭션 같은 게 없는데 어떻게? 그리고 DynamoDB는 강한 일관성(strong consistency)을 보장하는 KV store니까 lock 용도로 충분히 합리적이었다. 굳이 S3로 갈아탈 이유가 있나 싶었다.근데 마이그레이션을 준비하면서 내부를 까보니, 생각보다 깔끔하게 잘 만들어둔 구조였다. 단순히 "DynamoDB를 안 써도 된다"는 ..

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