Azure Front Door를 활용하여 Azure Storage에 파일을 업로드하면 향상된 복원력, 확장성 및 추가 보안 조치를 비롯한 많은 이점을 누릴 수 있습니다. 이러한 조치에는 WAF(웹 애플리케이션 방화벽)를 사용한 업로드된 콘텐츠 검사 및 스토리지 계정에 대한 사용자 지정 TLS(전송 계층 보안) 인증서 사용이 포함됩니다.
아키텍처
이 참조 아키텍처에서는 여러 Azure 스토리지 계정 및 다양한 원본이 있는 Azure Front Door 프로필이 배포됩니다. 콘텐츠 업로드에 여러 스토리지 계정을 활용하면 성능과 안정성이 향상되고 다양한 클라이언트가 다양한 순서로 스토리지 계정을 사용하게 되므로 부하 분산이 용이해집니다. API 및 Azure Service Bus 큐를 호스트하기 위해 Azure App Service도 배포합니다.
데이터 흐름
이 시나리오의 데이터 흐름은 다음과 같습니다.
- 클라이언트 앱이 웹 기반 API를 시작하여 여러 업로드 위치 목록을 검색합니다. 클라이언트가 업로드하는 각 파일에 대해 API는 각 기존 스토리지 계정에 하나씩 가능한 업로드 위치 목록을 생성합니다. 각 URL에는 SAS(공유 액세스 서명)가 포함되어 있어 지정된 Blob URL에 업로드하기 위해 해당 URL을 독점적으로 사용할 수 있습니다.
- 클라이언트 애플리케이션이 API에서 반환된 목록의 첫 번째 URL을 사용하여 Blob을 업로드하려고 시도합니다. 클라이언트는 사용자 지정 도메인 이름과 사용자 지정 TLS 인증서를 사용하여 Azure Front Door에 대한 보안 연결을 설정합니다.
- Azure Front Door WAF에서 요청을 검사합니다. WAF에서 요청의 위험 수준이 너무 높다고 판단하면 요청이 차단되며 Azure Front Door에서 HTTP 403 오류 응답을 반환합니다. 그렇지 않은 경우 요청은 원하는 스토리지 계정으로 라우팅됩니다.
- 파일이 Azure 스토리지 계정에 업로드됩니다. 이 요청이 실패하면 클라이언트 애플리케이션은 API에서 반환된 목록의 다음 URL을 사용하여 대체 스토리지 계정에 업로드를 시도합니다.
- 클라이언트 애플리케이션이 파일 업로드가 완료되었다는 것을 API에 알립니다.
- API가 업로드된 파일의 추가 처리를 위해 Azure Service Bus 큐에 항목을 배치합니다.
구성 요소
- Azure App Service는 Blob에 대한 업로드 URL 및 SAS를 생성합니다.
- Azure Front Door는 클라이언트 연결을 처리하고 WAF를 사용하여 검사하며 업로드 요청을 Azure 스토리지 계정으로 라우팅합니다.
- Azure Storage는 업로드된 파일을 Blob에 저장하는 데 사용됩니다.
- Azure Service Bus는 업로드된 콘텐츠의 추가 처리를 트리거하는 큐 역할을 합니다.
시나리오 정보
파일 업로드의 책임은 API 또는 백 엔드 시스템에 할당되는 경우가 많습니다. 그러나 클라이언트 애플리케이션이 JSON 파일을 Blob 스토리지에 직접 업로드할 수 있도록 함으로써 컴퓨팅 리소스(클라이언트로부터의 업로드를 처리하는 API 계층)가 병목 현상을 일으키지 않습니다. 또한 이 방식을 사용하면 API가 더 이상 파일 업로드에 컴퓨팅 시간을 소비하지 않으므로 전체 비용이 줄어듭니다.
API는 스토리지 계정 전체에 파일을 균등하게 배포하는 역할을 합니다. 이는 사용자가 클라이언트 애플리케이션에서 사용할 기본 스토리지 계정을 결정하는 논리를 정의해야 함을 의미합니다.
Azure Front Door 및 Azure 스토리지 계정을 함께 사용하면 콘텐츠 업로드를 위한 단일 진입점(단일 도메인)이 제공됩니다.
여러 스토리지 계정 원본이 있는 Azure Front Door 구성
Azure Front Door 구성에는 각 스토리지 계정에 대한 다음 단계가 포함됩니다.
- 원본 구성
- 경로 구성
- 규칙 집합 구성
원본 구성에서 원본 유형을 Blob 스토리지 계정으로 정의하고 구독 내에서 사용할 수 있는 적절한 스토리지 계정을 선택해야 합니다.
원본 그룹 경로에서 원본 그룹에서 처리할 경로를 정의해야 합니다. 새로 만든 원본 그룹을 선택하고 스토리지 계정 내에서 컨테이너의 경로를 지정하세요.
마지막으로 새 규칙 집합 구성을 만들어야 합니다. 원본 패턴 뒤의 나머지 경로를 새 경로에 추가할 수 있도록 일치하지 않는 경로 유지 설정을 구성하는 것이 중요합니다.
고려 사항
확장성 및 성능
제안된 아키텍처를 사용하면 콘텐츠 업로드에 여러 스토리지 계정을 사용하여 수평 확장성을 달성할 수 있습니다.
복원력
전역적으로 분산된 아키텍처를 사용하는 Azure Front Door는 단일 Azure 지역 및 PoP(Point of Presence)의 오류에 대해 복원력이 있는 고가용성 서비스입니다. 다양한 지역에 여러 스토리지 계정을 배포하는 이 아키텍처는 다양한 클라이언트가 다양한 순서로 스토리지 계정을 사용하도록 하여 복원력을 높이고 로드 분산을 달성하는 데 도움이 됩니다.
비용 최적화
Azure Storage의 비용 구조를 통해 솔루션 비용을 늘리지 않고도 필요에 따라 스토리지 계정을 얼마든지 생성할 수 있습니다. 저장된 파일의 양과 크기는 비용에 영향을 미칩니다.
보안
Azure Front Door를 사용하면 DDoS 보호와 같은 보안 기능을 활용할 수 있습니다. 기본 Azure 인프라 DDoS 보호는 Azure Front Door 네트워크의 글로벌 규모와 용량을 사용하여 네트워크 계층 공격을 실시간으로 모니터링하고 완화합니다. WAF(웹 애플리케이션 방화벽)를 사용하면 일반적인 익스플로잇 및 취약성으로부터 웹 서비스가 보호됩니다. 애플리케이션에 이러한 기능이 필요한 경우 Azure Front Door WAF를 사용하여 속도 제한 및 지역 필터링을 수행할 수도 있습니다.
Private Link를 사용하여 Azure 스토리지 계정을 보호할 수도 있습니다. 스토리지 계정은 인터넷으로부터의 직접 액세스를 거부하고 Azure Front Door에서 사용하는 프라이빗 엔드포인트 연결을 통해서만 요청을 허용하도록 구성할 수 있습니다. 이 구성을 사용하면 모든 요청이 Front Door에서 처리되고 스토리지 계정의 콘텐츠가 인터넷에 직접 노출되는 것을 방지할 수 있습니다. 그러나 이 구성에는 Azure Front Door의 프리미엄 계층이 필요합니다. 표준 계층을 사용하는 경우 스토리지 계정에 공개적으로 액세스할 수 있어야 합니다.
사용자 지정 도메인 이름
Azure Front Door는 사용자 지정 도메인 이름을 지원하며 해당 도메인에 대한 TLS 인증서를 발급 및 관리할 수 있습니다. 사용자 지정 도메인을 사용하면 클라이언트가 신뢰할 수 있고 친숙한 도메인 이름에서 파일을 수신하고 TLS가 Front Door에 대한 모든 연결을 암호화하도록 할 수 있습니다. Front Door에서 TLS 인증서를 관리하면 유효하지 않거나 오래된 TLS 인증서로 인한 중단 및 보안 문제를 방지할 수 있습니다.
Azure Storage는 사용자 지정 도메인 이름도 지원하지만 사용자 지정 도메인을 사용할 때는 HTTPS를 지원하지 않습니다. Front Door는 스토리지 계정과 함께 사용자 지정 도메인 이름을 사용하기 위한 가장 좋은 방법입니다.
시나리오 배포
Bicep을 사용하여 이 시나리오를 배포하려면 Blob 원본 및 Private Link를 사용하여 Azure Front Door Premium 배포를 참조하세요.
다음 단계
Front Door 프로필 만들기 방법에 대해 알아봅니다.