day-log

작년 말 GA 된 EKS Auto Mode를 우리 팀도 새 클러스터에 적용했다. 몇 주 굴려보고 운영에서 부딪힌 부분들이 꽤 있어서, 도입을 고민하는 분들에게 도움이 될 만한 실무 가이드를 정리했다. 마케팅 문구가 아닌 "현실에서 뭐가 좋고 뭐가 아픈가" 관점이다.처음 듣는 분을 위해 간단히 설명하면, EKS Auto Mode는 컴퓨트(노드), 네트워킹(VPC CNI/로드밸런서), 스토리지(EBS CSI), Karpenter, Pod Identity Agent 같은 클러스터 구성요소를 AWS가 관리형으로 묶어서 제공하는 모드다. 우리가 직접 Helm chart를 깔고 IRSA를 매핑하던 작업이 거의 사라진다. 대신 자유도는 줄어든다.1. 사전 준비: 우리 클러스터가 적합한가도입 전에 다음 체크리스트를 먼..

ALB의 gRPC 지원은 꽤 알려져 있다. Target group protocol version을 GRPC로 바꾸고, health check 경로를 /grpc.health.v1.Health/Check로 잡으면 끝. 근데 사내에서 ALB를 안 쓰고 NLB로 가야 하는 상황이 생긴다. 클라이언트가 mTLS를 끝단까지 가져가야 하거나, ALB로는 못 받는 별난 트래픽이 섞여 있거나, 비용 문제거나.이 글은 그 NLB + gRPC 조합에서 우리 팀이 며칠 헤맨 얘기를 정리한 거다. 결론부터 말하면 ALPN 정책 한 줄이 빠지면 TLS handshake는 되는데 gRPC만 안 된다. 로그도 별 게 안 남는다.NLB가 gRPC를 "지원"한다는 말의 의미NLB는 L4다. HTTP/2 프레임을 해석하지 않는다. 그래서..

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

처음에 의심한 것들지난주 새벽 2시 반에 알람이 울렸다. P99 레이턴시 알람이었는데, 한두 번이면 그냥 무시하고 자고 다음 날 보겠지만 같은 알람이 5분 간격으로 계속 울렸다. 누워서 폰만 보다가 결국 노트북을 열었다.원인은 Karpenter였다. v1.0으로 올리고 한 달 정도 됐는데, 이 시점에 처음으로 큰 사고가 터졌다. 자려고 누웠다가 새벽 5시까지 깨어 있었던 그 밤 이야기를 정리해두려고 한다.알람이 P99 latency였으니까 당연히 애플리케이션을 먼저 봤다. 그런데 백엔드 트레이스를 까보니 응답 자체는 빠른데, 가끔 한 노드의 모든 파드가 동시에 사라지는 패턴이 보였다. terminated 이벤트가 5분에 한 번씩 떴다.처음엔 spot interruption인 줄 알았다. 우리 서비스 노드..

작년에 신규 EKS 클러스터를 띄우면서 한 가지 결정을 미뤘다. 워크로드 IAM을 IRSA로 갈지 Pod Identity로 갈지. 그때는 "어차피 둘 다 지원되니까 나중에 보자"고 미뤘는데, 올해 들어 클러스터가 4개로 늘어나면서 더는 미룰 수 없는 상태가 됐다.지난 두 달 동안 stage 환경 전체를 Pod Identity로 옮겨보고, prod의 일부 워크로드도 마이그레이션을 시작했다. 결론부터 말하면 우리 팀은 신규 워크로드는 전부 Pod Identity로, 기존 IRSA는 천천히 전환 중이다. 왜 그런 결정을 했는지, 어떤 케이스에서는 IRSA가 더 나았는지 정리해본다.비교의 배경: 우리는 어떤 환경이었나먼저 우리 팀 환경을 짧게 적어둔다. 비교 결과는 환경에 따라 다르게 읽힐 수 있어서다.EKS ..

처음에 기대했던 것작년 가을, 우리 팀은 VPC를 5개 운영 중이었다. 메인 워크로드 VPC, 데이터 분석 VPC, 사내 도구 VPC, 보안 격리 VPC, 그리고 신규 사업 VPC. 각 VPC끼리 서비스를 호출해야 하는 케이스가 슬슬 늘어나면서 PrivateLink와 Transit Gateway가 거미줄처럼 얽혀 있었다. 어떤 서비스가 어디에 노출돼 있는지 추적하는 게 자체로 일이었다. 이 시점에 VPC Lattice를 도입하기로 결정했고, 지금은 약 6개월째 운영 중이다. 잘한 결정인지 묻는다면 솔직히 반반이다.이 글은 칭찬도 비판도 섞인 후기다. 도입을 검토 중인 분이라면 좀 도움이 될 것 같다.마케팅 페이지만 보면 정말 끌린다. VPC끼리 서비스를 노출하는데 NLB나 PrivateLink Endpo..

작년 KubeCon Salt Lake City 끝나고 팀에서 한참 얘기가 나왔던 게 EKS Pod Identity였다. 우리 팀은 그동안 IRSA(IAM Roles for Service Accounts)를 잘 쓰고 있었는데, 클러스터를 4개 운영하다 보니 OIDC provider를 클러스터마다 다 등록하고, 신뢰 정책에 sub 조건을 박아놓는 방식이 점점 귀찮아졌다. 멀티 클러스터 환경에서 같은 워크로드에 같은 권한을 주려면 클러스터마다 trust policy를 다르게 써야 했고, 새 클러스터를 띄울 때마다 이걸 반복했다.그래서 최근 2주에 걸쳐 dev → staging 클러스터를 차례로 Pod Identity로 옮겼다. prod는 다음 주 작업 예정이다. 이 글은 그 작업을 정리한 가이드다. 이미 운영..

월말마다 AWS 비용 리포트 보다가 NAT Gateway 항목에서 한숨 쉬어본 적 있다면 이 글이 도움이 될지도 모르겠다. 우리 팀도 작년에 비슷한 상황이었고, VPC Endpoint 몇 개 깔아둔 것만으로 NAT 처리 비용이 한 달 기준 40% 가까이 빠졌다. 거창한 아키텍처 변경 없이.이번 4월 AWS 비용 가이드들을 다시 훑어봤는데 NAT Gateway 단가는 여전히 시간당 $0.045, GB당 $0.045다. 게이트웨이 하나 띄워놓으면 가만히 있어도 월 $32. 거기에 처리량까지 붙으니 트래픽 많은 클러스터는 NAT 항목 하나가 인스턴스 비용을 추월하는 일도 흔하다. 이 글은 그 비용을 내리는 가장 확실한 방법인 VPC Endpoint 적용 가이드다.어디부터 손대야 하나VPC Endpoint는 두..

AWS EC2 Spot 인스턴스 비용 확인하기: 클라우드 비용 최적화의 첫걸음 AWS EC2 Spot 인스턴스는 고정적인 작업에는 적합하지 않을 수 있지만, 일정 유연성이 허용되는 워크로드에는 탁월한 비용 절감 효과를 제공합니다. 그러나 Spot 인스턴스를 활용하기 위해서는 현재 시장에서의 가격 동향을 파악하는 것이 중요합니다. 이 글에서는 AWS에서 Spot 인스턴스의 현재 비용을 확인하는 방법을 자세히 알아보고, 이를 통해 어떻게 클라우드 비용을 효율적으로 관리할 수 있는지 소개하겠습니다. Spot 비용을 실시간으로 모니터링하여 예산을 절약하고, 안정적으로 워크로드를 관리하는 데 도움을 드리겠습니다. 1. 사이트에서 확인하기이미지와 같이 https://aws.amazon.com/ko/ec2/spot/..