[CL]6단계_Kubernetes기반_배포_자동화 - 100-hours-a-week/12-marong-Wiki GitHub Wiki

☸️ EKS 도입 및 Kubernetes 전환 상세 설명서

마롱(Marong) 서비스는 다음과 같은 진화를 거쳤습니다:

Kubeadm 기반 수동 클러스터 운영은 개발 초기단계에서는 유효했지만, 서비스가 성장하면서 다음과 같은 한계에 직면했습니다:

항목	문제점	마롱 서비스에 미친 영향
수작업 클러스터 운영	워커 노드 추가, 장애 노드 교체, 버전 업그레이드 모두 수작업	이벤트 집중 시 노드 수요 급증 대응이 늦어 서비스 지연 위험 발생
복잡한 장애 대응	노드 장애 시 수동 복구 및 Pod 재배치 필요	마니또 공개 시점 트래픽 폭주에 즉각 대응이 어려움
가용성 구축 어려움	고가용성(HA) 구성을 직접 설정해야 함 (etcd 클러스터, 마스터 다중화 등)	장애 발생 시 전체 서비스 영향 가능성 높음
인프라 관리 부담	모니터링, 알림 시스템 구축 및 유지 직접 수행해야 함	운영 리소스 소모로 개발/비즈니스 집중도 저하
확장성 한계	클러스터 스케일링이 자동화되어 있지 않음	사용자 수 급증 시 원활한 대응 불가

"Kubernetes는 직접 운영하지 말고, 관리형 서비스를 활용하라." — 업계 표준 방향

기존(Kubeadm)	개선(EKS)
수작업 운영	AWS가 Control Plane 관리 (APIServer, etcd, Controller HA)
수동 업그레이드	관리형 Kubernetes 버전 업그레이드 지원
보안 직접 구성	IAM 연동, 인증/권한 관리 쉽게 설정 가능
클러스터 확장 직접 구성	AutoScaling Group + Cluster Autoscaler 자동 확장 지원
노드 장애 수동 복구	헬스 체크 및 장애 시 자동 복구
부하 분산 수작업 설정	ALB Ingress Controller 기본 지원
모니터링 구축 필요	CloudWatch, Container Insights 기본 연동 가능
추가 스택 직접 설치	Istio, Prometheus도 Helm 차트로 쉽게 설치/업데이트

항목	기대 효과
개발 속도 향상	클러스터 운영 부담 감소로 신규 기능 개발/배포에 더 많은 리소스 투입 가능
장애 대응 체계 강화	자동 복구 + 모니터링으로 사용자 신뢰도 제고
비용 최적화	워커 노드를 필요할 때만 자동 확장/축소하여 리소스 과잉 사용 방지
해외 확장 가능성	EKS를 통한 멀티 리전 구성 용이 → 해외 서비스 진출 시 유연성 확보
보안 강화	IAM Roles for Service Accounts(IRSA) 활용해 서비스별 최소 권한 부여 가능

항목	내용
운영 관리 최소화	EKS가 Kubernetes Control Plane을 운영
서비스 확장성 확보	자동 스케일링 기반 부하 대응
무중단 배포 강화	Rolling Update, Canary 지원
트래픽 집중 대응	HPA + ALB Ingress로 탄력적 부하 분산
관측성 강화	Istio, Prometheus 기반 실시간 모니터링 체계 구축

"마롱은 서비스 확장성과 안정성을 확보하기 위해 Kubernetes 기반 아키텍처로 전환했으며, 관리형 EKS 도입을 통해 운영 효율성과 비즈니스 민첩성을 동시에 달성했습니다."