Azure FunctionsのFlex Consumptionプランで、Rolling updatesが一般提供（GA）になりました。結論から言うと、Flex Consumptionを使っているFunction Appでは、siteUpdateStrategy.typeをRollingUpdateに設定することで、コード更新や一部の構成変更時にインスタンスを一斉再起動せず、段階的に入れ替えるデプロイ方式を選べるようになります。
これにより、デプロイ中の短時間停止や実行中処理の中断を避けやすくなります。ただし、すべてのFunction Appで無条件に有効化すべき機能ではありません。新旧バージョンが一時的に混在するため、後方互換性のない変更、Durable Functions、単一インスタンス構成、デプロイ完了を厳密に待つCI/CDでは注意が必要です。
この記事では、2026年6月3日に更新されたMicrosoft公式情報をもとに、Azure FunctionsのFlex ConsumptionにおけるRolling updatesの変更点、影響範囲、管理者・開発者が確認すべき設定、移行・展開時の注意点を実務目線で整理します。Microsoft Learnでは、Rolling update strategyは一部リージョンで一般提供され、他リージョンにも順次展開中と説明されています。(Microsoft Learn)
Azure FunctionsのRolling updatesとは
Azure FunctionsのRolling updatesは、Flex Consumptionプランで利用できるサイト更新戦略です。コードをデプロイしたり、アプリ設定などの構成を変更したりしたときに、実行中インスタンスをまとめて再起動するのではなく、インスタンスをバッチ単位で順番に入れ替えます。
従来の既定動作に近いRecreateでは、更新後に実行中インスタンスが再作成されるため、短時間の停止や実行中処理の強制終了が起きる可能性があります。一方、RollingUpdateでは、既存インスタンスをドレイン状態にし、新しいイベントを受け付けないようにしながら、実行中の処理を自然に完了させます。その間に、新しいバージョンのインスタンスがスケールアウトされ、最終的にすべてのインスタンスが新バージョンへ置き換わります。(Microsoft Learn)
ここで重要なのは、Rolling updatesは「デプロイのリスクをゼロにする機能」ではなく、「停止や処理中断を抑えながら更新するための仕組み」だという点です。アプリケーション側の互換性設計、監視、ロールバック手順が不十分なまま有効化すると、逆にトラブルの原因になります。
今回の変更点：Flex Consumptionでゼロダウンタイムデプロイを選びやすくなった
今回のアップデートの主なポイントは、Flex ConsumptionプランでRolling updatesが一般提供になり、本番利用を前提に検討しやすくなったことです。Azure Updatesでも「Generally Available: Rolling updates in Flex Consumption」として案内されています。(Microsoft Azure)
Microsoft公式ドキュメントでは、Flex Consumptionでサイト更新が発生するタイミングを「コードのデプロイ」「アプリケーション設定の変更」「その他の構成プロパティの変更」と説明しています。これらの更新時に、SiteUpdateStrategyによってRecreateまたはRolling updateを選択できます。(Microsoft Learn)
主な違いは次のとおりです。
| 観点 | Recreate | RollingUpdate |
|---|---|---|
| 停止時間 | 再起動・再スケール中に短時間停止する可能性がある | バッチ単位で入れ替えるため停止を避けやすい |
| 実行中の関数 | 強制終了される可能性がある | 原則として自然完了を待つ |
| デプロイ速度 | 比較的速い | バッチ更新のため遅くなる場合がある |
| アプリの互換性 | 基本的に1バージョンだけが動く前提 | 新旧バージョンの一時混在を考慮する必要がある |
| 既定設定 | 既定はRecreate | 明示的な設定が必要 |
| 向いている用途 | 短時間停止を許容できる更新、破壊的変更 | 無停止に近い更新、長時間処理、重要な本番ワークロード |
Rolling updatesの価値が大きいのは、HTTP API、イベント処理、キュー処理、業務連携処理など、デプロイ時の中断を避けたいAzure Functionsです。特に、数秒から数分の中断でもユーザー影響や再処理コストが発生するシステムでは、検討する価値があります。
影響範囲：対象はFlex ConsumptionプランのFunction App
Rolling updatesの対象は、Azure FunctionsのFlex Consumptionプランです。Flex ConsumptionはLinuxベースのAzure Functionsホスティングプランで、従量課金モデルをベースにしながら、仮想ネットワーク統合、インスタンスメモリサイズの選択、高速または大規模なスケールアウトなどを利用できるサーバーレスプランです。Microsoft Learnでは、Azure Functionsの推奨サーバーレスホスティングプランとされています。(Microsoft Learn)
一方で、Flex Consumptionにはほかのプランと異なる制約があります。たとえば、現時点でデプロイスロットはサポートされておらず、Flex Consumptionでゼロダウンタイムデプロイを行う場合は、サイト更新戦略としてRolling updatesを使う形になります。(Microsoft Learn)
確認すべき対象は、主に次のようなFunction Appです。
| 確認対象 | Rolling updates検討の優先度 | 理由 |
|---|---|---|
| Flex Consumption上の本番Function App | 高 | 今回の直接的な対象 |
| HTTPトリガーで外部ユーザーにAPIを提供しているFunction App | 高 | デプロイ中の停止がユーザー影響になりやすい |
| Queue、Service Bus、Event Hubなどで業務イベントを処理するFunction App | 高 | 実行中処理の中断や重複処理の影響を確認する必要がある |
| Durable Functionsを利用しているFunction App | 高 | 新旧バージョン混在時のオーケストレーション動作に注意が必要 |
| Consumption、Premium、DedicatedプランのFunction App | 低 | 今回のRolling updates対象ではない |
| Flex Consumptionへの移行を検討中のFunction App | 中 | 移行後のデプロイ方式として設計に含めるべき |
既存のConsumptionやPremiumプランからFlex Consumptionへ「設定変更だけで移行」できるわけではありません。Microsoft Learnでは、別プランからFlex Consumptionへのインプレース移行はサポートされず、新しいFlex ConsumptionプランのFunction Appを作成してコードを再デプロイする必要があると説明されています。(Microsoft Learn)
RecreateとRollingUpdateの判断基準
Rolling updatesは魅力的ですが、すべてのデプロイに最適とは限りません。実務では「無停止にしたいか」だけでなく、「新旧バージョンが同時に動いても安全か」で判断する必要があります。
RollingUpdateを選びやすいケース
RollingUpdateが向いているのは、次のようなケースです。
- デプロイ中の短時間停止も避けたい本番API
- 実行中の関数処理を途中で切りたくない
- キュー処理やイベント処理で処理中断による再試行・重複を減らしたい
- 変更内容が後方互換性を保っている
- DBスキーマや外部API仕様が、新旧どちらのコードからも扱える
- デプロイ完了を厳密に同期せず、監視で段階的に確認できるCI/CDになっている
たとえば、HTTP APIでレスポンス項目を1つ追加するだけなら、旧バージョンが返すレスポンスと新バージョンが返すレスポンスが混在しても、クライアント側が許容できる設計にしておけばRollingUpdateと相性がよいです。
Recreateを選んだほうがよいケース
一方で、次のような変更ではRecreateのほうが安全な場合があります。
- DBスキーマ変更とコード変更が強く依存している
- 旧バージョンと新バージョンが同時に動くとデータ不整合が起きる
- 設定値の変更後、古いインスタンスが残ると誤動作する
- 破壊的変更を含むリリースで、全インスタンスを一気に新バージョンへ切り替えたい
- デプロイ完了時刻を厳密に管理したい
- 多少の停止より、短く予測しやすい切り替えを優先したい
たとえば、メッセージのJSON構造を変更し、旧コードでは新形式を処理できず、新コードでは旧形式を処理できない場合、RollingUpdate中に新旧の処理が混在してエラーが増える可能性があります。この場合は、まず両方の形式を読める中間バージョンを出す、または停止時間を設けてRecreateで切り替える判断が現実的です。
Rolling updatesを有効化する設定
Rolling updatesは既定で有効になるわけではありません。既定のSiteUpdateStrategy.typeはRecreateです。RollingUpdateを使うには、Flex ConsumptionのFunction Appに対して明示的に設定します。Microsoft Learnでは、Azure CLI 2.87.0以降、Bicep、ARMテンプレートのAPIバージョン2023-12-01以降で設定できると説明されています。(Microsoft Learn)
Azure CLIで有効化する例は次のとおりです。
az functionapp update-strategy config set \
--name MyFunctionApp \
--resource-group MyResourceGroup \
--type RollingUpdate現在の設定を確認するには、次のコマンドを使います。
az functionapp update-strategy config show \
--name MyFunctionApp \
--resource-group MyResourceGroupAzure CLIのリファレンスでは、--typeに指定できる値はRecreateまたはRollingUpdateです。(Microsoft Learn)
Bicepで管理している場合は、Function AppのfunctionAppConfig配下にsiteUpdateStrategyを定義します。
functionAppConfig: {
siteUpdateStrategy: {
type: 'RollingUpdate'
}
}ARMテンプレートでは、同じくfunctionAppConfig配下に次のように指定します。
{
"functionAppConfig": {
"siteUpdateStrategy": {
"type": "RollingUpdate"
}
}
}運用上は、ポータルで手動設定して終わりにするより、BicepやARMテンプレートなどのInfrastructure as Codeに含めておくほうが安全です。手動設定だけにすると、環境再作成時や別リージョン展開時にRecreateへ戻ったことに気づきにくくなります。
管理者が確認すべきポイント
管理者が最初に確認すべきなのは、「対象アプリがFlex Consumptionか」「対象リージョンで利用できる状態か」「組織のリリース手順がRollingUpdateに対応しているか」です。
Microsoft Learnでは、Rolling update strategyはEast Asia、West Central US、North Central US、West US 2で一般提供され、その他リージョンには数週間かけて展開中と説明されています。リージョン展開状況は変わる可能性があるため、本番適用前には必ず最新の公式ドキュメントと対象リソースの動作を確認してください。(Microsoft Learn)
| 確認項目 | 見るべきポイント | 見落とした場合のリスク |
|---|---|---|
| ホスティングプラン | Function AppがFlex Consumptionか | 対象外プランで設定できない、期待した動作にならない |
| リージョン | RollingUpdateが利用可能なリージョンか | 設定変更時の挙動が想定と異なる可能性 |
| Azure CLI/API | CLI 2.87.0以降、API 2023-12-01以降か | 自動化スクリプトが失敗する |
| IaC管理 | Bicep/ARMに設定が反映されているか | 再作成時に既定のRecreateへ戻る |
| 監視 | Application Insightsでログを追えるか | 更新完了の推定や障害分析が難しい |
| リリース手順 | デプロイ後に即座に次工程へ進んでもよい設計か | 更新途中に別変更を重ねて原因特定が難しくなる |
特に注意したいのは、RollingUpdateにはリアルタイムの進捗表示や明確な完了シグナルがない点です。Microsoft Learnでは、Application Insightsのログを使って進捗を推定するKQL例を示していますが、本番自動化で厳密な完了判定として依存すべきではないと説明されています。(Microsoft Learn)
開発者が確認すべきポイント
開発者側で最も重要なのは、後方互換性です。RollingUpdate中は、一定時間、新旧バージョンの関数が同時に動く可能性があります。そのため「デプロイが成功したら即座に全処理が新コードになる」という前提で設計していると、予期しない不具合が起きます。
DBスキーマ変更は段階的に行う
DBスキーマ変更を伴う場合は、次のような段階的リリースが安全です。
| ステップ | 内容 | 目的 |
|---|---|---|
| 事前変更 | 新旧コードの両方で扱えるカラムやテーブルを追加する | 旧コードを壊さない |
| 中間リリース | 旧形式も新形式も扱えるコードをデプロイする | 新旧混在期間を安全にする |
| 切り替え | 書き込み先や参照先を新形式へ移す | 機能変更を反映する |
| 後片付け | 旧カラムや旧処理を削除する | 不要な互換処理を整理する |
悪い例は、「カラム名を変更してから、新しいカラム名だけを参照するコードを同時に出す」パターンです。RollingUpdate中に旧コードが残っていると、旧コードが存在しないカラムを参照してエラーになる可能性があります。
外部API・メッセージ形式の互換性を保つ
Queue、Service Bus、Event Hubなどでメッセージを扱うFunction Appでは、メッセージ形式の互換性も重要です。
たとえば、次のような変更は注意が必要です。
- 必須フィールドを追加する
- 既存フィールド名を変更する
- 列挙値を変更する
- JSONの階層構造を変える
- 旧バージョンでは解釈できないメッセージを新バージョンが生成する
安全な進め方は、まず読み取り側を新旧両対応にし、その後に書き込み側を新形式へ移行することです。メッセージ駆動のシステムでは、デプロイ中だけでなく、キューに滞留している古いメッセージも考慮する必要があります。
Durable Functionsではバージョン戦略を確認する
Durable Functionsでは、オーケストレーションが長時間続くことがあります。RollingUpdate中に新旧バージョンが混在すると、オーケストレーションの履歴や関数定義の変更が想定外の動作につながる場合があります。
Microsoft Learnでも、Rolling update strategyの考慮事項として、Durable Functionsでは明示的なオーケストレーションのバージョン一致戦略を使うよう案内しています。(Microsoft Learn)
Durable Functionsを使っている場合は、RollingUpdateを有効化する前に次の点を確認してください。
- 実行中のオーケストレーションがある状態でデプロイしても問題ないか
- Activity関数のシグネチャや戻り値を破壊的に変更していないか
- 長期間動くオーケストレーションに旧コード前提の処理が残っていないか
- バージョン管理や移行用のオーケストレーションを用意しているか
Rolling updatesで失敗しやすいポイント
Rolling updatesは「無停止デプロイ」という言葉だけが先行しやすい機能です。しかし、運用設計を誤ると、停止はしなくてもエラー率が上がったり、原因特定が難しくなったりします。
単一インスタンスでは短時間停止が起きる可能性がある
RollingUpdateは複数インスタンスを段階的に入れ替えることで効果を発揮します。単一インスタンスで動作しているアプリでは、短時間の停止がRecreateに近い形で発生する可能性があります。ただし、実行中処理の完了を待つ点ではメリットがあります。(Microsoft Learn)
常時可用性を重視するHTTP APIでは、Always ready instancesやスケール設定、実際の負荷時のインスタンス数も合わせて確認しましょう。
パラメーターは利用者側で細かく制御できない
RollingUpdateのバッチ数、バッチ内のインスタンス数、ドレイン間隔などはプラットフォームが管理します。Microsoft Learnでは、これらのパラメーターはパフォーマンスと信頼性の最適化のため変更される可能性があると説明されています。(Microsoft Learn)
つまり、「必ず何分で完了する」「必ず何台ずつ入れ替わる」といった前提で運用手順を組むべきではありません。デプロイ後の確認は、時間固定ではなく、ログ・メトリック・エラー率・正常性チェックを組み合わせて判断するのが現実的です。
デプロイ完了の明確なシグナルがない
RollingUpdateには、すべての旧インスタンスが新インスタンスへ置き換わったことを示す組み込みの完了シグナルがありません。Application Insightsログを使って推定することはできますが、ログが出ていないインスタンスを検知できない場合があるため、厳密な自動判定には向きません。(Microsoft Learn)
CI/CDでは、次のような運用が安全です。
- デプロイコマンド成功だけで「完全切り替え完了」と扱わない
- デプロイ直後のエラー率、失敗実行数、依存サービスのエラーを確認する
- 重要な変更では、一定時間の監視ウィンドウを設ける
- 次の構成変更やDB変更をすぐ重ねない
- 異常時に前回正常バージョンを再デプロイできるようにする
ロールバック機能は別途用意されていない
Microsoft Learnでは、サイト更新をロールバックする専用機能は現在なく、必要な場合は以前のコードまたは構成を再度デプロイすると説明されています。(Microsoft Learn)
そのため、RollingUpdateを使う場合でも、次の準備は欠かせません。
- 前回正常バージョンの成果物を保持する
- IaCで前回設定へ戻せるようにする
- DB変更を戻せない場合は、アプリ側で互換処理を残す
- Feature Flagで新機能だけ無効化できる設計にする
- 依存先APIや接続文字列の変更履歴を追跡できるようにする
本番適用前のチェックリスト
Rolling updatesを本番環境に入れる前に、少なくとも次の項目を確認してください。
| チェック項目 | 確認内容 |
|---|---|
| プラン | 対象Function AppがFlex Consumptionである |
| リージョン | 対象リージョンでRollingUpdateが利用可能である |
| 設定 | siteUpdateStrategy.typeがRollingUpdateになっている |
| 互換性 | 新旧バージョンが一時的に同時稼働しても問題ない |
| DB変更 | スキーマ変更が後方互換性を保っている |
| メッセージ形式 | キューやイベントの新旧形式を処理できる |
| Durable Functions | オーケストレーションのバージョン戦略を確認している |
| 監視 | Application Insightsでログ・例外・依存関係を確認できる |
| ロールバック | 前回正常バージョンを再デプロイできる |
| CI/CD | 更新完了を厳密に待つ前提の処理になっていない |
| IaC | BicepやARMテンプレートに設定が反映されている |
特に初回は、いきなり重要な本番アプリで有効化するのではなく、開発環境や低リスクな本番ワークロードで挙動を確認するのがおすすめです。ログ上で旧インスタンスと新インスタンスがどの程度の時間混在するか、デプロイ直後にエラー率が変化しないかを観察してから、対象を広げると安全です。
移行・展開時の実務的な進め方
既存のFlex ConsumptionアプリにRollingUpdateを導入するなら、次の順序で進めると失敗しにくくなります。
まず現在の更新方式と停止影響を把握する
最初に、現在のデプロイ時にどの程度の影響が出ているかを確認します。
- デプロイ中のHTTP 5xxやタイムアウト
- Function実行の失敗数
- QueueやService Busの再試行回数
- デプロイ直後のコールドスタート影響
- ユーザーから見える停止時間
影響がほとんどなく、短時間停止も許容できる内部バッチであれば、RollingUpdateを急いで導入する必要はありません。逆に、デプロイのたびにエラー率が上がるAPIや、途中終了させたくない処理がある場合は優先度が高くなります。
次に互換性を確認する
RollingUpdate導入前に、アプリの変更パターンを見直します。
たとえば、次のようなルールをチームで決めておくと安全です。
- APIレスポンス項目の削除は段階的に行う
- DBカラム削除は、利用停止を確認してから別リリースで行う
- メッセージ形式変更時は、読み取り側を先に新旧両対応にする
- Feature Flagで新機能を段階的に有効化する
- 破壊的変更ではRollingUpdateではなくRecreateや計画停止も選択肢に入れる
RollingUpdateはプラットフォーム機能ですが、成功するかどうかはアプリケーション設計に大きく依存します。
最後に監視と復旧手順を整える
設定変更そのものは簡単です。しかし、本番運用では「問題が起きたときに何を見るか」「誰がどう戻すか」を先に決めておくことが重要です。
最低限、次の情報をすぐ確認できる状態にしておきましょう。
- デプロイ開始時刻
- デプロイした成果物のバージョン
- Application Insightsの例外ログ
- 依存サービスの失敗率
- Function実行数と失敗数
- HTTP APIのステータスコード別件数
- キューの滞留数や再試行数
- 前回正常バージョンへの再デプロイ手順
「デプロイが成功したのに一部ユーザーだけエラーになる」という状況では、新旧バージョン混在、設定値の不整合、依存先の互換性不足を疑うと切り分けが早くなります。
よくある疑問
Rolling updatesを有効にすれば完全に停止しなくなる？
完全な停止ゼロを保証するものではありません。複数インスタンスで稼働し、新旧バージョンの互換性が保たれ、スケールや依存サービスに問題がない場合に、停止を避けやすくする仕組みです。単一インスタンスの場合は短時間停止が起きる可能性があります。(Microsoft Learn)
デプロイスロットの代わりになる？
一部の用途では代替になりますが、同じものではありません。Rolling updatesは追加インフラなしで段階的な入れ替えを行えますが、別環境での事前検証、カナリアテスト、トラフィック割合の制御は提供しません。Microsoft Learnでも、これらが必要な場合はElastic Premiumなどデプロイスロットをサポートするプラン、またはTraffic Manager配下の複数Flex Consumptionアプリ構成を検討するよう説明されています。(Microsoft Learn)
設定変更だけでもRollingUpdateの対象になる？
はい。Flex Consumptionでは、コードのデプロイだけでなく、アプリケーション設定やその他構成プロパティの変更もサイト更新として扱われます。RollingUpdate設定時は、こうした構成変更でも段階的な入れ替えが発生する可能性があります。(Microsoft Learn)
すでに進行中のRollingUpdateがある状態で次の更新をしたらどうなる？
Microsoft Learnでは、RollingUpdate中に追加のRollingUpdateを開始でき、その場合は最新ではないインスタンスがドレインされ、最新バージョンのみがスケールアウトされると説明されています。(Microsoft Learn)
ただし、実務では短時間に複数の変更を重ねると、エラー発生時の原因特定が難しくなります。特にDB変更、アプリ設定変更、コード変更を別々に適用する場合は、順序と監視ポイントを明確にしておきましょう。
まず取るべきアクション
Azure FunctionsのFlex Consumptionを使っている管理者・開発者は、まず対象Function Appの更新戦略を確認しましょう。Recreateのままでも誤りではありませんが、デプロイ中の停止や実行中処理の中断が問題になっているなら、RollingUpdateへの切り替えを検討する価値があります。
一方で、RollingUpdateは「設定すればすべて安全」な機能ではありません。新旧バージョンが同時に動く前提で、DB、メッセージ、外部API、Durable Functions、CI/CD、監視、復旧手順を見直すことが重要です。
実務では、次の順に進めるのがおすすめです。
- 対象がFlex Consumptionか確認する
- 対象リージョンでRollingUpdateが利用可能か確認する
- 開発環境または低リスクなFunction Appで
RollingUpdateを有効化する - デプロイ中のログ、エラー率、旧インスタンスの残存状況を観察する
- 後方互換性とロールバック手順を整えてから本番適用する
Rolling updatesの一般提供により、Azure FunctionsのFlex Consumptionは本番ワークロードでさらに使いやすくなりました。特に、停止を避けたいAPIやイベント処理では有力な選択肢になります。まずは既存のデプロイ方式と失敗パターンを棚卸しし、RollingUpdateを使うべきアプリと、Recreateのままでよいアプリを分けるところから始めるとよいでしょう。
コメント