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

https://gyazo.com/da0ca28fe7f138d112e6801d0f0e1632

はじめに

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.1　どこまでやればいいか？

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.5　新しいやり方への選択肢を開いておく

2.14　この章のまとめ

3章　モノリスを分割する

3.1　モノリスを変更すべきかどうか

3.1.1　切り貼りか再実装か？

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章　終わりに

付録A パターン一覧

参考文献

訳者あとがき

索引