Azure Functions デプロイ スロット
Azure Functions デプロイ スロットを使用すると、関数アプリで "スロット" と呼ばれる別のインスタンスを実行できます。 スロットは、一般公開されているエンドポイントを介して公開されるさまざまな環境です。 1 つのアプリ インスタンスが常に運用スロットにマップされ、必要に応じて、スロットに割り当てられたインスタンスをスワップできます。 App Service プランで実行されている関数アプリには複数のスロットが含まれる場合がありますが、従量課金プランでは 1 つのスロットのみが許可されます。
スロットのスワップによって関数がどのように影響を受けるかを以下に示します。
- トラフィックのリダイレクトはシームレスです。スワップが原因で要求が削除されることはありません。 このシームレスな動作は、スワップされたスロットに次の関数トリガーがルーティングされた結果です。
- 現在実行中の関数は、スワップ中に終了します。 ステートレス機能と防御機能を記述する方法については、「Azure Functions のパフォーマンスと信頼性の向上」を参照してください。
スロットを使用する理由
デプロイ スロットの使用には多くの利点があります。 次のシナリオでは、スロットの一般的な使用法について説明します。
- さまざまな目的に応じたさまざまな環境:さまざまなスロットを使用することで、運用またはステージング スロットにスワップする前に、アプリ インスタンスを区別できます。
- 事前ウォーミング:直接運用環境にではなく、スロットにデプロイすると、アプリをウォームアップしてから運用を開始することができます。 さらに、スロットを使用すると、HTTP によってトリガーされるワークロードの待機時間が短縮されます。 インスタンスはデプロイ前にウォームアップされるため、新しくデプロイされた関数のコールド スタートが減少します。
- 簡単なフォールバック:運用環境とのスワップ後も、以前にアプリがステージングされたスロットに、以前の運用アプリが存在します。 運用スロットにスワップされた変更が期待どおりでない場合は、すぐにスワップを逆にして、"最新の既知の良好なインスタンス" に戻すことができます。
- 再起動を最小限にする: 運用スロットでアプリ設定を変更するには、実行中のアプリの再起動が必要です。 代わりに、ステージング スロットの設定を変更し、その設定変更を事前に準備されたインスタンスを使用して運用環境に入れ替えることができます。 これは、最も高い可用性を維持しながら Functions ランタイム バージョン間でアップグレードする場合に推奨される方法です。 詳細については、「最小ダウンタイムのアップグレード」を参照してください。
スワップ操作
スワップ中は、一方のスロットがソースと見なされ、もう一方がターゲットと見なされます。 ソース スロットには、ターゲット スロットに適用されるアプリケーションのインスタンスがあります。 次の手順では、スワップ中にターゲット スロットでダウンタイムが発生しないようにします。
設定を適用する: ターゲット スロットからの設定は、ソース スロットのすべてのインスタンスに適用されます。 たとえば、運用設定はステージング インスタンスに適用されます。 適用される設定には次のカテゴリが含まれます。
- スロット固有のアプリ設定と接続文字列 (該当する場合)
- 継続的デプロイの設定 (有効な場合)
- App Service 認証の設定 (有効な場合)
再起動され、使用できるようになるまで待機する: スワップでは、ソース スロット内のすべてのインスタンスの再起動が完了し、要求で使用できるようになるまで待機します。 いずれかのインスタンスが再起動に失敗した場合、スワップ操作ではすべての変更がソース スロットに戻されて、操作が停止されます。
ルーティングを更新する: ソース スロットのすべてのインスタンスが正常にウォームアップされている場合、2 つのスロットでは、ルーティング規則を切り替えてスワップを完了します。 この手順の後は、前にソース スロットでウォーム アップされたアプリはターゲット スロット (運用スロットなど) に存在します。
操作を繰り返す: この時点でソース スロットには、スワップ以前にはターゲット スロットにあったアプリがあるため、すべての設定を適用し、ソース スロットのインスタンスを再起動して、同じ操作を完了します。
以下の点に注意してください。
スワップ操作の任意の時点で、スワップされたアプリの初期化がソース スロットで行われます。 ソース スロットが準備されている間、ターゲット スロットはオンラインのままになります。スワップが成功するか失敗するかは関係ありません。
ステージング スロットを運用スロットとスワップする場合は、運用スロットが "常に" ターゲット スロットであるようにします。 こうすることで、スワップ操作が運用アプリに影響を及ぼしません。
"スワップを開始する前" に、イベント ソースおよびバインドに関連する設定をデプロイ スロット設定として構成する必要があります。 事前に "固定" としてマークすることで、確実にイベントと出力が適切なインスタンスに送信されるようになります。
設定の管理
構成設定には、スロット固有のものがあります。 スロットをスワップしたときに変更される設定と変更されない設定を次の一覧に示します。
スロット固有の設定:
- 発行エンドポイント
- カスタム ドメイン名
- パブリックでない証明書と TLS/SSL 設定
- スケールの設定
- IP 制限
- 常時接続
- 診断設定
- クロスオリジン リソース共有 (CORS)
- プライベート エンドポイント
スロット固有ではない設定:
- 一般設定 (フレームワーク バージョン、32/64 ビット、Web ソケットなど)
- アプリ設定 (スロット固有として構成可能)
- 接続文字列 (スロット固有として構成可能)
- ハンドラー マッピング
- パブリック証明書
- ハイブリッド接続 *
- Virtual Network 統合 *
- サービス エンドポイント *
- Azure Content Delivery Network *
アスタリスク (*) 記号付きの機能は、スワップされない予定です。
Note
スワップされていない設定に適用されている特定のアプリ設定もスワップされません。 たとえば、診断の設定はスワップされないため、WEBSITE_HTTPLOGGING_RETENTION_DAYS や DIAGNOSTICS_AZUREBLOBRETENTIONDAYS などの関連するアプリ設定もスワップされません。これは、スロット設定として表示されない場合でも同様です。
デプロイ設定を作成する
設定をデプロイ設定としてマークし、"固定" にすることができます。 固定設定は、アプリ インスタンスとはスワップされません。
1 つのスロットにデプロイ設定を作成する場合は、必ず、スワップに関係する他のすべてのスロットに一意の値を持つ同じ設定を作成してください。 このようにすると、設定の値は変更されませんが、設定の名前はスロット間で一貫性が保たれます。 この名前の一貫性により、あるスロットでは定義されているが、別のものでは定義されていない設定へのアクセスがコードで試行されなくなります。
デプロイ設定を作成するには、次の手順を使用します。
関数アプリでデプロイ スロットに移動し、スロット名を選択します。
[構成] を選択し、現在のスロットで固定する設定名を選択します。
[デプロイ スロットの設定] を選択し、 [OK] を選択します。
[設定] セクションが表示されなくなったら、 [保存] を選択して変更を保持します。
デプロイ
スロットの作成時は、スロットは空になっています。 サポートされているデプロイ テクノロジのいずれかを使用して、アプリケーションをスロットにデプロイできます。
Scaling
すべてのスロットが、運用スロットと同じ数のワーカーにスケーリングされます。
- 従量課金プランでは、関数アプリがスケーリングされると、スロットがスケーリングされます。
- App Service プランの場合、アプリは一定数のワーカーにスケーリングされます。 スロットは、アプリ プランと同じ数のワーカーで実行されます。
スロットを追加する
スロットは、CLI を介して、またはポータルを使用して追加できます。 次の手順では、ポータルで新しいスロットを作成する方法を示します。
関数アプリに移動します。
[デプロイ スロット] を選択し、 [+ スロットの追加] を選択します。
スロットの名前を入力して、 [追加] を選択します。
スロットをスワップする
スロットは、CLI を介して、またはポータルを使用してスワップできます。 次の手順では、ポータルでスロットをスワップする方法を示します。
関数アプリに移動します。
[デプロイ スロット] を選択し、 [スワップ] を選択します。
![[スロットの追加] アクションが選択されている [デプロイ スロット] ページを示すスクリーンショット。](media/functions-deployment-slots/functions-swap-deployment-slot.png)
スワップの構成設定を確認して、 [スワップ] を選択します。
スワップ操作の実行中は、操作にしばらく時間がかかる場合があります。
スワップをロールバックする
スワップによってエラーが発生した場合、またはスワップを "元に戻す" だけの場合は、初期状態にロールバックすることができます。 スワップ前の状態に戻るには、別のスワップを実行してスワップを逆にします。
スロットを削除する
スロットは、CLI を介して、またはポータルを使用して削除できます。 次の手順では、ポータルでスロットを削除する方法を示します。
関数アプリでデプロイ スロットに移動し、スロット名を選択します。
[削除] を選択します。
![[削除] アクションが選択されている [概要] ページを示すスクリーンショット。](media/functions-deployment-slots/functions-delete-deployment-slot.png)
削除するデプロイ スロットの名前を入力し、 [削除] を選択します。
[削除の確認] ウィンドウを閉じます。
スロット管理を自動化する
Azure CLI を使用すると、スロットに対する次の操作を自動化できます。
App Service プランを変更する
App Service プランで実行されている関数アプリでは、スロットの基になる App Service プランを変更することができます。
Note
従量課金プランでは、スロットの App Service プランを変更することはできません。
スロットの App Service プランを変更するには、次の手順を使用します。
関数アプリでデプロイ スロットに移動し、スロット名を選択します。
[App Service プラン] で、 [App Service プランの変更] を選択します。
アップグレードするプランを選択するか、新しいプランを作成します。
[OK] を選択します。
考慮事項
Azure Functions デプロイ スロットには、次の考慮事項があります。
- アプリで使用できるスロットの数は、プランによって異なります。 従量課金プランでは 1 つのデプロイ スロットのみが許可されます。 他のプランで実行されているアプリには、追加のスロットを使用できます。 詳しくは、「サービスの制限」をご覧ください。
- スロットをスワップすると、
AzureWebJobsSecretStorageTypeアプリ設定がfilesに等しいアプリのキーがリセットされます。 - スロットが有効になっている場合、関数アプリはポータルで読み取り専用モードに設定されます。
- 関数アプリの名前は 32 文字より短いものを使います。 32 文字より長い名前は、ホスト ID の競合を引き起こす危険性があります。