Apigee API Management

解決する課題

• 多数の API を全社共通の流儀で公開・認可・流量制御し、入口を一元管理したい
• 社外・パートナー向けに API を製品（プロダクト）として提供し、利用申請・キー発行・利用状況の可視化までセルフサービス化したい
• 既存のバックエンドに手を入れずに、変換・キャッシュ・認可・脅威防御などの横断機能をプロキシ層で追加したい
• API の**バージョン管理・段階的リリース・廃止（デプリケーション）**といったライフサイクルを統制したい
• API 利用を**収益化（マネタイゼーション）**し、レート制限とクォータで品質を担保したい

主要概念と用語

• API プロキシ: クライアントとバックエンド（ターゲット）の間に立つ仮想的な API。Apigee が公開するのはこのプロキシで、実体のバックエンドは隠蔽される
• ProxyEndpoint と TargetEndpoint: プロキシは入口側のリクエスト処理（ProxyEndpoint）と、出口側のバックエンド接続（TargetEndpoint）の2段で構成される
• ポリシー: プロキシのフローに差し込む処理部品。認証、Quota（クォータ）、Spike Arrest（瞬間流量の平準化）、OAuth トークン発行、JSON とXML の変換、キャッシュ、メッセージ脅威防御などを宣言的に設定する
• フロー: リクエストとレスポンスがポリシーを順番に通過するパイプライン。条件分岐で特定の経路だけにポリシーを適用できる
• プロダクト（API プロダクト）: 複数の API プロキシをまとめ、アクセス範囲やレート上限を束ねた公開単位。開発者にはこのプロダクト単位で API を提供する
• 開発者ポータル: API 利用者が登録し、アプリを作成し、APIキーを発行し、ドキュメントを閲覧できるセルフサービスのサイト
• Environment と Environment Group: プロキシのデプロイ先（test や prod など）と、それらにホスト名を割り当てる単位
• マネタイゼーション: 利用量に応じた課金プランを設定し、API を収益化する機能

仕様・制限・クォータ

• Apigee は本格的な API 管理基盤で、プロビジョニングして使う。提供形態として、Google 管理のホスト型と、自社環境寄りのApigee hybrid（コントロールプレーンは Google、ランタイムは自前の Kubernetes）がある
• 課金には従量課金（Pay-as-you-go）とサブスクリプションの体系があり、規模やSLA要件に応じて選ぶ。小さく始めるなら従量課金、大規模・エンタープライズ用途はサブスクリプションが一般的
• プロキシのデプロイは Environment 単位で行い、リビジョンを切り替えて段階的にリリース・ロールバックできる
• 各種クォータ（プロキシ数、Environment 数、リクエストレートなど）は提供形態やプランに依存する。具体的な数値は変動しうるため、公式ドキュメントで最新値を確認する
• ポリシーの種類や設定可能なフロー段は豊富だが、過剰なポリシー連結はレイテンシ増につながるため必要最小限にとどめる

内部の仕組み

クライアントからのリクエストは、まず Apigee の**ランタイム（メッセージプロセッサ）**が受け取り、API プロキシのフローに沿って一連のポリシーを順に適用します。入口側の ProxyEndpoint で認証・流量制御・変換を行い、TargetEndpoint からバックエンドへ転送し、レスポンスにも同様にポリシーを適用してからクライアントへ返します。

• 設定や分析データを司るコントロールプレーンと、実際にトラフィックを処理する**ランタイム（データプレーン）**が分離している
• ポリシーは宣言的に定義され、フローのどの段に差し込むかを指定できる。これによりバックエンドのコードを変えずに横断的な機能を追加できる
• リクエスト・レスポンスのメトリクスはAnalyticsに集約され、トラフィック量・レイテンシ・エラー率・デベロッパー別利用などを後から分析できる
• バックエンドへの接続では、相互TLSやサービスアカウントによる認証を用いて安全に呼び出す

設計パターン / ベストプラクティス

• 認証・認可・流量制御をプロキシ層に集約し、バックエンドは業務ロジックに専念させる
• 外部アプリの識別にはAPIキー、利用者認可にはOAuth 2.0 / JWTを使い分ける
• 瞬間的なバーストにはSpike Arrestで平準化し、契約上の上限はQuotaで管理する、という役割分担を徹底する
• 公開はプロダクト単位で設計し、社内向け・パートナー向け・公開向けでアクセス範囲とレート上限を分ける
• Environment を test と prod に分け、リビジョンの段階的デプロイとロールバックでリスクを抑える
• バックエンドの所在やスキーマ変更はプロキシで吸収し、利用者に影響を与えずに内部を進化させる

運用・監視

• Analytics ダッシュボードでトラフィック・エラー・レイテンシ・デベロッパー別利用を継続的に観察する
• メトリクスとログは Cloud Monitoring / Cloud Logging とも連携でき、しきい値超過時のアラートを設定する
• レート制限超過は**429（Too Many Requests）**として返るため、Quota や Spike Arrest の設定値を見直す
• 認証エラー（401 / 403）は、APIキーの有効状態、OAuth トークンや JWT の発行者・有効期限、プロダクトのアクセス範囲を点検する
• プロキシの不具合切り分けには**トレース（デバッグセッション）**を使い、どのポリシー段で想定外の挙動が起きたかを段ごとに確認する

コスト

Apigee は本格的な API 管理基盤のため、軽量な API Gateway とは価格帯が大きく異なります。利用規模とSLA要件に応じて課金体系を選び、コストを最適化します。

セキュリティ

• APIキーで呼び出し元アプリを識別し、OAuth 2.0 / JWTで利用者の認可を行う
• Spike Arrest と Quotaで流量を制御し、過負荷や乱用からバックエンドを守る
• メッセージ脅威防御ポリシーで、過大なペイロードや不正な構造のリクエストを入口で弾く
• 通信はTLSで保護し、バックエンドへの接続も相互TLSやサービスアカウントで認証する
• 前段にグローバル配信やWAFが必要な場合は、外部ロードバランサと Cloud Armor を併用してDDoS緩和やIP制限を加える

Well-Architected の観点

• 運用上の優秀性（operational）: API のライフサイクル（バージョン管理・段階リリース・廃止）をプロダクトと Environment で統制でき、Analytics で利用実態を把握して継続的に改善できる
• セキュリティ（security）: 認証・認可・流量制御・脅威防御をプロキシ層に集約し、バックエンドを直接公開せずに守れる。横断的なセキュリティ方針を全 API に一貫して適用できる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 前提: gcloud にログイン済みで、対象プロジェクトに Apigee が有効化されていること

# 1) 組織（Apigee の最上位コンテナ）の一覧を確認
gcloud apigee organizations list

# 2) Environment（デプロイ先）の一覧を確認
gcloud apigee environments list --organization=ORG_NAME

# 3) API プロキシを作成（バンドル zip から登録）
gcloud apigee apis create orders-proxy \
  --organization=ORG_NAME \
  --bundle-source=orders-proxy.zip

# 4) 作成したプロキシのリビジョンを prod 環境へデプロイ
gcloud apigee apis deploy \
  --organization=ORG_NAME \
  --environment=prod \
  --api=orders-proxy \
  --revision=1

# 5) デプロイ状況を確認
gcloud apigee deployments list \
  --organization=ORG_NAME \
  --environment=prod