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