ストラングラーパターン（Strangler Pattern）とは？
モノリシックシステムを一度にマイクロサービスへ移行するのではなく、段階的に新しいサービスを導入しながら既存システムを徐々に置き換えていく手法です。
この名称は、締め殺し植物（strangler fig）が既存の木を覆い尽くしながら枯らしていく様子から由来したそうです！
ストラングラーパターンの主要な要素
-
APIゲートウェイ（API Gateway）
- 既存のモノリシックシステムのエンドポイントを変更せずに、新しいマイクロサービスへトラフィックをルーティングする役割を持ちます。
- どのリクエストを既存システムと新システムのどちらに送るかを決定します。
- トラフィックが徐々に新しいサービスへ移行できるよう制御します。
-
統合グルー（Integration Glue）
- 既存システムと新しいマイクロサービス間でデータの同期、変換、メッセージブローカーの管理を行う中間層の役割を果たします。
- 例えば、既存データベースとマイクロサービスのデータベースが分かれている場合、CDC（Change Data Capture）やイベント駆動アーキテクチャ（Kafka、RabbitMQなど）を活用してデータを同期します。
- モノリシックサービスとマイクロサービスが共存する間、データの一貫性を保つ上で重要な役割を担います。
モノリシックシステムを完全に削除する基準
モノリシックシステムを完全に削除できる主要な基準の一つが、「データ同期率（Data Sync Rate）= 0」 です。
データ同期率とは？
- マイクロサービスへ移行した後も、既存のモノリシックシステムと新しいマイクロサービスがデータを共有しなければならない場合があります。
- そのため、CDCやイベントソーシングなどの手法を用いてデータを同期しますが、
「モノリシックシステムから新システムへのデータ同期がゼロになった」 ということは、既存システムのデータが不要になったことを意味します。 - つまり、モノリシックDBからマイクロサービスDBへのデータ移行が完了し、既存システムが一切使用されなくなった状態 です。
完全な削除のその他の基準
-
トラフィックが100%マイクロサービスへ移行した
- APIゲートウェイを通じて既存システムへのリクエストが完全になくなる。
-
既存システムのすべてのビジネスロジックがマイクロサービスへ移行した
- モノリシックの一部モジュールが残っている場合、完全な移行とは言えない。
-
マイクロサービスが完全に独立している
- データと機能が完全に分離され、モノリシックシステムを停止しても問題が発生しない状態。
まとめ
ストラングラーパターンは 既存システムを段階的にマイクロサービスへ移行する手法であり、APIゲートウェイと統合グルーを活用してトラフィックを制御し、データの一貫性を維持します。
モノリシックシステムを完全に削除する基準は データ同期が不要になった（Data Sync Rate = 0）、既存システムへのトラフィックがゼロになった、すべての機能がマイクロサービスへ移行した場合です！