APIゲートウェイ

APIゲートウェイとは

API ゲートウェイは、クライアントと複数のバックエンド API の間に立つ唯一の入り口(玄関口)となるコンポーネントです。クライアントは個々のサービスの場所を知らなくても、ゲートウェイに向けてリクエストを送るだけで済みます。

クライアント → APIゲートウェイ → ユーザーサービス
                              → 商品サービス
                              → 注文サービス

[[マイクロサービス]] のようにバックエンドが多数のサービスに分かれている構成で、特に重要な役割を果たします。

何を一括で担うのか

各サービスに同じ処理を重複して実装する代わりに、ゲートウェイが横断的な関心事(どのAPIにも共通して必要な処理)を一手に引き受けます。

リバースプロキシとの違い

「手前に立って転送する」という点で [[リバースプロキシ]] と似ていますが、守備範囲が異なります。

• リバースプロキシは HTTP レベルの転送・キャッシュ・負荷分散が中心
• APIゲートウェイはそれに加えて、認証・レート制限・API キー管理など API 運用に特化した機能を持つ

実際には「API ゲートウェイはリバースプロキシの発展形」と捉えると理解しやすいです。負荷分散が主目的なら [[ロードバランサ]] を使います。

初学者向けポイント

• 代表的な製品・サービスに Amazon API Gateway、Kong、Apigee などがあります
• ゲートウェイは全リクエストが通る場所なので、ここが落ちると全サービスに影響する単一障害点になり得ます — [[高可用性設計]] の冗長化が前提です
• 小規模なシステムでは必須ではありません。サービス数が増え、認証やレート制限を共通化したくなったときに導入を検討します

関連技術とのつながり

• [[マイクロサービス]] — 多数のサービスの入り口を束ねるのがゲートウェイの主用途
• [[REST API]] — ゲートウェイが転送・保護する対象
• [[レートリミット]] — ゲートウェイの代表的な共通機能
• [[リバースプロキシ]] — 技術的な土台。API 特化機能の有無が違い

Q: APIゲートウェイの役割として正しいのはどれ?
- [x] 複数のAPIへの入り口を1つにまとめ、共通処理を一括で担う
- [ ] データベースのテーブルを正規化する
- [ ] クライアントのHTML描画を高速化する
解説: API ゲートウェイはクライアントと複数サービスの間に立つ唯一の入り口で、認証などの共通処理を引き受けます。

Q: APIゲートウェイが一括で担う処理の例として本文で挙げられているのはどれ?
- [ ] ソースコードのコンパイル
- [x] 認証・認可やレート制限
- [ ] OSのメモリ管理
解説: 認証・認可、レート制限、ログ収集などの横断的な関心事を入り口で一括処理します。

Q: APIゲートウェイ運用上の注意点として正しいのはどれ?
- [ ] キャッシュが効かないのでレスポンスが必ず遅くなる
- [ ] 各サービスに同じ認証処理を重複実装する必要がある
- [x] 全リクエストが通るため単一障害点になり得る — 冗長化が前提
解説: ゲートウェイが落ちると全サービスに影響するため、冗長化して単一障害点にしない設計が必要です。