翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# パスルーティングパターン
パスによるルーティングは、複数またはすべての 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 CloudFront の 3 つのアプローチについて説明します。API サービスの統合に推奨されているこれらのアプローチはいずれも、AWS で実行されているダウンストリームサービスに依存していません。これらのサービスは、HTTP 互換である限り、どこででも問題なく、またどのテクノロジーでも実行できます。
## HTTP サービスのリバースプロキシ
[NGINX](https://www.f5.com/go/product/welcome-to-nginx) などの HTTP サーバーを使用して動的ルーティング設定を作成できます。[Kubernetes](https://kubernetes.io/) アーキテクチャでは、パスをサービスと一致させるインバウンドトラフィック (イングレス) を作成することもできます。(このガイドでは Kubernetes のイングレスについて説明していません。詳細については、「[Kubernetes のドキュメント](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource)」を参照してください)
以下の 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 サービスのリバースプロキシ方式を示しています。
![\[HTTP サービスのリバースプロキシをパスルーティングに使用します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png)
リクエストの処理を開始するために追加の設定を使用せず、ダウンストリーム API でメトリクスとログを収集できる一部のユースケースでは、このアプローチで十分な場合があります。
本番運用の準備を整えるには、スタックのあらゆるレベルにオブザーバビリティを追加したり、設定を追加したり、API のイングレスポイントをカスタマイズするためにスクリプトを追加したりして、レート制限や使用トークンなどのより高度な機能に対応できるようにする必要があります。
### 長所
HTTP サービスのリバースプロキシ方式の最終的な目的は、API を 1 つのドメインに統合して、どの API コンシューマーにとっても一貫性があるように見せるためのスケーラブルで管理しやすいアプローチを作成することです。このアプローチにより、サービスチームは、デプロイ後のオーバーヘッドを最小限に抑えながら、独自の API をデプロイおよび管理することもできるようになります。[AWS X-Ray](https://aws.amazon.com/xray/) や [AWS WAF](https://aws.amazon.com/waf/) などのトレーシングのための AWS マネージドサービスは、ここでも引き続き適用できます。
### 短所
このアプローチの主な欠点は、必要なインフラストラクチャコンポーネントの広範なテストと管理が必要になることですが、サイト信頼性エンジニアリング (SRE) チームが配置されていれば、これは問題にならない可能性があります。
この方式にはコストの転換点があります。データ量が小～中程度の場合、このガイドで説明する他の方式よりもコストがかかります。データ量が多いと、費用対効果が非常に高くなります (1 秒あたり約 10 万トランザクション以上)。
## API Gateway
[Amazon API Gateway](https://aws.amazon.com/api-gateway/) サービス (REST API および HTTP API) は、HTTP サービスのリバースプロキシ方式と同様の方法でトラフィックをルーティングできます。API ゲートウェイを HTTP プロキシモードで使用すると、簡単に多くのサービスを最上位サブドメイン `api.example.com` へのエントリポイントにラップし、ネストされたサービス (例: `billing.internal.api.example.com`) にリクエストをプロキシできます。
ルートまたはコア API ゲートウェイのすべてのサービスのすべてのパスをマッピングするような、きめ細かな作業は不要な場合があります。代わりに、リクエストを請求サービスに転送するワイルドカードパス (`/billing/*` など) を選択してください。ルートまたはコア API ゲートウェイのすべてのパスをマッピングしないことにより、API を変更するたびにルート API ゲートウェイを更新する必要がなくなるため、API の柔軟性が高まります。
![\[API Gateway 経由のパスルーティング。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png)
### 長所
リクエスト属性の変更など、より複雑なワークフローを制御するために、REST API は Apache Velocity Template Language (VTL) を公開して、リクエストとレスポンスを変更できるようにします。REST API には他にも次のようなメリットがあります。
+ [Auth N/Z with AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html)、[Amazon Cognito](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html)、または [AWS Lambda オーソライザー](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)
+ [トレーシングのための AWS X-Ray](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html)
+ [ との統合AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html)
+ [基本レート制限](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ コンシューマーをさまざまな階層にバケット化するための使用トークン (「API Gateway ドキュメント」の「[API リクエストを調整してスループットを向上させる](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)」を参照してください)
### 短所
データ量が多いと、ユーザーによってはコストが問題になる場合があります。
## CloudFront
[Amazon CloudFront](https://aws.amazon.com/cloudfront/) の[動的オリジン選択機能](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html)を使用して、リクエストを転送するオリジン (サービス) を条件付きで選択できます。この機能を使用すると、1 つのホスト名 (`api.example.com` など) で多数のサービスをルーティングできます。
### 一般的なユースケース
ルーティングロジックは Lambda@Edge 関数内のコードとして存在するため、A/B テスト、canary リリース、機能のフラグ付け、パスの書き換えなど、高度にカスタマイズ可能なルーティングメカニズムをサポートできます。これについては、以下の図で示されています。
![\[CloudFront 経由のパスルーティング。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png)
### 長所
API レスポンスをキャッシュする必要がある場合、この方式は単一のエンドポイントの背後に存在するサービスのコレクションを統合するのに適した方法です。これは、API のコレクションを統合するための費用対効果の高い方式です。
また、CloudFront は、[フィールドレベルの暗号化](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html)に加えて、基本的なレート制限と基本的な ACL のための AWS WAF との統合もサポートしています。
### 短所
この方式でサポートされる統合可能なオリジン (サービス) は最大で 250 個です。ほとんどのデプロイではこの制限で十分ですが、サービスのポートフォリオが拡大するにつれて、多数の API で問題が発生する可能性があります。
現在、Lambda@Edge 関数の更新には数分かかります。また、CloudFront から、すべての PoP (ポイントオブプレゼンス) への変更の伝達が完了するまでに、最大 30 分かかります。そのため、更新が完了するまで、それ以降の更新は最終的にはブロックされます。