Kubeadm 설계 - 100-hours-a-week/20-real-wiki GitHub Wiki

📌 목차

Kubeadm 설계

⚙️ 1. kubeadm 오케스트레이션 계획 수립 및 분석

1.1. Kubeadm 도입 배경 및 필요성

이번 프로젝트는 초기에는 Docker 기반으로 각 서비스를 컨테이너화하고, 이를 EC2 인스턴스에 수작업으로 배포하는 방식으로 진행되었다. 이러한 방식은 단순성과 초기 구성의 용이성 측면에서는 유리했지만, 다음과 같은 문제점이 있었다:

  • 수동 배포에 따른 반복 작업과 오류 가능성
  • 서비스 복제 및 확장에 대한 자동화 부재
  • 장기적으로 운영 환경에 적합하지 않은 구조
  • 리소스 스케줄링, 자가 복구, 모니터링 등의 기능 부족

이러한 문제점은 초기 MVP 수준에서는 감내할 수 있지만, 향후 서비스 확장이나 팀 협업, 지속적인 운영 및 배포 자동화 측면에서 오케스트레이션 도구의 도입이 필수적이라는 판단으로 이어졌다.

이번 설계 단계에서 Kubernetes의 도입은 과제 요구 사항에 따른 필수적 선택이었다. 따라서 EC2 위에서 Kubernetes를 직접 설치하고 구성할 수 있는 Kubeadm을 사용하여 자체 관리형 Kubernetes 클러스터를 구축하고자 한다.

1.2. 기대 효과 및 서비스에 주는 이익

Kubernetes 도입을 통해 기대할 수 있는 효과는 다음과 같다:

  • 서비스 복원력 향상: Pod 단위의 자가 복구(Self-healing) 기능을 통해 장애 발생 시 자동 복구가 가능하다.
  • 배포 자동화 및 롤아웃 관리: Rolling Update, Canary Deployment 등을 활용하여 점진적 배포가 가능하다.
  • 리소스 효율성 증가: 노드 간 자원 스케줄링을 통해 CPU, 메모리 등의 사용률을 최적화할 수 있다.
  • 수평 확장 지원: Auto Scaling 정책에 따라 트래픽 증가 시 자동으로 인스턴스 수를 확장할 수 있다.
  • 운영 일관성 확보: 개발-테스트-운영 환경 간 일관된 배포 전략이 가능해진다.

이러한 이점은 특히 멀티 컨테이너 기반의 마이크로서비스 구조를 운영하는 데 필수적인 기능들로, 서비스의 안정성과 유지 보수성을 동시에 확보하는 데 기여할 수 있다.

1.3. 클러스터 구성 및 아키텍처

1.3.1 노드 구성

  • 마스터 노드: EC2의 Private Subnet에 위치
  • 워커 노드: Auto Scaling Group을 기반으로 2개 구성, Private Subnet에 위치
  • 퍼블릭 서브넷: Bastion Host, Grafana 모니터링 서버 배치
  • DB Subnet: Amazon RDS (MySQL) 별도 분리 구성

1.3.2 네트워크 구조

  • CNI: Calico 사용 (네트워크 정책 + 고성능 라우팅 지원)
  • 노드 간 통신: kubelet & kube-proxy를 통한 Pod 간 통신 구성
  • 외부 통신: Nginx Ingress Controller를 통해 서비스 라우팅

1.4. 서비스 배포 및 운영 전략

1.4.1 배포 단위 및 구성

각 서비스는 별도 Deployment 또는 StatefulSet으로 분리:

서비스 리소스 종류 스케일 비고
Web (Next.js) Deployment 2 replicas HPA 적용
App (Spring Boot) Deployment 2 replicas HPA 적용
AI 모듈 Deployment 2 replicas 향후 분리 가능
RDS (MySQL) RDS 서비스 1 instance 외부 관리 DB
로그 수집 DaemonSet (Fluent Bit) 각 노드 1개 로그 수집용
모니터링 Deployment (Prometheus, Loki) 1개씩 PVC 사용
시각화 Deployment (Grafana) 1개 퍼블릭 서브넷 배치
배포 자동화 Deployment (ArgoCD) 1개 GitOps 구성

1.4.2 오토스케일링 (HPA)

  • metric-server 설치
  • CPU 사용량 기준 HPA 구성 (예: 70% 초과 시 스케일 아웃)
yaml
복사편집
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef:
    kind: Deployment
    name: spring
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

1.4.3 장애 대응 및 롤링 배포

  • 모든 Deployment에 restartPolicy: Always 적용
  • Rolling Update로 배포, 상태 점검은 readinessProbe, livenessProbe 적용 예정
  • 로그 수집: Fluent Bit → Loki → Grafana, 또는 S3에 저장 (S3 Sink 적용 고려)

1.5. CI/CD 및 배포 고도화

1.5.1 Helm Chart

  • 모든 Deployment는 Helm Chart로 정의
  • 인프라 리소스와 애플리케이션을 템플릿화하여 간편하게 설치 및 버전 관리

1.5.2 ArgoCD

  • GitHub 저장소의 Helm Chart 디렉토리를 Watch
  • GitOps 방식으로 자동 동기화, 배포 이력 추적
  • AWS ECR → Pull → Deploy → HPA로 스케일 조정 흐름

1.6. 모니터링 및 로깅 아키텍처

1.6.1 Prometheus & Grafana

  • Prometheus는 각 서비스의 메트릭 수집
  • Grafana는 퍼블릭 서브넷에서 Prometheus 시각화
  • Spring Boot 애플리케이션은 Micrometer와 Actuator를 통해 메트릭 제공

1.6.2 로그 수집

  • Fluent Bit DaemonSet → Loki 저장소로 로그 수집
  • 필요 시 S3에 로그 보존 (추후 Athena/Glue 분석 가능)

1.7. 보완 및 개선 방향

  • 현재 구성은 Kubeadm 기반 수동 설치이므로, 관리형 서비스(EKS 등)로 이관 검토 가능
  • 스토리지는 현재 PVC(local storage) 기반이나, EBS 혹은 EFS 도입 고려
  • GitHub Actions와 ArgoCD 연계로 완전 자동화 배포 체계 구성 목표

📘 2. 설계 및 설정 명세

💰 3. 비용 계산 보고서

3.1. 개요

  • 본 문서는 하루 최대 접속자 150명을 기준으로 구성된 kubeadm 기반 마이크로서비스 아키텍처의 AWS 비용 산정 보고서다.
  • 모든 인프라는 EC2 인스턴스를 기반으로 구성되며, DB와 Redis도 EC2에 직접 설치해 운영 비용을 절감하였다.

3.2. 리소스별 비용 및 구성

리소스 유형 상세 구성 월간 사용량 가정 단가 (USD) 월 예상 비용 (USD) 비고
EC2 t3.medium x1 (Master node) 9시간/일 $0.0416/시간 $14.24 제어 플레인 노드
EC2 t3.large x4 (Worker node) 9시간/일 $0.0832/시간 $113.88 앱 트래픽 처리용 워커 노드
EC2 t3.micro x3 (Bastion, Grafana) 9시간/일 $0.0104/시간 $10.68 운영용 경량 서비스 및 접근용
EC2 t3.medium x2 (DB + Redis) 9시간/일 $0.0416/시간 $28.47 DB와 Redis 병합 운영
ALB Application Load Balancer x1 24시간/일 $0.0225/시간 $16.44 Ingress Controller 연동
NAT Gateway NAT + EIP x1 24시간/일 $0.045/시간 $47.31 Private Subnet 외부 호출용
CloudFront 데이터 전송 50GB 50GB $0.085/GB $4.25
WAF 웹 ACL x1 (1백만 요청) 1백만 요청 $5.00 + $0.60/M $5.60
ECR 컨테이너 이미지 저장소 x1 1GB 저장 $0.10/GB $0.10 기본 이미지 저장 용량 기준
SNS 월 1백만 요청 100,000건 $0.50/백만 요청 $0.00 무료 범위 내
Lambda 월 100회 호출 100회 무료 $0.00 무료 범위 내
CloudWatch 지표 수/로그 포함 - 무료 $0.00
Parameter Store 표준 파라미터 x10 표준 파라미터 무료 $0.00
S3 버킷 x2 (50GB 기준) 총 100GB 저장 + 100,000 요청 $0.023/GB $2.53 정적 파일 저장 용도

3.3. 총 예상 비용

  • 약 $243.50/ 월
  • 해당 비용은 On-Demand 기준, 하루 9시간 가동을 기준으로 AWS 요금 계산기에서 산출
  • 실제 사용 시간 및 트래픽에 따라 다소 차이가 발생할 수 있음

요금 계산서 바로가기

3.4. 참고 사항

  • CloudWatch 지표 수를 최소화하여 Prometheus로 내부 시각화, 알림은 필요한 핵심 지표만 CloudWatch로 전송하는 전략을 적용
  • EC2 기반 DB 구성 시 자동 백업 스크립트, 보안 설정 및 모니터링이 필수
  • cloud watch 지표는 프리티어 한도 내에서 최대한으로 활용하고, prometheus의 사용을 통해 비용 절약