サーバーレスな Functions アプリの操作

  • [アーティクル]

この記事では、サーバーレスな Functions アプリケーションに対する Azure の運用に関する考慮事項について説明します。 Functions アプリをサポートするために、運用担当者は次のことを行う必要があります。

  • ホスティング構成を理解し、実装します。
  • インフラストラクチャのプロビジョニングを自動化することで、将来のスケーラビリティに対応します。
  • 可用性とディザスター リカバリーの要件を満たすことで、ビジネス継続性を維持します。

計画

運用を計画するには、ワークロードとその要件を理解したうえで、その要件に最適なオプションを設計して構成します。

ホスティング オプションを選択する

Azure Functions Runtime により、ホスティングにおける柔軟性が提供されます。 ホスティング プランの比較表を使用して、ご自身の要件に最適な選択肢を判断します。

  • Azure Functions のホスティング プラン

    各 Azure Functions プロジェクトは、スケーリングとコストの単位である独自の Functions アプリでデプロイと実行が行われます。 Azure Functions に使用できる 3 つのホスティング プランは、従量課金プラン、Premium プラン、および専用 (App Service) プランです。 ホスティング プランによって、スケーリング動作、使用可能なリソース、および仮想ネットワーク接続などの高度な機能のサポートが決まります。

  • Azure Kubernetes Service (AKS)

    Kubernetes ベースの Functions は、Kubernetes ベースのイベントドリブン自動スケーリング (KEDA) によるイベントドリブン スケーリングを使用して、Docker コンテナーで Functions Runtime を提供します。

ホスティング プランの詳細については、次を参照してください。

スケーリングについて

サーバーレスの従量課金と Premium ホスティング プランでは、自動的に "スケーリング" が行われ、受信イベントの数に基づいて Azure Functions のホスト インスタンスが追加されたり削除されたりします。 スケーリングは複数のディメンションで異なる場合があり、プラン、トリガー、およびコード言語に基づいて動作が異なります。

スケーリングの詳細については、次を参照してください。

コールド スタートを理解して対処する

ホスト インスタンスの数が 0 にスケールダウンすると、次の要求に、"コールド スタート" と呼ばれる、Functions アプリを再起動するための待機時間が追加されます。 コールド スタートは、サーバーレス アーキテクチャの大きな論点であり、Azure Functions のあいまいな点です。

Premium ホスティング プランでは、一部のインスタンスをウォーム状態に保つことでコールド スタートが防止されます。 Functions アプリで依存関係を減らして非同期操作を使用した場合も、コールド スタートの影響を最小限に抑えることができます。 ただし、可用性の要件により、Always On を有効にして専用ホスティング プランでアプリを実行する必要がある場合があります。 専用プランでは専用の仮想マシン (VM) が使用されるため、サーバーレスではありません。

コールド スタートの詳細については、「サーバーレスのコールド スタートについて」を参照してください。

ストレージに関する考慮事項を特定する

すべての Azure Functions アプリは、トリガーの管理や関数実行のログ記録などの操作に関して Azure Storage に依存しています。 Functions アプリを作成するときは、BLOB、キュー、テーブル ストレージがサポートされている汎用の Azure Storage アカウントを作成またはリンクする必要があります。 詳細については、「Azure Functions のストレージに関する考慮事項」を参照してください。

ネットワーク設計に関する考慮事項を特定する

ネットワーク オプションを使用すると、Functions アプリでアクセスを制限したり、インターネットでルーティング可能なアドレスを使用せずにリソースにアクセスしたりできます。 ホスティング プランでは、さまざまなレベルのネットワークの分離が提供されています。 ネットワークの分離要件に最適なオプションを選択します。 詳細については、「Azure Functions のネットワーク オプション」をご覧ください。

Production

アプリケーションを運用で使用するように準備するには、ホスティング プランを簡単に再デプロイし、スケールアウト ルールを適用できるようにします。

ホスティング プランのプロビジョニングを自動化する

コードとしてのインフラストラクチャを使用することで、インフラストラクチャのプロビジョニングを自動化できます。 自動プロビジョニングでは、災害発生時の回復性が向上し、機敏性が増して、必要に応じて迅速にインフラストラクチャを再デプロイすることができます。

自動プロビジョニングの詳細については、次を参照してください。

スケールアウト オプションを構成する

自動スケーリングでは、アプリケーションの負荷を処理するのに適切な量の実行リソースが提供されます。 自動スケーリングでは、負荷の増加に対応するためのリソースを追加し、アイドル状態のリソースを削除することでコストを節約します。

自動スケーリング オプションの詳細については、次を参照してください。

Optimization

アプリケーションが運用環境にある場合は、次のことを確認してください。

  • アプリケーションの需要に合わせてホスティング プランをスケーリングできる。
  • 事業継続性、可用性、およびディザスター リカバリーに関する計画がある。
  • ホスティングとアプリケーションの正常性を監視し、アラートを受け取ることができる。

可用性の要件を実装する

Azure Functions は特定のリージョンで実行されます。 可用性を高めるために、同じ Functions アプリを複数のリージョンにデプロイできます。 複数のリージョンで、Functions は "アクティブ/アクティブ" または "アクティブ/パッシブ" の可用性パターンで実行できます。

Azure Functions の可用性とディザスター リカバリーの詳細については、次を参照してください。

ログ記録、アプリケーションの監視、およびアラートの監視

Azure Monitor の Application Insights とログは、ログ、パフォーマンス、およびエラーのデータを自動的に収集し、パフォーマンスの異常を検出します。 Azure Monitor には、問題を診断し、関数の使用を理解するのに役立つ強力な分析ツールが用意されています。 Application Insights は、パフォーマンスと使いやすさを継続的に向上させるのに役立ちます。

Azure Functions のパフォーマンスの監視と分析について詳しくは、次を参照してください。

次のステップ