이 문서에서는 AKS(Azure Kubernetes Service) 사용량 및 비용을 최적화하는 방법에 대한 지침을 제공합니다. 다음 항목에 대한 지침을 다룹니다.
자동 크기 조정
Horizontal pod 자동 크기 조정
HPA(Horizontal Pod Autoscaler)는 리소스 수요를 모니터링하고 워크로드 리소스를 자동으로 업데이트하여 수요에 맞게 Pod 수를 자동으로 조정합니다. 부하 증가에 대한 응답은 더 많은 Pod를 배포하는 것입니다. 부하가 감소하고 Pod 수가 구성된 최소값보다 높은 경우 자동 크기 조정기는 워크로드 리소스에 규모 축소를 지시합니다.
메트릭 API는 60초마다 kubelet에서 데이터를 가져오고 HPA는 기본적으로 필요한 변경 내용에 대해 15초마다 메트릭 API를 확인합니다. 즉, HPA는 60초마다 업데이트됩니다. 배포에 대해 HPA를 구성할 때 실행할 수 있는 최소 및 최대 복제본 수와 HPA에서 크기를 조정할 시기를 결정하는 데 사용하는 메트릭을 정의합니다.
자세한 내용은 Horizontal Pod 자동 크기 조정 및 AKS에서 Pod 자동 크기 조정을 참조하세요.
Kubernetes 이벤트 기반 자동 크기 조정
Kubernetes KEDA(이벤트 기반 자동 크기 조정기)는 워크로드에 이벤트 기반 자동 크기 조정을 적용합니다. KEDA는 HPA와 함께 작동하며 덮어쓰거나 복제하지 않고도 기능을 확장할 수 있습니다.
AKS용 KEDA 추가 기능을 사용하여 애플리케이션을 확장하고 풍부한 Azure KEDA 스칼라 카탈로그를 활용할 수 있습니다. 자세한 내용은 KEDA 추가 기능을 사용하여 애플리케이션 자동 크기 조정 을 참조하고 AKS용 KEDA 추가 기능 설치를 참조하세요.
Vertical Pod 자동 크기 조정
VPA(Vertical Pod Autoscaler)는 과거 사용량에 따라 워크로드당 컨테이너에 대한 리소스 요청 및 제한을 자동으로 설정합니다. VPA는 AKS 클러스터의 효과적인 사용률을 보장하기 위해 Pod에 대한 CPU 및 메모리를 확보합니다. 시간이 지남에 따라 VPA는 리소스 사용에 대한 권장 사항을 제공합니다.
자세한 내용은 AKS(Azure Kubernetes Service)의 수직 Pod 자동 크기 조정 및 AKS(AzureKubernetes Service)에서 VPA(Vertical Pod Autoscaler) 사용)을 참조하세요.
클러스터 크기 최적화
클러스터 크기 조정
클러스터 크기를 조정하여 비용과 성능을 최적화하는 것이 중요 합니다 . 애플리케이션의 요구 사항에 맞게 노드를 추가하거나 제거하여 클러스터 크기를 수동으로 조정할 수 있습니다. 또한 변화하는 요구에 따라 노드 수를 자동으로 조정하도록 클러스터의 크기를 자동으로 조정할 수 있습니다.
자세한 내용은 AKS(Azure Kubernetes Service) 클러스터 크기 조정을 참조하세요.
클러스터 자동 크기 조정
클러스터 자동 크기 조정기를 사용하면 리소스 사용량 및 제약 조건에 따라 노드 풀의 크기를 자동으로 조정할 수 있습니다(예: 보류 중인 Pod를 예약하도록 확장하거나 사용하지 않는 노드에 대한 비용을 줄이기 위해 축소). 클러스터 자동 크기 조정기 프로필은 클러스터 자동 크기 조정기의 동작을 제어하기 위해 미세 조정할 수 있는 매개 변수 집합입니다.
자세한 내용은 AKS(Azure Kubernetes Service) 개요의 클러스터 자동 크기 조정 및 AKS(Azure Kubernetes Service)의 클러스터 자동 크기 조정을 참조하세요.
노드 자동 프로비전(미리 보기)
오픈 소스 Karpenter 프로젝트를 기반으로 하는 NAP(노드 자동 프로비전)(미리 보기)를 사용하면 워크로드의 보류 중인 Pod 리소스 요구 사항에 따라 적절한 인프라를 프로비전할 수 있습니다. 효율적인 빈 패킹을 사용하면 워크로드를 적절한 크기의 인프라에 통합하여 운영 비용을 절감할 수 있습니다.
자세한 내용은 AKS(Azure Kubernetes Service)의 노드 자동 프로비전(미리 보기)을 참조하세요.
GPU 최적화
GPU 분할 및 공유
GPU 분할은 여러 워크로드에서 GPU를 분할하거나 공유하여 사용 미달에 대처하는 데 도움이 됩니다. 다음 섹션에서는 AKS에서 GPU를 분할하고 공유하는 다양한 방법을 다룹니다.
타임 슬라이싱
NVIDIA GPU 연산자를 사용하면 Kubernetes 클러스터에서 GPU를 시간 조각화할 수 있습니다. 시간 조각화를 통해 시스템 관리자는 GPU의 복제본 집합을 정의할 수 있으며, 각 복제본은 워크로드를 실행하기 위해 Pod에 독립적으로 할당될 수 있습니다. 클러스터 전체의 기본 시간 조각화 구성 및 노드별 구성을 적용할 수 있습니다.
자세한 내용은 Kubernetes에서 시간 분할 GPU를 참조하세요.
MPS(다중 처리 서비스)
단일 프로세스는 GPU에서 사용할 수 있는 모든 메모리 및 컴퓨팅 대역폭 용량을 활용하지 못할 수 있습니다. MPS(다중 프로세스 서비스)를 사용하면 워크로드 간에 메모리 및 컴퓨팅 리소스를 논리적으로 분할할 수 있으며, 다른 프로세스의 커널 및 memcopy 작업이 GPU에서 겹칠 수 있습니다. MPS를 사용하면 GPU 사용률이 높아지고 실행 시간이 단축됩니다.
자세한 내용은 MPS(Multi-Process Service)를 참조하세요.
다중 인스턴스 GPU(MIG)
MIG(다중 인스턴스 GPU) 를 사용하면 NVIDIA Ampere 이상 아키텍처에 따라 GPU를 CUDA 애플리케이션에 대한 별도의 보안 GPU 인스턴스로 분할할 수 있습니다.
자세한 내용은 MIG를 사용하여 GPU 연산자 및 AKS(Azure Kubernetes Service)에서 다중 인스턴스 GPU 노드 풀 만들기를 참조하세요.
다중 테넌시
다중 테넌트는 테넌트, 팀 및 사업부 간에 인프라를 공유하는 것을 의미합니다. 다음 표에서는 AKS에서 다중 테넌시를 구현하는 다양한 방법을 간략하게 설명합니다.
| 다중 테넌트 유형 | 다중 테넌트 수준 | 클러스터 파드 밀도 | 비용 할당 | 이상적인 사용 사례 | 잠재적 위험 |
|---|---|---|---|---|---|
| 전용 클러스터 | 하드 다중 테넌트 | 낮추다 | 가장 쉬운 | 완전한 보안 격리 경계 및 간단한 비용 할당 | • 대규모 클러스터 확장으로 관리 오버헤드 비용 추가 • 낮은 Pod 밀도 및 더 많은 과도하게 프로비전된 리소스 |
| 전용 노드 풀 | 유연한 다중 테넌시 | 중간 | 중간 | 중간 팟 밀도 | • 테넌트 간의 신뢰 필요 • 네트워크 정책, 할당량 관리, RBAC(역할 기반 액세스 제어) 등과 같은 추가 클러스터 구성이 필요합니다. |
| 전용 네임스페이스 | 유연한 다중 테넌시 | 더 높음 | 더 어려움 | 인프라를 공유하여 리소스 사용률 최대화 | • 기본적으로 적대적인 환경에 안전하지 않음 • 네트워크 정책, 할당량 관리, RBAC(역할 기반 액세스 제어) 등과 같은 추가 클러스터 구성이 필요합니다. |
전용 클러스터
전용 클러스터 다중 테넌트를 사용하면 클러스터가 단일 워크로드 또는 팀에 전용으로 제공됩니다.
다음 표에서는 전용 클러스터 사용의 장단점을 간략하게 설명합니다.
| 장점 | Cons |
|---|---|
| • 더 쉬운 격리 방법 • 간단한 비용 할당 및 차지백 • 테넌트가 서로 신뢰하지 않는 경우에 적합합니다(종종 보안 및 리소스 공유 관점에서) |
• 높은 관리 및 재무 오버헤드 • 일반적으로 낮은 Pod 밀도 및 과다하게 할당된 리소스 |
전용 노드 풀
전용 노드 풀 다중 테넌트에서 클러스터는 많은 테넌트에서 공유됩니다.
다음 표에서는 전용 노드 풀 사용의 장단점을 간략하게 설명합니다.
| 장점 | Cons |
|---|---|
| • 중간 Pod 밀도 • 일부 공유 인프라 • 단일 테넌트 전용 노드 풀에 Azure 태그 적용(태그가 노드에 전파되고 업그레이드를 통해 유지됨) |
• 테넌트 간의 신뢰 필요 • 네트워크 정책, 할당량 관리, RBAC(역할 기반 액세스 제어) 등과 같은 추가 클러스터 구성이 필요합니다. |
전용 네임스페이스
전용 네임스페이스 다중 테넌트에서 클러스터는 격리 경계 역할을 하는 네임스페이스를 사용하여 많은 테넌트에서 공유됩니다.
다음 표에서는 전용 네임스페이스 사용의 장단점을 간략하게 설명합니다.
| 장점 | Cons |
|---|---|
| • 더 높은 Pod 밀도 • 최고의 빈패킹 • 인프라를 공유하여 리소스 사용률 극대화 |
• 기본적으로 적대적인 환경에 안전하지 않음 • 모든 테넌트가 신뢰할 수 없는 경우 추가 보안 조치가 필요합니다. |
Azure 할인
한 단계 더 절감하려면 Azure 저축 플랜, 예약 인스턴스 및 Azure 하이브리드 혜택과 같은 Azure 할인을 활용합니다.
| Azure 할인 유형 | 세부 정보 |
|---|---|
| Azure 저축 플랜 | • 1-3년 선불 약정 • 종량제에 비해 최대 65% 절약 • SKU 패밀리 또는 지역 제한 없이 유연 • 다양한 SKU 및 지역의 리소스와 일관된 비용이 있는 워크로드에 가장 적합합니다. |
| 예약 인스턴스 | • 1-3년 선불 약정 • 종량제에 비해 최대 72% 절약 • 특정 SKU 제품군 및 지역으로 제한됨 • 지속적으로 실행되는 안정적인 워크로드에 가장 적합합니다(예기치 않은 SKU 또는 지역 변경 없음) |
| Azure 하이브리드 혜택 | • Azure에 고유한 온-프레미스 Windows Server 및 SQL Server 라이선스 가져오기 • 활성 SA(Software Assurance) 또는 적격 구독이 있는 경우, 모든 적격 온프레미스 라이선스를 사용합니다. |
다음 단계
AKS의 비용에 대한 자세한 내용은 다음 문서를 참조하세요.