一般的なユースケース HTTP サービスのリバースプロキシ API Gateway CloudFront

パスルーティングパターン

パスによるルーティングは、複数またはすべての API を同じホスト名でグループ化し、リクエスト URI を使用してサービスを分離する (api.example.com/service-a または api.example.com/service-b など) メカニズムです。

一般的なユースケース

ほとんどのチームはシンプルなアーキテクチャを必要とするため、この方式を選択します。開発者は HTTP API とやり取りするための URL (api.example.com など) を 1 つだけ覚えておく必要があります。API ドキュメントは、異なるポータルや PDF に分割されるのではなく、まとめて保管されることが多いため、理解しやすい場合が多いです。

パスベースのルーティングは HTTP API の共有に適したシンプルなメカニズムと考えられています。ただし、設定、承認、統合、マルチホップによるレイテンシーの増加などの運用上のオーバーヘッドが発生します。設定ミスによってすべてのサービスが中断されないように、成熟した変更管理プロセスも必要です。

では AWS、API を共有し、正しいサービスに効果的にルーティングする方法が複数あります。以下のセクションでは、HTTP サービスリバースプロキシ、API Gateway、Amazon の 3 つのアプローチについて説明します CloudFront。API サービスの統合に推奨されているこれらのアプローチはいずれも、 AWSで実行されているダウンストリームサービスに依存していません。これらのサービスは、HTTP 互換である限り、どこででも問題なく、またどのテクノロジーでも実行できます。

HTTP サービスのリバースプロキシ

NGINX などの HTTP サーバーを使用して動的ルーティング設定を作成できます。Kubernetes アーキテクチャでは、パスをサービスと一致させるインバウンドトラフィック (イングレス) を作成することもできます。(このガイドでは Kubernetes のイングレスについて説明していません。詳細については、「Kubernetes のドキュメント」を参照してください)

以下の NGINX の設定では、api.example.com/my-service/ の HTTP リクエストが my-service.internal.api.example.com に動的にマッピングされます。


server {
    listen  80;

    location (^/[\w-]+)/(.*) {
        proxy_pass $scheme://$1.internal.api.example.com/$2;
    }
}

次の図は、HTTP サービスのリバースプロキシ方式を示しています。

リクエストの処理を開始するために追加の設定を使用せず、ダウンストリーム API でメトリクスとログを収集できる一部のユースケースでは、このアプローチで十分な場合があります。

本番運用の準備を整えるには、スタックのあらゆるレベルにオブザーバビリティを追加したり、設定を追加したり、API のイングレスポイントをカスタマイズするためにスクリプトを追加したりして、レート制限や使用トークンなどのより高度な機能に対応できるようにする必要があります。

メリット

HTTP サービスのリバースプロキシ方式の最終的な目的は、API を 1 つのドメインに統合して、どの API コンシューマーにとっても一貫性があるように見せるためのスケーラブルで管理しやすいアプローチを作成することです。このアプローチにより、サービスチームは、デプロイ後のオーバーヘッドを最小限に抑えながら、独自の APIsをデプロイおよび管理することもできます。 AWS X-Rayやなどのトレース用の AWS マネージドサービスはAWS WAF、ここでも引き続き適用されます。

デメリット

このアプローチの主な欠点は、必要なインフラストラクチャコンポーネントの広範なテストと管理が必要になることですが、サイト信頼性エンジニアリング (SRE) チームが配置されていれば、これは問題にならない可能性があります。

この方式にはコストの転換点があります。データ量が小～中程度の場合、このガイドで説明する他の方式よりもコストがかかります。データ量が多いと、費用対効果が非常に高くなります (1 秒あたり約 10 万トランザクション以上)。

API Gateway

Amazon API Gateway サービス (REST API および HTTP API) は、HTTP サービスのリバースプロキシ方式と同様の方法でトラフィックをルーティングできます。API ゲートウェイを HTTP プロキシモードで使用すると、簡単に多くのサービスを最上位サブドメイン api.example.com へのエントリポイントにラップし、ネストされたサービス (例: billing.internal.api.example.com) にリクエストをプロキシできます。

ルートまたはコア API ゲートウェイのすべてのサービスのすべてのパスをマッピングするような、きめ細かな作業は不要な場合があります。代わりに、リクエストを請求サービスに転送するワイルドカードパス (/billing/* など) を選択してください。ルートまたはコア API ゲートウェイのすべてのパスをマッピングしないことにより、API を変更するたびにルート API ゲートウェイを更新する必要がなくなるため、API の柔軟性が高まります。

メリット

リクエスト属性の変更など、より複雑なワークフローを制御するために、REST API は Apache Velocity Template Language (VTL) を公開して、リクエストとレスポンスを変更できるようにします。REST API には他にも次のようなメリットがあります。

AWS Identity and Access Management (IAM)、Amazon Cognito 、またはオーソライザーによる認証 N/Z Amazon Cognito AWS Lambda
AWS X-Ray トレース用
との統合 AWS WAF
基本レート制限
コンシューマーをさまざまな階層にバケット化するための使用トークン (「API Gateway ドキュメント」の「API リクエストを調整してスループットを向上させる」を参照してください)

デメリット

データ量が多いと、ユーザーによってはコストが問題になる場合があります。

CloudFront

Amazon CloudFront の動的オリジン選択機能を使用して、リクエストを転送するオリジン (サービス) を条件付きで選択できます。この機能を使用すると、1 つのホスト名 (api.example.com など) で多数のサービスをルーティングできます。

一般的なユースケース

ルーティングロジックは Lambda@Edge 関数内のコードとして存在するため、A/B テスト、canary リリース、機能のフラグ付け、パスの書き換えなど、高度にカスタマイズ可能なルーティングメカニズムをサポートできます。これについては、以下の図で示されています。

メリット

API レスポンスをキャッシュする必要がある場合、この方式は単一のエンドポイントの背後に存在するサービスのコレクションを統合するのに適した方法です。これは、API のコレクションを統合するための費用対効果の高い方式です。

また、はフィールドレベルの暗号化と、基本レート制限と基本 ACLs AWS WAF のためのとの統合 CloudFront をサポートしています。

デメリット

この方式でサポートされる統合可能なオリジン (サービス) は最大で 250 個です。ほとんどのデプロイではこの制限で十分ですが、サービスのポートフォリオが拡大するにつれて、多数の API で問題が発生する可能性があります。

現在、Lambda@Edge 関数の更新には数分かかります。 CloudFront また、すべての存在ポイントへの変更の伝達が完了するまでに最大 30 分かかります。そのため、更新が完了するまで、それ以降の更新は最終的にはブロックされます。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

ホスト名ルーティング

HTTP ヘッダールーティング