☁️ 6단계: Kubernetes(AWS ECS or EKS)기반 배포 자동화 - 100-hours-a-week/7-team-ddb-wiki GitHub Wiki

1. 개요

본 설계는 kubeadm 기반 Kubernetes 클러스터에서 Amazon Elastic Kubernetes Service(EKS) 기반 클러스터로 전환함에 따라, 기존 운영 전략과 구성 방식을 EKS 환경에 최적화하기 위해 작성되었다.

모든 애플리케이션은 고가용성(HA)을 보장하는 상태에서 자동 배포, 모니터링, 로깅이 가능한 구조로 운영되며, GitOps 기반의 ArgoCD를 통한 배포 자동화, Prometheus 기반 메트릭 수집, Loki 기반 로그 수집이 통합되어 있다.

2. 도입 배경 및 필요성

기존 kubeadm 방식은 클러스터 제어 플레인 및 노드 구성에 대한 직접 관리가 요구되며, 장애 대응 및 확장성 측면에서 많은 운영 부담이 있었다.

• 운영 복잡성 증가: Control Plane, Node 설치 및 구성, CNI 설정, 모니터링 시스템 도입까지 모두 수작업으로 진행되어 운영자의 부담이 컸고, 장애 복구 및 버전 업그레이드 시에도 높은 리스크가 존재하였다.
• 확장성 한계: 트래픽 급증에 따른 Auto Scaling 구현이 복잡하고, Cluster Autoscaler 구성이나 Node Group 확장 역시 수동으로 처리되어 실시간 대응이 어려웠다.
• 고가용성 부재: Kubeadm 클러스터는 기본적으로 Single AZ 기반이며, Control Plane 이중화 구성은 별도 작업이 필요하여 장애 대응 지연 및 운영비용 증가 요인이 되었다.

이러한 한계를 극복하기 위해 AWS EKS를 도입함으로써 다음과 같은 핵심 이점을 확보하고자 한다.

• 제어 플레인 관리 부담 해소: AWS에서 Fully-managed Control Plane 제공
• Auto Scaling Group 및 NodeGroup: 자동 확장 기반의 고가용성 보장
• IAM 연동을 통한 보안 통제 강화
• Helm Chart 기반 구성 관리 및 무중단 롤링 업데이트 적용
• 관측 및 배포 도구의 안정적 배치 및 운영

결론적으로, EKS는 기존 Kubeadm 방식의 운영상 복잡성과 확장성 한계를 해결하면서, Dolpin 서비스의 고가용성, 보안성, 자동화된 운영 전략을 실현하는 최적의 대안으로 판단된다.

3. 목표 & 적용 범위

• 목표
  • 배포 자동화 및 롤백 가능 구조 구현 (ArgoCD 기반 GitOps)
  • Prometheus 기반 모니터링 지표 확보 및 알림 체계 구성
  • Loki 기반 수집 로그에 대한 시각화 및 검색 가능 환경 구축
  • HPA 기반 자동 확장 구성 및 퍼포먼스 테스트 대응
• 적용 범위
  • 클러스터 내 모든 FE, BE, AI 애플리케이션
  • 관측(모니터링/로깅) 시스템
  • 배포 파이프라인
  • 네트워크 정책 및 보안 전략
  • 퍼포먼스 테스트 및 장애 복구 체계

4. 설계 상세

EKS 아키텍쳐

CI/CD

4.1 노드 토폴로지

노드	역할	주요 구성 요소
Node1	관측 및 배포 도구 전용	Prometheus, Grafana, Loki, Node Exporter, ArgoCD, Nginx Ingress
Node2	워크로드 노드	FE, BE, Promtail, Node Exporter, Nginx Ingress
Node3	워크로드 노드	FE, BE, Promtail, Node Exporter, Nginx Ingress

FE/BE는 Node2, Node3에서 HPA 기반으로 자동 스케일링 가능

4.2 네임스페이스

네임스페이스	리소스 구성
monitoring	Prometheus, Grafana, Loki, Node Exporter, Promtail
argo	ArgoCD
fe-web	Next.js 프론트엔드 서비스
be-was	Spring 백엔드 서비스
kube-system	EKS 시스템 컴포넌트 (CNI, kube-proxy, coredns 등)

4.3 NetworkPolicy

• Kubernetes 클러스터 내에서는 기본적으로 모든 Pod 간 통신이 허용되어 있다.

• NetworkPolicy는 이러한 기본 정책을 제한하고, 정의된 규칙에 맞는 Pod 간의 통신만 허용함으로써 제로 트러스트 기반 네트워크를 실현하는 핵심 보안 메커니즘이다.

• 주요 목적은 다음과 같다:

  • 보안 강화: 민감한 서비스나 DB에 대한 접근을 허용된 Pod로 제한
  • 서비스 간 논리적 분리: 네임스페이스 또는 레이블 기반으로 역할을 분리
  • 최소 권한 원칙 적용: 필요한 서비스 간 트래픽만 허용하고 나머지는 차단

• 다음은 app=frontend 라벨을 가진 Pod만 app=backend 라벨을 가진 Pod에 TCP 80 포트로 통신할 수 있도록 허용하는 NetworkPolicy 예시이다:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-frontend-to-backend
    namespace: default
  spec:
    podSelector:
      matchLabels:
        app: backend
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: frontend
      ports:
      - protocol: TCP
        port: 80
    policyTypes:
    - Ingress
  

  이 정책은 app=backend인 Pod에 대해 app=frontend Pod로부터의 TCP 80 포트 요청만 허용하고, 다른 모든 인바운드 요청은 차단한다.

5. 운영 전략

5.1 리소스 구성 전략

구성 요소	사용 리소스	설명
애플리케이션 배포	Deployment	• FE/BE 서비스는 Deployment로 배포되며, 최소 2개 이상의 replica를 유지하여 고가용성을 확보함.• EKS의 Managed Node Group을 활용하여 노드 자동 확장이 가능함.
서비스 노출	Service (ClusterIP)	• FE/BE 각각에 대해 ClusterIP 서비스 객체를 생성하여 내부 통신을 위한 DNS 해석 기반 네트워크를 구성함.
Ingress	Ingress + Nginx Ingress Controller	• NodeGroup 별로 Nginx Ingress Controller를 배포하여 트래픽 진입점을 분산 구성함.• 외부 요청은 ALB를 통해 Ingress로 전달되며, Ingress가 내부 서비스로 라우팅함.
모니터링	DaemonSet (Promtail, Node Exporter)	• Node Exporter와 Promtail을 DaemonSet으로 배포하여 시스템 메트릭과 로그를 수집함.• Prometheus는 Exporter를 통해 수집하고, Loki는 로그를 중앙에서 수집 및 분석함.
네트워크 정책	AWS VPC CNI + Calico NetworkPolicy	• EKS에서 제공하는 AWS VPC CNI를 기본으로 사용하면서, 서비스 간 트래픽 제어를 위해 Calico NetworkPolicy를 추가적으로 구성함.

5.2 워크로드 오브젝트 사용 정책

목적	기본 오브젝트	추가 전략
스테이트리스 서비스	Deployment	• RollingUpdate 방식 기본 적용• maxUnavailable: 25% 설정• HPA (평균 CPU 60% 기준 자동 확장)
클러스터 레벨 에이전트 (Log/Metric)	DaemonSet	• priorityClassName: system-node-critical 설정• Promtail, Node Exporter 각 노드에 1개씩 배포
배치·스케줄 작업	CronJob / Job	• successfulJobsHistoryLimit: 3• ttlSecondsAfterFinished: 3600 (완료 후 자동 정리)

5.3 HPA

HPA(Horizontal Pod Autoscaler)는 Pod의 리소스 사용량(CPU, 메모리 등)을 기준으로 자동으로 복제 수를 조정하는 Kubernetes의 기본 오토스케일링 기능이다.

• 사전 조건 EKS에는 기본적으로 metrics-server가 설치되어 있지 않으므로, Helm 등을 통해 설치 필요

  helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
  helm install metrics-server metrics-server/metrics-server \
    -n kube-system \
    --set args={--kubelet-insecure-tls}
  

• 예시 YAML (CPU 기준 HPA)

  apiVersion: autoscaling/v2
  kind: HorizontalPodAutoscaler
  metadata:
    name: backend-hpa
    namespace: be-was
  spec:
    scaleTargetRef:
      apiVersion: apps/v1
      kind: Deployment
      name: backend
    minReplicas: 2
    maxReplicas: 10
    metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
  

6. 비용

AWS 비용 계산기 견적서 바로가기

서비스 이름	설명	요금 (USD)
Amazon EKS	AWS 관리형 Kubernetes 제어 플레인	73.00
Amazon EC2 (t3.medium)	fe/be 서비스 워커노드	15.70
Amazon EC2 (t3.large)	모니터링, ArgoCD 워커노드	28.88
Amazon EC2 (t3.small)	nat + bastion	5.54
Amazon EC2 (t3.medium)	Jenkins	13.17
Amazon EC2 (g4dn.xlarge)	GPU	139.86
Amazon S3 (Standard)	정적 이미지 저장소	2.50
Amazon RDS for PostgreSQL (db.t3.medium)		171.38
Amazon ElastiCache	Redis	34.31
Elastic Load Balancing		22.27
Amazon Elastic Container Registry		2.00
Amazon Route 53		0.90
Amazon CloudFront	프리티어 내 사용	0.00
Amazon API Gateway	프리티어 내 사용	0.00
총합 (주 49시간 운영, 한 달)		509.51