昨今では、サービス開発において「マイクロサービスアーキテクチャ」を採用することも珍しくなくなりました。 マイクロサービスアーキテクチャを採用する利点についてはもはや改めて語るまでもないですが、何となくマイクロサービスで始めてみたが後悔した、モノリスからマイクロサービスへ移行してみたがうまくいかなかった、という声が今でも聞こえてくることがあります。モノリスとマイクロサービスのどちらが向いているかについては、開発体制やサービスの特性など様々な要因を考慮する必要があるため、一概にどちらがよいかを断言することはできません。とは言え、基本的なマイクロサービスの設計パターンを理解しておくことができれば、このような落とし穴に嵌る可能性を小さくできるはずです。
マイクロサービスの設計パターンに関する書籍や Web サイトは様々なものがあり、昨今では情報を集めるのも容易になりました。 microservices.io は、 CloudFoundry.com の創設者でもある Chris Richardson がマイクロサービスのパターンをドキュメント化した、困ったときに最初に目を通すべきリファレンスと言えるでしょう。日本語の書籍としては、同じく Chris 氏が執筆した書籍である “Microservices Patterns: With Examples in Java” の邦訳として マイクロサービスパターン が出版されており、体系的に学びたい方におすすめです。
前置きが長くなりましたが、本連載では、マイクロサービスのための設計パターンについて簡単な概要を紹介していきます。初回である今回は、 Strangler Application (Strangler Fig Application) を取り上げたいと思います。不定期更新にはなりますが、他のパターンについても随時紹介していく予定です。
Strangler Application とは
Strangler Application パターンは、モノリシックなシステムを段階的に分解しリファクタリングする方法として知られています。このパターンの肝は、サービスの一部を切り出して段階的に Strangler Application という新たなアプリケーションへ置き換えることを何度も繰り返し、最終的にはモノリスが全て（場合によっては一部）なくなり新たなアプリケーションに完全に置き換わるということにあります。一定の期間は新旧両方の機能を併存した状態でルーティングによって安全に移行を進め、不要になったらモノリス側の旧機能を廃止していきます。
このアプローチのメリットとしては、主に以下の点が挙げられます。
- 既存システムの運用を止めることなく、新しい（既存の機能を置き換える）サービスの開発に専念できる
- ビッグバン的なアプローチと比較すると、遥かに短い時間で新しい価値の提供を実現できる
- 新旧機能の併存が可能なため、必要に応じて変更を簡単にロールバックでき、途中で方針を変更しやすい
- リリースサイクルが小さくなるため、移行の進捗が可視化されやすい
新旧サービスの併存を実現するための方式は様々なものが考えられますが、単一のステートレスな API であればリダイレクトするだけで完結するため、そう難しい話ではありません。実用的には、 API ゲートウェイやリバースプロキシを利用して、段階的にロールアウトしていくことになると思います。
一点留意しておくべき点としては、 Strangler Application が全てのシステム移行に対する銀の弾丸とはなりえないということが挙げられます。 Web サービスのような API ベースのシステムではない場合、機能として分解できる構造になかったり、新旧の機能を切り替えることがそもそも困難であったりする場合もあります。
そもそも Strangler Fig って？
ここまでの説明で何となくイメージを掴んでいただけたかと思いますが、そもそも “Strangler Fig” ってどういう意味なの？と思われた方もいらっしゃるでしょう。 Strangler Fig は訳すと「絞め殺しの木」という意味で、イチジクなどの種の俗称とされています。
「絞め殺し」という物騒な名前は、この種が宿主となった木を絞め殺しながら成長していくことに由来しています。宿主となる既存の木は最初は新しく生えてきた絞め殺しの木を支える構造になりますが、最終的には元の木が枯れて腐り、新しい絞め殺しの木だけが残ります。まさに、モノリスから少しずつマイクロサービスへ移行していく様子をうまく表現していると思います。
移行戦略
モノリスを分解するという作業は非常に大変かつ時間がかかるものであり、時間をかけて実施・検討する必要があります。また、モノリスに手をいれすぎないということも非常に重要です。マイクロサービスへの移行に際してはモノリス自体に手が入ることを避けられないケースもありますが、モノリスの変更が広範囲に及ぶと、それ自体がコストになるばかりか、移行時のリスクの高騰を招く恐れさえあります。
サービスの抽出順序については、移行によって得られるメリットが最も重視されるべきです。とは言え、最初からステートフルな API や依存関係が複雑な機能に手を付けようとすると、移行計画が頓挫してしまう可能性もあります。まずはステートレスな小さい API を切り出して移行を完了させ、開発チームのノウハウを蓄積していきながら、段階的に進めていくことが重要でしょう。
まとめ
本記事では、マイクロサービスの設計パターンの一つである、 Strangler Application について簡単に紹介しました。モノリスからマイクロサービスへの移行を考えているけど進め方に悩んでいる、という方への一つの指針となれば幸いです。
次回は、複数のマイクロサービスにまたがるデータの取得パターンとして知られる、 CQRS (Command Query Responsibility Segregation) や API Composition などのパターンを取り上げる予定です。
Masaaki Hirotsu
MLOps Div. 所属 / Kaggle Master
機械学習・データ分析基盤の構築に関わる事例や、クラウドを活用したアーキテクチャについて発信していきます。
