AKS(Azure Kubernetes Service)에 대한 다중 지역 배포 모델

AKS(Azure Kubernetes Service)는 컨테이너화된 애플리케이션을 배포, 관리 및 크기 조정하기 위한 관리되는 Kubernetes 환경을 제공합니다. AKS에서 실행되는 애플리케이션에 대한 지역 중단에 대한 복원력을 제공하기 위해 다양한 다중 지역 배포 모델을 구현할 수 있습니다. 이 문서에서는 이러한 모델에 대한 개요, 장단점 및 애플리케이션 작동 시간을 유지하기 위한 모범 사례를 제공합니다.

AKS는 클러스터 및 AKS에서 실행되는 애플리케이션에 대해 HA(고가용성) 및 DR(재해 복구)을 모두 지원하는 다양한 기능을 제공합니다. AKS에서 안정성 요구 사항을 지원하는 방법에 대한 자세한 내용은 AKS의 안정성을 참조하세요.

고려 사항

AKS에서 다중 지역 배포 모델을 구현할 때 몇 가지 중요한 고려 사항은 다음과 같습니다.

지역 및 전역 리소스

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

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

글로벌 부하 분산

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

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

범위 정의

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

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

다중 지역 배포 모델 구현

다음 표에는 AKS의 세 가지 주요 다중 지역 배포 모델과 장단점이 요약되어 있습니다.

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

활성-활성 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의 안정성
• Azure Backup을 사용한 AKS 백업 정보(미리 보기)
• Azure Backup을 사용하여 AKS 백업(미리 보기)
• 비즈니스 연속성, 고가용성 및 재해 복구