[reinvent 2024] 온프레미스 애플리케이션에 Amazon EKS의 강력한 성능 제공
Summary
온프레미스에서 Kubernetes 컨트롤 플레인을 관리하고, 온프레미스와 클라우드에서 별개의 클러스터를 운영하는 것은 많은 공수가 들어가는 일입니다. 이 세션에서는 온프레미스, 엣지 컴퓨팅 및 기 사용중인 다른 클라우드 환경의 자원을 Amazon EKS 클러스터의 노드로 활용할 수 있는 새로운 기능 Amazon EKS Hybrid Node 기능을 처음으로 소개합니다. Amazon EKS Hybrid Nodes 기능에 대한 소개, 데모 그리고 Northwestern Mutual의 사례에 대해 설명합니다.
리인벤트 2024 테크 블로그의 더 많은 글이 보고 싶다면?
Overview
들어가며
이 세션은 새롭게 출시한 EKS Hybrid Node 기능에 대한 소개와 Northwestern Mutual의 사용 사례를 소개합니다. EKS Hybrid Node는 기존 온프레미스의 서버를 EKS의 워커 노드로 추가하는 기능입니다. 클라우드 마이그레이션 이후에 기존에 사용하던 온프레미스를 활용하는 방법으로 고객분들이 많이 문의하던 기능 중 하나였기 때문에 이 소식을 빠르게 전달드리고자 합니다.
온프레미스에서 쿠버네티스를 운영할 때의 도전 과제
EKS를 사용하는 곳은 높은 확률로 온프레미스에서도 쿠버네티스를 사용하고 있습니다.
온프레미스 쿠버네티스를 운영할 때는 클러스터 인증서 만료, DHCP가 할당한 IP의 만료 등에 대한 문제들을 겪게 됩니다. 이러한 문제들은 운영 오버헤드와 비효율성을 증가시킵니다. 쿠버네티스 운영에 대한 전문성을 가짐으로써 이러한 문제를 해결하고 싶겠지만, 너무 빠른 기술의 발전으로 인해 전문성을 가지기란 쉽지 않고 온프레미스 환경은 특히 더 그렇습니다.
환경의 차이가 도구나 시스템의 불일치를 만들고, 이것들이 사일로를 형성하게 됩니다.
AWS에서는 2019년에 EKS on Outpost를 런칭했고 임대한 Outpost 장비에서 EKS를사용할 수 있다는 점에서 고객들에게서 좋은 반응을 이끌어냈습니다. 하지만 보안상의 이유로 엄격한 네트워크 제약 조건을 가진 곳(예: 전자금융거래법이 적용되는 워크로드)이나, 아주 낮은 레이턴시나 엄격한 데이터 의존성을 가진 워크로드에는 적합하지 않았습니다. 이러한 이유로 자사의 데이터센터에서 EKS를 실행할 수 있는 EKS-Anywhere를 출시했습니다. 하지만 ESK-Anywhere는 고객이 직접 컨트롤 플레인까지 관리해야 하기 때문에, 관리가 더 힘들다는 단점이 있습니다.
Amazon EKS Hybrid Nodes는 EKS, EKS Outpost, EKS-Anywhere가 가지는 모든 장점을 종합하는 기능이라고 볼 수 있습니다. 컨트롤 플레인은 SaaS 형태의 EKS를 사용하고, 워커 노드로 온프레미스의 서버를 사용하기 때문에 엄격한 네트워크 분리나 데이터 종속성에 대한 요건을 만족할 수 있습니다. 사용 사례는 아래와 같습니다.
- EKS를 여러 환경에서 운영하는 엔터프라이즈 기업에 쿠버네티스 환경의 일반화 제공
- 자사의 데이터센터에서 보유한 GPU를 이용하여 머신러닝 워크로드를 수행
- 엄격한 네트워크 분리 요건이 있는 금융사
- 다양한 지역에서 동작하는 엣지 컴퓨팅을 한 클러스터로 관리하고 싶은 미디어 혹은 제조업
Deep Dive to EKS Hybrid Node
EKS Hybrid Nodes의 아키텍처는 위와 같습니다. Control Plane은 EKS와 동일하게 클라우드 환경에서 수행되고 다양한 환경의 컴퓨팅 자원을 워커 노드로 추가합니다. 애드온으로는 kube-proxy, CoreDNS, Calico/Cilium, ADOT/CloudWatch를 지원하고, AWS권한 부여 방법은 SSM/EKS Pod Identity/IRSA를 지원합니다. 하드웨어, 가상화 솔루션(VMWARE, Nutanix 등), 네트워킹 스토리지, 운영 체제 등은 고객이 관리해야 합니다.운영체제는 Ubuntu, RHEL, Amazon Linux 2023(가상화 환경에서만 사용 가능)만 지원합니다.
EKS Hybrid Node의 네트워크 아키텍처는 위와 같습니다. 여기서 자세한 설명은 생략하고, 네트워크 제약 조건만 말씀드리겠습니다.
- Worker노드는 VPC와 프라이빗하게 연결(예: S2S VPN, DX)되어있어야 합니다.
- VPC와 온프레미스의 라우터의 라우팅 테이블 설정을 적절하게 수행해야 합니다.
- 프라이빗 네트워크 연결이 100MB/s의 대역폭과, 200ms 이하의 레이턴시를 가지는 것이 권장됩니다.(워크로드나 로깅 시스템이 얼마나 AWS와 통신하는지에 따라 실제 요구 스펙은 상이합니다)
EKS 콘솔에서는 노드와 해당 노드에서 동작하는 파드들에 대한 정보들을 확인할 수 있습니다.
EKS Hybrid node 기능은 새롭게 생성하는 EKS 클러스터에서만 사용할 수 있습니다(기존 클러스터는 2025 1Q 런칭 예정). 이 기능은 기존 EKS와 동일하게 여러가지 방법으로 사용 가능합니다(EKS 콘솔, eksctl, CloudFormation, Terraform 등).
EKS Hybrid Node를 잘 사용하기 위해 추천하는 방법들은 아래와 같습니다.
- EKS Hybrid node 기능가 필요로 하는 모든 요소를 담은 Golden Image를 만들고, OS 프로비저닝 시 자동으로 EKS에 연결되도록 설정할 것
- 온프레미스와 가까운 지역의 리전을 사용할 것
- 이 기능을 사용할 때 발생하는 대부분의 문제는 네트워크와 보안의 문제이니, 네트워크 팀과 보안 팀과 협업할 것
- VPC가 EKS Hybrid node의 노드/파드와 통신이 가능하도록 Security Group을 적절하게 설정할 것
- Affinity/Anti-Affinity를 적절하게 이용하여 파드가 Hybrid node와 그렇지 않은 노드 중 어떤 노드에 배치될 지 지정할 것
- API 서버 엔드포인트는 Public 혹은 Private으로 지정할 것
- CoreDNS를 클라우드 환경과 온프레미스 환경에 적어도 한 개씩 배치할 것
- 노드가 어떤 AZ에 있는지 알 수 있도록 Zone 레이블을 사용할 것
- 쿠버네티스 버전을 업그레이드 할 때, In-Place가 아닌 Rolling upgrade로 할 것
- Hybrid node 사용 시 비용이 발생하므로, 필요하지 않은 노드는 중단해 놓을 것
Northwestern Mutual의 사례
Northwestern Mutual은 두 개의 데이터 센터를 운영하고 있었고, 쿠버네티스 컨트롤 플레인을 어떤 데이터 센터에 위치시킬 것인지에 대한 고민이 있었습니다. 한 쪽에만 배치하면 데이터 센터 장애가 발생했을 때 다른 데이터 센터도 영향을 받을 것이고, 양쪽 다 배치하면 관리 영역이 두 배가 되는 상황이었습니다. 이를 해결하기 위해 컨트롤 플레인을 클라우드 환경에서 운영하다가, Hybrid Node 기능이 나온 후로는 컨트롤 플레인을 EKS로 변경했습니다.
이는 성공적으로 동작했고, 다양한 장애 패턴을 시뮬레이션 했을 때 모두 의도한대로 잘 동작하는 것을 확인할 수 있었습니다.
결론
이 세션에서는 새롭게 출시한 EKS Hybrid Node 기능을 소개하였습니다. 이 기능은 워크로드를 클라우드로 마이그레이션한 고객들이 기존 데이터 센터를 활용하기 위한 방안으로 많은 문의가 있던 기능인만큼 활용도가 높을 것이라고 생각합니다. 다만 클라우드, 인프라 및 쿠버네티스에 대한 이해가 높지 않으면 초기 구축이나 운영 중 발생한 문제에 대한 트러블슈팅이 쉽지 않을 것 같다는 생각이 듭니다. 잘 사용하면, 복잡한 쿠버네티스 컨트롤 플레인 운영, 온프레미스와 클라우드 간의 더욱 심리스한 연결, 안정성이 높은 DR 구성 등의 이점을 얻을 수 있기 때문에 널리 사용되면 좋겠습니다.