サーバーレス Web アプリケーション

Microsoft Entra ID

Azure API Management

Azure Blob Storage

Azure Content Delivery Network

Azure Functions

Azure Monitor

この参照アーキテクチャは、サーバーレス Web アプリケーションを示しています。このアプリケーションでは Azure Blob Storage から静的コンテンツを提供し、Azure Functions を使用して API が実装されます。 API は Azure Cosmos DB からデータを読み取り、結果を Web アプリに返します。

GitHub ロゴこのアーキテクチャの 2 つの参照実装である「ドローン配送アプリ (ARM & Azure Pipelines)」と「To Do App (Bicep & GitHub Actions)」は、「GitHub」で利用できます。

アーキテクチャ

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

このアーキテクチャの Visio ファイルをダウンロードします。

サーバーレスという言葉は 2 つの異なる意味を持ちますが、この 2 つの意味は関連しています。

サービスとしてのバックエンド (BaaS)。データベースやストレージなどのバックエンドクラウドサービスには、クライアントアプリケーションがこれらのサービスに直接接続できるようにする API が用意されています。
サービスとしての関数 (FaaS)。このモデルでは、"関数" はクラウドにデプロイされるひとまとまりのコードで、コードを実行するサーバーが完全に抽象化されたホスティング環境内で実行されます。

両方の定義に共通しているのは、開発者と DevOps スタッフが、サーバーをデプロイ、構成、または管理する必要がないというアイデアです。 Azure Blob Storage からの Web コンテンツ提供は BaaS の一例ですが、この参照アーキテクチャでは、Azure Functions を使用した FaaS に重点を置いています。 FaaS の重要な特性をいくつか次に示します。

コンピューティングリソースが、プラットフォームによって必要に応じて動的に割り当てられます。
使用量ベースの価格: ご自身のコードの実行に使用されたコンピューティングリソースに対してのみ課金されます。
コンピューティングリソースがトラフィックに基づいてオンデマンドでスケーリングされます。開発者が構成する必要はありません。

HTTP 要求やメッセージがキューに到着するなど、外部トリガーが発生すると、関数が実行されます。このため、サーバーレスアーキテクチャにとって、イベントドリブンアーキテクチャのスタイルが自然になります。アーキテクチャでのコンポーネント間の動作を調整するには、メッセージブローカーまたはパブリッシュ/サブスクライブパターンの使用を検討してください。 Azure でのメッセージングテクノロジの選択に関するヘルプについては、「メッセージを配信する Azure サービスの選択」を参照してください。

Components

アーキテクチャは、次のコンポーネントで構成されています。

Blob Storage。 HTML、CSS、JavaScript ファイルなどの静的 Web コンテンツは Azure Blob Storage に格納され、静的 Web サイトのホスティングを使用してクライアントに提供されます。動的な対話はすべて、バックエンド API を呼び出す JavaScript コードを介して行われます。 Web ページをレンダリングするサーバー側のコードはありません。静的な Web サイトのホスティングでは、インデックスドキュメントとカスタム 404 エラーページがサポートされます。

Content Delivery Network。 Azure Content Delivery Network を使用して、待機時間を短縮してコンテンツを高速に配信できるようにコンテンツをキャッシュし、HTTPS エンドポイントを提供します。

Function App。 Azure Functions はサーバーレスコンピューティングの 1 つのオプションです。ひとまとまりのコード ("関数") がトリガーによって呼び出されるイベントドリブンモデルが使用されます。このアーキテクチャでは、関数は、クライアントが HTTP 要求を行うと呼び出されます。要求は、以下で説明するように、常に API ゲートウェイ経由でルーティングされます。

API Management。 Azure API Management には、HTTP 関数の前に配置される API ゲートウェイが用意されています。 API Management を使用すると、クライアントアプリケーションで使用される API を発行および管理できます。ゲートウェイは、バックエンド API からフロントエンドアプリケーションを分離するのに役立ちます。たとえば、API Management では、URL の再書き込み、バックエンドに到達する前の要求の変換、要求または応答ヘッダーの設定などを行うことができます。

API Management を使って、複数のサービスにまたがる、次のような機能を実装することもできます。

使用量クォータとレート制限の強制
認証用の OAuth トークンの検証
クロスオリジン要求 (CORS) の有効化
応答のキャッシュ
要求の監視とログ記録

API Management によって提供される一部の機能が不要の場合は、別の選択肢として関数プロキシを使用できます。 Azure Functions のこの機能を使用すると、バックエンド関数へのルートを作成することで、複数の関数アプリに対して 1 つの API サーフェスを定義できます。関数プロキシによって、HTTP 要求および応答で制限付き変換を実行することもできます。ただし、API Management ほど豊富なポリシーベース機能は用意されていません。

Azure Cosmos DB Azure Cosmos DB は、マルチモデルデータベースサービスです。このシナリオでは、関数アプリケーションは、クライアントからの HTTP GET 要求に応答して Azure Cosmos DB からドキュメントをフェッチします。

Microsoft Entra ID。ユーザーは、各自の Microsoft Entra ID 資格情報を使用して Web アプリケーションにサインインします。 Microsoft Entra ID から API のアクセストークンが返されます。Web アプリケーションはこれを使って API 要求を認証します (「認証」を参照)。

Azure Monitor。 Azure Monitor は、ソリューションにデプロイされた Azure サービスに関するパフォーマンスメトリックを収集します。ダッシュボードでこれらを視覚化することで、ソリューションの正常性を把握できます。アプリケーションログも収集されます。

Azure Pipelines。 Azure Pipelines は、アプリケーションをビルド、テスト、デプロイする継続的インテグレーション (CI) および継続的デリバリー (CD) サービスです。

Github Actions ワークフローとは、お使いの GitHub リポジトリで設定する自動化されたプロセス (CI/CD) です。ワークフローを使用すると、任意のプロジェクトを GitHub でビルド、テスト、パッケージ化、リリース、またはデプロイできます。

シナリオの詳細

考えられるユースケース

このドローン配送ソリューションは、航空機、航空、航空宇宙、ロボットの各業界に最適です。

推奨事項

Function App プラン

Azure Functions では 2 つのホスティングモデルがサポートされています。 従量課金プランでは、コードの実行時にコンピューティング能力が自動的に割り当てられます。 App Service プランでは、一連の VM がお使いのコードに対して割り当てられます。 App Service プランで定義されるのは VM の数とサイズです。

上記の定義に従うと、App Service プランは厳密には "サーバーレス" ではありません。プログラミングモデルは同じですが、従量課金プランと App Service プランの両方で、同じ関数コードを実行できます。

使用するプランの種類を選択するときに検討すべき要素を、次に示します。

コールドスタート。従量課金プランでは、最近呼び出されていない関数の場合、次回の実行時に待ち時間が少し長くなります。この追加の待ち時間は、ランタイム環境の割り当てと準備が原因で発生します。通常は数秒程度ですが、読み込む必要がある依存関係の数など、いくつかの要因によって異なってきます。詳細については、「Understanding Serverless Cold Start (サーバーレスのコールドスタートについて)」を参照してください。通常、コールドスタートが問題になるのは、非同期のメッセージドリブンワークロード (キューまたはイベントハブトリガー) よりも対話型ワークロード (HTTP トリガー) です。対話型ワークロードでは、ユーザーが待ち時間が長くなったことに直接気付くためです。
タイムアウト時間。従量課金プランでは、構成可能な期間 (最大 10 分) が経過すると関数の実行はタイムアウトします
仮想ネットワークの分離。 App Service プランを使用すると、分離された専用ホスティング環境である App Service 環境内で関数を実行できます。
価格モデル。従量課金プランでは、実行数とリソース消費量 (メモリ x 実行時間) によって課金されます。 App Service プランでは、VM インスタンス SKU に基づいて 1 時間ごとに課金されます。従量課金プランは、使用したコンピューティングリソースにしか支払いが発生しないため、多くの場合 App Service プランよりもコストがかかりません。これは、トラフィックに山と谷がある場合に特に当てはまります。ただし、アプリケーションのスループットが一定して高い場合は、App Service プランの方が従量課金プランよりも低コストになる可能性があります。
スケーリング。従量課金モデルの大きな利点は、着信トラフィックに基づいて、必要に応じて動的にスケーリングされることです。このスケーリングは迅速に行われますが、やはり準備期間はあります。一部のワークロードでは、準備時間なしでトラフィックのバーストを処理できるように、VM の意図的オーバープロビジョニングが必要なことがあります。その場合は、App Service プランを検討してください。

Function App の境界

関数アプリ によって、1 つ以上の関数の実行がホストされます。関数アプリを使用すると、複数の関数を 1 つの論理ユニットとしてまとめることができます。関数アプリ内の関数は、同じアプリケーション設定、ホスティングプラン、およびデプロイライフサイクルを共有しています。関数アプリはそれぞれ独自のホスト名を持ちます。

関数アプリを使用して、同じライフサイクルと設定を共有する関数をグループ化します。同じライフサイクルを共有していない関数は、別の関数アプリでホストする必要があります。

マイクロサービスアプローチを使用することを検討します。このアプローチでは、各関数アプリが 1 つのマイクロサービスを表しており、関連する複数の関数で構成されている可能性があります。マイクロサービスアーキテクチャのサービスには、疎結合と、機能の高い凝集度が必要です。 "疎" 結合とは、他のサービスを同時に更新しなくても、あるサービスを変更できることを意味します。 "高凝集" とは、明確に定義された 1 つの目的をサービスが持つことを意味します。これらのアイデアの詳細については、「マイクロサービスの設計:ドメイン分析」を参照してください。

関数のバインディング

可能な場合は、関数のバインディングを使用します。バインディングにより、お使いのコードをデータに接続し、他の 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」を参照してください。

スケーラビリティ

Functions。従量課金プランの場合、HTTP トリガーはトラフィックに基づいてスケーリングされます。コンカレント関数インスタンスの数には制限がありますが、それぞれのインスタンスが一度に複数の要求を処理できます。 App Service プランでは、HTTP トリガーは VM インスタンスの数に応じてスケーリングされます。この数は固定値にすることも、一連の自動スケーリングルールに基づいて自動スケーリングすることもできます。詳細については、「Azure Functions のスケールとホスティング」を参照してください。

Azure Cosmos DB Azure Cosmos DB のスループット容量は、要求ユニットで測定されます。 1 RU のスループットは、1 KB のドキュメントを取得するのに必要なスループットに対応します。 Azure Cosmos DB コンテナーを 10,000 RU を超えてスケーリングするには、コンテナーの作成時にパーティションキーを指定し、作成するすべてのドキュメントにパーティションキーを含める必要があります。パーティションキーの詳細については、「Azure Cosmos DB でのパーティション分割とスケーリング」を参照してください。

API Management。 API Management はスケールアウトが可能で、ルールベースの自動スケーリングがサポートされます。このスケーリングプロセスには、少なくとも 20 分かかります。トラフィックのバーストが発生する場合は、最大バーストトラフィックの予測に基づいてプロビジョニングする必要があります。ただし、自動スケーリングを使えば、時間単位または日単位でトラフィックの変動が処理されるため便利です。詳細については、「Azure API Management インスタンスを自動的にスケーリングする」を参照してください。

障害復旧

ここに示したデプロイは単一の Azure リージョンに存在します。ディザスターリカバリーでより回復性に優れたアプローチを実現するには、さまざまなサービスで地理的分散機能を利用します。

API Management では複数リージョンのデプロイがサポートされており、API Management サービスの単一インスタンスを任意の数の Azure リージョンに分散できます。詳細については、「複数の Azure リージョンに Azure API Management サービスインスタンスをデプロイする方法」を参照してください。
Traffic Manager を使用して、HTTP 要求をプライマリリージョンにルーティングします。そのリージョンで実行されている Function App が使用できなくなった場合、Traffic Manager によってセカンダリリージョンにフェールオーバーできます。
Azure Cosmos DB では複数の書き込みリージョンがサポートされています。これにより、Azure Cosmos DB アカウントに追加した任意のリージョンに書き込むことができます。複数の書き込みを有効にしなくても、プライマリ書き込みリージョンには引き続きフェールオーバーできます。フェールオーバーは、Azure Cosmos DB クライアント SDK と Azure Functions のバインディングによって自動的に処理されるため、アプリケーション構成設定を更新する必要はありません。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については、「セキュリティの重要な要素の概要」を参照してください。

認証

リファレンス実装の GetStatus API では、Microsoft Entra ID を使用して要求が認証されます。 Microsoft Entra ID がサポートするのは OpenID Connect プロトコルで、この認証プロトコルは、OAuth 2 プロトコルを基盤として構築されています。

このアーキテクチャでは、クライアントアプリケーションは、ブラウザーで実行されるシングルページアプリケーション (SPA) です。この種類のクライアントアプリケーションでは、クライアントをシークレットにできません。また、認証コードも非表示になりません。このため暗黙的な許可フローが適しています (Which OAuth 2.0 flow should I use? (使用する必要がある OAuth 2.0 フロー) に関するページをご覧ください)。全体的なフローを次に示します。

ユーザーが Web アプリケーションで "サインイン" リンクをクリックします。
ブラウザーは Microsoft Entra のサインインページにリダイレクトされます。
ユーザーがサインインします。
Microsoft Entra ID がクライアントアプリケーションにもう一度リダイレクトされます。その URL フラグメントにはアクセストークンが含まれています。
Web アプリケーションが API を呼び出すとき、認証ヘッダーにはアクセストークンが含まれています。アプリケーション ID は、アクセストークンで audience ("aud") クレームとして送信されます。
バックエンド API によってアクセストークンが検証されます。

認証を構成するには:

Microsoft Entra テナントにアプリケーションを登録します。これによりアプリケーション ID が生成されます。クライアントはこれをログイン URL に含めます。
Function App 内の Microsoft Entra 認証を有効にします。詳細については、「 Azure App Service での認証および承認」を参照してください。
API Management に validate-jwt ポリシーを追加し、アクセストークンを検証することで要求を事前承認できるようにします。

詳細については、 GitHub の Readmeを参照してください。

クライアントアプリケーションとバックエンド 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

この参照アーキテクチャでは、Web アプリケーションと API はオリジンを共有しません。つまり、アプリケーションが API を呼び出す場合、それはクロスオリジン要求になります。ブラウザーのセキュリティ機能により、Web ページでは 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になっています。これにより、ブラウザーが要求と共に資格情報 (Cookie など) を送信することが承認されます。それ以外の場合、既定では、ブラウザーからクロスオリジン要求と共に資格情報が送信されません。

Note

allow-credentials を true に設定すると、Web サイトが、ユーザーの資格情報を、そのユーザーが知らないところでユーザーの代わりに API に送信できるようになるため、注意が必要です。許可されたオリジンを信頼する必要があります。

HTTPS の適用

セキュリティを最大限に高めるには、要求パイプライン全体で HTTPS を使用する必要があります。

CDN。既定では、Azure CDN は、 *.azureedge.net サブドメインで HTTPS をサポートしています。 CDN でカスタムドメイン名に対して HTTPS を有効にするには、「チュートリアル:Azure CDN カスタムドメインで HTTPS を構成する」を参照してください。
静的 Web サイトのホスティング。ストレージアカウントで[安全な転送が必須]オプションを有効にします。このオプションを有効にすると、ストレージアカウントでは、セキュリティで保護された 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 アドレスがあります。その静的 IP アドレスからの呼び出しのみを許可するように Azure 関数を制限します。詳細については、「Azure App Service 静的 IP 制限」を参照してください。 (この機能は、Standard レベルのサービスでのみ使用できます)。

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

データベースの資格情報などのアプリケーションシークレット情報を、コードや構成ファイルに保存しないでください。代わりに、暗号化された状態で Azure に保存されているアプリ設定を使用します。詳しくは、 Azure App Service と Azure Functions でのセキュリティに関する記事をご覧ください。

また、アプリケーションシークレット情報を Key Vault に格納することもできます。これにより、シークレットのストレージを一元化し、その配布を制御して、シークレットへのアクセス方法とそのタイミングを監視することができます。詳しくは、 Key Vault からシークレットを読み取るための Azure Web アプリケーションの構成に関する記事をご覧ください。ただし、その構成設定は、関数のトリガーとバインディングにより、アプリ設定から読み込まれることに注意してください。 Key Vault のシークレットを使用するようにトリガーとバインディングを構成する方法は、組み込まれていません。

DevOps

安全なデプロイプラクティスは、Azure Pipelines や GitHub Actions などの信頼性の高い CI/CD サービスを使用して自動化されます。これらのサービスは、フロントエンドとバックエンドのすべてのソース変更を自動的にビルドしてデプロイするために使用されます。ソースは、オンラインバージョンのコントロールシステムに存在する必要があります。 Azure Pipelines について詳しくは、「最初のパイプラインの作成」を参照してください。 Azure の GitHub Actions の詳細については、「Azure へのアプリのデプロイ」に関するページを参照してください。

フロントエンドのデプロイ

この参照アーキテクチャのフロントエンドは、サーバーレスバックエンド API にアクセスする JavaScript と高速なユーザーエクスペリエンスを提供する静的コンテンツを提供するシングルページアプリケーションです。このようなアプリケーションに関する重要な考慮事項を次に示します。

グローバル対応の CDN と、クラウド上でホストされている静的コンテンツを使用して、地理的に離れた場所にいるユーザーにアプリケーションを一律にデプロイします。これで専用の Web サーバーを使用する必要がなくなります。概要については、「Azure ストレージアカウントと Azure CDN との統合」を参照してください。 HTTPS を使用してアプリケーションをセキュリティで保護します。その他の推奨事項については、コンテンツ配信ネットワークを使用するためのベストプラクティスに関する記事を参照してください。
CDN の帯域幅の消費を削減し、パフォーマンスを向上させるために Web サイトファイルを圧縮します。 Azure CDN では、エッジサーバー上で圧縮を実行できます。また、この参照アーキテクチャのデプロイパイプラインでは、ファイルを BLOB ストレージにデプロイする前に圧縮します。これにより、ストレージ要件が軽減され、CDN の制限に関係なく、圧縮ツールを自由に選択できます。
CDN では、すべてのユーザーに最新コンテンツが提供されるように、キャッシュを消去できる必要があります。構築およびデプロイプロセスがアトミックでない場合 (たとえば、同じ元のフォルダー内で古いファイルが新しく構築されたファイルに置き換えられる場合) は、キャッシュの消去が必要です。
ディレクトリを使用したバージョン管理など、別のキャッシュ戦略では、CDN による消去が必要ない場合があります。このフロントエンドアプリケーションのビルドパイプラインでは、新しく構築されたバージョンごとに新しいディレクトリが作成されます。このバージョンは、BLOB ストレージにアトミックユニットとしてアップロードされます。 Azure CDN では、デプロイが完了した後にのみこの新しいバージョンを指します。
何か月間もの長期間にわたってリソースファイルをキャッシュすることで、キャッシュの TTL を増やします。キャッシュされたファイルが変更されたときに更新されるようにするには、再構築時にファイル名のフィンガープリントを作成します。このフロントエンドアプリケーションでは、 index.html などの公開されているファイルを除くすべてのファイルのフィンガープリントが作成されます。 index.html は頻繁に更新されるため、変更されたファイル名が反映され、キャッシュの更新が発生します。詳細については、「Azure CDN で Web コンテンツ有効期限を管理する」を参照してください。

バックエンドのデプロイ

関数アプリをデプロイするには、パッケージファイルを使用することをお勧めします ("パッケージから実行")。このアプローチを使用して、ZIP ファイルを Blob Storage コンテナーにアップロードすると、ZIP ファイルは、Functions ランタイムによって読み取り専用ファイルシステムとしてマウントされます。これはアトミック操作で、デプロイの失敗によりアプリケーションが不整合な状態のままになる可能性が少なくなります。また、すべてのファイルが一度にスワップされるため、特に Node.js アプリについては、コールドスタート時間を改善することができます。

ビルドパイプラインとデプロイパイプラインの両方に、十分な数の自動化されたテストを追加します。ワークロードを構成する個々のデプロイ可能なユニットが増えるほど、より多くのネットワーク境界が導入されることに注意してください。これらの個々のユニットが連携して、ユーザーフローとデータフローをサポートします。その後、このようなシステムのエンドツーエンドのテストでは、統合テストへの追加の投資が必要になります。

API のバージョン管理

API は、サービスとクライアントの間のコントラクトです。このアーキテクチャでは、API コントラクトは、API Management レイヤーで定義されます。 API Management では、次に示すように、2 つの異なる (ただし補完的な) バージョン管理の概念がサポートされています。

"バージョン" により、API のコンシューマーはニーズに基づいて API のバージョン (v1、v2 など) を選択できます。
"リビジョン" により、API 管理者が API の非破壊的変更を行い、これらの変更をデプロイできるようになります。その際、API コンシューマーにこれらの変更を通知する変更ログもデプロイされます。

API で破壊的変更を行う場合は、API Management で新しいバージョンを発行します。新しいバージョンは、別の関数アプリで、元のバージョンと共にデプロイしてください。これにより、クライアントアプリケーションを中断することなく、既存のクライアントを新しい API に移行できます。最終的には、以前のバージョンを廃止できます。 API Management では、複数のバージョン管理スキーム: URL のパス、HTTP ヘッダー、クエリ文字列がサポートされています。一般的な API のバージョン管理の詳細については、「RESTful Web API のバージョン管理」を参照してください。

API の破壊的変更とはならない更新プログラムの場合、新しいバージョンは、同じ関数アプリのステージングスロットにデプロイします。デプロイが成功したことを確認したら、ステージングバージョンを運用バージョンと入れ替えます。 API Management でリビジョンを発行します。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

コストの見積もりには、Azure 料金計算ツールをご利用ください。このアーキテクチャのコストを最適化するには、次の点を考慮してください。

Azure Functions

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

従量課金プラン。

コードの実行時にコンピューティング能力が自動的に割り当てられます。
App Service プラン。

一連の VM がお使いのコードに対して割り当てられます。このプランで定義されるのは VM の数とサイズです。

このアーキテクチャでは、クライアントが HTTP 要求を行うと、関数が呼び出されます。このユースケースではスループットが一定して高くなることは予想されないため、使用するコンピューティングリソースにのみ料金が発生する 従量課金プラン をお勧めします。

Azure Cosmos DB

Azure Cosmos DB では、プロビジョニングされたスループットと消費されたストレージに対して時間単位で課金されます。プロビジョニングされたスループットは要求ユニット/秒 (RU/秒) で表され、挿入、読み取りなどの一般的なデータベース操作に使用できます。価格は、予約した RU/秒の容量に基づいています。

ストレージへの課金は、格納データとインデックスに使用される GB ごとに行われます。

詳細については、「Azure Cosmos DB の価格」を参照してください。

このアーキテクチャでは、関数アプリケーションは、クライアントからの HTTP GET 要求に応答して Azure Cosmos DB からドキュメントをフェッチします。この場合は Azure Cosmos DB がコスト効率に優れています。RU/秒で表される書き込み操作よりも読み取り操作の方がはるかに低コストであるためです。

Content Delivery Network

課金レートは、請求先リージョンによって異なる場合があります。この請求先リージョンは、エンドユーザーにコンテンツを配信するソースサーバーの場所に基づいています。クライアントの物理的な場所は請求先リージョンではありません。 CDN にヒットする HTTP または HTTPS 要求はすべて課金対象イベントで、応答のすべての種類 (成功、失敗、またはその他) が含まれます。応答が異なれば、生成されるトラフィック量が異なる可能性があります。

この参照アーキテクチャでは、デプロイは単一の Azure リージョンに存在します。

コストを削減するには、リソースファイルを長期間にわたってキャッシュし、コンテンツで可能な限り長い TTL を設定することで、キャッシュ TTL を増やすことを検討してください。

詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。

このシナリオのデプロイ

このアーキテクチャのリファレンス実装をデプロイするには、 GitHub の Readmeを参照してください。

次のステップ

製品ドキュメント:

Learn モジュール:

リファレンス実装について詳しくは、「コードのチュートリアル: Azure Functions を使用したサーバーレスアプリケーション」をご覧ください。

次の方法で共有

サーバーレス Web アプリケーション

アーキテクチャ

Components

シナリオの詳細

考えられるユースケース

推奨事項

Function App プラン

Function App の境界

関数のバインディング

考慮事項

スケーラビリティ

障害復旧

セキュリティ

認証

承認

CORS

HTTPS の適用

関数アプリのロックダウン

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

DevOps

フロントエンドのデプロイ

バックエンドのデプロイ

API のバージョン管理

コスト最適化

Azure Functions

Azure Cosmos DB

Content Delivery Network

このシナリオのデプロイ

次のステップ

フィードバック

その他のリソース

次の方法で共有

サーバーレス Web アプリケーション

アーキテクチャ

Components

シナリオの詳細

考えられるユース ケース

推奨事項

Function App プラン

Function App の境界

関数のバインディング

考慮事項

スケーラビリティ

障害復旧

セキュリティ

認証

承認

CORS

HTTPS の適用

関数アプリのロックダウン

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

DevOps

フロントエンドのデプロイ

バックエンドのデプロイ

API のバージョン管理

コスト最適化

Azure Functions

Azure Cosmos DB

Content Delivery Network

このシナリオのデプロイ

次のステップ

関連リソース

フィードバック

その他のリソース

考えられるユースケース

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