Topology Aware Hints가 Amazon EKS 네트워크 트래픽에 미치는 영향 살펴보기

이번 게시글은 영문 게시글(Exploring the effect of Topology Aware Hints on network traffic in Amazon Elastic Kubernetes Service, by Bingjiao Yu, Niall Thomson, and Xiangyan Wang)의 한글 번역글입니다.

참고: 쿠버네티스 1.27 버전에서 Topology Aware Hints는 Topology Aware Routing으로 이름이 변경되었습니다. 이 게시물에서는 작성 당시 기능의 이름으로 Topology Aware Hints를 사용했습니다.

소개

AWS에서 복원력 있는 시스템을 설계하는 모범 사례로서 여러 가용 영역(Availability Zone) 을 활용하는 방법이 있습니다. AWS의 리전은 서로 독립적으로 설계된 여러 가용 영역으로 구성되며, 각 가용 영역은 서로 연관된 장애 상황을 피하기 위해 유의미한 거리를 두고 물리적으로 분리되어 있습니다. 고객들은 Amazon Elastic Kubernetes Service(Amazon EKS)를 통해 여러 개별 가용 영역에 미션 크리티컬한 워크로드를 실행할 수 있고, AWS의 글로벌 인프라를 Pod Topology Spread Constraints와 같은 쿠버네티스 기능과 결합하여 가용성을 높일 수 있습니다.

하지만 위와 같은 방식으로 워크로드를 설계할 경우, 지연 시간과 비용 측면에서 고려해야 할 사항들이 있습니다. 동일 Amazon EKS 클러스터 내의 Pod는 서로 다른 가용 영역에 있더라도 연결된 Pod로 트래픽을 라우팅하는 쿠버네티스의 Cluster IP 타입 Service를 사용하여 쉽게 통신할 수 있습니다. 이 방법은 여러 가용 영역을 편리하게 활용할 수 있는 방법이나, 일부 고객들은 발신자 Pod와 같은 가용 영역에 있는 Pod로 트래픽 라우팅을 한정하고자 할 수 있습니다. 트래픽을 동일한 가용 영역에 유지함으로써 지연 시간에 민감한 워크로드에 짧은 지연 시간이 적용되고 가용 영역 간 데이터 전송 비용을 줄일 수 있습니다.

Topology Aware Hints (TAH) 는 쿠버네티스 1.23 버전부터 베타 상태로 사용할 수 있으며, Amazon EKS 에서는 1.24 버전부터 사용할 수 있는 기능입니다. 이는 동일한 가용 영역 내에서 트래픽을 원본과 더 가깝게 유지하려는 메커니즘을 제공하기 위한 기능입니다. 이 게시물에서는 Topology Aware Hints 기능을 Amazon EKS와 함께 사용하는 방법, Amazon EKS 클러스터 내에 다수의 가용 영역에 배포된 Pod 간 트래픽이 라우팅에 미치는 영향, Amazon EKS 지연 시간 및 가용 영역 간 데이터 전송 비용을 최적화할 수 있는지 여부를 살펴보겠습니다.

솔루션 개요

Topology Aware Hints(TAH) 의 동작 방식

쿠버네티스 서비스의 동작 방식

Topology Aware Hints의 작동 방식을 소개하기 전에 쿠버네티스 Service의 작동 방식을 소개하도록 하겠습니다. Service를 생성할 때 특정 Pod를 타겟으로 하는 셀렉터를 지정하게 됩니다. 쿠버네티스는 Endpoints 오브젝트를 생성하며, 이 오브젝트는 관련 된 Pod들의 IP 주소들로 채워집니다.

다음으로 쿠버네티스 컨트롤러는 Service에 Cluster IP를 할당합니다. Cluster IP는 virtual IP이며 쿠버네티스 클러스터의 워커 노드에서만 라우팅할 수 있습니다. DaemonSet으로 각 노드에서 실행되는 kube-proxy는 일련의 iptables 규칙 (또는 IP Virtual Server (IPVS)가 활성화 된 경우, virtual servers) 을 생성합니다. Cluster IP가 타겟으로 지정되거나 NodePort를 통해 트래픽이 클러스터에 진입하면 iptables 또는 IPVS의 로드 밸런싱 알고리즘에 따라 패킷을 Pod로 라우팅합니다. iptables의 경우 기본 로드 밸런싱 알고리즘은 랜덤이며, IPVS은 라운드 로빈 입니다.

기본적으로 kube-proxy는 Pod가 실행 중인 가용 영역 또는 트래픽이 시작되는 리전 등의 측면을 고려하지 않고 Endpoints 오브젝트의 모든 Pod를 각 노드의 iptables 또는 IPVS에 추가합니다. 즉, 패킷이 가용 영역 간에 무차별적으로 라우팅되어 잠재적으로 지연 시간이 발생하고 가용 영역 간 데이터 트래픽 비용이 발생할 수 있습니다.

Topology Aware Hints가 서비스 메커니즘을 변경하는 방법

Topology Aware Hints는 Endpoints의 하위 집합을 kube-proxy에 배치하여 트래픽 라우팅을 위한 대체 메커니즘을 활성화합니다.

Topology Aware Hints는 Endpoints보다 확장성이 뛰어난 EndpointSlice Controller에 의존합니다. Endpoint Controller의 Endpoints에는 Pod IP 주소와 포트만 포함되며, EndpointSlice에서는 Hints를 사용하여 설정할 수 있습니다. Hints는 각 Endpoints의 추가 레이블입니다. Topology Aware Hints는 Endpoints가 있는 가용 영역에 대한 Hints를 설정합니다.

Hints가 설정되면 kube-proxy는 Hints를 기반으로 Endpoints를 필터링합니다. 대부분의 경우 같은 가용 영역의 Endpoints를 선택합니다. 트래픽이 kube-proxy에 들어오면 트래픽 비용이 발생하지 않는 같은 가용 영역의 Pod로 라우팅 됩니다.

둘러보기

Amazon EKS Blueprints를 통해 Amazon EKS 클러스터를 배포하도록 하겠습니다. 해당 실습에서는 Hashicorp에서 개발한 오픈 소스 코드형 인프라 (IaC) 도구인 Terraform을 사용할 것입니다. 인프라를 템플릿으로 설계하고 Terraform을 사용하여 인프라를 프로비저닝, 관리 및 삭제할 수 있습니다.

Terraform은 클러스터 자체 외에도 Amazon EKS Blueprints 애드온을 통해 AWS Distro for OpenTelemetry (ADOT) Operator를 배포할 수 있습니다. ADOT Operator를 사용하면 Amazon EKS에서 실행되는 애플리케이션의 메트릭을 수집하고, 트레이싱을 간소화할 수 있습니다. ADOT Operator와 AWS X-Ray를 사용하여 Amazon EKS 클러스터에서 실행되는 워크로드 간의 요청을 시각화 해보도록 하겠습니다.

Amazon EKS 클러스터 및 관련 인프라가 생성되면 개별 프론트엔드와 백엔드 컴포넌트 간의 트래픽을 보여주는 리테일 샘플 애플리케이션을 배포합니다. 이를 통해 Amazon EKS 워커 노드 및 Pod의 다양한 구성이 Topology Aware Hints에 미치는 영향을 살펴볼 수 있습니다.

다음 다이어그램은 하이 레벨 아키텍처를 보여줍니다.

그림 1. 하이 레벨 아키텍처 다이어그램

사전 구성

실습을 진행하기 위해서는 다음과 같은 사전 조건이 필요합니다.

리눅스 운영 체제 및 쿠버네티스에 대한 기본 이해
AWS
필요 리소스 배포에 대한 어드민 혹은 그에 준하는 접근 권한
AWS Command Line Interface (AWS CLI) (v2.6.3+) 설치 및 구성
Terraform CLI 설치
Git CLI 설치
kubectl 및 helm 클라이언트 설치

클러스터 배포

Amazon EKS 클러스터와 ADOT 오퍼레이터를 배포하기 위한 Terraform 템플릿을 준비했습니다. 먼저 GitHub에서 샘플 소스 코드 리포지토리를 복제합니다.

git clone <https://github.com/aws-samples/containers-blog-maelstrom>
cd topology-aware-hints/terraform

(역자주: 배포 시에 문제가 발생한다면, 테라폼 VPC 모듈의 버전 문제로 topology-aware-hints/terraform/main.tf의 Line 157을 version = “~> 3.0″에서 version = “>= 5.0.0″으로 수정해야 합니다.)

다음 명령을 실행하여 클러스터를 배포합니다. 아래 예시의 ap-southeast-1을 실습할 리전으로 변경합니다. 해당 과정은 20-30분 가량 소요될 수 있습니다.

export AWS_REGION="ap-southeast-1"
terraform init
terraform plan
terraform apply -auto-approve

Terraform 명령어 실행이 완료되면 다음 명령을 실행해 kubectl을 설정할 수 있습니다.

aws eks --region $AWS_REGION update-kubeconfig --name tah-demo-cluster

다음 명령을 실행해 3개의 서로 다른 가용 영역에 노드가 분산 되었는지 확인합니다.

kubectl get node -ocustom-columns="Name:.metadata.name,Zone:.metadata.labels.topology\\.kubernetes\\.io/zone"

각 노드가 서로 다른 가용 영역에 배포되면 아래와 같은 결과가 표시됩니다.

Name                                             Zone
ip-10-0-10-61.ap-southeast-1.compute.internal    ap-southeast-1a
ip-10-0-11-169.ap-southeast-1.compute.internal   ap-southeast-1b
ip-10-0-12-8.ap-southeast-1.compute.internal     ap-southeast-1c

다음 명령을 실행하여 ADOT 오퍼레이터가 실행 중인지 여부를 확인합니다.

kubectl -n opentelemetry-operator-system get po

다음과 같은 결과가 표시됩니다.

NAME                                      READY   STATUS    RESTARTS   AGE
opentelemetry-operator-5878dff984-tmdj8   2/2     Running   0          73m

데모 애플리케이션 배포하기

아래 명령을 실행하여 샘플 애플리케이션을 배포합니다.

cd ../kubernetes
kubectl apply --server-side -f common.yaml
kubectl apply --server-side -f simple.yaml

아래와 같이 모든 애플리케이션이 실행 중인지 확인합니다.

$ kubectl -n ui get po
NAME                  READY   STATUS    RESTARTS   AGE
ui-54ff9f9457-hxzjq   1/1     Running   0          8m35s
ui-54ff9f9457-j4bqm   1/1     Running   0          8m35s
ui-54ff9f9457-kmhvq   1/1     Running   0          8m35s
$ kubectl -n catalog get po                                                                                                                                         
NAME                             READY   STATUS    RESTARTS   AGE
catalog-9745fbb6f-49pm2          1/1     Running   0          8m44s
catalog-9745fbb6f-dvvx6          1/1     Running   0          8m44s
catalog-9745fbb6f-qwxmc          1/1     Running   0          8m44s
catalog-mysql-65d9474b69-zx2pg   1/1     Running   0          9m7s
$ kubectl -n opentelemetry get po                                                                                                                                   
NAME                                 READY   STATUS    RESTARTS   AGE
default-collector-7c8db9f559-54mjc   1/1     Running   0          9m17s

다음 명령을 실행해 사용자 인터페이스(UI) 컴포넌트의 엔드포인트를 가져옵니다.

kubectl get svc ui-lb -n ui -o jsonpath={.status.loadBalancer.ingress[0].hostname}

해당 엔드포인트 링크에 접속해 데모 애플리케이션에 액세스할 수 있습니다. 데모 애플리케이션에 접속하면 온라인 쇼핑 사이트 예시가 표시됩니다.

초기 부하 테스트 실행

Amazon EKS 클러스터와 데모 애플리케이션을 배포했으므로 부하 테스트를 실행하여 트래픽을 시뮬레이션하고, 프론트엔드와 백엔드 간의 트래픽이 라우팅되는 방식을 확인할 수 있습니다. HTTP 요청을 보내는 작은 프로그램인 hey를 사용하여 트래픽을 생성하도록 하겠습니다.

Topology Aware Hints를 테스트하기 전, 비교를 위해 Topology Aware Hints가 적용되지 않을 경우 트래픽이 어떻게 라우팅 되는 지 확인하고 싶을 수도 있습니다. 데모 애플리케이션에 대해 부하 테스트를 수행하면 AWS X-Ray Service Map에 트래픽이 표시되어 위 내용을 확인할 수 있습니다.

다음 명령을 실행하여 UI 로드 밸런서에 부하 테스트를 진행합니다.

export UI_ENDPOINT=$(kubectl get svc ui-lb -n ui -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

kubectl run load-generator \\
  --image=williamyeh/hey:latest \\
  --restart=Never -- -c 10 -q 5 -z 60m http://$UI_ENDPOINT/home

AWS X-Ray 콘솔의 X-Ray Service Map 패널에서 데모 애플리케이션의 네트워크 흐름을 확인할 수 있습니다.

그림 2. AWS X-Ray Service Map에서의 데모 애플리케이션 네트워크 흐름

위 서비스 그래프에서 확인할 수 있듯, 각 UI Pod는 모든 가용 영역의 카탈로그라는 EC2 인스턴스 3개 모두에게 트래픽을 전송합니다.

Topology Aware Hints 활성화 후 부하 테스트 재실행

이제 Topology Aware Hints를 활성화한 후, 부하 테스트를 다시 실행하여 트래픽 라우팅이 개선 되는지 확인해 보도록 하겠습니다. 다음 명령을 실행하여 카탈로그 Service에서 Topology Aware Hints를 활성화합니다.

kubectl -n catalog annotate svc catalog service.kubernetes.io/topology-aware-hints=auto

다음 명령을 실행하여 hints 값이 설정되었는지 확인할 수 있습니다.

kubectl get endpointslices -l kubernetes.io/service-name=catalog -n catalog -o yaml

다음 예와 비슷한 결과를 얻을 수 있습니다. hints 값과 해당 가용 영역의 이름이 표시되면 Topology Aware Hints가 성공적으로 활성화된 것입니다.

addressType: IPv4
apiVersion: discovery.k8s.io/v1
endpoints:
- addresses:
  - 10.0.10.201
  conditions:
    ready: true
    serving: true
    terminating: false
  hints:
    forZones:
    - name: ap-southeast-1b

다음 명령을 실행하여 부하 테스트를 다시 진행합니다.

export UI_ENDPOINT=$(kubectl get svc ui-lb -n ui -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

kubectl run load-generator \\
  --image=williamyeh/hey:latest \\
  --restart=Never -- -c 10 -q 5 -z 60m http://$UI_ENDPOINT/home

그리고 다시 AWS X-Ray 콘솔로 이동합니다. AWS X-Ray Service Map 패널에서 데모 애플리케이션의 네트워크 흐름을 확인할 수 있습니다.

그림 3. Topology Aware Hints 활성화 후 네트워크 흐름

이제 각 UI Pod가 하나의 카탈로그 Pod로만 통신하는 것을 확인하실 수 있습니다. 또한 UI Pod는 항상 동일한 가용 영역에 있는 카탈로그 Pod와 통신한다는 것도 확인하실 수 있습니다. 해당 시나리오에서는 가용 영역 간 데이터 트래픽 비용이 발생하지 않습니다.

고려 사항

Topology Aware Hints는 쿠버네티스 클러스터 내에서 트래픽 라우팅을 제어하는 강력한 메커니즘이지만, 워크로드에 부정적인 영향을 미칠 가능성도 있습니다. Topology Aware Hints에는 고려해야 할 중요한 몇 가지 보호 규칙이 내장되어 있습니다. 경우에 따라 이러한 보호 규칙이 Topology Aware Hints 기능 사용을 무효화할 수 있기 때문에, 이 섹션에서는 이러한 보호 규칙이 클러스터 및 워크로드 아키텍처에 미치는 영향을 자세히 살펴보겠습니다.

고려해야 할 주요 보호 규칙은 각 가용 영역의 최소 엔드포인트 수입니다. 이는 특정 가용 영역이 다른 가용 영역보다 더 많은 용량을 가지고 있을 경우, 비슷한 비율의 엔드포인트 수를 가져야 함을 보장하기 위해 구현되었습니다. 이 보호 규칙은 특정 가용 영역이 과도한 트래픽을 받지 않기 위한 목적을 가지고 있습니다.

아래에서는 쿠버네티스 소스 코드에 따라 쿠버네티스 1.24 버전에서 사용된 알고리즘에 대한 내용을 요약한 것입니다. 해당 내용은 쿠버네티스 프로젝트에서 명시적으로 문서화되지 않았으며, 쿠버네티스의 추가 릴리스에서 변경될 수 있다는 점에 유의해야 합니다.

기대 비율 = 해당 가용 영역에 존재하는 노드의 vCPU 합계/클러스터 내 모든 노드의 vCPU 코어 합계
과부하 임계값 은 20% 의 상수 값입니다.
최소 엔드포인트 = 총 엔드포인트 수 * 기대 비율 / (1 + 과부하 임계값), 1의 자리 수 이하는 올림

위 알고리즘을 실제 상황에 적용해 설명하기 위해 몇 가지 예를 살펴보겠습니다.

예시1

가용 영역	A	B	C
vCPUs	4	4	4
엔드포인트 수	2	2	1
기대 비율	33.33%	33.33%	33.33%
최소 엔드포인트 수	1.39	1.39	1.39
충분한 엔드포인트 존재 여부	Yes	Yes	No

예시 1에서의 각 가용 영역에는 고르게 분배된 양의 vCPU 리소스가 있어 각 가용영역이 해당 Service에 대해 33.33%의 기대 비율에 해당하는 엔드포인트 수를 요구합니다. 하지만, 가용 영역 C는 1개의 엔드포인트만 제공하므로 해당 Service에서는 Topology Aware Hints를 활성화할 수 없습니다.

예시2

가용 영역	A	B	C
vCPUs	4	4	4
엔드포인트 수	2	2	3
기대 비율	33.33%	33.33%	33.33%
최소 엔드포인트 수	1.94	1.94	1.94
충분한 엔드포인트 존재 여부	Yes	Yes	Yes

예시 2에서는 예시 1과 동일하게 각 가용 영역에 vCPU가 고르게 분배되었지만 가용 영역 C의 엔드포인트 수가 증가했습니다. 이 예시에서는 최소 엔드포인트 수가 충족되었으므로 해당 Service에서 Topology Aware Hints가 활성화 됩니다.

예시3

가용 영역	A	B	C
vCPUs	8	4	4
엔드포인트 수	1	1	1
기대 비율	50.00%	25.00%	25.00%
최소 엔드포인트 수	1.25	0.75	0.75
충분한 엔드포인트 존재 여부	No	Yes	Yes

예시 3에서는 가용 영역간 리소스가 비례하지 않을 경우의 동작을 보여 줍니다. 이 예시에서 가용 영역 A에는 다른 가용영역에 비해 vCPU가 두배입니다. 즉, 가용 영역 A는 추가 용량을 반영하기 위해 기대 비율에 해당하는 엔드포인트 수를 제공해야 합니다. 각 영역에 대한 엔드포인트가 하나뿐이므로 요구 사항이 충족되지 않습니다. 예시 1과 마찬가지로 해당 Service에 대해 Topology Aware Hints가 활성화 되지 않습니다.

이러한 관찰을 통해 다음과 같은 일반적인 결론을 도출 할 수 있습니다.

Pod Topology Spread Constraints 기능: Topology Spread Constraints 기능을 사용하여 노드 및 가용 영역과 같은 다양한 장애 도메인에 Pod를 분산할 수 있습니다. 쿠버네티스 1.25 버전의 기본 클러스터 제약 조건에서는 가용 영역에 대해 maxSkew가 5로 구성되어 있으므로 replica 수가 적을수록 Topology Aware Hints가 활성화될 가능성이 낮아집니다. 특정 워크로드에서는 토폴로지 분산 제약 조건을 조정해야 할 수 있습니다.
멀티 테넌트 클러스터: 여러 이기종 워크로드가 클러스터를 공유하는 상황에서는 특정 가용 영역에 편향을 일으키는 워크로드가 Topology Aware Hints를 활용하는 다른 워크로드의 기능에 영향을 미칠 수 있는 상황이 있을 수 있습니다. 보호 규칙 알고리즘은 전체 클러스터의 vCPU 용량을 고려하고, 관리 노드 그룹과 같은 특정 용량 풀로는 범위를 지정하지 않기 때문입니다. 따라서 Topology Aware Hints 기능은 모든 워크로드가 가용 영역 간 균등하게 분산되는 클러스터에서 가장 잘 작동합니다.
오토 스케일링: Horizontal Pod Autoscaler를 사용하는 경우, Topology Spread Constraints로 인해 스케일링 중에 신규 생성되는 Pod가 여러 가용 영역에 분산됩니다. 하지만 축소 시 Deployment Controller는 가용 영역 밸런스를 고려하지 않고, Pod를 무작위로 종료합니다. 이로 인해 각 가용 영역의 엔드포인트가 불균형해져 Topology Aware Hints가 비활성화될 수 있습니다. Descheduler 도구를 사용하면 쿠버네티스 스케줄러가 적절한 제약 조건에 따라 파드를 다시 스케줄링할 수 있도록 부적절하게 배치된 파드를 Evict하여 Pod의 밸런스를 재조정할 수 있습니다.
관찰 가능성: 원문 포스트 작성 시점 기준으로 Topology Aware Hints는 과부하 상태와 관련된 이벤트를 제공하지 않습니다. 즉, 클러스터가 변경되면 위에 설명된 보호 규칙에 따라 별도 알림 없이 기능이 비활성화될 수 있습니다. EndpointSlice 객체의 상태를 모니터링하여 Hints가 활성화 되었는지 확인하는 것이 좋습니다.

더 살펴보기

위 예시에서 배포한 클러스터와 워크로드는 위의 고려 사항을 기반으로 시스템 구성이 Topology Aware Hints에 부합할 경우의 이상적인 시나리오를 보여줍니다. Topology Aware Hints가 다양한 기타 상황에서 동작하는 방식을 더 자세히 이해하기 위해 각 가용 영역에서 실행되는 노드 및 Pod 수를 변경할 수 있습니다.

예를 들어, 관리 노드 그룹 중 하나를 최대 두 개의 노드로 확장할 수 있습니다.

export TF_VAR_num_nodes_az1=2
terraform apply -auto-approve

샘플 코드 저장소에는 구성 요소를 가용 영역 별로 별도의 쿠버네티스 Deployments로 분할하는 별도의 워크로드 배포 아키텍처도 포함되어 있습니다. 이를 통해 가용 영역당 별도의 Pod replica 수를 구성하여 앞서 설명한 보호 규칙을 살펴볼 수 있습니다.

kubectl delete -f simple.yaml 
AWS_REGION=<replace-to-your-region> awk -i inplace '{ gsub(/{{region}}/,ENVIRON["AWS_REGION"]); print $0 }' experiment.yaml 
kubectl apply --server-side -f experiment.yaml

다음은 몇 가지 테스트 시나리오입니다.

다음은 위 예시에서 도출할 수 있는 추가 결론입니다.

Topology Aware Hints가 유효한 경우, kube-proxy는 적합한 엔드포인트가 존재하는 한 트래픽을 반드시 동일한 영역의 엔드포인트로 라우팅합니다. 적합한 엔드포인트가 존재하지 않는 케이스에서는 kube-proxy는 트래픽을 모든 엔드포인트로 라우팅합니다.
같은 가용 영역에 업스트림이 없는 엔드포인트에는 트래픽이 전송되지 않습니다. NodePort로 향하는 외부 트래픽은 Topology Aware Hints 범위에 해당하지 않습니다. 하지만 트래픽이 노드에 도달하면 kube-proxy에 의해 트래픽이 분산되며, Topology Aware Hints의 영향도 받게 됩니다.
Topology Aware Hints는 Headless Service에는 영향을 주지 않고, 모든 엔드포인트는 kube-dns에 의해 리졸브됩니다.
각 가용 영역의 Pod 수는 동일한 가용 영역의 vCPU 수에 비례해야 합니다. 최적의 상황은 노드를 가용 영역 간에 균등하게 분배하고 Topology Spread Constraints에 따라 Pod가 여러 가용 영역에 분산되는 것입니다.

리소스 정리

생성된 리소스를 삭제하여 추가 비용 발생을 피하도록 합니다. Terraform을 사용하여 간단하게 배포된 모든 리소스를 한 번에 삭제할 수 있습니다. 다음 명령을 실행합니다.

cd <folder>/kubernetes
kubectl delete -f experiment.yaml
kubectl delete -f simple.yaml
kubectl delete -f common.yaml

cd <folder>/terraform
terraform destroy -target="module.eks_blueprints_kubernetes_addons" -auto-approve
terraform destroy -target="module.eks" -auto-approve
terraform destroy -auto-approve

이제 실습 중에 생성된 모든 리소스를 삭제했습니다. AWS 콘솔에 남아 있는 Elastic Load Balancing (ELB) 이 있는지도 확인해 볼 수 있습니다. 발견하면 안전하게 삭제할 수 있습니다.

결론

이 포스트에서는 Topology Aware Hints의 작동 방식과 Topology Aware Hints가 Amazon EKS에서 실행되는 워크로드에 미치는 영향에 대해 개괄적으로 살펴보았습니다. Topology Aware Hints 기능은 트래픽이 출발하는 가용 영역과 같은 가용 영역 내에서 트래픽을 라우팅하려는 쿠버네티스 고유 기능이며, Amazon EKS 1.24 버전부터 사용할 수 있습니다. 아키텍처에 Topology Aware Hints를 적용하면 지연 시간 및 가용 영역 간 데이터 전송 비용을 줄이는 동시에 다중 가용 영역 아키텍처의 복원력을 향상할 수 있습니다. 그러나 과부하 메커니즘으로 인해 Topology Aware Hints는 워크로드가 가용 영역 간에 균등하게 분산될 때만 사용할 수 있습니다.

자세한 내용은 쿠버네티스의 Topology Aware Routing 공식 문서를 참조하십시오. 쿠버네티스는 지속적으로 개발이 진행되어 Topology Aware Hints의 동작이 향후 버전에서 변경될 수 있다는 점에 유의하시기 바랍니다. AWS 컨테이너 블로그에서 추가 업데이트를 확인하시길 바랍니다.

AWS 기술 블로그