Amazon API Gatewayの仕組みと課題について

Pulisher : Managed & Support Center イ・スンヒ
Description：API Gatewayサービスの仕組みと、複数のサービス統合間で発生する可能性のある問題について紹介する3つのサービス

はじめに

業務を進めていく中で、API Gatewayの使用間で発生する問題についての問い合わせをよく受けます。

ただ、当該サービスの場合、複数のサービスとの統合して使用することがほとんどのケースであるため、多角的な側面からの検討が必要です。今回のセッションを通じて、動作方式及び複数のサービスとの統合間で発生する可能性のあるイシューについて確認できることを期待してセッションを申し込みました。

セッションの概要紹介

プロキシを使用する場合、クライアントはパケットを送信し、APIゲートウェイはそれをラップします。このとき、値は変更可能ですが、バックエンドで必要なメタデータやコンテキスト情報を追加でラップします。この情報はリクエストに関するものであったり、セキュリティなど様々なものである可能性があります。 その後、この場合、ラムダ関数がパケットを受け取り、処理して送り返します。

クライアントがリクエストを送信すると、上記の長方形に基づき、大きなピンク色の四角い枠で表示されます。 次に、VTLというものを使用します。これはVelocity Templating Language (Velocity Templating Language)の略です。

これはApacheが作成したテンプレート言語で、APIゲートウェイでサポートされています。これを使用してリクエストを修正することができます。if-thenのようなロジックを使用したり、パラメータを設定したり、静的データをロードしたりなど、さまざまなことを行うことができます。

簡単な例で説明します。

VTLを実行すると、VTLはデータを修正し、住所、都市、州を結合します。

これをオブジェクトの中に入れますが、これがバックエンドで望む方法です。 このように、VTLはマッピングの方法を変更する機能を提供します。

今回はVPC linksについて説明します。 例えば、単一のアプリケーションがあり、それを移行したい場合、単純に停止してサービス化して再構築するのは現実的ではありません。 AWSへの移行後に単一のアプリケーションをサービスに分割したい場合は、APIゲートウェイを前面に置いて、VPC linksを介してネットワークロードバランサーを接続することができます。これにより、データをバックエンドに直接転送し、リソースポリシー、キャッシュなどを透過的に使用することができます。 特定のサービスをラムダで分離し、APIゲートウェイを介して新しいサービスにリダイレクトすることができ、この方法は完全に無停止ではありませんが、最小限のダウンタイムでサービス移行を可能にします。

APIゲートウェイでの権限付与方法について説明します。まず、IAM権限付与を通じてリクエストに署名し、これに基づいてアクセスを決定します。第二に、Amazon Cognitoを利用してユーザープールを作成し、ログイン、パスワードのリセット、トークンの再要求などを管理することができます。Cognitoで認証されたトークンでAPIゲートウェイにリクエストを送信して認証を受けます。

最後に、Lambdaを使用したユーザー定義認証方式があり、Lambdaでロジックを実行した後、APIゲートウェイに認証結果を返します。これらの方法により、セキュリティを強化し、最適化することができます。

次に、キャッシュについて説明します。

データが非常に動的であるため、キャッシュは無意味に思えるかもしれませんが、生存時間がわずか5秒であっても、キャッシュを使用することで、応答速度を向上させ、バックエンドの負荷を軽減することができます。

APIゲートウェイを通じて管理されるキャッシュは、迅速な応答とバックエンドの負荷の最小化に効果的です。キャッシュキーを活用してパス、ヘッダー、クエリ文字列に応じてキャッシュを設定することができ、開発段階ではキャッシュを使用せず、本番段階ではキャッシュを使用して最適化することができます。

APIゲートウェイにおけるスロットリング(リクエスト制限)とその重要性について説明します。スロットリングは4段階に分かれており、最初の段階はアカウントレベルで地域ごとに設定されます。基本的な制限は10,000リクエスト/秒と5,000バースト（短時間で集中したリクエスト）です。例えば、あるアプリケーションに1秒間に5,000件のリクエストが入った場合、APIゲートウェイはこれを処理することができますが、5,001件のリクエストが入った場合、最後のリクエストは処理されません。 また、この制限は該当リージョンのすべてのAPIに共有されるため、複数のAPIを運営する場合はこれを考慮する必要があります。必要に応じてAWSの制限を調整して、より高いスロットリング制限を設定することができます。

セッションを終えて

今回のセッションでは、講師の方が愉快かつ分かりやすくリードしてくださったので、他のセッションに比べ、より集中して聞くことができました。API Gatewayサービスについてのディープダイブセッションになったようで、有意義なセッションでした。