AKS(Azure Kubernetes Service)에 대한 고가용성 및 재해 복구 개요

클라우드에서 애플리케이션을 생성하고 관리할 때 가동 중단 및 재해로 인한 중단 위험이 항상 존재합니다. BC(비즈니스 연속성)를 보장하려면 HA(고가용성) 및 DR(재해 복구)을 계획해야 합니다.

HA는 안정성이 뛰어나고 가동 중지 시간이 최소화되는 시스템 또는 서비스의 설계 및 구현을 의미합니다. HA는 시스템이나 서비스가 의도한 기능을 수행할 수 있도록 보장하는 도구, 기술 및 프로세스의 조합입니다. HA는 DR 계획의 중요한 구성 요소입니다. DR은 재해로부터 복구하고 비즈니스 운영을 정상 상태로 복원하는 프로세스입니다. DR은 BC의 하위 집합으로, 비즈니스 기능을 유지하거나 중대한 중단 발생 시 신속하게 재개하는 프로세스입니다.

이 문서에서는 AKS에 배포된 애플리케이션에 대한 몇 가지 권장 사례를 다루지만, 가능한 솔루션의 전체 목록을 의미하는 것은 아닙니다.

기술 개요

Kubernetes 클러스터는 다음 두 가지 구성 요소로 구분됩니다.

• 핵심 Kubernetes 서비스 및 애플리케이션 워크로드 오케스트레이션을 제공하는 컨트롤 플레인 및
• 애플리케이션 워크로드를 실행하는 노드입니다.

AKS 클러스터를 만들면 Azure 플랫폼은 자동으로 컨트롤 플레인을 만들고 구성합니다. AKS는 클러스터 관리를 위한 두 가지 가격 책정 계층인 무료 계층 및 표준 계층을 제공합니다. 자세한 내용은 AKS 클러스터 관리에 대한 무료 및 표준 가격 책정 계층을 참조하세요.

컨트롤 플레인 및 해당 리소스는 클러스터를 만든 지역에만 상주합니다. AKS는 전용 API 서버, 스케줄러 등이 포함된 단일 테넌트 컨트롤 플레인을 제공합니다. 노드의 수와 크기를 정의하고, Azure 플랫폼에서 컨트롤 플레인과 노드 간의 보안 통신을 구성합니다. 컨트롤 플레인과의 상호 작용은 kubectl 또는 Kubernetes 대시보드와 같은 Kubernetes API를 통해 수행됩니다.

애플리케이션과 지원 서비스를 실행하려면 Kubernetes 노드가 필요합니다. AKS 클러스터에는 Kubernetes 노드 구성 요소 및 컨테이너 런타임을 실행하는 하나 이상의 노드, 즉 Azure VM(가상 머신)이 있습니다. 노드의 Azure VM 크기는 CPU, 메모리, 크기, 사용 가능한 스토리지 유형(예: 고성능 SSD 또는 일반 HDD)을 정의합니다. 애플리케이션에 많은 양의 CPU 및 메모리 또는 고성능 스토리지가 필요한지 여부를 기준으로 VM 및 스토리지 크기를 계획합니다. AKS에서 클러스터 노드의 VM 이미지는 Ubuntu Linux, Azure Linux 또는 Windows Server 2022를 기반으로 합니다. AKS 클러스터를 만들거나 노드 수를 스케일 아웃하면 Azure 플랫폼에서 요청된 수의 VM을 자동으로 만들고 구성합니다.

AKS의 클러스터 및 워크로드 구성 요소에 대한 자세한 내용은 AKS에 대한 Kubernetes 핵심 개념을 참조하세요.

중요 사항

지역 및 전역 리소스

지역 리소스는 단일 Azure 지역에 배포 스탬프의 일부로 프로비전됩니다. 이러한 리소스는 다른 지역의 리소스와 아무것도 공유하지 않으며 독립적으로 제거하거나 다른 지역에 복제할 수 있습니다. 자세한 내용은 지역 리소스를 참조하세요.

전역 리소스는 시스템 수명을 공유하며 다중 지역 배포의 컨텍스트 내에서 전역적으로 사용할 수 있습니다. 자세한 내용은 글로벌 리소스를 참조하세요.

복구 목표

완전한 재해 복구 계획은 애플리케이션이 구현하는 각 프로세스에 대한 비즈니스 요구 사항을 지정해야 합니다.

• RPO(복구 지점 목표): 허용되는 최대 데이터 손실 기간입니다. RPO는 분, 시간 또는 일과 같은 시간 단위로 측정됩니다.
• RTO(복구 시간 목표)는 허용 가능한 가동 중지 시간의 최대 기간이며 가동 중지 시간은 사양에 따라 정의됩니다. 예를 들어, 재해 발생 시 허용되는 가동 중지 시간이 8시간이면 RTO는 8시간입니다.

가용성 영역

가용성 영역을 사용하여 동일한 지역의 여러 영역에 데이터를 분산시킬 수 있습니다. 한 지역 내에서 가용성 영역은 다른 가용성 영역에 대해 대기 시간이 짧은 연결을 가질 수 있을 만큼 충분히 가깝지만 둘 이상의 가용성 영역이 지역 중단이나 날씨의 영향을 받을 가능성을 줄일 수 있을 만큼 충분히 떨어져 있습니다. 자세한 내용은 가용성 영역 및 지역 사용에 대한 권장 사항을 참조하세요.

영역 복원력

AKS 클러스터는 영역 오류에 대해 복원력이 있습니다. 영역에 오류가 발생하는 경우 클러스터는 나머지 영역에서 계속 실행됩니다. 클러스터의 컨트롤 플레인 및 노드는 여러 영역에 분산되어 있으며 Azure 플랫폼은 자동으로 노드 배포를 처리합니다. 자세한 내용은 AKS 영역 복원력을 참조하세요.

부하 분산

전역 부하 분산

전역 부하 분산 서비스는 트래픽을 지역 백 엔드, 클라우드 또는 하이브리드 온-프레미스 서비스에 분산합니다. 이러한 서비스는 최종 사용자 트래픽을 가장 가깝고 사용 가능한 백 엔드로 라우팅합니다. 또한 가용성과 성능을 최대화하기 위해 서비스 안정성이나 성능의 변화에 대응합니다. 다음 Azure 서비스는 전역 부하 분산을 제공합니다.

• Azure Front Door
• Azure Traffic Manager
• 영역 간 Azure Load Balancer
• Azure Kubernetes Fleet Manager

지역 부하 분산

지역 부하 분산 서비스는 VM 전체 또는 지역 내의 영역 및 영역 중복 서비스 엔드포인트에 걸쳐 가상 네트워크 내에서 트래픽을 분산합니다. 다음 Azure 서비스는 지역 부하 분산을 제공합니다.

• Azure Load Balancer
• Azure Application Gateway
• 컨테이너용 Azure Application Gateway

가시성

효과적인 운영과 안정성 최대화를 위해서는 애플리케이션과 인프라에서 데이터를 수집해야 합니다. Azure는 AKS 워크로드를 모니터링하고 관리하는 데 도움이 되는 도구를 제공합니다. 자세한 내용은 가시성 리소스를 참조하세요.

범위 정의

AKS 클러스터를 관리할 때 애플리케이션 작동 시간이 중요해집니다. 기본적으로 AKS는 Virtual Machine Scale Set의 여러 노드를 사용하여 고가용성을 제공하지만 이러한 노드는 지역 오류로부터 시스템을 보호하지 않습니다. 작동 시간을 최대화하려면 다음 모범 사례를 사용하여 비즈니스 연속성을 유지 관리하고 재해 복구를 준비하도록 미리 계획합니다.

• 여러 지역에서 AKS 클러스터 계획 작성.
• Azure Traffic Manager를 사용하여 여러 클러스터에 트래픽 라우팅.
• 컨테이너 이미지 레지스트리에 지역에서 복제 사용.
• 여러 클러스터에서 애플리케이션 상태 계획 작성.
• 여러 지역의 스토리지 복제.

배포 모델 구현

배포 모델	장점	단점
‘활성-활성’	• 장애 조치(failover) 중 데이터 손실 또는 불일치 없음 • 높은 복원력 • 더 높은 성능으로 리소스 활용도 향상	• 복잡한 구현 및 관리 • 더 높은 비용 • 부하 분산 장치 및 트래픽 라우팅 형식이 필요함
활성-수동	• 보다 간단한 구현 및 관리 • 비용 절감 • 부하 분산 장치 또는 트래픽 관리자가 필요하지 않음	• 장애 조치(failover) 중 데이터 손실 또는 불일치 가능성 • 더 긴 복구 시간 및 가동 중지 시간 • 리소스 미달 사용
수동-콜드	• 최저 비용 • 동기화, 복제, 부하 분산 장치 또는 트래픽 관리자가 필요하지 않음 • 우선 순위가 낮고 중요하지 않은 워크로드에 적합	• 장애 조치(failover) 중 데이터 손실 또는 불일치 위험이 높음 • 가장 긴 복구 시간 및 가동 중지 시간 • 클러스터를 활성화하고 백업을 트리거하려면 수동 개입이 필요함

활성-활성 고가용성 배포 모델

활성-활성 HA(고가용성) 배포 모델에는 트래픽을 적극적으로 처리하는 두 개의 서로 다른 Azure 지역(일반적으로 캐나다 중부 및 캐나다 동부 또는 미국 동부 2 및 미국 중부와 같이 쌍을 이루는 지역)에 배포된 두 개의 독립적인 AKS 클러스터가 있습니다.

이 예제 아키텍처를 사용할 경우:

• 두 개의 AKS 클러스터를 별도의 Azure 지역에 배포합니다.
• 정상 작동 중에 네트워크 트래픽은 두 지역 간에 라우팅됩니다. 한 지역이 사용할 수 없게 되면 트래픽은 요청을 발행한 사용자와 가장 가까운 지역으로 자동 라우팅됩니다.
• 각 지역 AKS 인스턴스마다 배포된 허브-스포크 쌍이 있습니다. Azure Firewall Manager 정책은 지역 전체의 방화벽 규칙을 관리합니다.
• Azure Key Vault는 비밀과 키를 저장하기 위해 각 지역에 프로비전됩니다.
• Azure Front Door는 각 AKS 클러스터 앞에 있는 지역 Azure Application Gateway 인스턴스로 트래픽을 부하 분산하고 라우팅합니다.
• 지역 Log Analytics 인스턴스는 지역 네트워킹 메트릭과 진단 로그를 저장합니다.
• 워크로드에 대한 컨테이너 이미지는 관리형 컨테이너 레지스트리에 저장됩니다. 클러스터의 모든 Kubernetes 인스턴스에 단일 Azure Container Registry가 사용됩니다. Azure Container Registry에 대한 지역 복제를 사용하면 선택한 Azure 지역에 이미지를 복제하고 지역에 중단이 발생하더라도 이미지에 대한 지속적인 액세스를 제공할 수 있습니다.

AKS에서 활성-활성 배포 모델을 만들려면 다음 단계를 수행합니다.

1. 두 개의 서로 다른 Azure 지역에 두 개의 동일한 배포를 만듭니다.

2. 웹앱의 두 인스턴스를 만듭니다.

3. 다음을 리소스를 사용하여 Azure Front Door 프로필을 만듭니다.

   • 엔드포인트.
   • 두 개의 원본 그룹은 각각 1의 우선 순위를 갖습니다.
   • 경로.

4. Azure Front Door 인스턴스의 웹앱으로만 네트워크 트래픽을 제한합니다. 5. 데이터베이스, 스토리지 계정 및 인증 공급자와 같은 다른 모든 백 엔드 Azure 서비스를 구성합니다.

5. 지속적인 배포를 사용하여 두 웹앱에 코드를 배포합니다.

자세한 내용은 AKS에 권장되는 활성-활성 고가용성 솔루션 개요를 참조하세요.

활성-수동 재해 복구 배포 모델

활성-수동 DR(재해 복구) 배포 모델에는 트래픽을 적극적으로 처리하는 두 개의 서로 다른 Azure 지역(일반적으로 캐나다 중부 및 캐나다 동부 또는 미국 동부 2 및 미국 중부와 같이 쌍을 이루는 지역)에 배포된 두 개의 독립적인 AKS 클러스터가 있습니다. 주어진 시간에 클러스터 중 하나만 적극적으로 트래픽을 처리합니다. 다른 클러스터에는 활성 클러스터와 동일한 구성 및 애플리케이션 데이터가 포함되어 있지만 트래픽 관리자가 지시하지 않는 한 트래픽을 허용하지 않습니다.

이 예제 아키텍처를 사용할 경우:

• 두 개의 AKS 클러스터를 별도의 Azure 지역에 배포합니다.
• 정상적인 작업 중에 네트워크 트래픽은 Azure Front Door 구성에서 설정한 기본 AKS 클러스터로 라우팅됩니다.
  • 우선 순위는 1-5 사이에서 설정해야 하며 1이 가장 높고 5가 가장 낮습니다.
  • 여러 클러스터를 동일한 우선 순위 수준으로 설정하고 각각의 가중치를 지정할 수 있습니다.
• 기본 클러스터를 사용할 수 없게 되면(재해 발생) 트래픽이 Azure Front Door에서 선택한 다음 지역으로 자동 라우팅됩니다.
  • 이 시스템이 작동하려면 모든 트래픽이 Azure Front Door 트래픽 관리자를 통과해야 합니다.
• Azure Front Door는 트래픽을 주 지역의 Azure App Gateway로 라우팅합니다(클러스터는 우선 순위 1로 표시되어야 함). 이 지역에 오류가 발생하는 경우 서비스는 우선 순위 목록의 다음 클러스터로 트래픽을 리디렉션합니다.
  • 규칙은 Azure Front Door에서 제공됩니다.
• 허브-스포크 쌍이 각 지역 AKS 인스턴스에 대해 배포됩니다. Azure Firewall Manager 정책은 지역 전체의 방화벽 규칙을 관리합니다.
• Azure Key Vault는 비밀과 키를 저장하기 위해 각 지역에 프로비전됩니다.
• 지역 Log Analytics 인스턴스는 지역 네트워킹 메트릭과 진단 로그를 저장합니다.
• 워크로드에 대한 컨테이너 이미지는 관리형 컨테이너 레지스트리에 저장됩니다. 클러스터의 모든 Kubernetes 인스턴스에 단일 Azure Container Registry가 사용됩니다. Azure Container Registry에 대한 지역 복제를 사용하면 선택한 Azure 지역에 이미지를 복제하고 지역에 중단이 발생하더라도 이미지에 대한 지속적인 액세스를 제공할 수 있습니다.

AKS에서 활성-수동 배포 모델을 만들려면 다음 단계를 수행합니다.

1. 두 개의 서로 다른 Azure 지역에 두 개의 동일한 배포를 만듭니다.

2. 주 지역이 비활성화될 때 기본 애플리케이션과 동일한 인스턴스 수로 확장되도록 보조 애플리케이션에 대한 자동 크기 조정 규칙을 구성합니다. 비활성 상태에서는 확장할 필요가 없습니다. 이렇게 하면 비용을 절감할 수 있습니다.

3. 각 클러스터에 하나씩 웹 애플리케이션의 인스턴스 두 개를 만듭니다.

4. 다음을 리소스를 사용하여 Azure Front Door 프로필을 만듭니다.

   • 엔드포인트.
   • 주 지역에 대해 우선 순위가 1인 원본 그룹.
   • 보조 지역에 대해 우선 순위가 2인 두 번째 원본 그룹.
   • 경로.

5. Azure Front Door 인스턴스에서만 웹 애플리케이션에 대한 네트워크 트래픽을 제한합니다.

6. 데이터베이스, 스토리지 계정 및 인증 공급자와 같은 다른 모든 백 엔드 Azure 서비스를 구성합니다.

7. 지속적인 배포를 사용하여 두 웹 애플리케이션에 코드를 배포합니다.

자세한 내용은 AKS에 권장되는 활성-수동 재해 복구 솔루션 개요를 참조하세요.

수동-콜드 장애 조치(failover) 배포 모델

수동-콜드 장애 조치(failover) 배포 모델은 재해 발생 시 사용자가 클러스터를 활성화할 때까지 클러스터가 비활성 상태로 유지된다는 점을 제외하면 활성-수동 재해 복구 배포 모델과 동일한 방식으로 구성됩니다. 이 접근 방식은 활성-수동 구성과 유사하지만 클러스터를 활성화하고 백업을 트리거하기 위한 수동 개입이 더 복잡하기 때문에 범위 외로 간주합니다.

이 예제 아키텍처를 사용할 경우:

• 복원력을 높이기 위해 서로 다른 지역이나 영역에 두 개의 AKS 클러스터를 만드는 것이 좋습니다.
• 장애 조치(failover)가 필요한 경우 배포를 활성화하여 트래픽 흐름을 인계받습니다.
• 기본 수동 클러스터가 다운되는 경우 콜드 클러스터를 수동으로 활성화하여 트래픽 흐름을 인계받아야 합니다.
• 이 조건은 매번 수동으로 입력하거나 사용자가 지정한 특정 이벤트를 통해 설정해야 합니다.
• Azure Key Vault는 비밀과 키를 저장하기 위해 각 지역에 프로비전됩니다.
• 지역 Log Analytics 인스턴스는 각 클러스터에 대한 지역 네트워킹 메트릭과 진단 로그를 저장합니다.

AKS에서 수동-콜드 장애 조치(failover) 배포 모델을 만들려면 다음 단계를 수행합니다.

1. 서로 다른 영역/지역에 두 개의 동일한 배포를 만듭니다.
2. 주 지역이 비활성화될 때 기본 애플리케이션과 동일한 인스턴스 수로 확장되도록 보조 애플리케이션에 대한 자동 크기 조정 규칙을 구성합니다. 비활성 상태에서는 확장할 필요가 없으므로 비용 절감에 도움이 됩니다.
3. 각 클러스터에 하나씩 웹 애플리케이션의 인스턴스 두 개를 만듭니다.
4. 데이터베이스, 스토리지 계정 및 인증 공급자와 같은 다른 모든 백 엔드 Azure 서비스를 구성합니다.
5. 콜드 클러스터를 트리거해야 하는 경우 조건을 설정합니다. 필요한 경우 부하 분산 장치를 사용할 수 있습니다.

자세한 내용은 AKS에 권장되는 수동-콜드 장애 조치(failover) 솔루션 개요를 참조하세요.

서비스 할당량 및 제한

AKS는 특정 VM SKU에 대한 사용 제한을 포함하여 리소스 및 기능에 대한 기본 제한과 할당량을 설정합니다.

리소스	제한
구독당 최대 클러스터 수	5,000 참고: Azure API 제한 한도를 고려하도록 여러 지역에 클러스터 분산
Virtual Machine Scale Sets 및 표준 Load Balancer SKU를 사용하는 클러스터당 최대 노드 수	모든 노드 풀에서 5000개 참고: 클러스터당 최대 5,000개의 노드를 확장할 수 없는 경우 대규모 클러스터에 대한 모범 사례를 참조 하세요.
노드 풀당 최대 노드(Virtual Machine Scale Sets 노드 풀)	1000
클러스터당 최대 노드 풀	100
노드당 최대 Pod 수: Kubenet 네트워킹 플러그 인1 사용	최대: 250 Azure CLI 기본값: 110 Azure Resource Manager 템플릿 기본값: 110 Azure Portal 배포 기본값: 30
노드당 최대 Pod 수: Azure Container Networking Interface(Azure CNI)1 사용	최대: 250 Windows Server 컨테이너에 권장되는 최대 개수: 110개 기본값: 30
OSM(오픈 서비스 메시) AKS 추가 기능	Kubernetes 클러스터 버전: AKS 지원 버전 클러스터당 OSM 컨트롤러: 1 OSM 컨트롤러당 Pod: 1600 OSM에서 관리하는 Kubernetes 서비스 계정: 160
표준 Load Balancer SKU를 사용하여 클러스터당 최대 부하 분산 kubernetes 서비스 유지	300
Virtual Machine Availability Sets 및 기본 Load Balancer SKU를 사용하는 클러스터당 최대 노드 수	100

¹ Windows Server 컨테이너는 Azure CNI 네트워킹 플러그 인을 사용해야 합니다. Kubenet은 Windows Server 컨테이너에서 지원되지 않습니다.

Kubernetes 컨트롤 플레인 계층	제한
표준 계층	부하에 따라 Kubernetes API 서버를 자동으로 스케일링합니다. 더 큰 컨트롤 플레인 구성 요소 제한 및 API 서버/등 인스턴스.
무료 계층	리소스의 진행 중 요청 제한이 50개 변형 호출 및 100개 읽기 전용 호출로 제한됩니다. 권장되는 노드 제한이 클러스터당 10개 노드입니다. 실험, 학습 및 간단한 테스트에 가장 적합합니다. 프로덕션/중요 워크로드에는 권장되지 않습니다.

자세한 내용은 AKS 서비스 할당량 및 제한을 참조하세요.

Backup

Azure Backup은 백업 확장을 사용하여 클러스터에 연결된 AKS 클러스터 리소스 및 영구 볼륨 백업을 지원합니다. Backup 자격 증명 모음은 확장을 통해 AKS 클러스터와 통신하여 백업 및 복원 작업을 수행합니다.

자세한 내용은 다음 문서를 참조하세요.

• Azure Backup을 사용한 AKS 백업 정보(미리 보기)
• Azure Backup을 사용하여 AKS 백업(미리 보기)