編集

ハイブリッド環境での Azure Functions

Azure Functions
Azure Monitor
Azure Pipelines
Azure Storage
Azure Virtual Network

この参照アーキテクチャでは、地理的に分散している組織の多数のローカル ブランチを示しています。 各場所では、近くのクラウド リージョンで Premium プランで構成されている Microsoft Azure 関数アプリを使用しています。 このアーキテクチャの開発者は、Azure Monitor を 1 つの窓として使用して、すべての Azure 関数アプリを監視しています。

アーキテクチャ

このダイアグラムは、さまざまなリージョンの Azure Functions に接続されている多数のローカル仮想マシン (VM) を示しています。開発者は、Azure Monitor を使用して関数アプリを監視しています。

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

Components

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

  • Azure Functions 。 Azure Functions は、新しいインフラストラクチャを構築する必要なく、小さな単一タスクのコードを実行する Azure のサービスとしてのサーバーレス プラットフォーム (PaaS) です。 Azure Functions Premium プランでは、仮想ネットワーク経由で Azure Functions とプライベートに通信する機能が追加されます。
  • Azure Virtual Network 。 Azure Virtual Network は、Azure リソースがセキュアな方法で相互に通信できるように、Azure クラウド プラットフォームに構築されたプライベート ネットワークです。 Azure Virtual Network のサービス エンドポイントにより、Azure リソースは、セキュアな仮想ネットワーク バックボーンでのみ通信できます。
  • オンプレミス ネットワーク。 このアーキテクチャで、組織はさまざまなブランチを接続するセキュアなプライベート ネットワークを作成しています。 このプライベート ネットワークは、サイト間接続を使用して、Azure 仮想ネットワークに接続されています。
  • 開発者ワークステーション。 このアーキテクチャでは、個々の開発者が、セキュアなプライベート ネットワークまたは任意のリモートの場所から、Azure Functions のコードを完全に操作できます。 どちらのシナリオでも、開発者は Azure Monitor にアクセスして、関数アプリのメトリックとログをクエリまたは監視できます。

シナリオの詳細

このアーキテクチャの一般的な用途は次のとおりです。

  • Azure 内の仮想ネットワークに接続され、Azure Functions と通信する多数の物理的な場所がある組織。
  • Azure Functions をローカルに使用し、作業中の予期しないバーストに Azure を使用するオプションを保持している、高成長のワークロード。

Recommendations

ほとんどのシナリオには、次の推奨事項が適用されます。 これらの推奨事項には、オーバーライドする特定の要件がない限り、従ってください。

サーバーレス アーキテクチャの設計

従来のエンタープライズ アプリケーションは、1 つのコード "ソリューション" で、組織のビジネス ロジック全体を実行するモノリシック アプリケーション アーキテクチャに向かう傾向があります。 Azure Functions では、ベスト プラクティスとして、個々の関数が 1 つのタスクを実行するサーバーレス アーキテクチャを設計します。 これらの 1 つのタスクは、迅速に実行し、より大きなワークフローに統合するように設計されています。

Azure Functions のサーバーレス アーキテクチャには、次のような多くの利点があります。

  • アプリケーションは、ソリューション全体をスケーリングするのではなく、個々のビジネス機能別に自動的にスケーリングすることができます。 これにより、各タスクで既存のワークロードを処理するために必要なものだけをスケーリングすることで、コストを抑えることができます。
  • Azure Functions には、多くの Azure サービスのための宣言型バインドが用意されており、チームが記述、テスト、および管理する必要のあるコードの量が少なくなります。
  • 個々の関数を再利用して、大規模なエンタープライズ ソリューションに必要な繰り返しコードの量を減らすことができます。

オンプレミスでの Azure Functions の実行

Azure Functions を Azure ではなく、オンプレミスで 実行させることを選択できます。例:

  • チームは、既存のオンプレミス Kubernetes インストール内で Azure Functions を実行する必要がある場合があります。
  • 開発時に、チームはポータル内エディターではなくコマンド ライン インターフェイスを使用して、ローカルで開発する方が簡単であることに気付く場合があります。
  • 関数は、オンプレミスの VM にインストールされているツールセットを使用してローカルで実行します。

オンプレミスで Azure Functions を実行するには、次の 3 つの方法があります。

ネットワーク接続

Premium プランを使用して関数アプリを作成すると、Azure Virtual Networks、Azure、およびオンプレミス ネットワークと各オンプレミス ブランチのネットワーク間で、高度にセキュアなクロスネットワーク接続の可能性が広がります。

Azure Virtual Network とオンプレミス ネットワーク間では、サイト間接続または Azure ExpressRoute 接続を使用する必要があります。 これにより、オンプレミスのブランチでは、サービス エンドポイントを使用して、Azure 内の関数アプリと通信できます。

さらに、Azure の各仮想ネットワークでは、仮想ネットワーク ピアリングを使用して、リージョン間で個々の関数アプリ間の通信を可能にする必要もあります。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

スケーラビリティ

  • Azure Functions コードは、無限にスケールアウトできるように設計する必要があります。 競合状態、リースされたファイル、およびある関数の実行が他をブロックする可能性があるその他のワークロードを考慮します。 また、すべての Azure Functions コードをその設計においてステートレスで防御的になるように記述することも考慮してください。
  • トリガーまたはバインディングで Azure Storage アカウントを使用する関数アプリでは、関数アプリとそれらの実行に関するメタデータの格納に使用しているものと同じアカウントを再利用しないでください。

可用性

  • 通常、従量課金プランの Azure Functions はゼロ インスタンスにスケールダウンできます。 新しいイベントによって関数アプリがトリガーされたら、コードを実行する新しいインスタンスが作成される必要があります。 このプロセスに関連する待機時間は、コールド スタートと呼ばれます。 Azure Functions Premium プランには、新しい要求に対する準備ができている事前ウォーミングされたインスタンスを構成するオプションがあります。 スケールアウト構成で、インスタンスの最小数まで、事前ウォーミングされたインスタンスの数を構成できます。
  • 複数のリージョンで複数の Premium プランを使用し、Azure Traffic Manager を使用して要求を適切にルーティングすることを検討してください。

管理の容易性

  • Azure Functions は、他の Azure リソースと異なるサブネットである空のサブネットに存在する必要があります。 これにより、仮想ネットワークのサブネットの設計時に、より多くの計画が必要になることがあります。
  • Azure Functions でアクセスする必要がある可能性のあるすべてのオンプレミス リソースに対してプロキシを作成することを検討してください。 これにより、予期しないオンプレミスのネットワークの変更に対して、アプリケーションの整合性を保護できます。
  • Azure Monitor を使用して、ソリューション全体の Azure Functions の分析とログを監視します。

DevOps

  • 理想的には、デプロイ操作は、個々のブランチからではなく、1 つのチーム (Dev または DevOps) から行われる必要があります。 Azure Pipelines または GitHub Actions などの最新のワークフロー システムを使用して、すべての Azure リージョンと可能性のあるオンプレミス全体に、反復可能な方法で関数アプリをデプロイすることを検討してください。
  • ワークフロー システムを使用して、コードが更新され、リリースのタグ付けがされたときに、Azure Functions へのコードの再展開を自動化します。
  • デプロイ スロットを使用して、運用環境への最終的なプッシュの前に Azure Functions をテストします。

コストの最適化

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

  • コストの見積もりには、Azure 料金計算ツールをご利用ください。
  • Azure Functions Premium プランは、Azure Virtual Network 接続、プライベート サイト アクセス、サービス エンドポイント、および事前ウォーミングされたインスタンスに必要です。
  • Azure Functions Premium プランは、使用量ではなく、インスタンスに対して課金されます。 最小が 1 つのインスタンスであるため、実行しなくても、少なくともいくらかの月々の請求があります。 最大インスタンス数を設定して、サイズがバーストする可能性のあるワークロードのコストを制御できます。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

Azure Functions については、次のアーキテクチャ ガイダンスを参照してください。

Azure Virtual Networks については、次のアーキテクチャ ガイダンスを参照してください。