다음을 통해 공유

Azure Spring Apps를 Azure Kubernetes Service로 마이그레이션

  • 아티클

참고 항목

기본, 표준 및 엔터프라이즈 계획은 2025년 3월 중순부터 사용되지 않으며 3년의 은퇴 기간이 있습니다. Azure Container Apps로 전환하는 것이 좋습니다. 자세한 내용은 Azure Spring Apps 사용 중지 공지 사항을 참조하세요.

표준 소비 및 전용 계획은 2024년 9월 30일부터 사용되지 않으며 6개월 후에 완전히 종료됩니다. Azure Container Apps로 전환하는 것이 좋습니다. 자세한 내용은 Azure Spring Apps 표준 사용량 및 전용 계획을 Azure Container Apps로 마이그레이션을 참조 하세요.

이 문서는 기본/표준 ✅ 엔터프라이즈에✅ 적용됩니다.

이 문서에서는 Azure Spring Apps에서 AKS(Azure Kubernetes Service)로 마이그레이션하는 방법에 대한 개요를 제공합니다.

Azure Spring Apps는 Spring Boot 애플리케이션용으로 특별히 설계된 PaaS(Platform-as-a-Service) 솔루션입니다. 이렇게 하면 이러한 애플리케이션을 더 쉽게 배포, 실행 및 관리할 수 있습니다. Azure Spring Apps는 인프라, 크기 조정 및 모니터링을 관리하므로 개발자는 코드에 집중할 수 있습니다.

AKS는 완전히 관리되는 Kubernetes 환경을 제공하는 IaaS(Infrastructure-as-a-Service) 제품입니다. AKS를 사용하면 애플리케이션을 배포하고 관리하는 방법을 더 자세히 제어할 수 있습니다. 다양한 컨테이너화된 애플리케이션을 지원하고 특정 요구 사항에 맞게 사용자 지정할 수 있습니다.

Azure Spring Apps에서 AKS로 애플리케이션을 마이그레이션한다는 것은 관리되는 환경에서 더 많은 유연성을 제공하는 환경으로 이동하는 것을 의미합니다. 이 프로세스를 수행하려면 AZURE Spring Apps에서와 동일한 결과를 얻기 위해 새로운 도구와 사례를 채택해야 합니다.

개념 매핑

Azure Spring Apps 및 AKS는 다양한 유형의 클라우드 서비스 제품이므로 Azure Spring Apps 개념을 AKS에 직접 매핑하는 것은 완전히 정확하지 않습니다. 또한 Azure Spring Apps는 프로덕션 환경에서 사용될 때 많은 내부 구성 요소에 따라 달라지며 여기에 나열되지 않습니다. 다음 다이어그램과 표에서는 기본 사항을 이해하는 데 도움이 되도록 Azure Spring Apps에서 AKS로 개념의 간단한 매핑을 제공합니다. 실제 프로덕션 환경에서는 보다 안전하고 신뢰할 수 있는 솔루션을 고려해야 합니다.

Azure Spring Apps와 Azure Kubernetes Service 간의 개념 매핑 다이어그램.

Azure Spring Apps 서비스 Azure Kubernetes Service
서비스 인스턴스는 앱 및 기타 리소스에 대한 경계를 호스트하고 보호하며 사용자 지정 가상 네트워크를 지원합니다. 클러스터는 배포의 기본 단위입니다. 클러스터 내에서 네임스페이스는 리소스를 구성하고 격리하는 데 사용되는 가상 세분화입니다. 클러스터의 가상 네트워크에서 정의한 것과 동일한 기본 네트워크 인프라를 공유합니다. 전용 클러스터 또는 네임스페이스가 있는 공유 클러스터 중에서 선택하는 것은 비즈니스 요구 사항에 따라 달라집니다.
앱은 서비스 인스턴스 내에서 자식 리소스로 사용되는 하나의 비즈니스 앱입니다. 비즈니스 앱 은 Azure Spring Apps의 가상 개념이며 AKS의 여러 리소스로 구성됩니다. 수신 은 서비스에 대한 외부 액세스를 제어하고 트래픽을 다른 서비스로 라우팅하기 위한 규칙을 설정합니다. 서비스는 Pod 집합에 대한 액세스를 추상화합니다. 레이블을 사용하여 다른 버전의 배포를 가리키도록 서비스를 업데이트하여 청록색 배포 스위치를 수행할 수 있습니다.
배포는 앱의 버전입니다. 앱에는 하나의 프로덕션 배포와 하나의 스테이징 배포가 있을 수 있습니다. 배포는 특정 애플리케이션 또는 서비스의 출시 및 수명 주기를 관리합니다. 또한 업데이트 및 롤백을 롤링하여 가동 중지 시간 없이 제어되고 원활한 애플리케이션 변경을 가능하게 합니다.
애플리케이션 인스턴스는 서비스에서 관리하는 최소 런타임 단위입니다. Pod는 하나 이상의 긴밀하게 결합된 컨테이너를 나타내며 실행 중인 애플리케이션 또는 워크로드의 단일 인스턴스를 호스트합니다.

네트워크 고려 사항

AKS 클러스터를 프로비전하기 전에 네트워크 설정을 신중하게 고려해야 합니다. 이러한 결정은 애플리케이션의 성능, 확장성 및 보안에 큰 영향을 줄 수 있습니다.

AKS는 CNI(Container Networking Interface) 플러그 인을 사용하여 클러스터 내에서 네트워킹을 관리합니다. 이러한 플러그 인은 Pod에 IP 주소를 할당하고, 트래픽을 라우팅하고, Kubernetes Services를 통한 통신을 사용하도록 설정하는 것과 같은 중요한 작업을 처리합니다. AKS는 다양한 네트워킹 요구 사항에 맞게 조정된 여러 CNI 플러그 인을 지원하여 클러스터 디자인의 유연성을 제공합니다.

AKS는 두 가지 기본 네트워킹 모델인 오버레이 네트워크와 플랫 네트워크를 제공합니다. 오버레이 네트워크는 AKS 노드의 Azure Virtual Network 서브넷과는 별도로 개인 IP 주소를 Pod에 할당합니다. 이 모델은 확장 가능하고 가상 네트워크 IP 주소를 절약하지만 클러스터를 떠나는 트래픽에 NAT(네트워크 주소 변환)를 사용합니다. 반면, 플랫 네트워크는 노드와 동일한 Azure Virtual Network 서브넷에서 직접 Pod IP 주소를 할당하여 외부 서비스가 NAT 없이 Pod에 액세스할 수 있도록 합니다. 플랫 네트워크는 직접 Pod 통신을 가능하게 하지만 더 광범위한 가상 네트워크 IP 주소 공간이 필요합니다.

원활한 AKS 작업에는 적절한 IP 계획이 필수적입니다. 서브넷에 모든 리소스에 충분한 IP 주소가 있는지 확인하고, 범위가 겹치지 않도록 하고, 연결 문제 및 중단을 방지하기 위해 향후 성장을 위한 공간을 남겨두는 것이 중요합니다. 자세한 내용은 Azure Kubernetes Service CNI 네트워킹 개요를 참조하세요.

AKS에서 들어오는 트래픽을 처리하려면 부하 분산 장치 또는 수신 컨트롤러를 사용할 수 있습니다. 부하 분산 장치는 계층 4에서 작동하여 프로토콜 및 포트를 기반으로 트래픽을 분산하고 수신 컨트롤러는 계층 7에서 작동하며 URL 기반 라우팅 및 TLS/SSL 종료와 같은 고급 기능을 제공합니다. 수신 컨트롤러는 단일 IP를 통해 여러 애플리케이션에 대한 트래픽을 관리하여 여러 공용 IP의 필요성을 줄입니다. 웹 애플리케이션의 경우 수신 컨트롤러는 더 나은 트래픽 관리 및 Kubernetes 리소스와의 통합을 제공하므로 선호됩니다. 자세한 내용은 애플리케이션 라우팅 추가 기능을 사용하여 관리되는 NGINX 수신을 참조하세요.

AKS에서 네트워크 트래픽을 보호하려면 트래픽 라우팅 및 TLS/SSL 종료를 관리하면서 Azure 애플리케이션 Gateway와 같은 WAF(웹 애플리케이션 방화벽)를 사용하여 사이트 간 스크립팅 및 쿠키 중독과 같은 공격으로부터 보호합니다. 또한 레이블, 네임스페이스 또는 포트를 기반으로 YAML 매니페스트에서 규칙을 정의하여 Pod 간 통신을 제어하는 네트워크 정책을 구현합니다. Linux 기반 노드에만 사용할 수 있는 이러한 정책은 클러스터 내에서 더 나은 트래픽 제어 및 보안을 보장합니다. 자세한 내용은 AKS에서 네트워크 정책을 사용하여 Pod 간 트래픽 보호를 참조하세요.

프로비전

AKS 클러스터를 프로비전하려면 Azure Portal, Azure CLI 또는 ARM 템플릿을 사용할 수 있습니다. 이 프로세스에는 일반적으로 원하는 지역을 선택하고, 노드 풀 크기 및 유형을 정의하고, 네트워크 모델(Azure CNI 또는 Kubenet)을 선택하는 작업이 포함됩니다. 사용자 액세스 제어를 위한 Microsoft Entra ID 통합과 같은 인증 옵션도 구성해야 합니다. 모니터링 및 크기 조정을 위해 Azure Monitor를 사용하도록 설정하고 리소스 사용량에 따라 자동 크기 조정을 구성할 수 있습니다. 프로비전 후 kubectl 또는 Azure CLI를 사용하여 클러스터를 관리할 수 있습니다. AKS 프로비저닝에 대한 자세한 지침은 AKS 클러스터 만들기를 참조하세요.

액세스 및 ID

AKS는 Kubernetes 클러스터에 대한 인증, 권한 부여 및 액세스 제어를 관리하는 여러 가지 방법을 제공합니다. Kubernetes RBAC(역할 기반 액세스 제어)를 사용하여 사용자, 그룹 및 서비스 계정에 필요한 리소스에만 액세스 권한을 부여할 수 있습니다. 자세한 내용은 RBAC 권한 부여 사용을 참조하세요. 또한 AKS는 보안 및 제어를 개선하기 위해 Microsoft Entra ID 및 Azure RBAC를 지원하므로 보다 간소화된 방식으로 권한을 할당하고 관리할 수 있습니다.

최상의 보안을 위해 AKS를 Microsoft Entra ID와 통합하는 것이 좋습니다. 이 통합에서는 인증에 OpenID Connect 및 OAuth 2.0 프로토콜을 사용합니다. 사용자는 AKS 클러스터와 상호 작용할 때 클러스터 관리자가 관리하는 액세스 권한으로 Microsoft Entra 자격 증명을 사용하여 인증합니다. 자세한 내용은 kubelogin을 사용하여 Kubernetes 클러스터에 대한 Azure 관리 ID 인증 사용을 참조 하세요.

Microsoft Entra 워크로드 ID OIDC(OpenID Connect) 페더레이션을 통해 Kubernetes의 네이티브 기능을 외부 ID 공급자와 통합합니다. 서비스 계정 토큰 볼륨 프로젝션을 사용하여 주석이 추가된 서비스 계정을 통해 Pod에 Kubernetes ID를 할당합니다. 이러한 토큰을 사용하여 Kubernetes 애플리케이션은 Microsoft Entra ID를 사용하여 Azure 리소스를 안전하게 인증하고 액세스할 수 있습니다. 이 설정은 Azure ID 클라이언트 라이브러리() 또는 MSAL(Azure.IdentityMicrosoft 인증 라이브러리)과 같은 라이브러리와 원활하게 작동하여 워크로드에 대한 인증을 간소화합니다. 클러스터를 설정하고 워크로드 식별을 사용하여 애플리케이션 Pod를 구성하는 방법을 알아보려면 워크로드 ID 배포 및 구성을 참조 하세요.

애플리케이션 컨테이너화

애플리케이션을 컨테이너 이미지로 컨테이너화하는 것은 AKS에서 배포하는 데 필수적입니다. 이를 통해 배포가 일관되고 이식 가능하며 확장성이 보장됩니다. 컨테이너 이미지를 사용하면 다양한 버전의 애플리케이션을 유연하게 관리할 수 있습니다. 이렇게 하면 업데이트 및 롤백이 더 쉬워지고 여러 컨테이너가 단일 호스트에서 실행되도록 하여 리소스 효율성을 향상시킵니다.

Azure Spring Apps를 사용하면 사용자가 컨테이너 이미지를 만들고 다양한 방법으로 애플리케이션을 배포할 수 있습니다. 소스 코드, JAR 또는 WAR 파일과 같은 빌드된 아티팩트 또는 컨테이너 이미지에서 직접 배포할 수 있습니다. JAR 또는 WAR 파일에서 배포하는 방법을 알아보려면 JAR 또는 WAR에서 컨테이너 이미지 빌드를 참조하세요. 소스 코드에서 배포하는 방법을 알아보려면 Paketo Buildpacks를 사용하여 애플리케이션 컨테이너화를 참조 하세요.

AKS에 배포된 애플리케이션의 성능을 모니터링하려면 컨테이너화 프로세스 중에 APM(애플리케이션 성능 모니터ing) 에이전트를 통합할 수 있습니다. 자세한 내용은 애플리케이션 성능 모니터링을 컨테이너 이미지에 통합을 참조 하세요.

애플리케이션 및 Spring Cloud 구성 요소 배포

AKS에 애플리케이션을 배포하려면 애플리케이션의 요구 사항에 따라 Azure Spring Apps 또는 StatefulSets에서 사용되는 배포를 사용할 수 있습니다. 마이크로 서비스와 같은 상태 비저장 애플리케이션의 경우 일반적으로 애플리케이션의 복제본을 관리하고 원활하게 실행되도록 하는 배포를 사용합니다. 이 형식은 Azure Spring Apps에서 사용됩니다. 반면 StatefulSets는 상태 저장이 필요한 데이터베이스 또는 서비스와 같이 영구 스토리지 또는 안정적인 ID가 필요한 애플리케이션에 적합합니다.

애플리케이션 배포와 함께 백 엔드 Pod를 노출하는 서비스를 정의해야 합니다. 서비스는 논리적 Pod 집합을 정의하고 네트워크에 액세스할 수 있도록 하는 추상화입니다. 이 기능은 Pod 간의 부하 분산 및 통신에 매우 중요합니다.

Spring Cloud 구성 요소(예: Spring Cloud Config 또는 Spring Cloud Gateway)를 배포할 때는 일반적으로 상태 비정상 서비스에 배포를 사용합니다. 안정적인 스토리지 또는 상태가 필요한 백 엔드 서비스의 경우 StatefulSets를 선택할 수 있습니다.

다음 링크는 Spring Cloud 구성 요소에 대한 컨테이너 이미지 및 매니페스트 파일의 참조 예제를 제공합니다.

Monitor

모니터링은 AKS에 배포된 애플리케이션을 관리하는 데 중요한 부분입니다. AKS는 Azure Monitor, Azure Log Analytics 및 Prometheus와 같은 통합 솔루션을 포함하여 클러스터 및 워크로드의 상태를 추적하고 분석하는 다양한 도구를 제공합니다. 자세한 내용은 다음 문서를 참조하세요.

Azure Monitor 및 Prometheus 외에도 Datadog, New Relic 또는 ELK(탄력적 스택)와 같은 다른 모니터링 솔루션을 사용할 수도 있습니다. 이러한 도구를 AKS에 통합하여 로그, 메트릭 및 추적을 수집하여 클러스터 성능에 대한 다양한 인사이트를 제공할 수 있습니다.

자습서

AKS에서 ACME Fitness 스토어 애플리케이션을 실행하는 엔드투엔드 환경을 보여 주는 자습서를 제공합니다. 자세한 내용은 acme-fitness-store/azure-kubernetes-service를 참조하세요. 이 자습서에서는 실용적인 지침을 제공하며 참조용입니다. AKS는 매우 유연하므로 특정 요구 사항에 따라 구성 및 사용자 지정을 선택해야 합니다.