Book description
マイクロサービスとは、ThoughtWorks社のマーチン・ファウラーとジェームス・ルイスが最初に提唱したソフトウェアアーキテクチャです。モノリシック(一枚岩)なアーキテクチャを、ビジネス機能に沿って複数の小さい「マイクロサービス」に分割し、それらを連携させるアーキテクチャにすることで、迅速なデプロイ、優れた回復性やスケーラビリティといった利点を実現しようとするものです。本書は、マイクロサービスとは何か、その長所と短所、定義と概念、設計思想、アーキテクトの役割から、分割、デプロイ、テスト、監視、セキュリティといった個別の技術までを、マイクロサービスを採用しているNetflixやAmazonといった企業の事例を交えながら紹介します。
Table of contents
- 大扉
- 原書大扉
- クレジット
- はじめに
- 本書の対象読者
- 本書を執筆した理由
- マイクロサービスの現状
- 本書の構成
- 表記法
- コード例の使用
- 問い合わせ先
- 謝辞
- 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 最後に
- 付録A 実際のマイクロサービス:Azure Service Fabric
- A.1 概要
- A.2 主な機能と概念
- A.3 適したアプリケーション
- A.4 アーキテクチャ
- A.5 アプリケーションモデル
- A.6 Azure Service Fabricの試用
- 著者紹介
- 奥付
Product information
- Title: マイクロサービスアーキテクチャ
- Author(s):
- Release date: February 2016
- Publisher(s): O'Reilly Japan, Inc.
- ISBN: 9784873117607
You might also like
book
マイクロサービスアーキテクチャ 第2版
2014年にThoughtworksのマーチン・ファウラーとジェームス・ルイスによって提唱された「マイクロサービス」は、いまではすっかり市民権を得て、さまざまな手法やツールが開発されています。著者は、マイクロサービスに「賛成」でも「反対」でもないという中立的な立場から、マイクロサービスの仕組み、特徴、長所、短所、課題を丁寧に説明しています。Thoughtworks在籍中から数多くのマイクロサービスプロジェクトに携わっていた著者が共有する、自身の実体験から得た多くの知見は、システム設計、開発、デプロイ、テストといった技術的側面のみならず、人材をどのように活かし、生産性を上げるかといった組織面にも多くの示唆を与えてくれるものです。組織に適したアーキテクチャを選択し、信頼性が高く、堅牢性、安全性、柔軟性に優れたシステムを設計する上で指針となる一冊です。
book
プログラミングRust
RustはMozilla財団の支援下で開発が進められており、Mozillaの次世代ブラウザエンジンの実装にも用いられているシステムプログラミング用言語です。C/C++並みのパフォーマンスと低レベルなメモリ操作機能、型システムを用いたメモリとスレッドの安全性を両立し、さらに安全な並列性も実現した、いま最も注目されている言語です。このRustをテーマにした本書は、Rust特有の所有権、移動、借用といった概念だけでなく、生産性と柔軟性を向上させるジェネリックコード、クロージャ、イテレータ、コレクションといった高度な機能についても詳しい説明を加えており、言語仕様から高度なプログラミング技術までを網羅した決定版です。
book
オブザーバビリティ・エンジニアリング
本書は、近年のクラウドベースのソフトウェアシステム開発における設計プラクティスなどにおいて触れられる概念「オブザーバビリティ(可観測性)」に関する書籍です。オブザーバビリティとは何か、どのように役立てるのかなど、登場の背景から実践方法、組織、企業への適用といった幅広い視点で解説します。今後、ソフトウェアシステムの開発においてオブザーバビリティが果たすであろう、より大きな役割についても触れています。さらにSlackのゲスト寄稿者により、テストとデプロイプロセスへのオブザーバビリティの適用と、パイプラインによるテレメトリー管理についてのケーススタディを紹介。本書はソフトウェアに関わる多くの人々にとって今後より一般化するオブザーバビリティを知る第一歩となるでしょう。
book
初めてのAnsible
本書はサーバーの構成管理ツールAnsibleについての総合的な入門書です。設定管理のスクリプトであるPlaybookの基礎から、オープンソースの本格的なコンテンツ管理システムのインストールについて、順を追って説明します。そしてAnsibleの高速化やカスタムモジュール、VagrantやAmazonEC2、Dockerとの連携など、Ansibleの活用に役立つ事柄をサンプルを使いながら詳述します。日本語版付録として中山幸治氏による「Ansibleを利用したプロビジョニング方法」を収録。サーバーを上手に管理したいエンジニア必携の一冊です。