Kubernetes 기반 운영 플랫폼 설계 - 100-hours-a-week/KTB4-4th-wiki GitHub Wiki

1. Kubernetes 도입 필요성 및 운영 플랫폼 선택

설계 범위

Need U가 대국민 서비스 규모의 V3로 성장한 상황을 가정한다.

1. 상황과 필요성

V2에서는 Backend, Frontend, AI Server를 ECS + Fargate의 독립 Service로 분리하고 서비스별 확장과 장애 복구가 가능하도록 설계하였다.

V3에서는 다음과 같은 서비스·조직 구조로 성장했다고 가정한다.

  • 기능별 독립 팀 운영
  • 팀별 Repository와 배포 주기 분리
  • API, WebSocket, Queue Worker, Batch 등 다양한 Workload 운영
  • 여러 팀이 하나의 운영 환경을 공유

이 구조에서는 단순한 Scale-Out보다 여러 팀의 Resource·권한·배포 방식을 공통된 기준으로 관리하는 문제가 중요해진다.

따라서 V3에서는 이를 위한 Kubernetes 기반 공통 운영 플랫폼을 도입한다.

2. V3 서비스 규모 가정

2.1 상한 시나리오

V2에서는 MAU 약 291,900명을 가정하였다.

V3에서는 국내 대표 선물 서비스 수준까지 성장한 상황을 설계하기 위해 MAU 약 2,900만 명을 상한 시나리오로 설정한다.

2025년 12월 중순 기준 카카오톡 선물하기의 평균 MAU가 업계 추정 약 2,900만 명을 넘어선 것으로 보도되었다.

전자신문 - 카카오톡 선물하기 이용 규모

이 수치는 Need U의 성장 예측값이 아니라 대규모 선물 서비스까지 성장했을 때 인프라와 운영 구조를 검토하기 위한 Stress Scenario다.

4단계의 계산 기준을 동일하게 적용한다.

  • DAU / MAU = 25%
  • Peak Hour = DAU의 20%
  • 사용자당 API 요청 = 25~30회
  • AI 이용률 = 40%
  • AI 사용자당 Inference = 3회
항목 V2 V3 상한 시나리오
MAU 약 291,900 약 29,000,000
DAU 약 72,975 약 7,250,000
Peak Hour 사용자 약 14,595 약 1,450,000
Peak API 약 101~122 RPS 약 10,100~12,100 RPS
AI Inference 약 4.87 RPS 약 480 RPS
DB QPS 약 243 약 24,200

2.2 가정의 한계

DAU/MAU 25%는 실제 선물 서비스 공개 데이터가 아니므로 정확한 V3 이용량을 의미하지 않는다.

또한 카카오톡 선물하기는 2024년 설 시즌 약 700만 건, 추석 시즌 약 1,400만 건의 주문이 발생한 것으로 보도되어 일반 Peak와 별도로 시즌 Spike를 고려해야 한다.

전자신문 - 카카오톡 선물하기 이용 규모

단, MAU나 RPS 증가 자체는 Kubernetes 도입 근거로 사용하지 않는다.

3. V3 조직과 Workload

3.1 조직 가정

팀 담당 기능
추천·AI 팀 추천, 상품, AI 대화·분석
소셜 팀 회원·인증·설정, 친구, 콕 찌르기, 익명 대화
알림·일정 팀 알림, 캘린더·이벤트, 외부 캘린더 연동
플랫폼 팀 공통 배포 환경, 권한, Resource 관리

기능 팀은 담당 서비스의 개발과 운영을 책임지고, 플랫폼 팀은 기능 팀이 공통된 방식으로 Application을 운영할 수 있는 환경을 제공한다.

3.2 Workload 분리 기준

모든 기능을 별도 서비스로 분리하지 않는다.

다음 두 조건을 기준으로 분리한다.

  1. 실행 형태와 Scaling 기준이 다른 경우
  2. 소유 팀이 달라 독립적인 배포가 필요한 경우

3.3 Workload 구성

Workload 소유 팀 실행 형태 주요 확장 기준
Frontend 공통 상시 Request / CPU
reco-api 추천·AI 팀 상시 Request / CPU
ai-gateway 추천·AI 팀 상시 / SSE Request / 동시 연결
ai-worker 추천·AI 팀 Queue Consumer Queue Length
batch 추천·AI 팀 주기 실행 Schedule
social-api 소셜 팀 상시 Request / CPU
anonymous-chat 소셜 팀 WebSocket 동시 연결
schedule-api 알림·일정 팀 상시 Request / CPU
notification 알림·일정 팀 SSE 동시 연결

Frontend는 단일 Application으로 유지한다.

Backend가 기능 팀별 API로 분리되므로 DB Table 소유 범위와 서비스 간 호출 방식은 5단계-2에서 함께 설계한다.

4. ECS로도 해결 가능한 문제

V3의 모든 요구사항이 Kubernetes를 필요로 하는 것은 아니다.

요구사항 ECS 대응
Traffic 증가 Task Scale-Out
Application 증가 Service 추가
서비스별 Scaling ECS Service Auto Scaling
Queue 기반 Scaling SQS 기반 Custom Metric
SSE / WebSocket ECS + ALB
Workload별 AWS 권한 ECS Task Role

ECS는 SQS Queue의 적체량을 기준으로 Worker Task를 확장할 수 있다.

AWS - ECS Queue 기반 Auto Scaling

또한 ECS는 Task Definition별 Task IAM Role을 지정하여 Application별 최소 권한을 부여할 수 있다.

따라서 다음 항목은 Kubernetes 도입의 직접적인 이유가 아니다.

  • Traffic 증가
  • Application / Task 수 증가
  • Queue 기반 Scaling
  • SSE / WebSocket
  • Workload별 IAM 권한 분리
  • GPU 사용

Kubernetes 도입의 핵심은 여러 기능 팀의 운영 정책과 배포 방식을 공통 플랫폼으로 표준화하는 것이다.

5. Kubernetes를 도입하는 이유

5.1 팀 단위 Resource·권한 관리

V3에서는 여러 기능 팀이 하나의 Cluster를 공유한다.

Kubernetes에서는 Namespace를 팀별 관리 범위로 사용하고 RBAC로 접근 권한을 제한하며, ResourceQuota로 Namespace의 CPU·Memory 등 Resource 사용량을 제한할 수 있다.

Kubernetes - Multi-tenancy

예:

social Namespace
├─ social-api
└─ anonymous-chat

CPU / Memory 총량 제한
+
소셜 팀만 해당 Namespace에 배포

Namespace가 물리적 완전 격리를 제공하는 것은 아니므로 필요한 경우 Node Group 분리를 추가한다.

Need U에서는 팀별 Resource와 접근 정책을 하나의 공통 모델로 관리하기 위해 Kubernetes를 사용한다.

5.2 배포 방식 표준화

V3에서는 각 기능 팀이 독립적인 Repository와 배포 주기를 가진다.

팀마다 별도의 배포 구조를 만드는 대신 다음 형태로 표준화한다.

Application Repository
        ↓
GitHub Actions
Test → Build → ECR Push

GitOps Repository
        ↓
공통 Helm Chart + 팀별 Values
        ↓
ArgoCD
        ↓
EKS

Helm은 Template과 Values를 이용해 Kubernetes Resource를 공통 구조로 관리할 수 있다.

Helm - Chart Template Guide

ArgoCD는 Git에 정의된 Desired State를 기준으로 Kubernetes Application을 배포·동기화한다.

Argo CD 공식 문서

Need U에서는 여러 기능 팀에 동일한 배포 인터페이스와 Resource 정의 방식을 제공하기 위해 Kubernetes를 사용한다.

5.3 다양한 Workload의 공통 운영

V3에는 다음과 같이 실행 방식이 다른 Workload가 존재한다.

API                  → 상시 실행
WebSocket / SSE      → 장시간 Connection
AI Worker            → Queue 소비
Batch                → 주기 실행

Kubernetes에서는 Deployment, Service, CronJob, HPA 등의 Resource를 통해 이를 하나의 운영 모델 안에서 정의한다.

이 자체가 Kubernetes 도입 이유는 아니지만, 여러 팀이 다양한 Workload를 운영할 때 동일한 운영 기준을 적용할 수 있다는 점이 앞선 두 근거를 보완한다.

6. Kubernetes 운영 방식 선택

Need U V3에서는 Amazon EKS를 사용한다.

이유는 다음 세 가지다.

  1. 플랫폼 팀의 운영 범위를 Application 운영에 집중
  2. 기존 AWS Infrastructure와 Kubernetes를 그대로 연계
  3. Managed Node Group으로 Worker Node Lifecycle 관리 부담 감소

Pod Identity를 통한 IAM 분리는 EKS 선택의 장점이지만, ECS에서도 Task Role로 가능한 기능이므로 Kubernetes 도입 자체의 근거로 사용하지 않는다.

6.1 kubeadm과 EKS 비교

항목 kubeadm Amazon EKS
Control Plane 직접 운영 AWS 관리
etcd 직접 운영·Backup AWS 관리
Cluster Upgrade 직접 관리 EKS 기반 Upgrade
Worker Node 직접 구성 Managed Node Group 사용 가능
Pod IAM 별도 연동 필요 Pod Identity / IRSA
AWS 연동 직접 구성 AWS Controller / Add-on 활용

kubeadm은 Kubernetes Cluster를 Bootstrap하는 도구이며 Machine Provisioning이나 Cloud Provider별 Infrastructure 구성은 범위에 포함하지 않는다.

kubeadm의 장점 및 미선정 이유

kubeadm 기반 Kubernetes는 다음과 같은 설정을 직접 변경할 수 있다는 장점이 있다.

  • Pod 배치 우선순위: CPU·Memory 여유가 많은 Node를 우선 선택하도록 Scheduler의 점수 계산 기준과 가중치를 변경할 수 있다.
  • Node 장애 판단 시간: Node가 상태 정보를 보내지 않을 때 몇 초 후 장애로 판단할지 설정할 수 있다. 예를 들어 기본 유예 시간을 50초에서 30초로 조정할 수 있다.
  • etcd 백업·복구: Kubernetes의 Deployment, Service, Secret 등 Cluster 상태 정보가 저장된 etcd의 Snapshot을 직접 생성하고, 장애 발생 시 해당 Snapshot으로 복원할 수 있다.

그러나 Need U V3에서는 Scheduler의 점수 계산 방식을 변경하거나 Node 장애 판단 시간을 직접 조정할 요구사항이 없다. Pod의 분산과 Workload별 Node 분리는 EKS의 기본 Kubernetes 기능으로 구현할 수 있으며, Kubernetes 리소스는 GitOps 및 별도 백업 체계로 복구할 수 있다.

따라서 이러한 세부 제어 기능보다 Control Plane 운영 부담을 줄이는 것이 중요하므로 EKS를 선정한다.

6.2 플랫폼 팀을 Application 운영에 집중

Need U 플랫폼 팀의 목적은 Kubernetes Cluster 자체를 운영하는 것이 아니라 추천·AI / 소셜 / 알림·일정 팀이 사용할 공통 Application 운영 환경을 제공하는 것이다.

kubeadm을 사용하면 Application 외에도 다음을 직접 관리해야 한다.

  • Control Plane / etcd
  • Cluster Upgrade
  • 인증서와 Cluster Lifecycle
  • Control Plane 장애 및 복구

EKS에서는 Control Plane 운영을 AWS에 위임하고 플랫폼 팀은 다음 영역에 집중한다.

  • Application 배포 / Rollback
  • Resource 정책
  • Auto Scaling
  • AI Worker Queue Scaling
  • Batch 실행
  • Observability / 장애 대응

서비스 기능과 직접 관련 없는 Cluster 운영 부담을 줄이는 것이 EKS 선택의 첫 번째 이유다.

6.3 기존 AWS Infrastructure와 연계

Need U는 Kubernetes 도입 이후에도 다음 AWS Infrastructure를 유지한다.

외부 Traffic → ALB
Container Image → ECR
Database → RDS
Queue → SQS
AWS 권한 → IAM
Monitoring → CloudWatch
AI 추론 → RunPod

Redis → 운영 방식 별도 결정

EKS는 VPC CNI, EBS CSI 등의 Add-on을 통해 Kubernetes와 AWS Networking·Storage를 연계할 수 있다.

또한 EKS Pod Identity는 Kubernetes Service Account에 IAM Role을 연결하여 Pod 단위 AWS 권한을 제공한다.

예를 들어 Need U에서는 다음과 같이 적용할 수 있다.

ai-gateway
→ SQS 작업 전송 권한

ai-worker
→ SQS 작업 수신 권한

단, IAM 최소 권한 자체는 ECS에서도 Task Role로 구현 가능하다. 따라서 Pod Identity는 ECS → Kubernetes 전환의 근거가 아니라 kubeadm 대신 EKS를 선택했을 때 AWS IAM을 Kubernetes Workload와 연계하기 쉬운 장점으로 본다.

기존 AWS Architecture를 유지한 상태에서 Application Runtime만 Kubernetes로 전환할 수 있다는 점이 Need U에서 EKS를 선택하는 두 번째 이유다.

6.4 Managed Node Group 활용

V3에서는 API, WebSocket, Queue Worker, Batch처럼 Resource 사용 특성이 다른 Workload를 운영하므로 Worker 환경은 EC2 Managed Node Group을 사용한다.

EKS Managed Node Group은 EC2 Node의 Provisioning과 Lifecycle을 관리하며, Node Update와 Termination 과정에서 자동으로 Drain을 수행한다. Node Auto Repair도 사용할 수 있다.

따라서 플랫폼 팀은 개별 Node Lifecycle보다 다음 Capacity 설계에 집중한다.

  • Node Group 구성
  • Instance Type
  • 최소 / 최대 Capacity
  • Workload 배치
  • Node Auto Scaling

Node는 EC2로 유연하게 구성하면서 Lifecycle 관리 부담을 줄일 수 있다는 점이 EKS 선택의 세 번째 이유다.

6.4.1 EC2 Managed Node Group과 Self-managed EC2 Node 비교

EKS에서는 Worker Node를 직접 생성·관리하는 Self-managed EC2 Node와 AWS가 Node Lifecycle을 관리하는 EC2 Managed Node Group을 선택할 수 있다.

두 방식 모두 EC2에서 Pod를 실행하지만, Node 생성·Cluster 등록·업데이트·교체 과정의 관리 주체가 다르다.

항목 Self-managed EC2 Node EC2 Managed Node Group
EC2 생성 직접 구성 EKS가 관리
Cluster 등록 Bootstrap 직접 구성 자동 등록
Node Update 새 AMI 적용 및 교체 절차 직접 구현 관리형 업데이트 지원
Pod Drain 직접 실행·자동화 관리형 업데이트 시 자동 수행
장애 Node 교체 ASG 등 별도 구성 Node Auto Repair 지원
OS / Bootstrap 설정 높은 자유도 Custom AMI·Launch Template 등 지원
Node Auto Scaling 별도 구성 별도 Autoscaler 구성 필요
운영 부담 높음 상대적으로 낮음

Self-managed EC2 Node의 장점

Self-managed Node는 Node의 생성부터 종료까지 직접 제어할 수 있다.

예를 들어 특정 Kernel 설정이나 Container Runtime을 변경하거나, Node 교체 시 Pod를 이동시키는 순서와 종료 조건을 독자적으로 구현해야 하는 경우 유리하다.

Need U V3의 선정 이유

Need U V3에서는 API, WebSocket, Worker를 여러 Node에 배치하지만, Kernel이나 Container Runtime을 특별히 수정하거나 Node 교체 절차를 직접 구현해야 할 요구사항은 없다.

Managed Node Group에서도 Instance Type 선택, Workload별 Node Group 분리, Custom AMI 및 Node Auto Scaling 구성이 가능하다.

단, Managed Node Group 자체가 Pod의 Resource 요구량에 따라 Node를 자동 확장하는 것은 아니므로 Cluster Autoscaler나 Karpenter 등의 별도 구성이 필요하다.

따라서 Node 설정의 세부 제어보다 생성·등록·업데이트·교체 과정의 운영 부담을 줄이는 것이 중요하므로 EC2 Managed Node Group을 선정한다.

7. Node 실행 방식

Worker 환경은 EC2 Managed Node Group을 기본 구조로 사용한다.

구분 EKS Fargate EC2 Managed Node Group
Node 관리 적음 필요
Instance 선택 제한적 가능
Workload별 Node 구성 제한적 가능
DaemonSet 지원하지 않음 사용 가능
EBS Volume Fargate Pod에 Mount 불가 사용 가능

EKS Fargate에서는 DaemonSet을 지원하지 않으며 Amazon EBS Volume을 Fargate Pod에 Mount할 수 없다. EBS CSI node DaemonSet 역시 EC2 Instance에서만 실행할 수 있다.

V3에는 서로 다른 Resource 특성을 가진 Workload가 존재하고, 이후 Observability Agent나 Storage Driver 등 Node 수준의 구성요소가 필요할 수 있다.

따라서 EC2 Managed Node Group을 기본 Worker 구조로 사용한다.

구체적인 Node Group 분리, Instance Type, Capacity, Auto Scaling은 5단계-2에서 설계한다.

8. Kubernetes 도입 Trade-off

Kubernetes 도입으로 다음 운영 부담이 추가된다.

  • EKS Control Plane 비용
  • Kubernetes Version Upgrade
  • Node Capacity 관리
  • Requests / Limits
  • HPA 정책
  • Helm / ArgoCD 운영
  • Pod Pending / Scheduling 등 Kubernetes 장애 대응
  • Kubernetes 학습 비용

Amazon EKS는 표준 지원 버전에 대해 Cluster당 시간당 $0.10, Extended Support에서는 시간당 $0.60이 부과되며 Compute, Load Balancer, Storage 비용은 별도다.

따라서 Kubernetes는 운영 복잡성을 제거하는 선택이 아니다.

기능 팀의 운영 방식을 표준화하고, Kubernetes 자체의 운영 복잡성은 플랫폼 팀이 담당하는 구조로 전환하는 것이다.

9. 최종 판단

V3에서는 다음과 같은 서비스·조직 구조를 설계 가정으로 둔다.

기능별 독립 팀 운영
        +
팀별 Repository / 배포 주기 분리
        +
API / WebSocket / Worker / Batch 등 다양한 Workload
        +
팀 단위 Resource / 권한 관리
        +
공통 배포 방식
        +
플랫폼 팀 운영

이 가정에서는 기능 팀마다 서로 다른 운영 방식을 만드는 것보다 Resource·권한·배포 방식을 하나의 공통 운영 모델로 표준화하는 것이 중요하다.

따라서 Need U V3에서는 Kubernetes를 도입하고 운영 플랫폼으로 Amazon EKS를 사용한다.

  • Kubernetes 선택 이유: 기능 팀별 운영 정책과 배포 방식 표준화
  • EKS 선택 이유: 기존 AWS Architecture 연계 + Cluster 운영 범위 축소 + Managed Node Group 활용
  • Worker 선택: EC2 Managed Node Group

Need U V3에서는 기존 AWS Infrastructure를 유지하면서 여러 기능 팀의 Workload를 공통된 방식으로 운영하고, 플랫폼 팀의 역량을 Cluster 자체보다 서비스 운영에 집중하기 위해 EKS 기반 Kubernetes 플랫폼을 사용한다.