EKS 클러스터로 TGC 구성원 담당하는 RPM 특정 프로젝트 마이그레이션 진행 및 완료
K8S 마이그레이션 작업은 완료 이후 기사화 되거나,
매 년 AWS 세션에 발표가 될 정도로 의미 있는 작업 입니다.
1. 인프라 관리 유연성
• 기존: 초기 인프라 세팅 후 지속적인 형상 유지가 어려움. 인프라 변경 및 추가 작업은 수동으로 이루어져야 하거나, 기존 환경을 삭제하고 새로 구축하는 방식으로 진행.
•변경 후: 선언형으로 인프라를 관리하며, 쿠버네티스가 자체적으로 리소스를 수정하여 필요한 인프라를 간편하게 변경 가능.
예시:
기존 ECS에서의 인프라 변경은 관리되지 않던 기존 변경 사항을 하나씩 싱크를 맞춘 후 새로운 환경을 구축 후에 라우팅을 넘기는 방식으로 진행, EKS에서는 manifest 파일에서 간단히 값을 수정하고 적용하면 자동으로 업데이트됨.
2. 인프라 확장성
•기존: ECS에서 제공하는 기본 기능 외에는 사용할 수 없으며, 새로운 요구사항 반영 시 기존 환경에 맞추는 작업이 어려움.
•변경 후: 오픈소스 커뮤니티와 유연한 사용자 커스텀을 통해 필요한 기능을 직접 구현하거나, 기존 오픈소스를 쉽게 도입하여 활용 가능.
예시:
AWS에서 기본 제공하지 않는 기능을 ECS에 적용하기가 불가능에 가깝고 , EKS에서는 요구사항에 따라 기존 인프라에 플러그인을 붙이듯 확장하여 클러스터 전반에서 확장 가능.
3. 인프라 비용 절감
•기존: 모든 서버를 비싼 Fargate로 운영하며, 서비스별로 별도의 로드 밸런서를 사용하여 비용 증가.
•변경 후: 테스트 환경에서는 Spot 인스턴스를 활용하여 서버 비용을 최대 90% 절감 가능하며, Ingress를 활용해 로드 밸런서를 통합하여 운영 비용을 20~30% 절감.
예시:
4. 인프라 자원 관리 효율성
•기존: 서비스별 사이드카 패턴으로 인해 소규모 서비스에서도 자원의 20~30%가 모니터링 용도로 소모됨. 이로 인해 자원 할당량이 적은 프론트엔드 서비스는 기본 매트릭 외에는 활용하지 못하고, 사이드카 장애 발생시 복구가 안됌.
•변경 후: DaemonSet을 활용하여 1:1 사이드카 대신 1:N 모니터링 구성을 통해 각 서비스에서 자원을 효율적으로 사용 가능.
예시:
기존 서비스에서 모니터링 용도로 할당 된 자원의 30%씩 사이드카에 할당했다면, EKS에서는 DaemonSet으로 운영하여 단일 노드에이전트를 통해 복수의 서비스의 모니터링을 진행.
문제 발생 시 의존성이 없으므로 데몬셋 자체적으로 복구 가능.
5. 인프라 생산성
•기존: 신규 서비스 생성 시 인프라 구축 후 태스크 정의(Task Definition)를 수동으로 서비스와 동기화.
•변경 후: 서비스 선언 단계를 통합하여 브랜치 기반 환경 등 유연한 환경 구성이 가능. 선언형 관리로 신규 서비스 추가 시 인프라와 애플리케이션 설정이 단일 프로세스로 진행.
예시:
ECS에서는 신규 API를 추가할 때 태스크 정의와 서비스 업데이트가 필요했지만, EKS에서는 Manifest에 새로운 값만 추가하여 배포 가능.