PR：この記事にはアフィリエイトリンクが含まれます。
マイクロサービス 本で検索すると、設計や導入事例を扱う本がたくさん見つかります。けれど、モノリスの段階移行では、稼働中の仕組みをどう切り替えるかも大きな課題です。
そこで役立つのが、古い仕組みを動かしながら新しいサービスへ機能を移すStrangler Figパターン。一度に作り直さず、小さく置き換えていく方法ですね。
移行計画から設計、実装例、トレードオフ分析まで扱う4冊を紹介します。まずは早見表で各書籍の範囲を見てみましょう。
4冊の早見表
| 書籍 | 主な焦点 | 参考価格（税込） |
|---|---|---|
 モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド | 導入判断、段階移行、チームと進捗 | 3,520円 |
 マイクロサービスアーキテクチャ 第2版 | 境界設計、移行、実装・運用 | 4,840円 |
 マイクロサービスパターン 実践的システムデザインのためのコード解説 | 分割、通信、データ、テストの実例 | 5,280円 |
 ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析 | サービス粒度やデータ所有権の判断 | 4,180円 |
価格は税込の参考価格で、公式の希望小売価格・定価です。実売価格は時期や販売店によって変わるため、購入時には店頭や通販サイトで確認してください。
まず目的を決める
マイクロサービス化は、分割しただけで成功とはいえません。リリースを独立させたいのか、変更頻度の高い領域を切り離したいのか、チームの担当範囲を明確にしたいのか。目的を言葉にすれば、移行する領域も絞りやすくなります。
たとえば、一つの画面を直すたびに全体の回帰テストと一括リリースが必要なら、変更の影響範囲を狭める価値がありそうです。一方、デプロイや運用の仕組みが未整備なら、サービスを増やす前にそちらを整えるほうが近道でしょう。
モノリスには、単一プロセス内で処理でき、開発やデプロイの構成も比較的シンプルという利点があります。システムが安定し、変更頻度も低いなら、通信や監視の負担を増やしてまで分割する必要は薄いですね。
移行計画では、今の困りごとと移行後に減らしたい負担を並べます。「新しい技術を使う」だけでは目標が曖昧です。「この領域を別々にリリースできるようにする」と定めれば、成果を確かめる指標も見えてきます。
Strangler Figの流れ
Strangler Figでは、利用者のリクエストを受ける入口で、旧モノリスと新サービスのどちらへ処理を送るか振り分けます。最初は大半を旧側へ送り、移行できた機能から新側に切り替えます。
最初の対象には、業務上の意味が明確で、ほかの領域への依存が少ない機能が向いています。たとえば参照中心の履歴表示は、注文確定や決済のように複数の状態を同時に更新する処理より、切り出しやすい場合があります。
新旧の処理を並行して動かす期間は、どちらの結果を正とするか決めておきましょう。結果を照合する場合も、メール送信や課金などの副作用が二重に発生しない仕組みが必要です。ここは慎重に扱います。
移行できたら、対象リクエストを新側へ少しずつ振り分けます。問題が起きたときに旧側へ戻せる経路と、切り戻しの判断条件も用意しておくこと。小分けの移行を安全に進めるための要点です。
境界を小さく切る
サービスの境界はコードのフォルダー構成だけで決めると危険です。商品、注文、顧客といった業務のまとまりを調べ、誰がどの情報を変えるのか、変更理由がどこで重なるのかを見ていきます。
注文サービスを作っても、在庫数や配送状態の変更を毎回ほかのサービスに頼むなら、独立性は限られます。業務ルールとデータの所有範囲をそろえ、内部の変更が外へ漏れにくい境界を目指しましょう。
境界づけられたコンテキストは、同じ言葉でも領域ごとに意味が異なることを捉える手がかりになります。顧客情報が請求先と配送先で別なら、巨大な顧客モデルを全サービスで共有する設計は見直しどころです。
最初から理想の分割図を描き切る必要はありません。依存関係を調べ、一つずつ切り出して変更のしやすさや運用負荷を確かめる。境界を仮説として置き、実際の変更で検証していきます。
データを分ける
モノリス分割で手ごわいのは、アプリケーションのコードよりデータです。複数の機能が一つのデータベースを直接読み書きしていると、アプリを分けてもスキーマ変更や障害の影響は残ります。
移行先のサービスがデータを所有し、ほかのサービスは決められたAPIやイベントを通じて利用する。これが基本の形です。ただし所有権を移すには、読み書きの経路を洗い出し、移行期間と整合性の扱いを決めなくてはなりません。
旧システムと新システムの両方へ同時に書き込む方式では、片方だけ成功したときにデータがずれるおそれがあります。再試行や重複処理への対策に加え、照合・修復の仕組みまで考えないと、食い違いが移行後も積み上がります。
移行中は旧側を正とする期間を設ける、変更をイベントで伝える、読み取り先を段階的に変えるなど、手順を分けてみましょう。すべての表を一気に分けず、対象業務のデータから責任範囲を狭めるのが現実的です。
切替と検証
切替には機能トグルが役立ちます。利用者やリクエストの条件に合わせて旧処理と新処理を選べるので、限定公開や切り戻しがしやすくなります。ただし、役目を終えたトグルは整理しましょう。残し続けると条件分岐が増えていきます。
並列実行は、新旧の処理結果を比べるときに便利です。新側の結果を利用者に返さず旧側と照合すれば、挙動の差を見つけられます。決済や通知のように二重実行できない機能では、副作用を抑える設計が欠かせません。
検証では成功率や応答時間だけでなく、業務上の結果も確かめましょう。注文件数や集計値など対象に合った指標を選べば、システムが動いていても業務データがずれる問題に気づきやすくなります。
切替前に、戻す条件や担当者、確認するログ・メトリクスを決めておきます。小さな範囲から対象を広げ、異常があれば止める。短い単位で進めるほど原因を追いやすくなります。
チームと進捗
サービスを分ければ、開発チームの仕事も変わります。担当を分けてもリリースや障害対応、データ変更の連携が複雑なら、チーム間の待ち時間は増えかねません。組織の役割とサービスの境界は一緒に考えたいですね。
進捗を作ったサービスの数だけで測るのは不十分です。独立してリリースできる機能が増えたか、変更の影響範囲が狭まったか、不具合や復旧時間はどう変わったか。移行の目的に沿った指標が判断を支えます。
運用の責任が曖昧なままでは、サービスの数だけ監視や障害対応も増えてしまいます。各サービスの担当チームとアラート対応を定め、依存先の変更を共有する方法も整えて、日々の運用を計画に含めましょう。
区切りごとに技術面と業務面の両方を見直すことも大切です。期待した独立性が得られないなら、境界を直すか移行を中断する判断も必要。現場では止められる計画のほうが動かしやすいものです。
4冊の読みどころ
『モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド』は、導入判断から移行計画、Strangler Figや並列実行、チーム再編までをつなげて学びたい人におすすめです。276頁で段階移行の全体像をつかめます。
『マイクロサービスアーキテクチャ 第2版』は、サービス境界やデプロイ、テスト、監視、組織との連携まで幅広く扱います。664頁あり、段階移行から導入後の運用まで参照したい開発者や導入検討中の組織におすすめです。
『マイクロサービスパターン 実践的システムデザインのためのコード解説』では、フードサービスのサンプルを使い、サービス分割、通信、データ、テスト、デプロイのパターンを追えます。実装に近い具体例から設計を学びたい人におすすめです。
『ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析』は、サービスの粒度やデータ所有権など、答えが一つに定まらない課題を検討する本です。判断の根拠を記録しながら境界を決めたいアーキテクトにも役立ちます。
結論
段階移行の全体像をまず押さえたいなら、『モノリスからマイクロサービスへ』が堅実な一冊です。稼働中のモノリスを保ちながら進める方法や移行の測り方を、計画・組織の視点も交えて学べます。
導入後の設計や運用まで参照するなら『マイクロサービスアーキテクチャ 第2版』。実装パターンを例で追いたい人には『マイクロサービスパターン』がおすすめです。境界や粒度に悩むアーキテクトには、『ソフトウェアアーキテクチャ・ハードパーツ』がトレードオフの整理に役立ちます。
Strangler Figの実践では、小さく切り出し、結果を確かめ、問題があれば戻せることが肝心です。自社の課題に合う本を一冊選び、移行対象の境界と成功指標を言葉にするところから始めてください。
Amazon の PC をスコア化してみた
Amazonにある8〜14インチの小型WindowsタブレットやノートPCを、スペック別にスコア化して比較・ランキング。
