book

マイクロサービスアーキテクチャ第2版

by Sam Newman, 佐藤直生, 木下哲也

November 2022

Intermediate to advanced

664 pages

9h 43m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

本書の対象読者執筆した理由第1版からの変更点本書の構成Ⅰ部　基礎Ⅱ部　実装Ⅲ部　人表記法連絡先謝辞
1.1　マイクロサービスの概要サービス指向アーキテクチャとマイクロサービスは違うもの？1.2　マイクロサービスの重要な概念1.2.1　独立デプロイ可能性1.2.2　ビジネスドメインに基づくモデル化1.2.3　マイクロサービスごとの状態の所有1.2.4　サイズ1.2.5　柔軟性1.2.6　アーキテクチャと組織の連携「フェイク」企業に関する注意1.3　モノリス1.3.1　単一プロセスモノリス1.3.2　モジュラーモノリス1.3.3　分散モノリス1.3.4　モノリスとデリバリ競合1.3.5　モノリスの利点1.4　実現技術1.4.1　ログ集約と分散トレーシング1.4.2　コンテナとKubernetes1.4.3　ストリーミング1.4.4　パブリッククラウドとサーバレス1.5　マイクロサービスの利点1.5.1　技術の異種性1.5.2　堅牢性1.5.3　スケーリング1.5.4　デプロイの容易性1.5.5　組織との連携1.5.6　合成可能性1.6　マイクロサービスの課題1.6.1　開発者体験1.6.2　技術の過負荷1.6.3　コスト1.6.4　レポート1.6.5　監視とトラブルシューティング1.6.6　セキュリティ1.6.7　テスト1.6.8　遅延1.6.9　データ一貫性1.7　マイクロサービスを使うべきか1.7.1　役立たない場合1.7.2　効果的な場所1.8　まとめ
2.1　MusicCorpの紹介2.2　適切なマイクロサービス境界にするには2.2.1　情報隠蔽2.2.2　凝集2.2.3　結合2.2.4　結合と凝集の相互関係2.3　結合の種類構造化プログラミングの先行技術2.3.1　ドメイン結合2.3.2　パススルー結合時間的結合に関してひと言2.3.3　共通結合2.3.4　内容結合2.4　過不足のないドメイン駆動設計（DDD）2.4.1　ユビキタス言語2.4.2　アグリゲート（集約）2.4.3　境界づけられたコンテキスト（コンテキスト境界）2.4.4　アグリゲート、境界づけられたコンテキストのマイクロサービスへのマッピング2.4.5　イベントストーミング2.5　マイクロサービス向けのドメイン駆動設計（DDD）の例2.6　ビジネスドメイン境界の代替手段2.6.1　変動性2.6.2　データ2.6.3　技術2.6.4　組織内部階層化と外部階層化2.7　混合モデルと例外2.8　まとめ
3.1　目標を持つ3.2　漸進的な移行3.3　ほとんどの場合、モノリスは敵ではない3.3.1　時期尚早な分解の危険性3.4　まず何を分割すべきか3.5　階層による分解3.5.1　コードファースト3.5.2　データファースト3.6　便利な分解パターン3.6.1　ストラングラーフィグパターン3.6.2　並列実行3.6.3　機能トグル3.7　データ分解における懸念3.7.1　パフォーマンス3.7.2　データ完全性3.7.3　トランザクション3.7.4　ツール3.7.5　レポートデータベース3.8　まとめ
4.1　プロセス内からプロセス間へ4.1.1　パフォーマンス4.1.2　インタフェースの変更4.1.3　エラー処理4.2　プロセス間通信のための技術：多数の選択肢4.3　マイクロサービスの通信スタイル4.3.1　うまく組み合わせる4.4　パターン：同期ブロッキング4.4.1　利点4.4.2　欠点4.4.3　同期ブロッキングの用途4.5　パターン：非同期非ブロッキング4.5.1　利点4.5.2　欠点async/awaitと、非同期でもブロックするとき4.5.3　非同期非ブロッキングの用途4.6　パターン：共通データを介した通信4.6.1　実装4.6.2　利点4.6.3　欠点4.6.4　共通データを介した通信の用途4.7　パターン：リクエスト/レスポンス通信コマンドとリクエスト4.7.1　実装：同期と非同期並列呼び出しと逐次呼び出し4.7.2　リクエスト/レスポンス通信の用途4.8　パターン：イベント駆動通信イベントとメッセージ4.8.1　実装4.8.2　イベントの中身4.8.3　イベント駆動通信の用途4.9　注意深く進める4.10　まとめ

5.1　理想的な技術の探索5.1.1　後方互換性を容易にする5.1.2　インタフェースを明示的にする5.1.3　APIを技術非依存にする5.1.4　コンシューマにとって単純なサービスにする5.1.5　内部実装の詳細を隠す5.2　技術選択5.2.1　リモートプロシージャコール（RPC）5.2.2　REST5.2.3　GraphQL5.2.4　メッセージブローカー5.3　シリアライゼーション形式5.3.1　テキスト形式5.3.2　バイナリ形式5.4　スキーマ5.4.1　契約の構造的破壊と意味的破壊5.4.2　スキーマを使うべきか5.5　マイクロサービス間の変更に対処する5.6　破壊的変更の回避5.6.1　拡張変更5.6.2　耐性のあるリーダー5.6.3　適切な技術5.6.4　明示的なインタフェースセマンティックバージョニング5.6.5　偶発的な破壊的変更の早期把握5.7　破壊的変更の管理5.7.1　ロックステップデプロイ5.7.2　互換性のないマイクロサービスバージョンの共存5.7.3　旧インタフェースのエミュレーション5.7.4　どちらのアプローチが好ましいか5.7.5　社会契約5.7.6　利用の追跡5.7.7　極端な手段5.8　マイクロサービスの世界における、DRYとコード再利用の危険性5.8.1　ライブラリを介したコード共有5.9　サービス検出5.9.1　ドメインネームシステム（DNS）5.9.2　動的サービスレジストリ5.9.3　人を忘れない5.10　サービスメッシュとAPIゲートウェイ5.10.1　APIゲートウェイ5.10.2　サービスメッシュ5.10.3　他のプロトコルはどうか5.11　サービスの文書化5.11.1　明示的なスキーマ5.11.2　自己記述型システム5.12　まとめ
6.1　データベーストランザクション6.1.1　ACIDトランザクション6.1.2　ACIDでも、原子性に欠けるのか6.2　分散トランザクション：2フェーズコミット6.3　分散トランザクションはお断りデータベース分散トランザクション6.4　サーガ6.4.1　サーガの障害モード6.4.2　サーガの実装BPMツール呼び出しを追跡する6.4.3　サーガと分散トランザクションの比較6.5　まとめ
7.1　継続的インテグレーション（CI）とは7.1.1　本当にCIを行っているか7.1.2　ブランチモデル7.2　ビルドパイプラインと継続的デリバリ（CD）継続的デリバリと継続的デプロイの比較7.2.1　ツール7.2.2　トレードオフと環境7.2.3　成果物の作成7.3　ソースコードとビルドのマイクロサービスへのマッピング7.3.1　1つの巨大リポジトリ、1つの巨大ビルド7.3.2　パターン：マイクロサービスごとに1つのリポジトリ（別名マルチリポ）7.3.3　パターン：モノリポ7.3.4　どの方法を使うべきか7.4　まとめ
8.1　論理から物理へ8.1.1　複数インスタンス8.1.2　データベース8.1.3　環境8.2　マイクロサービスのデプロイの原則8.2.1　分離された実行8.2.2　自動化の重視8.2.3　IaC（コードとしてのインフラ）8.2.4　停止時間のないデプロイ8.2.5　望ましい状態の管理8.3　デプロイの選択肢8.3.1　物理マシン8.3.2　仮想マシン（VM）8.3.3　コンテナ曖昧な境界線8.3.4　アプリケーションコンテナ8.3.5　PaaS（Platform as a Service、サービスとしてのプラットフォーム）8.3.6　FaaS（Function as a Service、サービスとしての関数）WebAssembly（Wasm）8.4　どのデプロイオプションが自分に適しているかPuppet、Chef、その他のツールの役割8.5　Kubernetesとコンテナオーケストレーション8.5.1　コンテナオーケストレーションの例8.5.2　Kubernetesの概念の簡略図8.5.3　マルチテナントとフェデレーションKubernetesの背景8.5.4　CNCF（Cloud Native Computing Foundation）8.5.5　プラットフォームと移植性8.5.6　Helm、Operator、CRD8.5.7　Knative8.5.8　将来8.5.9　Kubernetesを使うべきか8.6　プログレッシブデリバリ8.6.1　デプロイとリリースの分離8.6.2　プログレッシブデリバリへの移行8.6.3　機能トグル8.6.4　カナリアリリース8.6.5　並列実行8.7　まとめ
9.1　テストの種類手動の探索的テスト9.2　テストスコープ9.2.1　単体テスト9.2.2　サービステスト9.2.3　エンドツーエンドテスト統合テストはどうなのか9.2.4　トレードオフ9.3　サービステストの実装9.3.1　モックかスタブか9.3.2　高度なスタブサービス9.4　（扱いにくい）エンドツーエンドテストの実装9.4.1　信頼できない脆弱なテスト9.4.2　誰がエンドツーエンドテストを書くか9.4.3　エンドツーエンドテストの実行期間9.4.4　積み上がる大きな山9.4.5　メタバージョン9.4.6　独立テスト容易性の欠如9.5　エンドツーエンドテストを避けるべきか9.5.1　契約テストとコンシューマ駆動契約（CDC）9.5.2　結論9.6　開発者体験9.7　本番前環境でのテストから本番環境でのテストへ9.7.1　本番環境でのテストの種類9.7.2　本番環境でのテストを安全にする9.7.3　平均故障間隔（MTBF）よりも平均修復時間（MTTR）か9.8　機能横断テスト9.8.1　パフォーマンステスト9.8.2　堅牢性テスト9.9　まとめ
10.1　断絶、パニック、混乱10.2　単一マイクロサービス、単一サーバ10.3　単一マイクロサービス、複数サーバ10.4　複数マイクロサービス、複数サーバ10.5　可観測性と監視の違い10.5.1　可観測性の柱？あまり高速ではない10.6　可観測性の構成要素10.6.1　ログ集約10.6.2　メトリック集約監視、可観測性システムは本番システムである10.6.3　分散トレーシング10.6.4　うまくいっているか10.6.5　アラートアラームとアラート10.6.6　セマンティック監視10.6.7　本番環境でのテスト10.7　標準化10.8　ツールの選択10.8.1　大衆性10.8.2　統合しやすさ10.8.3　コンテキストの提供10.8.4　リアルタイム10.8.5　自分たちの規模に合っている10.9　マシン内の専門家10.10　開始する10.11　まとめ
11.1　基本原則11.1.1　最小権限の原則11.1.2　多層防御セキュリティコントロールの種類11.1.3　自動化11.1.4　デリバリプロセスへのセキュリティの組み込み11.2　サイバーセキュリティの5つの機能11.2.1　特定11.2.2　保護11.2.3　検知11.2.4　対応11.2.5　復旧11.3　アプリケーションセキュリティの基礎11.3.1　資格情報（クレデンシャル）キーのスキャン11.3.2　パッチ適用11.3.3　バックアップ11.3.4　再構築11.4　暗黙の信頼とゼロトラスト11.4.1　暗黙の信頼11.4.2　ゼロトラスト11.4.3　併用のバリエーション11.5　データをセキュアにする11.5.1　転送データ11.5.2　保存データ11.6　認証認可11.6.1　サービス間認証11.6.2　人の認証11.6.3　一般的なシングルサインオン（SSO）の実装11.6.4　シングルサインオン（SSO）ゲートウェイ11.6.5　粒度の細かい認可11.6.6　混乱した代理問題11.6.7　一元的な上流での認可11.6.8　認可の分散化11.6.9　JSON Web Token（JWT）11.7　まとめ
12.1　レジリエンスとは12.1.1　堅牢性12.1.2　回復性12.1.3　グレースフルな拡張性12.1.4　持続的な適応性12.1.5　そして、マイクロサービスアーキテクチャ12.2　障害はどこにでもある12.3　どの程度が多すぎるのか12.4　機能低下12.5　安定性パターン12.5.1　タイムアウト12.5.2　再試行（リトライ）12.5.3　バルクヘッド12.5.4　サーキットブレーカー12.5.5　分離性12.5.6　冗長性12.5.7　ミドルウェア12.5.8　冪等性12.6　危険性の分散12.7　CAP定理12.7.1　一貫性を犠牲にする12.7.2　可用性を犠牲にする12.7.3　分断耐性を犠牲にするか12.7.4　APかCPか12.7.5　オールオアナッシングではない12.7.6　そして実世界アンチフラジャイル12.8　カオスエンジニアリング12.8.1　ゲームデイ12.8.2　本番環境実験12.8.3　堅牢性の先へ12.9　非難12.10　まとめ
13.1　スケーリングの4つの軸13.1.1　垂直スケーリング13.1.2　水平複製13.1.3　データのパーティション分割13.1.4　機能分解13.2　モデルの組み合わせ13.3　小さく始めるCQRSとイベントソーシング13.4　キャッシュ13.4.1　パフォーマンスのためのキャッシュ13.4.2　スケールのためのキャッシュ13.4.3　堅牢性のためのキャッシュ13.4.4　どこでキャッシュするか13.4.5　無効化13.4.6　キャッシュの黄金律13.4.7　鮮度と最適化13.4.8　キャッシュポイズニング：教訓13.5　オートスケーリング13.6　再出発13.7　まとめ
14.1　デジタルへ向けて14.2　所有権モデル14.2.1　専任フロントエンドチームに向かう要因14.3　ストリームアラインドチームを目指して14.3.1　専門家の共有14.3.2　一貫性の保証14.3.3　技術的課題の克服14.4　パターン：モノリシックフロントエンド14.4.1　モノリシックフロントエンドを使う場合14.5　パターン：マイクロフロントエンド14.5.1　実装14.5.2　マイクロフロントエンドを使う場合自己完結型システム14.6　パターン：ページベースの分解Web14.6.1　ページベースの分解の用途14.7　パターン：ウィジェットベースの分解14.7.1　実装Web Components14.7.2　ウィジェットベースの分解を使う場合14.8　制約14.9　パターン：中央集約ゲートウェイ14.9.1　所有権14.9.2　各種のUI14.9.3　複数の懸念14.9.4　中央集約ゲートウェイを使う場合14.10　パターン：BFF（フロントエンド向けのバックエンド）14.10.1　BFFをいくつにするか14.10.2　再利用とBFF14.10.3　デスクトップWebなどのためのBFF14.10.4　BFFを使う場合14.11　GraphQL14.12　ハイブリッドなアプローチ14.13　まとめ
15.1　疎結合の組織15.2　コンウェイの法則15.2.1　証拠15.3　チームサイズ15.4　コンウェイの法則を理解する15.5　小さなチーム、大きな組織15.6　自律性15.7　強い所有権と共同所有権の比較15.7.1　強い所有権15.7.2　共同所有権15.7.3　チームレベルと組織レベルの比較15.7.4　モデル間のバランスを取る15.8　イネイブリングチーム15.8.1　実践コミュニティ15.8.2　プラットフォーム15.9　共有マイクロサービス15.9.1　分割が難しすぎる15.9.2　横断的変更15.9.3　デリバリのボトルネック15.10　社内オープンソース15.10.1　コアコミッターの役割15.10.2　成熟度15.10.3　ツール15.11　プラグ可能なモジュラーマイクロサービス15.11.1　変更のレビュー15.12　孤立したサービス15.13　ケーススタディ：realestate.com.au15.14　地理的分散15.15　逆コンウェイの法則15.16　人15.17　まとめ
16.1　「名前が何だと言うの」*116.2　ソフトウェアアーキテクチャとは16.3　変更を可能にする16.4　進化するアーキテクト像16.5　システム境界の定義16.6　社会的構成概念16.7　居住性16.8　原則に基づいたアプローチ16.8.1　戦略的目標16.8.2　原則16.8.3　プラクティス16.8.4　原則とプラクティスの結合16.8.5　実世界の例16.9　進化的アーキテクチャへの指針16.10　ストリームアラインド組織でのアーキテクチャ16.11　チームの構築16.12　必要な標準16.12.1　監視16.12.2　インタフェース16.12.3　アーキテクチャ上の安全性16.13　ガバナンスと舗装道路16.13.1　見本16.13.2　カスタマイズされたマイクロサービステンプレート16.13.3　大規模での舗装道路16.14　技術的負債16.15　例外処理16.16　まとめ
マイクロサービスとはマイクロサービスへの移行通信スタイルワークフロービルドデプロイテスト監視と可観測性セキュリティレジリエンススケーリングUI組織アーキテクチャ参考文献今後について最後に