Azure Functions のデプロイメントスロット
Azure Functions デプロイ スロットを使用すると、関数アプリで "スロット" と呼ばれる別のインスタンスを実行できます。 スロットは、一般公開されているエンドポイントを介して公開されるさまざまな環境です。 1 つのアプリ インスタンスが常に運用スロットにマップされ、必要に応じて、スロットに割り当てられたインスタンスをスワップできます。
使用可能なスロットの数は、特定のホスティング オプションによって異なります。
| ホスティング オプション | スロット (運用を含む) |
|---|---|
| 従量課金プラン | 2 |
| Flex 従量課金プラン | 現在、サポートされていません |
| Premium プラン | 3 |
| 専用 (App Service) プラン | 1 から 20 |
| コンテナー アプリ | リビジョンを使用 |
スロットのスワップによって関数がどのように影響を受けるかを以下に示します。
- トラフィックのリダイレクトはシームレスです。スワップが原因で要求が削除されることはありません。 このシームレスな動作が発生するのは、次の関数トリガーがスワップされたスロットにルーティングされるためです。
- 現在実行中の関数は、スワップ中に終了します。 ステートレスで防御的な関数を記述する方法については、「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 プランの場合、アプリは一定数のワーカーにスケーリングされます。 スロットは、アプリ プランと同じ数のワーカーで実行されます。
スロットの表示
既存のスロットに関する情報は、Azure CLI または Azure portal を使用して表示できます。
ポータルで新しいスロットを作成するには、次の手順に従います。
関数アプリに移動します。
[デプロイ スロット] を選択すると、既存のスロットが表示されます。
スロットを追加する
スロットは、Azure CLI または Azure portal を使用して追加できます。
ポータルでスロットを作成するには、次の手順に従います。
関数アプリに移動します。
[デプロイ スロット] を選択し、 [+ スロットの追加] を選択します。
スロットの名前を入力して、 [追加] を選択します。
スロット リソースにアクセスする
運用スロットと同じ方法でステージング スロット内のリソース (HTTP トリガーと管理者エンドポイント) にアクセスします。 ただし、関数アプリのホスト名の代わりに、スロット固有のキーと共に、要求 URL にスロット固有のホスト名を使用します。 ステージング スロットはライブ アプリであるため、運用スロットと同様に、ステージング スロット内の関数をセキュリティで保護する必要があります。
スロットをスワップする
Azure CLI または Azure portal を使用して、スロットを運用環境にスワップインおよびアウトできます。
ステージング スロットを運用環境にスワップするには、次の手順を使用します。
関数アプリに移動します。
[デプロイ スロット] を選択し、 [スワップ] を選択します。
![[スロットの追加] アクションが選択されている [デプロイ スロット] ページを示すスクリーンショット。](media/functions-deployment-slots/functions-swap-deployment-slot.png)
スワップの構成設定を確認して、 [スワップ] を選択します。
スワップ操作には数秒かかることがあります。
スワップをロールバックする
スワップによってエラーが発生した場合、またはスワップを "元に戻す" だけの場合は、初期状態にロールバックすることができます。 スワップ前の状態に戻るには、別のスワップを実行してスワップを逆にします。
スロットを削除する
スロットを削除するには、Azure CLI または Azure portal を使用します。
ポータルでアプリからスロットを削除するには、次の手順に従います。
関数アプリでデプロイ スロットに移動し、スロット名を選択します。
[削除] を選択します。
![[削除] アクションが選択されている [概要] ページを示すスクリーンショット。](media/functions-deployment-slots/functions-delete-deployment-slot.png)
削除するデプロイ スロットの名前を入力し、 [削除] を選択します。
確認ウィンドウを閉じます。
App Service プランを変更する
App Service プランで実行されている関数アプリでは、スロットの基になる App Service プランを変更することができます。
Note
従量課金プランでは、スロットの App Service プランを変更することはできません。
スロットの App Service プランを変更するには、次の手順を使用します。
関数アプリでデプロイ スロットに移動し、スロット名を選択します。
[App Service プラン] で、 [App Service プランの変更] を選択します。
アップグレードするプランを選択するか、新しいプランを作成します。
[OK] を選択します。
考慮事項
Azure Functions のデプロイメントスロットには、次の考慮事項があります。
- アプリで使用できるスロットの数は、プランによって異なります。 従量課金プランでは 1 つのデプロイ スロットのみが許可されます。 他のプランで実行されているアプリでは、追加のスロットを使用できます。 詳しくは、「サービスの制限」をご覧ください。
- スロットをスワップすると、
AzureWebJobsSecretStorageTypeアプリ設定がfilesに等しいアプリのキーがリセットされます。 - スロットが有効になっている場合、関数アプリはポータルで読み取り専用モードに設定されます。
- スロットのスワップは、関数アプリでセキュリティで保護されたストレージ アカウントが既定のストレージ アカウント (
AzureWebJobsStorageに設定) として使用されている場合に失敗することがあります。 詳しくは、WEBSITE_OVERRIDE_STICKY_DIAGNOSTICS_SETTINGSのリファレンスを参照してください。 - 関数アプリの名前は 32 文字より短いものを使います。 32 文字より長い名前は、ホスト ID の競合を引き起こす危険性があります。