Azure 上のサーバーレス Web アプリケーションServerless web application on Azure

この参照アーキテクチャは、サーバーレス Web アプリケーションを示しています。This reference architecture shows a serverless web application. このアプリケーションでは Azure Blob Storage から静的コンテンツを提供し、Azure Functions を使用して API が実装されます。The application serves static content from Azure Blob Storage, and implements an API using Azure Functions. API は Cosmos DB からデータを読み取り、結果を Web アプリに返します。The API reads data from Cosmos DB and returns the results to the web app.

GitHub ロゴ このアーキテクチャのリファレンス実装は、GitHub で入手できます。GitHub logo A reference implementation for this architecture is available on GitHub.

サーバーレス Web アプリケーションの参照アーキテクチャ

サーバーレスという言葉は 2 つの異なる意味を持ちますが、この 2 つの意味は関連しています。The term serverless has two distinct but related meanings:

  • サービスとしてのバックエンド (BaaS)。Backend as a service (BaaS). データベースやストレージなどのバックエンド クラウド サービスには、クライアント アプリケーションがこれらのサービスに直接接続できるようにする API が用意されています。Back-end cloud services, such as databases and storage, provide APIs that enable client applications to connect directly to these services.
  • サービスとしての関数 (FaaS)。Functions as a service (FaaS). このモデルでは、"関数" はクラウドにデプロイされるひとまとまりのコードで、コードを実行するサーバーが完全に抽象化されたホスティング環境内で実行されます。In this model, a "function" is a piece of code that is deployed to the cloud and runs inside a hosting environment that completely abstracts the servers that run the code.

両方の定義に共通しているのは、開発者と DevOps スタッフが、サーバーをデプロイ、構成、または管理する必要がないというアイデアです。Both definitions have in common the idea that developers and DevOps personnel don't need to deploy, configure, or manage servers. Azure Blob Storage からの Web コンテンツ提供は BaaS の一例ですが、この参照アーキテクチャでは、Azure Functions を使用した FaaS に重点を置いています。This reference architecture focuses on FaaS using Azure Functions, although serving web content from Azure Blob Storage could be an example of BaaS. FaaS の重要な特性をいくつか次に示します。Some important characteristics of FaaS are:

  1. コンピューティング リソースが、プラットフォームによって必要に応じて動的に割り当てられます。Compute resources are allocated dynamically as needed by the platform.
  2. 使用量ベースの価格:ご自身のコードの実行に使用されたコンピューティング リソースに対してのみ課金されます。Consumption-based pricing: You are charged only for the compute resources used to execute your code.
  3. コンピューティング リソースがトラフィックに基づいてオンデマンドでスケーリングされます。開発者が構成する必要はありません。The compute resources scale on demand based on traffic, without the developer needing to do any configuration.

HTTP 要求やメッセージがキューに到着するなど、外部トリガーが発生すると、関数が実行されます。Functions are executed when an external trigger occurs, such as an HTTP request or a message arriving on a queue. このため、サーバーレス アーキテクチャにとって、イベント ドリブン アーキテクチャのスタイルが自然になります。This makes an event-driven architecture style natural for serverless architectures. アーキテクチャでのコンポーネント間の動作を調整するには、メッセージ ブローカーまたはパブリッシュ/サブスクライブ パターンの使用を検討してください。To coordinate work between components in the architecture, consider using message brokers or pub/sub patterns. Azure でのメッセージング テクノロジの選択に関するヘルプについては、「メッセージを配信する Azure サービスの選択」を参照してください。For help with choosing between messaging technologies in Azure, see Choose between Azure services that deliver messages.

ArchitectureArchitecture

アーキテクチャは、次のコンポーネントで構成されています。The architecture consists of the following components:

Blob StorageBlob Storage. HTML、CSS、JavaScript ファイルなどの静的 Web コンテンツは Azure Blob Storage に格納され、静的 Web サイトのホスティングを使用してクライアントに提供されます。Static web content, such as HTML, CSS, and JavaScript files, are stored in Azure Blob Storage and served to clients by using static website hosting. 動的な対話はすべて、バックエンド API を呼び出す JavaScript コードを介して行われます。All dynamic interaction happens through JavaScript code making calls to the back-end APIs. Web ページをレンダリングするサーバー側のコードはありません。There is no server-side code to render the web page. 静的な Web サイトのホスティングでは、インデックス ドキュメントとカスタム 404 エラー ページがサポートされます。Static website hosting supports index documents and custom 404 error pages.

CDNCDN. Azure Content Delivery Network (CDN) を使用して、待機時間を短縮してコンテンツを高速に配信できるようにコンテンツをキャッシュし、HTTPS エンドポイントを提供します。Use Azure Content Delivery Network (CDN) to cache content for lower latency and faster delivery of content, as well as providing an HTTPS endpoint.

Function AppFunction Apps. Azure Functions はサーバーレス コンピューティングの 1 つのオプションです。Azure Functions is a serverless compute option. ひとまとまりのコード ("関数") がトリガーによって呼び出されるイベント ドリブン モデルが使用されます。It uses an event-driven model, where a piece of code (a "function") is invoked by a trigger. このアーキテクチャでは、関数は、クライアントが HTTP 要求を行うと呼び出されます。In this architecture, the function is invoked when a client makes an HTTP request. 要求は、以下で説明するように、常に API ゲートウェイ経由でルーティングされます。The request is always routed through an API gateway, described below.

API ManagementAPI Management. API Management では、HTTP 関数の前に配置される API ゲートウェイが提供されます。API Management provides an API gateway that sits in front of the HTTP function. API Management を使用すると、クライアント アプリケーションで使用される API を発行および管理できます。You can use API Management to publish and manage APIs used by client applications. ゲートウェイは、バックエンド API からフロントエンド アプリケーションを分離するのに役立ちます。Using a gateway helps to decouple the front-end application from the back-end APIs. たとえば、API Management では、URL の再書き込み、バックエンドに到達する前の要求の変換、要求または応答ヘッダーの設定などを行うことができます。For example, API Management can rewrite URLs, transform requests before they reach the back end, set request or response headers, and so forth.

API Management を使って、複数のサービスにまたがる、次のような機能を実装することもできます。API Management can also be used to implement cross-cutting concerns such as:

  • 使用量クォータとレート制限の強制Enforcing usage quotas and rate limits
  • 認証用の OAuth トークンの検証Validating OAuth tokens for authentication
  • クロス オリジン要求 (CORS) の有効化Enabling cross-origin requests (CORS)
  • 応答のキャッシュCaching responses
  • 要求の監視とログ記録Monitoring and logging requests

API Management によって提供される一部の機能が不要の場合は、別の選択肢として関数プロキシを使用できます。If you don't need all of the functionality provided by API Management, another option is to use Functions Proxies. Azure Functions のこの機能を使用すると、バックエンド関数へのルートを作成することで、複数の関数アプリに対して 1 つの API サーフェスを定義できます。This feature of Azure Functions lets you define a single API surface for multiple function apps, by creating routes to back-end functions. 関数プロキシによって、HTTP 要求および応答で制限付き変換を実行することもできます。Function proxies can also perform limited transformations on the HTTP request and response. ただし、API Management ほど豊富なポリシー ベース機能は用意されていません。However, they don't provide the same rich policy-based capabilities of API Management.

Cosmos DBCosmos DB. Cosmos DB は、マルチモデル データベース サービスです。Cosmos DB is a multi-model database service. このシナリオでは、関数アプリケーションは、クライアントからの HTTP GET 要求に応答して Cosmos DB からドキュメントをフェッチします。For this scenario, the function application fetches documents from Cosmos DB in response to HTTP GET requests from the client.

Azure Active Directory (Azure AD)。Azure Active Directory (Azure AD). ユーザーは、自身の Azure AD 資格情報を使用して Web アプリケーションにサインインします。Users sign into the web application by using their Azure AD credentials. Azure AD から API のアクセス トークンが返されます。Web アプリケーションはこれを使って API 要求を認証します (「認証」を参照)。Azure AD returns an access token for the API, which the web application uses to authenticate API requests (see Authentication).

Azure MonitorAzure Monitor. Monitor は、ソリューションにデプロイされた Azure サービスに関するパフォーマンス メトリックを収集します。Monitor collects performance metrics about the Azure services deployed in the solution. ダッシュボードでこれらを視覚化することで、ソリューションの正常性を把握できます。By visualizing these in a dashboard, you can get visibility into the health of the solution. アプリケーション ログも収集されます。It also collected application logs.

Azure PipelinesAzure Pipelines. Pipelines は、アプリケーションをビルド、テスト、デプロイする継続的インテグレーション (CI) および継続的デリバリー (CD) サービスです。Pipelines is a continuous integration (CI) and continuous delivery (CD) service that builds, tests, and deploys the application.

RecommendationsRecommendations

Function App プランFunction App plans

Azure Functions では 2 つのホスティング モデルがサポートされています。Azure Functions supports two hosting models. 従量課金プランでは、コードの実行時にコンピューティング能力が自動的に割り当てられます。With the consumption plan, compute power is automatically allocated when your code is running. App Service プランでは、一連の VM がお使いのコードに対して割り当てられます。With the App Service plan, a set of VMs are allocated for your code. App Service プランで定義されるのは VM の数とサイズです。The App Service plan defines the number of VMs and the VM size.

上記の定義に従うと、App Service プランは厳密には "サーバーレス" ではありません。Note that the App Service plan is not strictly serverless, according to the definition given above. プログラミング モデルは同じですが、従量課金プランと App Service プランの両方で、同じ関数コードを実行できます。The programming model is the same, however — the same function code can run in both a consumption plan and an App Service plan.

使用するプランの種類を選択するときに検討すべき要素を、次に示します。Here are some factors to consider when choosing which type of plan to use:

  • コールド スタートCold start. 従量課金プランでは、最近呼び出されていない関数の場合、次回の実行時に待ち時間が少し長くなります。With the consumption plan, a function that hasn't been invoked recently will incur some additional latency the next time it runs. この追加の待ち時間は、ランタイム環境の割り当てと準備が原因で発生します。This additional latency is due to allocating and preparing the runtime environment. 通常は数秒程度ですが、読み込む必要がある依存関係の数など、いくつかの要因によって異なってきます。It is usually on the order of seconds but depends on several factors, including the number of dependencies that need to be loaded. 詳細については、「Understanding Serverless Cold Start (サーバーレスのコールド スタートについて)」を参照してください。For more information, see Understanding Serverless Cold Start. 通常、コールド スタートが問題になるのは、非同期のメッセージ ドリブン ワークロード (キューまたはイベント ハブ トリガー) よりも対話型ワークロード (HTTP トリガー) です。対話型ワークロードでは、ユーザーが待ち時間が長くなったことに直接気付くためです。Cold start is usually more of a concern for interactive workloads (HTTP triggers) than asynchronous message-driven workloads (queue or event hubs triggers), because the additional latency is directly observed by users.
  • タイムアウト時間Timeout period. 従量課金プランでは、構成可能な期間 (最大 10 分) が経過すると関数の実行はタイムアウトしますIn the consumption plan, a function execution times out after a configurable period of time (to a maximum of 10 minutes)
  • 仮想ネットワークの分離Virtual network isolation. App Service プランを使用すると、分離された専用ホスティング環境である App Service 環境内で関数を実行できます。Using an App Service plan allows functions to run inside of an App Service Environment, which is a dedicated and isolated hosting environment.
  • 価格モデルPricing model. 従量課金プランでは、実行数とリソース消費量 (メモリ × 実行時間) によって課金されます。The consumption plan is billed by the number of executions and resource consumption (memory × execution time). App Service プランでは、VM インスタンス SKU に基づいて 1 時間ごとに課金されます。The App Service plan is billed hourly based on VM instance SKU. 従量課金プランは、使用したコンピューティング リソースにしか支払いが発生しないため、多くの場合 App Service プランよりもコストがかかりません。Often, the consumption plan can be cheaper than an App Service plan, because you pay only for the compute resources that you use. これは、トラフィックに山と谷がある場合に特に当てはまります。This is especially true if your traffic experiences peaks and troughs. ただし、アプリケーションのスループットが一定して高い場合は、App Service プランの方が従量課金プランよりも低コストになる可能性があります。However, if an application experiences constant high-volume throughput, an App Service plan may cost less than the consumption plan.
  • スケーリングScaling. 従量課金モデルの大きな利点は、着信トラフィックに基づいて、必要に応じて動的にスケーリングされることです。A big advantage of the consumption model is that it scales dynamically as needed, based on the incoming traffic. このスケーリングは迅速に行われますが、やはり準備期間はあります。While this scaling occurs quickly, there is still a ramp-up period. 一部のワークロードでは、準備時間なしでトラフィックのバーストを処理できるように、VM の意図的オーバープロビジョニングが必要なことがあります。For some workloads, you might want to deliberately overprovision the VMs, so that you can handle bursts of traffic with zero ramp-up time. その場合は、App Service プランを検討してください。In that case, consider an App Service plan.

Function App の境界Function App boundaries

"関数アプリ" によって、1 つ以上の "関数" の実行がホストされます。A function app hosts the execution of one or more functions. 関数アプリを使用すると、複数の関数を 1 つの論理ユニットとしてまとめることができます。You can use a function app to group several functions together as a logical unit. 関数アプリ内の関数は、同じアプリケーション設定、ホスティング プラン、およびデプロイ ライフサイクルを共有しています。Within a function app, the functions share the same application settings, hosting plan, and deployment lifecycle. 関数アプリはそれぞれ独自のホスト名を持ちます。Each function app has its own hostname.

関数アプリを使用して、同じライフサイクルと設定を共有する関数をグループ化します。Use function apps to group functions that share the same lifecycle and settings. 同じライフサイクルを共有していない関数は、別の関数アプリでホストする必要があります。Functions that don't share the same lifecycle should be hosted in different function apps.

マイクロサービス アプローチを使用することを検討します。このアプローチでは、各関数アプリが 1 つのマイクロサービスを表しており、関連する複数の関数で構成されている可能性があります。Consider taking a microservices approach, where each function app represents one microservice, possibly consisting of several related functions. マイクロサービス アーキテクチャのサービスには、疎結合と、機能の高い凝集度が必要です。In a microservices architecture, services should have loose coupling and high functional cohesion. "" 結合とは、他のサービスを同時に更新しなくても、あるサービスを変更できることを意味します。Loosely coupled means you can change one service without requiring other services to be updated at the same time. "高凝集" とは、明確に定義された 1 つの目的をサービスが持つことを意味します。Cohesive means a service has a single, well-defined purpose. これらのアイデアの詳細については、「マイクロサービスの設計:ドメイン分析」を参照してください。For more discussion of these ideas, see Designing microservices: Domain analysis.

関数のバインディングFunction bindings

可能な場合は、関数のバインディングを使用します。Use Functions bindings when possible. バインディングにより、お使いのコードをデータに接続し、他の Azure サービスと統合するために宣言型の方法が提供されます。Bindings provide a declarative way to connect your code to data and integrate with other Azure services. 入力バインディングでは、入力パラメーターが外部データ ソースから設定されます。An input binding populates an input parameter from an external data source. 出力バインディングでは、キューやデータベースなどのデータ シンクに関数の戻り値が送信されます。An output binding sends the function's return value to a data sink, such as a queue or database.

たとえば、リファレンス実装の GetStatus 関数では、Cosmos DB の入力バインディングが使用されます。For example, the GetStatus function in the reference implementation uses the Cosmos DB input binding. このバインディングは、HTTP 要求のクエリ文字列から取得されるクエリ パラメーターを使用して、Cosmos DB のドキュメントを検索するように構成されています。This binding is configured to look up a document in Cosmos DB, using query parameters that are taken from the query string in the HTTP request. ドキュメントが見つかった場合、そのドキュメントは関数にパラメーターとして渡されます。If the document is found, it is passed to the function as a parameter.

[FunctionName("GetStatusFunction")]
public static Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
    [CosmosDB(
        databaseName: "%COSMOSDB_DATABASE_NAME%",
        collectionName: "%COSMOSDB_DATABASE_COL%",
        ConnectionStringSetting = "COSMOSDB_CONNECTION_STRING",
        Id = "{Query.deviceId}",
        PartitionKey = "{Query.deviceId}")] dynamic deviceStatus,
    ILogger log)
{
    ...
}

バインディングを使用すると、サービスと直接通信するコードを記述する必要がありません。これにより関数コードが簡単になるだけでなく、データ ソースまたはシンクの詳細が抽象化されます。By using bindings, you don't need to write code that talks directly to the service, which makes the function code simpler and also abstracts the details of the data source or sink. ただし、場合によっては、バインディングが提供するよりも複雑なロジックが必要になる可能性があります。In some cases, however, you may need more complex logic than the binding provides. その場合は、Azure のクライアント SDK を直接使用します。In that case, use the Azure client SDKs directly.

スケーラビリティに関する考慮事項Scalability considerations

FunctionsFunctions. 従量課金プランの場合、HTTP トリガーはトラフィックに基づいてスケーリングされます。For the consumption plan, the HTTP trigger scales based on the traffic. コンカレント関数インスタンスの数には制限がありますが、それぞれのインスタンスが一度に複数の要求を処理できます。There is a limit to the number of concurrent function instances, but each instance can process more than one request at a time. App Service プランでは、HTTP トリガーは VM インスタンスの数に応じてスケーリングされます。この数は固定値にすることも、一連の自動スケーリング ルールに基づいて自動スケーリングすることもできます。For an App Service plan, the HTTP trigger scales according to the number of VM instances, which can be a fixed value or can autoscale based on a set of autoscaling rules. 詳細については、「Azure Functions のスケールとホスティング」を参照してください。For information, see Azure Functions scale and hosting.

Cosmos DBCosmos DB. Cosmos DB のスループット容量は、要求ユニット (RU) で測定されます。Throughput capacity for Cosmos DB is measured in Request Units (RU). 1 RU のスループットは、1 KB のドキュメントを取得するのに必要なスループットに対応します。A 1-RU throughput corresponds to the throughput need to GET a 1KB document. Cosmos DB コンテナーを 10,000 RU を超えてスケーリングするには、コンテナーの作成時にパーティション キーを指定し、作成するすべてのドキュメントにパーティション キーを含める必要があります。In order to scale a Cosmos DB container past 10,000 RU, you must specify a partition key when you create the container and include the partition key in every document that you create. パーティション キーの詳細については、「Azure Cosmos DB でのパーティション分割とスケーリング」を参照してください。For more information about partition keys, see Partition and scale in Azure Cosmos DB.

API ManagementAPI Management. API Management はスケールアウトが可能で、ルールベースの自動スケーリングがサポートされます。API Management can scale out and supports rule-based autoscaling. このスケーリング プロセスには、少なくとも 20 分かかります。The scaling process takes at least 20 minutes. トラフィックのバーストが発生する場合は、最大バースト トラフィックの予測に基づいてプロビジョニングする必要があります。If your traffic is bursty, you should provision for the maximum burst traffic that you expect. ただし、自動スケーリングを使えば、時間単位または日単位でトラフィックの変動が処理されるため便利です。However, autoscaling is useful for handling hourly or daily variations in traffic. 詳細については、「Azure API Management インスタンスを自動的にスケーリングする」を参照してください。For more information, see Automatically scale an Azure API Management instance.

ディザスター リカバリーの考慮事項Disaster recovery considerations

ここに示したデプロイは単一の Azure リージョンに存在します。The deployment shown here resides in a single Azure region. ディザスター リカバリーでより回復性に優れたアプローチを実現するには、さまざまなサービスで地理的分散機能を利用します。For a more resilient approach to disaster-recovery, take advantage of the geo-distribution features in the various services:

  • API Management では複数リージョンのデプロイがサポートされており、API Management サービスの単一インスタンスを任意の数の Azure リージョンに分散できます。API Management supports multi-region deployment, which can be used to distribute a single API Management instance across any number of Azure regions. 詳細については、「複数の Azure リージョンに Azure API Management サービス インスタンスをデプロイする方法」を参照してください。For more information, see How to deploy an Azure API Management service instance to multiple Azure regions.

  • Traffic Manager を使用して、HTTP 要求をプライマリ リージョンにルーティングします。Use Traffic Manager to route HTTP requests to the primary region. そのリージョンで実行されている Function App が使用できなくなった場合、Traffic Manager によってセカンダリ リージョンにフェールオーバーできます。If the Function App running in that region becomes unavailable, Traffic Manager can fail over to a secondary region.

  • Cosmos DB では複数のマスター リージョンがサポートされています。これにより、Cosmos DB アカウントに追加した任意のリージョンに書き込むことができます。Cosmos DB supports multiple master regions, which enables writes to any region that you add to your Cosmos DB account. マルチマスターを有効にしなくても、プライマリ書き込みリージョンにはフェールオーバーできます。If you don't enable multi-master, you can still fail over the primary write region. フェールオーバーは、Cosmos DB クライアント SDK と Azure Functions のバインディングによって自動的に処理されるため、アプリケーション構成設定を更新する必要はありません。The Cosmos DB client SDKs and the Azure Function bindings automatically handle the failover, so you don't need to update any application configuration settings.

セキュリティに関する考慮事項Security considerations

認証Authentication

リファレンス実装の GetStatus API では、Azure AD を使用して要求が認証されます。The GetStatus API in the reference implementation uses Azure AD to authenticate requests. Azure AD がサポートするのは OpenID Connect プロトコルで、この認証プロトコルは、OAuth 2 プロトコルを基盤として構築されています。Azure AD supports the OpenID Connect protocol, which is an authentication protocol built on top of the OAuth 2 protocol.

このアーキテクチャでは、クライアント アプリケーションは、ブラウザーで実行されるシングル ページ アプリケーション (SPA) です。In this architecture, the client application is a single-page application (SPA) that runs in the browser. この種類のクライアント アプリケーションでは、クライアントをシークレットにできません。また、認証コードも非表示になりません。このため暗黙的な許可フローが適していますThis type of client application cannot keep a client secret or an authorization code hidden, so the implicit grant flow is appropriate. (Which OAuth 2.0 flow should I use? (使用する必要がある OAuth 2.0 フロー) に関するページをご覧ください)。(See Which OAuth 2.0 flow should I use?). 全体的なフローを次に示します。Here's the overall flow:

  1. ユーザーが Web アプリケーションで "サインイン" リンクをクリックします。The user clicks the "Sign in" link in the web application.
  2. ブラウザーが Azure AD のサインイン ページにリダイレクトされます。The browser is redirected the Azure AD sign in page.
  3. ユーザーがサインインします。The user signs in.
  4. Azure AD がクライアント アプリケーションにもう一度リダイレクトされます。その URL フラグメントにはアクセス トークンが含まれています。Azure AD redirects back to the client application, including an access token in the URL fragment.
  5. Web アプリケーションが API を呼び出すとき、認証ヘッダーにはアクセス トークンが含まれています。When the web application calls the API, it includes the access token in the Authentication header. アプリケーション ID は、アクセス トークンで audience ("aud") クレームとして送信されます。The application ID is sent as the audience ('aud') claim in the access token.
  6. バックエンド API によってアクセス トークンが検証されます。The back-end API validates the access token.

認証を構成するには:To configure authentication:

  • アプリケーションをお使いの Azure AD テナントに登録します。Register an application in your Azure AD tenant. これによりアプリケーション ID が生成されます。クライアントはこれをログイン URL に含めます。This generates an application ID, which the client includes with the login URL.

  • Function App 内の Azure AD 認証を有効にします。Enable Azure AD authentication inside the Function App. 詳細については、「 Azure App Service での認証および承認」を参照してください。For more information, see Authentication and authorization in Azure App Service.

  • API Management に validate-jwt ポリシーを追加し、アクセス トークンを検証することで要求を事前承認できるようにします。Add the validate-jwt policy to API Management to pre-authorize the request by validating the access token.

詳細については、GitHub の Readme を参照してください。For more details, see the GitHub readme.

クライアント アプリケーションとバックエンド API については、Azure AD で個別にアプリ登録を作成することをお勧めします。It's recommended to create separate app registrations in Azure AD for the client application and the back-end API. API を呼び出すアクセス許可をクライアント アプリケーションに付与します。Grant the client application permission to call the API. このアプローチにより、複数の API とクライアントを定義して、それぞれのアクセス許可を柔軟に制御できるようになります。This approach gives you the flexibility to define multiple APIs and clients and control the permissions for each.

API 内では、スコープを使用することにより、アプリケーションでユーザーに要求するアクセス許可を細かく制御できます。Within an API, use scopes to give applications fine-grained control over what permissions they request from a user. たとえば、API に Read スコープと Write スコープを指定し、特定のクライアント アプリが、ユーザーに Read アクセス許可のみを承認するよう求めることができます。For example, an API might have Read and Write scopes, and a particular client app might ask the user to authorize Read permissions only.

承認Authorization

多くのアプリケーションでは、バックエンド API で、ユーザーが特定のアクションを実行するアクセス許可があるかどうかを確認する必要があります。In many applications, the back-end API must check whether a user has permission to perform a given action. クレームベースの承認を使用することをお勧めします。この方法では、ユーザーに関する情報は ID プロバイダー (この例では Azure AD) によって伝達され、承認の判断に使用されます。It's recommended to use claims-based authorization, where information about the user is conveyed by the identity provider (in this case, Azure AD) and used to make authorization decisions. たとえば、Azure AD にアプリケーションを登録するときに、一連のアプリケーション ロールを定義できます。For example, when you register an application in Azure AD, you can define a set of application roles. ユーザーがアプリケーションにサインインするとき、Azure AD には、そのユーザーに付与されたロール (グループ メンバーシップを通じて付与されているロールを含む) ごとに roles 要求が含まれています。When a user signs into the application, Azure AD includes a roles claim for each role that the user has been granted, including roles that are inherited through group membership.

Azure AD からクライアントに返される ID トークンには、一部のユーザー要求が含まれています。The ID token that Azure AD returns to the client contains some of the user's claims. 関数アプリ内では、これらの要求はリクエストの X-MS-CLIENT-PRINCIPAL ヘッダーで利用できます。Within the function app, these claims are available in the X-MS-CLIENT-PRINCIPAL header of the request. ただし、バインディング データからこの情報を読み取る方が簡単です。However, it's simpler to read this information from binding data. その他の要求については、Microsoft Graph を使用して Azure AD に対するクエリを実行します。For other claims, use Microsoft Graph to query Azure AD. (ユーザーはサインイン時にこのアクションに同意する必要があります。)(The user must consent to this action when signing in.)

詳細については、「クライアント ID の操作」を参照してください。For more information, see Working with client identities.

CORSCORS

この参照アーキテクチャでは、Web アプリケーションと API はオリジンを共有しません。In this reference architecture, the web application and the API do not share the same origin. つまり、アプリケーションが API を呼び出す場合、それはクロス オリジン要求になります。That means when the application calls the API, it is a cross-origin request. ブラウザーのセキュリティ機能により、Web ページでは AJAX 要求を別のドメインに送信することはできません。Browser security prevents a web page from making AJAX requests to another domain. この制限は、"同一オリジン ポリシー" と呼ばれ、悪意のあるサイトが、別のサイトから機密データを読み取れないようにします。This restriction is called the same-origin policy and prevents a malicious site from reading sensitive data from another site. クロスオリジン要求を有効にするには、クロスオリジン リソース共有 (CORS) ポリシーを API Management ゲートウェイに追加します。To enable a cross-origin request, add a Cross-Origin Resource Sharing (CORS) policy to the API Management gateway:

<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 になっています。In this example, the allow-credentials attribute is true. これにより、ブラウザーが要求と共に資格情報 (Cookie など) を送信することが承認されます。This authorizes the browser to send credentials (including cookies) with the request. それ以外の場合、既定では、ブラウザーからクロス オリジン要求と共に資格情報が送信されません。Otherwise, by default the browser does not send credentials with a cross-origin request.

注意

allow-credentialstrue に設定すると、Web サイトが、ユーザーの資格情報を、そのユーザーが知らないところでユーザーの代わりに API に送信できるようになるため、注意が必要です。Be very careful about setting allow-credentials to true, because it means a website can send the user's credentials to your API on the user's behalf, without the user being aware. 許可されたオリジンを信頼する必要があります。You must trust the allowed origin.

HTTPS の適用Enforce HTTPS

セキュリティを最大限に高めるには、要求パイプライン全体で HTTPS を使用する必要があります。For maximum security, require HTTPS throughout the request pipeline:

  • CDNCDN. 既定では、Azure CDN は、*.azureedge.net サブドメインで HTTPS をサポートしています。Azure CDN supports HTTPS on the *.azureedge.net subdomain by default. CDN でカスタム ドメイン名に対して HTTPS を有効にするには、「チュートリアル:Azure CDN カスタム ドメインで HTTPS を構成する」を参照してください。To enable HTTPS in the CDN for custom domain names, see Tutorial: Configure HTTPS on an Azure CDN custom domain.

  • 静的 Web サイトのホスティングStatic website hosting. ストレージ アカウントで [安全な転送が必須] オプションを有効にします。Enable the "Secure transfer required" option on the Storage account. このオプションを有効にすると、ストレージ アカウントでは、セキュリティで保護された HTTPS 接続からの要求のみが許可されます。When this option is enabled, the storage account only allows requests from secure HTTPS connections.

  • API ManagementAPI Management. HTTPS プロトコルのみを使用するように API を構成します。Configure the APIs to use HTTPS protocol only. これは、Azure portal または Resource Manager テンプレートを使用して構成できます。You can configure this in the Azure portal or through a Resource Manager template:

    {
        "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 FunctionsAzure Functions. [HTTPS のみ] の設定を有効にします。Enable the "HTTPS Only" setting.

関数アプリのロックダウンLock down the function app

関数へのすべての呼び出しが、API ゲートウェイを経由する必要があります。All calls to the function should go through the API gateway. これは次のように実現できます。You can achieve this as follows:

  • 関数キーを必要とするように関数アプリを構成します。Configure the function app to require a function key. API Management ゲートウェイが関数アプリを呼び出すと、そのゲートウェイに関数キーが追加されます。The API Management gateway will include the function key when it calls the function app. これにより、クライアントはゲートウェイをバイパスして直接関数を呼び出すことができなくなります。This prevents clients from calling the function directly, bypassing the gateway.

  • API Management ゲートウェイには静的 IP アドレスがあります。The API Management gateway has a static IP address. その静的 IP アドレスからの呼び出しのみを許可するように Azure 関数を制限します。Restrict the Azure Function to allow only calls from that static IP address. 詳細については、「Azure App Service 静的 IP 制限」を参照してください。For more information, see Azure App Service Static IP Restrictions. (この機能は、Standard レベルのサービスでのみ使用できます)。(This feature is available for Standard tier services only.)

アプリケーション シークレットの保護Protect application secrets

データベースの資格情報などのアプリケーション シークレット情報を、コードや構成ファイルに保存しないでください。Don't store application secrets, such as database credentials, in your code or configuration files. 代わりに、暗号化された状態で Azure に保存されているアプリ設定を使用します。Instead, use App settings, which are stored encrypted in Azure. 詳しくは、Azure App Service と Azure Functions でのセキュリティに関する記事をご覧ください。For more information, see Security in Azure App Service and Azure Functions.

また、アプリケーション シークレット情報を Key Vault に格納することもできます。Alternatively, you can store application secrets in Key Vault. これにより、シークレットのストレージを一元化し、その配布を制御して、シークレットへのアクセス方法とそのタイミングを監視することができます。This allows you to centralize the storage of secrets, control their distribution, and monitor how and when secrets are being accessed. 詳しくは、Key Vault からシークレットを読み取るための Azure Web アプリケーションの構成に関する記事をご覧ください。For more information, see Configure an Azure web application to read a secret from Key Vault. ただし、その構成設定は、関数のトリガーとバインディングにより、アプリ設定から読み込まれることに注意してください。However, note that Functions triggers and bindings load their configuration settings from app settings. Key Vault のシークレットを使用するようにトリガーとバインディングを構成する方法は、組み込まれていません。There is no built-in way to configure the triggers and bindings to use Key Vault secrets.

DevOps の考慮事項DevOps considerations

フロントエンドのデプロイFront-end deployment

この参照アーキテクチャのフロント エンドは、サーバーレス バックエンド API にアクセスする JavaScript と高速なユーザー エクスペリエンスを提供する静的コンテンツを提供するシングル ページ アプリケーションです。The front end of this reference architecture is a single page application, with JavaScript accessing the serverless back-end APIs, and static content providing a fast user experience. このようなアプリケーションに関する重要な考慮事項を次に示します。The following are some important considerations for such an application:

  • グローバル対応の CDN と、クラウド上でホストされている静的コンテンツを使用して、地理的に離れた場所にいるユーザーにアプリケーションを一律にデプロイします。Deploy the application uniformly to users over a wide geographical area with a global-ready CDN, with the static content hosted on the cloud. これで専用の Web サーバーを使用する必要がなくなります。This avoids the need for a dedicated web server. 概要については、「Azure ストレージ アカウントと Azure CDN との統合」を参照してください。Read Integrate an Azure storage account with Azure CDN to get started. HTTPS を使用してアプリケーションをセキュリティで保護します。Secure your application with HTTPS. その他の推奨事項については、コンテンツ配信ネットワークを使用するためのベスト プラクティスに関する記事を参照してください。Read the Best practices for using content delivery networks for additional recommendations.
  • Azure Pipelines などの高速で信頼性の高い CI/CD サービスを使用して、すべてのソースの変更を自動的に構築してデプロイします。Use a fast and reliable CI/CD service such as Azure Pipelines, to automatically build and deploy every source change. ソースは、オンライン バージョンのコントロール システムに存在する必要があります。The source must reside in an online version control system. 詳細については、「最初のパイプラインの作成」を参照してください。For more details, read Create your first pipeline.
  • CDN の帯域幅の消費を削減し、パフォーマンスを向上させるために Web サイト ファイルを圧縮します。Compress your website files to reduce the bandwidth consumption on the CDN and improve performance. Azure CDN では、エッジ サーバー上で圧縮を実行できます。Azure CDN allows compression on the fly on the edge servers. また、この参照アーキテクチャのデプロイ パイプラインでは、ファイルを BLOB ストレージにデプロイする前に圧縮します。Alternatively, the deploy pipeline in this reference architecture compresses the files before deploying them to the Blob storage. これにより、ストレージ要件が軽減され、CDN の制限に関係なく、圧縮ツールを自由に選択できます。This reduces the storage requirement, and gives you more freedom to choose the compression tools, regardless of any CDN limitations.
  • CDN では、すべてのユーザーに最新コンテンツが提供されるように、キャッシュを消去できる必要があります。The CDN should be able to purge its cache to ensure all users are served the freshest content. 構築およびデプロイ プロセスがアトミックでない場合 (たとえば、同じ元のフォルダー内で古いファイルが新しく構築されたファイルに置き換えられる場合) は、キャッシュの消去が必要です。A cache purge is required if the build and deploy processes are not atomic, for example, if they replace old files with newly built ones in the same origin folder.
  • ディレクトリを使用したバージョン管理など、別のキャッシュ戦略では、CDN による消去が必要ない場合があります。A different cache strategy such as versioning using directories, may not require a purge by the CDN. このフロントエンド アプリケーションのビルド パイプラインでは、新しく構築されたバージョンごとに新しいディレクトリが作成されます。The build pipeline in this front-end application creates a new directory for each newly built version. このバージョンは、BLOB ストレージにアトミック ユニットとしてアップロードされます。This version is uploaded as an atomic unit to the Blob storage. Azure CDN では、デプロイが完了した後にのみこの新しいバージョンを指します。The Azure CDN points to this new version only after a completed deployment.
  • 何か月間もの長期間にわたってリソース ファイルをキャッシュすることで、キャッシュの TTL を増やします。Increase the cache TTL by caching resource files for a longer duration, spanning months. キャッシュされたファイルが変更されたときに更新されるようにするには、再構築時にファイル名のフィンガープリントを作成します。To make sure the cached files are updated when they do change, fingerprint the filenames when they are rebuilt. このフロントエンド アプリケーションでは、index.html などの公開されているファイルを除くすべてのファイルのフィンガープリントが作成されます。This front-end application fingerprints all files except for public-facing files such as index.html. index.html は頻繁に更新されるため、変更されたファイル名が反映され、キャッシュの更新が発生します。Since the index.html is updated frequently, it reflects the changed filenames causing a cache refresh. 詳細については、「Azure CDN で Web コンテンツ有効期限を管理する」を参照してください。See the Manage expiration of web content in Azure CDN for more information.

バックエンドのデプロイBack-end deployment

関数アプリをデプロイするには、パッケージ ファイルを使用することをお勧めします ("パッケージから実行")。To deploy the function app, we recommend using package files ("Run from package"). このアプローチを使用して、ZIP ファイルを Blob Storage コンテナーにアップロードすると、ZIP ファイルは、Functions ランタイムによって読み取り専用ファイル システムとしてマウントされます。Using this approach, you upload a zip file to a Blob Storage container and the Functions runtime mounts the zip file as a read-only file system. これはアトミック操作で、デプロイの失敗によりアプリケーションが不整合な状態のままになる可能性が少なくなります。This is an atomic operation, which reduces the chance that a failed deployment will leave the application in an inconsistent state. また、すべてのファイルが一度にスワップされるため、特に Node.js アプリについては、コールド スタート時間を改善することができます。It can also improve cold start times, especially for Node.js apps, because all of the files are swapped at once.

API のバージョン管理API versioning

API は、サービスとクライアントの間のコントラクトです。An API is a contract between a service and clients. このアーキテクチャでは、API コントラクトは、API Management レイヤーで定義されます。In this architecture, the API contract is defined at the API Management layer. API Management では、次に示すように、2 つの異なる (ただし補完的な) バージョン管理の概念がサポートされています。API Management supports two distinct but complementary versioning concepts:

  • "バージョン" により、API のコンシューマーはニーズに基づいて API のバージョン (v1、v2 など) を選択できます。Versions allow API consumers to choose an API version based on their needs, such as v1 versus v2.

  • "リビジョン" により、API 管理者が API の非破壊的変更を行い、これらの変更をデプロイできるようになります。その際、API コンシューマーにこれらの変更を通知する変更ログもデプロイされます。Revisions allow API administrators to make non-breaking changes in an API and deploy those changes, along with a change log to inform API consumers about the changes.

API で破壊的変更を行う場合は、API Management で新しいバージョンを発行します。If you make a breaking change in an API, publish a new version in API Management. 新しいバージョンは、別の関数アプリで、元のバージョンと共にデプロイしてください。Deploy the new version side-by-side with the original version, in a separate Function App. これにより、クライアント アプリケーションを中断することなく、既存のクライアントを新しい API に移行できます。This lets you migrate existing clients to the new API without breaking client applications. 最終的には、以前のバージョンを廃止できます。Eventually, you can deprecate the previous version. API Management では、複数のバージョン管理スキーム: URL のパス、HTTP ヘッダー、クエリ文字列がサポートされています。API Management supports several versioning schemes: URL path, HTTP header, or query string. 一般的な API のバージョン管理の詳細については、「RESTful Web API のバージョン管理」を参照してください。For more information about API versioning in general, see Versioning a RESTful web API.

API の破壊的変更とはならない更新プログラムの場合、新しいバージョンは、同じ関数アプリのステージング スロットにデプロイします。For updates that are not breaking API changes, deploy the new version to a staging slot in the same Function App. デプロイが成功したことを確認したら、ステージング バージョンを運用バージョンと入れ替えます。Verify the deployment succeeded and then swap the staged version with the production version. API Management でリビジョンを発行します。Publish a revision in API Management.

コストに関する考慮事項Cost considerations

コストの見積もりには、Azure 料金計算ツールをご利用ください。Use the Azure pricing calculator to estimate costs. このアーキテクチャのコストを最適化するには、次の点を考慮してください。Consider these points to optimize cost of this architecture.

Azure FunctionsAzure Functions

Azure Functions では 2 つのホスティング モデルがサポートされています。Azure Functions supports two hosting models.

  • 従量課金プランConsumption plan.

    コードの実行時にコンピューティング能力が自動的に割り当てられます。Compute power is automatically allocated when your code is running.

  • App Service プラン。App Service plan.

    一連の VM がお使いのコードに対して割り当てられます。A set of VMs are allocated for your code. このプランで定義されるのは VM の数とサイズです。This plan defines the number of VMs and the VM size.

このアーキテクチャでは、クライアントが HTTP 要求を行うと、関数が呼び出されます。In this architecture, a function is invoked when a client makes an HTTP request. このユース ケースではスループットが一定して高くなることは予想されないため、使用するコンピューティング リソースにのみ料金が発生する従量課金プランをお勧めします。Because a constant high-volume throughput is not expected in this use case, consumption plan is recommended because you pay only for the compute resources you use.

Azure Cosmos DBAzure Cosmos DB

Azure Cosmos DB では、プロビジョニングされたスループットと消費されたストレージに対して時間単位で課金されます。Azure Cosmos DB bills for provisioned throughput and consumed storage by hour. プロビジョニングされたスループットは要求ユニット/秒 (RU/秒) で表され、挿入、読み取りなどの一般的なデータベース操作に使用できます。Provisioned throughput is expressed in Request Units per second (RU/s), which can be used for typical database operations, such as inserts, reads. 価格は、予約した RU/秒の容量に基づいています。The price is based on the capacity in RU/s that you reserve.

ストレージへの課金は、格納データとインデックスに使用される GB ごとに行われます。Storage is billed for each GB used for your stored data and index.

詳細については、「Azure Cosmos DB の価格」を参照してください。See Cosmos DB pricing model for more information.

このアーキテクチャでは、関数アプリケーションは、クライアントからの HTTP GET 要求に応答して Cosmos DB からドキュメントをフェッチします。In this architecture, the function application fetches documents from Cosmos DB in response to HTTP GET requests from the client. この場合は Cosmos DB がコスト効率に優れています。RU/秒で表される書き込み操作よりも読み取り操作の方がはるかに低コストであるためです。Cosmos DB is cost effective in this case because reading operations are significantly cheaper than write operations expressed on RU/s.

Content Delivery NetworkContent Delivery Network

課金レートは、請求先リージョンによって異なる場合があります。この請求先リージョンは、エンド ユーザーにコンテンツを配信するソース サーバーの場所に基づいています。Billing rate may differ depending on the billing region based on the location of the source server delivering the content to the end user. クライアントの物理的な場所は請求先リージョンではありません。The physical location of the client is not the billing region. CDN にヒットする HTTP または HTTPS 要求はすべて課金対象イベントで、応答のすべての種類 (成功、失敗、またはその他) が含まれます。Any HTTP or HTTPS request that hits the CDN is a billable event, which includes all response types: success, failure, or other. 応答が異なれば、生成されるトラフィック量が異なる可能性があります。Different responses may generate different traffic amounts.

この参照アーキテクチャでは、デプロイは単一の Azure リージョンに存在します。In this reference architecture the deployment resides in a single Azure region.

コストを削減するには、リソース ファイルを長期間にわたってキャッシュし、コンテンツで可能な限り長い TTL を設定することで、キャッシュ TTL を増やすことを検討してください。To lower costs, consider increasing the cache TTL by caching resource files for a longer duration and setting the longest TTL possible on your content.

詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。For more information, see the Cost section in Microsoft Azure Well-Architected Framework.

ソリューションのデプロイ方法Deploy the solution

このアーキテクチャのリファレンス実装をデプロイするには、GitHub の Readme を参照してください。To deploy the reference implementation for this architecture, see the GitHub readme.

次のステップNext steps

リファレンス実装について詳しくは、「コードのチュートリアル: Azure Functions を使用したサーバーレス アプリケーション」をご覧ください。To learn more about the reference implementation, read Code walkthrough: Serverless application with Azure Functions.

関連するガイダンス:Related guidance: