ストラングラーパターン：段階的なシステム移行

その概要とWebアプリケーションへの適用例

2019年に入ってから、ストラングラーパターンを用いたシステム移行例をいくつか目にしました。たとえば下記の記事は、Oisixのマイクロサービス化に関するものです。

Oisixが19年運用してきたモノリシックなサービスのマイクロサービス化を進め、Kubernetesを本番運用できる理由

モノリシックなシステムをマイクロサービス化するに当たって採用したアプローチは、「ストラングラーパターン」「マルチクラウド構成」「共有データベースの段階的な分離」だ。

本稿では、このストラングラーパターンについて、概要とWebアプリケーションへの適用例をご紹介します。

「ストラングラーパターン」とは？

「ストラングラーパターン」は、既存のシステムを段階的に新規システムに置き換えていく手法のことです。マーティン・ファウラーが2004年の記事「StranglerApplication」で名付けました。

「Strangler」は直訳すると「絞殺者」となります。ファウラーは旅行先の熱帯雨林で、つる植物（絞め殺しの木）が自身の寄生した木を絞め殺している様子を見ました。じわじわと成長して本体を乗っ取るさまから、段階的なシステム移行の比喩に使えるとひらめいたそうです。

前掲のOisixの記事では、下記のように紹介されています。

ストラングラーパターンとは、機能の特定の部分を新しいアプリケーションやサービスに徐々に置き換えることで、レガシーシステムを段階的に移行するもの。OisixのECサイトは24時間365日稼働しており、一度で全てをマイクロサービス化することは不可能だ。そこで、既存のECサイトを稼働させたまま、徐々にサービスとして切り出していった。

Webアプリケーションへの適用例

ストラングラーパターンをWebアプリケーションに適用するとすれば、下記の図が典型例となるでしょう。赤が既存システム、青が新規システムです。

https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/ より引用

最初はすべてのリクエストが既存システムに向いていますが、新規システム開発の進捗に応じて、リクエストを新規システムに振り分けていきます。図ではロードバランサで振り分けていますが、アプリケーションのフロントコントローラで振り分けたり、CDNで振り分けたりする方法も考えられます。

Webアプリケーションへの実際の適用例として、ランサーズとクックパッドの事例をご紹介します。

ランサーズの例

ランサーズでは、CakePHPのバージョンを1.3から2.8に上げる際に、ストラングラーパターンで進めたそうです。

CakePHP1.3→2.8移行が完了しました。 - ランサーズ（Lancers）エンジニアブログ

リクエストを1.3のフロントコントローラで受け、移行済みのURLへのリクエストならば、2.8のフロントコントローラに処理を委譲する方式です。フレームワークのバージョンアップのためにストラングラーパターンを用いるのは面白いと思いました。

クックパッドの例

クックパッドでは、大きなコードベースから携帯電話向けサービスを独立させるために、ストラングラーパターンを使っています。

マイクロサービス化を支える継続的切り替え術 - クックパッド開発者ブログ

具体的には下記のような方式です。ぼくには思いつきませんでした。

• Nginxでリクエストを受ける
• すべてのリクエストを、まずは新規サービスに流す
• 新規サービスは、移行前のアクションであれば503を返す
• 503のときだけ、Nginxから既存サービスへリクエストを再送する

レイテンシへの影響が気になりますが、許容範囲内だったそうです。

まとめと所感

以上、ストラングラーパターンの概要と、Webアプリケーションへの適用例をご紹介しました。名前が付いていると、コミュニケーションがはかどっていいですよね。

各社の事例について、とくに興味深く感じたのは、リクエストの振り分けがアプリケーション主体で実現されている点です。ロードバランサのルート定義を編集することなく、新規システムの実装とデプロイだけで済んでしまうのは魅力的です。

ぼくもシステム移行の機会があれば、こうした先行事例を参考に、旧システムの息の根をじわじわと止めていきたいと思っております。