이 예제 아키텍처는 Azure App Service 웹 애플리케이션의 확장성과 성능 향상을 위한 검증된 사례를 보여 줍니다.
이 아키텍처에 대한 참조 구현은 GitHub에서 사용할 수 있습니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
이 아키텍처는 기본 웹 애플리케이션에 표시된 아키텍처를 기반으로 합니다. 다음 구성 요소가 포함되어 있습니다.
- 웹앱 일반적인 최신 애플리케이션에는 웹 사이트와 하나 이상의 RESTful 웹 API가 모두 포함되어 있을 수 있습니다. AJAX를 통한 브라우저 클라이언트, 기본 클라이언트 애플리케이션 또는 서버 쪽 애플리케이션에서 웹 API를 사용할 수 있습니다. 웹 API 디자인에 대한 고려 사항은 API 디자인 지침을 참조하세요.
- Front Door Front Door는 계층 7 부하 분산 장치입니다. 이 아키텍처에서 HTTP 요청을 웹 프런트 엔드로 라우팅합니다. 또한 Front Door는 일반적인 악용 및 취약점으로부터 애플리케이션을 보호하는 WAF(웹 애플리케이션 방화벽)를 제공합니다. Front Door는 이 디자인의 CDN(Content Delivery Network) 솔루션에도 사용됩니다.
- 함수 앱. 함수 앱을 사용하여 백그라운드 작업을 실행합니다. 함수는 큐에 배치되는 타이머 이벤트 또는 메시지와 같은 트리거에 의해 호출됩니다. 장기 실행 상태 저장 작업의 경우 Durable Functions를 사용합니다.
- 큐. 여기에 표시된 아키텍처에서는 애플리케이션이 Azure Service Bus 큐에 메시지를 넣어 백그라운드 작업을 큐에 넣습니다. 메시지가 함수 앱을 트리거합니다. 또는 Azure Storage 큐를 사용할 수 있습니다. 비교하려면 Storage 큐 및 Service Bus 큐 - 비교 및 대조를 참조하세요.
- 캐시. Azure Cache for Redis의 반정적 데이터를 저장합니다.
- 데이터 스토리지. 관계형 데이터의 경우 Azure SQL Database를 사용합니다. 비관계형 데이터의 경우 Azure Cosmos DB를 사용하는 것이 좋습니다.
- Azure Cognitive Search Azure Cognitive Search를 사용하여 검색 제안, 유사 항목 검색 및 언어별 검색과 같은 검색 기능을 추가합니다. Azure Search는 일반적으로 다른 데이터 저장소와 함께 사용되는데, 특히 기본 데이터 저장소에 엄격한 일관성이 필요한 경우 그렇습니다. 이러한 접근 방식에서는 신뢰할 수 있는 데이터를 다른 데이터 저장소에 저장하고 검색 인덱스를 Azure Search에 저장합니다. 또한 Azure Search는 여러 데이터 저장소의 단일 검색 인덱스를 통합하는 데 사용할 수 있습니다.
- Azure DNS. Azure DNS는 Microsoft Azure 인프라를 사용하여 이름 확인을 제공하는 DNS 도메인에 대한 호스팅 서비스입니다. Azure에 도메인을 호스트하면 다른 Azure 서비스와 동일한 자격 증명, API, 도구 및 대금 청구를 사용하여 DNS 레코드를 관리할 수 있습니다.
권장 사항
개발자의 요구 사항이 여기에 설명된 아키텍처와 다를 수 있습니다. 이 섹션의 권장 사항을 시작점으로 사용합니다.
App Service 앱
웹 애플리케이션과 웹 API를 별도의 App Service 앱으로 만드는 것이 좋습니다. 이렇게 디자인하면 이들을 별도의 App Service 계획에서 실행할 수 있으므로 독립적으로 확장할 수 있습니다. 처음에 이러한 수준의 확장성이 필요하지 않은 경우 앱을 동일한 계획에 배포하고 필요한 경우 나중에 별도의 계획으로 이동할 수 있습니다.
참고
Basic, Standard, Premium 및 격리 계획은 앱 단위가 아니라 계획의 VM 인스턴스에 대해 청구됩니다. App Service 가격 책정을 참조하세요.
캐시
Azure Cache for Redis를 사용하여 일부 데이터를 캐시하면 성능과 확장성을 향상할 수 있습니다. 다음을 위해 Azure Cache for Redis를 사용하는 것이 좋습니다.
- 반정적 트랜잭션 데이터
- 세션 상태
- HTML 출력 이는 복잡한 HTML 출력을 렌더링하는 애플리케이션에 유용할 수 있습니다.
캐싱 전략 디자인에 대한 자세한 지침은 캐싱 지침을 참조하세요.
CDN
Front Door의 기본 CDN 기능을 사용하여 정적 콘텐츠를 캐시합니다. CDN의 주요 이점은 사용자의 대기 시간이 줄어드는 것인데 그 이유는 콘텐츠가 사용자와 지리적으로 가까운 에지 서버에 캐시되기 때문입니다. 또한 애플리케이션에 의해 트래픽이 처리되지 않기 때문에 CDN은 애플리케이션의 부하를 줄일 수 있습니다. 또한 Front Door는 동적 사이트 가속을 제공하여 정적 콘텐츠 캐싱에서만 사용할 수 있는 것보다 웹앱에 더 나은 전반적인 사용자 환경을 제공할 수 있습니다.
참고
Front Door CDN은 인증이 필요한 콘텐츠를 제공하도록 설계되지 않았습니다.
스토리지
최신 애플리케이션은 종종 많은 양의 데이터를 처리합니다. 클라우드에 대한 크기를 조정하려면 올바른 스토리지 유형을 선택해야 합니다. 다음은 몇 가지 기본 권장 사항입니다.
| 저장 형식 | 예제 | 권장 스토리지 |
|---|---|---|
| 파일 | 이미지, 문서, PDF | Azure Blob Storage |
| 키/값 쌍 | 사용자 ID로 조회된 사용자 프로필 데이터 | Azure Table Storage |
| 추가 처리를 트리거할 짧은 메시지 | 주문 요청 | Azure Queue Storage, Service Bus 큐 또는 Service Bus 항목 |
| 기본 쿼리를 요구하는 유연한 스키마를 사용하는 비관계형 데이터 | 상품 카탈로그 | Azure Cosmos DB, MongoDB 또는 Apache CouchDB와 같은 문서 데이터베이스 |
| 보다 풍부한 쿼리 지원, 엄격한 스키마 및/또는 강력한 일관성이 필요한 관계형 데이터 | 제품 인벤토리 | Azure SQL Database |
적절한 데이터 저장소 선택을 참조하세요.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
보안
이 섹션에는 이 문서에 설명된 Azure 서비스와 관련된 보안 고려 사항이 나와 있습니다. 웹 애플리케이션에 대한 보안 모범 사례가 완전히 다 나와 있는 것은 아닙니다. 추가 보안 고려 사항은 Azure App Service에서 앱 보안을 참조하세요.
들어오는 트래픽 제한
Front Door에서만 트래픽을 허용하도록 애플리케이션을 구성합니다. 이렇게 하면 앱에 도달하기 전에 모든 트래픽이 WAF를 통과합니다. 자세한 내용은 내 백 엔드에 Azure Front Door만 액세스하도록 잠그려면 어떻게 해야 할까요?를 참조하세요.
CORS(원본 간 리소스 공유)
웹 사이트와 웹 API를 별도의 앱으로 만드는 경우 CORS를 사용하도록 설정하지 않으면 클라이언트 쪽 AJAX에서 API를 호출할 수 없습니다.
참고
브라우저 보안은 웹 페이지에서 다른 도메인으로 AJAX 요청을 수행하지 못하도록 방지합니다. 이렇게 제한하는 것을 동일 원본 정책이라고 하며, 악성 사이트에서 다른 사이트의 중요한 데이터를 읽을 수 없도록 합니다. CORS는 서버에서 동일 원본 정책을 완화하고 크로스-원본 요청을 일부는 허용하고 일부는 거부할 수 있는 W3C표준입니다.
App Services에서는 애플리케이션 코드를 작성할 필요 없이 기본적으로 CORS를 지원합니다. CORS를 사용하여 JavaScript에서 API 앱 사용을 참조하세요. API에 대해 허용되는 원본 목록에 웹 사이트를 추가합니다.
SQL Database 암호화
데이터베이스에서 미사용 데이터를 암호화해야 하는 경우 투명한 데이터 암호화를 사용합니다. 이 기능은 전체 데이터베이스(백업 및 트랜잭션 로그 파일 포함)의 실시간 암호화 및 암호 해독을 수행하며 애플리케이션을 변경할 필요가 없습니다. 암호화를 수행하면 대기 시간이 늘어나므로, 고유한 데이터베이스에 보호해야 하는 데이터를 분리하고 해당 데이터베이스에 대해서만 암호화를 사용하도록 설정하는 것이 좋습니다.
비용 최적화
캐싱을 사용하여 자주 변경되지 않는 콘텐츠를 제공하는 서버의 부하를 줄입니다. 페이지의 모든 렌더링 주기는 컴퓨팅, 메모리 및 대역폭을 소비하기 때문에 비용에 영향을 미칠 수 있습니다. 특히 JavaScript 단일 페이지 앱 및 미디어 스트리밍 콘텐츠와 같은 정적 콘텐츠 서비스의 경우 캐싱을 사용하여 이러한 비용을 크게 줄일 수 있습니다.
앱에 정적 콘텐츠가 있는 경우 CDN을 사용하여 프런트 엔드 서버의 부하를 줄입니다. 자주 변경되지 않는 데이터의 경우 Azure Cache for Redis를 사용합니다.
자동 크기 조정을 위해 구성된 상태 비저장 앱은 상태 저장 앱보다 비용 효율적입니다. 세션 상태를 사용하는 ASP.NET 애플리케이션의 경우 Azure Cache for Redis를 사용하여 메모리에 저장합니다. 자세한 내용은 Azure Cache for Redis용 ASP.NET 세션 상태 공급자를 참조하세요. 또 다른 옵션은 세션 상태 공급자를 통해 Azure Cosmos DB를 백 엔드 상태 저장소로 사용하는 것입니다. Azure Cosmos DB를 ASP.NET 세션 상태 및 캐싱 공급자로 사용을 참조하세요.
자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.
백그라운드 작업이 HTTP 요청을 처리하는 동일한 인스턴스에서 실행되지 않도록 함수 앱을 전용 App Service 요금제에 배치하는 것이 좋습니다. 백그라운드 작업을 일시적으로 실행하는 경우 사용 플랜을 사용하는 것이 좋습니다. 그러면 매시간이 아닌 실행의 수 및 사용된 리소스를 기준으로 요금이 청구됩니다.
가격 책정 계산기를 사용하여 비용을 예측합니다.
운영 우수성
운영 우수성에서는 프로덕션에서 애플리케이션을 배포하고 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 핵심 요소 개요를 참조하세요. 운영 우수성의 핵심 원칙은 DevOps 사례에 따라 인프라 수정을 포함한 운영 활동을 자동화하는 것입니다.
기본 웹 애플리케이션 DevOps 고려 사항 섹션에 제공된 지침은 이 아키텍처의 기초이므로 여기에 적용됩니다.
성능 효율성
Azure App Service의 주요 이점은 부하에 따라 애플리케이션을 확장할 수 있다는 점입니다. 다음은 애플리케이션 확장을 계획할 때 염두에 둘 몇 가지 고려 사항입니다.
App Service 앱
솔루션에 여러 App Service 앱이 포함되어 있는 경우 App Service 계획이 분리되도록 배포하는 것을 고려합니다. 이러한 방식을 사용하면 개별 인스턴스에서 실행되므로 개별적으로 확장할 수 있습니다.
SQL Database
데이터베이스를 분할하여 SQL데이터베이스의 확장성을 높입니다. 분할은 데이터베이스를 가로로 분할합니다. 분할을 사용하면 Elastic Database 도구로 데이터베이스를 가로로 확장할 수 있습니다. 분할의 잠재적 이점은 다음과 같습니다.
- 트랜잭션 처리량이 늘어납니다.
- 쿼리가 데이터의 하위 집합에서 더 빨리 실행될 수 있습니다.
Azure Front Door
Front Door는 SSL 오프로드를 수행할 수 있으며 백 엔드 웹앱과의 총 TCP 연결 수를 줄일 수도 있습니다. 이는 웹앱이 SSL 핸드셰이크 및 TCP 연결의 작은 볼륨을 관리하기 때문에 확장성을 향상시킵니다. 이러한 성능 향상은 높은 수준의 연결 재사용으로 인해 웹앱에 요청을 HTTPS로 전달하는 경우에도 적용됩니다.
Azure Search
Azure Search는 주요 데이터 저장소에서 복잡한 데이터 검색을 수행하는 데 따른 오버헤드를 제거하므로 부하를 처리하도록 확장할 수 있습니다. Azure Search의 쿼리 및 인덱싱 작업을 위한 리소스 수준 확장을 참조하세요.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Chad Kittel | 수석 SDE
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.