Microsoftは、Azure Logic Appsの統合アカウント機能を裏側で支える約6万本のAzure Functionsアプリケーションを、廃止予定のv1/v2ランタイムから最新のv4分離ワーカーモデルへ、顧客に気づかれることなく移行させた。かかった期間は2年、鍵になったのは「シャドウトラフィック」と呼ばれる検証手法だ。

6万本のFunctionsが支える「見えない基盤」

Logic Appsの統合アカウントは、EDI（電子データ交換）やAS2、X12、XML検証といったB2B連携処理を担う機能で、日本企業でも金融・製造業のシステム間連携で使われている。この処理エンジンの実体はAzure Functionsであり、顧客ごとに個別のFunctionsアプリが動いている。その数が約6万本という規模になる。

問題は、Functionsのv1/v2ランタイムがサポート終了に向かう一方で、6万本すべてを一斉に止めて入れ替えるわけにはいかないことだ。原文タイトルの「飛行中に飛行機のエンジンを交換する」という比喩どおり、サービスを止めずにランタイムそのものを差し替える必要があった。

「シャドウトラフィック」という検証手法

Microsoftが採ったのは、実際に流れてくる本番トラフィックを複製し、旧ランタイム（v1/v2）と新ランタイム（v4分離ワーカー）の両方に並行して流し込むというアプローチだ。旧ランタイムの応答を正としてユーザーに返しつつ、裏では新ランタイムにも同じリクエストを処理させ、両者の出力を突き合わせて差分を検出する。挙動が完全に一致することを確認できたアプリから順に、実際のトラフィックの向き先を新ランタイムへ切り替えていく。カナリアリリースやブルーグリーンデプロイの発想を、6万本という規模とサービス個別の複雑な業務ロジックに合わせて徹底した形と言える。

実務への影響

この手法自体は目新しい発明ではないが、「新旧の挙動が一致することを、推測ではなく実トラフィックで機械的に証明してから切り替える」という規律を、これだけの規模で最後までやり切った点に価値がある。日本企業がAzure Functionsのv1/v2ランタイム廃止に直面している場合、まず自社アプリの現行ランタイムを確認し、移行の猶予期間内に計画的に対応すべきだ。急ぐ必要はないが、放置は禁物である。

また、ランタイムのメジャーバージョン更新やAPI契約変更、データベースエンジンの入れ替えなど、自社システムで「止められないが変えなければならない」場面に直面するエンジニアにとって、シャドウトラフィックによる並行検証は再現性の高い王道パターンとして参考になる。フィーチャーフラグや段階的ロールアウトと組み合わせれば、大規模な基盤更新でも顧客影響をほぼゼロに抑えられることを、Microsoft自身が6万本規模で実証した意義は大きい。

筆者の見解

派手なAI関連の発表が続く裏で、Azureの中核インフラがこれだけ地道な規律を持って更新されているという事実は、素直に評価したい。奇をてらわず、実トラフィックでの検証を積み重ねてから切り替えるという「道のド真ん中」を歩くやり方は、まさにエンタープライズ基盤に求められる姿勢だ。

禁止や強制切り替えではなく、顧客が気づかないうちに安全な状態へ移行させる設計思想も好ましい。ユーザーに我慢や作業を強いず、気づいたら最新かつ安全な状態になっている——これは業務システムの運用で本来目指すべき理想形であり、Azure基盤チームの仕事としては十分に信頼できる水準だと感じる。派手さはないが、こういう仕事の積み重ねこそがAzureというプラットフォームへの信頼を支えている。

出典: この記事は Changing the Engine While the Plane Is Flying: Migrating 60,000 Apps Under Live Load の内容をもとに、筆者の見解を加えて独自に執筆したものです。