段階導入なら安全とは限らない。新旧システムの境界から考える、一斉切替と段階移行の選び方

新システムを全社一斉に切り替えるのは怖い。そこで一拠点ずつ導入する。しかし、新旧の在庫情報が食い違い、受注は新システム、出荷は旧システム、訂正は手作業になる。小さく始めたはずなのに、境目で仕事が止まる。

この仮の場面が示すのは、段階導入が悪いということではない。分けられるのは利用者の人数でも、取引やデータまで分けられるとは限らないという問題だ。

本稿は、政府の移行指針と大規模サービスの運用知見を材料に、導入方式の判断を考える。業務として独立した単位を切り出せ、結果を観測して復旧できるなら段階導入を優先候補にする。分割で整合性が崩れるなら、境界を作り直すか、切り離せない単位をまとめて切り替える。 これは実務上の提案であり、すべての移行案件に共通する成功率の比較ではない。

少人数に配れば、影響も小さくなるのか

GoogleのSRE Workbookは、一部の対象へ先に新しい版を配るカナリアリリースを説明している。小さな範囲で不具合を発見し、全体への展開前に止める考え方だ。同時に、利用状況を代表する対象数や期間、負荷のかかる時間帯などの選び方を論じている。Google SRE「Canarying Releases」

ここでの中心はオンラインサービスのリリースである。利用者の一部に配る方法を、会計や物流の一斉移行へそのまま当てはめた比較研究ではない。小さい範囲への展開が利益を持つのは、その範囲から不具合の信号を得られ、影響の拡大を制御できるからだ。

例えば、ある拠点の画面だけを変えるなら利用者を分けやすい。一方、その拠点が書き換える商品情報を全社が使うなら、画面の利用者が少なくても影響は全社に届く。段階導入の単位は、ログインする人数より、更新される情報とその利用先から決める必要がある。

先行拠点が最も単純な業務だけを扱う場合も注意したい。そこで成功した事実は有用だが、返品や月末締めを扱う他拠点まで確認したことにはならない。先行範囲の小ささと、次の展開判断に必要な業務の代表性を両方考える。

Googleの同章も、先行群と比較対象が基盤を共有すると、不具合が比較対象へ波及し、評価を誤る可能性を指摘している。「先行群だけに問題が出なかった」ことと、「先行導入が全体に影響しなかった」ことは別に確かめる必要がある。Google SRE・対象群の分離に関する説明

新旧をつなぐ仕組みも、一つの製品として扱う

英国政府の移行ガイドは、既存システムをAPIなどで包み、利用側との接続を保ちながら段階的に置き換える方法を紹介している。また、新しい処理への問い合わせ結果を旧処理と比較する方法も挙げる。2016年公開の実務指針で、段階移行の優越を実験で証明した資料ではない。GOV.UK「Moving away from legacy systems」

接続を維持できれば、一度に変える範囲を小さくする選択肢が生まれる。ただし、その接続部分には、形式の変換、障害時の再送、重複の防止といった設計が必要になる。本稿では、この部分の作業も段階移行の費用として扱うことを提案する。

暫定の連携を「移行中だけ」と呼んでも、そこで受け付けた取引は本物だ。失敗したデータを誰が見つけ、どちらを正として直すかが曖昧なら、段階移行は不一致を蓄積する仕組みになり得る。

段階導入の計画書には、次の拠点をいつ始めるかだけでなく、新旧が共存している期間に何を監視し、何がそろえば旧系を止められるかを書く。並行運用を続ける人員や費用を確保できないなら、段階移行という名称だけで採用しない方がよい。

「元の版へ戻す」と「元の業務へ戻れる」は違う

AmazonのBuilders' Libraryは、新しい形式で書いたデータを旧版が読めない場合など、前進と後退の両方向で互換性を確かめる必要を説明している。新形式を読める準備と、新形式を書き始める変更を分ける二段階の方法も示す。ただし、すべての過去版へ戻れるわけではない。Amazon「Ensuring rollback safety during deployments」

この技術上の知見を業務移行へ広げる際の、本稿の提案は明確だ。新システムで注文や支払いが発生した後、その情報をどこへ戻すかを決めずに「バックアップがあるから戻せる」と言わない。

切替前のデータを復元できても、切替後に受け付けた取引が消えるなら、業務は元に戻っていない。必要なのは、それらを再処理する方法か、新しい状態を保って不具合を直す方法である。取引をいったん止めることと、正しい状態まで復旧することも別の作業だ。

復旧の演習では、起動できるかに加え、受付済みの取引が欠けず、二重実行もされないかを確認したい。復旧時間を測る場合も、サーバーの復元完了ではなく、利用者が必要な仕事を再開できる時点を明確にする。

拠点別に分ける案が、逆転する条件

仮に五つの営業拠点を持つ会社を考える。各拠点が専用の受注番号と在庫を持ち、受注から出荷までを拠点内で完結できるとする。新旧の集計結果を照合でき、先行拠点の取引を復旧する手順も試せるなら、一拠点から移行する案には合理性がある。他拠点へ広げる前に、現実の注文を使って問題を見つけられる。

条件を変え、在庫は全社共通で、各拠点の受注が同じ在庫を即座に引き当てる会社だったらどうか。新旧双方が別々の在庫を正として処理すると、同じ商品を二重に販売するおそれがある。人数や拠点数だけで切った段階導入は採りにくい。

この場合、在庫を管理する正本を一つに保ち、新旧の受注から同じ仕組みを利用できるようにする案がある。それが実現できないなら、受注と在庫の関連部分を一つの切替単位としてまとめる案を比較する。分割できないから全社の全機能を一斉変更する、という飛躍は不要だ。

まとめて切り替える案にも条件がある。移行データの照合、利用者の操作準備、業務停止中の受付、復旧または代替運用を試せることだ。それらが整わなければ、一斉切替が安全になるわけではない。方式を決める前に、対象範囲や日程を見直す必要がある。

日程表には、展開を止める判断も載せる

段階導入が予定どおり拡大するだけの工程になれば、先に試す意味は薄い。次の展開へ進める条件と、待つ条件を業務の言葉で書きたい。

この表は本稿の判断例だ。待機時間や許容件数を一律の数字で決めてはいない。業務が通常どの周期で動き、何を失うと回復が難しいかによって、必要な観測と許容範囲が変わるためである。

また、段階移行には長引くほど新旧双方を維持する費用がかかる。安全を理由に旧系の廃止条件を決めないまま続けると、暫定連携が恒久化する。対象機能を使う依存先が残っていないこと、必要な履歴を参照できることなど、廃止に必要な条件を移行開始時から決めておきたい。

方式選定で先に聞くべきなのは「一斉か段階か」ではなく、どの取引を一つの単位として切り替え、失敗したときにどこまで正しい状態へ戻せるかである。その単位を小さく保てるなら段階移行を使う。分割が整合性を壊すなら境界を設計し直し、切り離せない部分をまとめる。この判断が、慎重に見える日程と、実際に回復できる計画を分ける。