비고
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 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 인스턴스가 하나만 있어야 합니다.
- 하나 이상의 보안 벤치마크를 준수해야 합니다.
- 애플리케이션 호스트 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 배포를 통해 이 참조 아키텍처를 살펴봅니다.
