다음을 통해 공유

AKS(Azure Kubernetes Service)에 권장되는 활성-활성 고가용성 솔루션 개요

  • 아티클

AKS(Azure Kubernetes Service)에서 애플리케이션을 만들고 리소스를 만드는 동안 Azure 지역을 선택하는 경우 단일 지역 앱에 해당합니다. 지역을 사용할 수 없게 만드는 재해가 발생하는 경우 애플리케이션도 사용할 수 없게 됩니다. 보조 Azure 지역에서 동일한 배포를 만드는 경우 애플리케이션이 단일 지역 재해에 덜 취약해져서 비즈니스 연속성이 보장되며, 지역 간 데이터 복제를 통해 마지막 애플리케이션 상태를 복구할 수 있습니다.

AKS 솔루션에 대한 복구 기능을 제공할 수 있는 여러 패턴이 있지만 이 가이드에서는 AKS에 권장되는 활성-활성 고가용성 솔루션을 간략하게 설명합니다. 이 솔루션 내에서 두 개의 독립적이고 동일한 AKS 클러스터를 두 개의 쌍을 이루는 Azure 지역에 배포하고 두 클러스터가 트래픽을 적극적으로 처리합니다.

참고 항목

다음 사용 사례는 AKS 내에서 표준 사례로 간주될 수 있습니다. 내부적으로 검토되었으며 Microsoft 파트너와 함께 검토되었습니다.

활성-활성 고가용성 솔루션 개요

이 솔루션은 트래픽을 적극적으로 처리하도록 구성된 두 개의 동일한 AKS 클러스터를 사용합니다. Azure Front Door와 같은 전역 트래픽 관리자를 두 클러스터 앞에 배치하여 트래픽을 분산합니다. 솔루션이 작동하는 데 필요한 모든 애플리케이션의 인스턴스를 호스트하도록 클러스터를 일관되게 구성해야 합니다.

가용성 영역은 동일한 지역 내의 AKS 클러스터에 대한 고가용성 및 내결함성을 보장하는 또 다른 방법입니다. 가용성 영역을 사용하면 Azure 지역 내의 여러 격리된 위치에 클러스터 노드를 분산할 수 있습니다. 이렇게 하면 정전, 하드웨어 오류 또는 네트워크 문제로 인해 한 영역이 중단되는 경우 클러스터가 계속 실행되어 애플리케이션에 서비스를 제공할 수 있습니다. 또한 가용성 영역은 노드 간의 대기 시간 및 경합을 줄여 클러스터의 성능과 확장성을 향상시킵니다. AKS 클러스터에 대한 가용성 영역을 설정하려면 노드 풀을 만들거나 업데이트할 때 영역 번호를 지정해야 합니다. 자세한 내용은 Azure 가용성 영역이란?을 참조하세요.

참고 항목

많은 지역에서 가용성 영역을 지원합니다. 가용성 영역이 있는 지역을 사용하여 워크로드에 더 많은 복원력과 가용성을 제공하는 것이 좋습니다. 자세한 내용은 지역 전체의 서비스 중단으로부터 복구를 참조하세요.

시나리오 및 구성

이 솔루션은 상태 비저장 애플리케이션을 호스트하거나 수평 확장과 같이 두 지역 모두에 배포된 다른 기술을 사용할 때 가장 잘 구현됩니다. 호스트된 애플리케이션이 한 지역에서만 활발하게 활동하는 리소스(예: 데이터베이스)에 의존하는 시나리오에서는 액티브-패시브는 액티브-액티브보다 가동 중지 시간이 더 길기 때문에 잠재적인 비용 절감을 위해 액티브-패시브 솔루션을 구현하는 것이 좋습니다.

구성 요소

액티브-액티브 고가용성 솔루션은 많은 Azure 서비스를 사용합니다. 이 섹션에서는 이 다중 클러스터 아키텍처에 고유한 구성 요소만 다룹니다. 나머지 구성요소에 대한 자세한 내용은 AKS 기본 아키텍처를 참조하세요.

여러 클러스터 및 지역: 각각 별도의 Azure 지역에 여러 AKS 클러스터를 배포합니다. 정상적인 작업 중에 Azure Front Door 구성은 모든 지역 간에 네트워크 트래픽을 라우팅합니다. 한 지역을 사용할 수 없게 되면 사용자의 로드 시간이 가장 빠른 지역으로 트래픽이 라우팅됩니다.

지역별 허브-스포크 네트워크: 지역별 허브-스포크 네트워크 쌍이 각 지역 AKS 인스턴스에 대해 배포됩니다. Azure Firewall Manager 정책은 모든 지역의 방화벽 정책을 관리합니다.

지역별 키 저장소: 각 지역에 Azure Key Vault를 프로비전하여 AKS 인스턴스와 관련된 중요한 값과 키를 저장하고 해당 지역에서 제공되는 서비스를 지원합니다.

Azure Front Door: Azure Front Door는 부하를 분산하고 각 AKS 클러스터 앞에 있는 지역 Azure Application Gateway 인스턴스로 트래픽을 라우팅합니다. Azure Front Door는 계층 7 글로벌 라우팅을 허용합니다.

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는 클러스터에서 카오스 실험을 만들 수 있는 기능을 제공합니다.

다음 단계

다른 솔루션을 고려하는 경우 다음 문서를 참조하세요.