이 아키텍처에서는 활성/활성 및 고가용성 구성으로 여러 지역에서 Azure Kubernetes Service(AKS) 클러스터의 여러 인스턴스를 실행하는 방법을 자세히 설명합니다.
이 아키텍처는 Microsoft에서 AKS 인프라의 시작점으로 권장하는 AKS 기준 아키텍처를 기반으로 합니다. AKS 기준선에는 Microsoft Entra 워크로드 ID, 수신 및 송신 제한, 리소스 제한 및 기타 보안 AKS 인프라 구성과 같은 인프라 기능이 자세히 설명되어 있습니다. 이러한 인프라의 세부 정보는 이 문서에서 다루지 않습니다. 다중 지역 콘텐츠를 진행하기 전에 AKS 기준선을 숙지하는 것이 좋습니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
구성 요소
이 다중 지역 AKS 아키텍처에는 많은 구성 요소와 Azure 서비스가 사용됩니다. 이 멀티 클러스터 아키텍처의 고유성을 가진 구성 요소만 여기에 나열됩니다. 나머지는 AKS 베이스라인 아키텍처를 참조하세요.
- 지역 AKS 클러스터: 여러 AKS 클러스터가 각각 별도의 Azure 지역에 배포됩니다. 정상적으로 작동하는 동안에는 네트워크 트래픽이 모든 지역 간에 라우팅됩니다. 한 지역이 사용할 수 없게 되면 요청을 발급한 사용자와 가장 가까운 지역으로 트래픽이 라우팅됩니다.
- 지역 허브-스포크 네트워크:지역 허브-스포크 네트워크 쌍이 각 지역 AKS 인스턴스에 대해 배포됩니다. Azure Firewall Manager 정책은 모든 지역에서 방화벽 정책을 관리하는 데 사용됩니다.
- 지역 키 볼트: Azure 키 볼트는 각 지역에 프로비저닝됩니다. 키 볼트는 AKS 클러스터에 특정한 민감한 값과 키를 저장하고 해당 지역에 있는 서비스를 지원하는 데 사용됩니다.
- 멀티플 로그 작업 공간: 지역별 로그 분석 작업 공간은 지역별 네트워킹 메트릭과 진단 로그를 저장하는 데 사용됩니다. 또한 공유 Log Analytics 인스턴스는 모든 AKS 인스턴스에 대한 메트릭 및 진단 로그를 저장하는 데 사용됩니다.
- 글로벌 Azure Front Door 프로필: Azure Front Door는 각 AKS 클러스터 앞에 있는 지역 Azure Application Gateway 인스턴스로 트래픽을 로드 밸런싱하고 라우팅하는 데 사용됩니다. Azure Front Door는 이 아키텍처에 필요한 레이어 7 글로벌 라우팅을 허용합니다.
- 글로벌 컨테이너 레지스트리: 워크로드에 대한 컨테이너 이미지는 관리형 컨테이너 레지스트리에 저장됩니다. 이 아키텍처에서는 클러스터의 모든 Kubernetes 인스턴스에 단일 Azure Container Registry가 사용됩니다. Azure Container Registry에 지역 복제를 사용하면 선택한 Azure 지역에 이미지를 복제하여 지역에서 중단이 발생하더라도 이미지에 대한 지속적인 액세스를 제공할 수 있습니다.
디자인 패턴
이 아키텍처는 두 가지 클라우드 디자인 패턴을 사용합니다.
- 지오드(지리적 노드), 모든 지역에서 모든 요청을 서비스할 수 있습니다.
- 배포 스탬프 - 배포 템플릿과 같은 단일 소스에서 애플리케이션 또는 애플리케이션 구성 요소의 여러 독립적인 복사본을 배포하는 경우입니다.
지오드 패턴 고려 사항
각 AKS 클러스터를 배포할 지역을 선택할 때는 워크로드 소비자 또는 고객과 가까운 지역을 고려하세요. 또한 지역 간 복제를 활용하는 것도 고려해 보세요. 지역 간 복제는 재해 복구 보호를 위해 다른 Azure 지역에서 동일한 애플리케이션 및 데이터를 비동기적으로 복제합니다. 클러스터가 두 지역 이상으로 확장되면 각 AKS 클러스터 쌍에 대한 지역 간 복제를 계속 계획하세요.
각 지역 내에서 AKS 노드 풀의 노드는 여러 가용 영역에 분산되어 영역 장애로 인한 문제를 방지할 수 있습니다. 가용성 영역은 제한된 지역에서만 지원되며, 지역 클러스터 배치에 영향을 줍니다. 지원되는 지역 목록을 포함하여 AKS 및 가용 영역에 대한 자세한 내용은 AKS 가용 영역을 참조하세요.
배포 스탬프 고려 사항
다중 지역 AKS 솔루션을 관리하는 경우 여러 지역에 걸쳐 여러 AKS 클러스터를 배포합니다. 이러한 각 클러스터는 스탬프로 간주됩니다. 지역 장애가 발생하거나 클러스터에 더 많은 용량 또는 지역적 존재를 추가해야 하는 경우 새 스탬프 인스턴스를 만들어야 할 수 있습니다. 배포 스탬프를 만들고 관리하는 프로세스를 선택할 때 다음 사항을 고려해야 합니다.
- 일반화된 구성을 허용하는 스탬프 정의에 적합한 기술을 선택합니다. 예를 들어 인프라를 코드로 정의하는 데 Bicep을 사용할 수 있습니다.
- 변수 또는 매개변수 파일과 같은 배포 입력 메커니즘을 사용하여 인스턴스별 값을 제공합니다.
- 유연하고 반복 가능하며 독립적인 배포가 가능한 배포 도구를 선택하세요.
- 액티브/액티브 스탬프 구성에서는 각 스탬프에서 트래픽이 어떻게 분산되는지 고려하세요. 이 아키텍처는 글로벌 로드 밸런싱을 위해 Azure Front Door를 사용합니다.
- 스탬프가 컬렉션에 추가되거나 제거될 때 용량 및 비용 문제를 고려하세요.
- 스탬프 컬렉션을 하나의 단위로 파악하고 모니터링하는 방법을 고려하세요.
이러한 각 항목은 다음 섹션에서 구체적인 지침과 함께 자세히 설명합니다.
차량 관리
이 솔루션은 모든 클러스터를 통합 플릿의 일부로 처리하는 고급 오케스트레이터가 포함되지 않은 다중 클러스터 및 다중 지역 토폴로지를 나타냅니다. 클러스터 수가 증가하면 참여하는 클러스터를 보다 효율적으로 대규모로 관리하기 위해 Azure Kubernetes Fleet Manager에 멤버를 등록하는 것을 고려하세요. 여기에 제시된 인프라 아키텍처는 Fleet Manager에 등록한다고 해서 근본적으로 바뀌지는 않지만, 2일차 운영 및 유사한 활동은 여러 클러스터를 동시에 대상으로 할 수 있는 제어 평면의 이점을 누릴 수 있습니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
클러스터 배포 및 부트스트랩
지리적으로 분산된 고가용성 구성으로 여러 Kubernetes 클러스터를 배포하는 경우 각 Kubernetes 클러스터의 합계를 결합된 단위로 고려해야 합니다. 자동화된 배포 및 구성을 위한 코드 중심 전략을 개발하여 각 Kubernetes 인스턴스가 가능한 한 동일하게 유지되도록 할 수 있습니다. 다른 Kubernetes 클러스터를 추가하거나 제거하는 등 스케일 아웃 및 스케일 인 전략을 고려하세요. 설계, 배포 및 구성 계획은 가용성 영역 중단, 지역 장애 및 기타 일반적인 시나리오를 고려해야 합니다.
클러스터 정의
Azure Kubernetes Service 클러스터를 배포하는 다양한 옵션이 있습니다. Azure portal, Azure CLI 및 Azure PowerShell 모듈은 모두 개별 또는 비커플링 AKS 클러스터를 배포하는 데 적합한 옵션입니다. 그러나 이러한 방법은 긴밀하게 결합된 많은 AKS 클러스터로 작업할 때 문제가 발생할 수 있습니다. 예를 들어 Azure portal을 사용하면 누락된 단계나 사용할 수 없는 구성 옵션으로 인해 구성이 잘못될 수 있습니다. Portal을 사용하여 많은 클러스터를 배포하고 구성하는 것은 한 명 이상의 엔지니어가 집중해야 하는 시간이 많이 소요되는 프로세스입니다. Azure CLI 또는 Azure PowerShell을 사용하는 경우 명령줄 도구를 사용하여 반복 가능하고 자동화된 프로세스를 구성할 수 있습니다. 그러나 멱등성, 배포 실패 제어 및 실패 복구에 대한 책임은 사용자와 사용자가 빌드하는 스크립트에 있습니다.
여러 AKS 인스턴스로 작업하는 경우 Bicep, Azure 리소스 관리자 템플릿 또는 Terraform과 같은 인프라를 코드 솔루션으로 고려하는 것이 좋습니다. 코드 제공 인프라(Infrastructure as code)는 자동화되고 확장 가능한 멱등 배포 솔루션을 제공합니다. 예를 들어 솔루션의 공유 서비스에는 하나의 Bicep 파일을 사용하고, AKS 클러스터 및 기타 지역 서비스에는 다른 파일을 사용할 수 있습니다. 코드 제공 인프라(Infrastructure as code)를 사용하면 네트워킹, 권한 부여 및 진단과 같은 일반화된 구성으로 배포 스탬프를 정의할 수 있습니다. 배포 매개변수 파일은 지역별 값과 함께 제공될 수 있습니다. 이 구성을 사용하면 단일 템플릿을 사용하여 모든 지역에 거의 동일한 스탬프를 배포할 수 있습니다.
코드 제공 인프라(Infrastructure as code)를 개발하고 유지 관리하는 데 많은 비용이 들 수 있습니다. 경우에 따라서는 인프라를 코드로 정의하는 데 따른 오버헤드가 이점을 능가할 수 있습니다. 예를 들어 AKS 인스턴스 수가 매우 적고(예: 2개 또는 3개) 변하지 않는 경우입니다. 이러한 경우에는 명령줄 도구 또는 Azure portal을 사용한 수동 접근 방식과 같은 보다 필수적인 접근 방식을 사용하는 것이 허용됩니다.
클러스터 배포
클러스터 스탬프가 정의된 후에는 개별 또는 여러 스탬프 인스턴스를 배포할 수 있는 다양한 옵션이 있습니다. GitHub Actions 또는 Azure Pipelines와 같은 최신 연속 통합 기술을 사용하는 것이 좋습니다. 연속 통합 기반 배포 솔루션은 다음과 같은 이점이 있습니다.
- 코드를 사용하여 스탬프를 추가하고 제거할 수 있는 코드 기반 배포
- 통합 테스트 기능
- 통합 환경 및 준비 기능
- 통합 비밀 관리 솔루션
- 애플리케이션 코드와 배포 스크립트 및 템플릿 모두에 대한 소스 제어와의 통합
- 배포 기록 및 로깅
- 액세스 제어 및 감사 기능을 통해 누가 어떤 조건에서 어떤 변경을 할 수 있는지 제어할 수 있습니다.
글로벌 클러스터에서 새 스탬프가 추가되거나 제거되면 일관성을 유지하기 위해 배포 파이프라인을 업데이트해야 합니다. 한 가지 접근 방식은 각 하위 지역의 리소스를 GitHub Actions 워크플로 내에서 개별 단계로 배포하는 것입니다. 이 구성은 각 클러스터 인스턴스가 배포 파이프라인 내에 명확하게 정의되어 있기 때문에 간단합니다. 이 구성에는 배포에서 클러스터를 추가하고 제거할 때 약간의 관리 오버헤드가 발생합니다.
또 다른 옵션은 원하는 위치 목록이나 기타 표시 데이터 포인트를 기반으로 클러스터를 생성하는 비즈니스 로직을 만드는 것입니다. 예를 들어 배포 파이프라인에는 원하는 지역 목록이 포함될 수 있습니다. 그리고 파이프라인 내의 단계가 이 목록을 반복하고, 목록에 있는 각 지역에 클러스터를 배포할 수 있습니다. 이 구성의 단점은 배포 일반화가 복잡하고 각 클러스터 스탬프가 배포 파이프라인에서 명시적으로 자세히 설명되지 않는다는 점입니다. 긍정적인 이점은 파이프라인에 클러스터 스탬프를 추가 또는 제거하면 원하는 지역 목록이 간단하게 업데이트된다는 것입니다.
또한 배포 파이프라인에서 클러스터 스탬프를 제거한다고 해서 스탬프의 리소스가 항상 해제되는 것은 아닙니다. 배포 솔루션 및 구성에 따라 AKS 인스턴스 및 기타 Azure 리소스를 해제하는 추가 단계가 필요할 수 있습니다. 배포 스택을 사용하여 더 이상 필요하지 않은 경우 정리를 포함하여 Azure 리소스의 전체 수명 주기를 관리할 수 있도록 하는 것을 고려하세요.
클러스터 부트스트랩
각 Kubernetes 인스턴스 또는 스탬프가 배포된 후에는, 인그레스 컨트롤러, ID 솔루션, 워크로드 구성 요소와 같은 클러스터 구성 요소를 배포하고 구성해야 합니다. 또한 클러스터 전체에 보안, 액세스 및 거버넌스 정책을 적용하는 것도 고려해야 합니다.
배포와 마찬가지로 이러한 구성은 여러 Kubernetes 인스턴스에서 수동으로 관리하기가 어려울 수 있습니다. 따라서 이렇게 하지 말고 대규모 구성 및 정책이 가능한 다음 옵션을 사용하는 것이 좋습니다.
GitOps
이러한 구성은 소스 리포지토리로 확인되므로, Kubernetes 구성 요소를 수동으로 구성하는 대신 자동화된 방법을 사용하여 Kubernetes 클러스터에 구성을 적용하는 것이 좋습니다. 이 프로세스를 GitOps라고도 하며, Kubernetes에 많이 사용되는 GitOps 솔루션은 Flux 및 Argo CD입니다. 예를 들어, AKS용 Flux 확장 프로그램을 사용하면 클러스터가 배포된 직후 자동으로 클러스터를 부트스트랩할 수 있습니다.
GitOps는 AKS 기준 참조 아키텍처에서 자세히 설명합니다. 구성에 GitOps 기반 접근 방식을 사용하면 맞춤형 작업 없이도 각 Kubernetes 인스턴스가 유사하게 구성되도록 할 수 있습니다. 플릿의 크기가 커질수록 간소화된 구성 프로세스는 더욱 중요해집니다.
Azure Policy
여러 Kubernetes 인스턴스가 추가되면 정책 기반 거버넌스, 규정 준수 및 구성의 이점이 증가합니다. 정책, 특히 Azure Policy을 활용하면 클러스터 제어를 위한 중앙 집중식 및 확장 가능한 방법을 제공합니다. AKS 정책의 이점은 AKS 기준 참조 아키텍처에 자세히 설명되어 있습니다.
AKS 클러스터를 만들 때 Azure Policy를 사용하도록 설정해야 합니다. 규정 위반에 대한 가시성을 확보하려면 감사 모드에서 이니셔티브를 할당해야 합니다. 기본 제공 이니셔티브에 포함되지 않은 더 많은 정책을 설정할 수도 있습니다. 이러한 정책은 거부 모드로 설정됩니다. 예를 들어, 승인된 컨테이너 이미지만 클러스터에서 실행되도록 하는 정책이 마련되어 있습니다. 고유의 사용자 지정 이니셔티브를 만드는 것이 좋습니다. 워크로드에 적용 가능한 정책을 단일 할당으로 결합합니다.
정책 범위는 각 정책 및 정책 이니셔티브의 대상을 의미합니다. Bicep을 사용하여 각 AKS 클러스터가 배포되는 리소스 그룹에 정책을 할당할 수 있습니다. 전역 클러스터의 공간이 증가할수록 많은 정책이 중복됩니다. 정책의 범위를 Azure 구독 또는 Azure 관리 그룹으로 지정할 수도 있습니다. 이 방법을 사용하면 구독 범위 내의 모든 AKS 클러스터 또는 관리 그룹에 있는 모든 구독에 단일 정책 집합을 적용할 수 있습니다.
여러 AKS 클러스터에 대한 정책을 디자인할 때 다음 사항을 고려해야 합니다.
- 모든 AKS 인스턴스에 전역적으로 적용해야 하는 정책을 관리 그룹 또는 구독에 적용합니다.
- 각 지역 클러스터를 자체 리소스 그룹에 배치하면 리소스 그룹에 지역별 정책을 적용할 수 있습니다.
정책 관리 전략을 수립하는 데 도움이 되는 자료는 클라우드 도입 프레임워크 리소스 구성을 참조하세요.
워크로드 배포
AKS 인스턴스 구성 외에도 각 지역별 인스턴스 또는 스탬프에 배포되는 워크로드를 고려해야 합니다. 배포 솔루션 또는 파이프라인은 각 지역 스탬프를 수용하도록 구성해야 합니다. 글로벌 클러스터에 더 많은 스탬프가 추가되면 배포 프로세스를 확장하거나 새로운 지역 인스턴스를 수용할 수 있을 만큼 유연해야 합니다.
워크로드 배포를 계획할 때 다음 사항을 고려해야 합니다.
- 단일 배포 구성을 여러 클러스터 스탬프에 사용할 수 있도록 Helm 차트와 마찬가지로 배포를 일반화합니다.
- 모든 클러스터 스탬프에 워크로드를 배포하도록 구성된 단일 지속적인 배포 파이프라인을 사용합니다.
- 스탬프별 인스턴스 세부 정보를 배포 매개 변수로 제공합니다.
- 애플리케이션 전체를 관찰할 수 있도록 애플리케이션 진단 로깅 및 분산 추적을 구성하는 방법을 고려합니다.
고가용성 및 장애 조치(failover)
다중 지역 Kubernetes 아키텍처를 선택하는 중요한 동기는 서비스 가용성입니다. 즉, 한 지역에서 서비스 또는 서비스 구성 요소를 사용할 수 없게 되는 경우 해당 서비스의 다른 인스턴스를 계속 사용할 수 있는 지역으로 트래픽을 라우팅해야 합니다. 다중 지역 아키텍처는 실패 지점이 여러 개 있습니다. 이 섹션에서는 이러한 잠재적 실패 지점에 대해 설명합니다.
애플리케이션 포드 장애
Kubernetes Deployment 오브젝트는 포드의 여러 복제본을 관리하는 레ReplicaSet을 생성하는 데 사용됩니다. 하나의 포드를 사용할 수 없는 경우 나머지 포드 간에 트래픽이 라우팅됩니다. Kubernetes ReplicaSet은 지정된 수의 복제본을 계속 가동하려고 시도합니다. 하나의 인스턴스가 다운되면 새 인스턴스가 자동으로 생성되어야 합니다. 활동성 프로브를 사용하여 포드에서 실행 중인 애플리케이션 또는 프로세스의 상태를 확인할 수 있습니다. 서비스가 응답하지 않으면, 활동성 프로브가 포드를 제거하여 ReplicaSet이 강제로 새 인스턴스를 생성합니다.
자세한 내용은 Kubernetes ReplicaSet를 참조하세요.
데이터센터 하드웨어 장애
때때로 국지적인 장애가 발생할 수 있습니다. 예를 들어 Azure 서버의 단일 랙에 전원을 사용할 수 없게 될 수 있습니다. AKS 노드가 단일 장애 지점이 되지 않도록 보호하려면 Azure 가용성 영역을 사용하세요. 가용성 영역을 사용하면 한 가용성 영역의 AKS 노드가 다른 가용성 영역에 정의된 노드와 물리적으로 분리되도록 할 수 있습니다.
자세한 내용은 AKS 및 Azure 가용성 영역을 참조하세요.
Azure 지역 장애
전체 지역이 사용할 수 없게 되면 클러스터의 Pod가 더 이상 요청을 처리할 수 없습니다. 이 경우 Azure Front Door는 모든 트래픽을 나머지 정상 지역으로 라우팅합니다. 정상 지역의 Kubernetes 클러스터와 포드는 계속해서 요청을 처리합니다.
이 상황에서는 나머지 클러스터에 대한 요청 및 트래픽 증가를 보완할 수 있도록 주의하세요. 다음 사항을 고려합니다.
- 네트워크 및 컴퓨팅 리소스가 지역 장애 조치(failover)로 인한 급격한 트래픽 증가를 흡수할 수 있도록 적절한 크기로 조정합니다. 예를 들어, Azure CNI를 사용하는 경우 트래픽이 급증하는 동안 모든 포드 IP 주소를 지원할 수 있을 만큼 충분히 큰 서브넷이 있는지 확인하세요.
- 늘어난 지역 수요를 보정할 수 있도록 Horizontal Pod Autoscaler를 사용하여 Pod 복제본 수를 늘립니다.
- 늘어난 지역 수요를 보정할 수 있도록 AKS Cluster Autoscaler를 사용하여 Kubernetes 인스턴스 노드 수를 늘립니다.
자세한 내용은 Horizontal Pod Autoscaler 및 AKS Cluster Autoscaler를 참조하세요.
네트워크 토폴로지
AKS 기준 참조 아키텍처와 마찬가지로, 이 아키텍처는 허브 스포크 네트워크 토폴로지를 사용합니다. AKS 기준 참조 아키텍처에 나와 있는 고려 사항 외에도 다음 모범 사례를 고려해야 합니다.
- 각 지역 AKS 인스턴스에 대해 허브-스포크 가상 네트워크 세트를 구현합니다. 각 지역 내에서 피어는 각각 허브 가상 네트워크에 연결됩니다.
- 각 지역 허브 네트워크에 있는 Azure Firewall 인스턴스를 통해 모든 아웃바운드 트래픽을 라우팅합니다. Azure Firewall Manager 정책을 활용하여 모든 지역의 방화벽 정책을 관리합니다.
- AKS 기준 참조 아키텍처에 나와 있는 IP 크기 조정을 따르고, 다른 지역에서 지역 장애가 발생하여 나머지 지역으로의 트래픽이 크게 증가할 경우를 대비하여 노드 및 포드 스케일 운영에 더 많은 IP 주소를 허용하세요.
트래픽 관리
AKS 기준 참조 아키텍처를 사용하면 워크로드 트래픽이 Azure Application Gateway 인스턴스로 직접 라우팅된 다음 백엔드 부하 분산 장치 및 AKS 인그레스 리소스로 전달됩니다. 여러 클러스터로 작업하는 경우에는 클라이언트 요청이 Azure Front Door 인스턴스를 통해 라우팅되고, 다시 Azure Application Gateway 인스턴스로 라우팅됩니다.
이 다이어그램의 Visio 파일을 다운로드합니다.
사용자가 도메인 이름(예:
https://contoso-web-a1bc2de3fh4ij5kl.z01.azurefd.net)으로 요청을 보내면, 이 요청은 Azure Front Door 프로필로 확인됩니다. 이 요청은 Azure Front Door의 모든 하위 도메인에 대해 발급된 와일드카드 인증서(*.azurefd.net)로 암호화됩니다. Azure Front Door는 웹 애플리케이션 방화벽 정책에 대해 요청의 유효성을 검사하고, 상태 및 대기 시간에 따라 가장 빠른 원본을 선택하고, 공용 DNS를 사용하여 원본 IP 주소(Azure Application Gateway 인스턴스)를 확인합니다.Azure Front Door는 지역 스탬프의 진입점 역할을 하는 선택한 적절한 Application Gateway 인스턴스로 요청을 전달합니다. 트래픽은 인터넷을 통해 흐릅니다. Azure Front Door는 원본으로 향하는 트래픽이 암호화되도록 보장합니다.
Application Gateway 인스턴스가 Front Door 인스턴스의 트래픽만 허용하는 방법을 사용하는 것이 좋습니다. 한 가지 방법은 서브넷에서 Application Gateway를 포함하는 네트워크 보안 그룹을 사용하는 것입니다. 규칙은 원본, 포트, 대상과 같은 속성에 따라 인바운드(또는 아웃바운드) 트래픽을 필터링할 수 있습니다. 원본 속성을 통해 Azure 리소스의 IP 주소를 나타내는 기본 제공 서비스 태그를 설정할 수 있습니다. 이 추상화는 규칙을 쉽게 구성 및 유지 관리하고 IP 주소를 추적할 수 있게 합니다. 또한 요청을 원본으로 보내기 전에 Azure Front Door가 요청에 추가하는
X-Azure-FDID헤더를 활용하여 Application Gateway 인스턴스가 Front Door 인스턴스의 트래픽만 수락하도록 하는 것도 고려해 보세요. Front Door 헤더에 대한 자세한 내용은 Azure Front Door의 HTTP 헤더에 대한 프로토콜 지원을 참조하세요.
공유 리소스 고려 사항
이 참조 아키텍처는 여러 Azure 지역에 여러 Kubernetes 인스턴스를 분산하는 데 중점을 두고 있지만, 모든 인스턴스에서 공유 리소스를 사용하는 것도 좋습니다. 한 가지 방법은 단일 Bicep 파일을 사용하여 모든 공유 리소스를 배포한 다음 각 지역 스탬프를 배포하는 것입니다. 이 섹션에서는 여러 AKS 인스턴스에서 각 공유 리소스를 사용하기 위한 각 공유 리소스 및 고려 사항에 대해 자세히 설명합니다.
Container Registry
Azure Container Registry는 이 아키텍처에서 컨테이너 이미지 서비스를 제공하는 데 사용됩니다. 클러스터는 레지스트리에서 컨테이너 이미지를 가져옵니다. 다중 지역 클러스터 배포에 Azure Container Registry를 사용할 때에는 다음 사항을 고려해야 합니다.
지리적 가용성
AKS 클러스터가 배포되는 각 지역에 컨테이너 레지스트리를 배치합니다. 이 접근 방식을 사용하면 지연 시간이 짧은 네트워크 운영을 통해 빠르고 안정적인 이미지 레이어 전송이 가능합니다. 또한 지역 서비스를 사용할 수 없을 때 가용성을 제공하기 위해 여러 이미지 서비스 엔드포인트가 있다는 의미이기도 합니다. Azure 컨테이너 레지스트리의 지역 복제 기능을 사용하면 여러 지역에 자동으로 복제되는 하나의 컨테이너 레지스트리를 관리할 수 있습니다.
클러스터가 포함된 각 Azure 지역에 복제본을 사용하여 단일 레지스트리를 만드는 것을 고려해 보세요. Azure Container Registry 복제에 대한 자세한 내용은 Azure Container Registry의 지역 복제를 참조하세요.
Azure portal 내에서 여러 개의 Azure 컨테이너 레지스트리 복제본을 보여주는 이미지.
클러스터 액세스
각 AKS 클러스터는 컨테이너 이미지 레이어를 가져올 수 있도록 컨테이너 레지스트리에 액세스해야 합니다. Azure 컨테이너 레지스트리에 대한 액세스를 설정하는 방법에는 여러 가지가 있습니다. 이 아키텍처에서는 각 클러스터에 대해 관리 ID가 생성된 다음 컨테이너 레지스트리에서 AcrPull 역할이 부여됩니다. Azure 컨테이너 레지스트리 액세스를 위한 관리 ID 사용에 대한 자세한 정보 및 권장 사항은 AKS 기준 참조 아키텍처를 참조하세요.
이 구성은 클러스터 스탬프 Bicep 파일에 정의되어 있으므로 새 스탬프가 배포될 때마다 새 AKS 인스턴스에 액세스 권한이 부여됩니다. 컨테이너 레지스트리는 공유 리소스이므로 배포에 컨테이너 레지스트리의 리소스 ID를 파라미터로 포함해야 합니다.
Azure Monitor
Azure Monitor 컨테이너 인사이트 기능은 클러스터 및 컨테이너 워크로드의 성능 및 상태를 모니터링하고 이해하는 데 권장되는 도구입니다. 컨테이너 인사이트는 로그 데이터를 저장하기 위한 로그 분석 작업 공간과 숫자 시계열 데이터를 저장하기 위한 Azure Monitor 메트릭를 모두 활용합니다. Prometheus 메트릭은 Container Insights에서도 수집할 수 있으며, 데이터는 Azure Monitor 관리형 서비스 for Prometheus 또는 Azure Monitor Logs로 전송할 수 있습니다. 자세한 내용은 AKS 기준 참조 아키텍처를 참조하세요.
또한 AKS 클러스터 진단 설정을 구성하여 AKS 컨트롤 플레인 구성 요소에서 리소스 로그를 수집 및 분석하여 로그 분석 작업 공간으로 전달할 수도 있습니다.
다중 지역 아키텍처를 위한 모니터링 솔루션을 설계할 때는 각 스탬프 간의 결합을 고려하는 것이 중요합니다. 각 Kubernetes 클러스터에서 공유하는 단일 Log Analytics 작업 공간을 배포할 수 있습니다. 다른 공유 리소스와 마찬가지로, 전 세계적으로 공유되는 단일 Log Analytics 작업 공간에 대한 정보를 사용하도록 지역 스탬프를 정의하고 각 지역 클러스터를 해당 공유 작업 공간에 연결합니다. 각 지역 클러스터가 진단 로그를 단일 Log Analytics 작업 공간으로 전송하면 리소스 메트릭과 함께 데이터를 사용하여 전체 다중 지역 솔루션의 실행 방식을 이해하는 데 도움이 되는 보고서와 대시보드를 보다 쉽게 작성할 수 있습니다.
Azure Front Door
Azure Front Door는 각 AKS 클러스터로 트래픽을 로드 밸런싱하고 라우팅하는 데 사용됩니다. Azure Front Door는 레이어 7 글로벌 라우팅도 지원합니다. 이 시나리오에는 이러한 기능이 필요합니다.
클러스터 구성
각 지역 AKS 인스턴스가 추가될 때마다 Kubernetes 클러스터와 함께 배포된 애플리케이션 게이트웨이를 Azure Front Door에 오리진으로 등록하여 라우팅에 사용할 수 있도록 해야 합니다. 이 작업을 수행하려면 코드 제공 인프라(Infrastructure as code) 자산을 업데이트해야 합니다. 또는 이 작업을 배포 구성에서 분리하여 Azure CLI와 같은 도구를 사용하여 관리할 수도 있습니다.
인증서
Azure Front Door는 개발 또는 테스트 환경에서도 자체 서명된 인증서를 사용하는 원본을 지원하지 않습니다. HTTPS 트래픽을 사용하려면 CA(인증 기관)에서 서명한 TLS/SSL 인증서를 만들어야 합니다. Front Door가 지원하는 다른 CA에 대한 자세한 내용은 Azure Front Door에서 사용자 지정 HTTPS를 사용하도록 설정하는 데 허용되는 인증 기관을 참조하세요.
테스트용 또는 비프로덕션 클러스터의 경우, Certbot를 사용하여 각 애플리케이션 게이트웨이에 대해 Let's Encrypt Authority X3 인증서를 만드는 것을 고려할 수 있습니다.
프로덕션 클러스터를 계획할 때에는 조직에서 선호하는 TLS 인증서 조달 방법을 사용합니다.
클러스터 액세스 및 ID
AKS 기본 참조 아키텍처에서 설명한 대로 클러스터의 ID 공급자로 Microsoft Entra ID를 사용하는 것이 좋습니다. 그런 다음 Microsoft Entra 그룹을 사용하여 클러스터 리소스에 대한 액세스를 제어할 수 있습니다.
여러 클러스터를 관리할 때는 액세스 스키마를 결정해야 합니다. 다음 옵션을 사용할 수 있습니다.
- 구성원이 클러스터의 모든 Kubernetes 인스턴스에서 모든 개체에 액세스할 수 있는 전역 클러스터 수준 액세스 그룹을 만듭니다. 이 옵션은 관리 부담이 최소화되지만 모든 그룹 구성원에게 상당한 권한을 부여합니다.
- Kubernetes 인스턴스마다 개별 클러스터 인스턴스의 개체에 대한 액세스 권한을 부여하는 데 사용되는 개별 액세스 그룹을 만듭니다. 이 옵션을 사용하면 관리 오버헤드가 증가하지만 보다 세밀한 클러스터 액세스가 제공됩니다.
- Kubernetes 개체 유형 및 네임스페이스에 대한 세분화된 액세스 제어를 정의하고 결과를 Microsoft Entra 그룹 구조와 상호 연관시키세요. 이 옵션을 사용하면 관리 오버헤드가 크게 증가하지만, 각 클러스터뿐만 아니라 각 클러스터 내에 있는 네임스페이스와 Kubernetes API에 대한 세분화된 액세스를 제공합니다.
관리 액세스 권한의 경우 각 지역에 대해 Microsoft Entra 그룹을 만드는 것이 좋습니다. 각 그룹에 해당 지역의 해당 클러스터 스탬프에 대한 전체 액세스 권한을 부여합니다. 그러면 각 그룹의 구성원은 해당 클러스터에 대한 관리 액세스 권한을 갖게 됩니다.
Microsoft Entra ID로 AKS 클러스터 액세스를 관리하는 방법에 대한 자세한 내용은 AKS Microsoft Entra 통합을 참조하세요.
데이터, 상태 및 캐시
전 세계에 분산된 AKS 클러스터 집합을 사용할 때는 클러스터에서 실행될 수 있는 애플리케이션, 프로세스 또는 기타 워크로드의 아키텍처를 고려하세요. 상태 기반 워크로드가 클러스터에 분산되어 있는 경우 상태 저장소에 액세스해야 하나요? 장애로 인해 클러스터의 다른 곳에서 프로세스가 다시 생성되는 경우 워크로드 또는 프로세스가 종속 상태 저장소 또는 캐싱 솔루션에 계속 액세스할 수 있나요? 상태는 여러 가지 방법으로 저장할 수 있지만, 단일 Kubernetes 클러스터에서도 관리하기가 복잡합니다. 여러 개의 Kubernetes 클러스터를 추가하면 복잡성이 증가합니다. 지역별 액세스 및 복잡성 문제로 인해 전 세계적으로 분산된 상태 저장소 서비스를 사용하도록 애플리케이션을 설계하는 것이 좋습니다.
이 아키텍처의 설계에는 상태 문제에 대한 구성이 포함되어 있지 않습니다. 여러 AKS 클러스터에서 단일 논리적 애플리케이션을 실행하는 경우, Azure Cosmos DB와 같은 전역에 분산된 데이터 서비스를 사용하도록 워크로드를 설계하는 것을 고려하세요. Azure Cosmos DB는 전 세계에 분산된 데이터베이스 시스템으로, 데이터베이스의 로컬 복제본에서 데이터를 읽고 쓸 수 있으며, Cosmos DB 서비스가 지리적 복제를 관리합니다. 자세한 내용은 Azure Cosmos DB를 참조하세요.
워크로드에서 캐싱 솔루션을 사용하는 경우, 장애 조치 이벤트 중에도 캐싱 서비스가 계속 작동하도록 설계해야 합니다. 워크로드 자체가 캐시 관련 장애 조치에 대해 복원력이 있는지, 그리고 캐싱 솔루션이 모든 지역 AKS 인스턴스에 있는지 확인합니다.
비용 최적화
Azure 가격 계산기를 사용하여 아키텍처에 사용되는 서비스 비용을 예측합니다. 다른 모범 사례는 Microsoft Azure 잘 설계된 프레임워크의 비용 최적화 섹션에, 구체적인 비용 최적화 구성 옵션은 비용 최적화 문서에 설명되어 있습니다.
Kubernetes별 구성에 따른 세분화된 클러스터 인프라 비용 할당을 위해 AKS 비용 분석을 활성화하는 것을 고려하세요.