book

マスタリングAPIアーキテクチャ ―モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法

by James Gough, Daniel Bryant, Matthew Auburn, 石川朝久

October 2024

Intermediate to advanced

308 pages

4h 33m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　0.1　アーキテクチャ・ジャーニー　0.2　API概論　0.3　ケーススタディ：カンファレンスシステム　　0.3.1　カンファレンスシステムにおけるAPIの種類　　0.3.2　カンファレンスシステムを変更する理由　　0.3.3　階層型アーキテクチャからAPIのモデリングへ　　0.3.4　ケーススタディ：進化的アーキテクチャに向けたステップ　　0.3.5　APIインフラストラクチャと通信パターン　　0.3.6　カンファレンスシステムのロードマップ　0.4　C4ダイヤグラムの利用　　0.4.1　C4 コンテキスト図　　0.4.2　C4コンテナ図　　0.4.3　C4コンポーネント図　0.5　ADRの利用　　0.5.1　Attendeeを進化させるADR　　0.5.2　APIを極める：ADRガイドライン　0.6　まとめ
　1.1　ケーススタディ：Attendee APIの設計　1.2　REST入門　　1.2.1　実例で学ぶRESTとHTTP入門　　1.2.2　リチャードソン成熟度モデル　1.3　RPC APIの基礎　1.4　GraphQLの概要　1.5　REST APIの標準化と構造化　　1.5.1　コレクションとページネーション　　1.5.2　コレクションのフィルタリング　　1.5.3　エラー処理　　1.5.4　ADRガイドライン：API標準の選択　1.6　OpenAPIを利用したREST APIの仕様　1.7　OpenAPI Specificationsの実践的活用　　1.7.1　コード生成　　1.7.2　OpenAPIを利用した検証　　1.7.3　モックと例示　　1.7.4　変化の検知　1.8　APIのバージョン管理　　1.8.1　セマンティックバージョン管理　　1.8.2　OpenAPI Specificationとバージョン管理　1.9　gRPCを利用してRPCを実装する　1.10　通信手法のモデリングとAPI形式の選択　　1.10.1　高トラフィックサービス　　1.10.2　大容量ペイロード　　1.10.3　HTTP/2パフォーマンスメリット　　1.10.4　ヴィンテージフォーマット（Vintage Formats）　1.11　ガイドライン：通信のモデル化　1.12　複数の仕様　　1.12.1　「黄金の仕様書」は存在するのか？　　1.12.2　複合仕様の課題　1.13　まとめ
　2.1　本章におけるシナリオ　2.2　テスト戦略　　2.2.1　テストの4象限　　2.2.2　テストピラミッド　　2.2.3　テスト戦略に関するADRガイドライン　2.3　コントラクトテスト　　2.3.1　コントラクトテストが望ましいことが多い理由　　2.3.2　コントラクトの実装方法　　2.3.3　ADRガイドライン：コントラクトテスト　2.4　コンポーネントテスト　　2.4.1　コントラクトテストとコンポーネントテストの比較　　2.4.2　ケーススタディ：コンポーネントテストによる動作確認　2.5　統合テスト　　2.5.1　スタブサーバの利用：理由と方法　　2.5.2　ADRガイドライン：統合テスト　　2.5.3　テストコンポーネントのコンテナ化：Testcontainers　　2.5.4　ケーススタディ：Testcontainersの適用による統合テスト　2.6　E2Eテスト　　2.6.1　E2Eテストの自動化　　2.6.2　E2Eテストの種類　　2.6.3　ADRガイドライン：E2Eテスト　2.7　まとめ
　3.1　APIゲートウェイは唯一のソリューションなのか？　3.2　ガイドライン：プロキシ・ロードバランサ・APIゲートウェイ　3.3　ケーススタディ：Attendeeサービスを利用者に公開する　3.4　APIゲートウェイとは？　3.5　APIゲートウェイはどのような機能を提供するのか？　3.6　APIゲートウェイはどこに配置されるべきか？　3.7　APIゲートウェイをエッジで他の技術と統合させる方法　3.8　なぜAPIゲートウェイを使うのか？　　3.8.1　疎結合を実現する：ファサード／アダプタ構成　　3.8.2　簡素化：バックエンドサービスの集約と変換　　3.8.3　APIを過剰利用や悪用から保護する：脅威の検知と緩和　　3.8.4　APIの利用状況を理解する：オブザーバビリティ　　3.8.5　APIを製品として管理する：APIライフサイクル管理　　3.8.6　APIの収益化：アカウント管理、課金、支払い　3.9　APIゲートウェイの近現代史　　3.9.1　1990年代以降：ハードウェアロードバランサ　　3.9.2　2000年代前半以降：ソフトウェアロードバランサ　　3.9.3　2000年代半ば：アプリケーションデリバリーコントローラ（ADC）　　3.9.4　2010年代前半：第一世代のAPIゲートウェイ　　3.9.5　2015年以降：第二世代のAPIゲートウェイ　3.10　APIゲートウェイの分類法　　3.10.1　従来の商用APIゲートウェイ　　3.10.2　マイクロサービスAPIゲートウェイ　　3.10.3　サービスメッシュゲートウェイ　　3.10.4　 APIゲートウェイの比較　3.11　ケーススタディ：APIゲートウェイを利用したカンファレンスシステムの進化　　3.11.1　KubernetesへのAmbassador Edge Stackのインストール　　3.11.2　URLパスからバックエンドサービスへのマッピングを構成する　　3.11.3　ホストベースルーティングを利用したマッピング設定　3.12　APIゲートウェイのデプロイ：失敗を理解し管理する　　3.12.1　APIゲートウェイが単一障害点になる場合　　3.12.2　問題の検知と認知　　3.12.3　インシデントと問題の解決　　3.12.4　リスク低減　3.13　APIゲートウェイ実装で陥りがちな落とし穴　　3.13.1　APIゲートウェイのループバック　　3.13.2　ESBとしてのAPIゲートウェイ　　3.13.3　“ずっと下まで亀（APIゲートウェイ）が続いているのよ”　3.14　APIゲートウェイの選択　　3.14.1　要求事項を特定する　　3.14.2　構築 vs. 購入　　3.14.3　ADRガイドライン：APIゲートウェイの選択　3.15　まとめ

　4.1　サービスメッシュは唯一の解決策なのか？　4.2　ガイドライン：サービスメッシュを導入すべきか？　4.3　ケーススタディ：講演機能のサービスへの抽出　4.4　サービスメッシュとは何か？　4.5　サービスメッシュはどのような機能を提供するか？　4.6　サービスメッシュはどこに展開されるか？　4.7　サービスメッシュは他のネットワーキング技術とどのように統合されるか？　4.8　なぜサービスメッシュを利用するのか？　　4.8.1　ルーティング、信頼性、およびトラフィック管理の細かな制御　　4.8.2　透過的なオブザーバビリティを提供する　　4.8.3　セキュリティの強制：トランスポート層のセキュリティ、認証・認可　　4.8.4　異なる言語間での機能横断的なコミュニケーションのサポート　　4.8.5　外部トラフィックと内部トラフィック管理の分離　4.9　サービスメッシュの進化　　4.9.1　初期の歴史と動機　　4.9.2　実装パターン　4.10　サービスメッシュの分類　4.11　ケーススタディ：ルーティング、オブザーバビリティ、セキュリティのためのサービスメッシュの利用134　　4.11.1　Istioを利用したルーティング　　4.11.2　Linkerdを利用した通信のオブザーバビリティ　　4.11.3　Consulを利用したネットワークセグメンテーション　4.12　サービスメッシュの展開：障害の理解と管理　　4.12.1　サービスメッシュが単一障害点になる場合　4.13　サービスメッシュ実装時における一般的課題　　4.13.1　サービスメッシュをESBとして利用する　　4.13.2　サービスメッシュをゲートウェイとして利用する　　4.13.3　多すぎるネットワークレイヤ　4.14　サービスメッシュの選択　　4.14.1　要件の特定　　4.14.2　構築 vs. 購入　　4.14.3　チェックリスト：サービスメッシュの選択　4.15　まとめ
　5.1　デプロイメントとリリースの分離　　5.1.1　ケーススタディ：フィーチャーフラグ　　5.1.2　トラフィック管理　5.2　ケーススタディ：カンファレンスシステムにおけるリリースのモデリング　　5.2.1　APIライフサイクル　　5.2.2　リリース戦略をライフサイクルにマッピングする　　5.2.3　ADRガイドライン：トラフィック管理とフィーチャーフラグを利用してリリースとデプロイメントを分離する　5.3　リリース戦略　　5.3.1　カナリアリリース　　5.3.2　トラフィックミラーリング　　5.3.3　ブルーグリーン戦略　5.4　ケーススタディ：Argo Rolloutsを利用したリリース　5.5　成功の監視と失敗の特定　　5.5.1　オブザーバビリティの三本柱　　5.5.2　APIにとって重要なメトリクス　　5.5.3　シグナルの読み取り　5.6　アプリケーションレイヤの考慮事項　　5.6.1　レスポンスキャッシュ　　5.6.2　アプリケーションレベルのヘッダ伝播　　5.6.3　デバッグを支援するためのログ記録　　5.6.4　提供価値を体現したプラットフォームの実現　　5.6.5　ADRガイドライン：提供価値を体現したプラットフォーム　5.7　まとめ
　6.1　ケーススタディ：Attendee APIにOWASPを適用する　6.2　外部APIを保護しないリスク　6.3　脅威モデリングの基礎　6.4　攻撃者のように考える　6.5　脅威モデリングの方法　　6.5.1　ステップ1：目標の特定　　6.5.2　ステップ2：適切な情報を収集する　　6.5.3　ステップ3：システムを分解する　　6.5.4　ステップ4：STRIDEを利用して脅威を特定する　　6.5.5　ステップ5：脅威のリスクを評価する　　6.5.6　ステップ6：検証　6.6　まとめ
　7.1　認証　　7.1.1　トークンを利用したエンドユーザ認証　　7.1.2　システム間の認証　　7.1.3　キーとユーザを混ぜてはいけない理由　7.2　OAuth2　　7.2.1　APIにおける認可サーバの役割　　7.2.2　JSON Web Tokens（JWT）　　7.2.3　OAuth2グラントの用語と仕組み　　7.2.4　ADRガイドライン：OAuth2の利用を検討すべきか？　　7.2.5　認可コードグラント　　7.2.6　リフレッシュトークン　　7.2.7　クライアント認証情報グラント　　7.2.8　追加のOAuth2グラント　　7.2.9　ADRガイドライン：サポートするOAuth2グラントの選択　　7.2.10　OAuth2のスコープ　　7.2.11　認可の強制　7.3　OIDCの導入　7.4　SAML 2.0　7.5　まとめ
　8.1　なぜシステムを進化させるためにAPIを利用するのか？　　8.1.1　有用な抽象化の作成：凝縮性の向上　　8.1.2　ドメイン境界を明確にする：疎結合の促進　8.2　ケーススタディ：利用者のドメイン境界の確立　8.3　最終アーキテクチャの選択肢　　8.3.1　モノリス（Monolith）　　8.3.2　サービス指向アーキテクチャ（SOA）　　8.3.3　マイクロサービス　　8.3.4　関数型アーキテクチャ　8.4　進化プロセスの管理　　8.4.1　目標を決定する　　8.4.2　適応度関数の利用　　8.4.3　システムをモジュールに分解する　　8.4.4　拡張のための“シーム”としてAPIを作成する　　8.4.5　システム内の変更レバレッジポイントの特定　　8.4.6　継続的なデリバリーと検証　8.5　進化するシステムのためのアーキテクチャパターン　　8.5.1　ストラングラーフィグ　　8.5.2　ファサード／アダプタ　　8.5.3　API Layer Cake　8.6　ペインポイントと機会の特定　　8.6.1　アップグレードとメンテナンスの問題　　8.6.2　パフォーマンスの問題　　8.6.3　依存関係の解消：密結合されたAPI　8.7　まとめ
　9.1　ケーススタディ：Attendeeサービスのクラウド移行　9.2　クラウド移行戦略の選択　　9.2.1　Retain or Revisit（保持・再検討）　　9.2.2　Rehost（再ホスティング）　　9.2.3　Replatform（再プラットフォーム）　　9.2.4　Repurchase（再購入）　　9.2.5　Refactor/Re-architect（リファクタリング／再設計）　　9.2.6　Retire（廃止）　9.3　ケーススタディ： Attendeeサービスの再プラットフォーム　9.4　API管理機能の役割　9.5　外部トラフィック vs. 内部トラフィック：トラフィック管理の境界をぼかす　　9.5.1　エッジから始めて内側に進む　　9.5.2　境界を越える：ネットワークを横断するルーティング　9.6　境界防御型アーキテクチャからゼロトラストアーキテクチャへ　　9.6.1　境界防御型アーキテクチャとは？　　9.6.2　だれも信頼せずに検証する　　9.6.3　ゼロトラストアーキテクチャにおけるサービスメッシュの役割　9.7　まとめ
　10.1　ケーススタディ：旅路の振り返り　10.2　API、コンウェイの法則、そして組織　10.3　意思決定のタイプの理解　10.4　将来に向けての準備　　10.4.1　非同期通信（Async Communication）　　10.4.2　HTTP/3　　10.4.3　プラットフォームベースのメッシュ　10.5　次のアクション：APIアーキテクチャについて学び続ける方法　　10.5.1　基本を絶え間なく磨く　　10.5.2　最新の業界ニュースをチェックする　　10.5.3　技術トレンドレポート　　10.5.4　ベストプラクティスとユースケースについて学ぶ　　10.5.5　実践で学ぶ　　10.5.6　教えることで学ぶ

Content preview from マスタリングAPIアーキテクチャ ―モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法

10章

総括

　本書を通じて、API設計から実装、セキュリティの確保、運用まで、あらゆる段階を網羅する旅路（ジャーニー）を歩んできました。本書はアーキテクチャに焦点を絞り検討していますが、同じくらい重要なのは、組織内でどのようにアーキテクチャを適用するかです。

　最後の章では、将来、より重要な役割を果たす可能性のある新しいAPI技術を探り、変化するベストプラクティス、ツール、プラットフォームにどのように追従していくかを学びます。

10.1　ケーススタディ：旅路の振り返り

　本書全体を通じて、カンファレンスシステムアーキテクチャのユースケースを更新し、成熟させるために、進化のステップを踏んできました。図10-1にその出発点を示します。

図10-1　オリジナルのカンファレンスシステムアーキテクチャを示すC4モデル（図0-2再掲）

　Attendeeサービスを抽出する際に行われた決定事項を見てみましょう。図10-2に示すように、私たちは（カンファレンスシステムのステークホルダーからの要件に基づいて）カンファレンス出席者を管理する機能をAPIサービスとして抽出し、レガシーカンファレンスシステムとは独立したプロセスとして実行することを決断しました。

図10-2　レガシーカンファレンスシステムからAttendeeサービスを抽出するC4モデル（図0-4再掲）