30分でわかるマイクロサービスアーキテクチャ 第2版 - Forkwell Library #17 https://forkwell.connpass.com/event/273812/ https://www.youtube.com/watch?v=xYTtw0ZgUNU
オライリー・ジャパン > マイクロサービスアーキテクチャ 第2版 https://www.oreilly.co.jp/books/9784814400010/
30分でわかるマイクロサービスアーキテクチャ第2版佐 藤 直 生
View Slide
30分でわかるマイクロサービスアーキテクチャ 第2版 - Forkwell Library #17 - YouTube
30分でわかるマイクロサービスアーキテクチャ 第2版
セッション概要2014年に登場した「マイクロサービスアーキテクチャ」は、多くの実践を経て進化を続けています。今回、第2版が出版された書籍「マイクロサービスアーキテクチャ」も、8年前の第1版から全面的に書き換えられました。本セッションでは、600ページを超える書籍「マイクロサービスアーキテクチャ 第2版)の全体像をご紹介します。30分でわかるマイクロサービスアーキテクチャ第2版 - Forkwell Library #17 –connpass
自己紹介日本オラクル株式会社における、Java EEアプリケーションサーバやミドルウェアのテクノロジーエバンジェリストとしての経験を経て、Microsoft Corporationで、パブリッククラウドプラットフォーム「MicrosoftAzure」のエバンジェリスト、ソリューションアーキテクトなどを歴任し、現在はシニアソフトウェアエンジニアとして活動オライリーの書籍の監訳、翻訳、執筆を18冊担当Twitter: @satonaoki
タイムライン2011-2012「マイクロサービス」(microservices) という用語が登場Microservices - Wikipedia2014martinfowler.com に「Microservices」ページが登場 (James Lewis, MartinFowler)Microservices(martinfowler.com)2015-2016書籍「BuildingMicroservices」出版日本語版「マイクロサービスアーキテクチャ」出版2021-2022書籍「BuildingMicroservices, 2ndEdition」出版日本語版「マイクロサービスアーキテクチャ 第2版」出版
本書の構成第2版• 第Ⅰ部 基礎• 1章 マイクロサービスとは• 2章 マイクロサービスのモデル化• 3章 モノリスの分割• 4章 マイクロサービスの通信スタイル• 第Ⅱ部 実装• 5章 マイクロサービスの通信の実装• 6章 ワークフロー• 7章 ビルド• 8章 デプロイ• 9章 テスト• 10章 監視から可観測性へ• 11章 セキュリティ• 12章 レジリエンス• 13章 スケーリング• 第Ⅲ部 人• 14章 UI• 15章 組織構造• 16章 進化的アーキテクト第1版• 1章 マイクロサービス• 2章 進化的アーキテクト• 3章 サービスのモデル化方法• 4章 統合• 5章 モノリス（一枚岩）の分割• 6章 デプロイ• 7章 テスト• 8章 監視• 9章 セキュリティ• 10章 コンウェイの法則とシステム設計• 11章 大規模なマイクロサービス• 12章 まとめ
第Ⅰ部 基礎
1章 マイクロサービスとは (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 コンテナとKubernetes• 1.4.3 ストリーミング• 1.4.4 パブリッククラウドとサーバレス
1章 マイクロサービスとは (2)• 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 まとめ
1章 マイクロサービスとは• マイクロサービスは、ビジネスドメインを中心にモデル化された、独立してリリース可能なサービス• サービスは機能をカプセル化し、ネットワーク経由で他のサービスからアクセス可能• 例: 在庫、注文管理、発送を表すマイクロサービスが、ECシステムを構成• マイクロサービスの重要な概念1. 独立デプロイ可能性2. ビジネスドメインに基づくモデル化3. マイクロサービスごとの状態の所有4. サイズ5. 柔軟性6. アーキテクチャと組織の連携 –ストリームアラインドチーム
1章 マイクロサービスとは• モノリスでは、システムのすべての機能をまとめてデプロイしなければならない• デリバリ競合が起きやすい1. 単一プロセスモノリス2. モジュラーモノリス3. 分散モノリス• 実現技術1. ログ集約と分散トレーシング –Honeycombなど2. コンテナとKubernetes3. ストリーミング - Kafkaなど4. パブリッククラウドとサーバレス
1章 マイクロサービスとは• マイクロサービスの利点1. 技術の異種性2. 堅牢性 – バルクヘッド3. スケーリング4. デプロイの容易性5. 組織との連携6. 合成可能性• マイクロサービスの課題1. 開発者体験2. 技術の過負荷3. コスト4. レポート5. 監視とトラブルシューティング6. セキュリティ7. テスト8. 遅延9. データ一貫性
1章 マイクロサービスとは• マイクロサービスを使うべきか• 役立たない場合1. 新製品、スタートアップ2. 顧客がデプロイ、管理するソフトウェアを開発している組織• 効果的な場所1. 急成長している100人規模の企業2. SaaSアプリケーション3. さまざまな新規チャネルで顧客にサービスを提供することを目指す組織
1章 マイクロサービスとは• マイクロサービスは、技術選択、堅牢性/スケーリング、チーム編成などに、非常に高い柔軟性を与える• 大きな複雑さも伴うので、使用が正当化する必要がある• 正しく理解、実装すると、強力で生産性の高いアーキテクチャを構築するのに役立つ
2章 マイクロサービスのモデル化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 まとめ
図2-16 Warehouseサービスは、内部でInventory、Shippingサービスに分割されている
3章 モノリスの分割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 まとめ
図3-5 ストラングラーフィグパターンの概要
4章 マイクロサービスの通信スタイル (1)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 欠点4.5.3 非同期非ブロッキングの用途
4章 マイクロサービスの通信スタイル (2)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 まとめ
図4-1 マイクロサービス間通信のさまざまなスタイルと、実装技術の例
第Ⅱ部 実装
5章 マイクロサービスの通信の実装 (1)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章 マイクロサービスの通信の実装 (2)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 まとめ
図5-6 APIゲートウェイとサービスメッシュが使われる場所の概要
6章 ワークフロー6.1 データベーストランザクション6.1.1 ACIDトランザクション6.1.2 ACIDでも、原子性に欠けるのか6.2 分散トランザクション：2フェーズコミット6.3 分散トランザクションはお断り6.4 サーガ6.4.1 サーガの障害モード6.4.2 サーガの実装6.4.3 サーガと分散トランザクションの比較6.5 まとめ
図6-7 サーガ全体のロールバックのトリガー
7章 ビルド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 まとめ
図7-10 独立したビルドにマッピングされたサブディレクトリを持つ、単一ソースリポジトリ
8章 デプロイ (1)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 asa Service、サービスとしてのプラットフォーム）8.3.6 FaaS（Function asa Service、サービスとしての関数）8.4 どのデプロイオプションが自分に適しているか
8章 デプロイ (2)8.5 Kubernetesとコンテナオーケストレーション8.5.1 コンテナオーケストレーションの例8.5.2 Kubernetesの概念の簡略図8.5.3 マルチテナントとフェデレーション8.5.4 CNCF（Cloud NativeComputing 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 まとめ
図8-23 Pod、サービス、デプロイの連携方法
9章 テスト (1)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章 テスト (2)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 まとめ
図9-9 複数サービスにわたるエンドツーエンドテストに対処する標準的な方法
10章 監視から可観測性へ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 まとめ
図10-6 一連の呼び出し用の相関IDを生成する
11章 セキュリティ (1)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章 セキュリティ (2)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 まとめ
図11-9 特定のリクエスト用のJWTトークンが生成され、下流マイクロサービスに渡される
12章 レジリエンス (1)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章 レジリエンス (2)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 まとめ
図12-6 AdvertCorpへのサーキットブレーカーの追加
13章 スケーリング13.1 スケーリングの4つの軸13.1.1 垂直スケーリング13.1.2 水平複製13.1.3 データのパーティション分割13.1.4 機能分解13.2 モデルの組み合わせ13.3 小さく始める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 まとめ
図13-5 リクエストを適切なマイクロサービスインスタンスに送る
第Ⅲ部 人
14章 UI (1)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 パターン：ページベースの分解14.6.1 ページベースの分解の用途14.7 パターン：ウィジェットベースの分解14.7.1 実装14.7.2 ウィジェットベースの分解を使う場合
14章 UI (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 まとめ
図14-11 各UIが、独自のBFFを持つ
15章 組織構造 (1)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章 組織構造 (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 まとめ
図15-2 イネイブリングチームは、複数のストリームアラインドチームをサポートする
16章 進化的アーキテクト (1)16.1 「名前が何だと言うの」16.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章 進化的アーキテクト (2)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 まとめ
図16-3 原則、プラクティスの実世界での例
まとめ本書は、マイクロサービスが適しているかを判断するための情報、経験を共有マイクロサービスを目標ではなく、漸進的に進む旅システムを分解し、進みながら学ぼうシステムを継続的に進化させるための規律が重要変化を受け入れましょう「マイクロサービスアーキテクチャ 第2版」を購入しましょう!
関連リソース• O'Reilly Japan - マイクロサービスアーキテクチャ 第2版• O'Reilly Japan - マイクロフロントエンド• O'Reilly Japan - モノリスからマイクロサービスへ• O'Reilly Japan - プロダクションレディマイクロサービス• O'Reilly Japan - 進化的アーキテクチャ• O‘Reilly Japan - Learning Platform (サブスクリプション)
関連リソース• マイクロサービス アーキテクチャの設計 -Azure Architecture Center• マイクロサービスの設計パターン - AzureArchitecture Center• AKS のマイクロサービス アーキテクチャ -Azure Architecture Center• 高度な Azure Kubernetes Service(AKS) マイクロサービス アーキテクチャ –Azure Architecture Center• Azure Container Apps を使用したマイクロサービスのデプロイ - AzureArchitecture Center• Azure Container Apps と Dapr を使ってマイクロサービスをデプロイする -Azure Example Scenarios• .NET Microservices アプリケーションアーキテクチャ ガイダンス• .NET と ASP.NET Core を使用してマイクロサービスを作成する - Training
satonaoki
bun913
victorrentea
bitkey
optim
ryomaru0825
m3hiro3
niryuu
hayaok3
soracom
hiroshinakagawa
yumayabe
doradora09
reverentgeek
aki_iinuma
orderedlist
bryan
lauravandoore
thoeni
panda_program
kastner
jennybc
malarkey
sstephenson
geeforr