딜라이트룸은 글로벌 누적 다운로드 1억 건을 돌파한 수면·기상 솔루션 Alarmy와 B2B 광고 수익화 플랫폼 DARO를 운영하고 있습니다. 최근에는 앱 인수를 통해 사업 영역을 확장하고 있습니다. 2025년 매출 460억 원, 영업이익 200억 원을 기록한 딜라이트룸은 매출 대부분이 해외에서 발생하는 글로벌 중심 기업입니다. Figure 1: 딜라이트룸 소개 앱 인수를 통한 사업 확장은 곧 인프라의 확장을 의미합니다. 새로운 […] ||
딜라이트룸은 글로벌 누적 다운로드 1억 건을 돌파한 수면·기상 솔루션 Alarmy와 B2B 광고 수익화 플랫폼 DARO를 운영하고 있습니다. 최근에는 앱 인수를 통해 사업 영역을 확장하고 있습니다. 2025년 매출 460억 원, 영업이익 200억 원을 기록한 딜라이트룸은 매출 대부분이 해외에서 발생하는 글로벌 중심 기업입니다.
Figure 1: 딜라이트룸 소개
앱 인수를 통한 사업 확장은 곧 인프라의 확장을 의미합니다. 새로운 앱이나 서비스가 추가될 때마다 관리해야 할 ‘Amazon EKS 클러스터(이하 EKS 클러스터)’와 주변 인프라가 늘어나 소규모 인프라 팀이 감당해야 하는 운영 범위도 함께 커졌습니다.
2025년 11월, 딜라이트룸은 기존에 운영하던 5개의 EKS 클러스터를 Amazon EKS Auto Mode(이하 EKS Auto Mode)로 전환했으며 현재는 10개 이상의 모든 클러스터를 EKS Auto Mode로 운영하고 있습니다.
이 글에서는 EKS Auto Mode를 선택한 배경, 마이그레이션 과정에서의 의사결정과 트러블슈팅, EKS Auto Mode 환경에서의 옵저버빌리티 확보 방법, 그리고 도입 성과를 공유합니다.
딜라이트룸의 EKS Auto Mode 선택 배경
업그레이드 프로세스의 복잡성
EKS 클러스터를 새로운 Kubernetes 버전으로 업그레이드하려면 Control Plane 버전을 올리는 것만으로 끝나지 않습니다. Amazon EKS는 Control Plane 업그레이드 시 Add-on을 자동으로 업그레이드하지 않기 때문에 Control Plane 업그레이드 이후 Amazon VPC CNI plugin for Kubernetes(이하 VPC CNI), kube-proxy, CoreDNS, Amazon EBS CSI driver(이하 EBS CSI driver) 등 Add-on을 개별적으로 업그레이드하고 Data Plane 노드를 갱신하며 Self-managed Karpenter까지 별도로 업그레이드해야 합니다. 딜라이트룸은 이렇게 총 7개의 컴포넌트를 개별적으로 관리하고 있었고 이 과정을 5개 클러스터에서 반복해야 했습니다.
Figure 2: 업그레이드 시 개별 관리해야 하는 7개 컴포넌트 다이어그램
특히 호환성 매트릭스 관리가 큰 부담이었습니다. Karpenter는 EKS 마이너 버전마다 호환되는 최소 버전이 달라 반드시 공식 호환성 매트릭스를 확인해야 했습니다. VPC CNI와 kube-proxy, EKS 버전 간에도 연쇄 의존성이 존재하여 버전을 잘못 맞추면 Pod IP 할당 실패나 노드 NotReady 같은 운영 장애로 직결될 수 있습니다.
Self-managed Karpenter 역시 운영 부담이 적지 않았습니다. Helm Chart 배포와 업그레이드를 직접 수행해야 했고 SQS Interruption Queue 등 부수 인프라도 함께 관리해야 했습니다. Karpenter v0.32.0에서는 CRD가 전면 변경(Provisioner → NodePool, AWSNodeTemplate → EC2NodeClass)되었고 v1.0.0에서도 추가적인 스키마 변경이 이어지는 등 메이저 업그레이드마다 마이그레이션 작업이 수반되었습니다. 이러한 업그레이드 복잡성과 다운타임 우려로 인해 새 클러스터를 병렬로 구성하는 블루-그린 방식을 택하였고, 인프라 이중 운영 비용과 DNS·트래픽 전환 작업까지 더해져 업그레이드 한 번에 드는 시간과 비용은 더욱 증가했습니다.
EKS Auto Mode의 핵심 가치
EKS Auto Mode는 Net