book

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

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

February 2016

Beginner to intermediate

344 pages

4h 27m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　　本書の対象読者　　本書を執筆した理由　　マイクロサービスの現状　　本書の構成　　表記法　　コード例の使用　　問い合わせ先　　謝辞
　　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.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.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.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.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.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.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.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.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.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.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.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　最後に
　　A.1　概要　　A.2　主な機能と概念　　A.3　適したアプリケーション　　A.4　アーキテクチャ　　A.5　アプリケーションモデル　　A.6　Azure Service Fabricの試用

Overview

マイクロサービスとは、ThoughtWorks社のマーチン・ファウラーとジェームス・ルイスが最初に提唱したソフトウェアアーキテクチャです。モノリシック（一枚岩）なアーキテクチャを、ビジネス機能に沿って複数の小さい「マイクロサービス」に分割し、それらを連携させるアーキテクチャにすることで、迅速なデプロイ、優れた回復性やスケーラビリティといった利点を実現しようとするものです。本書は、マイクロサービスとは何か、その長所と短所、定義と概念、設計思想、アーキテクトの役割から、分割、デプロイ、テスト、監視、セキュリティといった個別の技術までを、マイクロサービスを採用しているNetflixやAmazonといった企業の事例を交えながら紹介します。