『モノリスからマイクロサービスへ―モノリスを進化させる実践移行ガイド』

翻訳を担当した書籍『モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド』（オライリー・ジャパン）が12月26日に発売になります。本書は2019年11月にO'Reilly Mediaより出版されたSam Newman著『Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith』の全訳で、マイクロサービスアーキテクチャを解説した書籍として日本でも定評のある『マイクロサービスアーキテクチャ』（原題『Building Microservices』）の著者であるSam Newmanによるマイクロサービスを取り上げた2冊目の書籍となります。

O'Reilly Japan - モノリスからマイクロサービスへ

本書は、モノリスからマイクロサービスアーキテクチャへと移行するための実践的なガイドです。マイクロサービスが自分たちのシステムに適しているかを判断するところから、ビジネスを維持しながらモノリシックなシステムを少しずつマイクロサービスに切り替えていく方法、さらには、マイクロサービスアーキテクチャが成長するにつれて起こる課題への対処の仕方まで、豊富な例やシナリオを用いて解説します。また、モノリスやデータベースを分解していくのに役立つ様々なパターンやテクニックも扱います。

身も蓋もないタイトルが示す通り、本書は「モノリスからマイクロサービスへ」の移行ガイドです。

移行の計画、マイクロサービスのモデリングの仕方、既存のアーキテクチャをマイクロサービスに移行する際に使える実績あるパターンやテクニックーーー本書は、モノリシックなシステムを持つ組織がマイクロサービスアーキテクチャを導入するにあたっての検討材料を幅広く提供する実用書となっています。

ですが、本書は「今すぐにモノリスを止めて、マイクロサービスへ行こう」と無邪気にマイクロサービスを啓蒙する書籍というわけではありません。現実に立脚し、いかにマイクロサービスアーキテクチャが難しく、困難を伴うかを教えてくれ、そして、不必要にマイクロサービスへと飛び込まないことを私たちに強く促します。

それでもマイクロサービスアーキテクチャが自分たちにとって良い選択肢だと思えるときーー本書は、そうした場合にどうやってそこに向かっていくかを、その困難さとともに教えてくれる一冊となっています。

はじめに
1章　必要十分なマイクロサービス
1.1　マイクロサービスとは
1.1.1　独立デプロイ可能性
1.1.2　ビジネスドメインに基づくモデル化
1.1.3　自分たちのデータを所有する
1.1.4　マイクロサービスがもたらす利点
1.1.5　マイクロサービスが作り出す問題
1.1.6　ユーザーインターフェイス
1.1.7　技術
1.1.8　サイズ
1.1.9　所有権
1.2　モノリス
1.2.1　単一プロセスのモノリス
1.2.2　分散モノリス
1.2.3　サードパーティ製のブラックボックスシステム
1.2.4　モノリスの課題
1.2.5　モノリスの利点
1.3　結合と凝集
1.3.1　凝集
1.3.2　結合
1.4　必要十分なドメイン駆動設計
1.4.1　集約
1.4.2　境界づけられたコンテキスト
1.4.3　集約と境界づけられたコンテキストをマイクロサービスにマッピングする
1.4.4　参考文献
1.5　この章のまとめ
2章　移行を計画する
2.1　目的を理解する
2.1.1　3つの重要な質問
2.2　マイクロサービスを選択する理由
2.2.1　チームの自律性を高める
2.2.2　市場投入までの時間を減らす
2.2.3　負荷への費用対効果が高いスケーリング
2.2.4　堅牢性を改善する
2.2.5　開発者の数を増やす
2.2.6　新しい技術を受け入れる
2.3　マイクロサービスが悪いアイデアのとき
2.3.1　不明瞭なドメイン
2.3.2　スタートアップ
2.3.3　顧客の環境にインストールして管理するソフトウェア
2.3.4　もっともな理由を持たないとき
2.4　トレードオフ
2.5　みんなを連れていく
2.6　組織を変革する
2.6.1　危機意識を高める
2.6.2　変革推進のための連帯チームを築く
2.6.3　ビジョンと戦略を生み出す
2.6.4　変革のためのビジョンを周知徹底する
2.6.5　従業員の自発を促す
2.6.6　短期的成果を実現する
2.6.7　成果を活かして、さらなる変革を推進する
2.6.8　新しい方法を企業文化に定着させる
2.7　段階的に移行していくことの重要性
2.7.1　本番環境が重要
2.8　変更のコスト
2.8.1　可逆的な判断と不可逆的な判断
2.8.2　試しやすい場所
2.9　どこから始めればよいか？
2.10　ドメイン駆動設計
2.10.1　どこまでやればいいか？
2.10.2　イベントストーミング
2.10.3　ドメインモデルを使った優先順位付け
2.11　組み合わせモデル
2.12　チームを再編成する
2.12.1　構造を変える
2.12.2　どこにでもフィットするやり方はない
2.12.3　変化を起こす
2.12.4　スキルを変える
2.13　うまくいっているかどうかを分かるには？
2.13.1　定期的なチェックポイントを設ける
2.13.2　定量的な測定
2.13.3　定性的な測定
2.13.4　サンクコストの錯誤を回避する
2.13.5　新しいやり方への選択肢を開いておく
2.14　この章のまとめ
3章　モノリスを分割する
3.1　モノリスを変更すべきかどうか
3.1.1　切り貼りか再実装か？
3.1.2　モノリスをリファクタリングする
3.2　移行パターン
3.3　パターン：ストラングラーアプリケーション
3.3.1　使い方
3.3.2　使いどころ
3.3.3　例：HTTPリバースプロキシ
3.3.4　データ？
3.3.5　プロキシの選択肢
3.3.6　プロトコルを変える
3.3.7　例：FTP
3.3.8　例：メッセージ傍受
3.3.9　その他のプロトコル
3.3.10　ストラングラーパターンのその他の例
3.4　機能を移行しながら振る舞いを変える
3.5　パターン：UI合成
3.5.1　例：ページ合成
3.5.2　例：ウィジェット合成
3.5.3　例：マイクロフロントエンド
3.5.4　使いどころ
3.6　パターン：抽象化によるブランチ
3.6.1　使い方
3.6.2　フォールバック機構として
3.6.3　使いどころ
3.7　パターン：同時実行
3.7.1　例：クレジットデリバティブの価格比較
3.7.2　例：Homegate社のリスティング
3.7.3　検証テクニック
3.7.4　スパイを使う
3.7.5　GitHub Scientist
3.7.6　ダークローンチとカナリアリリース
3.7.7　使いどころ
3.8　パターン：デコレーティングコラボレーター
3.8.1　例：ポイントプログラム
3.8.2　使いどころ
3.9　パターン：変更データキャプチャ
3.9.1　例：ポイントカードの発行
3.9.2　変更データキャプチャを実装する
3.9.3　使いどころ
3.10　この章のまとめ
4章　データベースを分割する
4.1　パターン：共有データベース
4.1.1　対処パターン
4.1.2　使いどころ
4.2　しかし、できない！
4.3　パターン：データベースビュー
4.3.1　パブリックな契約としてのデータベース
4.3.2　提示用のビュー
4.3.3　制限事項
4.3.4　所有権
4.3.5　使いどころ
4.4　パターン：データベースをラップするサービス
4.4.1　使いどころ
4.5　パターン：サービスのインターフェイスとしてのデータベース
4.5.1　マッピングエンジンを実装する
4.5.2　ビューとの比較
4.5.3　使いどころ
4.6　所有権を移す
4.6.1　パターン：集約を公開するモノリス
4.6.2　パターン：データ所有権の変更
4.7　データ同期
4.8　パターン：アプリケーションでのデータ同期
4.8.1　ステップ 1：データを一括で同期する
4.8.2　ステップ 2：同期のために書き込み、古いスキーマから読み取る
4.8.3　ステップ 3：同期のために書き込み、新しいスキーマから読み取る
4.8.4　このパターンを使うとき
4.8.5　使いどころ
4.9　パターン：トレーサー書き込み
4.9.1　データ同期
4.9.2　事例：Squareの注文
4.9.3　使いどころ
4.10　データベースを分割する
4.10.1　物理的なデータベースの分離と論理的なデータベースの分離
4.11　データベースとコードのどちらを最初に分割するか
4.11.1　データベースを最初に分割する
4.11.2　コードを最初に分割する
4.11.3　データベースとコードを一緒に分割する
4.11.4　結局どちらを最初に分割すべきか？
4.12　スキーマ分割の例
4.13　パターン：テーブルの分割
4.13.1　使いどころ
4.14　パターン：外部キーのコードへの移動
4.14.1　結合の移動
4.14.2　データの一貫性
4.14.3　使いどころ
4.14.4　例：共有静的データ
4.15　トランザクション
4.15.1　ACIDトランザクション
4.15.2　ACIDだとしても原子性に欠ける？
4.15.3　2フェーズコミット
4.15.4　分散トランザクションにはノーと言う
4.16　サーガ
4.16.1　サーガの障害モード
4.16.2　サーガの実装
4.16.3　サーガ vs 分散トランザクション
4.17　この章のまとめ
5章　成長の痛み
5.1　サービスが増えれば痛みも増える
5.2　所有権のスケール
5.2.1　この問題はどのようにして現れるか？
5.2.2　この問題はいつ発生するか？
5.2.3　取り得る解決策
5.3　破壊的変更
5.3.1　この問題はどのようにして現れるか？
5.3.2　この問題はいつ発生するか？
5.3.3　取り得る解決策
5.4　レポーティング
5.4.1　この問題はどのようにして現れるか？
5.4.2　取り得る解決策
5.5　監視とトラブルシューティング
5.5.1　この問題はいつ発生するか？
5.5.2　こうした問題はどのように現れるか？
5.5.3　取り得る解決策
5.6　開発者体験
5.6.1　この問題はどのようにして現れるか？
5.6.2　この問題はいつ発生するか？
5.6.3　取り得る解決策
5.7　あまりにも多くのものを実行している
5.7.1　この問題はどのようにして現れるか？
5.7.2　この問題はいつ発生するか？
5.7.3　取り得る解決策
5.8　エンドツーエンドテスト
5.8.1　この問題はどのようにして現れるか？
5.8.2　この問題はいつ発生するか？
5.8.3　取り得る解決策
5.9　全体最適と局所最適
5.9.1　この問題はどのようにして現れるか？
5.9.2　この問題はいつ発生するか？
5.9.3　取り得る解決策
5.10　堅牢性と回復性
5.10.1　この問題はどのようにして現れるか？
5.10.2　この問題はいつ発生するか？
5.10.3　取り得る解決策
5.11　孤児サービス
5.11.1　この問題はどのようにして現れるか？
5.11.2　この問題はいつ発生するか？
5.11.3　取り得る解決策
5.12　この章のまとめ
6章　終わりに

目次からもわかる通り、もちろん本書にはマイクロサービスの専門家である著者ならではの実践的なヒントも大いに散りばめられています。

ドメイン駆動設計を利用したサービスのモデリング方法や、サーガを用いてサービス同士を協調させる方法、サービスの数が増えてくる中で起こってくるさまざまな課題の兆候と対処の仕方。

こうした、実践の中で培われた筆者の幅広い知見は、すでにマイクロサービスに取り組まれている方にも多いに参考になるはずです。

翻訳を進めていく中で、技術的な意思決定に対する著者の誠実な態度や姿勢に、私自身は何度も癒され（不思議な表現だとは思いますが、一技術者として癒される自分がいました）、襟を正されました。

そのような誠実な態度で書かれた、このマイクロサービスについての書籍が、ぜひマイクロサービスの導入に関心を持っている現場や実際にマイクロサービス化に取り組んでいる現場をはじめ、さまざまな現場のたくさんの方々に届くことを願っています。