Azure Functions デプロイ スロット

Flex Consumption でスロットを使用せずにデプロイする

Flex Consumption プランは展開スロットをサポートしていません。 制御リリースやゼロダウンタイムデプロイの場合は、 ローリングアップデートをサイト更新戦略として活用しましょう。

Azure Container Apps でリビジョンを使用してデプロイする

Azure Functions on Azure Container Apps はデプロイ スロットを使いません。 リビジョンを使用して、関数アプリの各バージョン間でトラフィックを管理し、振り分けます。

消費型、プレミアム型、専用プランでは、展開スロットは以下の通りに動作します:

• ルーティングスイッチ中、新しい機能トリガー呼び出しは明示的なアプリケーション再起動なしで交換されたスロットにルーティングされます。
• スロットスワップがダウンタイムゼロを保証するわけではありません。 現在実行中の関数は終了し、スロット スワップ操作中にスケーリングされたアプリで可用性が低下する可能性があります。 ステートレスで防御的な関数を記述する方法については、「Azure Functions のパフォーマンスと信頼性の向上」を参照してください。 ダウンタイムゼロの展開が必要な場合は、サイト更新戦略としてローリング 更新プログラムを含む Flex 従量課金プランを検討してください。

スロットを使用する理由

デプロイ スロットの使用には、次のように多くの利点があります。

• 目的に応じて異なる環境:異なるスロットを使うことで、本番やステージングスロットに切り替える前にアプリインスタンスを区別できます。
• プリウォーム:本番環境に直接行わずスロットにデプロイして、アプリを稼働前にウォームアップしましょう。 また、スロットを使うことでHTTPトリガーワークロードの遅延が減ります。 インスタンスはデプロイ前にウォームアップされるため、新しくデプロイされた関数のコールド スタートが減少します。
• 簡単なフォールバック: 運用環境とのスワップ後も、以前にアプリがステージングされたスロットに、以前の運用アプリが存在します。 もし本番スロットに切り替えた変更が期待通りでなければ、すぐに切り替えを元に戻して「最後に確認された良好なインスタンス」を取り戻すことができます。
• 再起動を最小限にする: 運用スロットでアプリ設定を変更するには、実行中のアプリの再起動が必要です。 代わりに、ステージング スロットの設定を変更し、その設定変更を事前に準備されたインスタンスを使用して運用環境に入れ替えることができます。 スロットは、最も高い可用性を維持しながら Functions ランタイム バージョン間で移行する場合に推奨される方法です。 詳細については、「最小ダウンタイムの更新」を参照してください。

スワップ操作

スワップ中は、1つのスロットがソース、もう1つのスロットがターゲットとなります。 ソーススロットには、ターゲットスロットに適用するアプリケーションのインスタンスが存在します。 次の手順は、スワップ中のターゲット スロットのダウンタイムを減らすのに役立ちます。

1. 設定を適用する: ターゲットスロットからソーススロットのすべてのインスタンスに設定を適用します。 例えば、ステージングインスタンスにプロダクション設定を適用します。 適用される設定には次のカテゴリが含まれます。

   • スロット固有のアプリ設定と接続文字列 (該当する場合)
   • 継続的デプロイの設定 (有効な場合)
   • App Service 認証の設定 (有効な場合)

2. 再起動と可用性を待機する: スワップでは、ソース スロット内のすべてのインスタンスの再起動が完了し、要求で使用できるようになるまで待機します。 いずれかのインスタンスが再起動に失敗した場合、スワップ操作ではすべての変更がソース スロットに戻されて、操作が停止されます。

3. ルーティングの更新: ソーススロットのすべてのインスタンスが正常にウォームアップした場合、2つのスロットはルーティングルールを切り替えてスワップを完了します。 この手順の後は、前にソース スロットでウォーム アップされたアプリはターゲット スロット (運用スロットなど) に存在します。

4. 繰り返し操作: この時点でソース スロットには、スワップ以前にはターゲット スロットにあったアプリがあるため、すべての設定を適用し、ソース スロットのインスタンスを再起動して、同じ操作を完了します。

以下の点に注意してください。

• スワップ操作の任意の時点で、スワップされたアプリの初期化がソース スロットで行われます。 ソース スロットが準備されている間、ターゲット スロットはオンラインのままになります。スワップが成功するか失敗するかは関係ありません。

• ステージングスロットと生産スロットを入れ替えるには、 必ず 生産スロットがターゲットスロットであることを確認してください。 こうすることで、スワップ操作が運用アプリに影響を及ぼしません。

• スワップを始める前に、イベントソースやバインディングに関連する設定をデプロイスロット設定として設定してください。 事前に "固定" としてマークすることで、確実にイベントと出力が適切なインスタンスに送信されるようになります。

• 新しいステージングスロットを作成すると、ポータルはその新しいスロットの生産スロットから既存のすべての設定を作成します。設定の 粘着性 に関わらずです。

設定の管理

一部の設定はスロットごとに特有です。 以下のリストは、スロットを入れ替えるとどの設定が変わるか、どの設定が変わらないかを詳しく示しています。

スロット固有の設定:

• 発行エンドポイント
• カスタム ドメイン名
• パブリックでない証明書と TLS/SSL 設定
• スケールの設定
• IP 制限
• Always On
• 診断設定
• クロスオリジン リソース共有 (CORS)
• プライベート エンドポイント

スロット固有ではない設定:

• フレームワークバージョン、32/64ビット、ウェブソケットなどの一般的な設定
• アプリ設定 (スロット固有として構成可能)
• 接続文字列 (スロット固有として構成可能)
• ハンドラー マッピング
• パブリック証明書
• ハイブリッド接続 *
• Virtual Network 統合 *
• サービス エンドポイント *
• Azure Content Delivery Network *

アスタリスク (*) でマークされた機能は、設計上スワップされません。

デプロイ設定を作成する

設定をデプロイ設定としてマークし、"固定" にすることができます。 固定設定は、アプリ インスタンスとはスワップされません。

あるスロットでデプロイメントを設定する場合は、スワップに関わる他のスロットでも同じ設定を一意の値で作成するようにしてください。 このようにすると、設定の値は変更されませんが、設定の名前はスロット間で一貫性が保たれます。 この名前の一貫性により、あるスロットでは定義されているが、別のものでは定義されていない設定へのアクセスがコードで試行されなくなります。

デプロイ設定を作成するには、次の手順を使用します。

1. 機能アプリのデプロイ スロットに行き 、スロット名を選択してください。

   

2. [構成] を選択し、現在のスロットで固定する設定名を選択します。

   

3. [デプロイ スロットの設定] を選択し、[OK] を選択します。

   

4. 設定セクションが閉じた後、変更を保持するために 「保存 」を選択してください。

   

スロットにアプリをデプロイする

スロットの作成時は、スロットは空になっています。 サポートされているデプロイ テクノロジのいずれかを使用して、アプリケーションをスロットにデプロイできます。

デプロイ スロットのスケール

すべてのスロットが、運用スロットと同じ数のワーカーにスケーリングされます。

• 従量課金プランでは、関数アプリがスケーリングされると、スロットがスケーリングされます。
• App Service プランの場合、アプリは一定数のワーカーにスケーリングされます。 スロットは、アプリ プランと同じ数のワーカーで実行されます。

スロットの表示

既存のスロット情報は、Azure CLIまたはAzureポータルのいずれかを使って確認できます。

az functionapp deployment slot list --name "<APP_NAME>" --resource-group "<RESOURCE_GROUP>"

スロットを追加する

スロットを追加するには、Azure CLIかAzureポータルのいずれかを使っています。

az functionapp deployment slot create --name "<APP_NAME>" --resource-group "<RESOURCE_GROUP>" --slot staging

また、Azure Resource Manager(ARM)テンプレートやBicepファイルを使ってスロットを作成することもできます。 デプロイ スロットを使用して従量課金プランで関数アプリを作成する方法の例については、この Azure Resource Manager クイック スタートを参照してください。

スロット リソースにアクセスする

運用スロットと同じ方法でステージング スロット内のリソース (HTTP トリガーと管理者エンドポイント) にアクセスします。 ただし、関数アプリのホスト名の代わりに、スロット固有のキーと共に、要求 URL にスロット固有のホスト名を使用します。 ステージング スロットはライブ アプリであるため、運用スロットと同様に、ステージング スロット内の関数をセキュリティで保護する必要があります。

スロットをスワップする

本番環境でのスロットの入れ替わりは、Azure CLIかAzureポータルのいずれかを使って行えます。

az functionapp deployment slot swap --name "<APP_NAME>" --resource-group "<RESOURCE_GROUP>" --slot staging --target-slot production

スワップをロールバックする

スワップでエラーが発生したり、元に戻したい場合は、元の状態に戻すことができます。 スワップ前の状態に戻るには、別のスワップを実行してスワップを逆にします。

スロットを削除する

スロットを取り除くには、Azure CLIまたはAzureポータルのいずれかを使うことができます。

az functionapp deployment slot delete --name "<APP_NAME>" --resource-group "<RESOURCE_GROUP>" --slot staging

App Service プランを変更する

機能型アプリがApp Serviceプランで動作する場合、基盤となるApp Serviceプランをスロットごとに変更できます。

スロットの App Service プランを変更するには、次の手順を使用します。

1. 機能アプリのデプロイ スロットに行き 、スロット名を選択してください。

   

2. [App Service プラン] で、[App Service プランの変更] を選択します。

3. アップグレードするプランを選択するか、新しいプランを作成します。

   

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

考慮事項

Azure Functions デプロイ スロットには、次の考慮事項があります。

• アプリで使用できるスロットの数は、プランによって異なります。 消費プランは合計2スロットをサポートしています:生産スロットとステージングスロット1つです。 他のプランで実行されているアプリでは、追加のスロットを使用できます。 詳しくは、「サービスの制限」をご覧ください。
• スロットをスワップすると、AzureWebJobsSecretStorageType アプリ設定が files に等しいアプリのキーがリセットされます。
• スロットを有効にすると、ポータルは機能アプリを読み取り専用モードに設定します。
• スロットスワップは、機能アプリがセ キュアストレージアカウント をデフォルトのストレージアカウント( AzureWebJobsStorage設定)として使っている場合に失敗することがあります。 詳細については、WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGS のリファレンスを参照してください。
• 関数アプリの名前は 32 文字より短いものを使います。 32文字を超える名前は ホストIDの衝突を引き起こすことがあります。