Share via

AKS(Azure Kubernetes Service) 및 MySQL 유연한 서버 워크로드를 가용성 영역 지원으로 마이그레이션

  • 아티클

이 가이드에서는 Azure Kubernetes Service 및 MySQL 유연한 서버 워크로드를 마이그레이션하여 모든 종속 서비스에서 가용성 영역 지원을 완료하는 방법을 설명합니다. 모든 워크로드 종속성의 전체 목록은 워크로드 서비스 종속성을 참조하세요.

AKS 클러스터 또는 MySQL 유연한 서버를 만드는 동안 이 워크로드에 대한 가용성 영역 지원을 사용하도록 설정해야 합니다. 기존 AKS 클러스터 및 MySQL 유연한 서버에 대한 가용성 영역 지원을 원하는 경우 해당 리소스를 다시 배포해야 합니다.

이 마이그레이션 지침은 주로 Azure에서 다음 아키텍처를 실행하는 인프라 및 가용성 고려 사항에 중점을 둡니다.

Picture showing first part of workflow architecture

Picture showing second part of workflow architecture

워크로드 서비스 종속성

가용성 영역에 대한 전체 워크로드 지원을 제공하려면 워크로드의 각 서비스 종속성이 가용성 영역을 지원해야 합니다.

가용성 영역 지원 서비스의 두 가지 접근 방식 유형인 영역 또는 영역 중복이 있습니다. 대부분의 서비스는 하나 또는 다른 서비스를 지원합니다. 그러나 경우에 따라 해당 서비스에 대한 영역 또는 영역 중복 리소스를 선택하는 옵션이 있습니다. 다음 권장 사항에서 영역 및 영역 중복 리소스를 지원하는 서비스를 나타냅니다. 또한 글로벌 및 지역 서비스를 나타냅니다.

AKS 및 MySQL 워크로드 아키텍처는 다음 구성 요소 종속성으로 구성됩니다.

AKS(Azure Kubernetes Service)

  • 영역: 만들 때 노드 풀이 배포되는 영역을 미리 선택하면 시스템 노드 풀 및 사용자 노드 풀이 영역입니다. 복원력을 높이기 위해 세 영역을 모두 미리 선택하는 것이 좋습니다. 가용성 영역을 지원하는 더 많은 사용자 노드 풀을 기존 AKS 클러스터에 추가하고 zones 매개 변수에 대한 값을 제공하여 추가할 수 있습니다.

  • 영역 중복: etcd, API server, Scheduler 및 컨트롤러 관리자와 같은 Kubernetes 컨트롤 플레인 구성 요소는 영역 간에 자동으로 복제되거나 분산됩니다.

    참고 항목

    AKS 클러스터 컨트롤 플레인 구성 요소의 영역 중복성을 사용하도록 설정하려면 AKS 클러스터를 만들 때 영역이 있는 기본 시스템 노드 풀을 정의해야 합니다. 기존 비 영역 AKS 클러스터에 영역 노드 풀을 더 추가해도 AKS 클러스터 영역이 중복되지는 않습니다. 이 작업은 실제 이후 영역에 컨트롤 플레인 구성 요소를 분산하지 않기 때문입니다.

MySQL용 Azure Database 유연한 서버

  • 영역: 영역 가용성 모드는 대기 서버를 주 서버와 동일한 영역 내에서 항상 사용할 수 있음을 의미합니다. 이 옵션은 장애 조치(failover) 시간과 네트워크 대기 시간을 줄이지만 주 서버와 대기 서버 모두에 영향을 주는 단일 영역 중단으로 인해 복원력이 떨어지게 됩니다.

  • 영역 중복: 영역 중복 가용성 모드는 주 서버와 동일한 지역의 다른 영역 내에서 대기 서버를 항상 사용할 수 있음을 의미합니다. 주 서버와 대기 서버에 대한 영역 중복성에 대해 두 개의 영역이 사용하도록 설정됩니다. 복원력을 높이기 위해 이 구성을 사용하는 것이 좋습니다.

Azure 표준 Load Balancer 또는 Azure Application Gateway

표준 Load Balancer

표준 Load Balancer 리소스와 관련된 고려 사항을 이해하려면 Load Balancer 및 가용성 영역을 참조하세요.

  • 영역 중복: 영역 중복을 선택하는 것이 기존 Load Balancer로 프런트 엔드 IP를 구성하는 데 권장되는 방법입니다. 영역 중복 프런트 엔드는 여러 영역에 분산된 AKS 클러스터 백 엔드 풀에 해당합니다.

  • 영역: 노드 풀을 영역 1 및 2와 같은 특정 영역에 고정하는 경우 기존 Load Balancer에서 프런트 엔드 IP에 대해 영역 1과 2를 미리 선택할 수 있습니다. 노드 풀을 특정 영역에 고정하려는 이유는 M 시리즈와 같은 특수 VM SKU 시리즈의 가용성 때문일 수 있습니다.

Azure Application Gateway

AKS 클러스터에서 Application Gateway 수신 컨트롤러 추가 기능을 사용하는 것은 Application Gateway v2 SKU(표준 및 WAF)에서만 지원됩니다. Azure Application Gateway와 관련된 추가 고려 사항을 이해하려면 v2 및 WAF v2에 Application Gateway 크기 조정을 참조하세요.

영역: 가용성 영역의 이점을 사용하려면 영역 1, 2 및 3과 같은 여러 영역에서 Application Gateway 리소스를 만드는 것이 좋습니다. 최상의 지역 내 복원력 전략을 위해 세 영역을 모두 선택합니다. 그러나 백 엔드 노드 풀에 해당하려면 App Gateway 리소스를 만드는 동안 영역 1과 2를 미리 선택하여 노드 풀을 특정 영역에 고정할 수 있습니다. 노드 풀을 특정 영역에 고정하려는 이유는 M-series와 같은 특수 VM SKU 시리즈의 가용성 때문일 수 있습니다.

ZRS(영역 중복 스토리지)

  • AKS 클러스터는 영역 중복 리소스이므로 관리되는 ZRS 디스크로 구성하는 것이 좋습니다. 볼륨은 모든 영역에서 예약할 수 있습니다.

  • Kubernetes는 버전 1.12부터 Azure 가용성 영역을 인식합니다. 다중 영역 AKS 클러스터에서 Azure Managed Disk를 참조하는 PersistentVolumeClaim 개체를 배포할 수 있습니다. Kubernetes는 올바른 가용성 영역에서 이 PVC를 주장하는 Pod의 스케줄을 관리합니다.

  • SQL용 Azure Database의 경우 데이터 및 로그 파일이 ZRS(영역 중복 스토리지)에서 호스트되는 것이 좋습니다. 이러한 파일은 ZRS에서 사용할 수 있는 스토리지 수준 복제를 통해 대기 서버에 복제됩니다.

Azure Firewall

영역: 가용성 영역의 이점을 사용하려면 영역 1, 2 및 3과 같은 여러 영역에서 Azure Firewall 리소스를 만드는 것이 좋습니다. 최상의 지역 내 복원력 전략을 위해 세 영역을 모두 선택하는 것이 좋습니다.

Azure Bastion

영역: Azure Bastion은 VNet 또는 피어링된 VNet 내부에 배포되고 Azure 지역에 연결됩니다. 자세한 내용은 Bastion FAQ를 참조하세요.

ACR(Azure Container Registry)

영역 중복: 프리미엄 서비스 계층에서 영역 중복 레지스트리를 만드는 것이 좋습니다. 복제본에 대한 zoneRedundancy 속성을 설정하여 영역 중복 레지스트리 복제본을 만들 수도 있습니다. ACR에 대한 영역 중복을 사용하도록 설정하는 방법을 알아보려면 복원력 및 고가용성을 위해 Azure Container Registry에서 영역 중복성 사용을 참조하세요.

Azure Cache for Redis

영역 중복: Azure Cache for Redis는 프리미엄 및 엔터프라이즈 계층에서 영역 중복 구성을 지원합니다. 영역 중복 캐시는 동일한 지역에 있는 다양한 가용성 영역에 노드를 배치합니다.

Microsoft Entra ID

글로벌: Microsoft Entra ID는 여러 수준의 내부 중복도와 자동 복구 기능을 제공하는 글로벌 서비스입니다. Microsoft Entra ID는 현재 가용성 영역을 제공하는 전 세계 30개 이상의 데이터 센터에 배포됩니다. 이 숫자는 더 많은 지역이 배포됨에 따라 빠르게 증가하고 있습니다.

Azure Key Vault

지역: Azure Key Vault는 지역에 배포됩니다. 키와 비밀의 높은 내구성을 유지하기 위해 키 자격 증명 모음의 콘텐츠는 지역 내 및 동일한 지역 내의 보조 지역에 복제됩니다.

영역 중복: 가용성 영역이 있고 지역 쌍이 없는 Azure 지역의 경우 Key Vault는 ZRS(영역 중복 스토리지)를 사용하여 단일 위치/지역 내에서 키 자격 증명 모음의 콘텐츠를 세 번 복제합니다.

워크로드 고려 사항

AKS(Azure Kubernetes Service)

  • Pod는 노드 또는 Pod가 노드에 있는 가용성 영역에 관계없이 다른 Pod와 통신할 수 있습니다. Pod가 다른 가용성 영역에 있는 경우 애플리케이션의 응답 시간이 더 높을 수 있습니다. Pod 간의 추가 왕복 대기 시간은 대부분의 애플리케이션에서 허용되는 범위 내에 속할 것으로 예상되지만, 특히 Pod 간의 수다스러운 통신 패턴의 경우 짧은 대기 시간이 필요한 애플리케이션 시나리오가 있습니다.

  • 애플리케이션이 가용성 영역에서 잘 수행되도록 테스트하는 것이 좋습니다.

  • 성능상의 이유로 대기 시간이 짧기 때문에 Pod는 동일한 가용성 영역 내의 동일한 데이터 센터에 공동 배치될 수 있습니다. 동일한 가용성 영역 내의 동일한 데이터 센터에서 Pod를 공동 배치하려면 고유한 영역 및 근접 배치 그룹을 사용하여 사용자 노드 풀을 만들 수 있습니다. 새 에이전트 노드 풀을 만들고 PPG를 지정하여 기존 AKS 클러스터에 PPG(근접 배치 그룹)를 추가할 수 있습니다. Pod 토폴로지 확산 제약 조건을 사용하여 가용성 영역, 노드 및 지역의 AKS 클러스터에서 Pod가 분산되는 방식을 제어합니다.

  • 대기 시간이 짧은 통신이 필요한 Pod가 동일한 가용성 영역에 공동 배치된 후에는 Pod 간의 통신이 직접적이지 않습니다. 대신 Pod 통신은 AKS 클러스터에서 논리적 Pod 집합을 정의하는 서비스를 통해 채널화됩니다. AKS와 통신하도록 Pod를 구성할 수 있으며 서비스와의 통신은 서비스의 멤버인 모든 Pod에 자동으로 부하가 분산됩니다.

  • 가용성 영역을 활용하기 위해 노드 풀에는 영역 리소스인 기본 VM이 포함됩니다. 컴퓨팅 또는 스토리지 요구 사항이 다른 애플리케이션을 지원하려면 사용자 노드 풀을 만들 때 특정 VM 크기의 사용자 노드 풀을 만들 수 있습니다.

    예를 들어 애플리케이션의 마이크로 서비스에 높은 처리량, 짧은 대기 시간 및 높은 vCPU 수와 많은 양의 메모리를 제공하는 메모리 최적화 VM 크기가 필요하기 때문에 사용자 노드에 대해 M-series에서 Standard_M32ms를 사용하도록 결정할 수 있습니다. 배포 지역에 따라 Azure Portal에서 VM 크기를 선택하면 이 VM 크기가 영역 1 및 2에서만 지원되는 것을 볼 수 있습니다. 이 복원력 구성을 고성능을 위한 절충안으로 받아들일 수 있습니다.

  • 노드 풀을 만든 후에는 노드 풀의 VM 크기를 변경할 수 없습니다. 노드 풀 제한 사항에 대한 자세한 내용은 제한 사항을 참조하세요.

MySQL용 Azure Database 유연한 서버

영역 1 및 2와 같은 특정 영역에 노드 풀을 배포할 때의 의미는 AKS 클러스터의 모든 서비스 종속성도 영역 1과 2를 지원해야 한다는 것입니다. 이 워크로드 아키텍처에서 AKS 클러스터에는 영역 복원력이 있는 Azure Database for MySQL 유연한 서버에 대한 서비스 종속성이 있습니다. 주 서버에 대해 영역 1을 선택하고 대기 서버가 AKS 사용자 노드 풀과 공동 배치되도록 영역 2를 선택합니다.

Picture showing zone selection for MySQL Flexible Servers

Azure Cache for Redis

  • Azure Cache for Redis는 선택한 가용성 영역에 대해 라운드 로빈 방식으로 영역 중복 캐시의 노드를 배포합니다.

  • 영역 중복을 사용하도록 기존 프리미엄 캐시를 업데이트할 수 없습니다. 영역 중복을 사용하려면 Azure Cache for Redis를 다시 만들어야 합니다.

  • 최적의 복원력을 달성하려면 3개 이상의 복제본으로 Azure Cache for Redis를 만들어 3개의 가용성 영역에 복제본을 배포하는 것이 좋습니다.

Picture showing three replicas for Azure Cache for Redis

재해 복구 고려 사항

가용성 영역은 배포의 주 지역 내에서 워크로드의 고가용성을 달성하기 위한 더 나은 복원력을 위해 사용됩니다.

재해 복구는 비즈니스 연속성 계획에 정의된 복구 작업 및 사례로 구성됩니다. 비즈니스 연속성 계획은 중단 이벤트 중에 워크로드가 복구되는 방법과 이벤트 후 완전히 복구되는 방법을 모두 해결합니다. 배포를 대체 지역으로 확장하는 것이 좋습니다.

Picture showing secondary region deployment architecture

애플리케이션 계층의 경우 이 문서에서 AKS에 대한 비즈니스 연속성 및 재해 복구 고려 사항을 검토하세요.

  • 대체 지역에서 여러 AKS 클러스터를 실행하는 것이 좋습니다. 대체 지역은 보조 쌍을 이루는 지역을 사용할 수 있습니다. 또는 주 지역에 대한 지역 페어링이 없는 경우 사용 가능한 서비스, 용량, 지리적 근접성 및 데이터 주권에 대한 고려 사항에 따라 대체 지역을 선택할 수 있습니다. Azure 지역 의사 결정 가이드를 검토하세요. 배포 스탬프 패턴도 검토합니다.

  • AKS 클러스터에 대해 활성-활성, 활성-대기, 활성-수동을 구성할 수 있습니다.

  • 데이터베이스 계층의 경우 재해 복구 기능에는 지역 복원을 시작할 수 있는 지역 중복 백업 및 다른 지역에서 읽기 복제본 배포를 포함합니다.

  • 가동 중단 중에 복구를 시작할지 여부를 결정해야 합니다. 중단이 워크로드의 RTO(복구 시간 목표)보다 오래 지속될 가능성이 있는 경우에만 복구 작업을 시작해야 합니다. 그렇지 않으면 Azure Service Health 대시보드에서 서비스 상태를 확인하여 서비스 복구를 기다립니다. Azure Portal의 Service Health 블레이드에서 구독과 연결된 모든 알림을 볼 수 있습니다.

  • Azure Database for MySQL에서 지역 복원 기능을 사용하여 복구를 시작하면 다른 지역에서 복제된 백업 데이터를 사용하여 새 데이터베이스 서버가 만들어집니다.

다음 단계

자세히 알아보기:

가용성 영역을 지원하는 Azure 서비스