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の試用

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

10章コンウェイの法則とシステム設計

ここまで本書の大部分では、粒度の細かいアーキテクチャへ移行する際の技術的課題を重点的に取り上げてきました。しかし、他にも検討すべき組織的問題があります。本章で学ぶように、あなたは危険を覚悟で会社の組織図を無視しています。

この業界は若く、常に自己改革しているように見えます。そして、少数の重要な法則が時の試練に耐えています。例えば、集積回路のトランジスタ密度が2年ごとに2倍になるというムーアの法則は、不思議なほど正確であることが証明されています（しかし、この傾向は既に減速していると予測する人もいます）。ある1つの法則はほぼ例外なく私にとって真実であり、毎日の仕事に極めて有益です。それはコンウェイの法則です。

1968年4月に雑誌Datamationで発表されたMelvin Conway（メルヴィン・コンウェイ）の論文「How Do Committees Invent?」では、以下のように述べられています†1。

[†1] 監訳者注：この論文の全文は、http://www.melconway.com/Home/Committees_Paper.htmlを参照。

システム（ここでは単なる情報システムよりも広く定義されたシステム）を設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を持つ設計を生み出す。

この記述は、「コンウェイの法則」としてさまざまな形で引用されています。Eric S. Raymondは、『The New Hacker's Dictionary』（MIT Press、日本語版『ハッカーズ大事典』アスキー）でこの現象を要約し、「コンパイラの開発を担当する4つのグループがあれば、4パスコンパイラが得られる」と述べています。 ...