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アーキテクチャ ―モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法

はじめに

本書を執筆した理由

　2020年初頭、私たちはニューヨークで開催されたO'Reilly Software Architectureに参加しました。そこでは、JimとMattがAPIに関するワークショップとAPIゲートウェイに関するプレゼンテーションを行っていました。JimとDanielはLondon Java Communityで知り合った間柄で、多くのアーキテクチャのイベントと同様、APIアーキテクチャに関する考え方や理解について話すために集まっていました。私たちが廊下で話していると、何人かのカンファレンス出席者が私たちのところにやってきて、APIに関する経験について議論を始めました。みんな、APIについて私たちの考えやガイダンスを求めていました。このとき、APIをトピックにした本を書けば、カンファレンスでの議論を他のアーキテクトと共有できると考えたのです。

本書を読むべき理由

　本書は、APIアーキテクチャの設計、運用、進化に関する全体像を提供するように設計しています。私たちは、解説パートと、カンファレンス出席者が講演を閲覧・予約する実際のカンファレンスシステムを模倣したケーススタディの両方を通して、私たちの経験とアドバイスを共有しています。このケーススタディは、抽象的なコンセプトがどのように実践的応用に結びつくかを探ることを目的として、本書全体を通して説明されています。ケーススタディの進化の概要を知りたい方は、10章を参照してください。

　私たちはまた、自らが決断できるようにすることも大切だと考えています。これをサポートするために、私たちは次のことを行いました。