APIゲートウェイとは？APIへのフロントドア

APIゲートウェイは、サービスの前に立つ単一のフロントドアであり、トラフィックがbackendに到達する前にリクエストをルーティングし、認証を適用し、レート制限などのポリシーを適用します。

多くのbackendサービスを直接公開する代わりに、チームはAPIゲートウェイを前面に配置します。クライアントに単一のアドレスを提供し、認証やthrottlingといった横断的関心事を処理し、各リクエストを正しいサービスへルーティングします。pipelineはゲートウェイへのdeployと、ゲートウェイ経由でのAPI呼び出しの両方を行います。

1つのエントリポイント、多数のbackend

クライアントはゲートウェイを呼び出し、ゲートウェイはpathやhostを検査して正しいupstreamサービスへ転送します。これによりクライアントは内部のサービス構成から切り離され、呼び出し側を壊すことなくbackendを変更できます。

横断的関心事

認証とtokenの検証。
レート制限とクォータの適用。
リクエストとレスポンスの変換。
logging、metrics、tracing。

ルーティングルール

ゲートウェイはpath、header、バージョンによってルートをbackendにマッピングします。deployでは、たとえばルートを新しいサービスバージョンに向けたり、canaryの分割を追加したりするために、これらのルールを更新することがよくあります。

deployにおけるゲートウェイ

新しいAPIバージョンをリリースするには、通常、トラフィックがそこへ流れるようゲートウェイの設定を更新する必要があります。ルートの設定ミスは、backend自体が正常であっても404や502を返すことがあります。

ゲートウェイでのレート制限

ゲートウェイがクォータを適用するため、pipelineの呼び出しが急増すると、backendに到達する前にそこで429を受け取ることがあります。呼び出しを分散させるか、retry-afterヘッダーを尊重することで制限に達するのを避けられます。

ゲートウェイを介した一時的なエラー

upstreamの再起動中にゲートウェイが502や503を返すのは、通常一時的なものです。Latchkeyのrunnerは、一般的なendpointへのゲートウェイの一時的なレスポンスを自動的にretryします。一方、不正なルートによる永続的な404は、修正すべき設定エラーです。

重要なポイント

APIゲートウェイは、APIトラフィックをルーティングしポリシーを適用する単一のフロントドアです。
多数のbackendに対して認証、レート制限、可観測性を一元化します。
backendが正常であっても、不正なルートは404や502を引き起こします。