Microsoft AZ-204: Azure Functions とサーバーレスコンピューティング — 学習ガイド

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Developer Associate AZ-204 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azure Functionsは、イベント駆動型で短時間のワークロードに最適化されたサーバーレスコンピューティングサービスです。インフラストラクチャを抽象化するため、開発者はHTTPエンドポイント、キュー、BLOB、データ変更フィード、ストリーミングサービスからのイベントに応答するコードに集中できます。スケーリング、価格設定、コールドスタートの動作を決定するホスティングプランを選択し、宣言的なバインディングでコードをトリガーやデータソースにバインドし、オプションでDurable Functionsを使用して長時間実行される信頼性の高いワークフローを構成します。堅牢な構成、再現性のあるデプロイ、そしてApplication Insightsによる詳細な可観測性が、本番環境レベルのシステム向けプラットフォームを完成させます。

ホスティングプラン、スケーリング、コールドスタート

ホスティングプランの選択は、実行特性とコストを決定します。

• 従量課金プラン (Consumption plan):

  • スケーリングと価格設定: 実行回数とリソース消費量に応じた従量課金です。プラットフォームはイベントに基づいて自動的にスケールアウトします。アイドル状態になるとインスタンス数はゼロにスケールします。
  • 実行制限: HTTP以外の関数のタイムアウトは最大10分まで設定可能です。HTTP関数はクライアントの接続性のため、実質的なタイムアウトはより短くなります。
  • コールドスタート: アイドル期間の後や、新しいインスタンスが初期化されるスケールアウト時にコールドスタートが発生します。起動時間は言語、依存関係、アプリのサイズに依存します。
  • ネットワーク/機能: デフォルトでパブリックネットワークをサポートします。Premiumプランと比較して機能セットが限定されています（例: VNET統合なし）。デプロイメントスロットは利用できません。

• Premiumプラン:

  • スケーリングと価格設定: イベントに基づいてスケールしますが、コールドスタートをなくすために「事前ウォーミングされた」インスタンスを維持します。アクティブおよび事前ウォーミングされたインスタンスに割り当てられたコア秒とメモリによって課金されます。
  • 実行制限: 実質的に無制限の実行時間（HTTPクライアントの制約に従います）。レイテンシに敏感なワークロードや、より重いワークロードに推奨されます。
  • コールドスタートの軽減: 事前ウォーミングされたインスタンスがランタイムをホットな状態に保ちます。プランごとに事前ウォーミングされたインスタンス数を制御でき、バースト時にも予測可能なレイテンシを提供します。
  • ネットワーク/機能: VNET統合、プライベートエンドポイント、より大きなインスタンスサイズ、デプロイメントスロットをサポートします。

• Dedicated (App Service) プラン:

  • スケーリングと価格設定: 手動または自動スケールルールを持つプロビジョニング済みのApp Serviceインスタンス上で実行されます。使用状況に関わらず、基盤となるApp Serviceプランに対して料金を支払います。
  • 実行制限: バックグラウンド実行に対してプラットフォームが課すタイムアウトはありません。既存のApp Serviceに予備のキャパシティがある場合や、一貫したパフォーマンスが必要な場合に最適です。
  • コールドスタートの軽減: Always Onを有効にすることで、アプリをロードしたままに保ちます。スケールトゥゼロは行われず、インスタンスはウォーム状態を維持します。

コスト最適化された散発的なワークロードには従量課金プランを、低レイテンシとVNETの要件にはPremiumプランを、既存のApp Serviceキャパシティと統合する場合や完全な制御が必要な場合はDedicatedプランを選択します。超低レイテンシを実現するためには、事前ウォーミングされたインスタンスを持つPremiumプラン、またはAlways Onを設定したDedicatedプランがコールドスタートを削減します。依存関係の削減、run-from-packageの使用、クライアントの遅延初期化によって、コールドスタートの影響をさらに最小化します。

トリガーとバインディング

関数はトリガーによって起動され、バインディングを介してデータと対話します。トリガーは、関数がどのように、いつ実行されるかを定義します。バインディングは、命令的なSDKコードを使用せずに、宣言的に外部サービスに接続して入出力を行います。

一般的なトリガー：

• HTTPトリガー: REST形式のAPIやWebhookのエンドポイントを公開します。認可レベルにはAnonymous、Function、Adminがあり、キーまたはプラットフォーム認証を介して適用されます。長時間実行されるタスクについては、べき等性とタイムアウトを考慮してください。必要に応じて、キューやDurable Functionsにオフロードします。
• タイマートリガー: CRONベースのスケジュールは、アプリごとに（タイマーごとに）単一のインスタンスで実行されます。タイムゾーン設定とともにNCRONTAB式を使用します。メンテナンス、ポーリング、クリーンアップジョブに最適です。
• Azure Storageキュー トリガー: キュー内のメッセージに応答します。デキューカウントのしきい値を超えた後、-poisonキューによるポイズンメッセージ処理をサポートします。host.jsonを介して、バッチサイズ、可視性タイムアウト、同時実行性を設定します。
• Azure Blob Storageトリガー: ポーリングとEvent Grid通知の組み合わせを使用して、BLOBの作成/更新イベントに反応します。パスパターンを使用して、コンテナとプレフィックスのスコープを限定します。大きなBLOBのアップロードにおける、結果整合性とリトライ動作を理解してください。
• Azure Event Hubsトリガー: チェックポイント機能を使用して、高スループットのイベントストリームをコンシュームします。スループット向上のため、パーティションの同時実行性、バッチサイズ、プリフェッチを設定します。テレメトリやストリーム処理に適しており、パーティションごとに順序が保持されます。
• Azure Service Busトリガー: キューまたはトピックのサブスクリプションをサポートします。maxConcurrentCalls、プリフェッチ、自動完了の動作を設定します。配信試行回数を超えたメッセージは、後で調査するためにデッドレターキューにキャプチャされます。
• Azure Cosmos DBトリガー: 変更フィードをリッスンして、挿入と更新を検知します。物理パーティションの数に応じてスケールします。十分なRUがプロビジョニングされていることを確認してください。リースコレクションを使用して、インスタンス間のスケールアウトを調整します。

バインディング：

• 入力バインディング: 関数にデータを供給します。例：BLOBコンテンツ、テーブルエンティティ、Cosmos DBドキュメント、またはキューメッセージのメタデータ。.NETでは、属性（例：[BlobInput]）またはfunction.jsonがバインディングを定義します。他の言語では、設定は宣言的に行われます。
• 出力バインディング: SDKなしでデータを書き込みます。例：メッセージのエンキュー、BLOBの作成、Event Hub/Service Busへの送信、またはCosmos DBへの書き込み。関数は複数の出力バインディングを持つことも、関数のシグネチャから単一の出力を返すこともできます。
• バインディング式: プレースホルダー（例：{queueTrigger}、{rand-guid}）や環境ベースのアプリ設定を使用して、接続の詳細とパスをパラメータ化します。接続プロパティはアプリケーション設定名を参照し、ローテーションとシークレット管理を可能にします。サポートされている場合は、マネージドIDによるIDベースの接続を使用して、シークレットの埋め込みを避けることが推奨されます。
• 同時実行性とバッチ: host.jsonで拡張機能ごと（queues、serviceBus、eventHub）に同時実行性とバッチサイズを制御し、スループットとメモリ使用量を調整します。障害が確実に表面化するように、ポイズン/デッドレター処理を検証します。

べき等性、バックプレッシャー、障害分離を考慮してトリガーとバインディングを設計します。少なくとも1回の配信が保証されるソース（キュー、Event Hubs、Service Bus）については、関数をべき等かつリトライに強いものとして作成します。

Durable Functions: 信頼性の高いオーケストレーションパターン

Durable Functionsは、Durable Task Frameworkを使用して、長時間実行されるワークフローのためのステートフルで信頼性の高いオーケストレーション機能でAzure Functionsを拡張します。

関数の種類：

• オーケストレーター関数: 決定論的な構造を使用して、コードでワークフローロジックを記述します。オーケストレーターはイベント発生時に状態を再生するため、適切なヘルパーなしで非決定論的なAPI（DateTime.Now、乱数、ネットワーク呼び出し）を避ける必要があります。Durable Orchestration Client APIを使用して、インスタンスの開始、クエリ、管理を行います。
• アクティビティ関数: 外部APIの呼び出し、CPUバウンドな操作、IOタスクなど、個別の作業単位を実行します。アクティビティはリトライ可能で、独立してスケーラブルです。
• エンティティ関数: 小さく一貫性のある状態と操作（例：カウンター、デバイスの状態）を持つ、永続的でアドレス指定可能なエンティティを提供します。エンティティは、シングルスレッドの一貫性で直列化された操作を処理します。

パターン：

• 関数チェーン: 定義された順序（A → B → C）でアクティビティをシーケンス実行し、結果を次に渡します。依存関係のあるパイプラインに便利です。
• ファンアウト/ファンイン: 複数のアクティビティを並列に開始し、結果を集約します。オーケストレーターはTask.WhenAllのようなセマンティクスで調整します。独立したタスクの並列処理に使用します。
• ヒューマンインタラクション（外部イベント）: WaitForExternalEventを使用して、タイムアウトとエスカレーション付きで外部入力（例：承認）を待ちます。Durable Timerと組み合わせて、SLAや補正ロジックを実装します。
• 非同期HTTP API: オーケストレーションを開始し、ステータス/クエリURLとともに202 Acceptedを返します。クライアントは、最終的な結果や状態を取得するために、Durable Clientバインディングによって公開されたステータスエンドポイントをポーリングします。
• モニター: スケジュールに従って実行される定期的なチェックポイント。例えば、条件が満たされるまでエンドポイントをポーリングし、Durable Timerを使用してコンピューティングリソースの保持を避けます。
• アグリゲーター/エンティティ: 完全なワークフローなしで、きめ細かい調整を行うために、エンティティ関数を使用してロジックの隣に小さな状態を保存します。

Durable Functionsは、アクティビティの少なくとも1回の実行（at-least-once）と、オーケストレーターの状態の厳密に1回の進行（exactly-once）を保証します。状態はストレージ（デフォルトはAzure Storage）に永続化されます。ストレージアカウントがスループットと信頼性の要件を満たしていることを確認してください。一時的な障害にはカスタムリトライポリシーを使用し、外部との対話にはイベントを発生させます。非常に長いプロセスの場合、Durable Orchestrationは組み込みの永続性により、数日から数ヶ月にわたって実行できます。

構成、デプロイ、および可観測性

Function App の構成は階層化され、環境を認識する仕組みになっています。

• host.json: ランタイムと拡張機能の動作を制御します。ログ記録（サンプリング、ログレベル）、functionTimeout、拡張機能の設定（バッチサイズ、コンカレンシー、プリフェッチ）、および JSON スキーマのバージョンを構成します。host.json はソース管理に含めてください。
• local.settings.json: 接続文字列やアプリ設定を含む、ローカル開発用の設定です。Azure にはデプロイされません。シークレットは適切に扱い、パブリックリポジトリからは除外し、ローカル開発では user-secrets や環境インジェクションを使用してください。
• アプリケーション設定: Function App (App Service) の構成に保存されます。重要な設定には、AzureWebJobsStorage（トリガー、ログ、チェックポイントで使用されるストレージアカウント用）、拡張機能固有の接続文字列、およびカスタム構成が含まれます。スワップを避けるため、シークレットはスロット設定としてマークしてください。マネージド ID と共に Key Vault 参照を使用し、シークレットを平文で保存するのを避けてください。

デプロイオプション:

• Zip Deploy: ビルドした成果物の ZIP をアプリにアップロードします。CI/CD にとって高速でシンプルです。az functionapp deployment source config-zip または zipdeploy API を使用します。これにより、ファイルがコンテンツディレクトリに書き込まれます。
• Run-From-Package: WEBSITE_RUN_FROM_PACKAGE をパッケージ URL（または最新版の場合は 1）に設定します。ランタイムはパッケージを読み取り専用でマウントするため、コールドスタートが改善され、デプロイ中のファイルロックの問題が解消されます。再現可能なロールバックのために、パッケージは SAS URL を付けて Blob Storage に保存します。
• デプロイメントスロット: ステージングスロットと本番スロットにより、ウォームアップを伴うゼロダウンタイムのスワップが可能になります。スロットは Premium および Dedicated プランでサポートされています。環境間の漏洩を防ぐため、シークレットやエンドポイントにはスロット固有の設定（スロット設定フラグ）を構成します。トラフィックが移動する前に、preSwap ウォームアップを使用して拡張機能とバインディングを検証します。

Application Insights による監視:

• 呼び出しログ: 各関数の呼び出しは、Requests、Traces、Exceptions、Dependencies を含む構造化されたテレメトリを出力します。構造化ログには ILogger（または同等のもの）を使用します。操作 ID と相関 ID は、サービス間のアクティビティと依存関係を結びつけます。
• Live Metrics: サンプリングなしでスループット、障害、レイテンシーをリアルタイムに表示します。デプロイ、スケーリング、ホットパスの監視に役立ちます。関数名でフィルタリングして問題を特定します。
• 障害と信頼性: Exceptions、失敗した Requests、および依存関係の障害を調査します。障害率、FunctionExecutionCount の異常、または DLQ/poison キューの増加に対してアラートを構成します。Storage Queue トリガーの場合は -poison キューを監視し、Service Bus/Event Hubs の場合はデッドレターとチェックポイントの状態を監視します。一時的なエラーの影響を軽減するために、host.json のリトライポリシーとバックオフを調整します。
• 分散トレーシング: W3C トレースヘッダーを有効にして、HTTP とメッセージングを介して相関関係を伝播させます。Durable Functions の場合、フレームワークはオーケストレーションとアクティビティのテレメトリをリンクさせ、エンドツーエンドの診断を支援します。コストと忠実度のバランスを取るためにサンプリングを調整します。

デプロイ自動化（GitHub Actions/Azure Pipelines）、HTTP エンドポイントのヘルスプローブ、および自動スケーリングを意識したチューニングを使用して関数を運用します。パッケージを軽量に保ち、クライアント（例: HttpClient, Service Bus client）を静的なシングルトンとしてキャッシュし、ランタイムエラーを防ぐためにバインディングの接続設定が起動時に解決されることを検証します。

実践的な問題シナリオ

Contoso Retail は、顧客がカートに商品を追加するとリアルタイムで割引を適用するプロモーションサービスを開始します。バックエンドは、変動の激しいトラフィックに低レイテンシーで応答し、サードパーティの価格設定 API を呼び出し、Cosmos DB のカートドキュメントを更新する必要があります。運用チームは、ゼロダウンタイムのデプロイと障害に対する深い可視性を求めています。

1. ホスティングプランを選択し、アプリを構成する

• 2つの事前ウォーミングされたインスタンスと VNET 統合を備えた Azure Functions Premium プランを使用します。Premium プランは、レイテンシーに敏感なカート操作のコールドスタートを排除し、VNET 内の NAT またはファイアウォールを介してサードパーティ API へのアウトバウンドトラフィックを保護します。
• カートエンドポイント用の HTTP トリガー関数と、割引の取得とカートの更新を調整するための Durable Functions オーケストレーターを持つ単一の Function App を作成します。

2. 信頼性と並列性のために Durable オーケストレーションを実装する

• オーケストレーター関数: 入力を検証し、アクティビティ関数を介して各カート品目の割引を並行して取得するためにファンアウトし、その後ファンインして最適な価格を集計する、という一連のステップを連鎖させます。Durable オーケストレーションは、決定論的な制御フローと再起動に対する回復力を保証します。
• アクティビティ関数: 1つのアクティビティはリトライポリシー付きでサードパーティ API を呼び出し、もう1つは出力バインディングを介して Cosmos DB のカートを更新します。アクティビティは外部 I/O をカプセル化し、オーケストレーターのロジックを複製することなく独立してリトライできます。

3. シンプルさのためにトリガーとバインディングを構成する

• Web フロントエンドからの署名付きリクエストを受け入れるために、Function 認証付きの HTTP トリガーを使用します。実行時間の長いカートにはステータス URL と共に 202 を返し、高速なパスには 200 を返します。
• アクティビティに Cosmos DB 出力バインディングを設定し、カートドキュメントを upsert します。バインディング式は、HTTP ペイロードの cartId を使用して正しいパーティションキーをターゲットにします。
• Cosmos DB と Key Vault 参照にはマネージド ID と ID ベースの接続を使用し、アプリ設定からシークレットを削除します。

4. 構成とデプロイを最適化する

• host.json で functionTimeout を無制限（Premium）に設定し、サービスメッシュに適した HTTP タイムアウトを構成します。ログレベルは本番環境では Information に調整し、コストを管理するために Samples は 20% に設定します。
• バージョン管理された Blob コンテナーに保存されたパッケージで run-from-package を使用します。CI を介して az functionapp deployment でデプロイし、ステージングスロットから本番環境にスワップすることで、ゼロダウンタイムのリリースを実現します。接続文字列と API エンドポイントをスロット設定としてマークし、環境間の漏洩を防ぎます。

5. 監視と運用

• リリース中にスループットとレイテンシーを監視するために、Application Insights と Live Metrics を有効にします。HTTP 5xx、価格設定 API への依存関係の障害率、および Durable Function の失敗したオーケストレーションの増加に対してアラートを構成します。
• 分散トレーシングを使用して HTTP リクエストを Durable オーケストレーションおよびアクティビティの依存関係と相関させ、断続的なサードパーティの問題の根本原因分析を迅速化します。

これらの選択の理由：

• 事前ウォーミングされたインスタンスを備えた Premium プランは、一貫して低いレイテンシーを保証し、安全なエグレスのための VNET 統合をサポートします。
• Durable Functions は、外部 API 呼び出しに対する自動的な状態管理とリトライ管理を備えた、信頼性の高い連鎖処理とファンアウト/ファンインを提供します。
• バインディングは定型コードを削減し、Cosmos DB への一貫した宣言的なデータアクセスを強制します。
• Run-from-package とスロットは、ファイルロックの問題やダウンタイムなしで、再現可能でアトミックなデプロイを実現します。
• Application Insights は、運用 SLA に沿ったリアルタイムの可観測性、相関分析、およびアラート機能を提供します。

← Azure App Service と Web Apps · すべてのドメイン · Azure Storage と Blob Storage →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Microsoftを閲覧 →