AKS(Azure Kubernetes Service)에 대한 수동 콜드 솔루션 개요

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

이 가이드에서는 AKS에 대한 수동 콜드 솔루션을 간략하게 설명합니다. 이 솔루션 내에서는 두 개의 독립적이고 동일한 AKS 클러스터를 쌍을 이루는 두 Azure 지역에 배포합니다. 여기서는 애플리케이션이 필요할 때 하나의 클러스터만 트래픽을 적극적으로 처리합니다.

수동 콜드 솔루션 개요

이 접근 방식에서는 두 개의 독립적인 AKS 클러스터를 두 개의 Azure 지역에 배포합니다. 애플리케이션이 필요한 경우 트래픽을 수신하도록 수동 클러스터를 활성화합니다. 수동 클러스터가 다운되면 트래픽 흐름을 인수하기 위해 콜드 클러스터를 수동으로 활성화해야 합니다. 매번 수동 입력을 통해 또는 특정 이벤트를 지정하여 이 조건을 설정할 수 있습니다.

시나리오 및 구성

이 솔루션은 워크로드가 특정 시간에 실행되거나 요청 시 실행되어야 하는 시나리오에 유용한 "필요에 따라 사용" 워크로드로 구현하는 것이 가장 좋습니다. 수동 콜드 접근 방식의 예제 사용 사례는 다음과 같습니다.

• 대규모 데이터 세트에서 복잡한 리소스 집약적인 시뮬레이션을 실행해야 하는 제조 회사. 이 경우 수동 클러스터는 고성능 컴퓨팅 및 스토리지 서비스를 제공하는 클라우드 지역에 있습니다. 수동 클러스터는 사용자가 시뮬레이션을 트리거하거나 일정에 따라 트리거되는 경우에만 사용됩니다. 클러스터가 트리거 시 작동하지 않는 경우 콜드 클러스터를 백업으로 사용할 수 있으며 이 클러스터에서 워크로드를 대신 실행할 수 있습니다.
• 사이버 공격이나 자연 재해 발생 시 중요한 시스템 및 데이터의 백업을 유지해야 하는 정부 기관. 이 경우 수동 클러스터는 공개적으로 액세스할 수 없는 안전하고 격리된 위치에 있습니다.

구성 요소

수동 콜드 재해 복구 솔루션은 많은 Azure 서비스를 사용합니다. 이 예제 아키텍처에서는 다음 구성 요소를 사용합니다.

여러 클러스터 및 지역: 각각 별도의 Azure 지역에 여러 AKS 클러스터를 배포합니다. 앱이 필요한 경우 수동 클러스터는 네트워크 트래픽을 수신하도록 활성화됩니다.

Key Vault: 각 지역에 Azure Key Vault를 프로비전하여 비밀과 키를 저장합니다.

Log Analytics: 지역별 Log Analytics 인스턴스는 지역 네트워킹 메트릭 및 진단 로그를 저장합니다. 공유 인스턴스는 모든 AKS 인스턴스에 대한 메트릭 및 진단 로그를 저장합니다.

허브-스포크 쌍: 허브-스포크 쌍이 각 지역 AKS 인스턴스에 대해 배포됩니다. Azure Firewall Manager 정책은 각 지역에서 방화벽 규칙을 관리합니다.

Container Registry: 워크로드에 대한 컨테이너 이미지는 관리형 컨테이너 레지스트리에 저장됩니다. 이 솔루션을 사용하는 경우 클러스터의 모든 Kubernetes 인스턴스에 단일 Azure Container Registry 인스턴스가 사용됩니다. Azure Container Registry에 지역 복제를 사용하면 선택한 Azure 지역에 이미지를 복제하여 지역에서 중단이 발생하더라도 이미지에 대한 지속적인 액세스를 제공할 수 있습니다.

장애 조치(failover) 프로세스

특정 Azure 지역의 문제로 인해 수동 클러스터가 제대로 작동하지 않는 경우 콜드 클러스터를 활성화하고 모든 트래픽을 해당 클러스터의 지역으로 리디렉션할 수 있습니다. 수동 클러스터가 다시 작동하기 시작할 때까지 비활성화되는 동안 이 프로세스를 사용할 수 있습니다. 콜드 클러스터가 꺼져 있고 설치 프로세스를 완료해야 하므로 온라인 상태가 될 때까지 몇 분 정도 걸릴 수 있습니다. 이 방법은 시간에 민감한 애플리케이션에 적합하지 않습니다. 이 경우 활성-활성 장애 조치를 고려하는 것이 좋습니다.

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

다음 단계

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

• AKS(Azure Kubernetes Service)에 대한 활성 수동 재해 복구 솔루션 개요
• AKS(Azure Kubernetes Service)에 대한 활성 고가용성 솔루션 개요