Service Fabric에서 AKS로 워크로드 마이그레이션
많은 조직에서 최신 앱 개발, 유지 관리 모범 사례 및 클라우드 네이티브 아키텍처를 채택하기 위한 추진의 일환으로 컨테이너화된 앱으로 전환합니다. 기술이 계속 발전하기 때문에 조직은 퍼블릭 클라우드에서 사용할 수 있는 많은 컨테이너화된 앱 플랫폼을 평가해야 합니다.
앱에 적합한 단일 솔루션은 없지만 조직에서는 AKS(Azure Kubernetes Service) 가 많은 컨테이너화된 애플리케이션에 대한 요구 사항을 충족하는 경우가 많습니다. AKS는 애플리케이션 워크로드에 대한 핵심 서비스를 제공하기 위해 제어 평면을 관리하여 Kubernetes를 통해 애플리케이션 배포를 간소화하는 관리되는 Kubernetes 서비스입니다. 많은 조직에서는 AKS를 기본 인프라 플랫폼으로 사용하고 다른 플랫폼에서 호스트되는 워크로드를 AKS로 전환합니다.
이 문서에서는 컨테이너화된 앱을 Azure Service Fabric에서 AKS로 마이그레이션하는 방법을 설명합니다. 이 문서에서는 Service Fabric에 익숙하지만 해당 기능과 AKS의 기능 비교 방법을 알아보는 데 관심이 있다고 가정합니다. 또한 이 문서에서는 마이그레이션 중에 고려해야 할 모범 사례도 제공합니다.
AKS와 Service Fabric 비교
시작하려면 다른 Azure 컴퓨팅 서비스와 함께 Azure 컴퓨팅 서비스 선택을 검토합니다. 이 섹션에서는 마이그레이션과 관련된 주목할 만한 유사점 및 차이점을 강조 표시합니다.
Service Fabric과 AKS는 모두 컨테이너 오케스트레이터입니다. Service Fabric은 여러 프로그래밍 모델을 지원하지만 AKS는 컨테이너만 지원합니다.
프로그래밍 모델: Service Fabric은 Linux 및 Windows 컨테이너, Reliable Services, Reliable Actors, ASP.NET Core 및 게스트 실행 파일을 포함하여 서비스를 작성하고 관리하는 여러 가지 방법을 지원합니다.
AKS의 컨테이너: AKS는 컨테이너된 컨테이너 런타임 에서 실행되는 Windows 및 Linux 컨테이너를 사용하여 컨테이너화만 지원하며, 이 컨테이너는 자동으로 관리됩니다.
Service Fabric과 AKS는 모두 Azure Pipelines, Azure Monitor, Azure Key Vault 및 Microsoft Entra ID를 비롯한 다른 Azure 서비스와의 통합을 제공합니다.
주요 차이점
관리형 클러스터 대신 기존 Service Fabric 클러스터를 배포하는 경우 ARM 템플릿(Azure Resource Manager 템플릿) 또는 Bicep 모듈에서 여러 지원 리소스와 함께 클러스터 리소스를 명시적으로 정의해야 합니다. 이러한 리소스에는 각 클러스터 노드 유형, 네트워크 보안 그룹 및 부하 분산 장치에 대한 가상 머신 확장 집합이 포함됩니다. 이러한 리소스가 올바르게 구성되었는지 확인하는 것은 사용자의 책임입니다. 반면 Service Fabric 관리형 클러스터의 캡슐화 모델은 단일 관리형 클러스터 리소스로 구성됩니다. 클러스터에 대한 모든 기본 리소스는 추상화되고 Azure에서 관리됩니다.
AKS 는 운영 오버헤드를 Azure로 오프로드하여 Azure에서 관리되는 Kubernetes 클러스터의 배포를 간소화합니다. AKS는 호스트된 Kubernetes 서비스이므로 Azure는 인프라 상태 모니터링 및 유지 관리와 같은 중요한 작업을 처리합니다. Azure는 Kubernetes 마스터 노드를 관리하므로 에이전트 노드를 관리하고 유지 관리하기만 하면 됩니다.
워크로드를 Service Fabric에서 AKS로 이동하려면 컨테이너화된 애플리케이션을 자신 있게 마이그레이션할 수 있도록 기본 인프라의 차이점을 이해해야 합니다. 다음 표에서는 두 호스팅 플랫폼의 기능과 기능을 비교합니다.
| 기능 또는 구성 요소 | Service Fabric | AKS |
|---|---|---|
| 컨테이너화되지 않은 애플리케이션 | 예 | 아니요 |
| Linux 및 Windows 컨테이너 | 예 | 예 |
| Azure 관리형 컨트롤 플레인 | 예 | 예 |
| 상태 비 상태 비지정 워크로드 및 상태 저장 워크로드 모두에 대한 지원 | 예 | 예 |
| 작업자 노드 배치 | Virtual Machine Scale Sets, 고객 구성 | Virtual Machine Scale Sets, Azure 관리형 |
| 구성 매니페스트 | XML | YAML |
| Azure Monitor 통합 | 예 | 예 |
| Reliable Services 및 Reliable Actor 패턴에 대한 기본 지원 | 예 | 아니요 |
| Reliable Services에 대한 WCF 기반 통신 스택 | 예 | 아니요 |
| 영구 스토리지 | Azure Files 볼륨 드라이버 | CSI Storage 클래스, 영구 볼륨 및 영구 볼륨 클레임을 통한 관리 디스크, Azure Files 및 Azure Blob Storage와 같은 다양한 스토리지 시스템 지원 |
| 네트워킹 모드 | Azure Virtual Network 통합 | 여러 네트워크 플러그 인(Azure CNI, kubenet, BYOCNI), 네트워크 정책(Azure, Calico) 및 수신 컨트롤러(Application Gateway 수신 컨트롤러, NGINX 등)에 대한 지원 |
| 수신 컨트롤러 | Service Fabric에 기본 제공되는 역방향 프록시입니다. Service Fabric 클러스터에서 실행되는 마이크로 서비스가 HTTP 엔드포인트가 있는 다른 서비스를 검색하고 통신하는 데 도움이 됩니다. Service Fabric에서 Traefik을 사용할 수도 있습니다. | NGINX 수신 컨트롤러, Application Gateway 수신 컨트롤러와 같이 플랫폼 관리 공용 또는 내부 부하 분산 장치를 사용하는 관리형 NGINX 수신 컨트롤러, BYO 수신 오픈 소스 및 상용 컨트롤러 |
참고 항목
Service Fabric에서 Windows 컨테이너를 사용하는 경우 AKS에서 컨테이너를 사용하여 마이그레이션을 더 쉽게 수행하는 것이 좋습니다.
마이그레이션 단계
일반적으로 Service Fabric에서 AKS로의 마이그레이션 단계는 다음과 같습니다.
배포 아키텍처를 설정하고 AKS 클러스터를 만듭니다. AKS는 클러스터 액세스, 노드 및 Pod 확장성, 네트워크 액세스 및 구성 등을 구성하는 다양한 옵션을 제공합니다. 일반적인 배포 아키텍처에 대한 자세한 내용은 예제 아키텍처를 참조 하세요. AKS 기준 아키텍처는 클러스터 배포 및 모니터링 지침도 제공합니다. AKS 생성 은 비즈니스 및 기술 요구 사항에 따라 AKS 클러스터를 배포하기 위한 빠른 시작 템플릿을 제공합니다.
Service Fabric 애플리케이션을 다시 아키텍처 지정합니다. Reliable Services 또는 Reliable Actors와 같은 프로그래밍 모델을 사용하거나 다른 Service Fabric 특정 구문을 사용하는 경우 애플리케이션을 다시 보관해야 할 수 있습니다. Reliable Services에서 마이그레이션할 때 상태 관리를 구현하려면 Dapr(분산 애플리케이션 런타임)을 사용합니다. Kubernetes는 Reliable Actors에서 마이그레이션하기 위한 패턴 및 예제를 제공합니다.
애플리케이션을 컨테이너로 패키지합니다. Visual Studio는 Dockerfile을 생성하고 애플리케이션을 컨테이너로 패키지하는 옵션을 제공합니다. 만든 컨테이너 이미지를 Azure Container Registry에 푸시합니다.
Service Fabric 구성 XML 파일을 Kubernetes YAML 파일로 다시 작성합니다. YAML 파일을 사용하거나 Helm 차트를 사용하여 패키지로 애플리케이션을 AKS에 배포합니다. 자세한 내용은 애플리케이션 및 서비스 매니페스트를 참조하세요.
AKS 클러스터에 애플리케이션을 배포합니다.
배포 전략에 따라 트래픽을 AKS 클러스터로 이동하고 애플리케이션의 동작, 가용성, 성능을 모니터링합니다.
예제 아키텍처
AKS 및 Azure는 비즈니스 요구 사항에 맞게 환경을 구성할 수 있는 유연성을 제공합니다. AKS는 다른 Azure 서비스와 잘 통합되어 있습니다. AKS 기준 아키텍처가 예입니다.
시작점으로, 몇 가지 주요 Kubernetes 개념을 숙지한 다음 몇 가지 예제 아키텍처를 검토합니다.
참고 항목
Service Fabric에서 AKS로 워크로드를 마이그레이션하는 경우 Service Fabric Reliable Actors를 Dapr 행위자 구성 요소로 바꿀 수 있습니다. Service Fabric Reliable Collections를 Dapr 상태 관리 구성 요소로 바꿀 수 있습니다.
Dapr은 마이크로 서비스 연결을 간소화하는 API를 제공합니다. 자세한 내용은 Dapr 소개를 참조하세요. AKS 확장으로 Dapr을 설치하는 것이 좋습니다.
애플리케이션 및 서비스 매니페스트
Service Fabric 및 AKS에는 다양한 애플리케이션 및 서비스 매니페스트 파일 형식과 구문이 있습니다. Service Fabric은 애플리케이션 및 서비스 정의에 XML 파일을 사용합니다. AKS는 Kubernetes YAML 파일 매니페스트를 사용하여 Kubernetes 개체를 정의합니다. Service Fabric XML 파일을 Kubernetes YAML 파일로 마이그레이션하기 위한 도구는 없습니다. 그러나 다음 리소스를 검토하여 Kubernetes에서 YAML 파일이 작동하는 방식에 대해 알아볼 수 있습니다.
Kubernetes 설명서: Kubernetes 개체 이해
Windows 노드/애플리케이션에 대한 AKS 설명서: Azure CLI를 사용하여 AKS 클러스터에 Windows Server 컨테이너를 만듭니다.
Helm을 사용하여 매개 변수가 있는 YAML 매니페스트를 정의하고 정적 하드 코드된 값을 배포 시 제공되는 사용자 지정 값으로 바꿀 수 있는 자리 표시자로 바꿔 제네릭 템플릿을 만들 수 있습니다. 사용자 지정 값을 포함하는 결과 템플릿은 Kubernetes에 대한 유효한 매니페스트로 렌더링됩니다.
Kustomize 는 템플릿이 없는 방법을 도입하여 기성품 애플리케이션의 사용을 간소화하는 애플리케이션 구성을 사용자 지정합니다. Helm과 함께 또는 Helm 대신 Kustomize를 사용할 수 있습니다.
Helm 및 Kustomize에 대한 자세한 내용은 다음 리소스를 참조하세요.
네트워킹
AKS는 기본 네트워크에 대한 두 가지 옵션을 제공합니다.
사용자 고유의 Azure 가상 네트워크를 가져와서 사용자가 제공하는 가상 네트워크에서 서브넷으로 AKS 클러스터 노드를 프로비전합니다.
AKS 리소스 공급자가 클러스터에서 사용하는 모든 Azure 리소스를 포함하는 노드 리소스 그룹에서 새 Azure 가상 네트워크를 만들도록 합니다.
두 번째 옵션을 선택하면 Azure에서 가상 네트워크를 관리합니다.
Service Fabric은 네트워크 플러그 인을 선택할 수 없습니다. AKS를 사용하는 경우 다음 중 하나를 선택해야 합니다.
kubenet. kubenet을 사용하는 경우 노드는 Azure 가상 네트워크 서브넷에서 IP 주소를 가져옵니다. Pod는 노드의 Azure 가상 네트워크 서브넷과 논리적으로 다른 주소 공간에서 IP 주소를 받습니다. 그러면 Pod가 Azure 가상 네트워크의 리소스에 연결할 수 있도록 NAT(Network Address Translation)가 구성됩니다. 트래픽의 원본 IP 주소는 NAT를 통해 노드의 기본 IP 주소로 변환됩니다. 이 방법은 Pod가 사용할 네트워크 공간에서 예약해야 하는 IP 주소 수를 크게 줄입니다.
Azure CNI. CNI(컨테이너 네트워킹 인터페이스)를 사용하는 경우 모든 Pod는 서브넷에서 IP 주소를 가져오고 직접 액세스할 수 있습니다. 이러한 IP 주소는 네트워크 공간에서 고유해야 하며 미리 계획해야 합니다. 각 노드에는 지원하는 최대 Pod 수에 대한 구성 매개 변수가 있습니다. 그런 다음 각 노드에 해당하는 IP 주소 수를 예약합니다. 이 방법을 사용하려면 더 많은 계획이 필요하며, 애플리케이션 요구가 증가함에 따라 IP 주소가 고갈되거나 더 큰 서브넷에서 클러스터를 다시 빌드해야 하는 경우가 많습니다. 클러스터를 만들거나 새 노드 풀을 만들 때 노드에 배포할 수 있는 최대 Pod 수를 구성할 수 있습니다.
Azure CNI 오버레이 네트워킹. Azure CNI 오버레이를 사용하는 경우 클러스터 노드는 Azure Virtual Network 서브넷에 배포됩니다. Pod는 노드를 호스트하는 가상 네트워크의 주소와 논리적으로 다른 프라이빗 CIDR의 IP 주소가 할당됩니다. 클러스터 내의 Pod 및 노드 트래픽은 오버레이 네트워크를 사용합니다. NAT는 노드의 IP 주소를 사용하여 클러스터 외부의 리소스에 연결합니다. 이 솔루션은 상당한 수의 가상 네트워크 IP 주소를 저장하고 클러스터를 대규모로 원활하게 확장하는 데 도움이 됩니다. 또한 AKS의 컨테이너화된 애플리케이션에 사용할 수 있는 IP 공간을 확장하는 여러 AKS 클러스터에서 프라이빗 CIDR을 다시 사용할 수 있다는 장점이 있습니다.
Cilium에서 제공하는 Azure CNI. Cilium에서 제공하는 Azure CNI는 Azure CNI의 강력한 제어 평면과 Cilium의 데이터 평면을 결합하여 고성능 네트워킹 및 향상된 보안을 제공합니다.
사용자 고유의 CNI 플러그 인을 가져옵니다. Kubernetes에서는 기본적으로 네트워크 인터페이스 시스템을 제공하지 않습니다. 이 기능은 네트워크 플러그 인에서 제공됩니다. AKS는 지원되는 몇 가지 CNI 플러그 인을 제공합니다. 지원되는 플러그 인에 대한 자세한 내용은 AKS의 애플리케이션에 대한 네트워크 개념을 참조하세요.
Windows 컨테이너는 현재 Azure CNI 플러그 인만 지원합니다. 네트워크 정책 및 수신 컨트롤러에 대한 다양한 선택을 사용할 수 있습니다.
AKS에서 Kubernetes 네트워크 정책을 사용하여 서로 통신할 수 있는 구성 요소를 제어하여 서비스 내 통신을 분리하고 보호할 수 있습니다. 기본적으로 Kubernetes 클러스터의 모든 Pod는 제한 없이 트래픽을 보내고 받을 수 있습니다. 보안을 강화하기 위해 Azure 네트워크 정책 또는 Calico 네트워크 정책을 사용하여 마이크로 서비스 간의 트래픽 흐름을 제어하는 규칙을 정의할 수 있습니다.
Azure 네트워크 정책 관리자를 사용하려면 Azure CNI 플러그 인을 사용해야 합니다. Azure CNI 플러그 인 또는 kubenet CNI 플러그 인에서 Calico 네트워크 정책을 사용할 수 있습니다. Windows 노드용 Azure 네트워크 정책 관리자의 사용은 Windows Server 2022에서만 지원됩니다. 자세한 내용은 AKS에서 네트워크 정책을 사용하여 Pod 간 트래픽 보호를 참조하세요. AKS 네트워킹에 대한 자세한 내용은 AKS의 네트워킹을 참조 하세요.
Kubernetes 에서 수신 컨트롤러 는 서비스와 외부 세계 간의 서비스 프록시 및 중개자 역할을 하므로 외부 트래픽이 서비스에 액세스할 수 있습니다. 서비스 프록시는 일반적으로 TLS 종료, 경로 기반 요청 라우팅, 부하 분산 및 인증 및 권한 부여와 같은 보안 기능과 같은 다양한 기능을 제공합니다. 또한 수신 컨트롤러는 HTTP 및 HTTPS 규칙에 따라 외부 트래픽을 Kubernetes 서비스로 라우팅하기 위한 추상화 및 제어의 또 다른 계층을 제공합니다. 이 계층은 트래픽 흐름 및 트래픽 관리에 대한 보다 세분화된 제어를 제공합니다.
AKS에는 수신 컨트롤러를 배포, 실행 및 운영하는 여러 옵션이 있습니다. 한 가지 옵션은 Azure 애플리케이션 Gateway를 TLS 종료, 경로 기반 라우팅 및 웹 액세스 방화벽의 수신 컨트롤러로 사용할 수 있는 Application Gateway 수신 컨트롤러입니다. 또 다른 옵션은 널리 사용되는 NGINX 수신 컨트롤러에 대한 Azure 관리형 옵션을 제공하는 관리되는 NGINX 수신 컨트롤러입니다. Traefik 수신 컨트롤러 는 Kubernetes에 대한 또 다른 인기 있는 수신 컨트롤러입니다.
이러한 각 수신 컨트롤러에는 강점과 약점이 있습니다. 사용할 것을 결정하려면 애플리케이션 및 환경의 요구 사항을 고려합니다. 관리되지 않는 수신 컨트롤러를 설치할 때 Helm의 최신 릴리스를 사용하고 적절한 Helm 리포지토리에 액세스할 수 있어야 합니다.
영구 스토리지
Service Fabric과 AKS에는 컨테이너화된 애플리케이션에 영구 스토리지를 제공하는 메커니즘이 있습니다. Service Fabric에서 Docker 볼륨 플러그 인인 Azure Files 볼륨 드라이버는 Linux 및 Windows 컨테이너용 Azure Files 볼륨을 제공합니다. Service Fabric 클러스터에 배포하여 클러스터 내의 다른 Service Fabric 컨테이너화된 애플리케이션에 대한 볼륨을 제공할 수 있는 Service Fabric 애플리케이션으로 패키지됩니다. 자세한 내용은 Service Fabric용 Azure Files 볼륨 드라이버를 참조 하세요.
AKS에서 실행되는 애플리케이션은 영구 파일 스토리지 시스템에서 데이터를 저장하고 검색해야 할 수 있습니다. AKS는 Azure 관리 디스크, Azure Files, Blob Storage 및 ANF(Azure NetApp Storage)와 같은 Azure Storage 서비스와 통합됩니다. 또한 CSI(Container Storage Interface) 드라이버를 통해 Rook 및 GlusterFS와 같은 타사 스토리지 시스템과 통합됩니다.
CSI 는 Kubernetes의 컨테이너화된 워크로드에 블록 및 파일 스토리지 시스템을 노출하는 표준입니다. CSI를 사용하는 비 Microsoft 스토리지 공급자는 핵심 Kubernetes 코드를 변경하고 릴리스 주기를 기다리지 않고도 플러그 인을 작성, 배포 및 업데이트하여 Kubernetes에서 새 스토리지 시스템을 노출하거나 기존 스토리지 시스템을 개선할 수 있습니다.
AKS의 CSI 스토리지 드라이버 지원을 사용하면 이러한 Azure Storage 서비스를 기본적으로 사용할 수 있습니다.
Azure Disks. Azure Disks를 사용하여 Kubernetes DataDisk 리소스를 만들 수 있습니다. 디스크는 고성능 SSD에서 지원되는 Azure Premium Storage 또는 표준 HDD 또는 SSD에서 지원되는 Azure 표준 스토리지를 사용할 수 있습니다. 대부분의 프로덕션 및 개발 워크로드의 경우 Premium Storage를 사용합니다. Azure Disks는 ReadWriteOnce로 탑재되며 AKS의 한 노드에서만 사용할 수 있습니다. 여러 Pod에서 동시에 액세스할 수 있는 스토리지 볼륨에는 Azure Files를 사용합니다.
반면 Service Fabric은 선언적 접근 방식을 통해 연결된 관리 디스크를 동적으로 만드는 애플리케이션이 아니라 관리 디스크를 사용하는 클러스터 또는 노드 형식의 생성을 지원합니다. 자세한 내용은 관리되는 데이터 디스크를 사용하여 Service Fabric 클러스터 노드 유형 배포를 참조 하세요.
Azure Files. Azure Files를 사용하여 Azure Storage 계정에서 지원되는 SMB 3.0 또는 3.1 공유를 Pod에 탑재할 수 있습니다. Azure Files를 사용하면 여러 노드 및 Pod 간에 데이터를 공유할 수 있습니다. Azure Files는 표준 HDD에서 지원되는 Azure 표준 스토리지 또는 고성능 SSD에서 지원되는 Azure Premium Storage를 사용할 수 있습니다.
Service Fabric은 Docker 컨테이너용 Azure Files 볼륨을 제공하는 Docker 볼륨 플러그 인으로 Azure Files 볼륨 드라이버를 제공합니다. Service Fabric은 Windows 클러스터용 드라이버 버전 1개와 Linux 클러스터용 드라이버를 제공합니다.
Blob Storage Blob Storage를 사용하여 Blob Storage(또는 개체 스토리지)를 파일 시스템으로 컨테이너 또는 Pod에 탑재할 수 있습니다. Blob Storage를 사용하면 AKS 클러스터가 로그 파일 데이터, 이미지 또는 문서 및 HPC 워크로드와 같은 구조화되지 않은 대규모 데이터 세트를 사용하는 애플리케이션을 지원할 수 있습니다. Azure Data Lake Storage에 데이터를 수집하는 경우 다른 중간 파일 시스템을 구성하지 않고도 스토리지를 직접 탑재하고 AKS에서 사용할 수 있습니다. Service Fabric은 선언적 모드에서 Blob Storage를 탑재하는 메커니즘을 지원하지 않습니다.
스토리지 옵션에 대한 자세한 내용은 AKS의 스토리지를 참조 하세요.
애플리케이션 및 클러스터 모니터링
Service Fabric과 AKS는 모두 Azure Monitor 및 Log Analytics와 같은 해당 서비스와의 네이티브 통합을 제공합니다. 모니터링 및 진단은 모든 클라우드 환경에서 워크로드를 개발, 테스트 및 배포하는 데 중요합니다. 모니터링에는 인프라 및 애플리케이션 모니터링이 포함됩니다.
예를 들어 애플리케이션 사용 방법, Service Fabric 플랫폼에서 수행하는 작업, 성능 카운터를 통한 리소스 사용률 및 클러스터의 전반적인 상태를 추적할 수 있습니다. 이 정보를 사용하여 문제를 진단하고 수정하고 나중에 발생하지 않도록 방지할 수 있습니다. 자세한 내용은 Service Fabric에 대한 모니터링 및 진단을 참조 하세요. Service Fabric 클러스터에서 컨테이너화된 애플리케이션을 호스트하고 운영하는 경우 컨테이너 이벤트 및 로그를 보려면 컨테이너 모니터링 솔루션을 설정해야 합니다.
그러나 AKS는 클라우드에 배포된 컨테이너화된 워크로드의 성능을 모니터링하도록 설계된 Azure Monitor 및 Container Insights와 기본적으로 통합되어 있습니다. Container Insights는 메트릭 API를 통해 Kubernetes에서 사용할 수 있는 컨트롤러, 노드 및 컨테이너에서 메모리 및 프로세서 메트릭을 수집하여 성능 가시성을 제공합니다.
Kubernetes 클러스터에서 모니터링을 사용하도록 설정하면 Linux용 Log Analytics 에이전트의 컨테이너화된 버전을 통해 메트릭 및 컨테이너 로그가 자동으로 수집됩니다. 메트릭은 Azure Monitor의 메트릭 데이터베이스로 전송됩니다. 로그 데이터는 Log Analytics 작업 영역으로 전송됩니다. 이를 통해 AKS 클러스터와 그 위에서 실행되는 컨테이너화된 애플리케이션 모두에 대한 모니터링 및 원격 분석 데이터를 가져올 수 있습니다. 자세한 내용은 Azure Monitor를 사용하여 AKS 모니터링을 참조하세요.
Container Insights의 대안 또는 도우미 솔루션으로 Prometheus용 Azure Monitor 관리 서비스에서 메트릭을 수집하도록 AKS 클러스터를 구성할 수 있습니다. 이 구성을 사용하여 Prometheus 프로젝트를 기반으로 하는 Prometheus 호환 모니터링 솔루션을 사용하여 대규모로 메트릭을 수집하고 분석할 수 있습니다. 완전 관리형 서비스를 사용하면 Prometheus 쿼리 언어(PromQL)를 사용하여 모니터링되는 인프라 및 워크로드의 성능을 분석할 수 있습니다. 또한 기본 인프라를 운영할 필요 없이 경고를 받을 수 있습니다.
Prometheus용 Azure Monitor 관리형 서비스는 Azure Monitor 메트릭의 구성 요소입니다. Azure Monitor를 사용하여 수집하고 분석할 수 있는 메트릭 데이터 형식에 더 많은 유연성을 제공합니다. Prometheus 메트릭은 플랫폼 및 사용자 지정 메트릭과 일부 기능을 공유하지만 PromQL및 Grafana와 같은 오픈 소스 도구를 더 잘 지원하기 위한 추가 기능이 있습니다.
Prometheus용 Azure Monitor 관리형 서비스를 Azure 가상 머신에서 실행할 수 있는 Azure Managed Grafana 및 자체 호스팅 Grafana 모두에 대한 데이터 원본으로 구성할 수 있습니다. 자세한 내용은 관리 시스템 ID를 사용하여 Grafana의 데이터 원본으로 Prometheus용 Azure Monitor 관리 서비스 사용을 참조하세요.
AKS용 추가 기능
Service Fabric에서 AKS로 마이그레이션하는 경우 추가 기능 및 확장을 사용하는 것이 좋습니다. AKS는 추가 기능 및 Kubernetes KEDA(이벤트 기반 자동 크기 조정) 및 GitOps Flux v2와 같은 확장을 통해 클러스터에 지원되는 추가 기능을 제공합니다. 오픈 소스 프로젝트 및 타사에서 제공하는 더 많은 통합은 일반적으로 AKS와 함께 사용됩니다. AKS 지원 정책은 오픈 소스 및 타사 통합을 다루지 않습니다. 자세한 내용은 AKS와의 추가 기능, 확장 및 기타 통합을 참조하세요.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
주요 작성자:
앨리 포드 | Product Manager II
파올로 살바토리 | 수석 고객 엔지니어
브랜든 스미스 | 프로그램 관리자 II 기타 기여자:
Mick Alberts | 테크니컬 라이터
Ayobami Ayodeji | 선임 프로그램 관리자
Moumita Dey Verma | 선임 클라우드 솔루션 설계자
Francis Simy Nazareth | 선임 기술 전문가
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.