関数アプリを別の Azure リージョンに再配置する
この記事では、Azure Functions でホストされる関数アプリを別の Azure リージョンに移動する方法について説明します。
既存の Azure リソースを 1 つのリージョンから他のリージョンに移動する必要が生じる理由は多数存在します。 以下を行うことができます。
- 新しい Azure リージョンの利点を活用する。
- 特定のリージョンでしか利用できない機能やサービスをデプロイする。
- 内部ポリシーやガバナンスの要件を満たす。
- 会社の合併と買収に合わせた調整を行う
- 容量計画の要件を満たす。
関数アプリをホストする Azure リソースはリージョン固有のものであり、リージョン間で移動できません。 代わりに、既存の関数アプリのリソースのコピーをターゲット リージョンに作成してから、関数のコードを新しいアプリに再デプロイする必要があります。
このような同じリソースを別のリソース グループまたはサブスクリプションに移動できますが、その同じリソースが同じリージョンに残っている場合に限られます。 詳細については、新しいリソース グループまたはサブスクリプションへの App Service リソースの移動に関するページを参照してください。
前提条件
- ターゲット リージョンで Azure Functions と、リソースを移動する関連サービスがサポートされていることを確認します。
- 必要なリソースを新しいリージョンに作成する権限があることを確認します。
準備
ソース リージョンで使用されている関数アプリのリソースをすべて特定します。これには、以下が含まれると考えられます。
- 関数アプリ
- ホスティング プラン
- デプロイ スロット
- Azure で購入したカスタム ドメイン
- TLS/SSL の証明書と設定
- 構成済みのネットワーク オプション
- マネージド ID
- 構成済みのアプリケーション設定
- スケーリング構成
アプリを新しいリージョンに移動する準備をする場合、アーキテクチャには、特別な考慮事項と計画が必要な部分がいくつか存在します。
関数アプリ名
関数アプリ名は、すべての Azure アプリ全体で一意である必要があります。 つまり、新しい関数アプリに指定する名前と URL は元のものと同じであってはなりません。 これは、カスタム DNS を使用する場合にも当てはまります。基になる <APP_NAME>.azurewebsites.net も一意であることが求められるためです。 関数アプリの HTTP エンドポイントに接続するクライアントの更新が必要になる場合があります。 これらのクライアントでは、要求を行うときに新しい URL を使用する必要があります。
ソース コード
ソース コードは、何らかの種類のコード リポジトリ内、または Linux コンテナーで実行する場合はコンテナー リポジトリ内に維持することをお勧めします。 継続的デプロイを使用している場合は、リポジトリまたはコンテナーのデプロイ接続を新しい関数アプリのアドレスに切り替えることを計画してください。 何らかの理由でソース コードがなくなっている場合は、元の関数アプリから現在実行中のパッケージをダウンロードできます。 ソース ファイルはコード リポジトリに保存し、更新プログラムの継続的デプロイを使用することをお勧めします。
既定のストレージ アカウント
Functions ホストを使用するには Azure Storage アカウントが必要です。 詳細については、「ストレージ アカウントの要件」をご覧ください。 最適なパフォーマンスを得るには、関数アプリで同じリージョンのストレージ アカウントを使用する必要があります。 新しいリージョンの新しいストレージ アカウントを使用して新しいアプリを作成すると、アプリで新しい関数アクセス キーのセットが得られ、トリガー (タイマー トリガーなど) の状態がリセットされます。
永続化されたローカル ストレージ
関数の実行は状態非依存であることが意図されています。 ただし、データをローカル ファイル システムに書き込むことができないわけではありません。 アプリケーションによって生成および使用されるデータは %HOME%\site 仮想ドライブに保存できますが、このデータは状態に関連していてはなりません。 ご自分のシナリオで、関数の実行間で状態を維持することが求められる場合は、代わりに Durable Functions の使用を検討してください。
アプリケーションでアプリの共有ストレージ パスにデータが永続化される場合は、リソースの移動中にその状態をどのように管理するかを計画する必要があります。 専用 (App Service) プラン アプリの場合、その共有はサイトの一部であることに注意してください。 従量課金および Premium プランの場合、既定では、その共有は既定のストレージ アカウント内の Azure Files 共有です。 Linux 上で実行されているアプリでは、永続化されたストレージ用に明示的にマウントされた共有が使用される場合があります。
接続済みサービス
関数は、サービス SDK またはトリガーとバインドを使用して、Azure サービスやその他のリソースに接続する場合があります。 接続済みサービスは、アプリが新しいリージョンに移動されると、悪影響を受けるおそれがあります。 待機時間またはスループットに問題がある場合は、接続済みサービスも新しいリージョンに移動することを検討してください。 これらのリソースをリージョン間で移動する方法については、それぞれのサービスのドキュメントを参照してください。 接続済みサービスと共にアプリを移動する場合は、移動時にリージョン間でのディザスター リカバリーと事業継続戦略を検討することをお勧めします。
接続済みサービスに変更を行う場合、アプリケーション設定に保存されている値 (これらのサービスへの接続に使用されるもの) の更新が必要になる可能性があります。
構成
Azure portal から、既存のアプリ設定と接続文字列のスナップショットをキャプチャできます。 [設定]>[環境変数] を展開し、[アプリ設定] または [接続文字列] で [高度な編集] を選択して、既存の設定または接続を含む JSON 出力を保存します。 これらの設定は新しいリージョンで再作成する必要がありますが、値自体は、接続済みサービスでのその後のリージョン変更の結果として変更される可能性があります。
既存の Key Vault の参照は、Azure の地理的境界を越えてエクスポートできません。 必要な参照は新しいリージョンで再作成する必要があります。
アプリ構成は、Azure App Configuration によって、または他の何らかの中央 (ダウンストリーム) データベースの依存関係から管理される場合があります。 変更が必要と考えられる環境およびリージョンに固有の設定については、App Configuration ストアまたは同様のストアを確認してください。
カスタム ドメイン
お使いの関数アプリでカスタム ドメインを使用する場合は、ターゲット アプリに事前にバインドします。 ターゲット アプリでドメインを確認して有効にします。 移動後に、ドメイン名を再マップする必要があります。
仮想ネットワーク
Azure Functions を使用すると、お使いのアプリを仮想ネットワーク リソースと統合して、仮想ネットワークで実行することもできます。 詳細については、「Azure Functions のネットワーク オプション」をご覧ください。 新しいリージョンに移動する際は、アプリをデプロイする前に、まず必要なすべての仮想ネットワークとサブネットのリソースを移動または再作成する必要があります。 これには、プライベート エンドポイントとサービス エンドポイントの移動や再作成が含まれます。
ID
新しいターゲット リージョンで、アプリと共にシステム割り当てマネージド ID を再作成する必要があります。 通常、自動的に作成された、EasyAuth で使用される Microsoft Entra ID アプリは、既定でアプリ リソース名に設定されます。
ユーザー割り当てマネージド ID も、リージョン間で移動できません。 ユーザー割り当てマネージド ID をアプリと同じリソース グループに保持するには、それらを新しいリージョンで再作成する必要があります。 詳細については、「Azure リソースのマネージド ID を別のリージョンに再配置する」を参照してください。
再配置されるサービスのマネージド ID に、それによって置き換えられる元の ID と同じアクセス許可 (グループ メンバーシップを含む) を付与します。
証明書
App Service 証明書リソースは、新しいリソース グループまたはサブスクリプションに移動できますが、リージョン間では移動できません。 エクスポート可能な証明書を、新しいリージョンのアプリまたは Key Vault にインポートすることもできます。 このエクスポートとインポートのプロセスは、リージョン間の移動と同じです。
サービスの再配置を計画するときに考慮する必要がある証明書の種類には、さまざまなものがあります。
| 証明書タイプ | Exportable | Comments |
|---|---|---|
| App Service マネージド | いいえ | これらの証明書を新しいリージョンで再作成します。 |
| Azure Key Vault マネージド | はい | これらの証明書は、Key Vault からエクスポートした後、新しいリージョンの Key Vault にインポートできます。 |
| 秘密キー (自己管理型) | はい | Azure の外部で取得した証明書は、App Service からエクスポートした後、新しいリージョンの新しいアプリまたは Key Vault にインポートできます。 |
| 公開キー | いいえ | アプリの証明書の中には、公開キーのみがあって秘密を含まないものがあります。これらは、他のセキュリティ保護エンドポイントへのアクセスに使用されます。 必要な公開キー証明書ファイルを取得し、新しいリージョン内のアプリにインポートします。 |
アクセス キー
Functions では、アクセス キーを使用して、関数アプリ内の HTTP エンドポイントへのアクセスをより困難にします。 これらのキーは、既定のストレージ アカウントに暗号化されて維持されます。 新しいリージョンに新しいアプリを作成すると、新しいキー セットが作成されます。 アクセス キーを使用する既存のクライアントは、新しいリージョンの新しいキーを使用するように更新する必要があります。 新しいキーを使用する必要がありますが、新しいアプリで古いキーを再作成することもできます。 詳細については、「Azure Functions でのアクセス キーの使用」を参照してください。
ダウンタイム
最小のダウンタイムが要件である場合は、推奨どおり両方のリージョンで関数アプリを実行してディザスター リカバリー アーキテクチャを実装することを検討してください。 実装する具体的なアーキテクチャは、関数アプリのトリガーの種類によって異なります。 詳細については、「Azure Functions の信頼性」をご覧ください。
Durable Functions
Durable Functions 拡張機能を使用すると、オーケストレーションを定義できます。この場合、ステートフル エンティティを使用して関数の実行時に状態が維持されます。 理想的には、Durable Functions アプリを移行する前に (特に新しいリージョンの新しいストレージ アカウントに切り替える予定の場合)、オーケストレーションの実行を完了できるようにする必要があります。 Durable Functions アプリを移行するときは、こちらのディザスター リカバリーと地理的分散戦略のうちの 1 つを使用することを検討してください。
Relocate
新しいリージョンで関数アプリを再作成するには、まず、App Service プラン、関数アプリ インスタンス、関連リソース (仮想ネットワーク、ID、スロットなど) を含む Azure インフラストラクチャを再作成する必要があります。 また、再接続するか、または新しいリージョンでアプリに必要な Azure リソースを再作成することも必要です。 これらのリソースには、既定の Azure Storage アカウントと Application Insights インスタンスが含まれると考えられます。
これで、実際のアプリケーション ソース コードまたはコンテナーをパッケージ化して、新しいリージョンで実行されている関数アプリに再デプロイできます。
Azure インフラストラクチャを再作成する
Azure の関数アプリと関連リソースをターゲット リージョンで作成するには、いくつかの方法があります。
- 展開テンプレート: 最初にコードとしてのインフラストラクチャ (IaC) ファイル (Bicep、ARM テンプレート、または Terraform) を使用して関数アプリをデプロイした場合は、新しいリージョンをターゲットにするように以前のデプロイを更新し、それらを使用して新しいリージョンでリソースを再作成できます。 これらのデプロイ ファイルがなくなっている場合は、いつでも Azure portal から既存のリソース グループの ARM テンプレートをダウンロードできます。
- Azure CLI/PowerShell スクリプト: 最初に Azure CLI または Azure PowerShell スクリプトを使用して関数アプリをデプロイした場合は、新しいリージョンを代わりにターゲットにするようにこれらのスクリプトを更新し、実行し直すことができます。 これらのスクリプトがなくなっている場合は、Azure portal から既存のリソース グループの ARM テンプレートをダウンロードすることもできます。
- Azure portal: 最初にポータルで関数アプリを作成した場合、またはスクリプトや IaC ファイルの使用に気が進まない場合は、ポータルですべてを再作成できます。 元のアプリと同じホスティング プラン、言語ランタイム、言語バージョンを使用する必要があります。
構成されたリソースの確認
前の「準備」の手順で特定したリソースをデプロイ中に構成していない場合は、ここで確認してターゲット リージョンに構成します。 マネージド ID 認証を使用する継続的デプロイを使用している場合は、必要な ID とロール マッピングが新しい関数アプリに存在することを確認します。
ソース コードを再デプロイする
インフラストラクチャの準備が整ったので、ソース コードを再パッケージ化して関数アプリに再デプロイできます。 このタイミングで、ソース コードまたはコンテナー イメージをリポジトリに移動し、そのリポジトリから継続的デプロイを有効にすることをお勧めします。
また、Functions でサポートされている他の発行方法を使用することもできます。 ほとんどのツール ベースの発行では、scm エンドポイントで基本認証を有効にする必要がありますが、これは運用環境のアプリではお勧めできません。
再配置に関する考慮事項
- 忘れずに、ターゲット リージョンで構成を検証して関数をテストしてください。
- カスタム ドメインが構成されている場合は、ドメイン名を再マップします。
- 専用 (App Service) プランで実行されている関数アプリの場合、そのプランが 1 つ以上の Web アプリと共有されているときは App Service の移行計画も確認してください。
クリーンアップ
移動が完了したら、ソース リージョンから関数アプリとホスティング プランを削除します。 アプリ自体が実行されていない場合でも、Premium または Dedicated プランでは関数アプリの料金が発生します。 新しいリージョンで他のサービスを再作成した場合は、不要になったことが確かめられた古いサービスも削除する必要があります。
関連リソース
より高度で geo 冗長のソリューション アーキテクチャの一環として、複数のリージョンで関数アプリを実行する例については、Azure アーキテクチャ センターを確認してください。