【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(インターネットへ)、リージョン内は無料
- 追加機能: 基本的な監視・ロギング機能は無料
料金比較のポイント
- 無料利用枠: GCPは毎月200万リクエストまで無料で、スタートアップや開発環境に有利
- 従量課金: 大規模になるとAWSのHTTP APIが最安値
- データ転送: 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
本番運用時の考慮事項
セキュリティのベストプラクティス
- APIキーの管理: 定期的なローテーションとスコープの制限
- CORS設定: 適切なオリジン制限の設定
- Rate Limiting: 過度なリクエストからの保護
パフォーマンス最適化
- レスポンスキャッシュ: 静的なデータは積極的にキャッシュ
- バックエンドの最適化: Cloud Functionのメモリ設定調整
- 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の独自サービスを試してみよう]