ECS to EKS 인프라 마이그레션 Part 1
안녕하세요, 휴이노 서비스 플랫폼의 인프라를 개발 및 운영 중인 DevOps 스쿼드 박이삭 입니다. 서비스 플랫폼 백엔드 팀 내에서 인프라에 대한 관심이 많은 몇몇 분들이 모여 DevOps 스쿼드를 구성하였습니다. 이 기간 동안 인프라 개선 및 발견된 문제들을 해결해 나가는 과정에서의 경험을 이번에 공유하고자 합니다.
ECS 사용기
AWS Elastic Container Service(ECS)는 단순한 구조의 서비스를 운영하기에 적합하며, 직관적인 인터페이스와 옵션 덕분에 학습 곡선이 낮아 빠르게 익힐 수 있습니다. 하지만, 제한된 스케줄링 옵션, 네트워킹 복잡성, 서비스 발견 및 로드 밸런싱의 유연성 부족, 벤더 종속성, 그리고 상세한 모니터링 및 로깅 기능 부족으로 인해 복잡한 애플리케이션을 관리하기에는 적합하지 않습니다.
몇 달 전까지, 휴이노 서비스의 백엔드는 ECS, 특히 Fargate 옵션을 사용하고 있었습니다. 휴이노 서비스가 처음 시작될 때는 하나의 API 서버만을 운영했기 때문에, ECS는 그 당시 우리 서비스에 아주 적합한 선택이었습니다. 하지만 서비스가 점차 복잡해지고 인프라 운영의 난이도가 높아짐에 따라, 우리는 AWS의 Elastic Kubernetes Service(EKS)로의 전환을 고려하기 시작했습니다. 이제부터, ECS를 사용하면서 접하게 된 다양한 도전과제들과, 그로 인해 EKS로의 이전을 고려하게 된 사례들에 대해 소개하고자 합니다.
- Infrastructure as Code (IaC)
서비스 환경(Dev, QA, Staging, Prod)에 따라 변경 사항을 적용하는 과정은 인프라 관리의 필수적인 부분입니다. 하지만, ECS를 사용하면서 이러한 과정을 자동화하기가 어려웠던 점들이 있었습니다.
a. 각 환경에 적용해야 할 변경사항을 매번 정리해야 하는 번거로움이 있었습니다.
b. 변경 사항을 수동으로 적용하며 많은 시간이 소모되었습니다.
c. 수동 적용 과정에서 인간의 실수가 발생할 위험이 높았습니다.
d. 자동화를 위해 스크립트를 작성하는 경우, imperative 한 스크립트의 재사용성과 확장성이 낮아 효율적인 관리가 어려웠습니다. 또한, 하나의 스크립트에 대해 다양한 시나리오를 검증하는 데 필요한 시간이 현실적으로 부족하여 버그가 발생할 수 있는 여지가 있었으며, 이는 시스템 장애로 이어질 수 있는 위험이 있었습니다.
- CloudWatch의 제한적인 로그 수집, 쿼리 및 대시보드
AWS CloudWatch는 로그 수집, 쿼리 작성, 대시보드 구성 등의 기능을 제공합니다. 하지만, Logstash나 FluentD와 같은 도구들이 제공하는 로그의 패턴 매칭, 수정, 병합과 같은 고급 기능들에 비해 CloudWatch의 기능은 상대적으로 제한적입니다. 특히, Elasticsearch와 같은 설루션의 강력한 인덱싱 및 검색 기능과 비교할 때 CloudWatch의 한계는 더욱 두드러집니다. ECS 환경 위에서 Elasticsearch를 구현하는 방법도 존재하지만, 본질적으로 단순한 서비스 관리에 초점을 맞춘 ECS의 구조에 추가적인 복잡성을 도입하는 것이 바람직한 접근 방법인지에 대해서는 의문이 있습니다. - 제한적인 Metric
ECS에서의 메트릭 수집은 주로 CPU 사용량과 메모리 사용량에 국한되어 있습니다. 이는 백엔드 서비스에서 필수적인 API 트래픽, 지연 시간, 메소드별 통계와 같은 세부적인 정보의 추출을 지원하지 않는다는 의미입니다.
이와 대비하여, Prometheus 시스템은 Kubernetes 환경에 쉽게 설치할 수 있으며, 훨씬 더 다양하고 상세한 메트릭을 제공합니다. Prometheus를 ECS에 통합하는 것도 가능하지만, 이렇게 하면 ECS의 관리 복잡성이 증가하며, 이는 효율적인 시스템 관리를 위한 최선의 방법이 아니라고 판단했습니다.
- 마이그레이션
AWS 내에서 특정 고객 전용 인프라를 분리하는 마이그레이션 작업, 또는 클라우드 서비스 프로바이더 간의 이전 작업(예: AWS에서 NCP로의 이전)은 ECS를 사용하여 수행하기 어렵거나 때로는 불가능할 수 있습니다. CloudFormation이나 Terraform과 같은 IaC 도구가 존재하긴 하지만, 이러한 작업의 요구사항을 충족시키기에는 여전히 적합하지 않습니다. 특히, CloudFormation은 다른 테넌트 간의 이전을 지원하지 않는 등의 제한 사항을 가지고 있어, 이러한 복잡한 마이그레이션 요구사항을 충족시키는 데 한계가 있습니다. - 제한적 커뮤니티
ECS 관리하기 위한 3rd party 도구의 선택지가 제한적입니다.
Kubernetes 소개
Kubernetes는 오픈소스 컨테이너 오케스트레이션 플랫폼으로, 복잡한 컨테이너화된 애플리케이션의 배포, 관리, 확장을 자동화합니다. Kubernetes는 다양한 클라우드 환경에서 강력한 기능을 쉽고 효율적으로 이용할 수 있게 해주며, 다음과 같은 이점과 기능을 제공합니다.
- CNCF 및 Kubernetes 생태계: Kubernetes는 Cloud Native Computing Foundation(CNCF)에 의해 지원되며, 광범위한 오픈소스 도구, 라이브러리, 및 커뮤니티의 지원을 받습니다. 이는 지속적인 혁신을 가능하게 하며, 사용자가 필요에 따라 애플리케이션을 더 효율적으로 개발하고 확장할 수 있습니다.
- Kubernetes의 IaC(Infrastructure as Code) 관리 장점: Kubernetes는 declarative 설정을 사용하여 인프라와 애플리케이션 리소스를 관리합니다. YAML 또는 JSON 형식의 매니페스트 파일을 통해 클러스터의 상태를 정의할 수 있으며, 이를 Git과 같은 버전 관리 시스템에 저장하여 인프라의 버전 관리, 재사용성, 자동화를 가능하게 합니다. 이로 인해 인프라 설정의 일관성과 정확성을 높여줍니다.
- CRD(Custom Resource Definitions) 확장성: Kubernetes에서는 CRD를 사용하여 기본 제공 리소스 외에 사용자 정의 리소스를 생성하고 관리할 수 있습니다. 이를 통해 애플리케이션 특화 로직을 클러스터에 통합할 수 있어, 애플리케이션 요구사항을 더 잘 충족시키는 인프라를 구축할 수 있습니다.
- 다른 플랫폼으로 이전 용이성: Kubernetes를 사용하면 애플리케이션을 하나의 클라우드 프로바이더에서 다른 클라우드로, 또는 온프레미스 환경으로 쉽게 이전할 수 있습니다. Kubernetes는 다양한 환경에서 일관된 API와 추상화를 제공하기 때문에, 더 넓은 이식성과 유연성을 얻을 수 있습니다.
- Service Mesh로 MSA 네트워크 정의 기능: Service Mesh를 Kubernetes와 통합하여 마이크로서비스 간의 네트워킹, 보안, 모니터링을 세밀하게 관리할 수 있습니다. 이는 마이크로서비스 아키텍처(MSA)에서 서비스 간 통신의 복잡성을 추상화하고, 서비스의 발견, 부하 분산, 장애 감지, 암호화 등의 기능을 제공합니다.
- Namespace로 Virtual Cluster 기능: Namespace를 사용하면 단일 Kubernetes 클러스터 내에서 여러 가상 클러스터를 생성하고 관리할 수 있습니다. 이를 통해 리소스를 격리하고, 다양한 팀 또는 프로젝트 간에 클러스터를 공유할 수 있습니다.
- Built-in Load Balancer: Kubernetes는 LoadBalancer 서비스 타입을 제공하여, 애플리케이션 서비스에 대한 외부 접근을 자동으로 관리합니다. 이는 애플리케이션에 대한 부하가 증가할 때 자동으로 리소스를 조정하여 성능을 유지할수 있게 돕습니다.
- Network Abstraction: Kubernetes의 네트워킹 모델은 Pod 간의 통신, 서비스 발견, 그리고 외부 트래픽 관리를 단순화합니다. 그로 인해 안전하고 효율적인 네트워크 통신을 가능하게 합니다.
- Complex Scheduling Features: Kubernetes의 스케줄러는 리소스 요구사항, 하드웨어/소프트웨어/정책 제약조건, affinity 및 anti-affinity 설정, 데이터 지역성, 워크로드 간의 격리 요구사항 등을 고려하여 자동으로 Pod를 클러스터의 노드에 할당합니다. 이를 통해 리소스를 효율적으로 사용하고, 애플리케이션 성능과 가용성을 최적화할 수 있습니다.
Kubernetes를 사용함으로써, 개발자와 조직은 안정적이고 확장 가능하며 보안이 강화된 애플리케이션 인프라를 구축할 수 있습니다. 이는 클라우드 네이티브 애플리케이션 개발과 운영을 간소화하고, 시장 출시 시간을 단축시키는 데 기여합니다.
EKS 소개
EKS(Elastic Kubernetes Service)는 AWS에서 제공하는 관리형 Kubernetes 서비스입니다. EKS는 Kubernetes의 강력한 기능을 클라우드 환경에서 쉽고 빠르게 이용할 수 있도록 합니다.
EKS의 주요 장점은 다음과 같습니다.
- 완전 관리형 서비스: AWS가 Kubernetes 클러스터의 설치, 운영 및 확장을 관리합니다. 자세히로는 k8s의 control plan 파트와 worker node 인스턴스(EC2 or fargate) 관리를 해줍니다. 이는 개발자가 인프라 관리보다 애플리케이션 개발에 더 많은 시간을 할애할 수 있게 해줍니다.
- 고가용성: EKS는 여러 가용 영역에 걸쳐 Kubernetes 컨트롤 플레인을 자동으로 분산시키고, 고가용성을 보장합니다. 이는 서비스 중단 시간을 최소화하고, 신뢰성 있는 애플리케이션 운영을 지원합니다.
- 확장성: EKS는 수천 개의 컨테이너를 실행하고 관리할 수 있는 높은 확장성을 제공합니다. 애플리케이션의 수요 변동에 따라 자동으로 노드를 추가하거나 제거할 수 있습니다.
- Kubernetes 표준 준수: EKS는 Kubernetes 커뮤니티에서 정의한 최신 버전과 API를 지원합니다. 이는 다른 Kubernetes 환경에서 작업한 경험이 있는 사용자도 EKS를 쉽게 사용할 수 있게 해줍니다.
EKS를 사용함으로써 개발팀은 Kubernetes의 복잡한 관리 작업에서 벗어나 클라우드 네이티브 애플리케이션의 개발과 운영에 집중할 수 있게 됩니다. 이는 시간과 비용을 절약할 뿐만 아니라, 보다 안정적이고 확장성 있는 애플리케이션 인프라 구축을 가능하게 합니다.
ECS에서 EKS로 전환하는 전략적 이유
ECS 로 안정적인 서비스를 운영하고 있음에도, EKS 로 전환하는 이유는 다음과 같습니다.
- 서비스 관리의 복잡성 대응: 단일 API 서버에서 시작하여 워커, 서버리스, 그리고 모노리식에서 마이크로서비스 아키텍처(MSA)로의 전환 등, 점점 복잡해지는 서비스 확장을 효과적으로 관리하기 위해 EKS로의 전환이 필수적입니다.
- B2B 서비스의 인프라 분리 요구: 고객의 요구사항이나 서비스의 특성에 따라, 동일한 인프라를 여러 버전으로 개발하고 관리해야 하는 경우가 있습니다. 인프라를 코드로 관리하지 않을 경우, 앞서 언급한 문제들이 발생할 수 있습니다.
- 클라우드 서비스 프로바이더에 대한 종속성 최소화: 비즈니스 요구사항, 파트너십, 투자자 관계 등으로 인해 단일 CSP(Cloud Service Provider)에 대한 종속을 피할 필요가 있습니다. 현재 AWS를 사용하고 있지만, 내부적으로 다른 CSP로의 이전을 고려하고 있습니다. ECS만을 사용할 경우, 특정 CSP에 대한 종속성은 마이그레이션 시 발생하는 비용, 개발 시간, 서비스 안정성 등 여러 면에서 비효율적인 시나리오를 초래합니다.
고려사항
- 직접 관리에 따른 비용 증가: 많은 스타트업이 관리형 서비스를 선호하는 주된 이유는 개발 팀이 인프라를 직접 관리할 필요가 없기 때문입니다. 이는 개발자가 개발에 더 집중할 수 있도록 하며, 시장 진입 시간을 단축시킵니다. 그러나, 관리형 서비스는 커스터마이징의 제한과 함께 클라우드 서비스 제공 업체에 대한 종속성을 높일 수 있습니다. 이런 종속성은 비즈니스가 성장함에 따라 더욱 문제가 될 수 있으며, 필요한 개발 인력이 충분하더라도 서비스를 다른 환경으로 이전하는 데에는 큰 비용이 발생할 수 있습니다.
- 초기 인프라 비용 증가: EKS로의 전환은 로깅, 모니터링, CI/CD와 같은 추가적인 커스텀 시스템을 필요로 하며, 이는 초기 인프라 비용을 증가시킬 수 있습니다. ECS는 기본적으로 인스턴스 관리에 대한 비용을 청구하지 않지만, EKS는 클러스터 운영에 대해 시간당 $0.10의 추가 비용을 부과합니다. 그럼에도 불구하고, RDS, ElastiCache와 같은 관리형 서비스를 EKS로 이전할 경우, 전체 운영 비용을 절감할 있습니다.
다음 편 예고
이번 글에서는 ECS에서 EKS로의 마이그레이션을 결정하게 된 배경을 소개했습니다. 다음 글에서는 ECS에서 EKS로 실제로 이전하는 과정, 이 과정에서 마주친 문제들, 그리고 이전을 돕기 위해 사용한 다양한 기술과 도구들에 대해 상세히 다룰 예정입니다. 실시간으로 운영 중인 안정적인 서비스를 어떻게 EKS로 옮겼는지, 프로토타입(Proof of Concept)과 테스트를 통해 시스템의 안정성을 어떻게 검증했는지에 대한 경험을 공유하겠습니다. 또한, Kubernetes와 그 생태계를 활용하여 시스템 전환을 어떻게 효율적으로 진행했는지 자세히 설명하겠습니다.
