이 문서에서는 신뢰할 수 있는 웹앱 패턴을 구현하기 위한 지침을 제공합니다. 이 패턴은 클라우드 마이그레이션을 위해 웹앱을 다시 배치하는 방법을 설명합니다. Azure Well-Architected Framework의 원칙에 부합하는 규범적 아키텍처, 코드 및 구성 지침을 제공합니다.
Java용 Reliable Web App 패턴을 사용하는 이유는 무엇인가요?
신뢰할 수 있는 웹앱 패턴은 웹앱을 클라우드로 마이그레이션할 때 웹앱을 다시 배치하는 방법을 정의하는 일련의 원칙 및 구현 기술입니다. 클라우드에서 성공을 보장하기 위해 최소한의 코드 업데이트를 강조합니다. 이 지침에서는 전체에서 일관된 예제로 참조 구현을 사용합니다. 가상의 회사 Contoso Fiber의 재편성 과정을 따라 사용자 고유의 마이그레이션을 위한 비즈니스 컨텍스트를 제공합니다. Contoso Fiber는 Java용 Reliable Web App 패턴을 구현하기 전에 Spring Boot 프레임워크를 사용하여 빌드된 모놀리식 온-프레미스 CAMS(고객 계정 관리 시스템)를 운영합니다.
팁 (조언)
신뢰할 수 있는 웹앱 패턴의 참조 구현 (샘플)은 완료된 구현의 최종 상태를 나타냅니다. 이 프로덕션 수준 웹앱에는 이 문서에 설명된 모든 코드, 아키텍처 및 구성 업데이트가 포함되어 있습니다. 참조 구현을 배포하고 사용하여 신뢰할 수 있는 웹앱 패턴의 고유한 구현을 안내합니다.
신뢰할 수 있는 웹앱 패턴을 구현하는 방법
이 문서의 다음 섹션에서 필요한 특정 지침을 찾습니다.
비즈니스 컨텍스트: 이 지침을 비즈니스 컨텍스트에 맞게 조정하고, 재편성 결정을 유도하는 즉각적이고 장기적인 목표를 정의하는 방법을 알아봅니다.
아키텍처 지침: 올바른 클라우드 서비스를 선택하고 비즈니스 요구 사항을 충족하는 아키텍처를 디자인합니다.
코드 지침: 클라우드에서 웹앱의 안정성과 성능 효율성을 개선하기 위해 재시도, 회로 차단기 및 Cache-Aside 디자인 패턴을 구현합니다.
구성 지침: 인증 및 권한 부여, 관리 ID, 권한 있는 환경, 코드로서의 인프라(IaC) 및 모니터링을 구성합니다.
비즈니스 컨텍스트
웹앱을 다시 배치하는 첫 번째 단계는 비즈니스 목표를 정의하는 것입니다. 웹 애플리케이션에 대한 향후 목표와 함께 SLO(서비스 수준 목표) 및 비용 최적화 목표와 같은 즉각적인 목표를 설정합니다. 이러한 목표는 클라우드 서비스 선택 및 클라우드에서 애플리케이션의 아키텍처에 영향을 줍니다. 99.9% 작동 시간과 같이 웹앱에 대한 대상 SLO를 정의합니다. 웹앱의 가용성에 영향을 주는 모든 서비스에 대한 복합 SLA(서비스 수준 계약) 를 계산합니다.
Contoso Fiber는 온-프레미스 CAMS 웹앱을 확장하여 다른 지역에 도달하려고 합니다. 웹앱에 대한 증가하는 수요를 충족하기 위해 회사는 다음 목표를 설정합니다.
- 저렴한 고가의 코드 변경 내용을 적용합니다.
- 서비스 수준 목표(SLO) 99.9%에 도달하세요.
- DevOps 사례를 채택합니다.
- 비용 최적화 환경을 만듭니다.
- 안정성 및 보안을 개선합니다.
Contoso Fiber는 온-프레미스 인프라가 애플리케이션 크기를 조정하기 위한 비용 효율적인 솔루션이 아니라고 결정합니다. 이 회사는 CAMS 웹 애플리케이션을 Azure로 마이그레이션하는 것이 즉각적이고 미래의 목표를 달성하는 가장 비용 효율적인 방법이라고 결정합니다.
아키텍처 지침
신뢰할 수 있는 웹앱 패턴에는 몇 가지 필수 아키텍처 요소가 있습니다. 엔드포인트 확인을 관리하려면 DNS(도메인 이름 시스템), 악의적인 HTTP 트래픽을 차단하는 웹 애플리케이션 방화벽, 인바운드 사용자 요청을 라우팅하고 보호하는 데 도움이 되는 부하 분산 장치가 필요합니다. 애플리케이션 플랫폼은 웹앱 코드를 호스트하고 가상 네트워크의 프라이빗 엔드포인트를 통해 백 엔드 서비스를 호출합니다. 애플리케이션 성능 모니터링 도구는 웹앱을 이해하는 데 도움이 되는 메트릭 및 로그를 캡처합니다.
아키텍처 디자인
RTO(복구 시간 목표) 및 RPO(복구 지점 목표)와 같은 복구 메트릭을 지원하도록 인프라를 디자인합니다. RTO는 가용성에 영향을 주며, 반드시 SLO를 지원해야 합니다. RPO를 결정하고 RPO를 충족하도록 데이터 중복성을 구성합니다.
인프라 안정성을 선택합니다. 가용성 요구 사항을 충족하는 데 필요한 가용성 영역 및 지역 수를 결정합니다. 복합 SLA가 SLO를 충족할 때까지 가용성 영역 및 지역을 추가합니다. Reliable Web App 패턴은 활성-활성 또는 활성-수동 구성에 대해 여러 지역을 지원합니다. 예를 들어 참조 구현은 활성-수동 구성을 사용하여 99.9%SLO를 충족합니다.
다중 지역 웹앱의 경우, 비즈니스 요구 사항에 따라 활성-활성 또는 활성-수동 구성을 지원하기 위해 트래픽을 두 번째 지역으로 라우팅하여 로드 밸런서를 설정합니다. 두 지역에는 동일한 서비스가 필요합니다. 그러나 한 지역에는 지역을 연결하는 허브 가상 네트워크가 있습니다. 허브 및 스포크 네트워크 토폴로지 채택을 통해 네트워크 방화벽과 같은 리소스를 중앙 집중화하고 공유합니다. VM(가상 머신)이 있는 경우 허브 가상 네트워크에 요새 호스트를 추가하여 보안 강화를 통해 관리합니다.
네트워크 토폴로지 선택 웹 및 네트워킹 요구 사항에 적합한 네트워크 토폴로지 선택 여러 가상 네트워크를 사용하려는 경우 허브 및 스포크 네트워크 토폴로지를 사용합니다. 온-프레미스 및 가상 네트워크에 대한 비용, 관리 및 보안 이점 및 하이브리드 연결 옵션을 제공합니다.
올바른 Azure 서비스 선택
웹앱을 클라우드로 이동하는 경우 비즈니스 요구 사항을 충족하고 온-프레미스 웹앱의 기능에 맞는 Azure 서비스를 선택합니다. 이 정렬은 재플랫폼 작업을 최소화하는 데 도움이 됩니다. 예를 들어 동일한 데이터베이스 엔진을 유지하고 기존 미들웨어 및 프레임워크를 지원할 수 있는 서비스를 사용합니다.
마이그레이션 전에 Contoso Fiber의 CAMS 웹앱은 온-프레미스 모놀리식 Java 애플리케이션입니다. PostgreSQL 데이터베이스가 있는 Spring Boot 앱입니다. 웹앱은 직원을 위한 LOB(기간 업무) 지원 앱입니다. 고객 지원 사례를 관리하는 데 사용합니다. 앱은 확장성 및 기능 배포와 관련하여 일반적인 문제를 경험합니다. 이 시작점은 비즈니스 목표 및 SLO와 함께 서비스 선택에 영향을 줍니다.
다음 목록에서는 웹앱에 적합한 Azure 서비스를 선택하는 지침을 제공하고 Contoso Fiber가 특정 서비스를 선택하는 이유를 설명합니다.
애플리케이션 플랫폼: 애플리케이션 플랫폼으로 Azure App Service 를 사용합니다. Contoso Fiber는 다음과 같은 이유로 App Service를 사용합니다.
자연스러운 진행: Contoso Fiber는 온-프레미스 서버에 Spring Boot JAR 파일을 배포하고 해당 배포 모델에 대한 재시도량을 최소화하려고 합니다. App Service는 Spring Boot 앱을 실행하는 강력한 지원을 제공하므로 적합한 옵션입니다. 또한 Azure Container Apps는 이 애플리케이션에 적합한 옵션입니다. 자세한 내용은 Container Apps 개요 및 컨테이너 앱의 Java 개요를 참조하세요.
높은 SLA: App Service는 프로덕션 요구 사항을 충족하는 높은 SLA를 제공합니다.
관리 오버헤드 감소: App Service는 관리되는 호스팅 솔루션입니다.
컨테이너화 기능: App Service는 Azure Container Registry와 같은 프라이빗 컨테이너 이미지 레지스트리와 통합됩니다. Contoso Fiber는 이러한 레지스트리를 사용하여 나중에 웹앱을 컨테이너화할 수 있습니다.
자동 크기 조정: 웹앱은 사용자 트래픽에 따라 신속하게 스케일 업, 스케일 다운, 규모 확장 및 스케일 아웃할 수 있습니다.
ID 관리:MICROSOFT Entra ID 를 ID 및 액세스 관리 솔루션으로 사용합니다. Contoso Fiber는 다음과 같은 이유로 Microsoft Entra ID를 사용합니다.
인증 및 권한 부여: 애플리케이션은 콜 센터 직원을 인증하고 권한을 부여해야 합니다.
확장성: Microsoft Entra ID는 더 큰 시나리오를 지원하기 위해 확장됩니다.
사용자 ID 제어: 콜 센터 직원은 기존 엔터프라이즈 ID를 사용할 수 있습니다.
권한 부여 프로토콜 지원: Microsoft Entra ID는 관리 ID에 대해 OAuth 2.0을 지원합니다.
데이터베이스: 동일한 데이터베이스 엔진을 유지할 수 있는 서비스를 사용합니다. 데이터 저장소 의사 결정 트리를 사용하여 선택을 안내합니다. Contoso Fiber는 다음과 같은 이유로 Azure Database for PostgreSQL 유연한 서버 배포 모델을 사용합니다.
신뢰도: 유연한 서버 배포 모델은 여러 가용성 영역에서 영역 중복 고가용성을 지원합니다. 이 구성은 동일한 Azure 지역 내의 서로 다른 가용성 영역에 웜 스탠바이 서버를 유지합니다. 구성은 대기 서버에 데이터를 동기적으로 복제합니다.
지역 간 복제: Azure Database for PostgreSQL은 데이터를 다른 지역의 읽기 전용 복제본 데이터베이스에 비동기적으로 복제하는 읽기 복제본 기능을 제공합니다.
성능: Azure Database for PostgreSQL은 실제 사용 데이터를 통해 예측 가능한 성능과 지능형 튜닝을 제공하여 데이터베이스 성능을 향상시킵니다.
관리 오버헤드 감소: 이 관리되는 Azure 서비스는 관리 의무를 줄입니다.
마이그레이션 지원: 온-프레미스 단일 서버 PostgreSQL 데이터베이스에서 데이터베이스 마이그레이션을 지원합니다. Contoso Fiber는 마이그레이션 도구를 사용하여 마이그레이션 프로세스를 간소화할 수 있습니다.
온-프레미스 구성과의 일관성: Contoso Fiber에서 현재 사용하는 버전을 포함하여 PostgreSQL의 다양한 커뮤니티 버전을 지원합니다.
복구: 유연한 서버 배포는 자동으로 서버 백업을 만들고 동일한 지역 내의 ZRS(영역 중복 스토리지)에 저장합니다. Contoso Fiber는 백업 보존 기간 내의 특정 시점으로 데이터베이스를 복원할 수 있습니다. 백업 및 복원 기능은 온-프레미스 환경에 비해 더 나은 RPO를 만듭니다.
애플리케이션 성능 모니터링:Application Insights를 사용하여 애플리케이션에서 원격 분석을 분석합니다. Contoso Fiber는 다음과 같은 이유로 Application Insights를 사용합니다.
Azure Monitor와 통합: Azure Monitor와 최상의 통합을 제공합니다.
변칙 검색: 성능 변칙을 자동으로 검색합니다.
문제 해결: 실행 중인 앱에서 문제를 진단하는 데 도움이 됩니다.
모니터링: 앱에 대한 사용량 현황 데이터를 수집하고 사용자 지정 이벤트를 추적합니다.
가시성 격차: 온-프레미스 솔루션에는 애플리케이션 성능 모니터링 솔루션이 없습니다. Application Insights는 애플리케이션 플랫폼 및 코드와 쉽게 통합할 수 있습니다.
캐시: 웹앱 아키텍처에 캐시를 추가할지 여부를 선택합니다. Azure Managed Redis 는 기본 Azure 캐시 솔루션입니다. Redis 소프트웨어를 기반으로 하는 관리되는 메모리 내 데이터 저장소입니다. Contoso Fiber는 다음과 같은 이유로 Azure Managed Redis를 추가합니다.
속도 및 볼륨: 자주 액세스하고 느리게 변화하는 데이터에 대해 높은 데이터 처리량과 짧은 대기 시간 읽기를 제공합니다.
다양한 지원 가능성: 웹앱의 모든 인스턴스에서 사용할 수 있는 통합 캐시 위치입니다.
외부 데이터 저장소: 온-프레미스 애플리케이션 서버는 VM 로컬 캐싱을 사용합니다. 이 설정은 자주 액세스하는 데이터를 오프로드하지 않으며 부실 데이터를 무효화할 수 없습니다.
논스틱 세션: 캐시를 사용하면 웹앱이 세션 상태를 외부화하고 비스틱 세션을 사용할 수 있습니다. 온-프레미스에서 실행되는 대부분의 Java 웹앱은 메모리 내 클라이언트 쪽 캐싱을 사용합니다. 이 방법은 잘 확장되지 않으며 호스트의 메모리 공간을 증가합니다. Azure Managed Redis는 애플리케이션의 확장성 및 성능을 개선하기 위해 관리되는 확장성 있는 캐시 서비스를 제공합니다. Contoso Fiber는 Spring Cache를 캐시 추상화 프레임워크로 사용했으며 Ehcache 공급자에서 Redis 공급자로 전환하려면 최소한의 구성 변경만 필요했습니다.
부하 분산 장치: PaaS(Platform as a Service) 솔루션을 사용하는 웹 애플리케이션은 웹앱 아키텍처 및 요구 사항에 따라 Azure Front Door, Azure Application Gateway 또는 둘 다를 사용해야 합니다. 부하 분산 장치 의사 결정 트리를 사용하여 올바른 부하 분산 장치를 선택합니다. Contoso 파이버에는 여러 지역에서 트래픽을 라우팅할 수 있는 계층 7 부하 분산 장치와 99.9%SLO를 충족하는 다중 리전 웹앱이 필요합니다. 이 회사는 다음과 같은 이유로 Azure Front Door 를 사용합니다.
전역 부하 분산: 이 계층 7 부하 분산 장치는 여러 지역에 걸쳐 트래픽을 라우팅할 수 있습니다.
웹 애플리케이션 방화벽: 기본적으로 Azure Web Application Firewall과 통합됩니다.
라우팅 유연성: 이를 통해 애플리케이션 팀은 애플리케이션의 향후 변경 내용을 지원하도록 수신 요구를 구성할 수 있습니다.
트래픽 가속: anycast 라우팅을 사용하여 가장 가까운 Azure 현재 지점에 도달하고 웹앱에 대한 가장 빠른 경로를 찾습니다.
사용자 지정 도메인: 유연한 도메인 유효성 검사를 통해 사용자 지정 도메인 이름을 지원합니다.
상태 프로브: 애플리케이션에는 지능형 상태 프로브 모니터링이 필요합니다. Azure Front Door는 프로브의 응답을 사용하여 클라이언트 요청을 라우팅하는 데 가장 적합한 원본을 결정합니다.
모니터링 지원: Azure Front Door는 Azure Front Door 및 보안 패턴 모두에 대한 올인원 대시보드가 포함된 기본 제공 보고서를 지원합니다. Azure Monitor와 통합되는 경고를 제공합니다. Azure Front Door를 사용하면 애플리케이션에서 각 요청 및 실패한 상태 프로브를 기록할 수 있습니다.
DDoS(분산 서비스 거부) 보호: 계층 3 및 계층 4에서 기본 제공 DDoS 보호 기능이 있습니다.
콘텐츠 배달 네트워크: 콘텐츠 배달 네트워크를 사용하도록 Contoso 파이버를 배치합니다. 콘텐츠 배달 네트워크는 사이트 가속을 제공합니다.
웹 애플리케이션 방화벽:Azure Web Application Firewall 을 사용하여 일반적인 웹 악용 및 취약성으로부터 중앙 집중식 보호를 제공합니다. Contoso Fiber는 다음과 같은 이유로 Azure 웹 애플리케이션 방화벽을 사용합니다.
전역 보호: 성능을 유지하면서 향상된 글로벌 웹앱 보호를 제공합니다.
봇넷 보호: 팀은 봇넷과 관련된 보안 문제를 해결하기 위해 설정을 모니터링하고 구성할 수 있습니다.
온-프레미스와의 패리티: 온-프레미스 솔루션은 IT에서 관리하는 웹 애플리케이션 방화벽 뒤에서 실행됩니다.
사용 편의성: Azure Web Application Firewall은 Azure Front Door와 통합됩니다.
비밀 관리자: Azure에서 관리할 비밀이 있는 경우 Azure Key Vault 를 사용합니다. Contoso Fiber는 다음과 같은 이유로 Key Vault를 사용합니다.
암호화: 저장된 데이터와 전송 중인 데이터의 암호화를 지원합니다.
관리 ID 지원: 애플리케이션 서비스는 관리 ID를 사용하여 비밀 저장소에 액세스할 수 있습니다.
모니터링 및 로깅: Key Vault는 감사 액세스를 용이하게 하고 저장된 비밀이 변경될 때 경고를 생성합니다.
통합: Key Vault는 Azure 구성 저장소(Azure App Configuration) 및 웹 호스팅 플랫폼(App Service)과 네이티브 통합을 제공합니다.
엔드포인트 보안:Azure Private Link 를 사용하여 가상 네트워크의 프라이빗 엔드포인트를 통해 PaaS 솔루션에 액세스합니다. 가상 네트워크와 서비스 간의 트래픽은 Microsoft 백본 네트워크를 통해 이동합니다. Contoso 파이버는 다음과 같은 이유로 Private Link를 사용합니다.
향상된 보안 통신: 이를 통해 애플리케이션은 Azure 플랫폼의 서비스에 비공개로 액세스할 수 있으며 데이터 누출로부터 보호하기 위해 데이터 저장소의 네트워크 공간을 줄일 수 있습니다.
최소한의 노력: 프라이빗 엔드포인트는 웹앱에서 사용하는 웹앱 플랫폼 및 데이터베이스 플랫폼을 지원합니다. 두 플랫폼 모두 기존 온-프레미스 구성을 미러링하므로 최소한의 변경이 필요합니다.
네트워크 보안:Azure Firewall 을 사용하여 네트워크 수준에서 인바운드 및 아웃바운드 트래픽을 제어합니다. Azure Bastion을 사용하여 RDP/SSH(원격 데스크톱 프로토콜/보안 셸) 포트를 노출하지 않고 보안이 강화된 VM에 연결합니다. Contoso Fiber는 허브 및 스포크 네트워크 토폴로지 및 공유 네트워크 보안 서비스를 허브에 배치합니다. Azure Firewall은 스포크에서 아웃바운드 트래픽을 검사하여 네트워크 보안을 강화합니다. 이 회사는 DevOps 서브넷의 점프 호스트에서 향상된 보안 배포를 위해 Azure Bastion을 사용합니다.
코드 지침
웹앱을 클라우드로 성공적으로 이동하려면 다시 시도, 회로 차단기 및 Cache-Aside 패턴을 사용하여 웹앱 코드를 업데이트해야 합니다.
다음 디자인 패턴은 하나 이상의 Well-Architected Framework 핵심 요소에 매핑되는 워크로드 이점을 제공합니다.
다시 시도 패턴은 간헐적으로 실패할 수 있는 작업을 다시 시도하여 일시적인 오류를 처리합니다. 다른 Azure 서비스에 대한 모든 아웃바운드 호출에서 이 패턴을 구현합니다.
회로 차단기 패턴은 애플리케이션이 일시적이지 않은 작업을 다시 시도하는 것을 방지합니다. 다른 Azure 서비스에 대한 모든 아웃바운드 호출에서 이 패턴을 구현합니다.
Cache-Aside 패턴은 요청 시 데이터를 데이터 저장소의 캐시로 로드합니다. 데이터베이스에 대한 요청에 대해 이 패턴을 구현합니다.
| 디자인 패턴 | 안정성(RE) | 보안(SE) | CO(비용 최적화) | 운영 우수성(OE) | PE(성능 효율성) | WAF 원칙 지원 |
|---|---|---|---|---|---|---|
| 다시 시도 패턴 | ✔ | 재:07 | ||||
| 회로 차단기 패턴 | ✔ | ✔ |
RE:03 재:07 PE:07 PE:11 |
|||
| Cache-Aside 패턴 | ✔ | ✔ |
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 Cloud 회로 차단기 및 Resilience4j를 사용하여 회로 차단기 패턴을 구현합니다. 참조 구현은 회로 차단기 특성으로 메서드를 데코레이팅하여 회로 차단기 패턴을 적용합니다.
Cache-Aside 패턴 구현
웹앱에 Cache-Aside 패턴을 추가하여 메모리 내 데이터 관리를 개선합니다. 이 패턴은 애플리케이션에 데이터 요청을 처리하고 캐시와 영구 스토리지(예: 데이터베이스) 간의 일관성을 보장하는 책임을 할당합니다. 응답 시간을 단축하고, 처리량을 향상시키며, 더 많은 크기 조정의 필요성을 줄입니다. 또한 기본 데이터 저장소의 부하를 줄여 안정성 및 비용 최적화를 향상시킵니다. Cache-Aside 패턴을 구현하려면 다음 권장 사항을 따릅니다.
캐시를 사용하도록 애플리케이션을 구성합니다. 캐싱을 활성화하려면
pom.xml파일에spring-boot-starter-cache패키지를 종속성으로 추가하세요. 이 패키지는 Redis 캐시에 대한 기본 구성을 제공합니다.필요한 데이터를 캐시합니다. 필요한 데이터에 Cache-Aside 패턴을 적용하여 효율성을 향상시킵니다. Azure Monitor를 사용하여 데이터베이스의 CPU, 메모리 및 스토리지를 추적합니다. 이러한 메트릭은 Cache-Aside 패턴을 적용한 후 더 작은 데이터베이스 SKU를 사용할 수 있는지 여부를 결정하는 데 도움이 됩니다. 코드에서 특정 데이터를 캐시하려면 주석을
@Cacheable추가합니다. 이 주석은 결과를 캐시해야 하는 메서드를 Spring에 지정합니다.캐시 데이터를 최신 상태로 유지합니다. 최신 데이터베이스 변경 내용과 동기화하도록 일반 캐시 업데이트를 예약합니다. 데이터 변동성을 사용하고 사용자는 최적의 새로 고침 속도를 결정해야 합니다. 이렇게 하면 애플리케이션이 Cache-Aside 패턴을 사용하여 신속한 액세스 및 현재 정보를 제공합니다. 기본 캐시 설정은 웹 애플리케이션에 적합하지 않을 수 있습니다. 파일 또는 환경 변수에서
application.properties이러한 설정을 사용자 지정할 수 있습니다. 예를 들어 값(밀리초 단위로 표시됨)을 수정spring.cache.redis.time-to-live하여 데이터가 제거되기 전에 캐시에 남아 있는 기간을 제어할 수 있습니다.데이터 일관성을 보장합니다. 데이터베이스 쓰기 작업 직후 캐시를 업데이트하는 메커니즘을 구현합니다. 이벤트 기반 업데이트 또는 전용 데이터 관리 클래스를 사용하여 캐시 일관성을 보장합니다. 캐시를 데이터베이스 수정과 일관되게 동기화하는 것은 Cache-Aside 패턴의 핵심입니다.
구성 지침
다음 섹션에서는 구성 업데이트를 구현하는 방법에 대한 지침을 제공합니다. 각 섹션은 Well-Architected Framework의 하나 이상의 기둥에 맞춥니다.
| 구성 / 설정 | 안정성(RE) | 보안(SE) | CO(비용 최적화) | 운영 우수성(OE) | PE(성능 효율성) | WAF 원칙 지원 |
|---|---|---|---|---|---|---|
| 사용자 인증 및 권한 부여 구성 | ✔ | ✔ |
SE:05 OE:10 |
|||
| 관리 ID 구현 | ✔ | ✔ |
SE:05 OE:10 |
|||
| 환경 권한 부여 | ✔ |
CO:05 CO:06 |
||||
| 자동 크기 조정 구현 | ✔ | ✔ | ✔ |
재: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](/azure/developer/java/spring-framework/spring-boot-starter-for-entra-developer-guide는 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에서 앱별 역할의 예로는 계정 관리자, Level One(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는 ID가 액세스할 수 있는 Azure 리소스, 해당 리소스로 수행할 수 있는 작업 및 액세스할 수 있는 영역을 정의합니다.
영구적으로 높은 권한을 피하십시오. Microsoft Entra PIM(Privileged Identity Management)을 사용하여 권한 있는 작업에 JIT(Just-In-Time) 액세스 권한을 부여합니다. 예를 들어 개발자는 데이터베이스를 만들고 삭제하고, 테이블 스키마를 수정하고, 사용자 권한을 변경하려면 관리자 수준의 액세스 권한이 필요한 경우가 많습니다. JIT 액세스를 사용하는 경우 사용자 ID는 권한 있는 작업을 수행할 수 있는 임시 권한을 받습니다.
관리 ID 구현
이를 지원하는 모든 Azure 서비스에 관리 ID 를 사용합니다. 관리 ID를 사용하면 자격 증명을 관리할 필요 없이 Azure 리소스, 특히 워크로드 ID를 사용하여 다른 Azure 서비스에 인증하고 상호 작용할 수 있습니다. 마이그레이션을 간소화하기 위해 하이브리드 및 레거시 시스템에 온-프레미스 인증 솔루션을 계속 사용할 수 있지만 가능한 한 빨리 관리 ID로 전환해야 합니다. 관리 ID를 구현하려면 다음 권장 사항을 따릅니다.
올바른 유형의 관리 ID를 선택합니다. 동일한 권한 집합이 필요한 둘 이상의 Azure 리소스가 있는 경우 사용자 할당 관리 ID를 선호합니다. 이 방법은 각 리소스에 대해 시스템 할당 관리 ID를 만들고 모든 리소스에 동일한 권한을 할당하는 것보다 더 효율적입니다. 그렇지 않으면 시스템 할당 관리 ID를 사용합니다.
최소 권한을 구성합니다. Azure RBAC를 사용하여 데이터베이스의 CRUD(만들기, 읽기, 업데이트 및 삭제) 작업 또는 비밀 액세스와 같은 작업에 중요한 권한만 부여합니다. 워크로드 ID 권한은 영구적이므로 워크로드 ID에 JIT 또는 단기 권한을 제공할 수 없습니다. Azure RBAC가 특정 시나리오를 다루지 않는 경우 Azure 서비스 수준 액세스 정책을 사용하여 Azure RBAC를 보완합니다.
나머지 비밀에 대한 보안을 제공합니다. Key Vault에 나머지 비밀을 저장합니다. 각 HTTP 요청 중에 대신 애플리케이션 시작 시 Key Vault에서 비밀을 로드합니다. HTTP 요청 내의 고주파 액세스는 Key Vault 트랜잭션 제한을 초과할 수 있습니다. App Configuration에 애플리케이션 구성을 저장합니다.
환경 권한 부여
각 환경의 요구 사항을 충족하는 Azure 서비스의 SKU(성능 계층)를 초과하지 않고 사용합니다. 환경을 최적화하려면 다음 작업을 수행합니다.
비용을 예측합니다. Azure 가격 계산기를 사용하여 각 환경의 비용을 예측합니다.
프로덕션 환경을 최적화합니다. 프로덕션 환경에는 프로덕션에 필요한 SLA, 기능 및 규모를 충족하는 SKU가 필요합니다. 리소스 사용량을 지속적으로 모니터링하고 실제 성능 요구 사항에 맞게 SKU를 조정합니다.
사전 프로덕션 환경을 최적화합니다.사전 프로덕션 환경에서는 저렴한 리소스를 사용하고 개발/테스트 가격 책정을 위한 Azure 플랜과 같은 할인을 활용해야 합니다. 이러한 환경에서는 필요하지 않은 서비스를 사용하지 않도록 설정합니다. 또한 사전 프로덕션 환경이 프로덕션 환경과 충분히 유사하여 위험이 발생하지 않도록 합니다. 불필요한 비용을 발생시키지 않고 테스트가 효과적으로 유지되도록 이 균형을 유지합니다.
IaC를 사용하여 SKU를 정의합니다. IaC를 구현하여 환경에 따라 올바른 SKU를 동적으로 선택하고 배포합니다. 이 방법은 일관성을 향상시키고 관리를 간소화합니다.
예를 들어 참조 구현에는 배포할 SKU를 지정하는 선택적 매개 변수가 있습니다. 환경 매개 변수는 Terraform 템플릿이 개발 SKU를 배포해야 한다고 지정합니다.
azd env set APP_ENVIRONMENT prod
자동 크기 조정 구현
자동 크기 조정은 웹앱이 복원력 있고 응답성이 뛰어나며 동적 워크로드를 효율적으로 처리할 수 있도록 하는 데 도움이 됩니다. 자동 크기 조정을 구현하려면 다음 권장 사항을 따릅니다.
스케일 아웃을 자동화합니다.Azure 자동 크기 조정 을 사용하여 프로덕션 환경에서 수평 크기 조정을 자동화합니다. 애플리케이션이 다양한 부하를 처리할 수 있도록 주요 성능 메트릭에 따라 스케일 아웃되도록 자동 크기 조정 규칙을 구성합니다.
크기 조정 트리거를 세분화합니다. 애플리케이션의 크기 조정 요구 사항에 익숙하지 않은 경우 CPU 사용률을 초기 크기 조정 트리거로 사용합니다. RAM, 네트워크 처리량 및 디스크 입력/출력(I/O)과 같은 다른 메트릭을 포함하도록 크기 조정 트리거를 구체화합니다. 목표는 성능 향상을 위해 웹 애플리케이션의 동작과 일치하도록 하는 것입니다.
스케일 아웃 버퍼를 제공합니다. 최대 용량에 도달하기 전에 크기 조정 임계값을 설정하여 크기 조정을 시작합니다. 예를 들어 100%도달할 때까지 기다리지 않고 85% CPU 사용률에서 수행되도록 크기 조정을 구성합니다. 이 사전 예방적 접근 방식은 성능을 유지하고 잠재적인 병목 상태를 방지하는 데 도움이 됩니다.
리소스 배포 자동화
자동화를 사용하여 모든 환경에서 Azure 리소스 및 코드를 배포하고 업데이트합니다. 다음 권장 사항을 따릅니다.
IaC를 사용합니다. CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인을 사용하여 IaC 를 배포합니다. Azure는 모든 Azure 리소스에 대해 미리 빌드된 Bicep 템플릿, ARM 템플릿(Azure Resource Manager 템플릿) JSON 및 Terraform 템플릿을 제공합니다.
CI/CD 파이프라인을 사용합니다. CI/CD 파이프라인을 사용하여 소스 제어에서 테스트, 스테이징 및 프로덕션과 같은 다양한 환경으로 코드를 배포합니다. Azure DevOps로 작업하는 경우 Azure Pipelines를 사용합니다. GitHub 프로젝트에 GitHub Actions를 사용합니다.
단위 테스트를 통합합니다. App Service에 배포하기 전에 파이프라인 내의 모든 단위 테스트 실행 및 유효성 검사 우선 순위를 지정합니다. SonarQube와 같은 코드 품질 및 검사 도구를 통합하여 포괄적인 테스트 범위를 달성합니다.
모의 프레임워크를 채택합니다. 외부 엔드포인트를 포함하는 테스트의 경우 모의 프레임워크를 사용합니다. 이러한 프레임워크를 사용하면 시뮬레이션된 엔드포인트를 만들 수 있습니다. 실제 외부 엔드포인트를 구성하고 환경 전체에서 균일한 테스트 조건을 보장할 필요가 없습니다.
보안 검사를 수행합니다. SAST(정적 애플리케이션 보안 테스트)를 사용하여 소스 코드에서 보안 결함 및 코딩 오류를 찾습니다. SCA(소프트웨어 컴퍼지션 분석)를 수행하여 비 Microsoft 라이브러리 및 구성 요소에서 보안 위험을 검사합니다. 이러한 분석을 위한 도구를 GitHub 및 Azure DevOps에 통합합니다.
모니터링 구성
애플리케이션 및 플랫폼 모니터링을 구현하여 웹앱의 운영 우수성과 성능 효율성을 향상시킵니다. 모니터링을 구현하려면 다음 권장 사항을 따릅니다.
애플리케이션 원격 분석을 수집합니다. Application 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 코드는 앱 서비스에 대한 진단 설정을 구성합니다.
# 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 } }
참조 구현 배포
참조 구현은 Contoso Fiber가 온-프레미스 Java 애플리케이션을 Azure로 시뮬레이트한 마이그레이션을 안내합니다. 또한 초기 채택 단계에서 필요한 변경 사항을 강조 표시합니다.
다음 아키텍처는 목표에 따라 Contoso Fiber의 신뢰할 수 있는 웹앱 패턴 구현의 최종 상태를 나타냅니다.
이 아키텍처의 Visio 파일을 다운로드합니다.