여러 지역에 Azure Spring Apps 배포

Azure Application Gateway
Azure Front Door
Azure Key Vault
Azure Spring Apps

이 참조 아키텍처는 활성-활성 구성에서 지역 간에 여러 Azure Spring Apps 인스턴스를 실행하는 방법을 설명합니다.

이 디자인은 Azure Spring Apps 기준 아키텍처기반으로 합니다. 기준은 단일 지역 내의 여러 가용성 영역에 Java Spring Boot 애플리케이션을 배포합니다 . 여러 영역은 애플리케이션 워크로드를 별도의 위치에 분산하여 워크로드가 Azure 지역 내에서 로컬 오류를 허용할 수 있도록 합니다.

그러나 전체 지역에서 중단이 발생하면 사용자가 기준을 사용할 수 없게 됩니다. 이 설계의 목적은 지역 가동 중단을 견딜 수 있는 고가용성을 구축하는 것입니다.

이 아키텍처는 다음 목표를 충족하는 데 유용합니다.

  • 애플리케이션의 전반적인 복원력 및 SLO(서비스 수준 목표)를 늘입니다.
  • 애플리케이션에 대한 전역 도달 범위를 사용하도록 설정합니다.
  • 워크로드를 최종 사용자에게 더 가깝게 만들고 대기 시간을 최대한 낮게 만듭니다.
  • 보조 지역을 주 지역의 장애 조치(failover) 사이트로 사용하고 활성-수동 디자인을 선택합니다.

애플리케이션 복원력 및 안정성을 높이기 위해 애플리케이션을 여러 지역에 배포할 수 있습니다. 이 디자인의 경우 지역 간에 애플리케이션에 대한 요청 부하를 분산하는 전역 라우터가 필요합니다. 이 아키텍처의 전역 라우터는 다른 목표도 해결합니다.

다중 지역 설정의 가장 큰 과제는 여러 지역 간에 애플리케이션에 대한 데이터를 복제본(replica) 것입니다. 이 문제는 다중 영역 설정과 관련이 없습니다. Azure 가용성 영역은 왕복 대기 시간이 2ms 미만인 고성능 네트워크에 의해 연결됩니다. 이 대기 시간 기간은 대부분의 애플리케이션에 충분합니다.

GitHub logo아키텍처는 몇 가지 디자인 선택을 보여 주는 GitHub의 예제 구현을 통해 지원됩니다. 다중 지역 배포, 자동화 및 트래픽 라우팅의 문제를 해결하기 위한 구현을 고려합니다.

아키텍처

다음 다이어그램에서는 이 방법의 아키텍처를 보여 줍니다.

Diagram that shows a multi-region Azure Spring Apps reference architecture.

구성 요소

이 아키텍처의 구성 요소는 기준 아키텍처동일합니다. 다음 목록에서는 기준 아키텍처의 변경 내용만 강조 표시합니다. Azure 서비스에 대한 제품 설명서는 관련 리소스 섹션을 참조하세요 .

  • Azure Front Door 는 전역 부하 분산 장치 역할을 합니다. 이 서비스는 대기 시간이 짧고 규모가 크고 에지에서 캐싱을 통해 더 높은 가용성을 제공하는 기능 때문에 사용됩니다.

워크플로

참조 아키텍처는 다음 워크플로를 구현합니다.

  1. 사용자는 애플리케이션의 HTTP 호스트 이름(예: www.contoso.com)에 요청을 보냅니다. Azure DNS는 이 호스트 이름에 대한 요청을 Azure Front Door로 확인합니다.

  2. Azure Front Door는 다양한 부하 분산 구성을 사용하여 들어오는 요청을 각 지역의 Azure 애플리케이션 Gateway의 퍼블릭 엔드포인트로 전달합니다. Application Gateway 인스턴스는 Azure Front Door와 동일한 사용자 지정 do기본 이름 및 TLS 인증서 이름으로 구성됩니다.

  3. 통합 Azure 웹 애플리케이션 방화벽이 있는 Application Gateway는 요청을 검사합니다. 웹 애플리케이션 방화벽은 지정된 Azure Front Door 프로필에서 들어오는 요청만 허용합니다.

  4. Application Gateway는 프로비전된 Spring Apps 인스턴스에서 허용된 트래픽을 부하 분산 장치의 IP 주소로 전달합니다.

  5. 내부 부하 분산 장치는 Application Gateway의 트래픽만 백 엔드 서비스로 라우팅합니다. 이러한 서비스는 각 지역의 가상 네트워크 내 Spring Apps 인스턴스에서 호스트됩니다.

  6. 요청 처리의 일환으로 애플리케이션은 가상 네트워크 내의 다른 Azure 서비스와 통신합니다. 예를 들어 비밀을 위해 Azure Key Vault와 통신하는 애플리케이션과 상태를 저장하기 위한 데이터베이스가 있습니다.

글로벌 분포

고가용성을 위해 디자인하는 경우 이 아키텍처를 활성-활성, 활성-수동 활성 대기 모드 또는 콜드 대기 모드의 활성-수동으로 설정할 수 있습니다.

사용자의 선택은 애플리케이션의 가용성 요구 사항에 따라 달라집니다. 이 아키텍처는 샘플 조직에서 가동 시간이 긴 SLA(서비스 수준 계약)가 있는 전역 상태를 갖기를 원하기 때문에 두 지역에서 활성-활성 배포를 사용합니다. 중요 업무용 애플리케이션을 실행하고 고가용성을 원하는 경우 두 개 이상의 지역을 사용해야 합니다.

참고 항목

다중 지역 배포는 전체 설정이 보조 지역에 중복되므로 워크로드 비용을 두 배로 곱합니다.

활성-활성

활성-활성 모드에서 모든 지역은 요청을 동시에 처리합니다. 활성-활성 모드의 가장 큰 과제는 지역 간의 데이터 동기화를 유지하는 것입니다. 이 모드는 거의 모든 구성 요소에 대해 두 번 지불하기 때문에 비용이 많이 드는 방법입니다.

활성-수동-활성 대기

활성-수동 모드에서 활성 대기 상태인 경우 보조 지역은 주 지역이 활성 상태인 한 Azure Front Door에서 요청을 수신하지 않습니다. 주 지역에서 보조 지역으로 애플리케이션 데이터를 복제본(replica) 확인합니다. 주 지역에서 오류가 발생하는 경우 백 엔드 데이터베이스의 역할을 변경하고 Azure Front Door를 통해 모든 트래픽을 보조 지역으로 장애 조치해야 합니다.

활성-수동 모드에서는 장애 조치(failover)가 다소 시간이 걸릴 것으로 예상되므로 모든 데이터가 다시 동기화되도록 보다 쉽게 기본. 그러나 활성-활성-활성 모드를 사용하는 활성-수동 모드는 활성-활성 모드로 작업하는 것만큼 비용이 많이 듭니다.

콜드 대기를 사용하여 활성-수동

콜드 대기 상태의 활성-수동 모드에서 주 지역에는 모든 리소스가 있으며 트래픽을 제공합니다. 보조 지역에는 컴퓨팅 리소스가 낮은 구성 요소 또는 구성 요소가 적을 수 있습니다. 기술 선택은 비즈니스 요구 사항에 따라 허용되는 가동 중지 시간에 따라 달라집니다. 보조 지역 설정 범위도 비용에 영향을 줍니다. 적어도 애플리케이션 데이터가 보조 지역에 있는지 확인합니다.

멘션 활성-수동 모드에는 약간의 시간이 걸리는 장애 조치(failover)가 포함되므로 모든 데이터를 동기화 상태로 유지하는 것이 더 쉽습니다. 콜드 대기를 사용하는 활성-수동 모드는 모든 리소스를 두 지역에 배포하지 않기 때문에 가장 비용 효율적인 방법입니다.

전체 솔루션 설정에서 템플릿을 사용하는 경우 필요에 따라 리소스를 만들어 콜드 대기 보조 지역을 쉽게 배포할 수 있습니다. Terraform, Bicep 또는 ARM(Azure Resource Manager) 템플릿을 사용하고 CI/CD(연속 통합/지속적인 배포) 파이프라인에서 인프라 설정을 자동화할 수 있습니다. 보조 지역을 다시 만들어 구성을 정기적으로 테스트하여 비상 시 템플릿을 배포할 수 있는지 확인해야 합니다.

애플리케이션 또는 구성 요소의 여러 독립 복사본을 단일 템플릿에서 여러 지역으로 배포할 수 있으므로 배포 스탬프 패턴을 사용하는 것이 좋습니다.

Important

중요 업무용 워크로드의 경우 영역 중복성과 지역 중복성을 결합하여 여러 Azure 지역에 배포된 영역 중복 서비스와 함께 최대 안정성과 가용성을 달성하는 것이 좋습니다. 자세한 내용은 중요 업무용 디자인 방법론의 전역 배포 섹션 및 중요 업무용 기준 아키텍처를 참조하세요.

모드 비교

다음 표에서는 각 모드의 데이터를 동기화하는 데 필요한 노력을 요약하고 비용을 비교합니다.

모드 동기화 작업 비용
활성-활성 지역 간 데이터 동기화를 기본 중요 비용이 많이 드는 경우 거의 모든 구성 요소에 대해 두 번 지불
활성-수동-활성 대기 더 쉬울수록 장애 조치(failover)에 다소 시간이 소요됩니다. 활성-활성 모드와 동일한 비용이 많이 듭니다.
콜드 대기를 사용하여 활성-수동 활성-수동 모드와 동일하게 핫 대기 모드로 더 쉽고 비용 효율적, 모든 리소스를 두 지역에 배포하지 마세요.

지역 간 라우팅

이 참조 아키텍처는 모든 지역에서 모든 요청을 처리할 수 있는 지리적 노드(Geodes)를 사용합니다.

Azure Front Door는 두 배포 지역 간에 동일한 라우팅으로 구성됩니다. Azure Front Door는 원본에 대한 다른 트래픽 라우팅 방법도 제공합니다. 클라이언트를 가장 가까운 원본으로 라우팅하려는 경우에는 대기 시간 기반 라우팅이 가장 합리적입니다. 활성-수동 솔루션을 디자인하는 경우 우선 순위 기반 라우팅이 더 적합합니다.

참조 아키텍처 예제에서는 두 지역 간에 동일한 가중치 부하 분산 규칙을 사용합니다. Azure Front Door는 다음을 사용하여 구성됩니다.

  • 사용자 지정 do기본 및 TLS(전송 계층 보안) 인증서(예: www.contoso.com애플리케이션 호스트 이름과 동일한 이름)입니다.

  • 애플리케이션이 배포되는 지역당 하나의 원본이며, 각 원본은 Azure 애플리케이션 게이트웨이 인스턴스입니다.

리소스 그룹 레이아웃

Azure 리소스 그룹을 사용하여 각 지역에 배포된 리소스를 단일 컬렉션으로 관리합니다. 다음 다이어그램과 같이 주 지역, 보조 지역 및 Azure Front Door를 별도의 리소스 그룹에 배치하는 것이 좋습니다.

Diagram that shows regions deployed in separate resource groups.

다이어그램은 리소스 그룹의 다음 구성을 보여줍니다.

  • Azure Front Door는 Application-shared 리소스 그룹에 배포됩니다.
  • 서유럽 지역(weu)에서 호스트되는 Application-weu 모든 리소스는 리소스 그룹에 배포됩니다.
  • 미국 동부 지역(eus)에서 호스트되는 리소스는 리소스 그룹에서 호스트 Application-eus 됩니다.
  • 일본 동부 지역(jae)에서 호스트되는 리소스는 리소스 그룹에서 호스트 Application-jae 됩니다.

동일한 리소스 그룹의 리소스는 동일한 수명 주기를 공유하며 함께 쉽게 만들고 삭제할 수 있습니다. 각 지역에는 지역 이름에 따라 명명 규칙을 따르는 전용 리소스 그룹에 자체 리소스 집합이 있습니다. Azure Front Door는 다른 지역이 추가되거나 제거된 경우에도 존재해야 하므로 자체 리소스 그룹에 있습니다.

역방향 프록시 설정

Azure Front Door는 지역 간에 전역 부하 분산을 수행합니다. 이 역방향 프록시는 워크로드를 여러 지역에 배포할 때 트래픽을 분산하는 데 도움이 됩니다. Azure Traffic Manager를 대안으로 사용할 수도 있습니다. Traffic Manager는 도메인 수준에서만 부하를 분산하는 DNS 기반 트래픽 부하 분산 장치입니다.

Azure Front Door에는 전 세계에 배포된 POP(지점)를 사용하여 Microsoft의 글로벌 에지 네트워크에서 콘텐츠를 제공하는 CDN(통합 콘텐츠 배달 네트워크)이 있습니다.

현재 솔루션은 두 개의 역방향 프록시를 사용하여 기준 아키텍처와의 일관성을 기본. Azure Front Door는 글로벌 라우터입니다. Application Gateway는 지역별 부하 분산 장치 역할을 합니다. 대부분의 경우 이 설정은 필요하지 않습니다. 다음 요구 사항을 해결하는 경우 Application Gateway를 제거할 수 있습니다.

  • Azure 웹 애플리케이션 방화벽이 Application Gateway에 연결되므로 대신 웹 애플리케이션 방화벽을 Azure Front Door 서비스에 연결해야 합니다.
  • 들어오는 호출이 Azure Front Door 인스턴스에서만 발생하도록 하는 방법이 필요합니다. Spring Cloud Gateway 애플리케이션에서 X-Azure-FDID header 검사 검사 및 Azure Front Door IP 범위를 추가할 수 있습니다. 자세한 내용은 Spring Cloud Gateway에서 Azure Front Door를 역방향 프록시로 사용하세요.

다양한 역방향 프록시 시나리오, 설정 방법 및 보안 고려 사항에 대한 자세한 내용은 역방향 프록시를 통해 Azure Spring Apps 노출을 참조하세요.

백 엔드 데이터베이스

다중 지역 배포의 경우 데이터 복제본(replica)tion 전략이 있어야 합니다. 여러 지역에서 애플리케이션을 사용할 수 있는 경우 사용자가 부실 데이터를 볼 수 없도록 데이터를 동기화해야 합니다.

현재 아키텍처는 백 엔드 데이터베이스에 MySQL 데이터베이스를 사용하지만 이 구성은 데이터 동기화를 다루지 않습니다. 데이터베이스 기술을 선택하는 경우 지역 간에 데이터를 가장 복제본(replica) 동기화하는 방법을 검사. 한 가지 옵션은 주 데이터베이스에 대해 지속적으로 동기화되고 읽을 수 있는 보조 데이터베이스를 제공하는 활성 지역 복제본(replica)tion 기능이 있는 Azure SQL Database입니다.

다음 시나리오에서 이 기능을 사용할 수 있습니다.

또 다른 방법은 Azure Cosmos DB를 사용하는 것입니다. 이 서비스는 Azure Cosmos DB 계정의 모든 지역에 데이터를 투명하게 복제본(replica) 데이터를 전역적으로 배포할 수 있습니다. 여러 쓰기 지역을 사용하여 Azure Cosmos DB를 구성할 수도 있습니다. 자세한 내용은 Geode 패턴을 참조 하세요.

자동화된 배포

인프라 배포 및 애플리케이션 코드 배포를 최대한 자동화합니다.

인프라 배포를 자동화하면 인프라가 동일하게 구성되므로 지역 간과 같은 구성 드리프트를 방지할 수 있습니다. 인프라 자동화는 장애 조치(failover) 작업을 테스트할 수도 있습니다.

애플리케이션 배포의 경우 배포 시스템이 배포해야 하는 여러 지역을 대상으로 하는지 확인합니다. 파란색-녹색 또는 카나리아 배포 전략에서 여러 지역을 사용할 수도 있습니다. 이러한 배포 전략을 사용하면 테스트에 성공한 후 테스트를 위해 한 지역 및 다른 지역에 새 버전의 애플리케이션을 롤아웃합니다.

성능 및 확장성

이 아키텍처는 지역 간에 부하를 분산하므로 애플리케이션 요구를 충족하는 기준 아키텍처 보다 더 적합합니다. 대기 시간에 따라 요청을 라우팅하도록 Azure Front Door를 구성하는 경우 요청이 가장 가까운 지역으로 라우팅되므로 사용자는 응답 시간이 향상됩니다.

데이터베이스 설정에 따라 지역 간에 데이터를 동기화해야 하는 경우 대기 시간이 추가로 발생할 수 있습니다. 보다 느슨한 일관성 수준으로 Azure Cosmos DB를 사용하여 이 대기 시간을 극복할 수 있습니다.

이 참조 아키텍처에는 메트릭에 따라 자동 크기 조정이 가능할 수 있는 몇 가지 구성 요소가 있습니다.

  • Azure Front Door는 수요에 따라 자동 크기 조정이 가능합니다. 트래픽 가속 및 캐싱 기능과 같은 다른 Azure Front Door 기능을 사용하여 자산을 최종 사용자에게 더 가깝게 만들 수 있습니다.
  • Application Gateway는 자동 크기 조정을 지원합니다. 자세한 내용은 Application Gateway v2 및 웹 애플리케이션 방화벽 v2 크기 조정을 참조 하세요.
  • Azure Spring Apps는 자동 크기 조정도 지원합니다. 자세한 내용은 애플리케이션의 자동 크기 조정 설정을 참조하세요.

비용 고려 사항

이 솔루션은 기준 아키텍처의 예상 비용을 효과적으로 두 배로 계산합니다.

다중 지역 솔루션과 관련된 비용에 대한 기본 드라이버는 다음과 같습니다.

  • 주 데이터베이스와 보조 데이터베이스는 동일한 서비스 계층을 사용해야 합니다. 그렇지 않으면 보조 데이터베이스가 복제본(replica) 변경 내용을 따라갈 수 없습니다.
  • 지역 간 트래픽이 많으면 비용이 증가합니다. Azure 지역 간의 네트워크 트래픽에는 요금이 발생합니다.

이러한 비용을 관리하려면 구현에 대한 권장 사항을 고려합니다.

  • 대기 지역에서 Azure Spring Apps 및 Application Gateway와 같은 축소된 버전의 리소스를 사용하고 대기가 활성화될 때만 리소스를 확장합니다.
  • 비즈니스 시나리오에서 허용하는 경우 비용을 절감하기 위해 활성-수동 설정을 만듭니다.
  • 가용성 및 복원력 비즈니스 요구 사항을 충족하도록 단일 지역에서 다중 영역 설정을 구현합니다. 이 옵션은 대부분의 리소스에 대해 한 번만 지불하기 때문에 비용 효율적일 수 있습니다.
  • 비용을 절감하기 위해 역방향 프록시를 하나만 사용하는 대체 설정을 선택합니다. 이 대안의 보안을 기본 위해 추가 구성을 적용해야 합니다.

소규모 애플리케이션에 적절한 기본값을 사용하여 Azure 가격 계산기를 사용하여 이 아키텍처의 서비스 비용을 예상했습니다. 애플리케이션의 예상 처리량 값에 따라 이 예상치를 업데이트할 수 있습니다.

기타 고려 사항

다중 영역 기준 아키텍처 에 대한 디자인 고려 사항은 이 문서에 설명된 다중 지역 솔루션에도 적용됩니다. 다중 지역 아키텍처의 컨텍스트에서 다음 사항을 검토합니다.

  • 네트워크 보안. 네트워크를 통해 통신을 제어하는 것이 중요합니다. 이 솔루션은 호출이 각 지역의 Application Gateway로 라우팅되는 Azure Front Door에서만 들어오는 호출을 허용합니다. Application Gateway에서 호출은 백 엔드 Azure Spring Apps 서비스로 라우팅됩니다. Azure Spring Apps에서 Key Vault와 같은 지원 서비스로의 통신도 프라이빗 엔드포인트를 사용하여 제어됩니다. 자세한 내용은 기준 아키텍처: 네트워크 보안을 참조하세요.

  • ID 및 액세스 관리 관리 ID를 사용하여 여러 구성 요소 간에 연결하여 보다 안전한 액세스를 구현합니다. 예를 들어 Azure Spring Apps가 관리 ID를 사용하여 Key Vault에 연결하는 방법입니다. 자세한 내용은 기준 아키텍처: ID 및 액세스 관리를 참조하세요.

  • 모니터링. 계측을 추가하고 분산 추적을 사용하도록 설정하여 애플리케이션에서 데이터를 수집할 수 있습니다. 해당 데이터 원본을 플랫폼 진단 결합하여 애플리케이션에 대한 엔드 투 엔드 인사이트를 가져옵니다. 자세한 내용은 기준 아키텍처: 모니터링을 참조 하세요.

  • 비밀 관리. 다중 지역 솔루션은 애플리케이션 비밀 및 인증서를 단일 키 자격 증명 모음에 저장합니다. 자세한 내용은 기준 아키텍처: 비밀 관리를 참조하세요.

시나리오 배포

이 참조 아키텍처에 대한 배포는 GitHub의 Azure Spring Apps 다중 지역 참조 아키텍처 에서 사용할 수 있습니다. 배포에는 Terraform 템플릿을 사용합니다.

아키텍처를 배포하려면 단계별 지침을 따릅니다.

참가자

Microsoft는 이 콘텐츠를 기본. 다음 기여자 원본 콘텐츠를 개발했습니다.

보안 주체 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

이 워크로드를 조직의 중앙 팀에서 관리하는 공유 서비스와 통합하려면 Azure 애플리케이션 랜딩 존에 배포합니다.

이 아키텍처에 사용되는 Azure 서비스 및 기능에 대한 설명서는 다음 문서를 참조하세요.

이 아키텍처와 관련된 구성 선택에 대해 자세히 이해하려면 다음 가이드를 사용하는 것이 좋습니다.

이 아키텍처는 Microsoft Azure Well-Architected Framework핵심 요소와 일치하도록 설계되었습니다. 각 핵심 요소에 대한 디자인 원칙을 검토하는 것이 좋습니다.