APIゲートウェイ
An API Gateway acts as a single entry point for clients accessing multiple backend microservices, handling requests, routing them to appropriate services, an...
APIゲートウェイは、バックエンドサービスへのすべてのクライアント要求のエントリポイントとして機能するサーバーです。クライアントアプリケーションとマイクロサービスまたはモノリシックバックエンドの間に配置され、基盤となるアーキテクチャを抽象化し、クライアントの対話を簡素化します。APIゲートウェイの主な機能には、リクエストルーティング、リクエスト/レスポンス変換、認証と認可、レート制限、キャッシング、ロギング、モニタリングが含まれます。これらの横断的な懸念事項を一元化することにより、ゲートウェイは複数のバックエンドサービスにわたって重複するのを防ぎ、よりクリーンで保守性の高いコードにつながります。リクエストルーティングは、リクエストパス、ヘッダー、またはその他の基準に基づいて、適切なバックエンドサービスに着信APIコールを送信します。変換により、ゲートウェイはリクエストまたはレスポンスを変更できます。たとえば、データ形式を変更したり（例：XMLからJSONへ）、複数のサービスからデータを集約したりします。セキュリティは重要な側面です。ゲートウェイは、認証（クライアントのIDを確認する）と認可（クライアントが要求されたリソースにアクセスする権限があるかどうかを判断する）を処理でき、多くの場合、IDプロバイダーまたはトークン検証サービスと統合されます。レート制限は、過剰なリクエストからバックエンドサービスを保護し、キャッシングは頻繁に要求されるデータをゲートウェイから直接提供することでパフォーマンスを向上させることができます。このアーキテクチャパターンは、多数の分散サービスを管理する複雑さを管理するのに役立つマイクロサービスアーキテクチャで特に普及しています。
graph LR
Center["APIゲートウェイ"]:::main
Rel_api_development["api-development"]:::related -.-> Center
click Rel_api_development "/terms/api-development"
Rel_microservices["microservices"]:::related -.-> Center
click Rel_microservices "/terms/microservices"
Rel_load_balancer["load-balancer"]:::related -.-> Center
click Rel_load_balancer "/terms/load-balancer"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 5歳でもわかるように説明
[API](/ja/terms/api)ゲートウェイは、大きなオフィスビルの親切な受付係のようなものです。訪問者（アプリのリクエスト）を適切な部署（バックエンドサービス）に案内し、許可された人だけが入れるようにします。訪問者は内部のレイアウトを知る必要はありません。
🤓 Expert Deep Dive
APIゲートウェイパターンは、クライアントに単一の統合されたインターフェイスを提供することにより、特にマイクロサービスなどの分散システムの管理の課題に対処します。主なアーキテクチャ上の考慮事項には、集中型ゲートウェイ（単一のエントリポイント）と分散型（サービスごとまたはドメインごとのゲートウェイ）のどちらを選択するかです。集中型ゲートウェイはクライアントの対話を簡素化し、一貫したポリシーを強制しますが、ボトルネックや単一障害点になる可能性があります。分散型ゲートウェイは、スケーラビリティと障害分離を向上させますが、ポリシーの重複につながる可能性があります。一般的な実装パターンには、Backend For Frontend（BFF）パターンがあり、特定のクライアントタイプ（例：モバイル、Web）の特定のニーズに対応する特殊化されたゲートウェイがあります。プロトコル変換（例：RESTからgRPCへ）やリクエスト集約におけるゲートウェイの役割は、クライアントをバックエンドサービスの進化から切り離すために重要です。パフォーマンスへの影響は、追加のネットワークホップと処理オーバーヘッドから生じるため、効率的なルーティング、キャッシング、および非同期処理が必要になります。ゲートウェイレベルでのセキュリティ強制（JWT検証やOAuth 2.0トークンイントロスペクションなど）は、重要なセキュリティベストプラクティスです。