はじめに
1章 マイクロサービス
1.1 マイクロサービスとは
1.1.1 小さく、かつ1つの役割に専念
1.1.2 自律性
1.2 主な利点
1.2.1 技術異質性
1.2.2 回復性
1.2.3 スケーリング
1.2.4 デプロイの容易性
1.2.5 組織面の一致
1.2.6 合成可能性
1.2.7 交換可能にするための最適化
1.3 サービス指向アーキテクチャ
1.4 他の分解テクニック
1.4.1 共有ライブラリ
1.4.2 モジュール
1.5 銀の弾丸などない
1.6 まとめ
2章 進化的アーキテクト
2.1 不正確な比較
2.2 進化するアーキテクト像
2.3 区画指定
2.4 原則に基づいたアプローチ
2.4.1 戦略的目標
2.4.2 原則
2.4.3 プラクティス
2.4.4 原則とプラクティスの結合
2.4.5 実世界の例
2.5 必要な標準
2.5.1 監視
2.5.2 インタフェース
2.5.3 アーキテクチャ上の安全性
2.6 コードを介したガバナンス
2.6.1 手本
2.6.2 カスタムのサービステンプレート
2.7 技術的負債
2.8 例外処理
2.9 中央からのガバナンスと指導
2.10 チームの構築
2.11 まとめ
3章 サービスのモデル化方法
3.1 MusicCorpの紹介
3.2 優れたサービスにするには
3.2.1 疎結合
3.2.2 高凝集性
3.3 境界づけられたコンテキスト
3.3.1 共有モデルと隠れモデル
3.3.2 モジュールとサービス
3.3.3 時期尚早な分解
3.4 ビジネス機能
3.5 ずっと下の亀
3.6 ビジネス概念の観点での通信
3.7 技術的境界
3.8 まとめ
4章 統合
4.1 理想的な統合技術の探索
4.1.1 破壊的変更を回避する
4.1.2 APIを技術非依存にする
4.1.3 コンシューマにとって単純なサービスにする
4.1.4 内部の実装詳細を隠す
4.2 顧客とのインタフェース
4.3 共有データベース
4.4 同期と非同期
4.5 オーケストレーションとコレオグラフィ
4.6 リモートプロシージャコール（RPC）
4.6.1 技術的結合
4.6.2 ローカル呼び出しはリモート呼び出しとは異なる
4.6.3 脆弱性
4.6.4 RPCはひどいか
4.7 REST
4.7.1 RESTとHTTP
4.7.2 アプリケーション状態エンジンとしてのハイパーメディア（HATEOAS）
4.7.3 JSONか、XMLか、他の何かか
4.7.4 便利すぎることに注意する
4.7.5 HTTP上のRESTの欠点
4.8 非同期イベントベース連携の実装
4.8.1 技術選択
4.8.2 非同期アーキテクチャの複雑さ
4.9 状態マシンとしてのサービス
4.10 Rx（Reactive Extentions）
4.11 マイクロサービスの世界におけるDRYと コード再利用のリスク
4.11.1 クライアントライブラリ
4.12 参照によるアクセス
4.13 バージョニング
4.13.1 最大限の先送り
4.13.2 破壊的変更の早期の把握
4.13.3 セマンティックバージョニングの利用
4.13.4 異なるエンドポイントの共存
4.13.5 複数のサービスバージョンの同時使用
4.14 ユーザインタフェース
4.14.1 デジタルへ向けて
4.14.2 制約
4.14.3 API合成
4.14.4 UI部品合成
4.14.5 フロントエンド向けのバックエンド（BFF）
4.14.6 ハイブリッド手法
4.15 サードパーティソフトウェアとの統合
4.15.1 制御の欠如
4.15.2 カスタマイズ
4.15.3 統合スパゲティ
4.15.4 思い通りにする
4.15.5 ストラングラー（絞め殺し）パターン
4.16 まとめ
5章 モノリスの分割
5.1 すべては接合部次第
5.2 MusicCorpの分解
5.3 モノリスを分割する理由
5.3.1 変化の速度
5.3.2 チーム構成
5.3.3 セキュリティ
5.3.4 技術
5.4 入り組んだ依存関係
5.5 データベース
5.6 問題の対処
5.7 例：外部キー関係の削除
5.8 例：共有静的データ
5.9 例：共有データ
5.10 例：共有テーブル
5.11 データベースリファクタリング
5.11.1 段階的な分割
5.12 トランザクション境界
5.12.1 後でリトライ
5.12.2 操作全体の中止
5.12.3 分散トランザクション
5.12.4 何をすべきか
5.13 レポート
5.14 レポートデータベース
5.15 サービス呼び出しを介したデータ取得
5.16 データポンプ
5.16.1 代替手段
5.17 イベントデータポンプ
5.18 バックアップデータポンプ
5.19 リアルタイムを目指す
5.20 変更のコスト
5.21 根本原因の理解
5.22 まとめ
6章 デプロイ
6.1 継続的インテグレーションとは
6.1.1 実際にCIを行っているか
6.2 継続的インテグレーションのマイクロサービスへのマッピング
6.3 ビルドパイプラインと継続的デリバリ
6.3.1 避けられない例外
6.4 プラットフォーム固有の成果物
6.5 OS成果物
6.6 カスタムイメージ
6.6.1 成果物としてのイメージ
6.6.2 イミュータブルサーバ
6.7 環境
6.8 サービス構成
6.9 サービスからホストへのマッピング
6.9.1 ホストごとに複数のサービス
6.9.2 アプリケーションコンテナ
6.9.3 ホストごとに1つのサービス
6.9.4 PaaS
6.10 自動化
6.10.1 自動化の威力に関する2つのケーススタディ
6.11 物理から仮想へ
6.11.1 従来の仮想化
6.11.2 Vagrant
6.11.3 Linuxコンテナ
6.11.4 Docker
6.12 デプロイのインタフェース
6.12.1 環境定義
6.13 まとめ
7章 テスト
7.1 テストの種類
7.2 テストスコープ
7.2.1 単体テスト
7.2.2 サービステスト
7.2.3 エンドツーエンドテスト
7.2.4 トレードオフ
7.2.5 いくつのテストを実施するか
7.3 サービステストの実装
7.3.1 モックかスタブか
7.3.2 高度なスタブサービス
7.4 面倒なエンドツーエンドテスト
7.5 エンドツーエンドテストの欠点
7.6 信頼できない脆弱なテスト
7.6.1 誰がテストを書くか
7.6.2 実行期間
7.6.3 積み上がる大きな山
7.6.4 メタバージョン
7.7 ストーリーではなくジャーニーをテストする
7.8 救いとなるコンシューマ駆動テスト
7.8.1 Pact
7.8.2 対話について
7.9 エンドツーエンドテストを使用すべきか
7.10 本番リリース後のテスト
7.10.1 デプロイとリリースの分離
7.10.2 カナリアリリース
7.10.3 平均故障間隔（MTBF）よりも平均修復時間（MTTR）か
7.11 機能横断テスト
7.11.1 性能テスト
7.12 まとめ
8章 監視
8.1 単一サービス、単一サーバ
8.2 単一サービス、複数サーバ
8.3 複数サービス、複数サーバ
8.4 ログ、ログ、さらにまたログ
8.5 複数サービスにわたるメトリックの追跡
8.6 サービスのメトリック
8.7 合成監視
8.7.1 セマンティック監視の実装
8.8 相関ID
8.9 連鎖
8.10 標準化
8.11 利用者の考慮
8.12 将来
8.13 まとめ
9章 セキュリティ
9.1 認証と認可
9.1.1 一般的なシングルサインオン（SSO）の実装
9.1.2 シングルサインオン（SSO）ゲートウェイ
9.1.3 粒度の細かい認可
9.2 サービス間の認証と認可
9.2.1 境界内のすべてを許可する
9.2.2 HTTP（S）ベーシック認証
9.2.3 SAMLやOpenID Connectの使用
9.2.4 クライアント証明書
9.2.5 HTTP上のHMAC
9.2.6 APIキー
9.2.7 代理の問題
9.3 格納データの保護
9.3.1 よく知られた手法を選ぶ
9.3.2 鍵がすべて
9.3.3 対象を選ぶ
9.3.4 必要に応じた復号
9.3.5 バックアップの暗号化
9.4 徹底的な防御
9.4.1 ファイアウォール
9.4.2 ロギング
9.4.3 侵入検知（および侵入防止）システム
9.4.4 ネットワーク分離
9.4.5 OS
9.5 実施例
9.6 節約する
9.7 人的要素
9.8 黄金律
9.9 セキュリティの組み込み
9.10 外部検証
9.11 まとめ
10章 コンウェイの法則とシステム設計
10.1 証拠
10.1.1 疎結合組織と密結合組織
10.1.2 Windows Vista
10.2 NetflixとAmazon
10.3 この法則で何ができるか
10.4 コミュニケーション経路に適応する
10.5 サービスの所有権
10.6 共有サービスに向かう要因
10.6.1 分割が難しすぎる
10.6.2 フィーチャーチーム
10.6.3 デリバリボトルネック
10.7 社内オープンソース
10.7.1 管理者の役割
10.7.2 成熟度
10.7.3 ツール
10.8 境界づけられたコンテキストとチーム構造
10.9 孤児サービス
10.10 ケーススタディ：RealEstate.com.au
10.11 逆向きのコンウェイの法則
10.12 人
10.13 まとめ
11章 大規模なマイクロサービス
11.1 障害はどこにでもある
11.2 どれくらいが多すぎるのか
11.3 機能低下
11.4 アーキテクチャ上の安全対策
11.5 アンチフラジャイルな組織
11.5.1 タイムアウト
11.5.2 サーキットブレーカー
11.5.3 隔壁
11.5.4 分離
11.6 冪等性
11.7 スケーリング
11.7.1 より大きくする
11.7.2 作業負荷の分割
11.7.3 リスクの分散
11.7.4 負荷分散
11.7.5 ワーカベースのシステム
11.7.6 再出発
11.8 データベースのスケーリング
11.8.1 サービスの可用性とデータの耐久性
11.8.2 読み取りのためのスケーリング
11.8.3 書き込みのためのスケーリング
11.8.4 共有データベースインフラ
11.8.5 CQRS
11.9 キャッシング
11.9.1 クライアント側、プロキシ、サーバ側のキャッシング
11.9.2 HTTPでのキャッシング
11.9.3 書き込みのキャッシング
11.9.4 回復性のためのキャッシング
11.9.5 オリジンサーバの隠蔽
11.9.6 簡潔に保つ
11.9.7 キャッシュポイズニング：訓話
11.10 オートスケーリング
11.11 CAP定理
11.11.1 整合性を犠牲にする
11.11.2 可用性を犠牲にする
11.11.3 分断耐性を犠牲にするか
11.11.4 APかCPか
11.11.5 オールオアナッシングではない
11.11.6 そして現実の世界
11.12 サービス検出
11.12.1 DNS
11.13 動的サービスレジストリ
11.13.1 ZooKeeper
11.13.2 Consul
11.13.3 Eureka
11.13.4 自作
11.13.5 人間を忘れない
11.14 サービスの文書化
11.14.1 Swagger
11.14.2 HALとHALブラウザ
11.15 自己記述型システム
11.16 まとめ
12章 まとめ
12.1 マイクロサービスの原則
12.1.1 ビジネス概念に沿ったモデル化
12.1.2 自動化の文化の採用
12.1.3 内部実装詳細の隠蔽
12.1.4 すべての分散化
12.1.5 独立したデプロイ
12.1.6 障害の分離
12.1.7 高度な観測性
12.2 マイクロサービスを使用すべきでない場合
12.3 最後に
付録 実際のマイクロサービス：Azure Service Fabric
索引