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

導入

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

説明

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

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

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

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

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

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

読んでみよう

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