Answer:
---
search:
  exclude: true
---

# 비용 최적화 - 컴퓨팅 및 오토스케일링

개발자는 애플리케이션의 리소스 요구 사항(예: CPU 및 메모리)을 초기 예상하지만 이런 리소스 스펙을 지속적으로 조정하지 않으면 비용이 증가하고 성능 및 안정성이 저하될 수 있습니다. 초기에 정확한 예측값을 얻는 것보다 애플리케이션의 리소스 요구 사항을 지속적으로 조정하는 것이 더 중요합니다.

아래에 언급된 모범 사례는 비용을 최소화하고 조직이 투자 수익을 극대화할 수 있도록 하는 동시에 비즈니스 성과를 달성하는 비용 인지형 워크로드를 구축하고 운영하는 데 도움이 됩니다. 클러스터 컴퓨팅 비용을 최적화하는 데 있어 가장 중요한 순서는 다음과 같습니다:

1. 워크로드 규모 조정(Right-sizing)
2. 사용되지 않는 용량 줄이기
3. 컴퓨팅 유형(예: 스팟) 및 가속기(예: GPU) 최적화

## 워크로드 규모 조정(Right-sizing)

대부분의 EKS 클러스터에서 대부분의 비용은 컨테이너식 워크로드를 실행하는 데 사용되는 EC2 인스턴스에서 발생합니다. 워크로드 요구 사항을 이해하지 않고는 컴퓨팅 리소스의 크기를 적절하게 조정할 수 없습니다. 따라서 적절한 요청(request) 및 제한(limit)을 사용하고 필요에 따라 해당 설정을 조정해야 합니다. 또한 인스턴스 크기 및 스토리지 선택과 같은 종속성이 워크로드 성능에 영향을 미쳐 비용과 안정성에 의도하지 않은 다양한 결과를 초래할 수 있습니다.

*request*는 실제 사용률과 일치해야 합니다. 컨테이너의 request가 너무 크면 사용되지 않은 용량이 발생하여 총 클러스터 비용의 큰 부분을 차지합니다. 파드 내 각 컨테이너 (예: 애플리케이션 및 사이드카) 에는 총 파드 한도가 최대한 정확하도록 자체 request 및 limit을 설정해야 합니다.

컨테이너에 대한 리소스 요청 및 한도를 추정하는 [Goldilocks](https://www.youtube.com/watch?v=DfmQWYiwFDk), [KRR](https://www.youtube.com/watch?v=uITOzpf82RY), [Kubecost](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/)와 같은 도구를 활용하세요. 애플리케이션의 특성, 성능/비용 요구 사항 및 복잡성에 따라 어떤 메트릭을 확장하는 것이 가장 좋은지, 애플리케이션 성능이 저하되는 시점 (포화 시점), 그리고 그에 따라 요청 및 제한을 조정하는 방법을 평가해야 합니다. 이 주제에 대한 자세한 지침은 [애플리케이션 적정 크기 조정](https://aws.github.io/aws-eks-best-practices/scalability/docs/node_efficiency/#application-right-sizing)을 참조하십시오.

Horizontal Pod Autoscaler(HPA)를 사용하여 실행해야 하는 애플리케이션 복제본 수를 제어하고, Vertical Pod Autoscaler(VPA)를 사용하여 복제본 당 애플리케이션에 필요한 요청 수와 제한을 조정하고, [Karpenter](http://karpenter.sh/) 또는 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler)와 같은 노드 오토스케일링을 사용하여 클러스터의 총 노드 수를 지속적으로 조정하는 것이 좋습니다. Karpenter 및 Cluster Autoscaler를 사용한 비용 최적화 기법은 이 문서의 뒷부분에 설명되어 있습니다.

VPA는 워크로드가 최적으로 실행되도록 컨테이너에 할당된 요청 및 제한을 조정할 수 있습니다. VPA를 감사 모드에서 실행하여 자동으로 변경한 후 파드를 다시 시작하지 않도록 해야 합니다. 관찰된 메트릭을 기반으로 변경 사항을 제안합니다. 프로덕션 워크로드에 영향을 미치는 변경 사항은 애플리케이션의 안정성과 성능에 영향을 미칠 수 있으므로 비프로덕션 환경에서 먼저 해당 변경 사항을 검토하고 테스트해야 합니다.

## 소비 감소

비용을 절감하는 가장 좋은 방법은 리소스를 적게 프로비저닝하는 것입니다.이를 위한 한 가지 방법은 현재 요구 사항에 따라 워크로드를 조정하는 것입니다. 워크로드가 요구 사항을 정의하고 동적으로 확장되도록 하는 것부터 비용 최적화 노력을 시작해야 합니다. 이를 위해서는 애플리케이션에서 메트릭을 가져오고 [`PodDisruptionBudgets`](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) 및 [Pod Readiness Gates](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.5/deploy/pod_readiness_gate/)와 같은 구성을 설정하여 애플리케이션이 안전하게 동적으로 확장 및 축소할 수 있는지 확인해야 합니다.

HPA는 애플리케이션의 성능 및 안정성 요구 사항을 충족하는 데 필요한 복제본 수를 조정할 수 있는 유연한 워크로드 오토스케일러입니다. CPU, 메모리 또는 사용자 지정 메트릭 (예: 큐 깊이, 파드에 대한 연결 수 등) 과 같은 다양한 메트릭을 기반으로 확장 및 축소 시기를 정의할 수 있는 유연한 모델을 제공합니다.

쿠버네티스 메트릭 서버는 CPU 및 메모리 사용량과 같은 내장된 지표에 따라 크기를 조정할 수 있지만 Amazon CloudWatch 또는 SQS 대기열 깊이와 같은 다른 지표를 기반으로 확장하려면 [KEDA](https://keda.sh/)와 같은 이벤트 기반 자동 크기 조정 프로젝트를 고려해야 합니다. KEDA를 CloudWatch 지표와 함께 사용하는 방법에 대해서는 [이 블로그 게시물](https://aws.amazon.com/blogs/mt/proactive-autoscaling-of-kubernetes-workloads-with-keda-using-metrics-ingested-into-amazon-cloudwatch/)을 참조하십시오. 어떤 지표를 모니터링하고 규모를 조정해야 할지 잘 모르겠다면 [중요한 지표 모니터링에 대한 모범 사례](https://aws-observability.github.io/observability-best-practices/guides/#monitor-what-matters)를 확인하십시오.

워크로드 소비를 줄이면 클러스터에 초과 용량이 생성되며 적절한 자동 크기 조정 구성을 통해 노드를 자동으로 축소하여 총 지출을 줄일 수 있습니다. 컴퓨팅 파워를 수동으로 최적화하지 않는 것이 좋습니다. 쿠버네티스 스케줄러와 노드 오토스케일러는 이 프로세스를 처리하도록 설계되었습니다.

## 미사용 용량 줄이기

애플리케이션의 크기를 올바르게 결정하고 초과 요청을 줄인 후 프로비저닝된 컴퓨팅 파워를 줄일 수 있습니다. 위 섹션에서 시간을 들여 워크로드 크기를 올바르게 조정했다면 이 작업을 동적으로 수행할 수 있을 것입니다.AWS의 쿠버네티스와 함께 사용되는 기본 노드 자동 확장 프로그램은 두 가지입니다.

### Karpenter와 Cluster Autoscaler

Karpenter와 쿠버네티스 Cluster Autoscaler는 모두 파드가 생성되거나 제거되고 컴퓨팅 요구 사항이 변경됨에 따라 클러스터의 노드 수를 확장합니다. 둘 다 기본 목표는 같지만 Karpenter는 비용을 줄이고 클러스터 전체 사용을 최적화하는 데 도움이 되는 노드 관리 프로비저닝과 디프로비저닝에 대해 다른 접근 방식을 취합니다.

클러스터의 규모가 커지고 워크로드의 다양성이 증가함에 따라 노드 그룹과 인스턴스를 미리 구성하기가 더욱 어려워지고 있습니다.워크로드 요청과 마찬가지로 초기 기준을 설정하고 필요에 따라 지속적으로 조정하는 것이 중요합니다.

### Cluster Autoscaler Priority Expander

쿠버네티스 Cluster Autoscaler는 노드 그룹을 확장하거나 축소하는 방식으로 작동합니다. 워크로드를 동적으로 확장하지 않는 경우 클러스터 오토스케일러는 비용 절감에 도움이 되지 않습니다. Cluster Autoscaler를 사용하려면 클러스터 관리자가 워크로드 사용에 대비하여 노드 그룹을 미리 생성해야 합니다. 노드 그룹은 "프로파일"이 동일한 인스턴스, 즉 CPU와 메모리 양이 거의 같은 인스턴스를 사용하도록 구성해야 합니다.

노드 그룹을 여러 개 가질 수 있으며 우선 순위 조정 수준을 설정하도록 클러스터 오토스케일러를 구성할 수 있으며 각 노드 그룹은 서로 다른 크기의 노드를 포함할 수 있습니다.노드 그룹은 다양한 용량 유형을 가질 수 있으며 우선 순위 확장기를 사용하여 비용이 저렴한 그룹을 먼저 확장할 수 있습니다.

다음은 온디맨드 인스턴스를 사용하기 전에 '컨피그맵'을 사용하여 예약 용량의 우선 순위를 지정하는 클러스터 구성 스니펫의 예입니다. 동일한 기법을 사용하여 다른 유형보다 Graviton 또는 스팟 인스턴스의 우선 순위를 지정할 수 있습니다.

```yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
managedNodeGroups:
  - name: managed-ondemand
    minSize: 1
    maxSize: 7
    instanceType: m5.xlarge
  - name: managed-reserved
    minSize: 2
    maxSize: 10
    instanceType: c5.2xlarge
```

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    10:
      - .*ondemand.*
    50:
      - .*reserved.*
```

노드 그룹을 사용하면 기본 컴퓨팅 리소스가 기본적으로 예상한 작업을 수행하는 데 도움이 될 수 있습니다(예: AZ 전체에 노드를 분산시키는 경우). 그러나 모든 워크로드의 요구 사항이나 기대치가 동일하지는 않으므로 애플리케이션이 요구 사항을 명시적으로 선언하도록 하는 것이 좋습니다. Cluster Autoscaler에 대한 자세한 내용은 [모범 사례 섹션](https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/)을 참조하십시오.

### 스케줄 조정자

Cluster Autoscaler는 스케줄이 필요한 새 파드 또는 사용률이 낮은 노드를 기반으로 클러스터에서 노드 용량을 추가하고 제거할 수 있습니다. 노드에 스케줄링된 후에는 파드 배치를 전체적으로 살펴볼 수 없습니다. 클러스터 오토스케일러를 사용하는 경우 클러스터의 용량 낭비를 방지하기 위해 [Kubernetes descheduler](https://github.com/kubernetes-sigs/descheduler)도 살펴봐야 합니다.

클러스터에 10개의 노드가 있고 각 노드의 사용률이 60%라면 클러스터에서 프로비저닝된 용량의 40% 를 사용하지 않는 것입니다. 클러스터 오토스케일러를 사용하면 노드당 사용률 임계값을 60% 로 설정할 수 있지만, 이렇게 하면 사용률이 60% 미만으로 떨어진 후 단일 노드만 축소하려고 합니다.

Descheduler를 사용하면 파드가 스케줄링되거나 클러스터에 노드가 추가된 후 클러스터 용량 및 사용률을 확인할 수 있습니다. 클러스터의 총 용량을 지정된 임계값 이상으로 유지하려고 시도합니다. 또한 노드 테인트나 클러스터에 합류하는 새 노드를 기반으로 파드를 제거하여 파드가 최적의 컴퓨팅 환경에서 실행되도록 할 수 있습니다. 참고로 Descheduler는 제거된 파드의 교체를 스케줄링하지 않고 기본 스케줄러를 사용한다.

### Karpenter 통합 기능

Karpenter는 노드 관리에 대해 "그룹과 무관한(groupless)" 접근 방식을 취합니다. 이 접근 방식은 다양한 워크로드 유형에 더 유연하며 클러스터 관리자의 사전 구성이 덜 필요합니다. 그룹을 미리 정의하고 워크로드 필요에 따라 각 그룹을 조정하는 대신 Karpenter는 프로비저너와 노드 템플릿을 사용하여 생성할 수 있는 EC2 인스턴스 유형과 생성 시 인스턴스에 대한 설정을 광범위하게 정의합니다.

빈패킹(Bin Packing)은 더 적은 수의 최적 크기의 인스턴스에 더 많은 워크로드를 패킹하여 인스턴스의 리소스를 더 많이 활용하는 방법입니다. 이렇게 하면 워크로드에서 사용하는 리소스만 프로비저닝하여 컴퓨팅 비용을 줄이는 데 도움이 되지만 절충점이 있습니다. 특히 대규모 확장 이벤트의 경우 클러스터에 용량을 추가해야 하므로 새 워크로드를 시작하는 데 시간이 더 오래 걸릴 수 있습니다. 빈패킹을 설정할 때는 비용 최적화, 성능 및 가용성 간의 균형을 고려하십시오.

Karpenter는 지속적으로 모니터링하고 빈패킹하여 인스턴스 리소스 사용률을 높이고 컴퓨팅 비용을 낮출 수 있습니다. 또한 Karpenter는 워크로드에 대해 더 비용 효율적인 워커 노드를 선택할 수 있습니다. 프로비저닝 도구에서 "consolidation" 플래그를 true로 설정하면 이를 달성할 수 있습니다 (아래 샘플 코드 스니펫 참조). 아래 예제는 통합을 지원하는 프로비저닝 도구의 예를 보여줍니다. 이 안내서를 작성하는 시점에서 Karpenter는 실행 중인 스팟 인스턴스를 더 저렴한 스팟 인스턴스로 대체하지 않을 것입니다. Karpenter 통합에 대한 자세한 내용은 [이 블로그](https://aws.amazon.com/blogs/containers/optimizing-your-kubernetes-compute-costs-with-karpenter-consolidation/)를 참조하십시오.

```yaml
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: enable-binpacking
spec:
  consolidation:
    enabled: true
```

중단이 불가능할 수 있는 워크로드(예: 체크포인트 없이 장기간 실행되는 일괄 작업)의 경우, 파드에 `do-not-evict` 어노테이션을 달아 보세요. 파드를 제거에서 제외시키는 것은 Karpenter가 이 파드를 포함하는 노드를 자발적으로 제거해서는 안 된다고 말하는 것입니다. 하지만 노드가 드레이닝되는 동안 노드에 `do-not-evict` 파드가 추가되면 나머지 파드는 여전히 제거되지만 해당 파드는 제거될 때까지 종료를 차단합니다. 어느 경우든 노드에 추가 작업이 스케줄링되는 것을 방지하기 위해 노드는 cordon됩니다. 다음은 어노테이션을 설정하는 방법을 보여주는 예시입니다.

```yaml hl_lines="8"
apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
  annotations:
    "karpenter.sh/do-not-evict": "true"
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
```

### Cluster Autoscaler 파라미터를 조정하여 사용률이 낮은 노드를 제거합니다.

노드 사용률은 요청된 리소스의 합계를 용량으로 나눈 값으로 정의됩니다. 기본적으로 'scale-down-utilization-threshold'은 50% 로 설정됩니다. 이 파라미터는 'scale-down-unneeded-time'과 함께 사용할 수 있습니다. 이 시간은 노드를 축소할 수 있을 때까지 필요하지 않게 되는 기간을 결정합니다. 기본값은 10분입니다.축소된 노드에서 여전히 실행 중인 파드는 kube-scheduler에 의해 다른 노드에 스케줄링됩니다. 이러한 설정을 조정하면 활용도가 낮은 노드를 제거하는 데 도움이 될 수 있지만, 클러스터를 조기에 강제로 축소하지 않도록 먼저 이 값을 테스트하는 것이 중요합니다.

제거하는 데 비용이 많이 드는 파드를 클러스터 오토스케일러에서 인식하는 레이블로 보호함으로써 스케일 다운이 발생하지 않도록 할 수 있습니다. 이렇게 하려면 제거 비용이 많이 드는 파드에 `cluster-autoscaler.kubernetes.io/safe-to-evict=false`라는 주석을 달아야 한다. 다음은 어노테이션을 설정하는 yaml의 예시입니다.

```yaml hl_lines="8"
apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
  annotations:
    "cluster-autoscaler.kubernetes.io/safe-to-evict": "false"
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
```

### 노드에 Cluster Autoscaler 및 Karpenter 태그 지정

AWS  [태그](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)는 리소스를 구성하고 세부 수준에서 AWS 비용을 추적하는 데 사용됩니다. 비용 추적을 위한 Kubernetes 레이블과 직접적인 상관 관계를 맺지는 않습니다. 먼저 쿠버네티스 리소스 레이블링으로 시작하고 [Kubecost](https://aws.amazon.com/blogs/containers/aws-and-kubecost-collaborate-to-deliver-cost-monitoring-for-eks-customers/)와 같은 도구를 활용하여 파드, 네임스페이스 등의 쿠버네티스 레이블을 기반으로 인프라 비용을 보고하는 것이 좋습니다.

AWS Cost Explorer에서 결제 정보를 표시하려면 워커 노드에 태그가 있어야 합니다. Cluster Autoscaler를 사용하면 [시작 템플릿](https://docs.aws.amazon.com/eks/latest/userguide/launch-templates.html)을 사용하여 관리형 노드 그룹 내의 워커 노드에 태그를 지정합니다. 자체 관리형 노드 그룹의 경우 [EC2 Auto Scaling 그룹](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-tagging.html) 을 사용하여 인스턴스에 태그를 지정합니다. Karpenter에서 프로비저닝한 인스턴스의 경우 [노드 템플릿의 spec.tags](https://karpenter.sh/v0.29/concepts/node-templates/#spectags)를 사용하여 태그를 지정하십시오.

### 멀티 테넌트 클러스터

다른 팀이 공유하는 클러스터에서 작업하는 경우 동일한 노드에서 실행되는 다른 워크로드를 파악하지 못할 수 있습니다. 리소스 요청은 CPU 공유와 같은 일부 "시끄러운 이웃(noisy neighbor)" 문제를 격리하는 데 도움이 될 수 있지만 디스크 I/O 병목과 같은 모든 리소스 경계를 분리하지는 못할 수도 있습니다. 워크로드에 의해 사용 가능한 모든 리소스를 분리하거나 제한할 수는 없습니다. 다른 워크로드보다 높은 비율로 공유 리소스를 사용하는 워크로드는 노드 [taint와 toleration](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)을 통해 격리해야 합니다. 이러한 워크로드를 위한 또 다른 고급 기법은 컨테이너의 공유 CPU 대신 전용 CPU를 보장하는 [CPU pinning](https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy)을 적용할 수 있습니다.

워크로드를 노드 수준에서 분리하는 것은 비용이 더 많이 들 수 있지만 [예약 인스턴스](https://aws.amazon.com/ec2/pricing/reserved-instances/), [Graviton 프로세서](https://aws.amazon.com/ec2/graviton/) 또는 [스팟 인스턴스](https://aws.amazon.com/ec2/spot/)을 사용하여 [BestEffort](https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#besteffort) 작업을 예약하거나 추가 비용 절감을 활용할 수 있습니다.

공유 클러스터에는 IP 고갈, 쿠버네티스 서비스 제한 또는 API 확장 요청과 같은 클러스터 수준 리소스 제약이 있을 수도 있습니다. [확장성 모범 사례 가이드](https://aws.github.io/aws-eks-best-practices/scalability/docs/control-plane/)를 검토하여 클러스터가 이러한 제한이 없는지 확인해야 합니다.

네임스페이스 또는 Karpenter 프로비저너 수준에서 리소스를 격리할 수 있습니다. [리소스 할당량(Quota)](https://kubernetes.io/docs/concepts/policy/resource-quotas/)은 네임스페이스의 워크로드가 소비할 수 있는 리소스 수를 제한하는 방법을 제공합니다. 이는 초기 보호 수단으로 유용할 수 있지만, 워크로드 확장을 인위적으로 제한하지 않도록 지속적으로 평가해야 합니다.

Karpenter 프로비저너는 클러스터에서 [일부 사용 가능한 리소스(예: CPU, GPU)에 제한을 설정](https://karpenter.sh/docs/concepts/provisioners/#speclimitsresources)할 수 있지만 적절한 프로비저너를 사용하도록 테넌트 애플리케이션을 구성해야 합니다. 이렇게 하면 단일 제공자가 클러스터에 너무 많은 노드를 생성하는 것을 방지할 수 있지만, 제한을 너무 낮게 설정하지 않도록 지속적으로 평가하여 워크로드가 확장되지 않도록 해야 합니다.

### 오토스케일링 스케줄링

주말 또는 휴일에는 클러스터를 축소해야 할 수도 있습니다. 이는 사용하지 않을 때 0으로 축소하려는 테스트 및 비프로덕션 클러스터에 특히 적합합니다. [cluster-turndown](https://github.com/kubecost/cluster-turndown) 와 같은 솔루션은 크론 스케줄에 따라 복제본을 0으로 축소할 수 있습니다. 다음 [AWS 블로그](https://aws.amazon.com/blogs/containers/manage-scale-to-zero-scenarios-with-karpenter-and-serverless/)에 설명된 대로 Karpenter를 사용하여 동일한 작업을 수행할 수도 있습니다.

## 컴퓨팅 용량 유형 최적화

클러스터의 총 컴퓨팅 용량을 최적화하고 빈 패킹을 사용한 후에는 클러스터에 프로비저닝한 컴퓨팅 유형과 해당 리소스에 대한 비용을 확인해야 합니다. AWS는 컴퓨팅 비용을 절감할 수 있는 [컴퓨팅 절감형 플랜(Savings Plan)](https://aws.amazon.com/savingsplans/compute-pricing/)을 운영하고 있으며, 이를 다음과 같은 용량 유형으로 분류해 보겠습니다.

* 스팟
* 절감형 플랜(Savings Plan)
* 온디맨드
* Fargate

각 용량 유형에는 관리 오버헤드, 가용성 및 장기 약정 측면에서 서로 다른 절충점이 있으므로 환경에 적합한 것을 결정해야 합니다. 어떤 환경도 단일 용량 유형에 의존해서는 안 되며 단일 클러스터에 여러 실행 유형을 혼합하여 특정 워크로드 요구 사항 및 비용을 최적화할 수 있습니다.

### 스팟 인스턴스

[스팟](https://aws.amazon.com/ec2/spot/) 용량 유형은 가용영역의 예비 용량에서 EC2 인스턴스를 프로비저닝합니다. 스팟은 최대 90% 까지 할인을 제공하지만, 다른 곳에서 필요할 경우 해당 인스턴스가 중단될 수 있습니다. 또한 새 스팟 인스턴스를 프로비저닝할 용량이 항상 있는 것은 아니며 [2분 중단 알림](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html)을 통해 기존 스팟 인스턴스를 회수할 수 있습니다. 애플리케이션의 시작 또는 종료 프로세스가 오래 걸리는 경우 스팟 인스턴스가 최선의 옵션이 아닐 수 있습니다.

스팟 컴퓨팅은 다양한 인스턴스 유형을 사용하여 사용 가능한 스팟 용량이 없을 가능성을 줄여야 합니다. 노드를 안전하게 종료하려면 인스턴스 중단을 처리해야 합니다. Karpenter 또는 관리형 노드 그룹의 일부로 프로비저닝된 노드는 [인스턴스 중단 알림](https://aws.github.io/aws-eks-best-practices/karpenter/#enable-interruption-handling-when-using-spot)을 자동으로 지원합니다. 자체 관리형 노드를 사용하는 경우 [노드 종료 핸들러](https://github.com/aws/aws-node-termination-handler)를 별도로 실행하여 스팟 인스턴스를 정상적으로 종료해야 합니다.

단일 클러스터에서 스팟 인스턴스와 온디맨드 인스턴스의 균형을 맞출 수 있습니다. Karpenter를 사용하면 [가중치 프로비저너](https://karpenter.sh/docs/concepts/scheduling/#on-demandspot-ratio-split)를 생성하여 다양한 용량 유형의 균형을 맞출 수 있습니다. Cluster Autoscaler를 사용하면 [스팟 및 온디맨드 또는 예약 인스턴스가 포함된 혼합 노드 그룹](https://aws.amazon.com/blogs/containers/amazon-eks-now-supports-provisioning-and-managing-ec2-spot-instances-in-managed-node-groups/)을 생성할 수 있습니다.

다음은 Karpenter를 사용하여 온디맨드 인스턴스보다 스팟 **** 인스턴스 우선 순위를 높게 정하는 예입니다. 프로비저너를 생성할 때 스팟, 온디맨드 또는 둘 다 지정할 수 있습니다(아래 그림 참조). 둘 다 지정하고 파드가 스팟 또는 온디맨드를 사용해야 하는지 명시적으로 지정하지 않는 경우 Karpenter는 [price-capacity-optimization 할당 전략](https://aws.amazon.com/blogs/compute/introducing-price-capacity-optimized-allocation-strategy-for-ec2-spot-instances/)으로 노드를 프로비저닝할 때 스팟의 우선 순위를 지정합니다.

```yaml hl_lines="9"
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: spot-prioritized
spec:
  requirements:
    - key: "karpenter.sh/capacity-type"
      operator: In
        values: ["spot", "on-demand"]
```

### Savings Plans, 예약 인스턴스 및 AWS 엔터프라이즈 할인 프로그램(EDP)

[Compute Savings Plan](https://aws.amazon.com/savingsplans/compute-pricing/)을 사용하면 컴퓨팅 비용을 줄일 수 있습니다. Savings Plan은 1년 또는 3년 컴퓨팅 사용 약정 시 할인된 가격을 제공합니다. 사용량은 EKS 클러스터의 EC2 인스턴스에 적용할 수 있지만 Lambda 및 Fargate와 같은 모든 컴퓨팅 사용에도 적용됩니다. Savings Plan을 사용하면 비용을 절감하면서도 약정 기간 동안 모든 EC2 인스턴스 유형을 선택할 수 있습니다.

Compute Savings Plan을 사용하면 사용하려는 인스턴스 유형, 제품군 또는 리전에 대한 약정 없이 EC2 비용을 최대 66% 절감할 수 있습니다. 절감액은 인스턴스를 사용할 때 인스턴스에 자동으로 적용됩니다.

EC2 인스턴스 Savings Plan은 특정 리전 및 EC2 제품군(예: C 제품군 인스턴스)의 사용량을 약정하여 컴퓨팅 비용을 최대 72% 절감합니다. 리전 내 모든 AZ로 사용량을 전환하고, c5 또는 c6와 같은 모든 세대의 인스턴스 패밀리를 사용하고, 패밀리 내에서 원하는 크기의 인스턴스를 사용할 수 있습니다. 할인은 Savings Plan 기준과 일치하는 계정 내 모든 인스턴스에 자동으로 적용됩니다.

[예약 인스턴스](https://aws.amazon.com/ec2/pricing/reserved-instances/)는 EC2 인스턴스 Savings Plan과 비슷하지만 가용영역 또는 지역의 용량을 보장하고 온디맨드 인스턴스에 비해 비용을 최대 72% 절감합니다 .필요한 예약 용량을 계산한 후 예약 기간(1년 또는 3년)을 선택할 수 있습니다. 어카운트에서 해당 EC2 인스턴스를 실행하면 할인이 자동으로 적용됩니다.

또한 고객은 AWS와 기업 계약을 체결할 수 있습니다.기업 계약은 고객에게 요구 사항에 가장 적합한 계약을 조정할 수 있는 옵션을 제공합니다.고객은 AWS 엔터프라이즈 할인 프로그램(EDP, Enterprise Discount Program)를 기반으로 가격 할인을 받을 수 있습니다. 기업 계약에 대한 추가 정보는 AWS 영업 담당자에게 문의하세요.

### 온디맨드

온디맨드 EC2 인스턴스는 (스팟에 비해) 중단 없이 사용할 수 있고 (Savings Plan에 비해) 장기 약정이 없다는 이점이 있습니다. 클러스터에서 비용을 절감하려면 온디맨드 EC2 인스턴스의 사용량을 줄여야 합니다.

워크로드 요구 사항을 최적화한 후에는 클러스터의 최소 및 최대 용량을 계산하여야 합니다. 이 수치는 시간이 지남에 따라 변경될 수 있지만 감소하는 경우는 거의 없습니다. 최소 금액 미만의 모든 항목에는 Savings Plan을 사용하고 애플리케이션 가용성에 영향을 미치지 않는 용량은 확보해 두는 것이 좋습니다. 지속적으로 사용되지 않거나 가용성이 필요한 다른 모든 항목은 온디맨드로 사용할 수 있습니다.

이 섹션에서 언급한 것처럼 사용량을 줄이는 가장 좋은 방법은 리소스를 적게 사용하고 프로비저닝한 리소스를 최대한 활용하는 것입니다. Cluster Autoscaler를 사용하면 `scale-down-utilization-threshold` 설정으로 사용률이 낮은 노드를 제거할 수 있습니다.Karpenter의 경우 통합을 활성화하는 것이 좋습니다.

워크로드에 사용할 수 있는 EC2 인스턴스 유형을 수동으로 식별하려면 [ec2-instance-selector](https://github.com/aws/amazon-ec2-instance-selector)를 사용할 수 있습니다. 그러면 각 러전에서 사용 가능한 인스턴스는 물론 EKS와 호환되는 인스턴스도 표시할 수 있습니다. 다음 예는 x86 프로세스 아키텍처, 4Gb 메모리, vCPU 2개를 갖추고 us-east-1 지역에서 사용 가능한 인스턴스를 보여줍니다.

```bash
ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 \
  -r us-east-1 --service eks
c5.large
c5a.large
c5ad.large
c5d.large
c6a.large
c6i.large
t2.medium
t3.medium
t3a.medium
```

운영 환경이 아닌 경우 야간 및 주말과 같이 사용하지 않는 시간에는 클러스터를 자동으로 축소할 수 있습니다. kubecost 프로젝트 [cluster-turndown](https://github.com/kubecost/cluster-turndown)은 설정된 일정에 따라 클러스터를 자동으로 축소할 수 있는 컨트롤러의 예입니다.

### Fargate 컴퓨팅

Fargate 컴퓨팅은 EKS 클러스터를 위한 완전 관리형 컴퓨팅 옵션입니다. 쿠버네티스 클러스터의 노드당 파드 하나를 스케줄링하여 파드 격리를 제공합니다. 이를 통해 워크로드의 CPU 및 RAM 메모리 요구 사항에 맞게 컴퓨팅 노드의 크기를 조정하여 클러스터의 워크로드 사용을 엄격하게 제어할 수 있습니다.

Fargate는 최소 0.25vCPU, 0.5GB 메모리에서부터 최대 16vCPU, 120GB 메모리까지 워크로드를 확장할 수 있습니다. 사용할 수 있는 [파드 크기 변형](https://docs.aws.amazon.com/eks/latest/userguide/fargate-pod-configuration.html)에 제한이 있으므로 Fargate 설정이 워크로드에 적합한지 확인해야 합니다. 예를 들어 워크로드가 vCPU 1개, 0.5GB 메모리가 필요한 경우 이를 위한 가장 작은 Fargate 파드는 vCPU 1개, 2GB 메모리입니다.

Fargate는 EC2 인스턴스 또는 운영 체제 관리가 필요 없는 등 많은 이점을 제공하지만 배포된 모든 파드가 클러스터의 개별 노드로 격리되어 있기 때문에 기존 EC2 인스턴스보다 더 많은 컴퓨팅 파워가 필요할 수 있습니다. 이를 위해서는 Kubelet, 로깅 에이전트, 일반적으로 노드에 배포하는 데몬셋 등의 항목을 더 많이 복제해야 합니다. 데몬셋은 Fargate에서 지원되지 않으므로 파드 "사이드카"로 변환하여 애플리케이션과 함께 실행해야 합니다.

Fargate는 노드별로 각 워크로드간 분리되기 때문에 버스팅이 불가능하고 공유될 수 없기 때문에 빈패킹이나 CPU 오버프로비저닝의 이점을 누릴 수 없습니다. Fargate를 사용하면 비용이 드는 EC2 인스턴스 관리 시간을 절약할 수 있지만 CPU 및 메모리 비용은 다른 EC2 용량 유형보다 비쌀 수 있습니다. Fargate 파드는 컴퓨팅 Savings Plan을 활용하여 온디맨드 비용을 절감할 수 있습니다.

## 컴퓨팅 사용 최적화

컴퓨팅 인프라 비용을 절감하는 또 다른 방법은 워크로드에 더 효율적인 컴퓨팅을 사용하는 것입니다. 이는 x86보다 최대 20% 저렴하고 에너지 효율이 60% 더 높은 [Graviton 프로세서](https://aws.amazon.com/ec2/graviton/)와 같이 성능이 더 뛰어난 범용 컴퓨팅이나 GPU 및 [FPGA](https://aws.amazon.com/ec2/instance-types/f1/) 와 같은 워크로드별 가속기를 통해 얻을 수 있습니다. 워크로드에 맞게 [ARM 아키텍처에서 실행](https://aws.amazon.com/blogs/containers/how-to-build-your-containers-for-arm-and-save-with-graviton-and-spot-instances-on-amazon-ecs/)하고 [적절한 가속기로 노드를 설정](https://aws.amazon.com/blogs/compute/running-gpu-accelerated-kubernetes-workloads-on-p3-and-p2-ec2-instances-with-amazon-eks/)할 수 있는 컨테이너를 구축해야 합니다.

EKS는 혼합 아키텍처(예: amd64 및 arm64)로 클러스터를 실행할 수 있으며 컨테이너가 멀티 아키텍처용으로 컴파일된 경우 프로비저너에서 두 아키텍처를 모두 허용하여 Karpenter와 함께 Graviton 프로세서를 활용할 수 있습니다. 하지만 성능을 일관되게 유지하려면 각 워크로드를 단일 컴퓨팅 아키텍처에 두고 추가 용량이 없는 경우에만 다른 아키텍처를 사용하는 것이 좋습니다.

프로비저너는 여러 아키텍처로 구성할 수 있으며 워크로드는 워크로드 사양에서 특정 아키텍처를 요청할 수도 있습니다.

```yaml
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
  - key: "kubernetes.io/arch"
    operator: In
    values: ["arm64", "amd64"]
```

Cluster Autoscaler를 사용하면 Graviton 인스턴스용 노드 그룹을 생성하고 새 용량을 활용하려면 [워크로드에 대한 노드 허용 범위](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정해야 합니다.

GPU와 FPGA는 워크로드의 성능을 크게 향상시킬 수 있지만 가속기를 사용하려면 워크로드를 최적화해야 합니다. 머신러닝 및 인공지능을 위한 다양한 워크로드 유형은 컴퓨팅에 GPU를 사용할 수 있으며, 리소스 요청을 사용하여 클러스터에 인스턴스를 추가하고 워크로드에 마운트할 수 있습니다.

```yaml
spec:
  template:
    spec:
    - containers:
      ...
      resources:
          limits:
            nvidia.com/gpu: "1"
```

일부 GPU 하드웨어는 여러 워크로드에서 공유할 수 있으므로 단일 GPU를 프로비저닝하고 사용할 수 있습니다. 워크로드 GPU 공유를 구성하는 방법을 보려면 자세한 내용은 [가상 GPU 장치 플러그인](https://aws.amazon.com/blogs/opensource/virtual-gpu-device-plugin-for-inference-workload-in-kubernetes/)을 참조하십시오. 다음 블로그를 참조할 수도 있습니다.

* [NVIDIA 타임슬라이싱 및 가속화 EC2 인스턴스를 사용하는 Amazon EKS에서의 GPU 공유](https://aws.amazon.com/blogs/containers/gpu-sharing-on-amazon-eks-with-nvidia-time-slicing-and-accelerated-ec2-instances/)
* [Amazon EKS에서 NVIDIA의 멀티 인스턴스 GPU(MIG)를 사용하여 GPU 사용률 극대화: GPU 당 더 많은 파드를 실행하여 성능 향상](https://aws.amazon.com/blogs/containers/maximizing-gpu-utilization-with-nvidias-multi-instance-gpu-mig-on-amazon-eks-running-more-pods-per-gpu-for-enhanced-performance/

search    exclude  true                                                          CPU                                                                                1             Right sizing  2                 3                         GPU                     Right sizing        EKS                                         EC2                                                                             request       limit                                                                                request                           request                                                                                request   limit                                         Goldilocks  https   www youtube com watch v DfmQWYiwFDk    KRR  https   www youtube com watch v uITOzpf82RY    Kubecost  https   aws amazon com blogs containers aws and kubecost collaborate to deliver cost monitoring for eks customers                                                                                https   aws github io aws eks best practices scalability docs node efficiency  application right sizing            Horizontal Pod Autoscaler HPA                                    Vertical Pod Autoscaler VPA                                           Karpenter  http   karpenter sh       Cluster Autoscaler  https   github com kubernetes autoscaler                                                        Karpenter   Cluster Autoscaler                                        VPA                                                  VPA                                                                                PodDisruptionBudgets   https   kubernetes io docs tasks run application configure pdb      Pod Readiness Gates  https   kubernetes sigs github io aws load balancer controller v2 5 deploy pod readiness gate                                                            HPA                                                                         CPU                                                                                CPU                                        Amazon CloudWatch    SQS                               KEDA  https   keda sh                                       KEDA  CloudWatch                                  https   aws amazon com blogs mt proactive autoscaling of kubernetes workloads with keda using metrics ingested into amazon cloudwatch                                                                      https   aws observability github io observability best practices guides  monitor what matters                                                                                AWS                                                 Karpenter  Cluster Autoscaler  Karpenter        Cluster Autoscaler                                                                         Karpenter                                                                                Cluster Autoscaler Priority Expander        Cluster Autoscaler                                                                                Cluster Autoscaler                                                                               CPU                                                                                Graviton                                      yaml apiVersion  eksctl io v1alpha5 kind  ClusterConfig metadata    name  my cluster managedNodeGroups      name  managed ondemand     minSize  1     maxSize  7     instanceType  m5 xlarge     name  managed reserved     minSize  2     maxSize  10     instanceType  c5 2xlarge         yaml apiVersion  v1 kind  ConfigMap metadata    name  cluster autoscaler priority expander   namespace  kube system data    priorities         10            ondemand       50            reserved                                                                     AZ                                                                                Cluster Autoscaler                        https   aws github io aws eks best practices cluster autoscaling                          Cluster Autoscaler                                                                                Kubernetes descheduler  https   github com kubernetes sigs descheduler                    10                     60                      40                                                 60                           60                                Descheduler                                                                                Descheduler                                            Karpenter        Karpenter                     groupless                                                                                Karpenter                               EC2                                              Bin Packing                                                                                Karpenter                                                             Karpenter                                                    consolidation       true                                                                                Karpenter                                              Karpenter                        https   aws amazon com blogs containers optimizing your kubernetes compute costs with karpenter consolidation                  yaml apiVersion  karpenter sh v1alpha5 kind  Provisioner metadata    name  enable binpacking spec    consolidation      enabled  true                                                               do not evict                                   Karpenter                                                                    do not evict                                                                                cordon                                         yaml hl lines  8  apiVersion  v1 kind  Pod metadata    name  label demo   labels      environment  production   annotations         karpenter sh do not evict    true  spec    containers      name  nginx     image  nginx     ports        containerPort  80          Cluster Autoscaler                                                                               scale down utilization threshold   50                    scale down unneeded time                                                                    10                            kube scheduler                                                                                cluster autoscaler kubernetes io safe to evict false                                yaml             yaml hl lines  8  apiVersion  v1 kind  Pod metadata    name  label demo   labels      environment  production   annotations         cluster autoscaler kubernetes io safe to evict    false  spec    containers      name  nginx     image  nginx     ports        containerPort  80              Cluster Autoscaler   Karpenter        AWS       https   docs aws amazon com tag editor latest userguide tagging html                     AWS                             Kubernetes                                                      Kubecost  https   aws amazon com blogs containers aws and kubecost collaborate to deliver cost monitoring for eks customers                                                                     AWS Cost Explorer                                    Cluster Autoscaler                https   docs aws amazon com eks latest userguide launch templates html                                                         EC2 Auto Scaling     https   docs aws amazon com autoscaling ec2 userguide ec2 auto scaling tagging html                          Karpenter                            spec tags  https   karpenter sh v0 29 concepts node templates  spectags                                                                                CPU                    noisy neighbor                              I O                                                                                taint  toleration  https   kubernetes io docs concepts scheduling eviction taint and toleration                                                   CPU       CPU        CPU pinning  https   kubernetes io docs tasks administer cluster cpu management policies  static policy                                                                 https   aws amazon com ec2 pricing reserved instances     Graviton       https   aws amazon com ec2 graviton                https   aws amazon com ec2 spot          BestEffort  https   kubernetes io docs concepts workloads pods pod qos  besteffort                                              IP                     API                                                       https   aws github io aws eks best practices scalability docs control plane                                                Karpenter                                      Quota   https   kubernetes io docs concepts policy resource quotas                                                                                Karpenter                                 CPU  GPU           https   karpenter sh docs concepts provisioners  speclimitsresources                                                                                0                                      cluster turndown  https   github com kubecost cluster turndown                            0                   AWS      https   aws amazon com blogs containers manage scale to zero scenarios with karpenter and serverless           Karpenter                                                                                AWS                               Savings Plan   https   aws amazon com savingsplans compute pricing                                                          Savings Plan           Fargate                                                                                https   aws amazon com ec2 spot                        EC2                        90                                                                                2         https   docs aws amazon com AWSEC2 latest UserGuide spot interruptions html                                                                                Karpenter                                           https   aws github io aws eks best practices karpenter  enable interruption handling when using spot                                              https   github com aws aws node termination handler                                                                                Karpenter                   https   karpenter sh docs concepts scheduling  on demandspot ratio split                                  Cluster Autoscaler                                            https   aws amazon com blogs containers amazon eks now supports provisioning and managing ec2 spot instances in managed node groups                     Karpenter                                                                                Karpenter   price capacity optimization        https   aws amazon com blogs compute introducing price capacity optimized allocation strategy for ec2 spot instances                                        yaml hl lines  9  apiVersion  karpenter sh v1alpha5 kind  Provisioner metadata    name  spot prioritized spec    requirements        key   karpenter sh capacity type         operator  In         values    spot    on demand            Savings Plans            AWS                EDP    Compute Savings Plan  https   aws amazon com savingsplans compute pricing                            Savings Plan  1     3                                  EKS       EC2                 Lambda   Fargate                        Savings Plan                              EC2                       Compute Savings Plan                                          EC2        66                                                  EC2      Savings Plan          EC2        C                                 72                 AZ             c5    c6                                                                  Savings Plan                                               https   aws amazon com ec2 pricing reserved instances    EC2      Savings Plan                                                  72                                1     3                          EC2                                    AWS                                                                         AWS                EDP  Enterprise Discount Program                                           AWS                                 EC2                                Savings Plan                                                 EC2                                                                                Savings Plan                                                                                Cluster Autoscaler        scale down utilization threshold                              Karpenter                                        EC2                      ec2 instance selector  https   github com aws amazon ec2 instance selector                                          EKS                               x86            4Gb      vCPU 2       us east 1                              bash ec2 instance selector   memory 4   vcpus 2   cpu architecture x86 64      r us east 1   service eks c5 large c5a large c5ad large c5d large c6a large c6i large t2 medium t3 medium t3a medium                                                                   kubecost       cluster turndown  https   github com kubecost cluster turndown                                                   Fargate      Fargate      EKS                                                                                CPU   RAM                                                                 Fargate     0 25vCPU  0 5GB            16vCPU  120GB                                             https   docs aws amazon com eks latest userguide fargate pod configuration html            Fargate                                      vCPU 1   0 5GB                         Fargate     vCPU 1   2GB          Fargate  EC2                                                                               EC2                                         Kubelet                                                         Fargate                                                   Fargate                                                      CPU                         Fargate              EC2                       CPU              EC2                    Fargate         Savings Plan                                                                                x86      20               60        Graviton       https   aws amazon com ec2 graviton                          GPU    FPGA  https   aws amazon com ec2 instance types f1                                           ARM            https   aws amazon com blogs containers how to build your containers for arm and save with graviton and spot instances on amazon ecs                       https   aws amazon com blogs compute running gpu accelerated kubernetes workloads on p3 and p2 ec2 instances with amazon eks                          EKS             amd64   arm64                                                                    Karpenter     Graviton                                                                                yaml apiVersion  karpenter sh v1alpha5 kind  Provisioner metadata    name  default spec    requirements      key   kubernetes io arch      operator  In     values    arm64    amd64        Cluster Autoscaler       Graviton                                                   https   kubernetes io docs concepts scheduling eviction taint and toleration               GPU  FPGA                                                                                GPU                                                                  yaml spec    template      spec        containers                  resources            limits              nvidia com gpu   1          GPU                               GPU                           GPU                              GPU          https   aws amazon com blogs opensource virtual gpu device plugin for inference workload in kubernetes                                      NVIDIA              EC2            Amazon EKS    GPU     https   aws amazon com blogs containers gpu sharing on amazon eks with nvidia time slicing and accelerated ec2 instances      Amazon EKS   NVIDIA          GPU MIG        GPU          GPU                        https   aws amazon com blogs containers maximizing gpu utilization with nvidias multi instance gpu mig on amazon eks running more pods per gpu for enhanced performance


eks exclude true HA AWS AZ Amazon EKS EKS VPC ELB ECR search

Answer:
---
search:
  exclude: true
---

# 비용 최적화 - 네트워킹

고가용성(HA)을 위한 시스템 아키텍처는 복원력과 내결함성을 달성하기 위한 모범 사례를 통해 구현됩니다. 이는 특정 AWS 리전의 여러 가용영역(AZ)에 워크로드와 기본 인프라를 분산시키는 것을 의미합니다. Amazon EKS 환경에 이러한 특성을 적용하면 시스템의 전반적인 안정성이 향상됩니다. 이와 함께 EKS 환경은 다양한 구조(예: VPC), 구성 요소(예: ELB) 및 통합(예: ECR 및 기타 컨테이너 레지스트리)으로 구성될 가능성이 높습니다.

고가용성 시스템과 기타 사용 사례별 구성 요소의 조합은 데이터 전송 및 처리 방식에 중요한 역할을 할 수 있습니다.이는 결국 데이터 전송 및 처리로 인해 발생하는 비용에도 영향을 미칩니다.

아래에 자세히 설명된 실천사항은 다양한 도메인 및 사용 사례에서 비용 효율성을 달성하기 위해 EKS 환경을 설계하고 최적화하는 데 도움이 됩니다.

## 파드 간 통신

설정에 따라 파드 간 네트워크 통신 및 데이터 전송은 Amazon EKS 워크로드 실행의 전체 비용에 상당한 영향을 미칠 수 있습니다.이 섹션에서는 고가용성 (HA) 아키텍처, 애플리케이션 성능 및 복원력을 고려하면서 파드 간 통신과 관련된 비용을 줄이기 위한 다양한 개념과 접근 방식을 다룹니다.

### 가용영역으로의 트래픽 제한

잦은 이그레스 크로스존 트래픽(AZ 간에 분산되는 트래픽)은 네트워크 관련 비용에 큰 영향을 미칠 수 있습니다. 다음은 EKS 클러스터의 파드 간 크로스 존 트래픽 양을 제어하는 방법에 대한 몇 가지 전략입니다.

_클러스터 내 파드 간 크로스-존 트래픽 양(예: 전송된 데이터 양 또는 바이트 단위 전송)을 세밀하게 파악하려면 [이 게시물 참조](https://aws.amazon.com/blogs/containers/getting-visibility-into-your-amazon-eks-cross-az-pod-to-pod-network-bytes/)하세요._

**Topology Aware Routing (이전 명칭은 Topology Aware Hint) 활용**

![Topology aware routing](../images/topo_aware_routing.png)

Topology Aware Routing을 사용할 때는 트래픽을 라우팅할 때 서비스, EndpointSlices 및 `kube-proxy`가 함께 작동하는 방식을 이해하는 것이 중요합니다. 위 다이어그램에서 볼 수 있듯이 서비스는 파드로 향하는 트래픽을 수신하는 안정적인 네트워크 추상화 계층입니다. 서비스가 생성되면 여러 EndpointSlices가 생성됩니다. 각 EndpointSlice에는 실행 중인 노드 및 추가 토폴로지 정보와 함께 파드 주소의 하위 집합이 포함된 엔드포인트 목록이 있습니다. `kube-proxy`는 클러스터의 모든 노드에서 실행되고 내부 라우팅 역할도 수행하는 데몬셋이지만, 생성된 EndpointSlices에서 소비하는 양을 기반으로 합니다.

[*Topology aware routing*](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/)을 활성화하고 쿠버네티스 서비스에 구현하면, EndpointSlices 컨트롤러는 클러스터가 분산되어 있는 여러 영역에 비례적으로 엔드포인트를 할당합니다. EndpointSlices 컨트롤러는 각 엔드포인트에 대해 영역에 대한 _힌트_ 도 설정합니다. _힌트_ 는 엔드포인트가 트래픽을 처리해야 하는 영역을 설명합니다.그러면 `kube-proxy`가 적용된 _힌트_ 를 기반으로 영역에서 엔드포인트로 트래픽을 라우팅합니다.

아래 다이어그램은 'kube-proxy'가 영역 출발지를 기반으로 가야 할 목적지를 알 수 있도록 힌트가 있는 EndpointSlice를 구성하는 방법을 보여줍니다. 힌트가 없으면 이러한 할당이나 구성이 없으며 트래픽이 어디에서 오는지에 관계없이 서로 다른 지역 목적지로 프록시됩니다.

![Endpoint Slice](../images/endpoint_slice.png)

경우에 따라 EndPointSlice 컨트롤러는 다른 영역에 대해 _힌트_ 를 적용할 수 있습니다. 즉, 엔드포인트가 다른 영역에서 발생하는 트래픽을 처리하게 될 수 있습니다. 이렇게 하는 이유는 서로 다른 영역의 엔드포인트 간에 트래픽을 균일하게 분배하기 위함입니다.

다음은 서비스에 대해 _토폴로지 인식 라우팅_ 을 활성화하는 방법에 대한 코드 스니펫입니다.

```yaml hl_lines="6-7"
apiVersion: v1
kind: Service
metadata:
  name: orders-service
  namespace: ecommerce
    annotations:
      service.kubernetes.io/topology-mode: Auto
spec:
  selector:
    app: orders
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 3003
    targetPort: 3003
```

아래 스크린샷은 EndpointSlices 컨트롤러가 `eu-west-1a`가용영역에서 실행되는 파드 복제본의 엔드포인트에 힌트를 성공적으로 적용한 결과를 보여준다.

![Slice shell](../images/slice_shell.png)

!!! note
    Topology aware routing이 아직 **베타**라는 것 인지해야 합니다. 또한 워크로드가 클러스터 토폴로지 전체에 광범위하고 균등하게 분산되어 있을 때 이 기능을 더 잘 예측할 수 있습니다. 따라서 [파드 토폴로지 확산 제약](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)과 같이 애플리케이션의 가용성을 높이는 일정 제약과 함께 사용하는 것이 좋습니다.

**오토스케일러 사용: 특정 가용영역에 노드 프로비저닝**

여러 가용영역의 고가용성 환경에서 워크로드를 실행하는 것을 _강력히 권장_ 합니다. 이렇게 하면 애플리케이션의 안정성이 향상되며, 특히 가용영역에 문제가 발생한 경우 더욱 그렇습니다. 네트워크 관련 비용을 줄이기 위해 안정성을 희생하려는 경우 노드를 단일 가용영역로 제한할 수 있습니다.

동일한 가용영역에서 모든 파드를 실행하려면 동일한 가용영역에 워커 노드를 프로비저닝하거나 동일한 가용영역에서 실행되는 워커 노드에 파드를 스케줄링해야 합니다. 단일 가용영역 내에서 노드를 프로비저닝하려면 [Cluster Autoscaler (CA)](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)를 사용하여 동일한 가용영역에 속하는 서브넷으로 노드 그룹을 정의하십시오. [Karpenter](https://karpenter.sh/)의 경우 "[_topology.kubernetes.io/zone"_](http://topology.kubernetes.io/zone%E2%80%9D)을 사용하고 워커 노드를 만들려는 가용영역를 지정합니다. 예를 들어 아래 카펜터 프로비저닝 스니펫은 us-west-2a 가용영역의 노드를 프로비저닝합니다.

**Karpenter**

```yaml hl_lines="5-9"
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
name: single-az
spec:
  requirements:
  - key: "topology.kubernetes.io/zone"
    operator: In
    values: ["us-west-2a"]
```

**Cluster Autoscaler (CA)**

```yaml hl_lines="7-8"
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-ca-cluster
  region: us-east-1
  version: "1.21"
availabilityZones:
- us-east-1a
managedNodeGroups:
- name: managed-nodes
  labels:
    role: managed-nodes
  instanceType: t3.medium
  minSize: 1
  maxSize: 10
  desiredCapacity: 1
...
```

**파드 할당 및 노드 어피니티 사용**

또는 여러 가용영역에서 실행되는 워커 노드가 있는 경우 각 노드에는 가용영역 값(예: us-west-2a 또는 us-west-2b)과 함께 _[topology.kubernetes.io/zone](http://topology.kubernetes.io/zone%E2%80%9D)_ 레이블이 붙습니다.`nodeSelector` 또는 `nodeAffinity`를 활용하여 단일 가용영역의 노드에 파드를 스케줄링할 수 있습니다. 예를 들어, 다음 매니페스트 파일은 가용영역 us-west-2a에서 실행되는 노드 내에서 파드를 스케줄링한다.

```yaml hl_lines="7-9"
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  nodeSelector:
    topology.kubernetes.io/zone: us-west-2a
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
```

### 노드로의 트래픽 제한

존 레벨에서 트래픽을 제한하는 것만으로는 충분하지 않은 경우가 있습니다. 비용 절감 외에도 상호 통신이 빈번한 특정 애플리케이션 간의 네트워크 지연 시간을 줄여야 하는 추가 요구 사항이 있을 수 있습니다. 최적의 네트워크 성능을 달성하고 비용을 절감하려면 트래픽을 특정 노드로 제한하는 방법이 필요합니다. 예를 들어 마이크로서비스 A는 고가용성(HA)설정에서도 항상 노드 1의 마이크로서비스 B와 통신해야 합니다. 노드 1의 마이크로서비스 A가 노드 2의 마이크로서비스 B와 통신하도록 하면 특히 노드 2가 완전히 별도의 AZ에 있는 경우 이러한 성격의 애플리케이션에 필요한 성능에 부정적인 영향을 미칠 수 있습니다.

**서비스 내부 트래픽 정책 사용**

파드 네트워크 트래픽을 노드로 제한하려면 _[서비스 내부 트래픽 정책](https://kubernetes.io/docs/concepts/services-networking/service-traffic-policy/)_ 을 사용할 수 있습니다. 기본적으로 워크로드 서비스로 전송되는 트래픽은 생성된 여러 엔드포인트에 무작위로 분산됩니다. 따라서 HA 아키텍처에서는 마이크로서비스 A의 트래픽이 여러 AZ의 특정 노드에 있는 마이크로서비스 B의 모든 복제본으로 이동할 수 있습니다. 하지만 서비스의 내부 트래픽 정책을 `local`로 설정하면 트래픽이 발생한 노드의 엔드포인트로 트래픽이 제한됩니다. 이 정책은 노드-로컬 엔드포인트를 독점적으로 사용하도록 규정합니다. 암시적으로 보면 해당 워크로드에 대한 네트워크 트래픽 관련 비용이 클러스터 전체에 분산되는 경우보다 낮아질 것입니다.또한 지연 시간이 짧아져 애플리케이션의 성능이 향상됩니다.

!!! note
    이 기능을 쿠버네티스의 토폴로지 인식 라우팅과 결합할 수 없다는 점에 유의해야 합니다.

![Local internal traffic](../images/local_traffic.png)

다음은 서비스의 _내부 트래픽 정책_ 을 설정하는 방법에 대한 코드 스니펫입니다.

```yaml hl_lines="14"
apiVersion: v1
kind: Service
metadata:
  name: orders-service
  namespace: ecommerce
spec:
  selector:
    app: orders
  type: ClusterIP
  ports:
  - protocol: TCP
    port: 3003
    targetPort: 3003
  internalTrafficPolicy: Local
```

트래픽 감소로 인한 예상치 못한 애플리케이션 동작을 방지하려면 다음과 같은 접근 방식을 고려해야 합니다:

* 통신하는 각 파드에 대해 충분한 레플리카 실행
* [토폴로지 분산 제약 조건](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/)을 사용하여 파드를 비교적 균일하게 분산시키십시오.
* 통신하는 파드를 동일한 노드에 배치하기 위해 [파드 어피니티 규칙](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)을 활용하세요.

이 예에서는 마이크로서비스 A의 복제본 2개와 마이크로서비스 B의 복제본 3개가 있습니다. 마이크로서비스 A의 복제본이 노드 1과 2 사이에 분산되어 있고 마이크로서비스 B의 복제본이 노드 3에 있는 경우 `local` 내부 트래픽 정책 때문에 통신할 수 없습니다. 사용 가능한 노드-로컬 엔드포인트가 없으면 트래픽이 삭제됩니다.

![node-local_no_peer](../images/no_node_local_1.png)

마이크로서비스 B의 노드 1과 2에 복제본 3개 중 2개가 있는 경우 피어 애플리케이션 간에 통신이 이루어집니다.하지만 통신할 피어 복제본이 없는 마이크로서비스 B의 격리된 복제본은 여전히 남아 있을 것입니다.

![node-local_with_peer](../images/no_node_local_2.png)

!!! note
    일부 시나리오에서는 위 다이어그램에 표시된 것과 같은 격리된 복제본이 여전히 목적(예: 외부 수신 트래픽의 요청 처리)에 부합한다면 걱정할 필요가 없을 수도 있습니다.

**토폴로지 분산 제약이 있는 서비스 내부 트래픽 정책 사용**

_내부 트래픽 정책_ 을 _토폴로지 확산 제약_ 과 함께 사용하면 서로 다른 노드의 마이크로서비스와 통신하기 위한 적절한 수의 복제본을 확보하는 데 유용할 수 있습니다.

```yaml hl_lines="16-22"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: express-test
spec:
  replicas: 6
  selector:
    matchLabels:
      app: express-test
  template:
    metadata:
      labels:
        app: express-test
        tier: backend
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: express-test
```

**파드 어피니티 규칙과 함께 서비스 내부 트래픽 정책 사용**

또 다른 접근 방식은 서비스 내부 트래픽 정책을 사용할 때 파드 어피니티 규칙을 사용하는 것입니다. 파드 어피니티를 사용하면 잦은 통신으로 인해 스케줄러가 특정 파드를 같은 위치에 배치하도록 영향을 줄 수 있다. 특정 파드에 엄격한 스케줄링 제약 조건(`RequiredDuringSchedulingExecutionDuringExecutionDuringIgnored`)을 적용하면, 스케줄러가 파드를 노드에 배치할 때 파드 코로케이션에 대해 더 나은 결과를 얻을 수 있다.

```yaml hl_lines="11-20"
apiVersion: apps/v1
kind: Deployment
metadata:
  name: graphql
  namespace: ecommerce
  labels:
    app.kubernetes.io/version: "0.1.6"
    ...
    spec:
      serviceAccountName: graphql-service-account
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - orders
            topologyKey: "kubernetes.io/hostname"
```

## 로드밸런서와 파드 통신

EKS 워크로드는 일반적으로 트래픽을 EKS 클러스터의 관련 파드로 분산하는 로드밸런서에 의해 선행됩니다. 아키텍처는 내부 또는 외부 로드밸런서로 구성될 수 있습니다. 아키텍처 및 네트워크 트래픽 구성에 따라 로드밸런서와 파드 간의 통신으로 인해 데이터 전송 요금이 크게 증가할 수 있습니다.

[AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller)를 사용하여 ELB 리소스 (ALB 및 NLB) 생성을 자동으로 관리할 수 있습니다. 이러한 설정에서 발생하는 데이터 전송 요금은 네트워크 트래픽이 사용한 경로에 따라 달라집니다. AWS Load Balancer Controller는 _인스턴스 모드_ 와 _IP 모드_ 라는 두 가지 네트워크 트래픽 모드를 지원합니다.

_인스턴스 모드_ 를 사용하면 EKS 클러스터의 각 노드에서 NodePort가 열립니다. 그러면 로드밸런서가 노드 전체에서 트래픽을 균등하게 프록시합니다. 노드에 대상 파드가 실행되고 있는 경우 데이터 전송 비용이 발생하지 않습니다. 하지만 대상 파드가 별도의 노드에 있고 트래픽을 수신하는 NodePort와 다른 AZ에 있는 경우 kube-proxy에서 대상 파드로 추가 네트워크 홉이 발생하게 된다. 이러한 시나리오에서는 AZ 간 데이터 전송 요금이 부과됩니다. 노드 전체에 트래픽이 고르게 분산되기 때문에 kube-proxy에서 관련 대상 파드로의 교차 영역 네트워크 트래픽 홉과 관련된 추가 데이터 전송 요금이 부과될 가능성이 높습니다.

아래 다이어그램은 로드밸런서에서 NodePort로, 이후에 `kube-proxy`에서 다른 AZ의 별도 노드에 있는 대상 파드로 이동하는 트래픽의 네트워크 경로를 보여줍니다. 다음은 _인스턴스 모드_ 설정의 예시이다.

![LB to Pod](../images/lb_2_pod.png)

_IP 모드_ 를 사용하면 네트워크 트래픽이 로드밸런서에서 대상 파드로 직접 프록시됩니다. 따라서 이 접근 방식에는 _데이터 전송 요금이 부과되지 않습니다_.

!!! tip
    데이터 전송 요금을 줄이려면 로드밸런서를 _IP 트래픽 모드_ 로 설정하는 것이 좋습니다. 이 설정에서는 로드밸런서가 VPC의 모든 서브넷에 배포되었는지 확인하는 것도 중요합니다.

아래 다이어그램은 네트워크 _IP 모드_ 에서 로드밸런서에서 파드로 이동하는 트래픽의 네트워크 경로를 보여줍니다.

![IP mode](../images/ip_mode.png)

## 컨테이너 레지스트리에서의 데이터 전송

### Amazon ECR

Amazon ECR 프라이빗 레지스트리로의 데이터 전송은 무료입니다. _지역 내 데이터 전송에는 비용이 들지 않습니다_. 하지만 인터넷으로 데이터를 전송하거나 지역 간에 데이터를 전송할 때는 양쪽에 인터넷 데이터 전송 요금이 부과됩니다.

ECR에 내장된 [이미지 복제 기능](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html)을 활용하여 관련 컨테이너 이미지를 워크로드와 동일한 지역에 복제해야 합니다. 이렇게 하면 복제 비용이 한 번만 청구되고 동일 리전 (리전 내) 이미지를 모두 무료로 가져올 수 있습니다.

_[인터페이스 VPC 엔드포인트](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html) 를 사용하여 지역 내 ECR 저장소에 연결하면_ ECR에서 이미지를 가져오는 작업 (데이터 전송) 과 관련된 데이터 전송 비용을 더욱 줄일 수 있습니다. NAT 게이트웨이와 인터넷 게이트웨이를 통해 ECR의 퍼블릭 AWS 엔드포인트에 연결하는 대안적인 접근 방식은 더 높은 데이터 처리 및 전송 비용을 발생시킵니다. 다음 섹션에서는 워크로드와 AWS 서비스 간의 데이터 전송 비용 절감에 대해 더 자세히 다루겠습니다.

특히 큰 이미지로 워크로드를 실행하는 경우, 미리 캐시된 컨테이너 이미지로 사용자 지정 Amazon 머신 이미지 (AMI) 를 구축할 수 있습니다. 이를 통해 초기 이미지 가져오기 시간과 컨테이너 레지스트리에서 EKS 워커 노드로의 잠재적 데이터 전송 비용을 줄일 수 있습니다.

## 인터넷 및 AWS 서비스로의 데이터 전송

인터넷을 통해 쿠버네티스 워크로드를 다른 AWS 서비스 또는 타사 도구 및 플랫폼과 통합하는 것은 일반적인 관행입니다. 관련 목적지를 오가는 트래픽을 라우팅하는 데 사용되는 기본 네트워크 인프라는 데이터 전송 프로세스에서 발생하는 비용에 영향을 미칠 수 있습니다.

### NAT 게이트웨이 사용

NAT 게이트웨이는 네트워크 주소 변환 (NAT) 을 수행하는 네트워크 구성 요소입니다. 아래 다이어그램은 다른 AWS 서비스 (Amazon ECR, DynamoDB, S3) 및 타사 플랫폼과 통신하는 EKS 클러스터의 파드를 보여줍니다. 이 예시에서는 파드가 별도의 가용영역에 있는 프라이빗 서브넷에서 실행된다. 인터넷에서 트래픽을 보내고 받기 위해 NAT 게이트웨이가 한 가용영역의 퍼블릭 서브넷에 배포되어 프라이빗 IP 주소를 가진 모든 리소스가 단일 퍼블릭 IP 주소를 공유하여 인터넷에 액세스할 수 있도록 합니다. 이 NAT 게이트웨이는 인터넷 게이트웨이 구성 요소와 통신하여 패킷을 최종 목적지로 전송할 수 있도록 합니다.

![NAT Gateway](../images/nat_gw.png)

이러한 사용 사례에 NAT 게이트웨이를 사용하면 _각 AZ에 NAT 게이트웨이를 배포하여 데이터 전송 비용을 최소화할 수 있습니다._ 이렇게 하면 인터넷으로 라우팅되는 트래픽이 동일한 AZ의 NAT 게이트웨이를 통과하므로 AZ 간 데이터 전송이 방지됩니다.그러나 AZ 간 데이터 전송 비용을 절감할 수는 있지만 이 설정의 의미는 아키텍처에 추가 NAT 게이트웨이를 설치하는 데 드는 비용이 발생한다는 것입니다.

이 권장 접근 방식은 아래 다이어그램에 나와 있습니다.

![Recommended approach](../images/recommended_approach.png)

### VPC 엔드포인트 사용

이러한 아키텍처에서 비용을 추가로 절감하려면 _[VPC 엔드포인트](https://docs.aws.amazon.com/whitepapers/latest/aws-privatelink/what-are-vpc-endpoints.html)를 사용하여 워크로드와 AWS 서비스 간의 연결을 설정해야 합니다._ VPC 엔드포인트를 사용하면 인터넷을 통과하는 데이터/네트워크 패킷 없이 VPC 내에서 AWS 서비스에 액세스할 수 있습니다. 모든 트래픽은 내부적이며 AWS 네트워크 내에 머물러 있습니다. VPC 엔드포인트에는 인터페이스 VPC 엔드포인트([많은 AWS 서비스에서 지원](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html))와 게이트웨이 VPC 엔드포인트 (S3 및 DynamoDB에서만 지원)의 두 가지 유형이 있습니다.

**게이트웨이 VPC 엔드포인트**

_게이트웨이 VPC 엔드포인트와 관련된 시간당 또는 데이터 전송 비용은 없습니다._ 게이트웨이 VPC 엔드포인트를 사용할 때는 VPC 경계를 넘어 확장할 수 없다는 점에 유의해야 합니다. VPC 피어링, VPN 네트워킹 또는 Direct Connect를 통해서는 사용할 수 없습니다.

**인터페이스 VPC 엔드포인트**

VPC 엔드포인트에는 [시간당 요금](https://aws.amazon.com/privatelink/pricing/)이 부과되며, AWS 서비스에 따라 기본 ENI를 통한 데이터 처리와 관련된 추가 요금이 부과되거나 부과되지 않을 수 있습니다. 인터페이스 VPC 엔드포인트와 관련된 가용영역 간 데이터 전송 비용을 줄이려면 각 가용영역에 VPC 엔드포인트를 만들 수 있습니다. 동일한 AWS 서비스를 가리키더라도 동일한 VPC에 여러 VPC 엔드포인트를 생성할 수 있습니다.

아래 다이어그램은 VPC 엔드포인트를 통해 AWS 서비스와 통신하는 파드를 보여줍니다.

![VPC Endpoints](../images/vpc_endpoints.png)

## VPC 간 데이터 전송

경우에 따라 서로 통신해야 하는 서로 다른 VPC(동일한 AWS 지역 내)에 워크로드가 있을 수 있습니다. 이는 각 VPC에 연결된 인터넷 게이트웨이를 통해 트래픽이 퍼블릭 인터넷을 통과하도록 허용함으로써 달성할 수 있습니다. 이러한 통신은 EC2 인스턴스, NAT 게이트웨이 또는 NAT 인스턴스와 같은 인프라 구성 요소를 퍼블릭 서브넷에 배포하여 활성화할 수 있습니다. 하지만 이러한 구성 요소가 포함된 설정에서는 VPC 내/외부로 데이터를 처리/전송하는 데 비용이 발생합니다. 개별 VPC와 주고받는 트래픽이 AZ 간에 이동하는 경우 데이터 전송 시 추가 요금이 부과됩니다. 아래 다이어그램은 NAT 게이트웨이와 인터넷 게이트웨이를 사용하여 서로 다른 VPC의 워크로드 간에 통신을 설정하는 설정을 보여줍니다.

![Between VPCs](../images/between_vpcs.png)

### VPC 피어링 연결

이러한 사용 사례에서 비용을 절감하려면 [VPC 피어링](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)을 사용할 수 있습니다. VPC 피어링 연결을 사용하면 동일한 AZ 내에 있는 네트워크 트래픽에 대한 데이터 전송 요금이 부과되지 않습니다. 트래픽이 AZ를 통과하는 경우 비용이 발생합니다. 하지만 동일한 AWS 지역 내의 개별 VPC에 있는 워크로드 간의 비용 효율적인 통신을 위해서는 VPC 피어링 접근 방식을 사용하는 것이 좋습니다. 하지만 VPC 피어링은 전이적 네트워킹을 허용하지 않기 때문에 주로 1:1 VPC 연결에 효과적이라는 점에 유의해야 합니다.

아래 다이어그램은 VPC 피어링 연결을 통한 워크로드 통신을 개괄적으로 나타낸 것입니다.

![Peering](../images/peering.png)

### 트랜지티브(Transitive) 네트워킹 연결

이전 섹션에서 설명한 것처럼 VPC 피어링 연결은 트랜지티브 네트워킹 연결을 허용하지 않습니다. 트랜지티브 네트워킹 요구 사항이 있는 VPC를 3개 이상 연결하려면 [Transit Gateway(TGW)](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)를 사용해야 합니다. 이를 통해 VPC 피어링의 한계 또는 여러 VPC 간의 다중 VPC 피어링 연결과 관련된 운영 오버헤드를 극복할 수 있습니다. TGW로 전송된 데이터에 대해서는 [시간당 요금](https://aws.amazon.com/transit-gateway/pricing/) 이 청구됩니다. _TGW를 통해 이동하는 가용영역 간 트래픽과 관련된 목적지 비용은 없습니다._

아래 다이어그램은 동일한 AWS 지역 내에 있는 서로 다른 VPC에 있는 워크로드 간에 TGW를 통해 이동하는 가용영역 간 트래픽을 보여줍니다.

![Transitive](../images/transititive.png)

## 서비스 메시 사용

서비스 메시는 EKS 클러스터 환경에서 네트워크 관련 비용을 줄이는 데 사용할 수 있는 강력한 네트워킹 기능을 제공합니다. 그러나 서비스 메시를 채택할 경우 서비스 메시로 인해 환경에 발생할 수 있는 운영 작업과 복잡성을 신중하게 고려해야 합니다.

### 가용영역으로의 트래픽 제한

**Istio의 지역성 가중 분포 사용**

Istio를 사용하면 라우팅이 발생한 _이후에_ 트래픽에 네트워크 정책을 적용할 수 있습니다. 이 작업은 [지역 가중 분포](https://istio.io/latest/docs/tasks/traffic-management/locality-load-balancing/distribute/)와 같은 [데스티네이션룰(Destination Rules)](https://istio.io/latest/docs/reference/config/networking/destination-rule/)을 사용하여 수행됩니다. 이 기능을 사용하면 출발지를 기준으로 특정 목적지로 이동할 수 있는 트래픽의 가중치 (백분율로 표시) 를 제어할 수 있습니다. 이 트래픽의 소스는 외부 (또는 공용) 로드밸런서 또는 클러스터 자체 내의 파드에서 발생할 수 있습니다. 모든 파드 엔드포인트를 사용할 수 있게 되면 가중치 기반 라운드로빈 로드 밸런싱 알고리즘을 기반으로 지역이 선택됩니다. 특정 엔드포인트가 비정상이거나 사용할 수 없는 경우, 사용 가능한 엔드포인트에 이러한 변경 사항을 반영하도록 [지역성 가중치가 자동으로 조정됩니다](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/locality_weight.html).

!!! note
    지역성 가중 배포를 구현하기 전에 먼저 네트워크 트래픽 패턴과 대상 규칙 정책이 애플리케이션 동작에 미칠 수 있는 영향을 이해해야 합니다.따라서 [AWS X-Ray](https://aws.amazon.com/xray/) 또는 [Jaeger](https://www.jaegertracing.io/)와 같은 도구를 사용하여 분산 추적(트레이싱) 메커니즘을 마련하는 것이 중요합니다.

위에서 설명한 Istio 대상 규칙을 적용하여 EKS 클러스터의 로드밸런서에서 파드로 이동하는 트래픽을 관리할 수도 있습니다. 가용성이 높은 로드밸런서 (특히 Ingress 게이트웨이) 로부터 트래픽을 수신하는 서비스에 지역성 가중치 배포 규칙을 적용할 수 있습니다. 이러한 규칙을 사용하면 영역 출처 (이 경우에는 로드밸런서) 를 기반으로 트래픽이 어디로 이동하는지 제어할 수 있습니다. 올바르게 구성하면 트래픽을 여러 가용영역의 파드 복제본에 균등하게 또는 무작위로 분배하는 로드밸런서에 비해 이그레스 교차 영역 트래픽이 덜 발생합니다.

다음은 Istio에 있는 데스티네이션룰 리소스의 코드 블록 예시입니다. 아래에서 볼 수 있듯이 이 리소스는 `eu-west-1` 지역의 서로 다른 3개 가용영역에서 들어오는 트래픽에 대한 가중치 기반 구성을 지정합니다. 이러한 구성은 특정 가용영역에서 들어오는 트래픽의 대부분 (이 경우 70%) 을 해당 트래픽이 발생한 동일한 가용영역의 대상으로 프록시해야 한다고 선언합니다.

```yaml hl_lines="7-11"
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: express-test-dr
spec:
  host: express-test.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        distribute:
        - from: eu-west-1/eu-west-1a/
          to:
            "eu-west-1/eu-west-1a/*": 70
            "eu-west-1/eu-west-1b/*": 20
            "eu-west-1/eu-west-1c/*": 10
        - from: eu-west-1/eu-west-1b/*
          to:
            "eu-west-1/eu-west-1a/*": 20
            "eu-west-1/eu-west-1b/*": 70
            "eu-west-1/eu-west-1c/*": 10
        - from: eu-west-1/eu-west-1c/*
          to:
            "eu-west-1/eu-west-1a/*": 20
            "eu-west-1/eu-west-1b/*": 10
            "eu-west-1/eu-west-1c/*": 70**
    connectionPool:
      http:
        http2MaxRequests: 10
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutiveGatewayErrors: 1
      interval: 1m
      baseEjectionTime: 30s
```

!!! note
    목적지에 분배할 수 있는 최소 가중치는 1% 입니다. 그 이유는 주 대상의 엔드포인트가 정상이 아니거나 사용할 수 없게 되는 경우에 대비하여 장애 조치 리전 및 가용영역을 유지하기 위함입니다.

아래 다이어그램은 _eu-west-1_ 지역에 고가용성 로드 밸런서가 있고 지역 가중 분배가 적용되는 시나리오를 보여줍니다. 이 다이어그램의 대상 규칙 정책은 _eu-west-1a_ 에서 들어오는 트래픽의 60% 를 동일한 AZ의 파드로 전송하도록 구성되어 있는 반면, _eu-west-1a_ 의 트래픽 중 40% 는 eu-west-1b의 파드로 이동해야 한다.

![Istio Traffic Control](../images/istio-traffic-control.png)

### 가용 영역 및 노드로의 트래픽 제한

**Istio에서 서비스 내부 트래픽 정책 사용**

파드 간의 _외부_ 수신 트래픽 및 _내부_ 트래픽과 관련된 네트워크 비용을 줄이기 위해 Istio의 대상 규칙과 쿠버네티스 서비스의 _내부 트래픽 정책_ 을 결합할 수 있습니다. Istio 목적지 규칙을 서비스 내부 트래픽 정책과 결합하는 방법은 크게 다음 세 가지 요소에 따라 달라집니다.

* 마이크로서비스의 역할
* 마이크로서비스 전반의 네트워크 트래픽 패턴
* 쿠버네티스 클러스터 토폴로지 전반에 마이크로서비스를 배포하는 방법

아래 다이어그램은 중첩된 요청의 경우 네트워크 흐름이 어떻게 표시되는지와 앞서 언급한 정책이 트래픽을 제어하는 방식을 보여줍니다.

![External and Internal traffic policy](../images/external-and-internal-traffic-policy.png)

1. 최종 사용자가 **앱 A**에 요청을 보내고, 이 요청은 다시 **앱 C**에 중첩된 요청을 보냅니다. 이 요청은 먼저 가용성이 뛰어난 로드 밸런서로 전송됩니다. 이 로드 밸런서는 위 다이어그램에서 볼 수 있듯이 AZ 1과 AZ 2에 인스턴스가 있습니다.
2. 그런 다음 외부 수신 요청은 Istio 가상 서비스에 의해 올바른 대상으로 라우팅됩니다.
3. 요청이 라우팅된 후 Istio 대상 규칙은 트래픽이 시작된 위치 (AZ 1 또는 AZ 2) 를 기반으로 각 AZ로 이동하는 트래픽 양을 제어합니다.
4. 그런 다음 트래픽은**앱 A**용 서비스로 이동한 다음 각 Pod 엔드포인트로 프록시됩니다. 다이어그램에서 볼 수 있듯이 수신 트래픽의 80% 는 AZ 1의 파드 엔드포인트로 전송되고, 수신 트래픽의 20% 는 AZ 2로 전송됩니다.
5. 그런 다음 **앱 A**가 내부적으로 **앱 C**에 요청을 보냅니다. **앱 C**의 서비스에는 내부 트래픽 정책이 활성화되어 있습니다(`내부 트래픽 정책``: 로컬`).
6. **앱 C**에 사용할 수 있는 노드-로컬 엔드포인트가 있기 때문에 **앱 A** (*노드 1*)에서 **앱 C**로의 내부 요청이 성공했습니다.
7. **앱 C**에 사용할 수 있는 _노드-로컬 엔드포인트_ 가 없기 때문에 **앱 A** (*노드 3)에서 **앱 C**에 대한 내부 요청이 실패합니다. 다이어그램에서 볼 수 있듯이 앱 C의 노드 3에는 복제본이 없습니다.****

아래 스크린샷은 이 접근법의 실제 예에서 캡처한 것입니다. 첫 번째 스크린샷 세트는 'graphql'에 대한 성공적인 외부 요청과 'graphql'에서 노드 `ip-10-0-151.af-south-1.compute.internal` 노드에 같은 위치에 있는 `orders` 복제본으로의 성공적인 중첩 요청을 보여줍니다.

![Before](../images/before.png)
![Before results](../images/before-results.png)

Istio를 사용하면 프록시가 인식하는 모든 [업스트림 클러스터](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/intro/terminology) 및 엔드포인트의 통계를 확인하고 내보낼 수 있습니다. 이를 통해 네트워크 흐름과 워크로드 서비스 간의 분산 점유율을 파악할 수 있습니다. 같은 예제를 계속하면, 다음 명령을 사용하여 `graphql` 프록시가 인식하는 `orders` 엔드포인트를 가져올 수 있습니다.

```bash
kubectl exec -it deploy/graphql -n ecommerce -c istio-proxy -- curl localhost:15000/clusters | grep orders
```

```bash
...
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_error::0**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_success::119**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_timeout::0**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**rq_total::119**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**health_flags::healthy**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**region::af-south-1**
orders-service.ecommerce.svc.cluster.local::10.0.1.33:3003::**zone::af-south-1b**
...
```

이 경우, `graphql` 프록시는 노드를 공유하는 복제본의 `orders` 엔드포인트만 인식합니다. 주문 서비스에서 `InternalTrafficPolicy: Local` 설정을 제거하고 위와 같은 명령을 다시 실행하면 결과는 서로 다른 노드에 분산된 복제본의 모든 엔드포인트를 반환합니다. 또한 각 엔드포인트의 `rq_total`을 살펴보면 네트워크 분배에서 비교적 균일한 점유율을 확인할 수 있습니다. 따라서 엔드포인트가 서로 다른 가용영역에서 실행되는 업스트림 서비스와 연결된 경우 여러 영역에 네트워크를 분산하면 비용이 더 많이 듭니다.

위의 이전 섹션에서 언급한 바와 같이, 파드 어피니티를 활용하여 자주 통신하는 파드를 같은 위치에 배치할 수 있다.

```yaml hl_lines="11-20"
...
spec:
...
  template:
    metadata:
      labels:
        app: graphql
        role: api
        workload: ecommerce
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - orders
            topologyKey: "kubernetes.io/hostname"
      nodeSelector:
        managedBy: karpenter
        billing-team: ecommerce
...
```

`graphql`과 `orders` 복제본이 동일한 노드에 공존하지 않는 경우 (`ip-10-0-0-151.af-south-1.compute.internal`), 아래 포스트맨 스크린샷의 `200 응답 코드`에서 알 수 있듯이 `graphql`에 대한 첫 번째 요청은 성공하지만, `graphql`에서 `orders`로의 두 번째 중첩 요청은 `503 응답 코드`로 실패합니다.

![After](../images/after.png)
![After results](../images/after-results.png)

## 추가 리소스

* [Istio를 사용하여 EKS의 지연 시간 및 데이터 전송 비용 해결](https://aws.amazon.com/blogs/containers/addressing-latency-and-data-transfer-costs-on-eks-using-istio/)
* [Amazon EKS의 네트워크 트래픽에 대한 토폴로지 인식 힌트의 효과 살펴보기](https://aws.amazon.com/blogs/containers/exploring-the-effect-of-topology-aware-hints-on-network-traffic-in-amazon-elastic-kubernetes-service/)
* [Amazon EKS 크로스 가용영역 파드 및 파드 네트워크 바이트에 대한 가시성 확보](https://aws.amazon.com/blogs/containers/getting-visibility-into-your-amazon-eks-cross-az-pod-to-pod-network-bytes/)
* [Istio로 가용영역 트래픽을 최적화하세요](https://youtu.be/EkpdKVm9kQY)
* [토폴로지 인식 라우팅으로 가용영역 트래픽 최적화](https://youtu.be/KFgE_lNVfz4)
* [서비스 내부 트래픽 정책을 통한 쿠버네티스 비용 및 성능 최적화](https://youtu.be/-uiF_zixEro)
* [Istio 및 서비스 내부 트래픽 정책으로 쿠버네티스 비용 및 성능을 최적화합니다.](https://youtu.be/edSgEe7Rihc)
* [공통 아키텍처의 데이터 전송 비용 개요](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
* [AWS 컨테이너 서비스의 데이터 전송 비용 이해](https://aws.amazon.com/blogs/containers/understanding-data-transfer-costs-for-aws-container-services/)

search    exclude  true                             HA                                                          AWS             AZ                                 Amazon EKS                                              EKS               VPC            ELB          ECR                                                                                EKS                                                                       Amazon EKS                                                 HA                                                                                AZ                                                EKS                                                                                https   aws amazon com blogs containers getting visibility into your amazon eks cross az pod to pod network bytes           Topology Aware Routing         Topology Aware Hint          Topology aware routing     images topo aware routing png   Topology Aware Routing                          EndpointSlices    kube proxy                                                                                EndpointSlices           EndpointSlice                                                                kube proxy                                                  EndpointSlices                        Topology aware routing   https   kubernetes io docs concepts services networking topology aware routing                           EndpointSlices                                                EndpointSlices                                                                                kube proxy                                                         kube proxy                                         EndpointSlice                                                                                Endpoint Slice     images endpoint slice png          EndPointSlice                                                                                yaml hl lines  6 7  apiVersion  v1 kind  Service metadata    name  orders service   namespace  ecommerce     annotations        service kubernetes io topology mode  Auto spec    selector      app  orders   type  ClusterIP   ports      protocol  TCP     port  3003     targetPort  3003               EndpointSlices        eu west 1a                                                        Slice shell     images slice shell png       note     Topology aware routing                                                                                https   kubernetes io docs concepts scheduling eviction topology spread constraints                                                                                Cluster Autoscaler  CA   https   github com kubernetes autoscaler tree master cluster autoscaler                                            Karpenter  https   karpenter sh          topology kubernetes io zone    http   topology kubernetes io zone E2 80 9D                                                         us west 2a                        Karpenter       yaml hl lines  5 9  apiVersion  karpenter sh v1alpha5 kind  Provisioner metadata  name  single az spec    requirements      key   topology kubernetes io zone      operator  In     values    us west 2a          Cluster Autoscaler  CA        yaml hl lines  7 8  apiVersion  eksctl io v1alpha5 kind  ClusterConfig metadata    name  my ca cluster   region  us east 1   version   1 21  availabilityZones    us east 1a managedNodeGroups    name  managed nodes   labels      role  managed nodes   instanceType  t3 medium   minSize  1   maxSize  10   desiredCapacity  1                                                                                us west 2a    us west 2b        topology kubernetes io zone  http   topology kubernetes io zone E2 80 9D              nodeSelector      nodeAffinity                                                                us west 2a                               yaml hl lines  7 9  apiVersion  v1 kind  Pod metadata    name  nginx   labels      env  test spec    nodeSelector      topology kubernetes io zone  us west 2a   containers      name  nginx     image  nginx      imagePullPolicy  IfNotPresent                                                                                A       HA             1          B               1          A     2          B                 2          AZ                                                                                https   kubernetes io docs concepts services networking service traffic policy                                                                          HA                 A          AZ                    B                                            local                                                                                note                                                         Local internal traffic     images local traffic png                                                       yaml hl lines  14  apiVersion  v1 kind  Service metadata    name  orders service   namespace  ecommerce spec    selector      app  orders   type  ClusterIP   ports      protocol  TCP     port  3003     targetPort  3003   internalTrafficPolicy  Local                                                                                https   kubernetes io docs concepts scheduling eviction topology spread constraints                                                                       https   kubernetes io docs concepts scheduling eviction assign pod node  inter pod affinity and anti affinity                          A      2           B      3                 A          1  2                     B          3         local                                                                    node local no peer     images no node local 1 png           B     1  2      3    2                                                            B                               node local with peer     images no node local 2 png       note                                                                                yaml hl lines  16 22  apiVersion  apps v1 kind  Deployment metadata    name  express test spec    replicas  6   selector      matchLabels        app  express test   template      metadata        labels          app  express test         tier  backend     spec        topologySpreadConstraints          maxSkew  1         topologyKey   topology kubernetes io zone          whenUnsatisfiable  ScheduleAnyway         labelSelector            matchLabels              app  express test                                                                                RequiredDuringSchedulingExecutionDuringExecutionDuringIgnored                                                                 yaml hl lines  11 20  apiVersion  apps v1 kind  Deployment metadata    name  graphql   namespace  ecommerce   labels      app kubernetes io version   0 1 6              spec        serviceAccountName  graphql service account       affinity          podAffinity            requiredDuringSchedulingIgnoredDuringExecution              labelSelector                matchExpressions                  key  app                 operator  In                 values                    orders             topologyKey   kubernetes io hostname                        EKS                  EKS                                                                                AWS Load Balancer Controller  https   kubernetes sigs github io aws load balancer controller        ELB      ALB   NLB                                                                            AWS Load Balancer Controller               IP                                                   EKS              NodePort                                                                                NodePort     AZ        kube proxy                                          AZ                                              kube proxy                                                                                NodePort        kube proxy       AZ                                                                         LB to Pod     images lb 2 pod png    IP                                                                                tip                             IP                                        VPC                                                  IP                                                  IP mode     images ip mode png                                Amazon ECR  Amazon ECR                                                                                ECR                  https   docs aws amazon com AmazonECR latest userguide replication html                                                                                VPC        https   docs aws amazon com whitepapers latest aws privatelink what are vpc endpoints html              ECR            ECR                                                        NAT                      ECR      AWS                                                                     AWS                                                                                Amazon         AMI                                                   EKS                                               AWS                                      AWS                                                                                NAT           NAT                    NAT                                     AWS      Amazon ECR  DynamoDB  S3                 EKS                                                                                NAT                                   IP                       IP                                 NAT                                                            NAT Gateway     images nat gw png              NAT                AZ  NAT                                                                  AZ  NAT              AZ                     AZ                                            NAT                                                                      Recommended approach     images recommended approach png       VPC                                      VPC        https   docs aws amazon com whitepapers latest aws privatelink what are vpc endpoints html              AWS                       VPC                                      VPC     AWS                                 AWS                   VPC               VPC           AWS           https   docs aws amazon com vpc latest privatelink aws services privatelink support html          VPC        S3   DynamoDB                                 VPC                 VPC                                           VPC               VPC                               VPC      VPN         Direct Connect                            VPC          VPC                  https   aws amazon com privatelink pricing          AWS            ENI                                                    VPC                                           VPC                       AWS                 VPC     VPC                               VPC           AWS                         VPC Endpoints     images vpc endpoints png      VPC                                   VPC     AWS                              VPC                                                                   EC2       NAT          NAT                                                                         VPC                                    VPC            AZ                                             NAT                              VPC                                  Between VPCs     images between vpcs png       VPC                                 VPC      https   docs aws amazon com vpc latest peering what is vpc peering html               VPC                  AZ                                               AZ                             AWS          VPC                              VPC                              VPC                               1 1 VPC                                     VPC                                         Peering     images peering png             Transitive                           VPC                                                        VPC  3            Transit Gateway TGW   https   docs aws amazon com vpc latest tgw what is transit gateway html                   VPC               VPC       VPC                                  TGW                         https   aws amazon com transit gateway pricing             TGW                                                        AWS                VPC             TGW                                Transitive     images transititive png                         EKS                                                                                Istio                  Istio                                                                 https   istio io latest docs tasks traffic management locality load balancing distribute                Destination Rules   https   istio io latest docs reference config networking destination rule                                                                                https   www envoyproxy io docs envoy latest intro arch overview upstream load balancing locality weight html         note                                                                                AWS X Ray  https   aws amazon com xray       Jaeger  https   www jaegertracing io                                                           Istio             EKS                                                            Ingress                                                                                Istio                                                    eu west 1            3                                                                              70                                                      yaml hl lines  7 11  apiVersion  networking istio io v1beta1 kind  DestinationRule metadata    name  express test dr spec    host  express test default svc cluster local   trafficPolicy      loadBalancer                                localityLbSetting          distribute            from  eu west 1 eu west 1a                to               eu west 1 eu west 1a     70               eu west 1 eu west 1b     20              eu west 1 eu west 1c     10           from  eu west 1 eu west 1b                 to               eu west 1 eu west 1a     20               eu west 1 eu west 1b     70              eu west 1 eu west 1c     10           from  eu west 1 eu west 1c                 to               eu west 1 eu west 1a     20               eu west 1 eu west 1b     10              eu west 1 eu west 1c     70       connectionPool        http          http2MaxRequests  10         maxRequestsPerConnection  10     outlierDetection        consecutiveGatewayErrors  1       interval  1m       baseEjectionTime  30s          note                           1                                                                                eu west 1                                                                      eu west 1a               60        AZ                         eu west 1a          40    eu west 1b                   Istio Traffic Control     images istio traffic control png                              Istio                                                                         Istio                                              Istio                                                                                External and Internal traffic policy     images external and internal traffic policy png   1              A                          C                                                                               AZ 1  AZ 2              2                  Istio                             3             Istio                     AZ 1    AZ 2           AZ                      4                A                  Pod                                        80    AZ 1                          20    AZ 2         5            A              C                  C                                                     6      C                                     A        1         C                     7      C                                        A        3        C                                       C     3                                                                    graphql                   graphql        ip 10 0 151 af south 1 compute internal                 orders                                Before     images before png    Before results     images before results png   Istio                                https   www envoyproxy io docs envoy latest intro arch overview intro terminology                                                                                graphql             orders                          bash kubectl exec  it deploy graphql  n ecommerce  c istio proxy    curl localhost 15000 clusters   grep orders          bash     orders service ecommerce svc cluster local  10 0 1 33 3003    rq error  0   orders service ecommerce svc cluster local  10 0 1 33 3003    rq success  119   orders service ecommerce svc cluster local  10 0 1 33 3003    rq timeout  0   orders service ecommerce svc cluster local  10 0 1 33 3003    rq total  119   orders service ecommerce svc cluster local  10 0 1 33 3003    health flags  healthy   orders service ecommerce svc cluster local  10 0 1 33 3003    region  af south 1   orders service ecommerce svc cluster local  10 0 1 33 3003    zone  af south 1b                   graphql                      orders                          InternalTrafficPolicy  Local                                                                                rq total                                                                                yaml hl lines  11 20      spec        template      metadata        labels          app  graphql         role  api         workload  ecommerce     spec        affinity          podAffinity            requiredDuringSchedulingIgnoredDuringExecution              labelSelector                matchExpressions                  key  app                 operator  In                 values                    orders             topologyKey   kubernetes io hostname        nodeSelector          managedBy  karpenter         billing team  ecommerce           graphql    orders                            ip 10 0 0 151 af south 1 compute internal                   200                   graphql                       graphql     orders                 503                     After     images after png    After results     images after results png                 Istio       EKS                        https   aws amazon com blogs containers addressing latency and data transfer costs on eks using istio      Amazon EKS                                    https   aws amazon com blogs containers exploring the effect of topology aware hints on network traffic in amazon elastic kubernetes service      Amazon EKS                                       https   aws amazon com blogs containers getting visibility into your amazon eks cross az pod to pod network bytes      Istio                    https   youtu be EkpdKVm9kQY                                 https   youtu be KFgE lNVfz4                                          https   youtu be  uiF zixEro     Istio                                           https   youtu be edSgEe7Rihc                            https   aws amazon com blogs architecture overview of data transfer costs for common architectures       AWS                         https   aws amazon com blogs containers understanding data transfer costs for aws container services


Answer:
---
search:
  exclude: true
---

# IP 주소 사용 최적화

애플리케이션 현대화로 인하여 컨테이너화된 환경의 규모가 빠른 속도로 증가하고 있습니다. 이는 점점 더 많은 워커 노드와 파드가 배포되고 있음을 의미합니다.

[아마존 VPC CNI](../vpc-cni/) 플러그인은 각 파드에 VPC CIDR의 IP 주소를 할당합니다. 이 접근 방식은 VPC flow logs 및 기타 모니터링 솔루션과 같은 도구를 사용하여 파드 주소를 완벽하게 파악할 수 있도록 합니다. 이로 인해 워크로드 유형에 따라 파드에서 상당한 수의 IP 주소를 사용할 수 있습니다.

AWS 네트워킹 아키텍처를 설계할 때는 VPC와 노드 수준에서 Amazon EKS IP 사용을 최적화하는 것이 중요합니다. 이렇게 하면 IP 고갈 문제를 완화하고 노드당 파드 밀도를 높이는 데 도움이 됩니다.

이 섹션에서는 이러한 목표를 달성하는 데 도움이 될 수 있는 기술에 대해 설명합니다.

## 노드 레벨 IP 소비 최적화

[접두사(Prefix) 위임](https://docs.aws.amazon.com/eks/latest/userguide/cni-increase-ip-addresses.html) 은 Amazon Virtual Private Cloud(Amazon VPC) 의 기능으로, 이를 통해 Amazon Elastic Compute Cloud (Amazon EC2) 인스턴스에 IPv4 또는 IPv6 접두사를 할당할 수 있습니다. 네트워크 인터페이스당 IP 주소(ENI)가 증가하여 노드당 파드 밀도가 증가하고 컴퓨팅 효율성이 향상됩니다. 사용자 지정 네트워킹에서는 접두사 위임도 지원됩니다.

자세한 내용은 [Linux 노드를 사용한 접두사 위임](../prefix-mode/index_linux/) 및 [윈도우 노드를 사용한 프리픽스 위임](../prefix-mode/index_windows/) 섹션을 참조하십시오.

## IP 소진 완화

클러스터가 사용 가능한 IP 주소를 모두 사용하지 않도록 하려면 성장을 염두에 두고 VPC와 서브넷의 크기를 조정하는 것이 좋습니다.

[IPv6](../ipv6/) 채택은 이러한 문제를 처음부터 방지할 수 있는 좋은 방법입니다. 그러나 확장성 요구 사항이 초기 계획을 초과하여 IPv6을 채택할 수 없는 조직의 경우 IP 주소 고갈에 대한 대응책으로 VPC 설계를 개선하는 것이 좋습니다. Amazon EKS 고객이 가장 일반적으로 사용하는 방법은 라우팅이 불가능한 보조 CIDR을 VPC에 추가하고 IP 주소를 Pod에 할당할 때 이 추가 IP 공간을 사용하도록 VPC CNI를 구성하는 것입니다. 이를 일반적으로 [사용자 지정 네트워킹](../custom-networking/)이라고 합니다.

노드에 할당된 IP 웜 풀을 최적화하는 데 사용할 수 있는 Amazon VPC CNI 변수에 대해 알아보겠습니다. Amazon EKS에 고유하지는 않지만 IP 고갈을 완화하는 데 도움이 될 수 있는 몇 가지 다른 아키텍처 패턴에 대해 설명하면서 이 섹션을 마치겠습니다.

### IPv6 사용 (권장사항)

IPv6을 채택하는 것이 RFC1918 제한을 해결하는 가장 쉬운 방법입니다. 네트워크 아키텍처를 선택할 때는 IPv6을 첫 번째 옵션으로 채택하는 것이 좋습니다. IPv6은 총 IP 주소 공간이 훨씬 더 넓기 때문에 클러스터 관리자는 IPv4 제한을 우회하는 데 노력을 기울이지 않고도 애플리케이션을 마이그레이션하고 확장하는 데 집중할 수 있습니다.

Amazon EKS 클러스터는 IPv4와 IPv6을 모두 지원합니다. 기본적으로 EKS 클러스터는 IPv4 주소 공간을 사용합니다. 클러스터 생성 시 IPv6 기반 주소 공간을 지정하면 IPv6을 사용할 수 있습니다. IPv6 EKS 클러스터에서 파드와 서비스는 IPv6 주소를 수신하며, **레거시 IPv4 엔드포인트를 IPv6 클러스터에서 실행되는 서비스에 연결하는 기능을 유지하며 그 반대의 경우도 마찬가지입니다**. 클러스터 내의 모든 파드 간 통신은 항상 IPv6을 통해 이루어집니다. VPC(/56)내에서 IPv6 서브넷의 IPv6 CIDR 블록 크기는 /64로 고정됩니다.이는 2^64(약 18억)의 IPv6 주소를 제공하므로 EKS에서 배포를 확장할 수 있습니다.

자세한 내용은 [IPv6 EKS 클러스터 실행](../ipv6/) 섹션을 참조하십시오. 핸즈온 실습은 [IPv6 실습 워크숍](https://catalog.workshops.aws/ipv6-on-aws/en-US) 내에 [Amazon EKS에서의 IPv6에 대한 이해](https://catalog.workshops.aws/ipv6-on-aws/en-US/lab-6) 섹션을 참조하십시오.

![EKS Cluster in IPv6 Mode, traffic flow](./ipv6.gif)

### IPv4 클러스터의 IP 사용 최적화

이 섹션은 기존 애플리케이션을 실행 중이거나 IPv6으로 마이그레이션할 준비가 되지 않은 고객을 대상으로 합니다. 모든 조직이 가능한 한 빨리 IPv6으로 마이그레이션하도록 권장하고 있지만 일부 조직에서는 IPv4로 컨테이너 워크로드를 확장하기 위한 대체 접근 방식을 모색해야 할 수도 있다는 점을 알고 있습니다. 이러한 이유로 Amazon EKS 클러스터를 사용하여 IPv4 (RFC1918) 주소 공간 소비를 최적화하는 아키텍처 패턴도 소개합니다.

#### 확장을 위한 계획

IP 고갈에 대한 첫 번째 방어선으로서 클러스터가 사용 가능한 IP 주소를 모두 소비하지 않도록 성장을 염두에 두고 IPv4 VPC와 서브넷의 크기를 조정하는 것이 좋습니다. 서브넷에 사용 가능한 IP 주소가 충분하지 않으면 새 파드나 노드를 생성할 수 없습니다.

VPC와 서브넷을 구축하기 전에 필요한 워크로드 규모에서 역방향으로 작업하는 것이 좋습니다.예를 들어 [eksctl](https://eksctl.io/)(EKS에서 클러스터를 생성하고 관리하기 위한 간단한 CLI 도구)를 사용하여 클러스터를 구축하면 기본적으로 19개의 서브넷이 생성됩니다. /19의 넷마스크는 8000개 이상의 주소를 할당할 수 있는 대부분의 워크로드 유형에 적합합니다.

!!! attention
    VPC와 서브넷의 크기를 조정할 때 IP 주소를 소비할 수 있는 요소 (예: 로드 밸런서, RDS 데이터베이스 및 기타 vpc 내 서비스) 가 여러 개 있을 수 있습니다.
또한 Amazon EKS는 컨트롤 플레인과의 통신을 허용하는 데 필요한 최대 4개의 엘라스틱 네트워크 인터페이스(X-ENI)를 생성할 수 있습니다. (자세한 내용은 [다음 문서](../subnets/)를 참고하세요.) 클러스터 업그레이드 중에 Amazon EKS는 새 X-ENI를 생성하고 업그레이드가 성공하면 이전 X-ENI를 삭제합니다. 따라서 EKS 클러스터와 연결된 서브넷의 경우 최소 /28 (16개의 IP 주소)의 넷마스크를 사용하는 것이 좋습니다.

[샘플 EKS 서브넷 계산기](../subnet-calc/subnet-calc.xlsx) 스프레드시트를 사용하여 네트워크를 계획할 수 있습니다. 스프레드시트는 워크로드 및 VPC ENI 구성을 기반으로 IP 사용량을 계산합니다. IP 사용량을 IPv4 서브넷과 비교하여 구성 및 서브넷 크기가 워크로드에 충분한지 확인합니다. VPC의 서브넷에 사용 가능한 IP 주소가 부족할 경우 VPC의 원래 CIDR 블록을 사용하여 [새 서브넷을 생성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-subnets.html#create-subnets)하는 것이 좋습니다. 이제 [Amazon EKS에서 클러스터 서브넷 및 보안 그룹을 수정](https://aws.amazon.com/about-aws/whats-new/2023/10/amazon-eks-modification-cluster-subnets-security/)할 수 있는 점에 유의하세요.

#### IP 공간 확장

RFC1918 IP 공간을 거의 사용한 경우 [커스텀 네트워킹](../custom-networking/) 패턴을 사용하여 전용 추가 서브넷 내에서 파드를 스케줄링하여 라우팅 가능한 IP를 절약할 수 있습니다.
커스텀 네트워킹은 추가 CIDR 범위에 모든 유효한 VPC 범위를 허용하지만, CG-NAT (Carrier-Grade NAT, RFC 6598) 공간의 CIDR (/16)을 사용하는 것을 추천합니다. (예: `100.64.0.0/10` 또는 `198.19.0.0/16`)  이는 RFC1918 범위보다 기업 환경에서 사용될 가능성이 적기 때문입니다.

자세한 내용은 [Custom 네트워킹](../custom-networking/) 문서를 참조하십시오.

![Custom Networking, traffic flow](./custom-networking.gif)

#### IP 웜 풀 최적화

기본 구성을 사용하면 VPC CNI가 전체 ENI(및 관련 IP)를 웜 풀에 보관합니다. 이로 인해 특히 대규모 인스턴스 유형에서 많은 IP가 소모될 수 있습니다.

클러스터 서브넷의 사용 가능한 IP 주소 수가 제한되어 있는 경우 다음 VPC CNI 구성 환경 변수를 자세히 살펴보십시오:

* `WARM_IP_TARGET`
* `MINIMUM_IP_TARGET`
* `WARM_ENI_TARGET`

노드에서 실행할 것으로 예상되는 파드의 수와 거의 일치하도록 `MINIMUM_IP_TARGET` 값을 구성할 수 있습니다. 이렇게 하면 파드가 생성되고 CNI는 EC2 API를 호출하지 않고도 웜 풀에서 IP 주소를 할당할 수 있습니다.

`WARM_IP_TARGET` 값을 너무 낮게 설정하면 EC2 API에 대한 추가 호출이 발생하고 이로 인해 요청이 병목 현상이 발생할 수 있다는 점에 유의하시기 바랍니다. 대규모 클러스터의 경우 요청의 병목 현상을 피하려면 `MINIMUM_IP_TARGET`과 함께 사용하십시오.

이러한 옵션을 구성하려면 `aws-k8s-cni.yaml` 매니페스트를 다운로드하고 환경 변수를 설정하면 됩니다. 이 글을 쓰는 시점에서 최신 릴리스는 [다음 링크](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/config/master/aws-k8s-cni.yaml)를 참조하세요. 구성 값의 버전이 설치된 VPC CNI 버전과 일치하는지 확인하세요.

!!! Warning
    CNI를 업데이트하면 이러한 설정이 기본값으로 재설정됩니다. 업데이트하기 전에 CNI를 백업해 두세요. 구성 설정을 검토하여 업데이트가 성공한 후 다시 적용해야 하는지 결정하십시오.

기존 애플리케이션을 다운타임 없이 즉시 CNI 파라미터를 조정할 수 있지만 확장성 요구 사항을 지원하는 값을 선택해야 합니다. 예를 들어, 배치 워크로드로 작업하는 경우 파드 스케일 요구 사항에 맞게 기본 `WARM_ENI_TARGET`으로 업데이트하는 것이 좋다. `WARM_ENI_TARGET`을 높은 값으로 설정하면 대규모 배치 워크로드를 실행하는 데 필요한 웜 IP 풀을 항상 유지하므로 데이터 처리 지연을 피할 수 있습니다.

!!! warning
    IP 주소 고갈에 대한 대응책은 VPC 설계를 개선하는 것이 좋습니다. IPv6 및 보조 CIDR과 같은 솔루션을 고려해 보십시오. 다른 옵션을 제외한 후에는 이러한 값을 조정하여 웜 IP 수를 최소화하는 것이 일시적인 해결책이 될 수 있습니다. 이러한 값을 잘못 구성하면 클러스터 작동에 방해가 될 수 있습니다.

    **프로덕션 시스템을 변경하기 전에** [이 페이지](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/eni-and-ip-target.md)의 고려 사항을 반드시 검토하십시오.

#### IP 주소 인벤토리 모니터링

위에서 설명한 솔루션 외에도 IP 활용도를 파악하는 것도 중요합니다. [CNI 메트릭 헬퍼](https://docs.aws.amazon.com/eks/latest/userguide/cni-metrics-helper.html)를 사용하여 서브넷의 IP 주소 인벤토리를 모니터링할 수 있습니다. 사용 가능한 일부 메트릭은 다음과 같습니다.

* 클러스터가 지원할 수 있는 최대 ENI 수
* 이미 할당된 ENI 수
* 현재 파드에 할당된 IP 주소 수
* 사용 가능한 전체 및 최대 IP 주소 수

서브넷의 IP 주소가 부족할 경우 알림을 받도록 [CloudWatch 알람](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 설정할 수도 있습니다. [CNI 메트릭 헬퍼](https://docs.aws.amazon.com/eks/latest/userguide/cni-metrics-helper.html)의 설치 지침은 EKS 사용 설명서를 참조하십시오.

!!! warning
    VPC CNI의 `DISABLE_METRICS` 변수가 false로 설정되어 있는지 확인하십시오.

#### 추가 고려 사항

Amazon EKS에 고유하지 않은 다른 아키텍처 패턴도 IP 고갈에 도움이 될 수 있습니다. 예를 들어 [VPC 간 통신을 최적화](../subnets/#communication-across-vpcs)하거나 [여러 계정에서 VPC 공유](../subnets/#sharing-vpc-across-multiple-accounts)를 사용하여 IPv4 주소 할당을 제한합니다.

여기에서 이러한 패턴에 대해 자세히 알아보세요.

* [하이퍼스케일 아마존 VPC 네트워크 설계](https://aws.amazon.com/blogs/networking-and-content-delivery/designing-hyperscale-amazon-vpc-networks/),
* [Amazon VPC Lattice를 사용하여 안전한 다중 계정 다중 VPC 연결 구축](https://aws.amazon.com/blogs/networking-and-content-delivery/build-secure-multi-account-multi-vpc-connectivity-for-your-applications-with-amazon-vpc-lattice/).

search    exclude  true         IP                                                                                VPC CNI     vpc cni               VPC CIDR  IP                     VPC flow logs                                                                                IP                  AWS                   VPC          Amazon EKS IP                            IP                                                                                IP               Prefix      https   docs aws amazon com eks latest userguide cni increase ip addresses html    Amazon Virtual Private Cloud Amazon VPC                Amazon Elastic Compute Cloud  Amazon EC2        IPv4    IPv6                              IP    ENI                                                                                Linux                    prefix mode index linux                              prefix mode index windows                   IP                     IP                                VPC                            IPv6     ipv6                                                                  IPv6                  IP                 VPC                   Amazon EKS                                    CIDR  VPC       IP     Pod             IP           VPC CNI                                       custom networking                     IP                       Amazon VPC CNI                 Amazon EKS            IP                                                                     IPv6            IPv6          RFC1918                                         IPv6                          IPv6    IP                              IPv4                                                              Amazon EKS       IPv4  IPv6                  EKS       IPv4                         IPv6                IPv6              IPv6 EKS                 IPv6                 IPv4        IPv6                                                                            IPv6             VPC  56     IPv6      IPv6 CIDR         64           2 64   18    IPv6           EKS                             IPv6 EKS             ipv6                        IPv6         https   catalog workshops aws ipv6 on aws en US      Amazon EKS    IPv6         https   catalog workshops aws ipv6 on aws en US lab 6                 EKS Cluster in IPv6 Mode  traffic flow    ipv6 gif        IPv4       IP                                  IPv6                                                   IPv6                               IPv4                                                                 Amazon EKS            IPv4  RFC1918                                                   IP                                 IP                            IPv4 VPC                                     IP                                      VPC                                                       eksctl  https   eksctl io   EKS                          CLI                            19                19        8000                                             attention     VPC                 IP                             RDS             vpc                              Amazon EKS                              4                   X ENI                                   subnets                          Amazon EKS    X ENI                      X ENI             EKS                       28  16   IP                               EKS             subnet calc subnet calc xlsx                                                VPC ENI          IP             IP      IPv4                                          VPC              IP            VPC     CIDR                      https   docs aws amazon com vpc latest userguide working with subnets html create subnets                 Amazon EKS                         https   aws amazon com about aws whats new 2023 10 amazon eks modification cluster subnets security                         IP        RFC1918 IP                             custom networking                                             IP                            CIDR            VPC            CG NAT  Carrier Grade NAT  RFC 6598      CIDR   16                       100 64 0 0 10      198 19 0 0 16       RFC1918                                            Custom          custom networking                  Custom Networking  traffic flow    custom networking gif        IP                      VPC CNI     ENI      IP                                         IP                                IP                     VPC CNI                           WARM IP TARGET      MINIMUM IP TARGET     WARM ENI TARGET                                      MINIMUM IP TARGET                                 CNI  EC2 API                 IP                   WARM IP TARGET                EC2 API                                                                                MINIMUM IP TARGET                              aws k8s cni yaml                                                              https   github com aws amazon vpc cni k8s blob master config master aws k8s cni yaml                        VPC CNI                       Warning     CNI                                         CNI                                                                              CNI                                                                                WARM ENI TARGET                   WARM ENI TARGET                                         IP                                         warning     IP                VPC                   IPv6      CIDR                                                 IP                                                                                https   github com aws amazon vpc cni k8s blob master docs eni and ip target md                            IP                               IP                      CNI         https   docs aws amazon com eks latest userguide cni metrics helper html             IP                                                                      ENI            ENI                IP                       IP            IP                     CloudWatch     https   docs aws amazon com AmazonCloudWatch latest monitoring AlarmThatSendsEmail html                 CNI         https   docs aws amazon com eks latest userguide cni metrics helper html          EKS                       warning     VPC CNI   DISABLE METRICS      false                                   Amazon EKS                      IP                          VPC               subnets  communication across vpcs              VPC        subnets  sharing vpc across multiple accounts        IPv4                                                           VPC          https   aws amazon com blogs networking and content delivery designing hyperscale amazon vpc networks       Amazon VPC Lattice                    VPC        https   aws amazon com blogs networking and content delivery build secure multi account multi vpc connectivity for your applications with amazon vpc lattice