AWS re:Invent 2024에서 소개된 EKS 하이브리드 노드를 소개합니다. AWS와 온프레미스 각각의 장점을 활용할 수 있는 하이브리드 클러스터 솔루션입니다. AWS EKS Anywhere, Outposts와 함께 제가 기다렸던 기능인데요. 이번에 소개된 하이브리드 노드는 일반 데스크탑도 EKS에 동적으로 추가할 수 있는, 좀 더 유연한 하이브리드 클러스터를 구성할 수 있는 솔루션입니다. 다음 AWS 업무에서 가장 먼저 도입을 검토해보고 싶은 기능입니다. 기존 기능들 보다 사용성이 좋을 것으로 기대하는 하이브리드 노드를 리뷰해보겠습니다.
✨ 1. 소개: EKS 하이브리드 노드
올해 AWS Summit Seoul 2024에서 AWS 직원이 곧 기존과는 다른 형태의 EKS 하이브리드 신기능이 나온다고 귀뜸을 해주셨거든요. 말씀하셨던 신기능이 드디어 출시되었습니다. 이름은 Amazon EKS Hybrid Nodes 입니다. 기존 EKS에 '하이브리드 노드' 기능을 활성화하고 온프레미스 노드를 추가할 수 있습니다. 그럼 온프레미스 노드를 마치 EC2 인스턴스처럼 사용할 수 있습니다. 쉽게 생각하면 하나의 쿠버네티스 클러스터에서 EC2와 내 데이터센터 GPU 서버를 함께 제어할 수 있는 것이죠.
💬 1.1. 이 리뷰를 하는 이유
공식 블로그 문서가 있음에도 이 리뷰는 하는 것은, 실무자의 입장에서 도입 여부를 판단해야 하기 때문입니다. 이유를 정리하면 다음과 같습니다:
- 하이브리드 클러스터를 지원하는 새로운 기술에 관심이 많음
- 이 기능을 도입으로 생기는 장점과 단점을 미리 파악할 필요 있음
- 특히 최고 성능과 최소 비용을 파악해야 함 (의사결정에 꼭 필요합니다)
🧐 1.2. 기존 서비스와 비교
기존 EKS 하이브리드 서비스와 비교하면 이런 차이가 있습니다. 공식 블로그의 표를 인용합니다. 저의 이해로는 Outposts는 온프레미스 상품으로 알고 있습니다. 공식 표에서는 하드웨어에 대해 'AWS 관리' 라고 표기되어서 아래 영상을 통해 정정하고자 합니다.
위 영상의 10:39 부터의 설명으로는 Outposts는 AWS에서 제공하는 하드웨어 (서버 및 네트워크 스위치)를 데이터 센터 및 고객사에 설치하여 운영하는 것으로 알고 있습니다. 이 부분은 더블체크가 필요할 것 같습니다.
따라서 블로그의 표를 제 버전으로 수정하면 다음과 같습니다:
| 구성 요소 | EKS on Outposts | EKS 하이브리드 노드 | EKS Anywhere |
| 하드웨어 | 고객 관리 (AWS 판매 하드웨어) | 고객 관리 (사용자 구축) | |
| Kubernetes 컨트롤 플레인 | AWS에서 호스팅 및 관리 | 고객이 호스팅 및 관리 | |
| Kubernetes 노드 | Amazon EC2 지원 | 고객이 관리하는 물리적 또는 가상 머신 | |
| 동적 EC2 노드 생성 | O (AWS 가용영역) | O | X |
각 EKS 하이브리드 배포 옵션을 사용하여 Kubernetes 및 하드웨어 구성 요소를 관리하는 방법 < AWS 공식 표를 수정한 버전 >
각 서비스를 요약하면 다음과 같습니다
- AWS Outposts
- 'AWS 사설 가용영역을 만들어서 사용하기'
- AWS에서 판매하는 표준 하드웨어, 소프트웨어로 온프레미스를 사설 가용영역(AZ)으로 등록
- EC2, ECS, EKS 구성가능. 데이터는 온프레미스에서 처리, 모니터링은 AWS 콘솔에서 가능
- EKS Anywhere
- '온프레미스 클러스터를 AWS에서 제어하기'
- AWS에서 제공하는 소프트웨어로 EKS를 구성 (동적 노드 프로비저닝 불가)
- 컨트롤 플레인과 워커 노드 모두 온프레미스 구성; 데이터는 온프레미스에서 처리, 모니터링은 AWS 콘솔에서 가능
- EKS 하이브리드 노드
- 'AWS EKS에 온프레미스 노드 추가하기'
- AWS 콘솔에서 일반 EKS를 구성하고, 설정에서 하이브리드 노드 활성화
- 컨트롤 플레인은 AWS, 워커 노드는 AWS과 온프레미스 모두 가능
AWS Outposts는 모든 인프라를 별도 주문해야 합니다. EKS Anywhere는 내 서버들로 할 수 있지만 컨트롤 플레인, 워커 노드를 OS까지 모두 재설정 해야합니다. 장점은 IAM을 쓸 수 있다는 건데, 그냥 Teleport같은 IAM을 제공하는 k8s 오픈소스를 쓰는 걸 권장합니다. 하지만 EKS 하이브리드 노드는 평범한 EKS 클러스터에 VPN과 함께 온프레미스 노드를 추가하면 됩니다. 노드 1대만 있어도 바로 시작할 수 있을 정도로 진입장벽이 매우 낮고, 설정이 유연하기 때문에 하이브리드 인프라 도입을 위해 고려하기 좋은 확장기능입니다.
🧐 2. 아키텍처 분석
그럼 하이브리드 노드는 어떤 불편을 해결해줄까요? 가장 큰 장점은 관리와 통신을 매우 편하게 해준다는 겁니다. 비교를 위해 하이브리드 클러스터를 가정하겠습니다.
- 클러스터 그룹 A: API 게이트웨이로 연합한 하이브리드 클러스터
- 온프레미스 클러스터 (데이터 센터)
- 3대의 컨트롤 플레인
- 5대의 GPU 워커 노드
- 퍼블릭 클러스터 (AWS EKS)
- 관리형 컨트롤 플레인
- 2대의 CPU 워커 노드 (EC2)
- 온프레미스와 연결된 API 게이트웨이
- 온프레미스 클러스터 (데이터 센터)
- 클러스터 그룹 B: 하이브리드 노드를 사용한 EKS 클러스터
- 퍼블릭 클러스터 (AWS EKS)
- 관리형 컨트롤 플레인
- 5대의 GPU 워커 노드 (하이브리드 노드)
- 2대의 CPU 워커 노드 (EC2)
- GPU 서비스를 실행할 API 서버
- 퍼블릭 클러스터 (AWS EKS)
그림으로 표현하면 다음과 같습니다.
위 클러스터 그룹 A는 제가 현업에서 사용하고 있는 하이브리드 아키텍처입니다. 두 클러스터가 하나의 서비스를 위해 연합하는 구조입니다. 퍼블릭 클러스터(AWS EKS)에는 웹 서비스가 배포되어 있습니다. 사용자는 웹 서비스에서 ML 서비스를 호출합니다. 여기에 연결된 API 게이트웨이가 온프레미스 클러스터 의 ML API로 요청을 보내고 냅니다. 그리고 GPU 노드가 AI 모델 혹은 파이프라인을 동작시킨 후 퍼블릭 클러스터로 결과를 반환하여 사용자에게 결과를 제공합니다. 트래픽이 클러스터를 넘나들어야 하기 때문에, 과정이 복잡해보입니다 🥲.
위 클러스터 그룹 B는 EKS 하이브리드 노드로 아키텍처입니다. 하나의 클러스터에 웹 서비스와 ML API가 함께 있기 때문에, 별도의 게이트웨이 없이 바로 AI 모델을 동작시킬 수 있습니다. API 게이트웨이가 하는 일을 EKS 하이브리드 노드 설정으로 대체하였기 때문에, 아키텍처가 매우 단순해졌습니다.
이 내용에 대한 AWS re:Invent 2024 소개 영상도 함께 첨부합니다.
https://www.youtube.com/watch?v=ZxC7SkemxvU
EKS 하이브리드 노드 소개 및 구성법
https://www.youtube.com/watch?v=QMzor8haEOM
EKS 하이브리드 노드 소개 및 사용 사례
🥹 3. 장단점
클러스터 그룹 A와 클러스터 그룹 B의 동작은 매우 유사합니다. 하지만 클러스터가 나누어져 있고, 합쳐져 있는 차이는 관리와 개발에 큰 차이를 가집니다.
하이브리드 노드의 장점은 다음과 같이 비교할 수 있습니다:
- 그룹 A의 경우, EKS에서 온프레미스의 GPU 리소스를 조회하려면 API 게이트웨이의 엔드포인트를 작성하고 배포를 갱신해야 합니다.
- 그룹 B의 경우, EKS에서 GPU 리소스를 조회하려면, 바로 `kubectl` 명령 혹은 모니터링 도구로 바로 확인할 수 있습니다. 이러한 장점이 개발과 모니터링의 효율성을 올려주고, 서비스 품질을 더 올릴 수 있는 환경이 됩니다.
이런 차이로 얻을 수 있는 장점을 정리하면 다음과 같습니다:
- 장점 1: 클러스터 컨텍스트를 전환할 필요없습니다.
- k9s 혹은 lens를 사용하신다면, 하나의 컨텍스트에서 모든 인프라를 관리할 수 있습니다. 엄청난 장점입니다
- 장점 2: API 게이트웨이 없이 하이브리드 클러스터를 운영할 수 있습니다. 아키텍처가 간단해집니다.
- 파이프라인 및 API 개발 중 온프레미스, 퍼블릭의 상태를 조회하기 위해 'API 게이트웨이 엔드포인트를 개발/배포 하는 것' 대신, '실시간으로 k8s 상태를 확인'하면 됩니다. 이 차이는 비니지스 로직의 개발 속도를 훨씬 빠르게 해 줄거에요.
- 장점 3: 두 클러스터가 하나가 되었기 때문에 DevOps 도구를 이중화 할 필요 없어집니다.
- k8s 레이블을 이용하여 두 환경을 구분하고, 단일 IAM / 모니터링 / 파이프라인 / 알림 / 장애대응 등을 통합관리할 수 있습니다.
- ex) 하이브리드 노드가 다운되면, 동일 기능을 하는 EC2 노드를 Karpenter로 빠르게 프로비저닝 할 수 있습니다. 이는 그룹 A로도 가능하겠지만, 복잡한 로직을 개발해야합니다.
단순한 아키텍처는 대규모 인프라에서 높은 효율성을 가져옵니다. 특히, AWS IAM으로 온프레미스 권한 도 제어할 수 있다면 DevOps 엔지니어들이 정말 편해질 것 같네요. 하지만 단점도 있습니다:
- 단점 1: 추가 비용이 발생합니다
- 아키텍처가 단순해진다는 것은 AWS가 대신 관리해주는 숨겨진 계층이 많다는 겁니다. 그럼 비용이 늘어나겠죠. 이 내용은 이후 섹션에서 자세히 다루겠습니다.
- 단점 2: AWS 의존성이 생깁니다
- AWS만 사용하는 경우, 결합성으로 생각할 수 있고, 오히려 장점이 될 수 있습니다.
- 멀티 클라우드: 비용 혹은 정책으로 AWS 이외의 Azure, GCP 등 여러 클라우드 공급자를 동시에 사용할 수 있습니다.
- AWS EKS에 결합해버리면 다른 클라우드와 통신하기 위해 홉이 늘어납니다.
- 그룹 A의 경우
- AWS → 온프레미스
- Azure → 온프레미스
- GCP → 온프레미스
- 그룹 B의 경우
- AWS → 온프레미스: AWS VPN(AWS Site-to-Site Direct Connect)만 거치면 됩니다
- Azure (→ AWS) → 온프레미스
- GCP (→ AWS) → 온프레미스
- 그룹 A의 경우
- 그룹 B의 형태가 개발 및 네트워크 비용이 커진다면 그룹 A 형태를 사용하는 것이 더 적합합니다.
🤔 4. 환경 설정 및 비용
4.1. 개요
- 블로그를 보니 설치법이 아주 간단하게 잘 소개되어 있습니다. 방화벽 설정만 쉽다면 EKS 하이브리드 노드는 설정이 쉬워보입니다.
- `nodeadm` 이라는 이름의 AWS EKS의 노드 제어 도구가 있습니다. `nodeadm`으로 하이브리드 노드를 초기화 하고 EKS에 join 시킬 수 있습니다. 설치 스크립트를 작성하여 자동화 할 수도 있겠네요
- AWS VPC와 온프레미스 데이터센터의 방화벽을 연결하여야 합니다. 이를 위해 인프라 엔지니어링의 도움을 받아야 합니다.
4.2. 네트워크 구조 및 비용
모든 일에는 영수증이 있죠. 그리고 EKS 하이브리드 노드를 위해 추가로 설정해야 할 리소스가 있습니다. 온프레미스와 AWS 네트워크를 연결하는 통신 레이어입니다. AWS의 빠르고 안정적인 인프라를 이용하는 만큼 과금도 감당해야 하는데요.
EKS 하이브리드 노드 공식 블로그의 사전준비를 보면서 예상해보겠습니다.
하이브리드 노드 기본 비율
| 사용 구간 | 시간 당 사용 코어 | 비용 |
| First 576,000 monthly vCPU-hours | ≤ 800 | $0.020 per vCPU per hour |
| Next 576,000 monthly vCPU-hours | ≤ 1,600 | $0.014 per vCPU per hour |
| Next 4,608,000 monthly vCPU-hours | ≤ 8,000 | $0.010 per vCPU per hour |
| Next 5,760,000 monthly vCPU-hours | ≤ 16,000 | $0.008 per vCPU per hour |
| Over 11,520,000 monthly vCPU-hours | > 16,000 | $0.006 per vCPU per hour |
코어 사용 구간에 따른 과금 표 < AWS 비용 차트 참조 >
- 노드 비용이 가장 중요한 부분인데요, 사용 구간에 따라 차등 요금을 가집니다.
- AWS에서 vCPU-hours 라는 표현은 실사용량이 아닌 임대의 개념입니다. 노드가 대기만 해도 과금이 되는 점 주의해주세요.
- 첫 번째 구간이 800 코어를 720시간(1달) 동안 사용한 구간입니다. 시간 당 800코어를 사용할 경우 $11,520를 하이브리드 노드 관리비용으로 지출하게 됩니다. 무시무시하네요. 그 이후로는 단가가 내려가지만 모두 첫 구간을 사용하는 것으로 가정하겠습니다.
- 예를 들어 16 vCPU의 하이브리드 노드를 1달 동안 EKS에 연결해 두겠습니다. 그럼 16 (코어) x 720 (시간) x 0.020 (비용) = $230.4 입니다.
- 비교를 위해 서울 리전의 g5.4xlarge (16 vCPU, 64 GiB)와 비교해 보겠습니다. 이 경우 $1458(3y-$630)가 과금됩니다. 전기와 통신 구독을 제외하더라도 경제적이라고 할 수 있겠네요.
VPN
그리고 VPN의 요금도 스팩이나 환경에 따라서 선택하실 수 있습니다. 블로그에서 권장하는 방식은 다음 둘 중 하나입니다.
- (보통)AWS Site-to-Site VPN: 활성화: $0.05/h (월 $72), 송신: 100GB까지 무료, 500GB까지 $0.09/GB, 수신: 1,000GB까지 (초과시 협의)
- (고속) AWS Direct Connect: https://aws.amazon.com/ko/directconnect/pricing/?nc=sn&loc=3 참조
- 이미 속도 때문에 Direct Connect를 사용하는 중이라면 구조만 변경하여 도입하는 것도 좋은 선택으로 보입니다.
나머지
- 나머지 IAM이나 RDS와 같은 관리형 서비스의 요금은 동일하게 사용량 만큼 과금됩니다.
이런 비용들이 추가로 발생하게 되는데요. 관리 편의성과 데이터 전송 비용을 비교하여, 사업성이 개선된다고 판단할 수 있다면 아주 좋은 솔루션이 될 것 같습니다.
만약 테스트로 구성한다면 작은 단위로 해야할 것 같습니다. 16코어 1대, 혹은 4코어 4대를 연결할 때 $230을 매달 지불해야하다니... 좀 부담스럽군요 (집에선 못 쓰겠네요 🥲). 누군가 제 계산이 틀렸고 더 저렴하다고 말씀해주시면 좋겠어요
🧑💻 5. 후기
유연하게 하이브리드 클러스터를 설정하고 관리할 수 있는, AWS 하이브리드 노드에 대해서 살펴봤습니다. 바쁜 일이 끝나면 AWS EKS 하이브리드 노드를 테스트할 계획입니다. 사용성이 편한지, 실제로 비용이 얼마나 나오는지 얼른 비교해보고 싶네요. 큰 주제로 다루지 못한 것을 몇 개 적어봅니다. 먼저 써보신 분이 있으면 댓글 부탁드립니다 🥹
API 게이트웨이 패턴에 대하여
- 하이브리드 클러스터를 구성하는 방법은 아주 다양합니다. API 게이트웨이를 사용하는 것은 한가지 사례입니다!
- 'API 게이트웨이 패턴' 대신 `k8s Service의 ExternalName` 혹은 `istio VirtualService`을 사용하여 온프레미스 클러스터와 연결할 수도 있습니다. 하지만 온프레미스 클러스터와의 통신 로직이 복잡할 경우, API 게이트웨이를 사용하여 라우팅 하는 것이 서비스 장애를 피할하는 좋은 선택이 됩니다.
🔍 6. 참조
작성을 위해 참조한 사이트입니다.
- 최초 소식: 링크드인 업데이트
- EKS 표준 비용: https://aws.amazon.com/ko/eks/pricing
- EKS 하이브리드 노드 메인: https://aws.amazon.com/ko/eks/hybrid-nodes
- EKS 하이브리드 노드 소개 블로그: https://aws.amazon.com/blogs/aws/use-your-on-premises-infrastructure-in-amazon-eks-clusters-with-amazon-eks-hybrid-nodes
- 기타
- EKS Anywhere: https://aws.amazon.com/ko/eks/eks-anywhere
- AWS Outposts: https://aws.amazon.com/ko/outposts
- AWS Site-to-Site VPN: https://aws.amazon.com/ko/vpn/site-to-site-vpn
읽어주셔서 감사합니다. 잘못된 부분이나 궁금한 점이 있으시면 댓글 부탁드립니다.
'DevOps' 카테고리의 다른 글
| 🛥️ Kind#1: 멀티 노드 클러스터 생성하는 명령어 정리 (0) | 2025.01.07 |
|---|---|
| ⚓️ Helm#1: pull 명령어 정리 (0) | 2024.12.27 |
| 🍩 호머(Homer)#2: 호머로 만든 쿠버네티스 네이티브 대시보드를 소개합니다 (0) | 2024.11.26 |
| 🐙 GitOps#2: Argo CD와 Git으로 커스텀 차트 배포하기 (1) | 2024.11.25 |
| 🐙 GitOps#1: Argo CD와 함께 GitOps 시작하기 (1) | 2024.11.21 |
어제보다 오늘 더 공부 잘하는 코딩냥이. 어제보다 오늘 더 일 잘하는 코딩냥이.
포스팅이 좋았다면, 오류를 발견했다면, 더 좋은 아이디어가 있다면 댓글 부탁드립니다!
