API Gatewayは、利用者側のアプリケーションと、処理を担当するAPIの間に置く入口です。要求を適切なサービスへ転送し、認証や流量制御などの共通処理をまとめるために使います。ただし、導入しただけで業務上の権限判断や障害対策がすべて完了するわけではありません。
この記事では、APIを公開・運用する担当者に向けて、入口に集める処理とアプリケーション側に残す責任を整理します。
API Gatewayは複数APIへの入口になる
Microsoftのアーキテクチャ資料では、API Gatewayをクライアントとアプリケーションサービスの間に置く集約された入口として説明しています。リバースプロキシとして要求を適切なサービスへ転送し、認証、TLSの終端、流量制限などを担う構成が示されています。Microsoft「API gateways」
たとえば、商品検索、注文、配送状況を別々のサービスが提供しているとします。利用側へ内部の接続先を個別に伝える代わりに、入口で要求先を振り分ける構成を検討できます。これは説明用の例で、すべてのAPIを一つの入口へ集めることを推奨するものではありません。
「API Gateway」は役割の名称としても製品名としても使われます。Amazon API Gatewayは、REST、HTTP、WebSocket APIの作成・公開・管理などを扱うAWSのサービスです。一般的な役割と、特定製品の対応機能は区別して読んでください。AWS「What is Amazon API Gateway?」
入口に集める処理と業務側に残す判断
設計では、「入口で確認済み」という一言で済ませず、何を確認するのかを分けます。次は責任分担を相談するための整理例です。
| 確認したいこと | 入口で検討する処理 | 業務側で確認すること |
|---|---|---|
| 誰からの要求か | 認証情報の検証 | その利用者が対象の注文を見てよいか |
| どこへ転送するか | パスなどによる転送先選択 | 対象業務の処理とデータ整合 |
| 要求が多すぎないか | 利用者・APIなどの単位で制限 | 業務処理の容量や同時更新の制約 |
| 失敗をどう追うか | 入口の受付・転送記録 | 処理結果とデータ変更の記録 |
本人と確認できることと、その操作を許可してよいことは別の問いです。入口と業務側のどちらが判定する場合でも、対象データや操作に必要な条件を具体化します。この表は設計の検討案で、製品共通の必須構成ではありません。
一つの要求を最後まで追う
架空の注文照会を例にします。利用者が照会を送り、入口が認証情報を確認し、注文サービスへ転送する。その先で、注文サービスが対象注文へのアクセス可否を判断し、結果を返す流れです。
この経路で、認証失敗、対象なし、業務側の処理失敗を別々に試すと、どこで拒否され、利用者へ何が返るかを確認できます。入口のログだけで「注文を表示できた」と判定せず、業務側の結果と対応づけます。
APIそのものの操作・入力・応答を整理する方法は、API設計の進め方を参照してください。本稿の対象は、そのAPIを受け付ける入口の分担です。
停止や設定変更の影響を確かめる
入口の設定を変えたとき、どのAPIに影響するかを確認します。共有する経路が増えるほど、一つの設定変更を複数の利用側で確認する必要があるかもしれません。
設計時には、入口へ到達できない場合、業務側が応答しない場合、入口が要求を制限した場合を分けて記録します。再試行が必要な処理では、同じ操作を重複実行してよいかも業務側と合わせます。
Microsoftの資料も、機能の対応差や、ルーティング・証明書・セキュリティ設定の変更管理を選定上の確認事項に挙げています。製品名だけで要件を満たすと判断せず、使う機能と運用責任を照合しましょう。
導入前に責任と確認方法をそろえる
まず、公開する一つのAPIについて、入口の処理、業務側の処理、失敗時に見る記録、設定を変更する担当を一枚にします。共通化によって減らせる作業と、新しく必要になる運用の両方を確認できます。
全機能を最初から入口へ移す必要はありません。利用側との約束を保ちながら、責任が明確になる範囲から検討してください。利用者へ伝える仕様の整理にはAPI設計書の書き方、構成・運用の相談にはインフラ・クラウド技術支援をご利用いただけます。