서버리스 웹 애플리케이션

Microsoft Entra ID

Azure API Management

Azure Blob Storage

Azure Content Delivery Network

Azure 기능

Azure Monitor

이 참조 아키텍처에서는 서버리스 웹 애플리케이션을 보여줍니다. 이 애플리케이션은 Azure Blob Storage의 정적 콘텐츠를 제공하고 Azure Functions를 사용하여 API를 구현합니다. API는 Azure Cosmos DB에서 데이터를 읽고 결과를 웹앱에 반환합니다.

GitHub 로고 이 아키텍처에 대한 두 가지 참조 구현은 GitHub 에서 사용할 수 있습니다. 즉, ARM 및 Azure Pipelines(드론 배달 앱) 및 할 일 앱(Bicep 및 GitHub Actions)입니다.

아키텍처

서버리스 웹 애플리케이션을 위한 참조 아키텍처를 보여 주는 다이어그램

이 아키텍처의 Visio 파일을 다운로드합니다.

'서버리스'라는 용어에는 별도의 관련된 두 가지 의미가 있습니다.

BaaS(Backend as a Service). 데이터베이스 및 스토리지와 같은 백 엔드 클라우드 서비스는 클라이언트 애플리케이션에서 이러한 서비스에 직접 연결할 수 있게 하는 API를 제공합니다.
FaaS(Functions as a Service). 이 모델에서 "함수"는 클라우드에 배포되고, 코드를 실행하는 서버를 완전히 추상화하는 호스팅 환경 내에서 실행되는 코드 조각입니다.

두 정의 모두에는 개발자와 DevOps 직원이 서버를 배포, 구성 또는 관리할 필요가 없다는 일반적인 개념이 있습니다. 이 참조 아키텍처는 Azure Functions를 사용하는 FaaS에 중점을 두고 있지만, Azure Blob Storage의 웹 콘텐츠를 제공하는 BaaS의 예가 될 수 있습니다. FaaS에 대한 몇 가지 중요한 특징은 다음과 같습니다.

컴퓨팅 리소스는 필요에 따라 플랫폼별로 동적으로 할당됩니다.
사용량 기반 가격 책정: 코드를 실행하는 데 사용되는 컴퓨팅 리소스에 대해서만 요금이 청구됩니다.
컴퓨팅 리소스는 트래픽 기반 요청에 따라 크기 조정되며, 개발자가 구성할 필요가 없습니다.

Functions는 HTTP 요청 또는 큐에 도착하는 메시지와 같은 외부 트리거가 발생하면 실행됩니다. 그러면 서버리스 아키텍처에서 이벤트 구동 아키텍처 스타일이 자연스럽게 됩니다. 아키텍처에서 구성 요소 간의 작업을 조정하려면 메시지 broker 또는 pub/sub 패턴을 사용하는 것이 좋습니다. Azure에서 메시지 기술을 선택하는 데 도움이 필요하면메시지를 배달하는 Azure 서비스 중에서 선택을 참조하세요.

구성 요소

이 아키텍처는 다음과 같은 구성 요소로 구성됩니다.

Blob Storage HTML, CSS 및 JavaScript 파일과 같은 정적 웹 콘텐츠는 Azure Blob Storage에 저장되며, 정적 웹 사이트 호스팅을 사용하여 클라이언트에 제공됩니다. 모든 동적 상호 작용은 백 엔드 API를 호출하는 JavaScript 코드를 통해 수행됩니다. 웹 페이지를 렌더링할 서버 쪽 코드가 없습니다. 정적 웹 사이트 호스팅은 인덱스 문서 및 404 사용자 지정 오류 페이지를 지원합니다.

CDN. HTTPS 엔드포인트를 제공할 뿐만 아니라 대기 시간을 줄이고 콘텐츠를 빠르게 전송하기 위해 콘텐츠를 캐시하려면 Azure CDN(Content Delivery Network)을 사용합니다.

함수 앱. Azure Functions는 서버리스 컴퓨팅 옵션입니다. 트리거를 통해 코드("함수")가 호출되는 이벤트 구동 모델을 사용합니다. 이 아키텍처에서 함수는 클라이언트에서 HTTP를 요청할 때 호출됩니다. 요청은 항상 아래에 설명된 API 게이트웨이를 통해 라우팅됩니다.

API Management. Azure API Management는 HTTP 함수 앞에 있는 API 게이트웨이를 제공합니다. API Management를 사용하여 클라이언트 애플리케이션에서 사용하는 API를 게시하고 관리할 수 있습니다. 게이트웨이를 사용하면 프런트 엔드 애플리케이션을 백 엔드 API에서 분리할 수 있습니다. 예를 들어 API Management는 URL을 다시 쓰거나, 백 엔드에 도달하기 전에 요청을 변환하거나, 요청 또는 응답 헤더를 설정하는 등의 작업을 수행할 수 있습니다.

API Management는 다음과 같은 교차 편집 문제를 구현하는 데에도 사용할 수 있습니다.

사용 할당량 및 속도 제한 적용
인증을 위한 OAuth 토큰 유효성 검사
CORS(원본 간 요청) 사용
응답 캐싱
요청 모니터링 및 로깅

API Management에서 제공하는 기능 중 일부만 필요한 경우 다른 옵션으로 Functions 프록시를 사용합니다. Azure Functions의 이 기능을 사용하면 백 엔드 함수에 대한 경로를 만들어 여러 함수 앱에 대해 단일 API 화면을 정의할 수 있습니다. Function 프록시는 HTTP 요청 및 응답에 대해 제한된 변환을 수행할 수도 있습니다. 그러나 API Management의 다양한 정책 기반 기능을 동일하게 제공하지는 않습니다.

Azure Cosmos DB. Azure Cosmos DB는 다중 모델 데이터베이스 서비스입니다. 이 시나리오의 경우 함수 애플리케이션은 클라이언트의 HTTP GET 요청에 대한 응답으로 Azure Cosmos DB에서 문서를 가져옵니다.

Microsoft Entra ID (Microsoft Entra ID). 사용자는 Microsoft Entra ID 자격 증명을 사용하여 웹 애플리케이션에 로그인합니다. Microsoft Entra ID는 웹 애플리케이션이 API 요청을 인증하는 데 사용하는 API에 대한 액세스 토큰을 반환합니다(인증 참조).

Azure Monitor Azure Monitor는 솔루션에 배포된 Azure 서비스에 대한 성능 메트릭을 수집합니다. 이러한 메트릭을 대시보드에서 시각화하여 솔루션의 상태를 볼 수 있습니다. 또한 애플리케이션 로그도 수집합니다.

Azure Pipelines. Azure Pipelines는 애플리케이션을 빌드, 테스트 및 배포하는 CI(지속적인 통합) 및 CD(지속적인 업데이트) 서비스입니다.

GitHub Actions. 워크플로는 GitHub 리포지토리에서 설정하는 자동화된 프로세스(CI/CD)입니다. GitHub에서 워크플로를 사용하여 프로젝트를 빌드, 테스트, 패키징, 릴리스 또는 배포할 수 있습니다.

시나리오 정보

잠재적인 사용 사례

이 드론 배달 솔루션은 항공기, 항공, 항공 우주 및 로봇 산업에 이상적입니다.

권장 사항

함수 앱 계획

Azure Functions는 두 가지 호스팅 모델을 지원합니다. 사용 계획을 사용하면 코드가 실행될 때 컴퓨팅 능력이 자동으로 할당됩니다. App Service 계획을 사용하면 코드에 일단의 VM이 할당됩니다. App Service 계획은 VM의 수와 크기를 정의합니다.

위에서 지정한 정의에 따라 App Service 계획은 엄격하게 서버리스가 아닙니다. 프로그래밍 모델은 동일하지만, 동일한 함수 코드가 사용 계획과 App Service 계획 모두에서 실행될 수 있습니다.

사용할 계획 유형을 선택할 때 고려해야 할 몇 가지 요소는 다음과 같습니다.

콜드 부팅. 사용 계획에서 최근에 호출되지 않은 함수는 다음에 실행될 때 약간의 대기 시간이 추가로 발생합니다. 이 추가 대기 시간은 런타임 환경을 할당하고 준비하기 때문입니다. 일반적으로 초 순서에 따라 달라지지만 로드해야 하는 종속성 수를 포함하여 여러 요인에 따라 달라집니다. 자세한 내용은 서버리스 콜드 부팅 이해를 참조하세요. 추가 대기 시간은 사용자가 직접 관찰하므로 콜드 부팅은 일반적으로 비동기 메시지 구동 워크로드(큐 또는 이벤트 허브 트리거)보다 대화형 워크로드(HTTP 트리거)에서 더 큰 문제가 됩니다.
제한 시간. 사용 계획에서 구성 가능한 기간(최대 10분) 후에는 함수 실행 시간이 초과됩니다.
가상 네트워크 격리. App Service 계획을 사용하면 격리된 전용 호스팅 환경인 App Service Environment 내에서 함수가 실행될 수 있습니다.
가격 책정 모델. 사용 계획은 실행 횟수와 리소스 사용량 따라 청구됩니다(메모리 × 실행 시간). App Service 계획은 VM 인스턴스 SKU에 따라 시간당 기준으로 청구됩니다. 사용하는 컴퓨팅 리소스에 대해서만 비용을 지불하므로 사용 계획이 App Service 계획보다 저렴한 경우가 많습니다. 트래픽이 최고점 및 최저점에 있는 경우 특히 그렇습니다. 그러나 애플리케이션에서 지속적으로 대량의 처리량이 발생하는 경우 App Service 계획이 사용 계획보다 비용이 저렴할 수 있습니다.
크기 조정. 소비 모델의 큰 장점은 들어오는 트래픽을 기반으로 하여 필요에 따라 동적으로 크기가 조정된다는 것입니다. 이 크기 조정은 빠르게 수행되지만 여전히 증가 기간이 있습니다. 일부 워크로드의 경우 VM을 의도적으로 과도하게 프로비전하여 램프 업 시간 없이 트래픽 급증을 처리할 수 있습니다. 이 경우 App Service 계획을 사용하는 것이 좋습니다.

함수 앱 경계

함수 앱은 실행할 하나 이상의 함수를 호스팅합니다. 함수 앱을 사용하여 여러 함수를 논리적 단위로 그룹화할 수 있습니다. 함수 앱 내에서 함수는 동일한 애플리케이션 설정, 호스팅 계획 및 배포 수명 주기를 공유합니다. 각 함수 앱에는 자체의 호스트 이름이 있습니다.

함수 앱을 사용하여 동일한 수명 주기와 설정을 공유하는 함수를 그룹화합니다. 동일한 수명 주기를 공유하지 않는 함수는 다른 함수 앱에서 호스팅해야 합니다.

마이크로 서비스 접근 방식을 사용하는 것이 좋습니다. 여기서는 각 함수 앱이 하나의 마이크로 서비스를 나타내며, 몇 가지 관련된 함수로 구성될 수 있습니다. 마이크로 서비스 아키텍처의 경우 서비스에는 느슨한 결합과 높은 기능적 응집력이 있어야 합니다. 느슨한 결합은 다른 서비스를 동시에 업데이트하지 않고도 하나의 서비스를 변경할 수 있다는 것입니다. 응집력은 서비스에 잘 정의된 단일 용도가 있다는 것입니다. 이러한 개념에 대한 자세한 내용은 마이크로 서비스 설계: 도메인 분석을 참조하세요.

Functions 바인딩

가능한 경우 Functions 바인딩을 사용합니다. 바인딩은 코드를 데이터에 연결하고 다른 Azure 서비스와 통합하는 선언적 방법을 제공합니다. 입력 바인딩은 외부 데이터 원본의 입력 매개 변수를 채웁니다. 출력 바인딩은 함수의 반환 값을 큐 또는 데이터베이스와 같은 데이터 싱크로 보냅니다.

예를 들어 참조 구현의 GetStatus 함수는 Azure Cosmos DB 입력 바인딩을 사용합니다. 다음 바인딩은 HTTP 요청의 쿼리 문자열에서 가져온 쿼리 매개 변수를 사용하여 Azure Cosmos DB에서 문서를 조회하도록 구성되어 있습니다. 문서가 발견되면 함수에 매개 변수로 전달됩니다.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

바인딩을 사용하면 서비스와 직접 통신하는 코드를 작성할 필요가 없으므로 함수 코드가 더 간단해지고 데이터 원본 또는 싱크의 세부 정보가 추상화됩니다. 그러나 경우에 따라 바인딩에서 제공하는 것보다 더 복잡한 논리가 필요할 수도 있습니다. 이 경우 Azure 클라이언트 SDK를 직접 사용합니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

확장성

함수. 사용 계획의 경우 HTTP 트리거는 트래픽에 따라 크기 조정됩니다. 동시 함수 인스턴스 수에는 제한이 있지만 각 인스턴스는 한 번에 둘 이상의 요청을 처리할 수 있습니다. App Service 계획의 경우 HTTP 트리거는 VM 인스턴스의 수에 따라 크기 조정됩니다. 즉 VM 인스턴스의 수가 고정된 값이거나 자동 크기 조정 규칙 집합을 기반으로 하여 자동으로 크기 조정될 수 있습니다. 자세한 내용은 Azure Functions 크기 조정 및 호스팅을 참조하세요.

Azure Cosmos DB. Azure Cosmos DB의 처리 용량은 RU(요청 단위)로 측정됩니다. 1RU 처리량은 1KB 문서를 가져오는 데 필요한 GET 처리량에 해당합니다. 10,000RU를 초과하는 Azure Cosmos DB 컨테이너의 크기를 조정하려면 컨테이너를 만들 때 파티션 키를 지정하고, 만드는 모든 문서에 파티션 키가 포함되어야 합니다. 파티션 키에 대한 자세한 내용은 Azure Cosmos DB의 파티션 및 확장을 참조하세요.

API Management. API Management는 규모를 확장하고 규칙 기반 자동 크기 조정을 지원할 수 있습니다. 스케일링 프로세스에는 20분 이상이 걸립니다. 트래픽이 급증하면 예상되는 최대 버스트 트래픽을 제공해야 합니다. 그러나 자동 크기 조정은 시간별 또는 일별 트래픽 변동을 처리하는 데 유용합니다. 자세한 내용은 Azure API Management 인스턴스자동 크기 조정을 참조하세요.

재해 복구

여기에 표시된 배포는 단일 Azure 지역에 있습니다. 재해 복구에 더 탄력적인 방법을 적용하려면 다양한 서비스의 지리적 배포 기능을 활용합니다.

API Management는 여러 Azure 지역에 걸쳐 단일 API Management 인스턴스를 배포하는 데 사용할 수 있는 다중 지역 배포를 지원합니다. 자세한 내용은 여러 Azure 지역에 Azure API Management 서비스 인스턴스를 배포하는 방법을 참조하세요.
Traffic Manager를 사용하여 HTTP 요청을 주 지역으로 라우팅합니다. 해당 지역에서 실행하는 함수 앱을 사용할 수 없게 되면 Traffic Manager에서 보조 지역으로 조치 할 수 있습니다.
Azure Cosmos DB는 다중 마스터 지역을 지원하므로 Azure Cosmos DB 계정에 추가하는 모든 지역에 쓸 수 있습니다. 다중 쓰기를 사용하도록 설정하지 않은 경우에도 주 쓰기 지역을 장애 조치(failover)할 수 있습니다. Azure Cosmos DB 클라이언트 SDK 및 Azure Function 바인딩은 장애 조치(failover)를 자동으로 처리하므로 애플리케이션 구성 설정을 업데이트할 필요가 없습니다.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

인증

참조 구현의 API는 GetStatus Microsoft Entra ID를 사용하여 요청을 인증합니다. Microsoft Entra ID는 OAuth 2 프로토콜을 기반으로 빌드된 인증 프로토콜인 OpenID 커넥트 프로토콜을 지원합니다.

이 아키텍처에서 클라이언트 애플리케이션은 브라우저에서 실행되는 SPA(단일 페이지 애플리케이션)입니다. 이 유형의 클라이언트 애플리케이션은 클라이언트 비밀 또는 권한 부여 코드를 숨길 수 없으므로 암시적 권한 부여 흐름이 적절합니다. 어떤 OAuth 2.0 흐름을 사용해야 합니까?를 참조하세요. 전체 흐름은 다음과 같습니다.

사용자가 웹 애플리케이션에서 "로그인" 링크를 클릭합니다.
브라우저가 Microsoft Entra 로그인 페이지로 리디렉션됩니다.
사용자가 로그인합니다.
Microsoft Entra ID는 URL 조각의 액세스 토큰을 포함하여 클라이언트 애플리케이션으로 다시 리디렉션됩니다.
웹 애플리케이션에서 API를 호출하면 인증 헤더에 액세스 토큰이 포함됩니다. 애플리케이션 ID는 액세스 토큰의 대상 그룹('aud') 클레임으로 보내집니다.
백 엔드 API에서 액세스 토큰의 유효성을 검사합니다.

인증을 구성하려면

Microsoft Entra 테넌트에 애플리케이션을 등록합니다. 그러면 클라이언트에서 로그인 URL에 포함하는 애플리케이션 ID가 생성됩니다.
함수 앱 내에서 Microsoft Entra 인증을 사용하도록 설정합니다. 자세한 내용은 Azure App Service에서 인증 및 권한 부여를 참조하세요.
액세스 토큰의 유효성을 검사하여 요청을 사전 승인하는 validate-jwt policy 정책을 API Management에 추가합니다.

자세한 내용은 GitHub 추가 정보를 참조하세요.

클라이언트 애플리케이션 및 백 엔드 API에 대한 Microsoft Entra ID에 별도의 앱 등록을 만드는 것이 좋습니다. 클라이언트 애플리케이션에 API를 호출하는 권한을 부여합니다. 이 방법은 여러 API 및 클라이언트를 정의하고 각각에 대한 사용 권한을 제어할 유연성을 제공합니다.

API 내에서 범위를 사용하여 애플리케이션이 사용자로부터 요청한 사용 권한을 세부적으로 제어할 수 있습니다. 예를 들어 API에는 Read 및 Write 범위가 포함될 수 있고, 특정 클라이언트 앱은 Read 권한만을 부여하도록 사용자에게 요청할 수 있습니다.

권한 부여

많은 애플리케이션에서 백 엔드 API는 사용자에게 지정된 작업을 수행할 권한이 있는지 여부를 확인해야 합니다. 클레임 기반 권한 부여를 사용하는 것이 좋습니다. 여기서 사용자에 대한 정보는 ID 공급자(이 경우 Microsoft Entra ID)에 의해 전달되고 권한 부여 결정을 내리는 데 사용됩니다. 예를 들어 Microsoft Entra ID에 애플리케이션을 등록할 때 애플리케이션 역할 집합을 정의할 수 있습니다. 사용자가 애플리케이션에 로그인하면 Microsoft Entra ID에는 그룹 멤버 자격을 통해 상속된 역할을 포함하여 사용자에게 부여된 각 역할에 대한 클레임이 포함 roles 됩니다.

Microsoft Entra ID가 클라이언트에 반환하는 ID 토큰에는 사용자의 클레임 중 일부가 포함됩니다. 함수 앱 내에서 이러한 클레임은 요청의 X-MS-CLIENT-PRINCIPAL 헤더에서 사용할 수 있습니다. 그러나 바인딩 데이터에서 이 정보를 읽는 것이 더 간단합니다. 다른 클레임의 경우 Microsoft Graph를 사용하여 Microsoft Entra ID를 쿼리합니다. (로그인 중에 사용자가 이 작업에 동의해야 합니다.)

자세한 내용은 클라이언트 ID 사용을 참조하세요.

CORS

이 참조 아키텍처에서 웹 애플리케이션과 API는 동일한 원본을 공유하지 않습니다. 즉, 애플리케이션이 API를 호출할 때 원본 간 요청입니다. 브라우저 보안은 웹 페이지에서 다른 도메인으로 AJAX 요청을 수행하지 못하도록 방지합니다. 이 제한은 동일 원본 정책이라고 하며, 악성 사이트에서 다른 사이트의 중요한 데이터를 읽지 못하도록 차단합니다. 원본 간 요청을 사용하려면 CORS(원본 간 요청) 정책을 API Management 게이트웨이에 추가합니다.

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

이 예제에서 allow-credentials 특성은 true입니다. 그러면 요청과 함께 자격 증명(쿠키 포함)을 보낼 수 있는 권한을 브라우저에 부여합니다. 그렇지 않으면 기본적으로 브라우저는 원본 간 요청과 함께 자격 증명을 보내지 않습니다.

참고 항목

allow-credentials는 매우 신중하게 true로 설정해야 합니다. 이렇게 하면 사용자가 알지 못하는 사이에 웹 사이트에서 해당 사용자를 대신하여 사용자의 자격 증명을 API로 보낼 수 있기 때문입니다. 허용된 원본을 신뢰해야 합니다.

HTTPS 적용

보안을 극대화하려면 요청 파이프라인 전체에 HTTPS가 필요합니다.

CDN. Azure CDN은 기본적으로 *.azureedge.net 하위 도메인에서 HTTPS를 지원합니다. 사용자 지정 도메인 이름에 대해 CDN에서 HTTPS를 사용하도록 설정하려면 자습서: Azure CDN 사용자 지정 도메인에서 HTTPS 구성을 참조하세요.
정적 웹 사이트 호스팅. 스토리지 계정에서 "보안 전송 필요" 옵션을 사용하도록 설정합니다. 이 옵션을 사용하도록 설정하면 스토리지 계정에서 보안 HTTPS 연결의 요청만 허용합니다.

API Management. HTTPS 프로토콜만 사용하도록 API를 구성합니다. Azure Portal 또는 Resource Manager 템플릿을 통해 이를 구성할 수 있습니다.

{
    "apiVersion": "2018-01-01",
    "type": "apis",
    "name": "dronedeliveryapi",
    "dependsOn": [
        "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
    ],
    "properties": {
        "displayName": "Drone Delivery API",
        "description": "Drone Delivery API",
        "path": "api",
        "protocols": [ "HTTPS" ]
    },
    ...
}

Azure Functions. "HTTPS만" 설정을 사용하도록 설정합니다.

함수 앱 잠금

모든 함수 호출은 API 게이트웨이를 통해 이동해야 합니다. 이 작업은 다음과 같이 수행할 수 있습니다.

함수 키를 요구하도록 함수 앱을 구성합니다. 함수 앱을 호출하면 API Management 게이트웨이에 함수 키가 포함됩니다. 이렇게 하면 클라이언트에서 게이트웨이를 무시하여 직접 함수를 호출하지 못하도록 차단합니다.
API Management 게이트웨이에는 고정 IP 주소가 있습니다. Azure Function을 제한하여 고정 IP 주소의 호출만 허용합니다. 자세한 내용은 Azure App Service 고정 IP 제한을 참조하세요. 이 기능은 표준 계층 서비스에서만 사용할 수 있습니다.

애플리케이션 비밀 보호

애플리케이션 비밀(예: 데이터베이스 자격 증명)은 코드 또는 구성 파일에 저장하지 않습니다. 대신, Azure에서 암호화되어 저장되는 [앱 설정]을 사용합니다. 자세한 내용은 Azure App Service 및 Azure Functions의 보안을 참조하세요.

또는 Key Vault에 애플리케이션 비밀을 저장할 수 있습니다. 이렇게 하면 비밀 스토리지를 중앙 집중화하고, 해당 배포를 제어하며, 비밀에 액세스하는 방법과 시기를 모니터링할 수 있습니다. 자세한 내용은 자습서: Key Vault에서 비밀을 읽도록 Azure 웹 애플리케이션 구성을 참조하세요. 그러나 Functions 트리거와 바인딩은 앱 설정에서 해당 구성 설정을 로드합니다. Key Vault 비밀을 사용하도록 트리거 및 바인딩을 구성하는 기본 제공 방법은 없습니다.

DevOps

프런트 엔드 배포

이 참조 아키텍처의 프런트 엔드는 JavaScript가 서버리스 백 엔드 API에 액세스하고 정적 콘텐츠가 빠른 사용자 환경을 제공하는 단일 페이지 애플리케이션입니다. 다음은 이러한 애플리케이션에 대한 몇 가지 중요한 고려 사항입니다.

클라우드에서 호스팅되는 정적 콘텐츠를 사용하여 전역 준비 CDN에서 광범위한 지리적 영역의 사용자에게 애플리케이션을 균일하게 배포합니다. 이렇게 하면 전용 웹 서버가 필요하지 않습니다. 시작하려면 Azure CDN과 Azure Storage 계정 통합을 읽어보세요. HTTPS를 사용하여 애플리케이션을 보호합니다. 추가 권장 사항은 콘텐츠 배달 네트워크 사용에 대한 모범 사례를 읽어보세요.
Azure Pipelines 또는 GitHub Actions 같은 빠르고 신뢰할 수 있는 CI/CD 서비스를 사용하여 모든 원본 변경 사항을 자동으로 빌드하고 배포합니다. 원본은 온라인 버전 제어 시스템에 있어야 합니다. Azure Pipelines에 대한 자세한 내용은 첫 번째 파이프라인 만들기를 읽어보세요. Azure용 GitHub Actions에 대한 자세한 내용은 Azure에 앱 배포를 참조하세요.
웹 사이트 파일을 압축하여 CDN의 대역폭 소비를 줄이고 성능을 향상시킵니다. Azure CDN은 에지 서버에서 즉각적인 압축을 허용합니다. 또는 이 참조 아키텍처의 배포 파이프라인은 Blob Storage에 배포하기 전에 파일을 압축합니다. 이렇게 하면 스토리지 요구 사항이 줄어들고 CDN 제한에 관계없이 압축 도구를 자유롭게 선택할 수 있습니다.
CDN은 모든 사용자에게 최신 콘텐츠가 제공되도록 캐시를 제거할 수 있어야 합니다. 예를 들어 빌드 및 배포 프로세스가 원자적이지 않은 경우 캐시 제거가 필요합니다. 예를 들어 이전 파일을 동일한 원본 폴더에 새로 빌드된 파일로 바꾸는 경우입니다.
디렉터리를 사용한 버전 관리 등의 다른 캐시 전략은 CDN에서 제거하지 않아도 될 수 있습니다. 이 프런트 엔드 애플리케이션의 빌드 파이프라인은 새로 빌드된 각 버전에 대한 새 디렉터리를 만듭니다. 이 버전은 Blob Storage에 원자 단위로 업로드됩니다. Azure CDN은 배포가 완료된 후에만 이 새 버전을 가리킵니다.
리소스 파일을 더 오랜 기간(수개월)에 걸쳐 캐싱하여 캐시 TTL을 늘입니다. 캐시된 파일이 변경될 때 업데이트되도록 하려면 다시 빌드할 때 파일 이름을 지문으로 찍습니다. 이 프런트 엔드 애플리케이션은 “index.html”과 같은 퍼블릭 파일을 제외한 모든 파일에 지문을 지정합니다. index.html은 자주 업데이트되므로 캐시 새로 고침을 일으키는 변경된 파일 이름이 반영됩니다. 자세한 내용은 Azure CDN의 웹 콘텐츠 만료 관리를 참조하세요.

백 엔드 배포

함수 앱을 배포하려면 패키지 파일("패키지에서 실행")을 사용하는 것이 좋습니다. 이 방법을 사용하면 Blob Storage 컨테이너에 zip 파일을 업로드하고, Functions 런타임은 읽기 전용 파일 시스템으로 zip 파일을 탑재합니다. 실패한 배포로 인해 애플리케이션이 일관성이 없는 상태로 남겨질 가능성을 줄일 수 있는 원자성 조작입니다. 한 번에 모든 파일이 교환되기 때문에 특히 Node.js 앱의 경우 콜드 시작 시간을 개선할 수도 있습니다.

API 버전 관리

API는 서비스와 클라이언트 간의 계약입니다. 이 아키텍처에서 API 계약은 API Management 계층에서 정의됩니다. API Management는 각각 별개이지만 상호 보완 관계인 두 가지 버전 관리 개념을 지원합니다.

버전을 사용하면 API 소비자가 요구 사항에 따라 API 버전을 선택할 수 있습니다(예: v1 및 v2).
수정 버전을 통해 API 관리자는 API에서 호환성이 손상되지 않는 변경 작업을 수행하고 변경 내용을 배포할 수 있으며, 변경 로그를 통해 API 소비자에게 변경 관련 정보를 제공할 수 있습니다.

API에서 호환성이 손상되는 변경을 수행하는 경우 API Management에서 새 버전을 게시합니다. 새 버전은 원래 버전과 함께 별도의 함수 앱에 배포됩니다. 이렇게 하면 클라이언트 애플리케이션을 중단하지 않고 기존 클라이언트를 새 API로 마이그레이션할 수 있습니다. 결국에는 이전 버전을 더 이상 사용하지 않을 수 있습니다. API Management는 URL 경로, HTTP 헤더 또는 쿼리 문자열과 같은 여러 버전 관리 체계를 지원합니다. 일반적인 API 버전 관리에 대한 자세한 내용은 RESTful 웹 API 버전 관리를 참조하세요.

API 변경 내용을 위반하지 않는 업데이트의 경우 동일한 함수 앱의 스테이징 슬롯에 새 버전을 배포합니다. 배포가 성공했는지 확인한 다음, 준비된 버전을 프로덕션 버전으로 바꿉니다. API Management에서 수정 버전을 게시합니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

Azure 가격 계산기를 사용하여 비용을 예측합니다. 이러한 사항을 고려하여 이 아키텍처의 비용을 최적화합니다.

Azure Functions

Azure Functions는 두 가지 호스팅 모델을 지원합니다.

사용 플랜.

코드가 실행되면 컴퓨팅 성능이 자동으로 할당됩니다.
App Service 플랜.

코드에 VM 집합이 할당됩니다. 이 플랜은 VM의 수와 크기를 정의합니다.

이 아키텍처에서 클라이언트에서 HTTP를 요청할 때 함수가 호출됩니다. 이 사용 사례 에서는 일정한 대용량 처리량이 예상되지 않으므로 사용하는 컴퓨팅 리소스에 대해서만 비용을 지불하므로 사용 계획을 사용하는 것이 좋습니다.

Azure Cosmos DB

Azure Cosmos DB는 프로비저닝된 처리량 및 사용된 스토리지에 대한 시간당 요금을 청구합니다. 프로비저닝된 처리량은 초당 요청 단위(RU/s)로 표현되며 삽입, 읽기와 같은 일반적인 데이터베이스 작업에 사용할 수 있습니다. 가격은 예약한 RU/s의 용량을 기준으로 합니다.

스토리지는 저장된 데이터 및 인덱스용으로 사용되는 각 GB에 대해 청구됩니다.

자세한 내용은 Azure Cosmos DB 가격 책정 모델을 참조하세요.

이 아키텍처에서 함수 애플리케이션은 클라이언트의 HTTP GET 요청에 대한 응답으로 Azure Cosmos DB에서 문서를 가져옵니다. 읽기 작업은 RU/s로 나타낸 쓰기 작업보다 훨씬 저렴하기 때문에 이 경우에 Azure Cosmos DB가 비용 효율적입니다.

Content Delivery Network

청구 요금은 최종 사용자에게 콘텐츠를 배달하는 원본 서버의 위치를 기준으로 청구 지역에 따라 다를 수 있습니다. 클라이언트의 물리적 위치는 청구 지역이 아닙니다. CDN에서 수행되는 모든 HTTP 또는 HTTPS 요청은 청구 가능 이벤트로, 모든 응답 형식(성공, 실패 또는 기타)을 포함합니다. 응답에 따라 트래픽 양이 달라질 수 있습니다.

이 참조 아키텍처에서 배포는 단일 Azure 지역에 상주합니다.

비용을 절감하려면 리소스 파일을 더 오래 캐싱하고 콘텐츠에 대해 가능한 가장 긴 TTL을 설정하여 캐시 TTL을 늘리는 것이 좋습니다.

자세한 내용은 Microsoft Azure Well-Architected Framework의 비용 섹션을 참조하세요.

시나리오 배포

이 아키텍처에 대한 참조 구현을 배포하려면 GitHub 추가 정보를 참조하세요.

다음 단계

제품 설명서:

학습 모듈:

참조 구현에 대해 자세히 알아보려면 코드 연습: Azure Functions를 사용하는 서버리스 애플리케이션을 읽어보세요.

서버리스 웹 애플리케이션

아키텍처

구성 요소

시나리오 정보

잠재적인 사용 사례

권장 사항

함수 앱 계획

함수 앱 경계

Functions 바인딩

고려 사항

확장성

재해 복구

보안

인증

권한 부여

CORS

HTTPS 적용

함수 앱 잠금

애플리케이션 비밀 보호

DevOps

프런트 엔드 배포

백 엔드 배포

API 버전 관리

비용 최적화

Azure Functions

Azure Cosmos DB

Content Delivery Network

시나리오 배포

다음 단계

피드백

피드백

추가 리소스

서버리스 웹 애플리케이션

아키텍처

구성 요소

시나리오 정보

잠재적인 사용 사례

권장 사항

함수 앱 계획

함수 앱 경계

Functions 바인딩

고려 사항

확장성

재해 복구

보안

인증

권한 부여

CORS

HTTPS 적용

함수 앱 잠금

애플리케이션 비밀 보호

DevOps

프런트 엔드 배포

백 엔드 배포

API 버전 관리

비용 최적화

Azure Functions

Azure Cosmos DB

Content Delivery Network

시나리오 배포

다음 단계

관련 리소스

피드백

피드백

추가 리소스