.NET에 대한 신뢰할 수 있는 웹앱 패턴

Azure App Service

Azure Front Door

Azure Cache for Redis

.NET

이 문서에서는 신뢰할 수 있는 웹앱 패턴을 구현하기 위한 지침을 제공합니다. 이 패턴은 클라우드 마이그레이션을 위해 웹앱을 수정(다시 배치)하는 방법을 설명합니다. Azure Well-Architected Framework 원칙에 부합하는 규범적 아키텍처, 코드 및 구성 지침을 제공합니다.

.NET에 대한 신뢰할 수 있는 웹앱 패턴인 이유는 무엇인가요?

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

팁

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

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

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

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

비즈니스 컨텍스트

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

예를 들어 Relecloud는 긍정적인 판매 예측을 가지고 있으며 티켓 웹앱에 대한 수요 증가를 예상합니다. 이러한 요구를 충족하기 위해 웹 애플리케이션에 대한 목표를 정의했습니다.

저렴한 고가의 코드 변경 내용을 적용합니다.
99.9%SLO에 도달합니다.
DevOps 사례를 채택합니다.
비용 최적화 환경을 만듭니다.
안정성 및 보안을 개선합니다.

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

아키텍처 지침

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

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

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

아키텍처 설계

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

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

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

그림 2. 두 번째 지역 및 허브 및 스포크 토폴로지의 신뢰할 수 있는 웹앱 패턴입니다.
네트워크 토폴로지 선택 웹 및 네트워킹 요구 사항에 적합한 네트워크 토폴로지 선택 여러 가상 네트워크를 사용하려는 경우 허브 및 스포크 네트워크 토폴로지사용합니다. 온-프레미스 및 가상 네트워크에 대한 비용, 관리 및 보안 이점 및 하이브리드 연결 옵션을 제공합니다.

올바른 Azure 서비스 선택

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

예를 들어 클라우드로 이동하기 전에 Relecloud의 티켓 웹앱은 온-프레미스 모놀리식 ASP.NET 앱이었습니다. 두 가상 머신에서 실행되었으며 SQL Server 데이터베이스를 사용했습니다. 웹앱은 확장성 및 기능 배포와 관련된 일반적인 문제를 겪었습니다. 이 시작점, 비즈니스 목표 및 SLO는 서비스 선택을 이끌었습니다.

애플리케이션 플랫폼: Azure 앱 Service를 애플리케이션 플랫폼으로 사용합니다. Relecloud는 다음과 같은 이유로 App Service를 애플리케이션 플랫폼으로 선택했습니다.
- 높은 SLA(서비스 수준 계약). 99.9%프로덕션 환경 SLO를 충족하는 높은 SLA가 있습니다.
- 관리 오버헤드를 줄입니다. 크기 조정, 상태 검사 및 부하 분산을 처리하는 완전 관리형 솔루션입니다.
- .NET 지원. 애플리케이션이 작성된 .NET 버전을 지원합니다.
- 컨테이너화 기능. 웹앱은 컨테이너화 없이 클라우드에 수렴할 수 있지만 애플리케이션 플랫폼은 Azure 서비스를 변경하지 않고도 컨테이너화를 지원합니다.
- 자동 크기 조정. 웹앱은 사용자 트래픽 및 구성 설정에 따라 자동으로 스케일 인 및 스케일 아웃할 수 있습니다. 또한 플랫폼은 다양한 호스팅 요구 사항을 수용하도록 확장 또는 축소를 지원합니다.
ID 관리: ID 및 액세스 관리 솔루션으로 Microsoft Entra ID를 사용합니다. Relecloud는 다음과 같은 이유로 Microsoft Entra ID를 선택했습니다.
- 인증 및 권한 부여. 애플리케이션은 콜 센터 직원을 인증하고 권한을 부여해야 합니다.
- 확장성. Microsoft Entra ID는 더 큰 시나리오를 지원하기 위해 확장됩니다.
- 사용자 ID 컨트롤입니다. 콜 센터 직원은 기존 엔터프라이즈 ID를 사용할 수 있습니다.
- 권한 부여 프로토콜 지원. Microsoft Entra ID는 관리 ID에 대해 OAuth 2.0을 지원합니다.
데이터베이스: 동일한 데이터베이스 엔진을 유지할 수 있는 서비스를 사용합니다. 데이터 저장소 의사 결정 트리 사용하여 선택을 안내합니다. Relecloud의 웹앱은 SQL Server 온-프레미스를 사용했습니다. 기존 데이터베이스 스키마, 저장 프로시저 및 함수를 사용하려고 했습니다. 여러 SQL 제품은 Azure에서 사용할 수 있지만 Relecloud는 다음과 같은 이유로 Azure SQL Database를 선택했습니다.
- 신뢰도. 범용 계층은 높은 SLA 및 다중 지역 중복성을 제공합니다. 높은 사용자 부하를 지원할 수 있습니다.
- 관리 오버헤드를 줄입니다. SQL Database는 관리되는 SQL 데이터베이스 인스턴스를 제공합니다.
- 마이그레이션 지원. 온-프레미스 SQL Server에서 데이터베이스 마이그레이션을 지원합니다.
- 온-프레미스 구성과의 일관성. 기존 저장 프로시저, 함수 및 뷰를 지원합니다.
- 복구. 백업 및 지정 시간 복원을 지원합니다.
- 전문 지식과 최소한의 재작업. SQL Database를 사용하면 Relecloud가 기존 전문 지식을 활용할 수 있으며 채택하려면 최소한의 작업이 필요합니다.
애플리케이션 성능 모니터링:Application Insights 사용하여 애플리케이션에 대한 원격 분석을 분석합니다. Relecloud는 다음과 같은 이유로 Application Insights를 사용하도록 선택했습니다.
- Azure Monitor와 통합합니다. Azure Monitor와 최상의 통합을 제공합니다.
- 변칙 검색. 성능 변칙을 자동으로 검색합니다.
- 문제 해결. 실행 중인 앱에서 문제를 진단하는 데 도움이 됩니다.
- 모니터링. 사용자가 앱을 사용하는 방법에 대한 정보를 수집하여 사용자 지정 이벤트를 쉽게 추적할 수 있습니다.
- 표시 유형 간격입니다. 온-프레미스 솔루션에는 애플리케이션 성능 모니터링 솔루션이 없습니다. Application Insights는 애플리케이션 플랫폼 및 코드와 쉽게 통합할 수 있습니다.
캐시: 웹앱 아키텍처에 캐시를 추가할지 여부를 선택합니다. Azure Cache for Redis 기본 Azure 캐시 솔루션입니다. Redis 소프트웨어를 기반으로 하는 관리되는 메모리 내 데이터 저장소입니다. Relecloud의 웹앱 로드는 콘서트 및 장소 세부 정보를 보는 쪽으로 크게 기울어져 있습니다. Relecloud는 다음과 같은 이유로 Azure Cache for Redis를 추가했습니다.
- 관리 오버헤드를 줄입니다. 완전 관리형 서비스입니다.
- 속도 및 볼륨. 일반적으로 액세스되고 느리게 변화하는 데이터에 대한 높은 데이터 처리량과 짧은 대기 시간 읽기가 있습니다.
- 다양한 지원 가능성. 웹앱의 모든 인스턴스에서 사용할 통합 캐시 위치입니다.
- 외부 데이터 저장소. 온-프레미스 애플리케이션 서버는 VM 로컬 캐싱을 수행했습니다. 이 설정은 자주 사용한 데이터를 오프로드하지 않았으며 데이터를 무효화할 수 없었습니다.
- 논스틱 세션입니다. 세션 상태를 외부화하면 비스틱 세션이 지원됩니다.
부하 분산 장치: PaaS 솔루션을 사용하는 웹 애플리케이션은 웹앱 아키텍처 및 요구 사항에 따라 Azure Front Door, Azure Application Gateway 또는 둘 다를 사용해야 합니다. 부하 분산 장치 의사 결정 트리를 사용하여 올바른 부하 분산 장치를 선택합니다. Relecloud에는 여러 지역에 걸쳐 트래픽을 라우팅할 수 있는 계층 7 부하 분산 장치가 필요했습니다. 이 회사는 99.9%SLO를 충족하기 위해 다중 지역 웹앱이 필요했습니다. Relecloud는 다음과 같은 이유로 Azure Front Door를 선택했습니다.
- 전역 부하 분산. 여러 지역에 걸쳐 트래픽을 라우팅할 수 있는 계층 7 부하 분산 장치입니다.
- 웹 애플리케이션 방화벽. 기본적으로 Azure Web Application Firewall과 통합됩니다.
- 라우팅 유연성. 이를 통해 애플리케이션 팀은 애플리케이션의 향후 변경 내용을 지원하도록 수신 요구를 구성할 수 있습니다.
- 트래픽 가속. anycast를 사용하여 가장 가까운 Azure 현재 지점에 도달하고 웹앱에 대한 가장 빠른 경로를 찾습니다.
- 사용자 지정 도메인. 유연한 도메인 유효성 검사를 통해 사용자 지정 도메인 이름을 지원합니다.
- 상태 프로브. 애플리케이션에는 지능형 상태 프로브 모니터링이 필요합니다. Azure Front Door는 프로브의 응답을 사용하여 클라이언트 요청을 라우팅하는 데 가장 적합한 원본을 결정합니다.
- 모니터링 지원. Azure Front Door 및 보안 패턴 모두에 대한 올인원 대시보드가 포함된 기본 제공 보고서를 지원합니다. Azure Monitor와 통합되는 경고를 구성할 수 있습니다. Azure Front Door를 사용하면 애플리케이션이 각 요청 및 실패한 상태 프로브를 기록할 수 있습니다.
- DDoS 보호. 기본 제공 계층 3-4 DDoS 보호 기능이 있습니다.
- 콘텐츠 배달 네트워크. 콘텐츠 배달 네트워크를 사용하도록 Relecloud를 배치합니다. 콘텐츠 배달 네트워크는 사이트 가속을 제공합니다.
웹 애플리케이션 방화벽: Azure 웹 애플리케이션 방화벽을 사용하여 일반적인 웹 악용 및 취약성으로부터 중앙 집중식 보호를 제공합니다. Relecloud는 다음과 같은 이유로 Azure 웹 애플리케이션 방화벽을 사용합니다.
- 전역 보호. 성능을 저하시키지 않고 향상된 글로벌 웹앱 보호를 제공합니다.
- 봇넷 보호. 팀은 봇넷과 관련된 보안 문제를 해결하기 위해 설정을 모니터링하고 구성할 수 있습니다.
- 온-프레미스와의 패리티. 온-프레미스 솔루션이 IT에서 관리하는 웹 애플리케이션 방화벽 뒤에서 실행되고 있었습니다.
- 사용 편의성. 웹 애플리케이션 방화벽은 Azure Front Door와 통합됩니다.
구성 스토리지: 웹앱에 앱 구성 스토리지를 추가할지 여부를 선택합니다. Azure 앱 구성은 애플리케이션 설정 및 기능 플래그를 중앙에서 관리하기 위한 서비스입니다. App Configuration 모범 사례를 검토하여 이 서비스가 앱에 적합한지 여부를 결정합니다. Relecloud는 파일 기반 구성을 애플리케이션 플랫폼 및 코드와 통합되는 중앙 구성 저장소로 바꾸고자 했습니다. 다음과 같은 이유로 아키텍처에 App Configuration을 추가했습니다.
- 융통성. 기능 플래그를 지원합니다. 기능 플래그를 사용하면 사용자가 앱을 다시 배포하지 않고도 프로덕션 환경에서 초기 미리 보기 기능을 옵트인 및 옵트아웃할 수 있습니다.
- Git 파이프라인 지원. Git 리포지토리가 되어야 하는 구성 데이터의 원본입니다. 중앙 구성 저장소의 데이터를 업데이트하는 데 필요한 파이프라인입니다.
- 관리 ID 지원. 관리 ID를 지원하여 구성 저장소에 대한 연결을 간소화하고 보호합니다.
비밀 관리자: Azure에서 관리할 비밀이 있는 경우 Azure Key Vault를 사용합니다. ConfigurationBuilder 개체를 사용하여 .NET 앱에 Key Vault를 통합할 수 있습니다. Relecloud의 온-프레미스 웹앱은 코드 구성 파일에 비밀을 저장하지만, 더 나은 보안 방법은 RBAC 및 감사 컨트롤을 지원하는 위치에 비밀을 저장하는 것입니다. 관리 ID Azure 리소스에 연결하기 위한 기본 솔루션이지만 Relecloud에는 관리하는 데 필요한 애플리케이션 비밀이 있습니다. Relecloud는 다음과 같은 이유로 Key Vault를 사용했습니다.
- 암호화. 미사용 및 전송 중인 암호화를 지원합니다.
- 관리 ID 지원. 애플리케이션 서비스는 관리 ID를 사용하여 비밀 저장소에 액세스할 수 있습니다.
- 모니터링 및 로깅. Key Vault는 감사 액세스를 용이하게 하고 저장된 비밀이 변경될 때 경고를 생성합니다.
- 통합. Key Vault는 Azure 구성 저장소(App Configuration) 및 웹 호스팅 플랫폼(App Service)과 네이티브 통합을 제공합니다.
Storage 솔루션: 요구 사항에 따라 올바른 스토리지 솔루션을 선택하려면 Azure Storage 옵션을 참조하세요. Relecloud의 온-프레미스 웹앱에는 각 웹 서버에 디스크 스토리지가 탑재되었지만 팀은 외부 데이터 스토리지 솔루션을 사용하고자 했습니다. Relecloud는 다음과 같은 이유로 Azure Blob Storage를 선택했습니다.
- 향상된 보안 액세스. 웹앱은 익명 액세스를 사용하여 공용 인터넷에 노출된 스토리지에 액세스하기 위한 엔드포인트를 제거할 수 있습니다.
- 암호화. Blob Storage는 미사용 및 전송 중인 데이터를 암호화합니다.
- 복구. Blob Storage는 ZRS(영역 중복 스토리지)를 지원합니다. 영역 중복 스토리지는 주 지역의 세 Azure 가용성 영역에서 데이터를 동기적으로 복제합니다. 각 가용성 영역은 독립적인 전원, 냉각 및 네트워킹이 있는 별도의 물리적 위치에 있습니다. 이 구성은 티켓 이미지를 손실에 대해 복원력 있게 만들어야 합니다.
엔드포인트 보안 :Azure Private Link 사용하여 가상 네트워크의 프라이빗 엔드포인트를 통해 PaaS(Platform as a Service) 솔루션에 액세스합니다. 가상 네트워크와 서비스 간의 트래픽은 Microsoft 백본 네트워크를 통해 이동합니다. Relecloud는 다음과 같은 이유로 Private Link를 선택했습니다.
- 향상된 보안 통신. Private Link를 사용하면 애플리케이션이 Azure 플랫폼의 서비스에 비공개로 액세스할 수 있으며 데이터 누출을 방지할 수 있도록 데이터 저장소의 네트워크 공간을 줄일 수 있습니다.
- 최소한의 노력. 프라이빗 엔드포인트는 웹앱에서 사용하는 웹앱 플랫폼 및 데이터베이스 플랫폼을 지원합니다. 두 플랫폼 모두 기존 온-프레미스 구성을 미러링하므로 최소한의 변경이 필요합니다.
네트워크 보안. Azure Firewall 사용하여 네트워크 수준에서 인바운드 및 아웃바운드 트래픽을 제어합니다. Azure Bastion 사용하여 RDP/SSH 포트를 노출하지 않고 보안이 강화된 가상 머신에 연결합니다. Relecloud는 허브 및 스포크 네트워크 토폴로지와 공유 네트워크 보안 서비스를 허브에 배치하려고 했습니다. Azure Firewall은 스포크에서 모든 아웃바운드 트래픽을 검사하여 보안을 향상시켜 네트워크 보안을 강화합니다. Relecloud는 DevOps 서브넷의 점프 호스트에서 향상된 보안 배포를 위해 Azure Bastion이 필요했습니다.

코드 지침

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

신뢰할 수 있는 웹앱 패턴의 디자인 패턴 역할을 보여 주는

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

각 디자인 패턴은 Well-Architected Framework의 하나 이상의 핵심 요소와 일치하는 워크로드 디자인 이점을 제공합니다. 구현해야 하는 패턴의 개요는 다음과 같습니다.

다시 시도 패턴입니다. 다시 시도 패턴은 간헐적으로 실패할 수 있는 작업을 다시 시도하여 일시적인 오류를 처리합니다. 다른 Azure 서비스에 대한 모든 아웃바운드 호출에서 이 패턴을 구현합니다.
회로 차단기 패턴입니다. 회로 차단기 패턴은 애플리케이션이 일시적이지 않은 작업을 다시 시도하는 것을 방지합니다. 다른 Azure 서비스에 대한 모든 아웃바운드 호출에서 이 패턴을 구현합니다.
Cache-Aside 패턴입니다. Cache-Aside 패턴은 요청 시 데이터를 데이터 저장소의 캐시로 로드합니다. 데이터베이스에 대한 요청에 대해 이 패턴을 구현합니다.

디자인 패턴	안정성(RE)	PE(성능 효율성)	WAF 원칙 지원
패턴 다시 시도	✔		RE:07
회로 차단기 패턴	✔	✔	RE:03 RE:07 PE:07 PE:11
Cache-Aside 패턴	✔	✔	RE:05 PE:08 PE:12

재시도 패턴 구현

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

기본 제공 재시도 메커니즘을 사용합니다. 대부분의 Azure 서비스에서 제공하는 기본 제공 재시도 메커니즘을 사용하여 구현을 신속하게 처리합니다. 예를 들어 참조 구현은 Entity Framework Core 연결 복원력을 사용하여 SQL Database에 요청 시 재시도 패턴을 적용합니다.
```
services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
    sqlServerOptionsAction: sqlOptions =>
    {
        sqlOptions.EnableRetryOnFailure(
        maxRetryCount: 5,
        maxRetryDelay: TimeSpan.FromSeconds(3),
        errorNumbersToAdd: null);
    }));
```

다시 시도 프로그래밍 라이브러리를 사용합니다. HTTP 통신의 경우 Polly 또는 Microsoft.Extensions.Http.Resilience같은 표준 복원력 라이브러리를 통합합니다. 이러한 라이브러리는 외부 웹 서비스와의 통신을 관리하는 데 중요한 포괄적인 재시도 메커니즘을 제공합니다. 예를 들어 참조 구현은 코드가 IConcertSearchService 개체를 호출하는 개체를 생성할 때마다 Polly를 사용하여 재시도 패턴을 적용합니다.

private void AddConcertSearchService(IServiceCollection services)
{
    var baseUri = Configuration["App:RelecloudApi:BaseUri"];
    if (string.IsNullOrWhiteSpace(baseUri))
    {
        services.AddScoped<IConcertSearchService, MockConcertSearchService>();
    }
    else
    {
        services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
        {
            httpClient.BaseAddress = new Uri(baseUri);
            httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
            httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
        })
        .AddPolicyHandler(GetRetryPolicy())
        .AddPolicyHandler(GetCircuitBreakerPolicy());
    }
}

private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
{
    var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
    return HttpPolicyExtensions
      .HandleTransientHttpError()
      .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
      .WaitAndRetryAsync(delay);
}

회로 차단기 패턴 구현

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

예를 들어 참조 구현은 API에 대한 모든 요청에 회로 차단기 패턴을 적용합니다. HandleTransientHttpError 논리를 사용하여 안전하게 다시 시도할 수 있지만 지정된 기간 동안 집계 오류 수를 제한할 수 있는 HTTP 요청을 검색합니다.

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

캐시 배제 패턴 구현

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

캐시를 사용하도록 애플리케이션을 구성합니다. 프로덕션 앱은 분산 Redis 캐시를 사용해야 합니다. 이 캐시는 데이터베이스 쿼리를 줄여 성능을 향상시킵니다. 또한 부하 분산 장치가 트래픽을 균등하게 분산할 수 있도록 논스틱 세션을 사용하도록 설정합니다. 참조 구현은 분산 Redis 캐시를 사용합니다. AddAzureCacheForRedis 메서드 Azure Cache for Redis를 사용하도록 애플리케이션을 구성합니다.
```
private void AddAzureCacheForRedis(IServiceCollection services)
{
    if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
    {
        services.AddStackExchangeRedisCache(options =>
        {
            options.Configuration = Configuration["App:RedisCache:ConnectionString"];
        });
    }
    else
    {
        services.AddDistributedMemoryCache();
    }
}
```

필요한 데이터를 캐시합니다. 필요한 데이터에 Cache-Aside 패턴을 적용하여 효율성을 향상시킵니다. Azure Monitor를 사용하여 데이터베이스의 CPU, 메모리 및 스토리지를 추적합니다. 이러한 메트릭은 Cache-Aside 패턴을 적용한 후 더 작은 데이터베이스 SKU를 사용할 수 있는지 여부를 결정하는 데 도움이 됩니다. 예를 들어 참조 구현은 예정된 콘서트 페이지를 지원하는 필요한 데이터를 캐시합니다. GetUpcomingConcertsAsync 메서드는 SQL Database에서 Redis 캐시로 데이터를 끌어와 캐시를 최신 콘서트 데이터로 채웁니다.

public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
{
    IList<Concert>? concerts;
    var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
    if (concertsJson != null)
    {
        // There is cached data. Deserialize the JSON data.
        concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
    }
    else
    {
        // There's nothing in the cache. Retrieve data 
        // from the repository and cache it for one hour.
        concerts = await this.database.Concerts.AsNoTracking()
            .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
            .OrderBy(c => c.StartTime)
            .Take(count)
            .ToListAsync();
        concertsJson = JsonSerializer.Serialize(concerts);
        var cacheOptions = new DistributedCacheEntryOptions {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
        };
        await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
    }
    return concerts ?? new List<Concert>();
}

캐시 데이터를 최신 상태로 유지합니다. 최신 데이터베이스 변경 내용과 동기화하도록 일반 캐시 업데이트를 예약합니다. 데이터 변동성을 사용하고 사용자는 최적의 새로 고침 속도를 결정해야 합니다. 이 방법을 사용하면 애플리케이션이 Cache-Aside 패턴을 사용하여 빠른 액세스 및 현재 정보를 모두 제공합니다. 예를 들어 참조 구현은 1시간 동안만 데이터를 캐시하고 CreateConcertAsync 메서드를 사용하여 데이터가 변경되면 캐시 키를 지웁니다.
```
public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
{
    database.Add(newConcert);
    await this.database.SaveChangesAsync();
    this.cache.Remove(CacheKeys.UpcomingConcerts);
    return CreateResult.SuccessResult(newConcert.Id);
}
```
데이터 일관성을 보장합니다. 데이터베이스 쓰기 작업 직후 캐시를 업데이트하는 메커니즘을 구현합니다. 이벤트 기반 업데이트 또는 전용 데이터 관리 클래스를 사용하여 캐시 일관성을 보장합니다. 캐시를 데이터베이스 수정과 일관되게 동기화하는 것은 캐시 배제 패턴의 핵심입니다. 참조 구현은 UpdateConcertAsync 메서드를 사용하여 캐시의 데이터를 일관성 있게 유지합니다.
```
public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
{
   database.Update(existingConcert);
   await database.SaveChangesAsync();
   this.cache.Remove(CacheKeys.UpcomingConcerts);
   return UpdateResult.SuccessResult();
}
```

구성 지침

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

구성	안정성(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에는 기본 테넌트에서 애플리케이션 등록이 필요합니다. 애플리케이션 등록은 웹앱에 액세스하는 사용자에게 기본 테넌트에 ID가 있는지 확인하는 데 도움이 됩니다.
플랫폼 기능을 사용합니다. 플랫폼 기능을 사용하여 사용자를 인증하고 데이터에 액세스하여 사용자 지정 인증 코드의 필요성을 최소화합니다. 예를 들어 App Service 기본 제공 인증 지원을 제공하므로 웹앱에서 코드를 최소한으로 작성하거나 작성하지 않으면서 사용자를 로그인하고 데이터에 액세스할 수 있습니다.
애플리케이션에서 권한 부여를 적용합니다. RBAC를 사용하여 애플리케이션 역할 최소 권한을 할당합니다. 서로 다른 사용자 작업에 대한 특정 역할을 정의하여 겹치지 않도록 하고 명확성을 보장합니다. 사용자를 적절한 역할에 매핑하고 필요한 리소스 및 작업에만 액세스할 수 있는지 확인합니다.

스토리지에 대한 임시 액세스를 선호합니다. 임시 사용 권한을 사용하여 무단 액세스 및 위반으로부터 보호합니다. 예를 들어 SAS(공유 액세스 서명) 사용하여 액세스를 일정 기간으로 제한할 수 있습니다. 임시 액세스 권한을 부여할 때 사용자 위임 SAS를 사용하여 보안을 최대화합니다. Microsoft Entra ID 자격 증명을 사용하고 영구 스토리지 계정 키가 필요하지 않은 유일한 SAS입니다.
Azure에서 권한 부여를 적용합니다. Azure RBAC를 사용하여 사용자 ID에 최소 권한을 할당합니다. Azure RBAC는 ID가 액세스할 수 있는 Azure 리소스, 해당 리소스로 수행할 수 있는 작업 및 액세스할 수 있는 영역을 정의합니다.
영구 관리자 권한은 사용하지 않습니다. Microsoft Entra Privileged Identity Management를 사용하여 권한 있는 작업에 대한 Just-In-Time 액세스 권한을 부여합니다. 예를 들어 개발자는 데이터베이스를 만들거나 삭제하고, 테이블 스키마를 수정하고, 사용자 권한을 변경하려면 관리자 수준의 액세스 권한이 필요한 경우가 많습니다. Just-In-Time 액세스를 사용하는 경우 사용자 ID는 권한 있는 작업을 수행할 수 있는 임시 권한을 받습니다.

관리 ID 사용

관리 ID를 지원하는 모든 Azure 서비스에 사용합니다. 관리 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 앱 구성에 저장합니다.

참조 구현은 App Service가 관리 ID인 Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default사용하여 SQL 데이터베이스 연결할 수 있도록 SQL 데이터베이스 연결 문자열의 Authentication 인수를 사용합니다. DefaultAzureCredential 사용하여 웹 API가 관리 ID를 사용하여 Key Vault에 연결할 수 있도록 합니다.

    builder.Configuration.AddAzureAppConfiguration(options =>
    {
         options
            .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
            .ConfigureKeyVault(kv =>
            {
                // Some of the values coming from App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

환경 권한 부여

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

비용을 예측합니다. Azure 가격 계산기를 사용하여 각 환경의 비용을 예측합니다.
비용 최적화 프로덕션 환경. 프로덕션 환경에는 SLA(서비스 수준 계약), 기능 및 프로덕션에 필요한 규모를 충족하는 SKU가 필요합니다. 리소스 사용량을 지속적으로 모니터링하고 실제 성능 요구 사항에 맞게 SKU를 조정합니다.
비용 최적화 사전 프로덕션 환경사전 프로덕션 환경 저렴한 리소스를 사용하고 Azure 개발/테스트 가격 책정같은 할인을 활용해야 합니다. 이러한 환경에서는 필요하지 않은 서비스를 사용하지 않도록 설정해야 합니다. 동시에 사전 프로덕션 환경이 프로덕션 환경과 충분히 유사하여 위험이 발생하지 않도록 해야 합니다. 이 잔액을 유지하면 불필요한 비용이 발생하지 않고 테스트가 효과적으로 유지됩니다.
IaC(Infrastructure as code)를 사용하여 SKU를 정의합니다. IaC를 구현하여 환경에 따라 올바른 SKU를 동적으로 선택하고 배포합니다. 이 방법은 일관성을 향상시키고 관리를 간소화합니다.

예를 들어 참조 구현은 Bicep 매개 변수를 사용하여 프로덕션 환경에 더 비싼 SKU(계층)를 배포합니다.

    var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
    var redisCacheFamilyName = isProd ? 'C' : 'C'
    var redisCacheCapacity = isProd ? 1 : 0

자동 크기 조정을 구현

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

스케일 아웃을 자동화합니다. Azure 자동 크기 조정을 사용하여 프로덕션 환경에서 수평 크기 조정을 자동화합니다. 애플리케이션이 다양한 부하를 처리할 수 있도록 주요 성능 메트릭에 따라 스케일 아웃되도록 자동 크기 조정 규칙을 구성합니다.
크기 조정 트리거를 구체화합니다. 애플리케이션의 크기 조정 요구 사항에 익숙하지 않은 경우 CPU 사용률을 초기 크기 조정 트리거로 사용합니다. RAM, 네트워크 처리량 및 디스크 I/O와 같은 다른 메트릭을 포함하도록 크기 조정 트리거를 구체화합니다. 목표는 성능 향상을 위해 웹 애플리케이션의 동작과 일치하도록 하는 것입니다.
스케일 아웃 버퍼를 제공합니다. 최대 용량에 도달하기 전에 트리거할 크기 조정 임계값을 설정합니다. 예를 들어 100%에 도달할 때까지 기다리지 않고 CPU 사용률이 85%로 조정되도록 구성합니다. 이 사전 예방적 접근 방식은 성능을 유지하고 잠재적인 병목 상태를 방지하는 데 도움이 됩니다.

리소스 배포 자동화

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

인프라를 코드로 사용합니다. CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인을 사용하여 인프라를 코드 배포합니다. Azure는 모든 Azure 리소스에 대해 미리 빌드된 Bicep, ARM(JSON) 및 Terraform 템플릿 제공합니다.
CI/CD(연속 통합/지속적인 배포) 파이프라인을 사용합니다. CI/CD 파이프라인을 사용하여 소스 제어에서 테스트, 스테이징 및 프로덕션과 같은 다양한 환경으로 코드를 배포합니다. Azure DevOps로 작업하는 경우 Azure Pipelines를 사용합니다. GitHub 프로젝트에 GitHub Actions를 사용합니다.
단위 테스트를 통합합니다. App Services에 배포하기 전에 파이프라인 내의 모든 단위 테스트 실행 및 전달 우선 순위를 지정합니다. SonarQube와 같은 코드 품질 및 검사 도구를 통합하여 포괄적인 테스트 범위를 달성합니다.
모의 프레임워크를 채택합니다. 외부 엔드포인트를 포함하는 테스트의 경우 모의 프레임워크를 사용합니다. 이러한 프레임워크를 사용하면 시뮬레이션된 엔드포인트를 만들 수 있습니다. 실제 외부 엔드포인트를 구성하고 환경 전체에서 균일한 테스트 조건을 보장할 필요가 없습니다.
보안 검사를 수행합니다. SAST(정적 애플리케이션 보안 테스트)를 사용하여 소스 코드에서 보안 결함 및 코딩 오류를 찾습니다. 또한 SCA(소프트웨어 컴퍼지션 분석)를 수행하여 타사 라이브러리 및 구성 요소에서 보안 위험을 검사합니다. 이러한 분석을 위한 도구는 GitHub와 Azure DevOps 모두에 쉽게 통합할 수 있습니다.

모니터링 구현

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

애플리케이션 원격 분석을 수집합니다. Azure Application Insights의 자동 침입 사용하여 요청 처리량, 평균 요청 기간, 오류 및 종속성 모니터링과 같은 원격 분석 애플리케이션을 수집합니다. 이 원격 분석을 사용하기 위해 코드를 변경할 필요가 없습니다.

참조 구현은 NuGet 패키지 Microsoft.ApplicationInsights.AspNetCoreAddApplicationInsightsTelemetry 사용하여 원격 분석 수집사용하도록 설정합니다.
```
public void ConfigureServices(IServiceCollection services)
{
   ...
   services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
   ...
}
```
사용자 지정 애플리케이션 메트릭을 만듭니다. 사용자 지정 애플리케이션 원격 분석에 코드 기반 계측을 사용합니다. 코드에 Application Insights SDK를 추가하고 Application Insights API를 사용합니다.

참조 구현은 카트 활동과 관련된 이벤트에 대한 원격 분석을 수집합니다. this.telemetryClient.TrackEvent 은 카트에 추가된 티켓을 계산합니다. 이벤트 이름(AddToCart)을 제공하고 concertId 및 count있는 사전을 지정합니다.
```
this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
    { "ConcertId", concertId.ToString() },
    { "Count", count.ToString() }
});
```
플랫폼을 모니터링합니다. 지원되는 모든 서비스에 대해 진단을 사용하도록 설정합니다. 상관 관계를 위해 애플리케이션 로그와 동일한 대상으로 진단을 보냅니다. Azure 서비스는 플랫폼 로그를 자동으로 만들지만 진단을 사용하도록 설정할 때만 저장합니다. 진단을 지원하는 각 서비스에 대한 진단 설정을 사용하도록 설정합니다.

참조 구현 배포

참조 구현은 개발자가 온-프레미스 ASP.NET 애플리케이션에서 Azure로 시뮬레이션된 마이그레이션을 안내하고 초기 채택 단계에서 필요한 변경 내용을 강조 표시합니다. 이 예제에서는 온-프레미스 웹 애플리케이션을 통해 티켓을 판매하는 가상의 회사 Relecloud에 대한 콘서트 티켓 애플리케이션을 사용합니다. Relecloud는 웹 애플리케이션에 대해 다음 목표를 설정합니다.

저렴한 고가의 코드 변경 내용을 구현합니다.
99.9%SLO를 달성합니다.
DevOps 사례를 채택합니다.
비용 최적화 환경을 만듭니다.
안정성 및 보안을 향상시킵니다.

Relecloud는 온-프레미스 인프라가 이러한 목표를 달성하기 위한 비용 효율적인 솔루션이 아니라고 판단했습니다. 웹 애플리케이션을 Azure로 마이그레이션하는 것이 즉각적이고 미래의 목표를 달성하는 가장 비용 효율적인 방법이라고 결정했습니다. 다음 아키텍처는 Relecloud의 신뢰할 수 있는 웹앱 패턴 구현의 최종 상태를 나타냅니다.

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

참조 구현

다음을 통해 공유