편집

다음을 통해 공유

Java용 신뢰할 수 있는 웹앱 패턴

Azure App Service
Azure Front Door

이 문서에서는 신뢰할 수 있는 웹앱 패턴을 구현하는 방법에 대한 지침을 제공합니다. 이 패턴은 클라우드 마이그레이션을 위해 웹앱을 수정(다시 배치)하는 방법을 간략하게 설명합니다. 잘 설계된 프레임워크의 원칙에 부합하는 규범적 아키텍처, 코드 및 구성 지침을 제공합니다.

Java용 신뢰할 수 있는 웹앱 패턴인 이유는 무엇인가요?

신뢰할 수 있는 웹앱 패턴은 클라우드로 마이그레이션할 때 웹앱을 다시 배치하는 방법을 정의하는 일련의 원칙 및 구현 기술입니다. 클라우드에서 성공하기 위해 수행해야 하는 최소한의 코드 업데이트에 중점을 둡니다. 다음 지침에서는 참조 구현을 전체 예제로 사용하고 가상의 회사인 Contoso Fiber의 재배치 과정을 따라 여정에 대한 비즈니스 컨텍스트를 제공합니다. Java용 Reliable Web App 패턴을 구현하기 전에 Contoso Fiber에는 Spring Boot 프레임워크를 사용하는 모놀리식 온-프레미스 CAMS(고객 계정 관리 시스템)가 있었습니다.

팁

GitHub 로고 신뢰할 수 있는 웹앱 패턴의 참조 구현 (샘플)이 있습니다. 신뢰할 수 있는 웹앱 구현의 끝 상태를 나타냅니다. 이 문서에서 설명하는 모든 코드, 아키텍처 및 구성 업데이트를 제공하는 프로덕션 수준의 웹앱입니다. 참조 구현을 배포하고 사용하여 신뢰할 수 있는 웹앱 패턴의 구현을 안내합니다.

신뢰할 수 있는 웹앱 패턴을 구현하는 방법

이 문서에는 신뢰할 수 있는 웹앱 패턴을 구현하기 위한 아키텍처, 코드 및 구성 지침이 포함되어 있습니다. 다음 링크를 사용하여 필요한 특정 지침으로 이동합니다.

  • 비즈니스 컨텍스트: 이 지침을 비즈니스 컨텍스트에 맞게 조정하고 재편성 결정을 유도하는 즉각적이고 장기적인 목표를 정의하는 방법을 알아봅니다.
  • 아키텍처 지침: 올바른 클라우드 서비스를 선택하고 비즈니스 요구 사항을 충족하는 아키텍처를 디자인하는 방법을 알아봅니다.
  • 코드 지침: 클라우드에서 웹앱의 안정성과 성능 효율성을 개선하기 위한 세 가지 디자인 패턴 구현: 다시 시도, 회로 차단기 및 캐시 배제 패턴
  • 구성 지침: 인증 및 권한 부여, 관리 ID, 권한 있는 환경, 코드로서의 인프라 및 모니터링을 구성합니다.

비즈니스 컨텍스트

웹앱을 다시 배치하는 첫 번째 단계는 비즈니스 목표를 정의하는 것입니다. 서비스 수준 목표 및 비용 최적화 목표와 같은 즉각적인 목표와 웹 애플리케이션에 대한 향후 목표를 설정해야 합니다. 이러한 목표는 클라우드 서비스 선택 및 클라우드의 웹 애플리케이션 아키텍처에 영향을 줍니다. 99.9% 가동 시간 등 웹앱에 대한 대상 SLO를 정의합니다. 웹앱의 가용성에 영향을 주는 모든 서비스에 대한 복합 SLA 를 계산합니다.

예를 들어 Contoso Fiber는 온-프레미스 CAMS(고객 계정 관리 시스템) 웹앱을 확장하여 다른 지역에 도달하려고 했습니다. 웹앱에 대한 증가하는 수요를 충족하기 위해 다음 목표를 설정했습니다.

  • 저렴한 고가용성 코드 변경 적용
  • 99.9%의 SLO(서비스 수준 목표)에 도달
  • DevOps 사례 채택
  • 비용 최적화 환경 만들기
  • 안정성 및 보안 향상

Contoso Fiber는 온-프레미스 인프라가 애플리케이션 크기를 조정하기 위한 비용 효율적인 솔루션이 아니라고 판단했습니다. 따라서 CAMS 웹 애플리케이션을 Azure로 마이그레이션하는 것이 즉각적이고 미래의 목표를 달성하는 가장 비용 효율적인 방법이라고 결정했습니다.

아키텍처 지침

신뢰할 수 있는 웹앱 패턴에는 몇 가지 필수 아키텍처 요소가 있습니다. 엔드포인트 확인을 관리하는 DNS, 악의적인 HTTP 트래픽을 차단하는 웹 애플리케이션 방화벽 및 인바운드 사용자 요청을 보호하고 라우팅하는 부하 분산 장치가 필요합니다. 애플리케이션 플랫폼은 웹앱 코드를 호스트하고 가상 네트워크의 프라이빗 엔드포인트를 통해 모든 백 엔드 서비스를 호출합니다. 애플리케이션 성능 모니터링 도구는 메트릭 및 로그를 캡처하여 웹앱을 이해합니다.

신뢰할 수 있는 웹앱 패턴의 필수 아키텍처 요소를 보여 주는 다이어그램

그림 1 신뢰할 수 있는 웹앱 패턴의 필수 아키텍처 요소입니다.

아키텍처 설계

RTO(복구 시간 목표) 및 RPO(복구 지점 목표)와 같은 복구 메트릭을 지원하도록 인프라를 디자인합니다. RTO는 가용성에 영향을 미치며 SLO를 지원해야 합니다. RPO(복구 지점 목표)를 결정하고 RPO를 충족하도록 데이터 중복성을 구성합니다.

  • 인프라 안정성을 선택합니다. 가용성 요구 사항을 충족하는 데 필요한 가용성 영역 및 지역 수를 결정합니다. 복합 SLA가 SLO를 충족할 때까지 가용성 영역 및 지역을 추가합니다. Reliable Web App 패턴은 활성-활성 또는 활성-수동 구성에 대해 여러 지역을 지원합니다. 예를 들어 참조 구현은 활성-수동 구성을 사용하여 99.9%의 SLO를 충족합니다.

    다중 지역 웹앱의 경우 비즈니스 요구 사항에 따라 활성-활성 또는 활성-수동 구성을 지원하도록 트래픽을 두 번째 지역으로 라우팅하도록 부하 분산 장치를 구성합니다. 두 지역에는 한 지역에 지역을 연결하는 허브 가상 네트워크가 있다는 점을 제외하고 동일한 서비스가 필요합니다. 허브 및 스포크 네트워크 토폴로지 채택을 통해 네트워크 방화벽과 같은 리소스를 중앙 집중화하고 공유합니다. 가상 머신이 있는 경우 허브 가상 네트워크에 요새 호스트를 추가하여 안전하게 관리합니다(그림 2 참조).

    두 번째 지역 및 허브 및 스포크 토폴로지와 신뢰할 수 있는 웹앱 패턴을 보여 주는 다이어그램

    그림 2. 두 번째 지역 및 허브 및 스포크 토폴로지의 신뢰할 수 있는 웹앱 패턴입니다.

  • 네트워크 토폴로지 선택 웹 및 네트워킹 요구 사항에 적합한 네트워크 토폴로지 선택 여러 가상 네트워크를 사용하려는 경우 허브 및 스포크 네트워크 토폴로 지를 사용합니다. 온-프레미스 및 가상 네트워크에 대한 하이브리드 연결 옵션을 통해 비용, 관리 및 보안 이점을 제공합니다.

올바른 Azure 서비스 선택

웹앱을 클라우드로 이동하는 경우 비즈니스 요구 사항을 충족하고 온-프레미스 웹앱의 현재 기능에 부합하는 Azure 서비스를 선택해야 합니다. 맞춤은 재배치 작업을 최소화하는 데 도움이 됩니다. 예를 들어 동일한 데이터베이스 엔진을 유지하고 기존 미들웨어 및 프레임워크를 지원할 수 있는 서비스를 사용합니다. 다음 섹션에서는 웹앱에 적합한 Azure 서비스를 선택하기 위한 지침을 제공합니다.

예를 들어 클라우드로 이동하기 전에 Contoso Fiber의 CAMS 웹앱은 온-프레미스 모놀리식 Java 웹앱이었습니다. PostgreSQL 데이터베이스가 있는 Spring Boot 앱입니다. 웹앱은 기간 업무 지원 앱입니다. 그것은 직원을 향한 것입니다. Contoso Fiber 직원은 애플리케이션을 사용하여 고객의 지원 사례를 관리합니다. 웹앱은 확장성 및 기능 배포에서 일반적인 문제를 겪었습니다. 이 시작점, 비즈니스 목표 및 SLO는 서비스 선택을 이끌었습니다.

  • 애플리케이션 플랫폼: Azure 앱 Service를 애플리케이션 플랫폼으로 사용합니다. Contoso Fiber는 다음과 같은 이유로 Azure 앱 Service를 애플리케이션 플랫폼으로 선택했습니다.

    • 자연스러운 진행: Contoso Fiber는 온-프레미스 서버에 Spring Boot jar 파일을 배포하고 해당 배포 모델에 대한 재정의 양을 최소화하려고 했습니다. App Service는 Spring Boot 앱을 실행하기 위한 강력한 지원을 제공하며, Contoso Fiber가 App Service를 사용하기 위한 자연스러운 진행이었습니다. Azure Container Apps는 이 앱의 매력적인 대안이기도 합니다. 자세한 내용은 Azure Container Apps의 Azure Spring Apps 및 Java 개요를 참조하세요.
    • 높은 SLA: 프로덕션 환경에 대한 요구 사항을 충족하는 높은 SLA가 있습니다.
    • 관리 오버헤드 감소: 완전히 관리되는 호스팅 솔루션입니다.
    • 컨테이너화 기능: App Service는 Azure Container Registry와 같은 프라이빗 컨테이너 이미지 레지스트리에서 작동합니다. Contoso Fiber는 이러한 레지스트리를 사용하여 나중에 웹앱을 컨테이너화할 수 있습니다.
    • 자동 크기 조정: 웹앱은 사용자 트래픽에 따라 빠르게 확장, 축소, 축소 및 확장할 수 있습니다.

  • ID 관리: ID 및 액세스 관리 솔루션으로 Microsoft Entra ID를 사용합니다. Contoso Fiber는 다음과 같은 이유로 Microsoft Entra ID를 선택했습니다.

    • 인증 및 권한 부여: 애플리케이션은 콜 센터 직원을 인증하고 권한을 부여해야 합니다.
    • 확장 가능: 더 큰 시나리오를 지원하도록 확장됩니다.
    • 사용자 ID 제어: 콜 센터 직원은 기존 엔터프라이즈 ID를 사용할 수 있습니다.
    • 권한 부여 프로토콜 지원: 관리 ID에 대해 OAuth 2.0을 지원합니다.

  • 데이터베이스: 동일한 데이터베이스 엔진을 유지할 수 있는 서비스를 사용합니다. 데이터 저장소 의사 결정 트리를 사용합니다. Contoso Fiber는 다음과 같은 이유로 Azure Database for PostgreSQL 및 유연한 서버 옵션을 선택했습니다.

    • 안정성: 유연한 서버 배포 모델은 여러 가용성 영역에서 영역 중복 고가용성을 지원합니다. 이 구성은 동일한 Azure 지역 내의 다른 가용성 영역에 웜 대기 서버를 유지 관리합니다. 구성은 대기 서버에 데이터를 동기적으로 복제합니다.
    • 지역 간 복제: 다른 지역의 읽기 전용 복제본 데이터베이스에 데이터를 비동기적으로 복제할 수 있는 읽기 복제본 기능이 있습니다.
    • 성능: 실제 사용량 현황 데이터를 사용하여 데이터베이스 성능을 향상시키기 위해 예측 가능한 성능과 지능형 튜닝을 제공합니다.
    • 관리 오버헤드 감소: 관리 의무를 줄이는 완전 관리형 Azure 서비스입니다.
    • 마이그레이션 지원: 온-프레미스 단일 서버 PostgreSQL 데이터베이스에서 데이터베이스 마이그레이션을 지원합니다. 마이그레이션 도구를 사용하여 마이그레이션 프로세스를 간소화할 수 있습니다.
    • 온-프레미스 구성과의 일관성: Contoso Fiber에서 현재 사용하는 버전을 포함하여 PostgreSQL의 다양한 커뮤니티 버전을 지원합니다.
    • 복원력. 유연한 서버 배포는 자동으로 서버 백업을 만들고 동일한 지역 내에서 ZRS(영역 중복 스토리지)를 사용하여 저장합니다. 백업 보존 기간 내의 특정 시점으로 데이터베이스를 복원할 수 있습니다. 백업 및 복원 기능은 Contoso Fiber가 온-프레미스를 만들 수 있는 것보다 더 나은 RPO(데이터 손실의 허용 가능한 양)를 만듭니다.

  • 애플리케이션 성능 모니터링: Application Insights를 사용하여 애플리케이션에서 원격 분석을 분석합니다. Contoso Fiber는 다음과 같은 이유로 Application Insights를 사용하도록 선택했습니다.

    • Azure Monitor와의 통합: Azure Monitor와 최상의 통합을 제공합니다.
    • 변칙 검색: 성능 변칙을 자동으로 검색합니다.
    • 문제 해결: 실행 중인 앱에서 문제를 진단하는 데 도움이 됩니다.
    • 모니터링: 사용자가 앱을 사용하는 방법에 대한 정보를 수집하여 사용자 지정 이벤트를 쉽게 추적할 수 있습니다.
    • 가시성 격차: 온-프레미스 솔루션에 애플리케이션 성능 모니터링 솔루션이 없습니다. Application Insights는 애플리케이션 플랫폼 및 코드와 쉽게 통합할 수 있습니다.

  • 캐시: 웹앱 아키텍처에 캐시를 추가할지 여부를 선택합니다. Azure Cache for Redis 는 Azure의 기본 캐시 솔루션입니다. Redis 소프트웨어를 기반으로 하는 관리되는 메모리 내 데이터 저장소입니다. Contoso Fiber는 다음과 같은 이유로 Azure Cache for Redis를 추가했습니다.

    • 속도 및 볼륨: 일반적으로 액세스되고 느리게 변화하는 데이터에 대한 높은 데이터 처리량과 짧은 대기 시간 읽기를 제공합니다.
    • 다양한 지원 가능성: 웹앱의 모든 인스턴스에서 사용할 수 있는 통합 캐시 위치입니다.
    • 외부 데이터 저장소. 온-프레미스 애플리케이션 서버는 VM 로컬 캐싱을 수행했습니다. 이 설정은 자주 사용한 데이터를 오프로드하지 않았으며 데이터를 무효화할 수 없었습니다.
    • 비스틱 세션: 캐시를 사용하면 웹앱이 세션 상태를 외부화하고 논스틱 세션을 사용할 수 있습니다. 온-프레미스에서 실행되는 대부분의 Java 웹앱은 메모리 내 클라이언트 쪽 캐싱을 사용합니다. 메모리 내 클라이언트 쪽 캐싱은 잘 확장되지 않으며 호스트의 메모리 공간을 증가합니다. Contoso Fiber는 Azure Cache for Redis를 사용하여 애플리케이션의 확장성 및 성능을 개선하기 위해 완전히 관리되고 확장 가능한 캐시 서비스를 제공합니다. Contoso Fiber는 캐시 추상화 프레임워크(Spring Cache)를 사용하고 있었고 캐시 공급자를 교체하기 위해 최소한의 구성 변경만 필요했습니다. 이를 통해 Ehcache 공급자에서 Redis 공급자로 전환할 수 있습니다.

  • 부하 분산 장치: PaaS 솔루션을 사용하는 웹 애플리케이션은 Azure Front Door, Azure 애플리케이션 Gateway 또는 웹앱 아키텍처 및 요구 사항에 따라 둘 다 사용해야 합니다. 부하 분산 장치 의사 결정 트리를 사용하여 올바른 부하 분산 장치를 선택합니다. Contoso 파이버에는 여러 지역에 걸쳐 트래픽을 라우팅할 수 있는 계층 7 부하 분산 장치가 필요했습니다. Contoso Fiber는 99.9%의 SLO를 충족하기 위해 다중 지역 웹앱이 필요했습니다. Contoso Fiber는 다음과 같은 이유로 Azure Front Door를 선택했습니다.

    • 전역 부하 분산: 여러 지역에 걸쳐 트래픽을 라우팅할 수 있는 계층 7 부하 분산 장치입니다.
    • 웹 애플리케이션 방화벽: 기본적으로 Azure 웹 애플리케이션 방화벽과 통합됩니다.
    • 라우팅 유연성: 애플리케이션 팀이 애플리케이션의 향후 변경 내용을 지원하도록 수신 요구를 구성할 수 있습니다.
    • 트래픽 가속: anycast를 사용하여 가장 가까운 Azure 현재 지점에 도달하고 웹앱에 대한 가장 빠른 경로를 찾습니다.
    • 사용자 지정 도메인: 유연한 도메인 유효성 검사를 통해 사용자 지정 도메인 이름을 지원합니다.
    • 상태 프로브: 애플리케이션에는 지능형 상태 프로브 모니터링이 필요합니다. Azure Front Door는 프로브의 응답을 사용하여 클라이언트 요청을 라우팅하는 데 가장 적합한 원본을 결정합니다.
    • 모니터링 지원: Front Door 및 보안 패턴 모두에 대한 올인원 대시보드가 포함된 기본 제공 보고서를 지원합니다. Azure Monitor와 통합되는 경고를 구성할 수 있습니다. 애플리케이션에서 각 요청 및 실패한 상태 프로브를 기록할 수 있습니다.
    • DDoS 보호: 기본 제공 계층 3-4 DDoS 보호가 있습니다.
    • 콘텐츠 배달 네트워크: 콘텐츠 배달 네트워크를 사용하도록 Contoso 파이버를 배치합니다. 콘텐츠 배달 네트워크는 사이트 가속을 제공합니다.

  • 웹 애플리케이션 방화벽: Azure 웹 애플리케이션 방화벽을 사용하여 일반적인 웹 악용 및 취약성으로부터 중앙 집중식 보호를 제공합니다. Contoso Fiber는 다음과 같은 이유로 Azure 웹 애플리케이션 방화벽을 사용했습니다.

    • 글로벌 보호: 성능을 저하시키지 않고 향상된 글로벌 웹앱 보호를 제공합니다.
    • 봇넷 보호: 팀은 봇넷과 관련된 보안 문제를 해결하기 위해 설정을 모니터링하고 구성할 수 있습니다.
    • 온-프레미스와의 패리티: 온-프레미스 솔루션이 IT에서 관리하는 웹 애플리케이션 방화벽 뒤에서 실행되었습니다.
    • 사용 편의성: 웹 애플리케이션 방화벽이 Azure Front Door와 통합됩니다.

  • 비밀 관리자: Azure에서 관리할 비밀이 있는 경우 Azure Key Vault를 사용합니다. Contoso 파이버는 다음과 같은 이유로 Key Vault를 사용했습니다.

    • 암호화: 미사용 및 전송 중인 암호화를 지원합니다.
    • 관리 ID 지원: 애플리케이션 서비스는 관리 ID를 사용하여 비밀 저장소에 액세스할 수 있습니다.
    • 모니터링 및 로깅: 저장된 비밀이 변경될 때 감사 액세스를 용이하게 하고 경고를 생성합니다.
    • 통합: Azure 구성 저장소(App Configuration) 및 웹 호스팅 플랫폼(App Service)과 네이티브 통합을 제공합니다.

  • 엔드포인트 보안: Azure Private Link를 사용하여 가상 네트워크의 프라이빗 엔드포인트를 통해 서비스로서의 플랫폼 솔루션에 액세스합니다. 가상 네트워크와 서비스 간의 트래픽은 Microsoft 백본 네트워크를 통해 이동합니다. Contoso Fiber는 다음과 같은 이유로 Private Link를 선택했습니다.

    • 향상된 보안 통신: 애플리케이션이 Azure 플랫폼의 서비스에 비공개로 액세스하고 데이터 누출을 방지할 수 있도록 데이터 저장소의 네트워크 공간을 줄일 수 있습니다.
    • 최소 작업: 프라이빗 엔드포인트는 웹앱에서 사용하는 웹앱 플랫폼 및 데이터베이스 플랫폼을 지원합니다. 두 플랫폼 모두 최소한의 변경을 위해 기존 온-프레미스 구성을 미러링합니다.

  • 네트워크 보안: Azure Firewall을 사용하여 네트워크 수준에서 인바운드 및 아웃바운드 트래픽을 제어합니다. Azure Bastion을 사용하여 RDP/SSH 포트를 노출하지 않고 가상 머신에 안전하게 연결합니다. Contoso Fiber는 허브 및 스포크 네트워크 토폴로지와 공유 네트워크 보안 서비스를 허브에 배치하려고 했습니다. Azure Firewall은 스포크에서 모든 아웃바운드 트래픽을 검사하여 보안을 향상시켜 네트워크 보안을 강화합니다. Contoso Fiber는 DevOps 서브넷의 점프 호스트에서 안전한 배포를 위해 Azure Bastion이 필요했습니다.

코드 지침

웹앱을 클라우드로 성공적으로 이동하려면 다시 시도 패턴, 회로 차단기 패턴 및 캐시 배제 디자인 패턴으로 웹앱 코드를 업데이트해야 합니다.

신뢰할 수 있는 필수 웹앱 아키텍처에서 디자인 패턴의 역할을 보여 주는 다이어그램

그림 3. 디자인 패턴의 역할입니다.

각 디자인 패턴은 잘 설계된 프레임워크의 더 많은 핵심 요소 중 하나에 부합하는 워크로드 디자인 이점을 제공합니다. 구현해야 하는 패턴의 개요는 다음과 같습니다.

  1. 다시 시도 패턴: 다시 시도 패턴은 간헐적으로 실패할 수 있는 작업을 다시 시도하여 일시적인 오류를 처리합니다. 다른 Azure 서비스에 대한 모든 아웃바운드 호출에서 이 패턴을 구현합니다.

  2. 회로 차단기 패턴: 회로 차단기 패턴은 애플리케이션이 일시적이지 않은 작업을 다시 시도하는 것을 방지합니다. 다른 Azure 서비스에 대한 모든 아웃바운드 호출에서 이 패턴을 구현합니다.

  3. 캐시 배제 패턴: 캐시 배제 패턴은 데이터 저장소보다 캐시에 더 자주 추가되고 캐시에서 검색됩니다. 데이터베이스에 대한 요청에 대해 이 패턴을 구현합니다.

디자인 패턴 안정성(RE) 보안(SE) CO(비용 최적화) 운영 우수성(OE) PE(성능 효율성) WAF 원칙 지원
패턴 다시 시도 ✔ RE:07
회로 차단기 패턴 ✔ ✔ RE:03
RE:07
PE:07
PE:11
캐시 배제 패턴 ✔ ✔ RE:05
PE:08
PE:12

재시도 패턴 구현

애플리케이션 코드에 재시도 패턴을 추가하여 임시 서비스 중단을 해결합니다. 이러한 중단을 일시적인 오류라고 합니다. 일시적인 오류는 일반적으로 몇 초 내에 자체적으로 해결됩니다. 다시 시도 패턴을 사용하면 실패한 요청을 다시 전송할 수 있습니다. 또한 실패를 허용하기 전에 요청 지연 및 시도 횟수를 구성할 수 있습니다.

간단한 내결함성 라이브러리인 Resilience4j를 사용하여 Java에서 재시도 패턴을 구현합니다. 예를 들어 참조 구현은 서비스 계획 컨트롤러의 listServicePlans 메서드를 재시도 주석으로 데코레이팅하여 재시도 패턴을 추가합니다. 코드는 초기 호출이 실패할 경우 데이터베이스에서 서비스 계획 목록에 대한 호출을 다시 시도합니다. 참조 구현은 최대 시도, 대기 기간 및 다시 시도해야 하는 예외를 포함하여 재시도 정책을 구성합니다. 재시도 정책은 .에서 구성됩니다 application.properties.

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

회로 차단기 패턴 구현

회로 차단기 패턴을 사용하여 일시적인 오류가 아닌 서비스 중단을 처리합니다. 회로 차단기 패턴은 애플리케이션이 응답하지 않는 서비스에 계속 액세스하지 못하도록 합니다. 애플리케이션을 릴리스하고 CPU 주기를 낭비하지 않으므로 애플리케이션이 최종 사용자의 성능 무결성을 유지합니다.

Spring Circuit Breaker 및 Resilience4j 설명서를 사용하여 회로 차단기 패턴을 구현합니다. 예를 들어 참조 구현은 회로 차단기 특성으로 메서드를 데코레이팅하여 회로 차단기 패턴을 구현합니다.

캐시 배제 패턴 구현

메모리 내 데이터 관리를 개선하기 위해 웹앱에 캐시 배제 패턴을 추가합니다. 이 패턴은 데이터 요청을 처리하고 캐시와 영구 스토리지(예: 데이터베이스) 간의 일관성을 보장하는 책임을 애플리케이션에 할당합니다. 응답 시간을 단축하고, 처리량을 향상시키며, 더 많은 크기 조정의 필요성을 줄입니다. 또한 기본 데이터 저장소의 부하를 줄여 안정성 및 비용 최적화를 개선합니다. Cache-Aside 패턴을 구현하려면 다음 권장 사항을 따릅니다.

  • 캐시를 사용하도록 애플리케이션을 구성합니다. 캐싱을 사용하도록 설정하려면 파일에 패키지를 종속성으로 추가 spring-boot-starter-cache 합니다 pom.xml . 이 패키지는 Redis 캐시에 대한 기본 구성을 제공합니다.

  • 필요한 데이터를 캐시합니다. 높은 필요 데이터에 Cache-Aside 패턴을 적용하여 효율성을 증폭합니다. Azure Monitor를 사용하여 데이터베이스의 CPU, 메모리 및 스토리지를 추적합니다. 이러한 메트릭은 캐시 배제 패턴을 적용한 후 더 작은 데이터베이스 SKU를 사용할 수 있는지 여부를 결정하는 데 도움이 됩니다. 코드에서 특정 데이터를 캐시하려면 주석을 @Cacheable 추가합니다. 이 주석은 결과를 캐시해야 하는 메서드를 Spring에 알려줍니다.

  • 캐시 데이터를 최신 상태로 유지합니다. 최신 데이터베이스 변경 내용과 동기화하도록 일반 캐시 업데이트를 예약합니다. 데이터 변동성 및 사용자 요구에 따라 최적의 새로 고침 속도를 결정합니다. 이렇게 하면 애플리케이션이 Cache-Aside 패턴을 사용하여 빠른 액세스 및 현재 정보를 모두 제공할 수 있습니다. 기본 캐시 설정은 웹 애플리케이션에 적합하지 않을 수 있습니다. 파일 또는 환경 변수에서 application.properties 이러한 설정을 사용자 지정할 수 있습니다. 예를 들어 값(밀리초 단위로 표시됨)을 수정 spring.cache.redis.time-to-live 하여 데이터가 제거되기 전에 캐시에 남아 있는 기간을 제어할 수 있습니다.

  • 데이터 일관성을 보장합니다. 데이터베이스 쓰기 작업 직후 캐시를 업데이트하는 메커니즘을 구현합니다. 이벤트 기반 업데이트 또는 전용 데이터 관리 클래스를 사용하여 캐시 일관성을 보장합니다. 캐시를 데이터베이스 수정과 일관되게 동기화하는 것은 캐시 배제 패턴의 핵심입니다.

구성 지침

다음 섹션에서는 구성 업데이트를 구현하는 방법에 대한 지침을 제공합니다. 각 섹션은 잘 설계된 프레임워크의 하나 이상의 기둥에 맞춥니다.

구성 안정성(RE) 보안(SE) CO(비용 최적화) 운영 우수성(OE) PE(성능 효율성) WAF 원칙 지원
사용자 인증 및 권한 부여 구성 ✔ ✔ SE:05
OE:10
관리 ID 구현 ✔ ✔ SE:05
OE:10
적절한 크기 환경 ✔ CO:05
CO:06
자동 크기 조정을 구현 ✔ ✔ ✔ RE:06
CO:12
PE:05
리소스 배포 자동화 ✔ OE:05
모니터링 구현 ✔ ✔ ✔ OE:07
PE:04

사용자 인증 및 권한 부여 구성

웹 애플리케이션을 Azure로 마이그레이션할 때 사용자 인증 및 권한 부여 메커니즘을 구성합니다. 다음 권장 사항을 따릅니다.

  • ID 플랫폼을 사용합니다. Microsoft ID 플랫폼을 사용하여 웹앱 인증을 설정합니다. 이 플랫폼은 단일 Microsoft Entra 디렉터리, 여러 조직의 여러 Microsoft Entra 디렉터리 및 Microsoft ID 또는 소셜 계정을 사용하는 애플리케이션을 지원합니다.

    Microsoft Entra ID용 Spring Boot Starter는 쉽게 설정할 수 있는 Spring Security 및 Spring Boot를 활용하여 이 프로세스를 간소화합니다. Spring Cloud 구성 요소와 통합 기능과 함께 다양한 인증 흐름, 자동 토큰 관리 및 사용자 지정 가능한 권한 부여 정책을 제공합니다. 이렇게 하면 수동 라이브러리 또는 설정 구성 없이 Spring Boot 애플리케이션에 간단한 Microsoft Entra ID 및 OAuth 2.0 통합이 가능합니다.

    예를 들어 참조 구현에서는 Microsoft ID 플랫폼(Microsoft Entra ID)를 웹앱의 ID 공급자로 사용합니다. OAuth 2.0 인증 코드 부여를 사용하여 Microsoft Entra 계정으로 사용자를 로그인합니다. 다음 XML 코드 조각은 OAuth 2.0 인증 코드 부여 흐름의 두 가지 필수 종속성을 정의합니다. 종속성을 com.azure.spring: spring-cloud-azure-starter-active-directory 통해 Spring Boot 애플리케이션에서 Microsoft Entra 인증 및 권한 부여를 사용할 수 있습니다. 종속성은 org.springframework.boot: spring-boot-starter-oauth2-client Spring Boot 애플리케이션에서 OAuth 2.0 인증 및 권한 부여를 지원합니다.

    <dependency>
    <groupid>com.azure.spring</groupid>
    <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
</dependency>
<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-oauth2-client</artifactid>
</dependency>

  • 앱 등록을 만듭니다. Microsoft Entra ID에는 기본 테넌트에서 애플리케이션 등록이 필요합니다. 애플리케이션 등록을 통해 웹앱에 액세스하는 사용자에게 기본 테넌트에 ID가 있는지 확인합니다. 예를 들어 참조 구현은 Terraform을 사용하여 앱별 계정 관리자 역할과 함께 Microsoft Entra ID 앱 등록을 만듭니다.

    resource "azuread_application" "app_registration" {
  display_name     = "${azurecaf_name.app_service.result}-app"
  owners           = [data.azuread_client_config.current.object_id]
  sign_in_audience = "AzureADMyOrg"  # single tenant

  app_role {
    allowed_member_types = ["User"]
    description          = "Account Managers"
    display_name         = "Account Manager"
    enabled              = true
    id                   = random_uuid.account_manager_role_id.result
    value                = "AccountManager"
  }
}

  • 애플리케이션에서 권한 부여를 적용합니다. RBAC(역할 기반 액세스 제어)를 사용하여 애플리케이션 역할에 최소 권한을 할당합니다. 서로 다른 사용자 작업에 대한 특정 역할을 정의하여 겹치지 않도록 하고 명확성을 보장합니다. 사용자를 적절한 역할에 매핑하고 필요한 리소스 및 작업에만 액세스할 수 있는지 확인합니다. Microsoft Entra ID에 Spring Boot Starter를 사용하도록 Spring Security를 구성합니다. 이 라이브러리를 사용하면 Microsoft Entra ID와 통합할 수 있으며 사용자가 안전하게 인증되도록 할 수 있습니다. MSAL(Microsoft 인증 라이브러리)을 구성하고 사용하도록 설정하면 더 많은 보안 기능에 액세스할 수 있습니다. 이러한 기능에는 토큰 캐싱 및 자동 토큰 새로 고침이 포함됩니다.

    예를 들어 참조 구현은 Contoso Fiber의 계정 관리 시스템에서 사용자 역할 유형을 반영하는 앱 역할을 만듭니다. 역할은 권한 부여 중에 사용 권한으로 변환됩니다. CAMS에서 앱별 역할의 예로는 계정 관리자, 수준 1(L1) 지원 담당자 및 필드 서비스 담당자가 있습니다. 계정 관리자 역할에는 새 앱 사용자 및 고객을 추가할 수 있는 권한이 있습니다. 현장 서비스 담당자는 지원 티켓을 만들 수 있습니다. 특성은 PreAuthorize 특정 역할에 대한 액세스를 제한합니다.

        @GetMapping("/new")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    public String newAccount(Model model) {
        if (model.getAttribute("account") == null) {
            List<ServicePlan> servicePlans = accountService.findAllServicePlans();
            ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
            NewAccountRequest accountFormData = new NewAccountRequest();
            accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
            model.addAttribute("account", accountFormData);
            model.addAttribute("servicePlans", servicePlans);
        }
        model.addAttribute("servicePlans", accountService.findAllServicePlans());
        return "pages/account/new";
    }
    ...

    Microsoft Entra ID와 통합하기 위해 참조 구현은 OAuth 2.0 인증 코드 부여 흐름을 사용합니다. 이 흐름을 사용하면 사용자가 Microsoft 계정으로 로그인할 수 있습니다. 다음 코드 조각에서는 인증 및 권한 부여에 Microsoft Entra ID를 사용하도록 구성하는 SecurityFilterChain 방법을 보여줍니다.

    @Configuration(proxyBeanMethods = false)
@EnableWebSecurity
@EnableMethodSecurity
public class AadOAuth2LoginSecurityConfig {
    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
            .and()
                .authorizeHttpRequests()
            .requestMatchers(EndpointRequest.to("health")).permitAll()
            .anyRequest().authenticated()
            .and()
                .logout(logout -> logout
                            .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                            .clearAuthentication(true)
                            .invalidateHttpSession(true));
        return http.build();
    }
}
...

  • 스토리지에 대한 임시 액세스를 선호합니다. 임시 사용 권한을 사용하여 SAS(공유 액세스 서명)와 같은 무단 액세스 및 위반으로부터 보호합니다. 임시 액세스 권한을 부여할 때 사용자 위임 SAS를 사용하여 보안을 최대화합니다. Microsoft Entra ID 자격 증명을 사용하고 영구 스토리지 계정 키가 필요하지 않은 유일한 SAS입니다.

  • Azure에서 권한 부여를 적용합니다. Azure RBAC를 사용하여 사용자 ID에 최소 권한을 할당합니다. Azure RBAC는 Azure 리소스 ID가 액세스할 수 있는 항목, 해당 리소스로 수행할 수 있는 작업 및 액세스 권한이 있는 영역을 결정합니다.

  • 영구 관리자 권한은 사용하지 않습니다. Microsoft Entra Privileged Identity Management를 사용하여 권한 있는 작업에 대한 Just-In-Time 액세스 권한을 부여합니다. 예를 들어 개발자는 데이터베이스를 만들거나 삭제하고, 테이블 스키마를 수정하고, 사용자 권한을 변경하려면 관리자 수준의 액세스 권한이 필요한 경우가 많습니다. Just-In-Time 액세스를 통해 사용자 ID는 권한 있는 작업을 수행할 수 있는 임시 권한을 받습니다.

관리 ID 구현

관리 ID를 지원하는 모든 Azure 서비스에 대해 관리 ID를 사용합니다. 관리 ID를 사용하면 Azure 리소스(워크로드 ID)가 자격 증명을 관리하지 않고도 다른 Azure 서비스에 인증하고 상호 작용할 수 있습니다. 하이브리드 및 레거시 시스템은 마이그레이션을 간소화하기 위해 온-프레미스 인증 솔루션을 유지할 수 있지만 가능한 한 빨리 관리 ID로 전환해야 합니다. 관리 ID를 구현하려면 다음 권장 사항을 따릅니다.

  • 올바른 유형의 관리 ID를 선택합니다. 동일한 권한 집합이 필요한 둘 이상의 Azure 리소스가 있는 경우 사용자 할당 관리 ID를 선호합니다. 이 설정은 각 리소스에 대해 시스템 할당 관리 ID를 만들고 모든 리소스에 동일한 권한을 할당하는 것보다 더 효율적입니다. 그렇지 않으면 시스템 할당 관리 ID를 사용합니다.

  • 최소 권한을 구성합니다. Azure RBAC를 사용하여 데이터베이스의 CRUD 작업 또는 비밀 액세스와 같은 작업에 중요한 권한만 부여합니다. 워크로드 ID 권한은 영구적이므로 워크로드 ID에 대한 Just-In-Time 또는 단기 권한을 제공할 수 없습니다. Azure RBAC가 특정 시나리오를 다루지 않는 경우 Azure RBAC를 Azure 서비스 수준 액세스 정책으로 보완합니다.

  • 남은 비밀을 보호합니다. Azure Key Vault에 나머지 비밀을 저장합니다. 각 HTTP 요청 중에 대신 애플리케이션 시작 시 Key Vault에서 비밀을 로드합니다. HTTP 요청 내의 고주파 액세스는 Key Vault 트랜잭션 제한을 초과 할 수 있습니다. 애플리케이션 구성을 Azure 앱 구성에 저장합니다.

적절한 크기 환경

초과하지 않고 각 환경의 요구 사항을 충족하는 Azure 서비스의 SKU(성능 계층)를 사용합니다. 환경 크기를 조정하려면 다음 권장 사항을 따르세요.

  • 비용을 예측합니다. Azure 가격 계산기를 사용하여 각 환경의 비용을 예측합니다.

  • 비용 최적화 프로덕션 환경. 프로덕션 환경에는 SLA(서비스 수준 계약), 기능 및 프로덕션에 필요한 규모를 충족하는 SKU가 필요합니다. 리소스 사용량을 지속적으로 모니터링하고 실제 성능 요구 사항에 맞게 SKU를 조정합니다.

  • 비용 최적화 사전 프로덕션 환경. 사전 프로덕션 환경에서는 저렴한 리소스를 사용하고, 불필요한 서비스를 사용하지 않도록 설정하고, Azure 개발/테스트 가격 책정과 같은 할인을 적용해야 합니다. 사전 프로덕션 환경이 프로덕션 환경과 충분히 유사하여 위험이 발생하지 않도록 합니다. 이 잔액을 통해 불필요한 비용을 발생시키지 않고도 테스트가 효과적으로 유지됩니다.

  • IaC(Infrastructure as Code)를 사용하여 SKU를 정의합니다. IaC를 구현하여 환경에 따라 올바른 SKU를 동적으로 선택하고 배포합니다. 이 방법은 일관성을 향상시키고 관리를 간소화합니다.

예를 들어 참조 구현에는 다른 SKU를 배포하는 선택적 매개 변수가 있습니다. 환경 매개 변수는 Terraform 템플릿에 개발 SKU를 선택하도록 지시합니다.

azd env set APP_ENVIRONMENT prod

자동 크기 조정을 구현

자동 크기 조정을 사용하면 웹앱이 복원력 있고 응답성이 뛰어나며 동적 워크로드를 효율적으로 처리할 수 있습니다. 자동 크기 조정을 구현하려면 다음 권장 사항을 따릅니다.

  • 스케일 아웃을 자동화합니다. Azure 자동 크기 조정을 사용하여 프로덕션 환경에서 수평 크기 조정을 자동화합니다. 애플리케이션에서 다양한 부하를 처리할 수 있도록 주요 성능 메트릭에 따라 스케일 아웃하도록 자동 크기 조정 규칙을 구성합니다.

  • 크기 조정 트리거를 구체화합니다. 애플리케이션의 크기 조정 요구 사항에 익숙하지 않은 경우 초기 크기 조정 트리거로 CPU 사용률로 시작합니다. RAM, 네트워크 처리량 및 디스크 I/O와 같은 다른 메트릭을 포함하도록 크기 조정 트리거를 구체화합니다. 목표는 성능 향상을 위해 웹 애플리케이션의 동작과 일치하도록 하는 것입니다.

  • 스케일 아웃 버퍼를 제공합니다. 최대 용량에 도달하기 전에 트리거할 크기 조정 임계값을 설정합니다. 예를 들어 100%에 도달할 때까지 기다리지 않고 CPU 사용률이 85%로 조정되도록 구성합니다. 이 사전 예방적 접근 방식은 성능을 유지하고 잠재적인 병목 상태를 방지하는 데 도움이 됩니다.

리소스 배포 자동화

자동화를 사용하여 모든 환경에서 Azure 리소스 및 코드를 배포하고 업데이트합니다. 다음 권장 사항을 따릅니다.

  • 인프라를 코드로 사용합니다. CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인을 통해 코드로 인프라를 배포합니다. Azure에는 모든 Azure 리소스에 대해 미리 작성된 Bicep, ARM(JSON) 및 Terraform 템플릿이 있습니다 .

  • CI/CD(연속 통합/지속적인 배포) 파이프라인을 사용합니다. CI/CD 파이프라인을 사용하여 소스 제어에서 테스트, 스테이징 및 프로덕션과 같은 다양한 환경으로 코드를 배포합니다. GitHub 프로젝트용 Azure DevOps 또는 GitHub Actions를 사용하는 경우 Azure Pipelines를 활용합니다.

  • 단위 테스트를 통합합니다. App Services에 배포하기 전에 파이프라인 내의 모든 단위 테스트 실행 및 전달 우선 순위를 지정합니다. SonarQube와 같은 코드 품질 및 검사 도구를 통합하여 포괄적인 테스트 범위를 달성합니다.

  • 모의 프레임워크를 채택합니다. 외부 엔드포인트를 포함하는 테스트의 경우 모의 프레임워크를 활용합니다. 이러한 프레임워크를 사용하면 시뮬레이션된 엔드포인트를 만들 수 있습니다. 실제 외부 엔드포인트를 구성하고 환경 전체에서 균일한 테스트 조건을 보장할 필요가 없습니다.

  • 보안 검사를 수행합니다. SAST(정적 애플리케이션 보안 테스트)를 사용하여 소스 코드에서 보안 결함 및 코딩 오류를 찾습니다. 또한 SCA(소프트웨어 컴퍼지션 분석)를 수행하여 타사 라이브러리 및 구성 요소에서 보안 위험을 검사합니다. 이러한 분석을 위한 도구는 GitHub와 Azure DevOps 모두에 쉽게 통합됩니다.

모니터링 구성

애플리케이션 및 플랫폼 모니터링을 구현하여 웹앱의 운영 우수성과 성능 효율성을 향상시킵니다. 모니터링을 구현하려면 다음 권장 사항을 따릅니다.

  • 애플리케이션 원격 분석을 수집합니다. Azure 애플리케이션 Insights에서 자동 침입을 사용하여 코드 변경 없이 요청 처리량, 평균 요청 기간, 오류 및 종속성 모니터링과 같은 애플리케이션 원격 분석을 수집합니다. Spring Boot는 Java JVM(가상 머신), CPU, Tomcat 등과 같은 Application Insights에 여러 핵심 메트릭을 등록합니다. Application Insights는 Log4j 및 Logback과 같은 로깅 프레임워크에서 자동으로 수집합니다. 예를 들어 참조 구현은 App Service app_settings 구성의 일부로 Terraform을 통해 사용하도록 설정된 Application Insights를 사용합니다. (다음 코드 참조).

    app_settings = {
    APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
    ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
    ...
}

    자세한 내용은 다음을 참조하세요.

  • 사용자 지정 애플리케이션 메트릭을 만듭니다. Application Insights SDK를 추가하고 해당 API를 사용하여 사용자 지정 애플리케이션 원격 분석을 캡처하는 코드 기반 계측을 구현합니다.

  • 플랫폼을 모니터링합니다. 지원되는 모든 서비스에 대한 진단을 사용하도록 설정하고 상관 관계를 위해 애플리케이션 로그와 동일한 대상으로 진단을 보냅니다. Azure 서비스는 플랫폼 로그를 자동으로 만들지만 진단을 사용하도록 설정할 때만 저장합니다. 진단을 지원하는 각 서비스에 대한 진단 설정을 사용하도록 설정합니다. 참조 구현에서는 Terraform을 사용하여 지원되는 모든 서비스에서 Azure 진단을 사용하도록 설정합니다. 다음 Terraform 코드는 App Service에 대한 진단 설정을 구성합니다.

    # Configure Diagnostic Settings for App Service
resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
  name                           = "app-service-diagnostic-settings"
  target_resource_id             = azurerm_linux_web_app.application.id
  log_analytics_workspace_id     = var.log_analytics_workspace_id
  #log_analytics_destination_type = "AzureDiagnostics"

  enabled_log {
    category_group = "allLogs"

  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}

참조 구현 배포

참조 구현은 개발자가 온-프레미스 Java 애플리케이션에서 Azure로의 시뮬레이트된 마이그레이션을 안내하며 초기 채택 단계에서 필요한 변경 사항을 강조 표시합니다. 이 예제에서는 가상 회사 Contoso Fiber에 CAMS(고객 계정 관리 시스템) 웹앱 애플리케이션을 사용합니다. Contoso Fiber는 웹 애플리케이션에 대해 다음 목표를 설정합니다.

  • 저렴한 고가용성 코드 변경 구현
  • 99.9%의 SLO(서비스 수준 목표) 달성
  • DevOps 사례 채택
  • 비용 최적화 환경 만들기
  • 안정성 및 보안 향상

Contoso Fiber는 온-프레미스 인프라가 이러한 목표를 달성하기 위한 비용 효율적인 솔루션이 아니라고 판단했습니다. 그들은 CAMS 웹 애플리케이션을 Azure로 마이그레이션하는 것이 즉각적이고 미래의 목표를 달성하는 가장 비용 효율적인 방법이라고 결정했습니다. 다음 아키텍처는 Contoso Fiber의 Reliable Web App 패턴 구현의 끝 상태를 나타냅니다.

참조 구현의 아키텍처를 보여 주는 다이어그램그림 4. 참조 구현의 아키텍처입니다. 이 아키텍처의 Visio 파일을 다운로드합니다.

참조 구현