Strangler Figパターン入門｜モノリスからマイクロサービスへの段階的移行をクラウドで実現する実践ガイド

2026年6月17日

オンプレの既存システムをクラウドに移行するとき、「一気にマイクロサービスへ作り直す」計画を立てた経験はないでしょうか。実際には予算・工数・リスクの壁に阻まれ、計画倒れになるケースが後を絶ちません。

そこで現場のエンジニアが実際に採用しているのが「Strangler Figパターン」です。熱帯雨林に生えるイチジク科の植物（絞め殺しイチジク）が宿主の木を少しずつ包み込みながら最終的に置き換えるように、既存システムを動かしながら段階的に新システムへ切り替える設計手法です。

この記事では、Strangler Figパターンの仕組みと、AWSを使った具体的な実装例、移行時のポイントをオンプレ経験者向けに解説します。

なぜStrangler Figパターンが必要なのか？

モノリシックなシステムを「止めずにマイクロサービス化する」というのは、走行中の列車の車輪を交換するようなものです。それでも現実のビジネスは停止できません。

オンプレのシステムをそのままAWS移行（リフト＆シフト）した直後は、ある程度のクラウド恩恵を受けられます。しかし本来のクラウドネイティブの恩恵（独立デプロイ・個別スケーリング・障害の局所化）を得るには、最終的にはモノリスを分解する必要があります。

Strangler Figパターンが解決する課題は以下のとおりです。

・リスク分散: 全機能を一度に書き直すビッグバンリリースを避けられる
・継続稼働: 既存システムを止めずに移行できる
・段階的検証: 新しいマイクロサービスを本番トラフィックの一部で検証できる
・コスト平準化: 予算・チームのキャパシティに合わせてペースを調整できる

Strangler Figパターンの基本的な仕組み

このパターンの核心は「ファサード（玄関口）を設けて、そこへのリクエストをどちらへ流すかを制御する」点にあります。

1. ファサード層の設置

まずルーターとなるファサード層を既存システムの前面に置きます。外部からのリクエストはすべてここを経由し、今まで通りモノリスへ転送します。この時点でエンドユーザーへの影響はゼロです。

2. 新機能をマイクロサービスで実装する

モノリスに新機能を追加する代わりに、独立したマイクロサービスとして実装します。ファサード層で「この機能へのリクエストは新サービスへ」とルーティングを切り替えます。

3. 既存機能を段階的に移行する

機能単位で「モノリスのコードを削除し、マイクロサービスへ移行する」を繰り返します。最終的にモノリスが空になったとき、移行完了です。

フェーズ	モノリス	マイクロサービス	ファサードの動作
Phase 1（開始）	全機能	0機能	全リクエストをモノリスへ
Phase 2（移行中）	一部機能	一部機能	機能別にルーティング分岐
Phase 3（完了）	廃止	全機能	全リクエストをマイクロサービスへ

AWSでStrangler Figパターンを実装する構成例

AWSでは、ファサード層として以下のサービスが使われます。

1. Amazon API GatewayをHTTPルーターとして使う

Amazon API GatewayはHTTPリクエストをパスやメソッド単位でバックエンドへルーティングできます。モノリスへのリクエストをHTTP統合でオンプレや既存EC2へ流しつつ、移行済み機能だけAWS Lambda（または新しいマイクロサービスのエンドポイント）へ切り替える設定が可能です。

# Amazon API Gateway リソース設定イメージ（AWS CLI） # /legacy/* → 既存モノリス（EC2/オンプレ）へルーティング # /orders/* → 新しい注文マイクロサービス（Lambda）へルーティング # モノリスへのHTTP統合 aws apigateway put-integration \ --rest-api-id xxxxxxxx \ --resource-id yyyyyyyy \ --http-method ANY \ --type HTTP_PROXY \ --integration-http-method ANY \ --uri "http://legacy-app.internal/{proxy}" # 移行済み機能はLambda統合に切り替え aws apigateway put-integration \ --rest-api-id xxxxxxxx \ --resource-id zzzzzzzz \ --http-method ANY \ --type AWS_PROXY \ --integration-http-method POST \ --uri "arn:aws:apigateway:ap-northeast-1:lambda:path/2015-03-31/functions/arn:aws:lambda:ap-northeast-1:123456789012:function:OrderService/invocations"

2. Application Load Balancer（ALB）のパスベースルーティングを使う

ALBのリスナールールで「パスが /api/orders/* ならターゲットグループAへ、それ以外はターゲットグループB（モノリス）へ」と設定することも有効です。

この構成のメリットはシンプルさです。Amazon API Gatewayは認証・スロットリング・キャッシュなどAPIマネジメント機能が豊富ですが、単純なHTTPルーティングだけが目的ならALBの方が料金が安く、設定も直感的です。

・Amazon API Gateway: 認証・スロットリング・レートリミットが必要な場合に選択
・ALB: シンプルなHTTPルーティングのみで十分な場合に選択

3. Amazon CloudFrontのオリジン振り分け

フロントエンドを含むWebアプリケーションの場合、Amazon CloudFrontのオリジングループ機能を使う選択肢もあります。パスパターンによって、モノリスのオリジンと新しいマイクロサービスのオリジンを使い分けられます。CloudFrontを使う利点は、静的アセットのキャッシュと動的APIのルーティングを一元管理できる点です。

移行コストとリスクの現実

Strangler Figパターンは「安全に移行できる」と言われますが、注意点もあります。

【注意】データベースのStrangler化は別問題

アプリケーション層のStrangler Figは比較的実装しやすいですが、DBはそう簡単にいきません。モノリスが単一のRDBをすべての機能で共有している場合、マイクロサービスごとにDBを分離するためには追加の設計（イベントソーシング・データレプリケーション・二重書き込み）が必要です。

オンプレからAmazon RDSへの移行時に「とりあえず既存のスキーマをそのまま持ってきた」という状況が多いため、ここで詰まるケースが多いです。DB分離は専用のフェーズとして別プロジェクトで計画することを推奨します。

ファサード層自体が新たな障害点になる

Amazon API GatewayやALBはマネージドサービスのため高可用性が確保されていますが、ルーティングロジックの設定ミスがインシデントの原因になることがあります。移行作業中はフィーチャーフラグを使って、特定のパーセンテージのトラフィックだけ新サービスへ流す段階的切り替えを推奨します。

応用・実務Tips

移行進捗をCloudWatchで可視化する

どの機能がどのフェーズにあるかを追跡しないと、移行プロジェクトは形骸化します。Amazon CloudWatchでAPIのエンドポイント別リクエスト数を計測し、モノリスへの転送比率が減っているかをダッシュボード化する運用が現場では定着しています。


# CloudWatch メトリクスでALBのターゲットグループ別リクエスト数を確認（AWS CLI）
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB \
  --metric-name RequestCount \
  --dimensions Name=TargetGroup,Value=targetgroup/monolith-tg/xxxxxxxxxxxxxxxxxx \
  --start-time 2026-06-01T00:00:00Z \
  --end-time 2026-06-17T00:00:00Z \
  --period 86400 \
  --statistics Sum

移行単位は「機能ドメイン」で切る

「ユーザー管理」「注文処理」「在庫管理」のようにドメイン単位で移行の優先順位を決めると、依存関係の整理がしやすくなります。最初に移行するドメインは「他の機能との依存が少ない末端の機能」を選ぶのがセオリーです。依存関係が複雑な中心的ドメインは最後に移行します。

Linuxサーバーのプロセス管理やサービス起動の基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。クラウドのAmazon EC2上でアプリケーションを動かす際の参考にしてください。

よくあるトラブルと対処法

Q: 新旧システム間でセッション情報の不一致が起きた

モノリスと新マイクロサービスが別々にセッションを管理していると、ルーティングの切り替え時にユーザーがログアウトされるなどの問題が発生します。対処法は、セッション情報をAmazon ElastiCache（Redis）のような外部ストアに集約することです。どちらのサービスも同じElastiCacheを参照することで、セッションの一貫性を保てます。

Q: 移行後に新サービスのレスポンスタイムが遅くなった

ファサード層経由になったことでレイテンシが増加するケースがあります。Amazon API Gatewayのキャッシュ機能を有効化するか、CloudFrontを前段に置いてエッジキャッシュを活用することで改善できます。また、AWS Lambda関数はコールドスタートの影響を受けることがあるため、Provisioned Concurrencyの設定も検討してください。

Q: モノリスへのHTTPS転送時に証明書エラーが出る

ファサード（ALBやAmazon API Gateway）からバックエンドのモノリス（オンプレやEC2）への通信でHTTPS接続を試みた際に、自己署名証明書を使っている場合に発生します。ALBの場合はバックエンドへの通信をHTTPに変更するか、AWS Certificate Manager（ACM）で正式な証明書を設定してください。なお、ALBとバックエンドEC2が同じVPC内にある場合はHTTP転送でも十分にセキュアです。

本記事のまとめ

Strangler Figパターンは、リスクを抑えながらモノリスをマイクロサービスへ段階的に移行するための実践的な設計手法です。

・ファサード層の設置: Amazon API GatewayまたはALBをHTTPルーターとして使う
・段階的移行: 機能ドメイン単位で新旧を切り替える
・DB分離は別問題: アプリ層と合わせてデータ設計を計画する
・進捗可視化: Amazon CloudWatchでモノリスへの転送比率を監視する
・セッション外部化: Amazon ElastiCacheなどの共有セッションストアを活用する

やりたいこと	AWSサービス	オンプレ相当
HTTPルーティングのファサード	Amazon API Gateway / ALB	リバースプロキシ（nginx / HAProxy）
新機能のサーバーレス実装	AWS Lambda	アプリサーバー（Tomcat / Node.js等）
セッション外部ストア	Amazon ElastiCache（Redis）	セッション共有サーバー（Memcached等）
移行進捗の監視	Amazon CloudWatch	Zabbix / Prometheus
静的キャッシュ＋ルーティング一元化	Amazon CloudFront	Varnish / CDN（Akamai等）