day-log

EKS Auto Mode 실전 도입 가이드

EKS Auto Mode가 나온 지 1년 반쯤 됐다. 초기엔 "AWS가 Karpenter 위에 껍데기 하나 씌운 거 아냐?"라는 반응이 많았는데, 올해 초부터 zonal shift, EFA 지원, CloudWatch 로깅까지 붙으면서 이제 진지하게 검토해볼 만한 옵션이 됐다.우리 팀도 얼마 전에 스테이징 클러스터 하나를 Auto Mode로 옮겼다. 이 글은 그 과정에서 정리한 내용이다. "왜 쓰는지" 같은 마케팅 얘기는 최대한 빼고, 실제로 뭘 바꿔야 하고 뭘 조심해야 하는지에 집중한다.뭘 대신 관리해주는지부터Auto Mode를 켜면 AWS가 아래를 관리한다.컴퓨트: Managed Node Group 대신 Karpenter가 노드를 띄운다. AMI는 Bottlerocket 고정, 21일마다 강제 재활용네..

지난주에 인프라 비용 리뷰가 있었다. 평소 같으면 EC2랑 NAT Gateway 위주로 훑고 지나갔을 자리인데, 이번엔 AWS Secrets Manager 라인이 유난히 눈에 띄었다. 전월 대비 4배. 절대 금액이 큰 건 아닌데(정확히는 $180 정도), 갑자기 4배가 뛴 게 이상해서 파보다가 며칠 날렸다.결론부터 말하면 범인은 External Secrets Operator였다. 정확히는 ExternalSecret 리소스에 박아둔 refreshInterval: 15s.왜 15초로 뒀었나원래 이 값은 팀에서 붙인 게 아니고, 초창기에 ESO를 도입한 사람이 "빠르게 반영되면 좋겠지" 하고 넣어둔 걸 아무도 안 건드린 채 굴러왔다. 몇 년 지나면서 ExternalSecret 개수도 슬금슬금 늘어서 지금 확인..

지난주 금요일 저녁, 슬랙에서 얼굴이 화끈거리는 알림이 하나 왔다. "누가 지금 prod 계정에 terraform apply 돌리고 있어요?" 확인해 보니 아무도 돌리고 있지 않았다. 근데 state lock은 걸려 있었다. terraform-state-lock DynamoDB 테이블에 유령 락 하나가 남아 있었던 거다. 이런 걸 마주칠 때마다 매번 force-unlock으로 때웠는데, 이번엔 좀 다르게 해결해보고 싶었다. 마침 팀 내부에서 "DynamoDB 이거 언제까지 붙이고 있을 거냐"는 얘기가 몇 주째 돌고 있었고, Terraform 1.11에서 S3 네이티브 락킹이 GA로 승격된 지도 꽤 됐다.그동안 DynamoDB가 왜 있었나우리 팀 backend 설정은 5년 넘게 이 모양이었다.terrafo..

왜 OIDC인가 — 30초 요약한동안 "AWS Access Key를 Secrets에 넣지 마세요"가 마치 mantra처럼 돌았다. 대안은 오래전부터 있었다. GitHub Actions의 OIDC 토큰을 AWS IAM Role의 web identity federation으로 교환하는 방식. 우리 팀도 재작년쯤 다 옮겼는데, 최근 이걸 다시 손 볼 일이 생겼다. 2026년 4월과 7월에 걸쳐 GitHub가 OIDC 토큰의 sub 클레임 포맷을 immutable ID 기반으로 바꿨기 때문이다. 새로 만드는 리포는 자동으로 새 포맷을 쓴다. 기존에 잘 돌던 IAM trust policy가 새 리포에서는 안 붙는다는 얘기다.이 글은 처음 세팅하는 사람과, 이미 쓰고 있지만 최근 트러스트 정책이 실패한 사람 둘 다..

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

시크릿 관리 도구 얘기가 나오면 늘 "그거 Vault로 하면 되잖아요" 아니면 "AWS 쓰면 Secrets Manager가 편하지" 두 진영으로 갈린다. 우리 팀도 작년까지는 그랬다. 지금은? 둘 다 쓴다. 하이브리드로 굴러가는 지 반 년쯤 됐고, 나름 안정화됐다. 그 과정에서 알게 된 것들을 정리한다.작년 초 IBM이 HashiCorp을 인수하면서 Vault Enterprise 라이선스 정책이 조금씩 바뀌기 시작했다. 우리는 커뮤니티 에디션을 쓰고 있었지만, 로드맵이 IBM 포트폴리오와 얽히기 시작한 게 살짝 불안하긴 했다. 그렇다고 AWS Secrets Manager로 다 옮기자니 우리 워크로드가 AWS 온리도 아니었다. 온프렘 DB가 아직 남아있고, GCP에도 워크로드가 조금 있다.각각의 강점, 실..

지난 화요일 밤이었다. 정확히는 수요일 새벽 2시 40분. 폰이 진동했고, 나는 다음날 반차를 쓸까 진지하게 고민 중이었다.Karpenter를 도입한 지 4개월쯤 됐다. 처음에는 얌전하게 consolidationPolicy: WhenEmpty로 돌렸는데, 팀 내부에서 "이럴 거면 왜 Karpenter 썼냐"는 얘기가 슬슬 나왔다. 우리 EKS 클러스터는 노드 30대 규모, 대부분 m6i 계열이었고 야간에는 40% 정도 놀고 있었다. AWS 비용 리뷰에서 매번 얻어맞다 보니 결국 이번 분기에 WhenEmptyOrUnderutilized로 넘어가기로 했다. Karpenter 문서에 최근 이게 코스트 민감한 팀의 기본값이라고까지 적혀 있었으니 뭐 걱정할 게 있겠나 싶었다.그날 새벽에 걸린 알람은 Payment..

지난주 새벽에 겪은 이야기다. 프로덕션 EKS 두 개 중 한 쪽에서 신규 파드가 시크릿을 못 읽는다는 알림이 왔다. 처음엔 대수롭지 않게 봤는데, 결국 External Secrets Operator(ESO) 전체 sync가 멈춰 있는 상태였다. 우리 팀이 ESO를 IRSA + AWS Secrets Manager 조합으로 3년 넘게 쓰고 있는데, 이런 식으로 죽는 건 처음이었다.증상은 조용했다관측 가능한 신호가 애매했다. kubectl get externalsecret -A 를 찍으면 상태는 죄다 SecretSyncedError 였다. 근데 컨트롤러 파드는 살아 있고, CPU도 정상이고, 리더 election 로그도 잘 남고 있었다. Prometheus에서 externalsecret_sync_calls_e..

Karpenter 얘기는 이제 새롭지 않다. AWS re:Invent 때마다 나오고, 트위터에서도 마이그레이션 후기가 쏟아진다. 얼마 전 Salesforce가 1,000개 넘는 EKS 클러스터를 Karpenter로 옮겼다는 소식도 있었고. 그런데 우리 팀은 좀 늦게 결정한 편이다. 작년에 Cluster Autoscaler(이하 CA)에서 Karpenter로 넘겼고, 반년 정도 운영해봤다. 결론부터 말하면 이득은 있었다. 다만 처음 예상했던 이유들과는 조금 달랐다.왜 넘어갔나원래 이유는 명확했다. 노드 스케일링이 느리다. CA는 ASG 기반이라 unschedulable 파드가 생기면 → CA가 감지 → ASG desired capacity 조정 → EC2 프로비저닝 → kubelet join. 이 사이클이..

지난주에 몇 년 방치된 AWS 계정 정리를 맡았다. 상태 파일이랑 실물 리소스가 서로 다른 우주에 있는 그런 계정. 늘 하던 대로 콘솔에서 목록 뽑아서 `terraform import`를 한 줄씩 돌리려다가 옆 팀 시니어가 "요즘 그거 안 써도 돼요, `terraform query` 있잖아요" 하길래 처음 알았다. 지난해 11월 GA된 Terraform 1.14 신규 기능인데, 소문만 들었지 실제로 안 써봤었다. 써보고 나서 후회했다. 이거 진작에 알았어야 했다.`.tfquery.hcl`이 하는 일이름 그대로 새로운 파일 타입이다. 확장자가 `.tfquery.hcl`이어야 인식한다. 안에는 `list` 블록이 들어간다. import 블록이 "이 리소스를 상태로 끌어와줘"라면, list 블록은 "일단 계정..