モダナイゼーション ― コンテナ化、サーバーレス化、ストラングラーフィグパターン

導入

移行が終わっても、そこがゴールではありません。「移しただけ」のシステムは、オンプレ時代の制約（密結合・単一障害点・スケールしにくさ）をそのままクラウドに持ち込んでいます。ここからが、クラウドネイティブへの作り替え＝モダナイゼーションです。

説明

モダナイゼーションの代表的な方向性は、大きく2つです。

しかし、モノリシックな巨大アプリケーションを、ある日一斉に作り替えるのは非現実的でリスクが高すぎます。そこで使われるのが、ストラングラーフィグ（絞め殺しの木）パターンです。

flowchart LR
    U["利用者からのリクエスト"] --> R["ルーティング層<br/>（API Gateway等）"]
    R -->|"未移行の機能"| Mono["既存モノリス"]
    R -->|"移行済みの機能"| New["新マイクロサービス"]

これは、既存のモノリスの前にルーティング層（プロキシ）を配置し、機能ごとに少しずつ新しいマイクロサービスへリクエストを振り替えていく手法です。名前の由来である絞め殺しの木（strangler fig）が、宿主の木に巻きついて少しずつ成長し、最終的に宿主に取って代わるように、新システムが旧システムの機能を少しずつ「乗っ取って」いき、最後には旧モノリスが空っぽになって退役できます。一気に全部を作り替えるより、機能単位で検証しながら安全に移行できるのが最大の利点です。

モダナイゼーションの実務上の判断ポイントを整理します。

• 状態を持たない処理・イベント駆動な処理 → Lambda + Step Functions でサーバーレス化
• 既存のコンテナ資産・Kubernetesの知見がある → EKS（Kubernetes互換）を選び学習コストを抑える
• コンテナ運用のシンプルさを優先 → ECS（AWS独自だが構成がシンプル）
• サーバー管理そのものを無くしたい → コンテナ実行基盤に Fargate を選ぶ（EC2起動タイプではなく）
• 巨大なモノリスを段階的に切り出したい → ストラングラーフィグパターンで機能単位に移行

具体例

10年もののモノリシックなECアプリ（注文・在庫・会員・決済が1つの巨大コードに同居）を、クラウドネイティブへ作り替えます。

危険な案：全機能を一斉にマイクロサービスへ作り替え、ある日一括で切り替える（ビッグバン移行）。→ 検証しきれず、切替日に広範囲の障害。SAPではリスクが高すぎて基本的に不正解。

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

1. 既存モノリスの前にルーティング層（API Gateway等）を置く。最初は全リクエストを旧モノリスへ流す。
2. まず「会員」機能だけ新しいマイクロサービスに切り出し、ルーティング層で会員リクエストだけ新サービスへ振り替える。問題があれば旧へ戻すだけ。
3. 検証できたら「在庫」「注文」…と機能単位で少しずつ新サービスへ移していく。
4. 最後にモノリスが空になり、退役できる。

絞め殺しの木が宿主に巻きついて徐々に乗っ取るように、新システムが旧システムの機能を1つずつ奪っていきます。「段階的に」「リスクを抑えて」と来たら、この漸進的な移行を選ぶ視点を。モダナイゼーションは技術選定よりどう安全に移行の道筋を作るかが問われます。

読んでみよう

「一気に全部作り替える」という選択肢は、SAPではリスクが高すぎるため基本的に不正解になりがちです。「段階的に」「リスクを抑えながら」というキーワードを見たら、ストラングラーフィグパターンのような漸進的な移行を選ぶ視点を持ってください。モダナイゼーションは技術選定そのものより、どう安全に移行の道筋を作るかが問われる領域です。