モノリスからマイクロサービスへ (Sam Newman)

書籍情報

• 著者: Sam Newman(著), 島田浩二(訳)
• 発行日:2020-12-24
• ISBN: 9784873119311
• URL: https://www.oreilly.co.jp/books/9784873119311/

書籍目次

• はじめに
• 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章 終わりに
• 付録A パターン一覧
• 参考文献
• 訳者あとがき
• 索引