EKS 아키텍처 다이어그램

EKS 클러스터에서 서비스가 구성된 전반적인 구조를 나타낸 다이어그램입니다.
(예: 클러스터 노드 배치, 각 파드가 어떤 노드에 있고 어떤 서비스로 묶여있는지, 외부 요청이 Ingress를 통해 파드로 전달되는 경로 등)

---

설계 설명 및 타당성 보고서

왜 Kubernetes(EKS)를 도입하기로 했는지 서비스 맥락에서 충분히 설명한 문서입니다.
여기에는 Kubeadm 대비 추가로 충족해야 할 요구사항과 Amazon EKS로 그것을 해결하는 방식이 포함됩니다.
(예: 고급 배포전략 필요 → Kubernetes의 Rolling Update 및 Canary 구현으로 대응)
또한 Kubernetes 리소스 선택과 구성에 대한 설명(Deployment vs StatefulSet 사용 이유 등)을 담아 설계상의 의사결정 근거를 명확히 합니다.

---

1. 도입 배경 및 필요성

서비스의 안정적인 운영과 지속적인 배포를 위해 컨테이너 오케스트레이션 플랫폼의 도입이 필요했습니다.
특히 다수의 애플리케이션 및 인프라 서비스를 효율적으로 관리하고, 배포 자동화 및 롤백 기능을 통해 개발 생산성과 장애 대응력을 높이기 위해 Kubernetes를 도입하였으며, 그 구현체로는 AWS에서 제공하는 Amazon EKS를 채택하였습니다.

직접 구성(Kubeadm 등)하는 Kubernetes 클러스터는 운영 복잡성과 안정성 문제가 있었고, EKS는 다음과 같은 이점을 제공하므로 선택하게 되었습니다:

• AWS IAM, ALB, ACM, VPC 등과의 자연스러운 통합
• 관리형 Control Plane으로 운영 부담 감소
• 최신 보안 패치 및 고가용성 제공

---

2. 클러스터 구성 및 리소스 선택

🧱 클러스터 구조

• Amazon EKS 기반 클러스터 구성
  • 워커 노드는 서비스(app) 와 인프라(infra) 역할로 분리하여 자원 격리 및 효율적 운영
  • 컨트롤 플레인과 데이터 노드를 분리하여 관리 효율성 확보
• GitHub Actions + ArgoCD 기반 GitOps 방식의 CI/CD 구성
  • 이미지 빌드 → ECR 푸시 → ArgoCD로 자동 배포

🔁 배포 전략

• Spring Boot 애플리케이션:
  • Deployment 리소스를 활용하여 RollingUpdate 방식의 무중단 배포
  • HorizontalPodAutoscaler를 통한 자동 확장
• Redis, ElasticSearch 등 상태 기반 서비스:
  • StatefulSet을 활용하여 각 Pod에 고유한 Volume 및 네트워크 ID 유지

🌐 네트워크 및 인증

• ALB Ingress Controller 도입
  • 사용자 요청: Route53 → CloudFront (정적 자원) 또는 ALB → Ingress → Kubernetes 서비스
  • alb.ingress.kubernetes.io 어노테이션을 활용하여 HTTPS 및 경로 기반 라우팅 처리
  • ACM 인증서를 통해 TLS 종단 보안 적용
• 내부 통신은 VPC 및 서브넷 분리로 격리

📊 로깅 및 APM

• Elastic Stack (ELK + APM):
  • ElasticSearch + Logstash + Kibana + Filebeat + Metricbeat
  • Application 성능 모니터링 및 실시간 로그 집계
  • EKS 로그는 Filebeat와 함께 Elastic으로 수집 가능

---

3. 기술 선택 비교 (Kubeadm vs EKS)

항목	Kubeadm 직접 구성	Amazon EKS 기반 구성
운영 관리	컨트롤 플레인 직접 구성, 유지보수 필요	AWS에서 Control Plane 관리, 운영 부담 낮음
AWS 통합	IAM/ALB/ACM 별도 구성 필요	AWS 리소스와 네이티브 연동
보안 업데이트	수동 패치 필요	자동 패치 및 고가용성 관리
CI/CD 구성	Helm, kubectl 등 스크립트 기반	ArgoCD 기반 GitOps, ECR와 자연스럽게 연동
비용	낮을 수 있으나 인건비 및 유지보수 비용 존재	예측 가능한 비용, 운영 인력 최소화 가능

---

4. Kubernetes vs EC2 기반 서비스 비교

항목	EC2 기반 배포	Kubernetes(EKS) 기반 개선점
배포 방식	수동 또는 스크립트 기반 배포	Declarative한 RollingUpdate 및 Canary 지원
롤백	복잡한 수동 작업	kubectl rollout undo로 즉시 롤백 가능
스케일링	수동 스케일링	HPA 기반 자동 스케일링
가용성	인스턴스 장애 시 수동 복구 필요	Pod 단위 자동 복구(Self-healing)
배포 자동화	별도 CD 파이프라인 필요	GitOps 기반 ArgoCD 자동화
모니터링/로깅	CloudWatch 중심	Elastic Stack 통한 고급 분석 및 APM 도입

---

5. 요약

Amazon EKS는 Kubernetes의 강력한 기능을 그대로 활용하면서도, AWS 클라우드 환경에서 안정적이고 운영 효율적인 인프라를 구축할 수 있도록 지원합니다.

본 아키텍처에서는 다음을 구현하였습니다:

• EKS 기반 클러스터 운영 및 서비스 배포
• 무중단 롤링 배포 + Canary 전략
• ArgoCD 기반 GitOps 방식의 CI/CD 자동화
• Elastic APM 기반 실시간 모니터링 및 문제 추적
• 서비스/인프라 노드 분리 운영을 통한 안정성 강화

이러한 요소들은 서비스의 신뢰성, 확장성, 가시성, 배포 효율성을 모두 향상시켜 실제 운영 환경에 적합한 현대적 인프라 구조를 완성하는 데 크게 기여하였습니다.

---

Kubernetes 리소스 명세서

서비스 배포에 사용되는 주요 Kubernetes 리소스들의 설정 값을 표 또는 목록으로 제시합니다. (예: 각 Deployment의 이름, Replica 개수, 컨테이너 자원 할당(CPU/메모리), 사용 이미지, 적용된 HPA(Horizontal Pod Autoscaler) 설정, ConfigMap/Secret 항목 등) 또한 클러스터 구성에 특이사항이 있다면 (예: Node 간 스케줄링 제한, Taint/Toleration, 네트워크 정책) 함께 기술합니다. 가능하다면 부분적인 YAML 매니페스트 예시를 포함하여, 실제 구현에 가깝게 표현합니다.

추가 자료(선택)

Kubernetes 환경에서의 배포 시나리오를 보여주는 예시를 포함할 수 있습니다. (예: 신규 버전 배포 시 Rolling Update가 진행되는 순서를 도식화, 실패 시 Helm Rollback 예시, Kubernetes Dashboard나 kubectl 출력 예시 등) 이러한 자료를 통해 Kubernetes 도입의 효과와 운영 과정을 더욱 명확히 전달하십시오.