1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

30日間で理解する GCP for AWSエンジニア - 実践ブログシリーズ - 11日目: API GatewayとCloud Endpoints:API公開のベストプラクティス

1
Last updated at Posted at 2025-08-26

【AWS経験者向け】API GatewayとCloud Endpoints:API公開のベストプラクティス


はじめに:API公開のための「門番」

皆さん、こんにちは!「30日間でGCPをマスターするAWSエンジニアの挑戦」シリーズ、11日目へようこそ。

AWSでのAPI開発において、API Gatewayは欠かせないサービスです。HTTP/REST APIやWebSocket APIを構築し、バックエンドのLambda関数やEC2インスタンスにリクエストをルーティングするだけでなく、認証、スロットリング、キャッシュといった様々な機能を提供します。

GCPにも、同様の役割を担うサービス、Cloud Endpointsがあります。Cloud Endpointsは、API Gatewayと同様の機能を提供しますが、OpenAPI(旧Swagger)仕様との親和性が非常に高く、API開発をシンプルにするという設計思想を持っています。

この記事では、AWS API Gatewayの知識を前提に、GCP Cloud Endpointsの運用管理における以下のポイントを徹底的に比較し、理解を深めていきます:

  • サービス思想と開発スタイル:なぜGCPは「OpenAPI」にこだわるのか?
  • 認証・認可機能:IAM、Cognito、そしてAPIキーの比較
  • 料金体系:なぜGCPの方が料金が予測しやすいのか?

この記事を読めば、GCPでのAPI設計と公開が明確になり、より効率的なシステムを構築できるようになります。


サービス思想と開発スタイルの比較

API GatewayとCloud Endpointsは、API公開という共通の目的を持ちながらも、アプローチが根本的に異なります。

AWS API Gateway

API Gatewayは、AWSの各サービス(Lambda、EC2など)をバックエンドに統合することに重点を置いています。

  • 開発スタイル: コンソールやCLIでAPIのパス、HTTPメソッド、バックエンドの統合先を細かく設定します
  • 特徴: 非常に多機能で柔軟性が高い反面、設定が複雑になりがちです
  • 設定方法: GUIベース、CloudFormation、CDKなど複数の方法から選択可能

GCP Cloud Endpoints

Cloud Endpointsは、**OpenAPI(旧Swagger)**というAPI定義の標準仕様を徹底的に活用します。

  • 開発スタイル: openapi.yamlファイルでAPIのパス、メソッド、認証方法、APIキーの要件などを定義し、そのファイルをアップロードすることでAPIが自動的にプロビジョニングされます
  • 特徴: YAMLファイル一つでAPIの全体像を管理できるため、開発チーム内でのAPI仕様の共有やバージョン管理が容易になります
  • 設定方法: OpenAPI仕様ファイルを中心とした宣言的アプローチ

認証・認可機能の比較

項目 AWS API Gateway GCP Cloud Endpoints
主な認証プロバイダ AWS IAM、Amazon Cognito、Lambda Authorizer Google IAM、Firebase Auth、Auth0など
APIキー管理 Usage Plan、Quota、Throttling設定 APIキーの要件をOpenAPIファイルで定義
認証の実装 Cognitoユーザープールとの統合 Firebase AuthやIdentity Platformと統合
カスタム認証 Lambda Authorizerで柔軟にカスタマイズ 外部認証プロバイダーとの統合
特徴 AWSサービスとの豊富な統合 GCPの認証プロバイダとネイティブ統合

GCP Cloud Endpointsの認証実装例

GCP Cloud Endpointsでは、APIキーの使用要件をopenapi.yamlファイル内で直接定義できます:

securityDefinitions:
  api_key:
    type: "apiKey"
    name: "key"
    in: "query"
security:
  - api_key: []

これにより、APIのコードとセキュリティ要件を同時に管理でき、運用のシンプルさが向上します。


料金体系の詳細比較

API GatewayとCloud Endpointsの料金は、APIリクエスト数データ転送量で構成されますが、詳細な料金構造に違いがあります。

AWS API Gateway(東京リージョン)

  • REST API: $3.50/100万リクエスト
  • HTTP API: $1.00/100万リクエスト(より安価)
  • データ転送量: $0.114/GB(インターネットへ)
  • 追加機能: キャッシュ($0.02/時間〜)、カスタムドメイン(証明書管理含む)

GCP Cloud Endpoints(東京リージョン)

  • APIリクエスト数: 最初の200万リクエストは無料、以降は$3.00/100万リクエスト
  • データ転送量: $0.12/GB(インターネットへ)、リージョン内は無料
  • 追加機能: 基本的な監視・ロギング機能は無料

料金比較のポイント

  1. 無料利用枠: GCPは毎月200万リクエストまで無料で、スタートアップや開発環境に有利
  2. 従量課金: 大規模になるとAWSのHTTP APIが最安値
  3. データ転送: GCPの方がやや高めだが、リージョン内通信は無料

実践ハンズオン:GCPでAPIを公開する

openapi.yamlファイルを使って、API GatewayよりもシンプルにAPIを公開する手順を見ていきましょう。

1. 事前準備

# 必要なAPIを有効化
gcloud services enable endpoints.googleapis.com
gcloud services enable servicemanagement.googleapis.com
gcloud services enable servicecontrol.googleapis.com

# プロジェクトIDを確認
export PROJECT_ID=$(gcloud config get-value project)

2. バックエンドのCloud Function作成

// index.js
exports.helloHttp = (req, res) => {
  res.set('Access-Control-Allow-Origin', '*');
  res.json({
    message: 'Hello from Cloud Endpoints!',
    timestamp: new Date().toISOString()
  });
};
# Cloud Functionをデプロイ
gcloud functions deploy helloHttp \
  --runtime nodejs18 \
  --trigger-http \
  --allow-unauthenticated \
  --region asia-northeast1

3. OpenAPIファイルの作成(openapi.yaml)

swagger: '2.0'
info:
  title: My Simple API
  description: A simple API on Cloud Endpoints with authentication
  version: 1.0.0
host: my-api.endpoints.${PROJECT_ID}.cloud.goog
x-google-backend:
  address: https://asia-northeast1-${PROJECT_ID}.cloudfunctions.net/helloHttp
  protocol: h2
schemes:
  - https
produces:
  - application/json
paths:
  /hello:
    get:
      summary: Hello Endpoint
      operationId: hello
      security:
        - api_key: []
      responses:
        200:
          description: Successfully returned a greeting
          schema:
            type: object
            properties:
              message:
                type: string
              timestamp:
                type: string
        401:
          description: Unauthorized
securityDefinitions:
  api_key:
    type: apiKey
    name: key
    in: query

4. Cloud Endpointsにデプロイ

# PROJECT_IDを置換してからデプロイ
envsubst < openapi.yaml | gcloud endpoints services deploy -

# デプロイ状況の確認
gcloud endpoints services list

5. APIキーの作成とテスト

# APIキーを作成
gcloud alpha services api-keys create --display-name="My API Key"

# 作成されたAPIキーを取得
API_KEY=$(gcloud alpha services api-keys list --format="value(name)" --filter="displayName:'My API Key'")
KEY_STRING=$(gcloud alpha services api-keys get-key-string $API_KEY --format="value(keyString)")

# APIをテスト
curl "https://my-api.endpoints.${PROJECT_ID}.cloud.goog/hello?key=${KEY_STRING}"

監視とロギング

GCP Cloud Endpointsでは、Cloud MonitoringとCloud Loggingが自動的に統合されます。

主要なメトリクス

  • リクエスト数とレスポンス時間
  • エラー率とステータスコード分布
  • API利用者ごとの使用量(APIキーベース)

ログの確認方法

# エンドポイントのログを確認
gcloud logging read "resource.type=api AND protoPayload.serviceName=my-api.endpoints.${PROJECT_ID}.cloud.goog" --limit=10

本番運用時の考慮事項

セキュリティのベストプラクティス

  1. APIキーの管理: 定期的なローテーションとスコープの制限
  2. CORS設定: 適切なオリジン制限の設定
  3. Rate Limiting: 過度なリクエストからの保護

パフォーマンス最適化

  1. レスポンスキャッシュ: 静的なデータは積極的にキャッシュ
  2. バックエンドの最適化: Cloud Functionのメモリ設定調整
  3. CDN連携: Cloud CDNとの組み合わせでレスポンス速度向上

まとめ:API GatewayとCloud Endpoints、選択のポイント

今回は、API公開のマネージドサービスであるAPI GatewayとCloud Endpointsを、思想、機能、料金の観点から比較しました。

項目 AWS API Gateway GCP Cloud Endpoints
設計思想 多機能性、柔軟性重視 OpenAPIベースのシンプルさ
開発スタイル GUI/CLIでの詳細設定 openapi.yamlでの宣言的管理
料金 従量課金(HTTP APIは安価) 200万リクエスト/月まで無料
学習コスト 高い(多機能ゆえの複雑さ) 低い(標準仕様ベース)
エコシステム AWSサービスとの豊富な統合 Google Cloudサービスとの統合

選択の指針

Cloud Endpointsが適している場合

  • OpenAPI仕様でAPI設計を標準化したい
  • シンプルなAPI公開で十分
  • 開発・テスト環境でコストを抑えたい
  • チーム内でAPI仕様の共有・管理を重視

API Gatewayが適している場合

  • 複雑な認証・認可ロジックが必要
  • WebSocketやカスタマイズが重要
  • 既存のAWSエコシステムとの統合が前提

GCP Cloud Endpointsは、特にAPI-First開発を採用するチームや、OpenAPI標準に準拠したドキュメント化されたAPIを構築したい場合に非常に強力な選択肢となります。


次回は、いよいよGCPの独自サービス、Cloud Runを試してみます。コンテナをサーバーレスに動かすという、これまでのAWSにはない新しい概念に触れ、その便利さを体験しましょう。お楽しみに!

この記事が役に立ったという方は、ぜひ「いいね」や「ストック」をお願いします!

シリーズ記事一覧

  • [【1日目】はじめの一歩!AWSエンジニアがGCPで最初にやるべきこと]
  • [【2日目】GCPのIAMはAWSとどう違う?「プリンシパル」と「ロール」の理解]
  • [【3日目】VPCとVPCネットワーク:GCPのネットワーク設計思想を理解する]
  • [【4日目】S3とCloud Storage:オブジェクトストレージを徹底比較]
  • [【5日目】RDSとCloud SQL:マネージドデータベースの運用管理の違い]
  • [【6日目】EC2とCompute Engine:インスタンスの起動から課金モデルまで]
  • [【7日目】1週間のまとめ:AWSとGCP、それぞれの得意なことと設計思想]
  • [【8日目】EKSとGKE:Kubernetesのマネージドサービスを比較体験!]
  • [【9日目】Dockerイメージをどこに置く?ECRとArtifact Registryを比較]
  • [【10日目】LambdaとCloud Functions:イベント駆動型サーバーレスの実装]
  • [【11日目】API GatewayとCloud Endpoints:API公開のベストプラクティス](この記事)
  • [【12日目】Cloud Run:サーバーレスでコンテナを動かすGCPの独自サービスを試してみよう]
1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?