技術移行の進め方: ストラングラーフィグパターン・段階的移行・Blue-Green・カナリアリリース

はじめに

技術移行は、プロダクトの成長やビジネス要件の変化に伴って避けて通れない課題です。しかし、移行の失敗はサービスの停止やデータの損失、ユーザーの離脱を招く危険性があります。本記事では、安全に技術移行を進めるためのパターンと判断基準を解説します。

身近な例えで理解する技術移行

技術移行は「走っている電車の車輪を交換する」ようなものです。

• Big Bang移行 = 電車を止めて一気に交換する。最も速いが、失敗したら全てが止まる
• 段階的移行 = 車輪を1つずつ交換する。時間はかかるが、失敗しても他の車輪で走り続けられる
• ストラングラーフィグ = 新しい電車を横に走らせて、乗客を少しずつ移す。旧電車は最後に廃止
• Blue-Green = 新旧2つの電車を用意して、一気に乗客を新電車に移す。問題があればすぐ戻せる
• カナリア = 新電車にまず少数の乗客だけ乗せてテスト。問題なければ全員を移す

移行パターンの全体像

比較表

パターン1: ストラングラーフィグパターン

概要

ストラングラーフィグ（絞め殺しのイチジク）は、Martin Fowlerが2004年に提唱した移行パターン。旧システムを稼働させたまま、新システムを徐々に構築し、機能を1つずつ新システムに移行する。

名前の由来は、熱帯のイチジクが宿主の木に巻きつき、徐々に宿主を覆い尽くし、最終的に宿主が枯れて新しい木だけが残る現象から。

仕組み

[Phase 1: 初期状態]

[ユーザー] --> [旧システム（モノリス）]

[Phase 2: ファサード導入 + 一部機能を新システムに]

[ユーザー] --> [ファサード/プロキシ]
                   |
                   +-- /users/* --> [旧システム]
                   +-- /products/* --> [旧システム]
                   +-- /search --> [新システム] ← 最初の移行対象
                   +-- /notifications --> [新システム]

[Phase 3: 機能を段階的に移行]

[ユーザー] --> [ファサード/プロキシ]
                   |
                   +-- /users/* --> [新システム] ← 移行完了
                   +-- /products/* --> [新システム] ← 移行完了
                   +-- /search --> [新システム]
                   +-- /notifications --> [新システム]
                   +-- /orders/* --> [旧システム] ← まだ移行中

[Phase 4: 移行完了]

[ユーザー] --> [新システム]
              [旧システム: 廃止]

実装のポイント

移行順序の判断基準

メリット・デメリット

パターン2: Blue-Green デプロイメント

概要

本番環境を2つ（Blue/Green）用意し、一方で新バージョンを準備、もう一方で旧バージョンを運用する。切り替えはDNSやロードバランサーで瞬時に行う。

仕組み

[Phase 1: 初期状態 (Blue が本番)]

[ユーザー] --> [ロードバランサー] --> [Blue環境 (v1.0)]
                                      [Green環境 (待機)]

[Phase 2: Greenに新バージョンをデプロイ]

[ユーザー] --> [ロードバランサー] --> [Blue環境 (v1.0)] ← 本番
                                      [Green環境 (v2.0)] ← テスト中

[Phase 3: トラフィックを切り替え]

[ユーザー] --> [ロードバランサー] --> [Blue環境 (v1.0)] ← 待機（ロールバック用）
                                      [Green環境 (v2.0)] ← 本番

[Phase 4: 問題なければBlueを更新または削除]

AWSでの実装

データベースの移行

Blue-Greenの最大の課題はデータベース。

後方互換性のあるスキーマ変更

[NG: 後方互換性がない変更]
ALTER TABLE users RENAME COLUMN name TO full_name;
→ 旧バージョンが動かなくなる

[OK: 後方互換性のある変更（3ステップ）]

Step 1: 新カラムを追加（旧バージョンも動く）
ALTER TABLE users ADD COLUMN full_name VARCHAR(255);

Step 2: 新バージョンをデプロイ（両カラムに書き込み）
INSERT INTO users (name, full_name) VALUES ('田中', '田中');

Step 3: 旧カラムを削除（旧バージョンを完全に廃止後）
ALTER TABLE users DROP COLUMN name;

メリット・デメリット

パターン3: カナリアリリース

概要

新バージョンを少数のユーザーにのみ公開し、問題がないことを確認してから段階的に全ユーザーに展開する方式。「カナリア」の名前は、炭鉱でカナリアを使って有毒ガスを検知した慣習に由来する。

仕組み

[Phase 1: カナリア開始 (5%)]

[ユーザー] --> [ロードバランサー]
                   |
                   +-- 95% --> [旧バージョン (v1.0)] (10台)
                   |
                   +-- 5% --> [新バージョン (v2.0)] (1台)

[Phase 2: 問題なし → 拡大 (25%)]

[ユーザー] --> [ロードバランサー]
                   |
                   +-- 75% --> [旧バージョン (v1.0)] (8台)
                   |
                   +-- 25% --> [新バージョン (v2.0)] (3台)

[Phase 3: 問題なし → さらに拡大 (50%)]

[ユーザー] --> [ロードバランサー]
                   |
                   +-- 50% --> [旧バージョン (v1.0)] (5台)
                   |
                   +-- 50% --> [新バージョン (v2.0)] (5台)

[Phase 4: 完全移行 (100%)]

[ユーザー] --> [ロードバランサー]
                   |
                   +-- 100% --> [新バージョン (v2.0)] (10台)

カナリアの判断基準

AWSでの実装

[ECS + CodeDeploy カナリアデプロイ]

CodeDeploy の設定:
- デプロイメントタイプ: Blue/Green (カナリア)
- トラフィック設定:
  - Linear10PercentEvery1Minutes
    (1分ごとに10%ずつ新バージョンに移行)
  - Canary10Percent5Minutes
    (最初に10%を5分間テスト、問題なければ残り90%を一気に移行)

自動ロールバックトリガー:
- CloudWatchアラーム（エラー率 > 5%）
- ヘルスチェック失敗

メリット・デメリット

パターン4: 段階的移行（Feature Flag + A/B テスト）

概要

Feature Flag（機能フラグ）を使って、同一バージョンのアプリケーション内で新旧の機能を切り替える方式。

仕組み

[同一アプリケーション内での切り替え]

function getTimeline(userId) {
  if (featureFlag.isEnabled('new-timeline', userId)) {
    // 新しいタイムラインアルゴリズム
    return newTimelineService.get(userId);
  } else {
    // 旧タイムラインアルゴリズム
    return oldTimelineService.get(userId);
  }
}

Feature Flagツール

Feature Flagの活用パターン

データベース移行の実践

DBマイグレーションの安全な進め方

[安全なDB移行の手順]

Phase 1: 準備（ダウンタイムなし）
├── 新カラム/テーブルを追加（既存に影響なし）
├── アプリを更新（新旧両方に書き込み）
└── データ同期ジョブで既存データを移行

Phase 2: 切り替え（ダウンタイムなし）
├── アプリの読み取りを新カラム/テーブルに変更
├── 旧カラム/テーブルへの書き込みを停止
└── 動作確認

Phase 3: クリーンアップ（ダウンタイムなし）
├── 旧カラム/テーブルを削除
└── マイグレーションジョブを削除

大規模データ移行のパターン

移行判断のチェックリスト

移行を開始する前のチェック

移行中のチェック

移行後のチェック

移行パターンの選び方

[移行パターン選定フロー]
    |
    v
[移行対象は?]
    |
    +-- インフラ（サーバー、DB等）
    |   |
    |   +-- [ダウンタイムが許容できる?]
    |       |
    |       +-- はい --> Big Bang or Blue-Green
    |       |
    |       +-- いいえ --> Blue-Green or ストラングラーフィグ
    |
    +-- アプリケーション（言語、FW変更）
    |   |
    |   +-- [段階的に移行できる?]
    |       |
    |       +-- はい --> ストラングラーフィグ
    |       |
    |       +-- いいえ --> Blue-Green + 十分なテスト
    |
    +-- 機能リリース（新機能の展開）
        |
        +-- [リスクが高い変更?]
            |
            +-- はい --> カナリアリリース + Feature Flag
            |
            +-- いいえ --> ローリングアップデート

実際の企業での移行事例

Amazon: モノリスからマイクロサービスへ

Stripe: Ruby→Go への段階的移行

GitHub: MySQL→Vitess への移行

Shadow Traffic パターン

概要

本番トラフィックのコピーを新システムに送り、結果を比較する方法。実際のユーザーには影響を与えずに、新システムの正確性とパフォーマンスを検証できる。

[ユーザー] --> [プロキシ]
                  |
                  +-- [旧システム] --> [レスポンスをユーザーに返す]
                  |
                  +-- [新システム] --> [レスポンスを比較のみ（返さない）]
                                         |
                                    [結果を比較/記録]
                                    - レスポンスの一致率
                                    - レスポンスタイム
                                    - エラー率

Shadow Trafficのメリット

まとめ

各パターンの使い分け

移行の鉄則

技術移行は「いかに安全に進めるか」が最も重要。新技術への期待よりも、既存ユーザーへの影響を最小限にすることを常に最優先に考えるべきである。

参考リンク

• Martin Fowler: StranglerFigApplication
• Martin Fowler: BlueGreenDeployment
• Martin Fowler: CanaryRelease
• Martin Fowler: FeatureToggle
• AWS Blue/Green Deployments
• GitHub Engineering Blog