Azure Static Web Apps を別のリージョンに再配置する

この記事では、Azure Static Web Apps リソースを別の Azure リージョンに再配置する方法について説明します。

既存の Azure リソースを 1 つのリージョンから他のリージョンに移動する必要が生じる理由は多数存在します。 以下を行うことができます。

• 新しい Azure リージョンの利点を活用する。
• 特定のリージョンでしか利用できない機能やサービスをデプロイする。
• 内部ポリシーやガバナンスの要件を満たす。
• 会社の合併と買収に合わせた調整を行う
• 容量計画の要件を満たす。

前提条件

再配置の準備をする前に、次の前提条件を確認してください。

• ターゲット リージョンで Azure Static Web Apps が使用可能であることを確認します。

• ターゲット リージョンに静的 Web アプリ リソースを作成する権限があることを確認します。

• 組織に Azure Policy リージョンの制限が適用されているかどうかを確認します。

• Azure Functions によって提供される統合 API サポートを使用する場合は次のことを確認してください。

  • ターゲット リージョンでの Azure Functions の可用性を確認します。
  • 関数 API キーが使用されているかどうかを確認します。 たとえば、Key Vault を使用しているか、アプリケーション構成ファイルの一部としてデプロイしていますか?
  • ターゲット リージョンにおける API サポートのデプロイ モデルを決定します: 分散管理機能または BYO機能。 2 つのモデルの違いを理解します。

• 静的 Web アプリのホスティングに Standard ホスティング プランが使用されていることを確認します。 ホスティング プランの詳細については、「Azure Static Web Apps のホスティング プラン」に関するページをご覧ください。

• 再配置の際に許容されるダウンタイムを確認します。

• Azure Static Web Apps のデプロイによっては、再配置の前に、次の依存リソースをターゲット リージョンにデプロイして構成する必要がある場合があります。

  • Azure Functions。
  • Azure Virtual Network
  • Azure Front Door
  • ネットワーク セキュリティ グループ
  • Azure Private Link サービス
  • Azure Key Vault
  • Azure Storage アカウント
  • Azure Application Gateway

ダウンタイム

Azure 静的 Web サイトを再配置すると、アプリケーションにダウンタイムが発生します。 ダウンタイムは、Azure 静的 Web サイトに実装した高可用性パターンに左右されます。 一般的なパターンは次のとおりです。

• コールド スタンバイ: ワークロード データは、その要件に基づいて定期的にバックアップされます。 障害が発生した場合、ワークロードは新しい Azure リージョンに再デプロイされ、データが復元されます。
• ウォーム スタンバイ: ワークロードは事業継続とディザスター リカバリー (BCDR) リージョンにデプロイされ、データは非同期または同期的に複製されます。 障害が発生した場合、ディザスター リカバリー (DR) リージョンでのデプロイはスケールアップおよびスケールアウトされます。
• マルチリージョン: ワークロードは両方のリージョンにデプロイされ、データは同期的に複製されます。 どちらのリージョンにも、データの書き込み可能なコピーがあります。 実装には、アクティブ/パッシブまたはアクティブ/アクティブを指定できます。

準備

プライベート エンドポイントを使用したデプロイ

静的 Web アプリ がプライベート エンドポイントと共にデプロイされている場合は、次のことを確認します。

• 接続エンドポイントのホスト名を更新します。
• DNS プライベート ゾーンまたはカスタム DNS サーバーのホスト名を更新します (Private Link にのみ適用されます)。

詳細については、「Azure Static Web Apps でプライベート エンドポイントを構成する」を参照してください。

その他のすべてのデプロイ

その他のすべてのデプロイの種類については、次のことを確認します。

• 必要に応じて、新しいリージョンの Azure Functions から新しい関数 API キーを取得します。

• この Azure 関数がデータベースに依存している場合は、DATABASE_CONNECTION_STRING が更新されていることを確認します。 このデータベースは、リージョン移行のスコープに含まれていない可能性があります。

• 静的 Web アプリの新しいホスト名を更新して、カスタム ドメインを指定します。

• Key Vault を使用している場合は、ターゲット リージョンに新しい Key Vault をプロビジョニングします。 必要に応じて、Key Vault の関数 API キーを更新します。 コードまたは構成ファイルに格納されないその他の機密データは、この Key Vault に格納する必要があります

テンプレートをエクスポートする

静的 Web アプリを記述する設定を含む Resource Manager テンプレートをエクスポートする方法は以下のとおりです。

1. Azure portal にサインインします。

2. 静的 Web アプリに移動します。

3. 左側のメニューの [オートメーション] で、[テンプレートのエクスポート] を選択します。

   テンプレートの生成には少し時間がかかる場合があります。

4. [Download] を選択します。

5. ダウンロードした .zip ファイルを検索して、任意のフォルダーに開きます。

   このファイルには、テンプレートおよびテンプレートをデプロイするためのスクリプトを含む .json ファイルが含まれています。

6. ターゲット リージョンで場所を更新するなど、テンプレートに必要な変更を加えます。

Relocate

静的 Web アプリを別のリージョンに再配置するには、次の手順に従います。

1. プライベート エンドポイントを使用して再配置する場合は、「Azure Private Link サービスを別のリージョンに再配置する」のガイドラインに従ってください。

2. 既存の Azure Functions を静的 Web アプリに提供している場合は、Azure Functions の再配置手順に従います。

3. 前のセクションでエクスポートおよび構成したテンプレートを使用して、静的 Web アプリを再デプロイします。

   重要

   カスタム ドメインを使用していない場合は、ターゲット リージョンでアプリケーションの URL が変更されます。 このシナリオでは、ユーザーに URL の変更について必ず周知してください。

4. 統合 API を使用している場合は、Azure Functions でサポートされている新しい統合 API を作成します。

5. リポジトリ (GitHub または Azure DevOps) を再構成して、ターゲット リージョンに新しくデプロイされた静的 Web アプリにデプロイします。 GitHub アクションまたは Azure Pipelines を使用して、アプリケーションのデプロイを開始します。

6. コールド スタンバイ デプロイでは、新しい URL について必ず顧客に通知してください。 カスタム DNS ドメインを使用している場合は、ターゲット リージョンを変更して DNS エントリを指定するだけです。 ウォーム スタンバイ デプロイでは、Front Door や Traffic Manager などのロード バランサーが、ソース リージョン内の静的 Web アプリのターゲット リージョンへの移行を処理します。