OCI API Gateway

解決する課題

• API 用のサーバーを自前で運用したくない（フルマネージドで自動スケール）
• 認証・レート制限・CORS を共通の玄関で処理したい
• OCI Functions や内部 HTTP サービスを安全に公開したい
• パブリック／プライベートの両方のエンドポイントを使い分けたい

主要概念と用語

• ゲートウェイ（Gateway）: リクエストを受ける実体。VCN のサブネットに配置し、パブリックまたはプライベートのエンドポイントを持つ。配置サブネットのセキュリティリストに加え、ゲートウェイには**ネットワークセキュリティグループ（NSG）**を関連付けられる
• デプロイメント（Deployment）: 1 つのゲートウェイ上に、特定のパスプレフィックス（例 /v1）で公開する API 定義。ルート・ポリシー・バックエンドをまとめた単位
• ルート（Route）: パス（例 /orders）と HTTP メソッドの組み合わせに対し、どのバックエンドへ流すかを定義
• バックエンド（Backend）: ルートの転送先。OCI Functions / HTTP（URL）/ Stock Response（固定応答） の 3 種類
• API デプロイメント仕様（Specification）: ルート・リクエスト/レスポンスポリシーを記述した JSON。コンソール、CLI、または OpenAPI（Resource Manager 経由） で定義
• リクエストポリシー / ルートポリシー: 認証（Authentication）、CORS、レートリミット、変換、ヘッダー検証など、ゲートウェイ全体（デプロイメント単位）またはルート単位で適用する処理
• オーソライザー（Authorizer）: JWT 検証（IDCS / OAuth IdP の発行トークン）または OCI Functions による独自認可で認証を玄関に集約
• 使用量プラン（Usage Plan）/ APIキー（クライアント）/ サブスクライバー: クライアントごとの流量管理と利用可否を制御

仕様・制限・クォータ

• フルマネージドで自動スケール。サーバー台数の管理は不要
• 1 ゲートウェイあたりのデプロイメント数、デプロイメントあたりのルート数などにサービスリミットがある（テナンシ／リージョンごとに上限が設定され、引き上げ申請が可能）
• ゲートウェイは特定リージョンのサブネットに紐づくリージョナルなリソース。複数 AD（可用性ドメイン）にまたがり冗長化される
• TLS 終端はゲートウェイで実施。パブリックエンドポイントには**カスタムドメイン＋証明書（Certificates サービス）**を関連付け可能
• レートリミットはデプロイメント単位で「秒あたりリクエスト数」と、PER_CLIENT（クライアント単位）/ TOTAL（全体）の単位を指定できる
• リクエスト/レスポンスのペイロードサイズやタイムアウトに上限がある（バックエンド応答待ちのタイムアウト等）

内部の仕組み

クライアント → API Gateway → バックエンド、という流れで、玄関で認証（オーソライザー）→ 流量制限（レートリミット）→ CORS / ヘッダー検証 → ルーティングを順に適用し、最終的に OCI Functions / HTTP バックエンド / 固定応答へ転送します。

ゲートウェイは VCN 内のサブネットにデプロイされるため、プライベートエンドポイントにすれば VCN 内部や FastConnect / VPN 経由のクライアントだけに公開でき、パブリックエンドポイントにすればインターネットからアクセスできます。バックエンドがプライベートサブネットのロードバランサや内部 HTTP サービスでも、ゲートウェイが同じ VCN に居るため到達できます。

リクエストポリシーはデプロイメント全体に効くもの（認証、全体 CORS、相互 TLS など）と、ルート単位で効くもの（個別の認可・変換・レートリミット）があり、両者を組み合わせて段階的に制御します。

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

• API Gateway + OCI Functions でサーバーレス API（AWS の API Gateway + Lambda 相当）
• JWT オーソライザーで IDCS（Oracle Identity Cloud Service）や外部 OAuth IdP の発行トークンを玄関で検証し、認証を集約
• レートリミット（PER_CLIENT） と使用量プランで乱用防止・利用者ごとの流量管理
• 前段やバックエンド側に Web Application Firewall（OCI WAF） を併用して L7 防御
• バックエンドをプライベートサブネットのロードバランサにして、サービス本体を直接公開しない
• デプロイメント仕様を OpenAPI ＋ Resource Manager（Terraform） で IaC 管理し、ステージ相当を**別デプロイメント（パスプレフィックス）**で表現

運用・監視・トラブルシュート

• Monitoring（メトリクス）: HttpResponses（ステータス別件数）、Latency、BackendHttpResponses、BytesSent などを名前空間 oci_apigateway で確認
• アクセスログ / 実行ログ: OCI Logging サービスへ出力（デプロイメント単位で有効化）。401/403 は認証ポリシー、429 はレートリミット超過を確認
• Service Connector Hub でログを Object Storage / Streaming / Functions へ転送し、長期保管や分析に回す
• 5xx 多発時はバックエンド（Functions のコールドスタート・タイムアウト、HTTP バックエンドの到達性／NSG）を切り分け

コスト

OCI API Gateway はゲートウェイ単位の時間課金とAPI コール数に基づく従量課金です。バックエンド（Functions やロードバランサ）の料金は別計上になります。

セキュリティ

• オーソライザー: JWT 検証（発行者・対象・署名鍵を検証）または OCI Functions オーソライザーで独自認可。認証を玄関に集約
• IAM ポリシー: ゲートウェイが Functions を呼ぶ・Certificates を読む等は、動的グループ＋ポリシーで最小権限付与（資格情報のハードコード不要）
• mTLS（相互 TLS）: クライアント証明書を要求してデバイス／サービス間を相互認証
• ネットワーク分離: プライベートエンドポイント＋NSG／セキュリティリストでアクセス元を限定。バックエンドはプライベートサブネットへ
• TLS / カスタムドメイン: Certificates サービスの証明書で HTTPS を終端、レートリミットで乱用防止、必要に応じて WAF を併用

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# 1. ゲートウェイを作成（パブリックエンドポイント、指定サブネットに配置）
oci api-gateway gateway create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --display-name orders-gw \
  --endpoint-type PUBLIC \
  --subnet-id "ocid1.subnet.oc1.ap-tokyo-1.xxxx"

# 2. デプロイメント仕様（ルート＋バックエンド）を JSON で用意
cat > spec.json <<'JSON'
{
  "routes": [
    {
      "path": "/orders",
      "methods": ["GET", "POST"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.ap-tokyo-1.xxxx"
      }
    }
  ]
}
JSON

# 3. デプロイメントを作成（パスプレフィックス /v1 で公開）
oci api-gateway deployment create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --display-name orders-v1 \
  --gateway-id "ocid1.apigateway.oc1.ap-tokyo-1.xxxx" \
  --path-prefix /v1 \
  --specification file://spec.json

# 4. ゲートウェイとデプロイメントを一覧で確認
oci api-gateway gateway list \
  --compartment-id "ocid1.compartment.oc1..xxxx" --output table
oci api-gateway deployment list \
  --compartment-id "ocid1.compartment.oc1..xxxx" --output table