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

ストーリー

田

田中VPoE

段階的移行の中核となるのがストラングラーフィグパターンだ。Martin Fowlerが提唱したこのパターンは、レガシーシステムの周りに新しいシステムを成長させ、徐々に置き換えていく手法だ

あなた

Month 5のクラウド移行でも学びましたね。あの時はサービス単位での移行でしたが

あ

田

田中VPoE

今回はそれを組織全体の技術基盤に適用する。CI/CDパイプライン、監視基盤、セキュリティ基盤、データパイプライン — すべてをストラングラーフィグで段階的に刷新する

あなた

一つのサービスではなく、組織全体の基盤をストラングラーフィグで置き換えるんですね。規模が全然違います

あ

田

田中VPoE

だからこそ「基盤のストラングラーフィグ」には特有の設計が必要だ。ルーティング層、互換性レイヤー、段階的切り替え — 一つずつ見ていこう

ストラングラーフィグパターンの基本

パターンの本質

初期状態:
┌────────────────────────────┐
│      レガシー基盤           │
│  ┌──────┐ ┌──────┐        │
│  │機能A  │ │機能B  │ ...   │
│  └──────┘ └──────┘        │
└────────────────────────────┘

Phase 1: ファサード（前面）を設置
┌────────────────────────────┐
│      ルーティング層          │  ← 新規追加
├────────────────────────────┤
│      レガシー基盤           │  ← 既存
│  ┌──────┐ ┌──────┐        │
│  │機能A  │ │機能B  │ ...   │
│  └──────┘ └──────┘        │
└────────────────────────────┘

Phase 2: 新基盤で機能Aを実装
┌────────────────────────────┐
│      ルーティング層          │
├──────────┬─────────────────┤
│ 新基盤   │ レガシー基盤      │
│ ┌──────┐│ ┌──────┐        │
│ │機能A' ││ │機能B  │ ...   │
│ └──────┘│ └──────┘        │
└──────────┴─────────────────┘

Phase N: レガシーが消滅
┌────────────────────────────┐
│      ルーティング層          │
├────────────────────────────┤
│           新基盤             │
│  ┌──────┐ ┌──────┐        │
│  │機能A' │ │機能B' │ ...   │
│  └──────┘ └──────┘        │
└────────────────────────────┘

基盤レベルのストラングラーフィグ

CI/CD基盤のストラングラーフィグ

現状: Jenkins / GitHub Actions / Bitrise の混在

Phase 1: 抽象化レイヤーの導入
  ┌────────────────────────────────────┐
  │  CI/CD標準インターフェース           │
  │  (Reusable Workflow テンプレート)    │
  ├──────────┬──────────┬──────────────┤
  │ GitHub   │ Jenkins  │ Bitrise      │
  │ Actions  │ (既存)   │ (既存)       │
  └──────────┴──────────┴──────────────┘

Phase 2: チーム単位でGitHub Actionsに移行
  ┌────────────────────────────────────┐
  │  CI/CD標準インターフェース           │
  ├──────────────────────┬─────────────┤
  │ GitHub Actions       │ Jenkins     │
  │ (チームA,B,C移行済み) │ (チームD,E) │
  └──────────────────────┴─────────────┘

Phase 3: Jenkins/Bitrise廃止
  ┌────────────────────────────────────┐
  │  CI/CD標準インターフェース           │
  ├────────────────────────────────────┤
  │         GitHub Actions              │
  │         (全チーム統一)               │
  └────────────────────────────────────┘

監視基盤のストラングラーフィグ

現状: Datadog（一部）/ CloudWatch（一部）/ Zabbix（レガシー）

Phase 1: Datadogをプライマリに指定、全新規サービスはDatadog
Phase 2: CloudWatchメトリクスをDatadogに転送（互換レイヤー）
Phase 3: Zabbix監視対象をDatadogに順次移行
Phase 4: Zabbix/CloudWatch廃止、Datadog統一

データ基盤のストラングラーフィグ

現状: Salesforce / Elasticsearch / BigQuery に分散

Phase 1: データカタログでメタデータを統合管理（論理統合）
Phase 2: ETLパイプラインでBigQueryにデータを集約（物理統合開始）
Phase 3: リアルタイムストリーミング基盤を追加（Kafka導入）
Phase 4: 各サービスがKafka経由でデータ連携（データメッシュへ進化）

ストラングラーフィグの設計パターン

ルーティング層の設計

基盤	ルーティング層	切り替え方法
CI/CD	Reusable Workflow テンプレート	テンプレートの参照先を変更
監視	メトリクス転送エージェント	エージェント設定の変更
セキュリティ	API Gateway / Service Mesh	ルーティングルールの変更
データ	ETL/ELTパイプライン	パイプラインの入出力先変更
認証	OIDC Proxy / IdP Federation	IdPフェデレーション設定の変更

互換性レイヤーの設計

compatibility_layer:
  ci_cd:
    old_interface: "Jenkinsfile"
    new_interface: "GitHub Actions Workflow"
    bridge: "Jenkins→GitHub Actions変換スクリプト"
    validation: "旧Jenkinsfileと新Workflowの出力比較テスト"

  monitoring:
    old_interface: "Zabbixエージェント"
    new_interface: "Datadogエージェント"
    bridge: "Zabbix→Datadog メトリクスフォワーダー"
    validation: "アラート同等性テスト"

  data:
    old_interface: "直接DB接続"
    new_interface: "データカタログAPI"
    bridge: "ビューレイヤー（旧テーブル→新テーブルのマッピング）"
    validation: "クエリ結果の一致検証"

段階的切り替えの管理

カナリアリリースの基盤版

段階的トラフィック切り替え:

Week 1: 新基盤 5%  / 旧基盤 95%
  └── パイロットチーム1チームが新CI/CDを利用
  └── メトリクス比較: デプロイ成功率、ビルド時間

Week 2-3: 新基盤 20% / 旧基盤 80%
  └── 3チームが新CI/CDに移行
  └── フィードバック収集、テンプレート改善

Week 4-8: 新基盤 50% / 旧基盤 50%
  └── 主要チームが移行完了
  └── エッジケースの対応

Week 9-12: 新基盤 80% / 旧基盤 20%
  └── 残りチームの移行

Week 13+: 新基盤 100% / 旧基盤廃止
  └── 旧基盤のクリーンアップ

ロールバック戦略

シナリオ	ロールバック方法	所要時間
新パイプラインの障害	ルーティング層で旧パイプラインに切り戻し	数分
新監視基盤のデータ欠損	旧監視ツールを再有効化（並行期間中）	30分以内
新認証基盤の障害	IdPフェデレーションのフォールバック	15分以内
データ移行の不整合	スナップショットからのリストア	1-4時間

ストラングラーフィグのアンチパターン

アンチパターン	症状	対策
永遠の並行運用	旧システムが廃止されず、コスト倍増	廃止期限を事前に設定し、厳守する
互換性レイヤーの肥大化	ブリッジが複雑化し、メンテナンスコスト増大	互換性レイヤーは一時的。シンプルに保つ
部分移行の放置	80%移行したまま残り20%が永遠に残る	ラストマイル移行の専任担当を置く
テスト不足	旧→新の等価性が検証されていない	自動化されたリグレッションテストを整備

「ストラングラーフィグの最大の敵は『あとでやる』だ。80%まで移行して安心し、残り20%が3年放置される — これが現実によくある。移行プロジェクトのKPIには必ず『完了率100%の期限』を入れろ」 — 田中VPoE

まとめ

ポイント	内容
パターンの本質	ルーティング層を設置し、レガシーを段階的に新基盤に置き換える
基盤への適用	CI/CD、監視、データ、セキュリティの各基盤に適用可能
互換性レイヤー	旧→新の橋渡しを一時的に設置し、移行を円滑にする
カナリア方式	5% → 20% → 50% → 80% → 100% と段階的に切り替える
アンチパターン	永遠の並行運用、互換性レイヤーの肥大化、部分移行の放置

チェックリスト

ストラングラーフィグパターンの基本構造を理解した
CI/CD、監視、データ基盤への適用方法を把握した
ルーティング層と互換性レイヤーの設計ができる
カナリア方式の段階的切り替えを計画できる
アンチパターンと対策を理解した

次のステップへ

次は「フェーズドロールアウト計画」を学びます。ストラングラーフィグを組織全体に展開するための、3年間のフェーズ分け計画を策定しましょう。

推定読了時間: 30分