다음을 통해 공유


Azure Spring Apps 참조 아키텍처

비고

Azure Spring Apps는 Azure Spring Cloud 서비스의 새 이름입니다. 서비스에 새 이름이 지정되었지만, 자산을 업데이트하는 동안 스크린샷, 비디오, 다이어그램과 같은 일부 위치에서는 당분간 이전 이름이 표시됩니다.

이 문서 적용 대상: ✔️ 표준 ✔️ 엔터프라이즈

이 참조 아키텍처는 Azure Spring Apps를 사용하기 위한 일반적인 엔터프라이즈 허브 및 스포크 디자인을 사용하는 기반입니다. 디자인에서 Azure Spring Apps는 허브에서 호스트되는 공유 서비스에 종속된 단일 스포크에 배포됩니다. 아키텍처는 Microsoft Azure Well-Architected Framework 원칙을 달성하기 위해 구성 요소로 구성됩니다.

Azure Spring Apps에는 표준 플랜과 엔터프라이즈 계획의 두 가지 버전이 있습니다.

Azure Spring Apps 표준 계획은 Spring Cloud Config Server, Spring Cloud Service Registry 및 kpack 빌드 서비스로 구성됩니다.

Azure Spring Apps Enterprise 계획은 VMware Tanzu 빌드 서비스, VMware Tanzu®®용 애플리케이션 구성 서비스, VMware Tanzu 서비스 레지스트리, VMware Tanzu®®용 Spring Cloud Gateway 및 VMware Tanzu용 API 포털로 구성됩니다®.™

이 아키텍처의 구현은 GitHub에서 Azure Spring Apps 참조 아키텍처 참조하세요.

이 아키텍처에 대한 배포 옵션으로는 ARM(Azure Resource Manager), Terraform, Azure CLI 및 Bicep이 있습니다. 이 리포지토리의 아티팩트는 사용자 환경에 맞게 사용자 지정할 수 있는 기반을 제공합니다. Azure Firewall 또는 Application Gateway와 같은 리소스를 다른 리소스 그룹 또는 구독으로 그룹화할 수 있습니다. 이 그룹화는 IT 인프라, 보안, 비즈니스 애플리케이션 팀 등과 같은 다양한 기능을 별도로 유지하는 데 도움이 됩니다.

주소 공간 계획

Azure Spring Apps에는 다음 두 개의 전용 서브넷이 필요합니다.

  • 서비스 런타임
  • Spring Boot 애플리케이션

이러한 각 서브넷에는 전용 Azure Spring Apps 클러스터가 필요합니다. 여러 클러스터는 동일한 서브넷을 공유할 수 없습니다. 각 서브넷의 최소 크기는 /28입니다. Azure Spring Apps에서 지원할 수 있는 애플리케이션 인스턴스 수는 서브넷의 크기에 따라 달라집니다. 가상 네트워크에서 Azure Spring Apps 배포가상 네트워크 요구 사항 섹션에서 자세한 요구 사항을 찾을 수 있습니다.

경고

선택한 서브넷 크기는 기존 가상 네트워크 주소 공간과 겹칠 수 없으며 피어링된 서브넷 또는 온-프레미스 서브넷 주소 범위와 겹치지 않아야 합니다.

사용 사례

이 아키텍처의 일반적인 용도는 다음과 같습니다.

  • 프라이빗 애플리케이션: 하이브리드 클라우드 환경에 배포된 내부 애플리케이션
  • 외부 공개 애플리케이션: 외부 지향적인 애플리케이션

이러한 사용 사례는 보안 및 네트워크 트래픽 규칙을 제외하고 유사합니다. 이 아키텍처는 각각의 뉘앙스를 지원하도록 설계되었습니다.

프라이빗 애플리케이션

다음 목록에서는 프라이빗 애플리케이션에 대한 인프라 요구 사항을 설명합니다. 이러한 요구 사항은 높은 규제 환경에서 일반적입니다.

  • 서브넷에는 Azure Spring Apps 인스턴스가 하나만 있어야 합니다.
  • 하나 이상의 보안 벤치마크를 준수해야 합니다.
  • 애플리케이션 호스트 DNS(Domain Name Service) 레코드는 Azure 프라이빗 DNS에 저장해야 합니다.
  • Azure 서비스 종속성은 서비스 엔드포인트 또는 Private Link를 통해 통신해야 합니다.
  • 휴지 상태의 데이터를 암호화해야 합니다.
  • 전송 중인 데이터를 암호화해야 합니다.
  • DevOps 배포 파이프라인을 사용할 수 있으며(예: Azure DevOps) Azure Spring Apps에 대한 네트워크 연결이 필요합니다.
  • 아웃바운드 트래픽은 중앙 NVA(네트워크 가상 장치)(예: Azure Firewall)를 통해 이동해야 합니다.
  • Azure Spring Apps 구성 서버 리포지토리에서 구성 속성을 로드하는 데 사용되는 경우 리포지토리는 프라이빗이어야 합니다.
  • Microsoft의 제로 트러스트 보안 접근 방식을 사용하려면 비밀, 인증서 및 자격 증명을 보안 저장소에 저장해야 합니다. 권장되는 서비스는 Azure Key Vault입니다.
  • 온-프레미스 및 클라우드에서 호스트의 이름 확인은 양방향이어야 합니다.
  • 제어 평면 트래픽을 제외하고 공용 인터넷에 직접 접속이 없습니다.
  • Azure Spring Apps 배포에서 관리하는 리소스 그룹은 수정해서는 안 됩니다.
  • Azure Spring Apps 배포에서 관리하는 서브넷은 수정해서는 안 됩니다.

다음 목록에서는 디자인을 구성하는 구성 요소를 보여 줍니다.

  • 온-프레미스 네트워크
    • DNS(Domain Name Service)
    • 게이트웨이
  • 허브 구독
    • Application Gateway 서브넷
    • Azure Firewall 서브넷
    • Shared Services 서브넷
  • 연결된 구독
    • Azure Bastion 서브넷
    • 가상 네트워크 피어링

다음 목록에서는 이 참조 아키텍처의 Azure 서비스에 대해 설명합니다.

다음 다이어그램은 위의 요구 사항을 해결하는 잘 설계된 허브 및 스포크 디자인을 나타냅니다.

azure Spring Apps Standard 계획을 사용하는 프라이빗 애플리케이션에 대한 참조 아키텍처를 보여 주는 다이어그램

공용 애플리케이션

다음 목록에서는 공용 애플리케이션에 대한 인프라 요구 사항을 설명합니다. 이러한 요구 사항은 높은 규제 환경에서 일반적입니다.

  • 서브넷에는 Azure Spring Apps 인스턴스가 하나만 있어야 합니다.
  • 하나 이상의 보안 벤치마크를 준수해야 합니다.
  • 애플리케이션 호스트 DNS(Domain Name Service) 레코드는 Azure 프라이빗 DNS에 저장해야 합니다.
  • Azure DDoS Protection을 사용하도록 설정해야 합니다.
  • Azure 서비스 종속성은 서비스 엔드포인트 또는 Private Link를 통해 통신해야 합니다.
  • 휴지 상태의 데이터를 암호화해야 합니다.
  • 전송 중인 데이터를 암호화해야 합니다.
  • DevOps 배포 파이프라인을 사용할 수 있으며(예: Azure DevOps) Azure Spring Apps에 대한 네트워크 연결이 필요합니다.
  • 아웃바운드 트래픽은 중앙 NVA(네트워크 가상 장치)(예: Azure Firewall)를 통해 이동해야 합니다.
  • 수신 트래픽은 적어도 Application Gateway 또는 Azure Front Door에서 관리해야 합니다.
  • 인터넷 라우팅 가능 주소는 Azure 공용 DNS에 저장해야 합니다.
  • Microsoft의 제로 트러스트 보안 접근 방식을 사용하려면 비밀, 인증서 및 자격 증명을 보안 저장소에 저장해야 합니다. 권장되는 서비스는 Azure Key Vault입니다.
  • 온-프레미스 및 클라우드에서 호스트의 이름 확인은 양방향이어야 합니다.
  • 제어 평면 트래픽을 제외하고 공용 인터넷에 직접 접속이 없습니다.
  • Azure Spring Apps 배포에서 관리하는 리소스 그룹은 수정해서는 안 됩니다.
  • Azure Spring Apps 배포에서 관리하는 서브넷은 수정해서는 안 됩니다.

다음 목록에서는 디자인을 구성하는 구성 요소를 보여 줍니다.

  • 온-프레미스 네트워크
    • DNS(Domain Name Service)
    • 게이트웨이
  • 허브 구독
    • Application Gateway 서브넷
    • Azure Firewall 서브넷
    • Shared Services 서브넷
  • 연결된 구독
    • Azure Bastion 서브넷
    • 가상 네트워크 피어링

다음 목록에서는 이 참조 아키텍처의 Azure 서비스에 대해 설명합니다.

  • Azure Application Firewall: 일반적인 악용 및 취약성으로부터 애플리케이션을 중앙 집중식으로 보호하는 Azure Application Gateway의 기능입니다.

  • Azure Application Gateway: 계층 7에서 작동하는 TLS(전송 계층 보안) 오프로드를 사용하여 애플리케이션 트래픽을 담당하는 부하 분산 장치입니다.

  • Azure Key Vault: Microsoft ID 서비스 및 컴퓨팅 리소스와 긴밀하게 통합된 하드웨어 지원 자격 증명 관리 서비스입니다.

  • Azure Monitor: Azure 및 온-프레미스에 모두 배포되는 애플리케이션에 대한 모든 것을 포괄하는 모니터링 서비스 모음입니다.

  • Azure Pipelines: 업데이트된 Spring Boot 앱을 Azure Spring Apps에 자동으로 배포할 수 있는 완전한 기능을 갖춘 CI/CD(연속 통합/지속적인 개발) 서비스입니다.

  • Microsoft Defender for Cloud: 온-프레미스, 여러 클라우드 및 Azure의 워크로드에 대한 통합 보안 관리 및 위협 방지 시스템입니다.

  • Azure Spring Apps : Java 기반 Spring Boot 애플리케이션과 .NET 기반 Steeltoe 애플리케이션에 맞게 특별히 설계되고 최적화된 관리형 서비스입니다.

다음 다이어그램은 위의 요구 사항을 해결하는 잘 설계된 허브 및 스포크 디자인을 나타냅니다. 허브-가상 네트워크만 인터넷과 통신합니다.

Azure Spring Apps 온-프레미스 연결

Azure Spring Apps의 애플리케이션은 다양한 Azure, 온-프레미스 및 외부 리소스와 통신할 수 있습니다. 허브 및 스포크 디자인을 사용하여 애플리케이션은 Express Route 또는 사이트간 VPN(가상 사설망)을 사용하여 외부 또는 온-프레미스 네트워크로 트래픽을 라우팅할 수 있습니다.

Azure 잘 설계된 프레임워크 고려 사항

Azure Well-Architected Framework는 강력한 인프라 기반을 구축하기 위한 지침 원칙의 집합입니다. 프레임워크에는 비용 최적화, 운영 우수성, 성능 효율성, 안정성 및 보안 범주가 포함됩니다.

비용 최적화

분산 시스템 디자인의 특성으로 인해 인프라 스프롤이 현실입니다. 이 현실로 인해 예기치 않은 제어할 수 없는 비용이 발생합니다. Azure Spring Apps는 수요를 충족하고 비용을 최적화할 수 있도록 크기를 조정하는 구성 요소를 사용하여 빌드됩니다. 이 아키텍처의 핵심은 AKS(Azure Kubernetes Service)입니다. 이 서비스는 클러스터의 운영 비용 효율성을 포함하여 Kubernetes 관리의 복잡성과 운영 오버헤드를 줄이기 위해 설계되었습니다.

Azure Spring Apps의 단일 인스턴스에 다양한 애플리케이션 및 애플리케이션 유형을 배포할 수 있습니다. 이 서비스는 사용률 및 비용 효율성을 향상시킬 수 있는 메트릭 또는 일정에 의해 트리거되는 애플리케이션의 자동 크기 조정을 지원합니다.

Application Insights 및 Azure Monitor를 사용하여 운영 비용을 절감할 수도 있습니다. 포괄적인 로깅 솔루션에서 제공하는 가시성을 통해 자동화를 구현하여 시스템의 구성 요소를 실시간으로 확장할 수 있습니다. 또한 로그 데이터를 분석하여 시스템의 전반적인 비용과 성능을 개선하기 위해 해결할 수 있는 애플리케이션 코드의 비효율성을 표시할 수 있습니다.

운영 우수성

Azure Spring Apps는 운영 우수성의 여러 측면을 다룹니다. 다음 목록에 설명된 대로 이러한 측면을 결합하여 서비스가 프로덕션 환경에서 효율적으로 실행되도록 할 수 있습니다.

  • Azure Pipelines를 사용하여 사용자 오류를 방지하면서 배포가 안정적이고 일관되도록 할 수 있습니다.
  • Azure Monitor 및 Application Insights를 사용하여 로그 및 원격 분석 데이터를 저장할 수 있습니다. 수집된 로그 및 메트릭 데이터를 평가하여 애플리케이션의 상태 및 성능을 확인할 수 있습니다. APM(애플리케이션 성능 모니터링)은 Java 에이전트를 통해 서비스에 완전히 통합됩니다. 이 에이전트는 추가 코드 없이 배포된 모든 애플리케이션 및 종속성에 대한 가시성을 제공합니다. 자세한 내용은 Azure Spring Apps 애플리케이션 및 종속성을 간편하게 모니터링하기블로그 게시물을 참조하세요.
  • Microsoft Defender for Cloud를 사용하여 제공된 데이터를 분석하고 평가하는 플랫폼을 제공하여 애플리케이션이 보안을 유지하도록 할 수 있습니다.
  • 이 서비스는 다양한 배포 패턴을 지원합니다. 자세한 내용은 Azure Spring Apps에서 스테이징 환경 설정을 참조하세요.

신뢰도

Azure Spring Apps는 AKS를 기반으로 합니다. AKS는 클러스터링을 통해 복원력 수준을 제공하지만, 이 참조 아키텍처는 구성 요소 오류가 있는 경우 애플리케이션의 가용성을 높이기 위해 서비스와 아키텍처 고려 사항을 통합하여 더욱 발전합니다.

잘 정의된 허브 및 스포크 디자인을 기반으로 구축하면 이 아키텍처의 기초를 통해 여러 지역에 배포할 수 있습니다. 프라이빗 애플리케이션 사용 사례의 경우 아키텍처는 Azure 프라이빗 DNS를 사용하여 지리적 오류 발생 시 지속적인 가용성을 보장합니다. 공용 애플리케이션 사용 사례의 경우 Azure Front Door 및 Azure Application Gateway는 가용성을 보장합니다.

안전

이 아키텍처의 보안은 업계 정의 컨트롤 및 벤치마크를 준수하여 해결됩니다. 이 컨텍스트에서 "제어"는 "정보 시스템 액세스를 구현할 때 최소 권한 원칙 사용"과 같이 간결하고 잘 정의된 모범 사례를 의미합니다. IAM-05" 이 아키텍처의 컨트롤은 CSA(Cloud Security Alliance)의 CCM(클라우드 제어 매트릭스)과 CIS(Center for Internet Security)의 MAFB(Microsoft Azure Foundations Benchmark)에서 제공됩니다. 적용된 컨트롤에서 초점은 거버넌스, 네트워킹 및 애플리케이션 보안의 기본 보안 디자인 원칙에 있습니다. 대상 인프라와 관련된 ID, 액세스 관리 및 스토리지의 디자인 원칙을 처리하는 것은 사용자의 책임입니다.

거버넌스

이 아키텍처에서 해결하는 거버넌스의 주요 측면은 네트워크 리소스 격리를 통한 분리입니다. CCM에서 DCS-08은 데이터 센터에 대한 수신 및 송신 제어를 권장합니다. 컨트롤을 충족하기 위해 아키텍처는 NSG(네트워크 보안 그룹)를 사용하여 허브 및 스포크 디자인을 사용하여 리소스 간의 동서 트래픽을 필터링합니다. 또한 이 아키텍처는 허브의 중앙 서비스와 스포크 리소스 간의 트래픽을 필터링합니다. 아키텍처는 Azure Firewall 인스턴스를 사용하여 인터넷과 아키텍처 내 리소스 간의 트래픽을 관리합니다.

다음 목록에서는 이 참조의 데이터 센터 보안을 해결하는 컨트롤을 보여 줍니다.

CSA CCM 제어 ID CSA CCM 컨트롤 도메인
DCS-08 데이터 센터 보안 무단 침입자 출입

네트워크

이 아키텍처를 지원하는 네트워크 디자인은 기존 허브 및 스포크 모델에서 파생됩니다. 이 결정은 네트워크 격리가 기본 구성 요소임을 보장합니다. CCM 제어 IVS-06은 신뢰할 수 있는 환경과 신뢰할 수 없는 환경 간에 네트워크와 가상 머신 간의 트래픽을 제한하고 모니터링하는 것이 좋습니다. 이 아키텍처는 동서 트래픽에 대한 NSG("데이터 센터" 내) 및 남북 트래픽에 대한 Azure Firewall("데이터 센터" 외부)을 구현하여 제어를 채택합니다. CCM 제어 IPY-04는 인프라가 서비스 간 데이터 교환을 위해 보안 네트워크 프로토콜을 사용해야 한다고 권장합니다. 이 아키텍처를 지원하는 Azure 서비스는 모두 HTTP 및 SQL용 TLS와 같은 표준 보안 프로토콜을 사용합니다.

다음 목록에서는 이 참조에서 네트워크 보안을 처리하는 CCM 컨트롤을 보여 줍니다.

CSA CCM 제어 ID CSA CCM 컨트롤 도메인
IPY-04 네트워크 프로토콜
IVS-06 네트워크 보안

네트워크 구현은 MAFB에서 컨트롤을 정의하여 더욱 보호됩니다. 컨트롤은 환경으로의 트래픽이 공용 인터넷에서 제한되도록 합니다.

다음 목록에서는 이 참조에서 네트워크 보안을 처리하는 CIS 컨트롤을 보여 줍니다.

CIS 컨트롤 ID CIS 제어 설명
6.2 SSH 액세스가 인터넷에서 제한되는지 확인합니다.
6.3 SQL Database에서 0.0.0.0/0(모든 IP)로부터의 접근을 허용하지 않도록 확인합니다.
6.5 Network Watcher가 '사용'되었는지 확인합니다.
6.6 UDP를 사용한 수신이 인터넷에서 제한되는지 확인합니다.

Azure Spring Apps는 보안 환경에 배포될 때 관리 트래픽이 Azure를 통해 송신되어야 합니다. 가상 네트워크 Azure Spring Apps를 실행하는고객 책임에 나열된 네트워크 및 애플리케이션 규칙을 허용해야 합니다.

애플리케이션 보안

이 디자인 원칙은 ID, 데이터 보호, 키 관리 및 애플리케이션 구성의 기본 구성 요소를 다룹니다. 기본적으로 Azure Spring Apps에 배포된 애플리케이션은 작동에 필요한 최소 권한으로 실행됩니다. 권한 부여 컨트롤 집합은 서비스를 사용할 때 데이터 보호와 직접 관련이 있습니다. 키 관리는 이 계층화된 애플리케이션 보안 접근 방식을 강화합니다.

다음 목록에서는 이 참조의 키 관리를 처리하는 CCM 컨트롤을 보여 줍니다.

CSA CCM 제어 ID CSA CCM 컨트롤 도메인
EKM-01 암호화 및 키 관리 권한
EKM-02 암호화 및 키 관리 키 생성
EKM-03 암호화 및 키 관리 중요한 데이터 보호
EKM-04 암호화 및 키 관리 스토리지 및 액세스

CCM, EKM-02 및 EKM-03에서는 키를 관리하고 암호화 프로토콜을 사용하여 중요한 데이터를 보호하는 정책과 절차를 권장합니다. EKM-01은 모든 암호화 키를 관리할 수 있도록 식별 가능한 소유자가 있는 것이 좋습니다. EKM-04는 표준 알고리즘을 사용하는 것이 좋습니다.

다음 목록에서는 이 참조의 키 관리를 처리하는 CIS 컨트롤을 보여 줍니다.

CIS 컨트롤 ID CIS 제어 설명
8.1 만료 날짜가 모든 키에 설정되어 있는지 확인합니다.
8.2 만료 날짜가 모든 비밀에 설정되어 있는지 확인합니다.
8.4 키 볼트의 복구 가능성을 보장합니다.

CIS 컨트롤 8.1 및 8.2는 순환이 적용되도록 자격 증명에 대한 만료 날짜를 설정하는 것이 좋습니다. CIS 컨트롤 8.4는 비즈니스 연속성을 유지하기 위해 키 볼트의 내용을 복원할 수 있도록 합니다.

애플리케이션 보안의 측면은 이 참조 아키텍처를 사용하여 Azure에서 Spring 워크로드를 지원하기 위한 기초를 설정합니다.

다음 단계

Azure Spring Apps 참조 아키텍처 리포지토리에서 사용할 수 있는 ARM, Terraform 및 Azure CLI 배포를 통해 이 참조 아키텍처를 살펴봅니다.