[cloud] 6단계 : Kubernetes(AWS ECS or EKS)기반 배포 자동화 - 100-hours-a-week/5-yeosa-wiki GitHub Wiki

1. 단계 개요

이 단계는 기존 Docker, kubeadm 기반 단일 클러스터 운영 모델에서 발생하는 한계를 해결하기 위해,

AWS ECS 혹은 EKS를 활용하여 완전한 Kubernetes 기반 멀티노드 오케스트레이션 환경을 구축하고,

서비스의 확장성, 안정성, 자동화 수준을 한 단계 업그레이드하는 것을 목표로 한다.

특히,

온기 서비스는 한 명의 사용자로부터 발생할 수 있는 대량 사진 업로드 트래픽과 장애 상황에 신속히 대응해야 하므로, 수작업 관리에 한계가 있는 kubeadm 기반 운영을 넘어, EKS의 자동화된 확장성과 고가용성을 적극 활용해야 한다.

2. 기술 선택 배경

2.1 kubeadm만으로는 부족한 이유

항목 kubeadm 한계 Kubernetes(EKS/ECS) 도입 효과
운영 자동화 설치, 업그레이드, 인증서 갱신 모두 수작업 관리형 Control Plane, 자동 헬스체크, 운영 간소화
고가용성 Master 장애 시 전체 서비스 영향 EKS Control Plane은 다중 AZ 분산, 자동 복구
확장성 노드 추가/삭제 수작업, 복잡한 스케일링 HPA, Cluster Autoscaler 통한 즉각적 확장
보안 통합 IAM, VPC 통합 직접 설정 AWS IAM Roles, VPC 네이티브 연동 지원
운영 인력 부담 수작업 유지보수, 문제 발생 시 빠른 대응 어려움 자동화 기반 운영, 소규모 팀에 최적화

2.2 온기 서비스 특성 기반 Kubernetes 필요성

1. 사용자 기반 트래픽 폭발 대응

  • 온기는 이벤트, 친구 초대 등 상황에서

    단일 사용자라도 다량의 사진을 동시에 업로드하는 경우가 빈번하다.

  • 이로 인해 순간적인 서버 부하가 급격히 증가할 수 있다.

  • Kubernetes는 Pod와 Node를 자동 확장하여

    트래픽 폭발 상황에도 빠르게 대응할 수 있다.

트래픽 집중성 높은 서비스 특성상, 빠른 자원 확장이 필수다.

2. 소규모 팀의 운영 효율성 확보

  • 온기 팀은 소수 인력으로 서비스 개발과 운영을 모두 담당한다.

  • kubeadm 기반 클러스터는 수작업 장애 복구, 업그레이드 등

    관리 복잡도가 높아, 인력 리소스를 소모한다.

  • Kubernetes(EKS)는

    • Self-healing,

    • Auto-scaling,

    • RollingUpdate,

    • 선언적 관리

      기능을 통해 운영 부담을 획기적으로 감소시킨다.

소규모 팀이 '운영 리스크 없이' 서비스를 확장하려면 자동화 기반 운영이 필수다.

3. 빠른 기능 업데이트와 무중단 배포

  • 온기는 지속적으로 사진 분류, 앨범 추천, 검색 기능을 고도화할 예정이다.

  • 이를 위해 기능 배포는 빠르고, 장애 리스크는 낮아야 한다.

  • Kubernetes는 Deployment 전략(RollingUpdate, Canary)을 지원하여,

    새로운 기능을 안정적이고 끊김 없이 사용자에게 제공할 수 있다.

빠른 기능 추가와 서비스 안정성을 동시에 잡기 위해 Kubernetes 기반 운영이 필요하다.

3. Kubernetes 클러스터 아키텍처 설계

3.1 클러스터 구성

구성 요소 설명
Control Plane AWS EKS 관리형 Control Plane (Multi AZ 고가용성 구성)
Worker Nodes Managed Node Group
네트워킹 VPC 내 퍼블릭/프라이빗 Subnet 분리 구성
Load Balancer ALB(External), NLB(Internal) 사용
CNI AWS VPC CNI 또는 Calico 연동 (Pod당 VPC IP 부여)

3.2 네임스페이스 구성 전략

네임스페이스 설명
frontend Next.js/Nginx 기반 프론트엔드 앱
backend Spring Boot 기반 API 서버
ai AI 모델 서버용 파드 관리
database MySQL 클러스터 관리
monitoring Prometheus, Grafana 등 모니터링 컴포넌트
argocd GitOps 배포 자동화 관리용 네임스페이스

3.3 애플리케이션 배포 리소스

컴포넌트 리소스 특이사항
React App Deployment + Service(LoadBalancer) HPA 적용 (CPU 기준)
Spring Boot App Deployment + Service(Internal) HPA 적용 (CPU/Memory 기준)
AI 서버 Deployment + Service(Internal) 고사양 리소스 할당, 리밋 설정
MySQL StatefulSet + PVC 영구 저장소 관리 (RDS 고려 가능)

3.4 트래픽 흐름

  1. 외부 사용자가 ALB(HTTPS)로 접속
  2. ALB → Ingress Controller → React App
  3. React App → API 요청 → Spring Boot App
  4. Spring Boot App → AI 서버 호출 및 MySQL 연결

4. 주요 리소스 및 설정 요약

리소스 설정
Deployment replicas: 3, strategy: RollingUpdate
HPA Target CPU 70%, min: 3, max: 10
Ingress ALB Ingress Controller, HTTPS 적용
ConfigMap/Secret 환경변수, DB 접속 정보 관리
PVC MySQL 볼륨 지속성 확보
Monitoring Prometheus Operator, Grafana, Slack 알람 연동

5. YAML 리소스

React App Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: react-frontend
  namespace: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: react-frontend
  template:
    metadata:
      labels:
        app: react-frontend
    spec:
      containers:
      - name: react
        image: myrepo/react-frontend:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi

6. 기대 효과

  • 단일 사용자의 대량 트래픽에도 빠른 자원 확장으로 대응 가능
  • 기능 업데이트 시 무중단 롤링 배포로 사용자 경험 유지
  • 장애 발생 시 Kubernetes 자가 복구(Self-healing) 기능으로 빠른 회복
  • 소규모 팀 운영 인력으로도 안정적이고 확장 가능한 서비스 관리
  • 선언적 인프라 관리로 오류 가능성 최소화 및 운영 표준화
  • 모니터링, 알림 시스템을 통한 빠른 장애 탐지 및 대응 가능

7. 현 단계 한계 및 향후 개선 방향

항목 상세 설명
비용 최적화 HPA/Cluster Autoscaler 적극 활용하여 불필요 리소스 절감
고급 배포 전략 ArgoCD를 도입하여 Blue/Green 배포 도입 예정
네트워크 보안 Calico NetworkPolicy 도입하여 네임스페이스별 격리 강화 예정
운영 자동화 Helm Charts 관리, GitOps 기반 운영 체계 완성 예정

최종 정리 문장

온기 서비스는 소규모 팀이 한 명의 사용자로부터 발생할 수 있는 대량의 사진 업로드 트래픽과 장애 상황을 효율적으로 대응해야 하므로, 직접 운영 부담이 큰 kubeadm을 넘어서 EKS의 자동화와 고가용성 기능을 통해 서비스를 안정적으로 운영해야 한다.