AKS(Azure Kubernetes Service)에 대한 활성-수동 재해 복구 솔루션 개요
AKS(Azure Kubernetes Service)에서 애플리케이션을 만들고 리소스를 만드는 동안 Azure 지역을 선택하는 경우 단일 지역 앱에 해당합니다. 재해 중에 지역을 사용할 수 없게 되면 애플리케이션도 사용할 수 없게 됩니다. 보조 Azure 지역에서 동일한 배포를 만드는 경우 애플리케이션이 단일 지역 재해에 덜 취약해져서 비즈니스 연속성이 보장되며, 지역 간 데이터 복제를 통해 마지막 애플리케이션 상태를 복구할 수 있습니다.
이 가이드에서는 AKS에 대한 활성-수동 재해 복구 솔루션을 간략하게 설명합니다. 이 솔루션 내에서는 두 개의 독립적이고 동일한 AKS 클러스터를 쌍을 이루는 두 Azure 지역에 배포하며, 하나의 클러스터만 트래픽을 적극적으로 처리합니다.
참고 항목
다음 사례는 내부적으로 검토되고 Microsoft 파트너와 함께 검토되었습니다.
활성-수동 솔루션 개요
이 재해 복구 접근 방식에서는 두 개의 Azure 지역에 배포되는 두 개의 독립적인 AKS 클러스터가 있습니다. 그러나 클러스터 중 하나만 한 번에 트래픽을 적극적으로 처리합니다. 보조 클러스터(트래픽을 적극적으로 처리하지 않음)는 기본 클러스터와 동일한 구성 및 애플리케이션 데이터를 포함하지만 Azure Front Door 트래픽 관리자가 지시하지 않는 한 트래픽을 허용하지 않습니다’.
시나리오 및 구성
이 솔루션은 한 지역에서 트래픽을 적극적으로 제공하는 데이터베이스와 같은 리소스에 의존하는 애플리케이션을 호스팅할 때 가장 잘 구현됩니다. 수평 크기 조정과 같이 두 지역에 배포된 상태 비저장 애플리케이션을 호스트해야 하는 시나리오에서는 활성-수동에 추가된 대기 시간이 수반되므로 활성-활성 솔루션을 고려하는 것이 좋습니다.
구성 요소
활성-수동 재해 복구 솔루션은 많은 Azure 서비스를 사용합니다. 이 예제 아키텍처에는 다음 구성 요소가 포함됩니다.
여러 클러스터 및 지역: 각각 별도의 Azure 지역에 여러 AKS 클러스터를 배포합니다. 정상적인 작업 중에 네트워크 트래픽은 Azure Front Door 구성에 설정된 기본 AKS 클러스터로 라우팅됩니다.
구성된 클러스터 우선 순위 지정: 각 클러스터에 대해 우선 순위 수준을 1-5 사이로 설정합니다(1은 가장 높은 우선 순위이고 5는 가장 낮은 우선 순위임). 여러 클러스터를 동일한 우선 순위 수준으로 설정하고 각 클러스터에 대한 가중치를 지정할 수 있습니다. 기본 클러스터를 사용할 수 없게 되면 트래픽이 Azure Front Door에서 선택한 다음 지역으로 자동 라우팅됩니다. 이 시스템이 작동하려면 모든 트래픽이 Azure Front Door를 통과해야 합니다.
Azure Front Door: Azure Front Door는 부하 분산을 수행하고 기본 지역의 Azure Application Gateway 인스턴스로 라우팅합니다(클러스터는 우선 순위 1로 표시되어야 함). 지역 오류가 발생하는 경우 서비스는 우선 순위 목록의 다음 클러스터로 트래픽을 리디렉션합니다.
자세한 내용은 우선 순위 기반 트래픽 라우팅을 참조하세요.
허브-스포크 쌍: 허브-스포크 쌍이 각 지역 AKS 인스턴스에 대해 배포됩니다. Azure Firewall Manager 정책은 각 지역에서 방화벽 규칙을 관리합니다.
Key Vault: 각 지역에 Azure Key Vault를 프로비전하여 비밀과 키를 저장합니다.
Log Analytics: 지역별 Log Analytics 인스턴스는 지역 네트워킹 메트릭 및 진단 로그를 저장합니다. 공유 인스턴스는 모든 AKS 인스턴스에 대한 메트릭 및 진단 로그를 저장합니다.
Container Registry: 워크로드에 대한 컨테이너 이미지는 관리형 컨테이너 레지스트리에 저장됩니다. 이 솔루션을 사용하는 경우 클러스터의 모든 Kubernetes 인스턴스에 단일 Azure Container Registry 인스턴스가 사용됩니다. Azure Container Registry에 지역 복제를 사용하면 선택한 Azure 지역에 이미지를 복제하여 지역에서 중단이 발생하더라도 이미지에 대한 지속적인 액세스를 제공할 수 있습니다.
장애 조치(failover) 프로세스
한 지역에서 서비스 또는 서비스 구성 요소를 사용할 수 없게 되면 해당 서비스를 사용할 수 있는 지역으로 트래픽을 라우팅해야 합니다. 다중 지역 아키텍처는 실패 지점이 여러 개 있습니다. 이 섹션에서는 잠재적 실패 지점을 다룹니다.
애플리케이션 Pod(지역)
Kubernetes 배포 개체는 Pod의 여러 복제본(ReplicaSet)을 만듭니다. 하나를 사용할 수 없게 되면 트래픽이 나머지 복제본 간에 라우팅됩니다. Kubernetes ReplicaSet은 지정된 수의 복제본을 계속 가동하려고 시도합니다. 한 인스턴스가 다운되면 새 인스턴스를 다시 만들어야 합니다. 활동성 프로브는 Pod에서 실행 중인 애플리케이션 또는 프로세스의 상태를 확인할 수 있습니다. Pod가 응답하지 않는 경우 활동성 프로브는 Pod를 제거합니다. 그러면 ReplicaSet은 강제로 새 인스턴스를 만듭니다.
자세한 내용은 Kubernetes ReplicaSet를 참조하세요.
애플리케이션 Pod(전역)
전체 지역이 사용할 수 없게 되면 클러스터의 Pod가 더 이상 요청을 처리할 수 없습니다. 이 경우 Azure Front Door 인스턴스는 모든 트래픽을 나머지 정상 지역으로 라우팅합니다. 이러한 지역의 Kubernetes 클러스터 및 Pod는 계속해서 요청을 처리합니다. 나머지 클러스터에 대한 증가된 트래픽 및 요청을 보정하려면 다음 지침에 유의하세요.
- 네트워크 및 컴퓨팅 리소스가 지역 장애 조치(failover)로 인한 급격한 트래픽 증가를 흡수할 수 있도록 적절한 크기로 조정합니다. 예를 들어 Azure CNI(Container Network Interface)를 사용하는 경우 트래픽 부하가 급증하는 모든 Pod IP를 지원할 수 있는 서브넷을 확보합니다.
- 늘어난 지역 수요를 보정할 수 있도록 Horizontal Pod Autoscaler를 사용하여 Pod 복제본 수를 늘립니다.
- 늘어난 지역 수요를 보정할 수 있도록 AKS Cluster Autoscaler를 사용하여 Kubernetes 인스턴스 노드 수를 늘립니다.
Kubernetes 노드 풀(지역)
Azure 서버 단일 랙의 전력 공급이 중단되는 경우처럼 가끔 컴퓨팅 리소스에 지역 장애가 발생할 수 있습니다. AKS 노드가 단일 지역 실패 지점이 되지 않도록 하려면 Azure 가용성 영역을 사용합니다. 가용성 영역은 각 가용성 영역의 AKS 노드가 다른 가용성 영역에 정의된 노드와 물리적으로 분리되도록 합니다.
Kubernetes 노드 풀(전역)
한 지역 전체가 사용할 수 없게 되면 Azure Front Door는 트래픽을 나머지 정상 지역으로 라우팅합니다. 다시 말하지만, 나머지 클러스터에 대한 증가된 트래픽 및 요청을 보정해야 합니다.
장애 조치(failover) 테스트 전략
현재는 테스트 목적으로 전체 배포 지역을 중단하기 위해 AKS 내에서 사용할 수 있는 메커니즘이 없지만 Azure Chaos Studio는 클러스터에서 카오스 실험을 만들 수 있는 기능을 제공합니다.
다음 단계
다른 솔루션을 고려하는 경우 다음 문서를 참조하세요.
Azure Kubernetes Service