モノリスからマイクロサービスへ

マイクロサービスアーキテクチャへの実践的な移行ガイド!
モノリシックなシステムのもつれを解きほぐして、マイクロサービスアーキテクチャへと移行するにはどうしたらよいか、またビジネスを続けながら各サービスをメンテナンスするにはどうするかなど、マイクロサービスアーキテクチャへの移行について解説する書籍です。マイクロサービスを選択した場合のトレードオフや変更コストなどマイクロサービスの特性を再確認し、モノリスの分割と変更の方法、機能を移行しながら振る舞いを変える方法などを学びます。

動いているモノリスを壊さずに、どうマイクロサービスへ移していくか。その問いに移行パターンの形で答える本が『モノリスからマイクロサービスへ』 (Sam Newman 著、島田浩二 訳、オライリー・ジャパン発行、オーム社発売、2020 年 12 月刊) です。原書は "Monolith to Microservices"、副題は「モノリスを進化させる実践移行ガイド」。版元は本書を、マイクロサービスが自分たちのシステムに適しているかを判断するところから、ビジネスを維持しながらモノリシックなシステムを少しずつマイクロサービスに切り替えていく方法、さらにマイクロサービスアーキテクチャが成長するにつれて起こる課題への対処の仕方までを、豊富な例やシナリオを用いて解説する実践的なガイドと紹介しています。マイクロサービスの「作り方」ではなく「既存システムからの移り方」に主題を絞っている点が、この本の性格を決めています。

全 6 章の構成、移行の計画からモノリスと DB の分割、成長の痛みへ

構成は全 6 章 (6 章は「終わりに」) に、付録 A「パターン一覧」と参考文献が付きます。1 章「必要十分なマイクロサービス」は、独立デプロイ可能性、ビジネスドメインに基づくモデル化、自分たちのデータを所有するというマイクロサービスの定義から入り、単一プロセスのモノリス、分散モノリス、サードパーティ製のブラックボックスシステムというモノリスの分類、結合と凝集、そして集約と境界づけられたコンテキストを扱う「必要十分なドメイン駆動設計」までを収めます。2 章「移行を計画する」は、マイクロサービスを選択する理由 (チームの自律性を高める、市場投入までの時間を減らす、堅牢性を改善するなど) と並べて「マイクロサービスが悪いアイデアのとき」 (不明瞭なドメイン、スタートアップ、顧客の環境にインストールして管理するソフトウェア、もっともな理由を持たないとき) を立て、組織を変革する手順、段階的に移行していくことの重要性、変更のコスト、どこから始めればよいか、イベントストーミングを含むドメイン駆動設計、チームを再編成する、うまくいっているかどうかを分かるには (定量的な測定、定性的な測定、サンクコストの錯誤を回避する) と、技術以前の判断に一章を使います。3 章「モノリスを分割する」と 4 章「データベースを分割する」が本書の中核で、5 章「成長の痛み」はサービスが増えたあとに現れる問題を、所有権のスケール、破壊的変更、レポーティング、監視とトラブルシューティング、開発者体験、エンドツーエンドテスト、全体最適と局所最適、堅牢性と回復性、孤児サービスなどの項目ごとに「この問題はどのようにして現れるか」「この問題はいつ発生するか」「取り得る解決策」の順で整理します。

ストラングラーパターンほか、3 章の移行パターンが要る理由

移行が難しいのは、モノリスの内部では機能同士が呼び出しとデータを共有して密に結合しており、ある機能だけを切り出そうとすると、呼び出し元、共有テーブル、デプロイ手順のすべてに手が及ぶからです。一度に作り直すビッグバン型の書き換えは、完成まで価値を生まないうえに、旧システムの振る舞いを漏れなく再現できる保証がありません。3 章はこの問題に対して「モノリスを変更すべきかどうか」 (切り貼りか再実装か、モノリスをリファクタリングする) から入り、移行パターンを一つずつ「使い方」と「使いどころ」の形で示します。中心となるのが ストラングラーパターン で、本書では「パターン: ストラングラーアプリケーション」として、HTTP リバースプロキシ、FTP、メッセージ傍受を例に、旧システムの手前に置いた層で呼び出しを少しずつ新しいサービスへ振り向けていく手順を扱います。続いて UI 合成 (ページ合成、ウィジェット合成、マイクロフロントエンド)、抽象化によるブランチ、同時実行 (新旧の実装を並走させて結果を突き合わせる方法で、スパイを使う、GitHub Scientist、ダークローンチとカナリアリリースの項を含む)、デコレーティングコラボレーター、変更データキャプチャ と並び、いずれも「機能を移行しながら振る舞いを変える」ための道具です。パターンごとに使いどころが明記されているため、自分のシステムの結合のしかたに合わせて選べます。

データベースを分割する 4 章、共有データベースからサーガまで

コードを分けてもデータベースが一つのままなら、サービスは独立してデプロイできず、スキーマ変更のたびに全サービスが足並みを揃えることになります。4 章はこのデータの難所に本書で最も多くの節を割いており、共有データベース、データベースビュー、データベースをラップするサービス、サービスのインターフェイスとしてのデータベースといった過渡期のパターンから、集約を公開するモノリスやデータ所有権の変更による所有権の移動、アプリケーションでのデータ同期 (データを一括で同期する、同期のために書き込み、古いスキーマから読み取る、同期のために書き込み、新しいスキーマから読み取る、の 3 ステップ)、トレーサー書き込み、テーブルの分割、外部キーのコードへの移動へと進みます。「データベースとコードのどちらを最初に分割するか」という実務で必ず突き当たる問いにも一節を使っています。章の終盤はトランザクションで、ACID トランザクションと 2 フェーズコミットを踏まえて「分散トランザクションにはノーと言う」と題し、代わりにサーガを、その障害モードと実装、分散トランザクションとの比較まで含めて扱います。複数のサービスにまたがる更新の一貫性をどう保つかは、マイクロサービスへ踏み出した現場が最初に痛む場所であり、この章だけでも本書を手に取る理由になります。

アーキテクトと開発リーダー向けの前提知識と、向かない読者

読者として想定されるのは、すでに動いているシステムの移行を判断し、実行する立場の人です。前提知識としては、Web アプリケーションの一般的な構成とリレーショナルデータベースの基本 (テーブル、外部キー、トランザクション) を知っていれば読めますが、ドメイン駆動設計 の集約と 境界づけられたコンテキスト は 1 章で「必要十分」な範囲が説明されるだけなので、初めて聞く人はそこで理解を固めてから進むほうが、2 章以降のサービス境界の議論を追いやすくなります。同じ著者の『マイクロサービスアーキテクチャ』 (佐藤直生 監訳、木下哲也 訳、オライリー・ジャパン、2016 年 2 月刊、第 2 版は 2022 年 12 月刊) は、版元の紹介文によればマイクロサービスとは何か、長所と短所、設計思想から、分割、デプロイ、テスト、監視、セキュリティといった個別の技術までを扱う本で、全体像を先に押さえたい人はそちらが入口になります。本書はその全体像を前提に、移行という一点に絞って深く掘る位置づけです。一方、マイクロサービスをゼロから設計する方法や、特定のフレームワークやクラウドサービスの操作手順を求める人には向きません。本書はコードよりも判断とパターンの本で、2 章のイベントストーミングやチームの再編成のように組織側の話にも紙面を割くため、移行の必要がない新規開発の読者や、技術選定に関わらず手順書だけが欲しい読者には遠回りに感じられるはずです。著者の Sam Newman は書店掲載の書誌 (出版社提供 / 刊行当時) で開発者、アーキテクト、執筆家、講演者と紹介され、刊行当時は独立してクラウド、継続的デリバリー、マイクロサービスに焦点を当てて働いていると記されています。訳者の島田浩二は同じ書誌によれば 2009 年に株式会社えにしテックを設立し、2011 年からは一般社団法人日本 Ruby の会の理事も務めています (刊行当時の情報)。

ビッグバンリライトを提案して却下された経験がある人、分割したいが共有データベースが足を引っ張っている人、すでに数個のサービスに分けたあとで監視やテストの痛みが出始めた人。こうした状況にある開発リーダーやアーキテクトなら、付録 A のパターン一覧を索引に該当する章から読み始めるだけで、チーム内の議論の言葉が揃い、次の一手を具体化しやすくなります。移行の是非を判断する材料 (2 章)、実行のための道具 (3 章と 4 章)、その後の運用の見通し (5 章) が 1 冊に収まっている点で、モノリスを抱える現場が最初に共有しておく価値のある本です。