API Gatewayによって大幅な遅延が発生しますか？
私の通話の待ち時間がどこから来ているのかを把握しようとしています。この情報のいずれかがより明確な形式で表示できるかどうかをお知らせください。
背景：システムAとシステムBの2つのシステムがあります。システムBのエンドポイントを呼び出すシステムAのエンドポイントに手動で（Postmanを介して）ヒットします。システムAはEC2インスタンスでホストされています。
- システムBがAPI Gatewayの背後にあるLambda関数でホストされている場合、呼び出しのレイテンシは125ミリ秒です。
- システムBがEC2インスタンスでホストされている場合、呼び出しのレイテンシは8ミリ秒です。
- システムBがAPI Gatewayの背後にあるEC2インスタンスでホストされている場合、呼び出しの遅延は100ミリ秒です。
したがって、私の仮説は、API GatewayがLambda関数とペアになっている場合にもレイテンシが増加する理由であるということです。これが事実であるかどうかを誰かが確認できますか？そうである場合、レイテンシを大幅に増加させるAPI Gatewayは何をしていますか？それを回避する方法はありますか？ありがとうございました！
これについてアマゾンのサポートから聞いた：
API Gatewayを使用する場合、クライアントからAPI Gatewayに移動する必要があります。つまり、VPCを離れてインターネットに移動し、次にVPCに戻って他のEC2インスタンスに移動し、次にAPI Gatewayに戻って、つまりVPCを離れる必要があります。その後、最初のEC2インスタンスに戻ります。
したがって、この追加の待ち時間が予想されます。レイテンシを下げる唯一の方法は、APIキャッシングを追加することです。これは、リクエストしているコンテンツが静的であり、常に更新されない場合にのみ役立ちます。アイテムがキャッシュから削除され、システムからフェッチする必要がある場合でも、レイテンシは長くなりますが、ほとんどの呼び出しは低くなります。
ですから、レイテンシは正常であると思いますが、これは残念なことですが、うまくいけば、常に前進し続ける必要があるものではありません。
正確には元の質問が要求するものではないかもしれませんが、CloudFrontに関するコメントを追加します。
私の経験では、CloudFrontとAPI Gatewayの両方で、平均ですべてのHTTPSリクエストに対して少なくとも100ミリ秒（おそらくそれ以上）が追加されます。
これは、API呼び出しを保護するために、API GatewayがすべてのコンポーネントでSSLを適用するためです。つまり、バックエンドでSSLを使用している場合、最初のAPI呼び出しは3つのSSLハンドシェイクをネゴシエートする必要があります。
- CloudFrontへのクライアント
- CloudFrontからAPI Gateway
- バックエンドへのAPIゲートウェイ
これらのハンドシェイクが100ミリ秒以上かかることも珍しくありません。つまり、非アクティブなAPIへの1つのリクエストで300ミリ秒を超える追加のオーバーヘッドが発生する可能性があります。 CloudFrontとAPI Gatewayはどちらも接続を再利用しようとするため、多数のリクエストに対して、各呼び出しのオーバーヘッドが最初のSSLハンドシェイクのコストのみに近づくことが予想されます。残念ながら、Webブラウザーからテストしていて、まだ本番環境にないAPIに対して単一の呼び出しを行っている場合、これはおそらく表示されません。
同じ議論で、接続の再利用を実際に確認するには、「大量のリクエスト」がどうあるべきかが最終的に明らかになりました。
さらに、私が大きいことを意味したとき、私はスケールで少し正確である必要がありました。単一のソースからの1000リクエストでは、大きな再利用は見られないかもしれませんが、複数のソースからの1秒あたりの数が多いことを確認しているAPIは、私が述べた結果を期待しています。
...
残念ながら、正確な数を提供することはできませんが、1秒あたりのリクエスト数が100に近づくまで、接続の再利用はほとんどありません。
これは2016年後半からのスレッドであり、すでにいくつかの改善が行われているはずです。しかし、私自身の経験では、このオーバーヘッドはまだ存在しており、2000 rpsの単純なAPIで負荷テストを実行しても、2018年の時点で200ミリ秒を超えるレイテンシがまだ発生しています。
ソース： https://forums.aws.Amazon.com/thread.jspa?messageID=737224
直接的なケース（＃2）では、SSLを使用していますか？ SSLの場合、8 msは非常に高速ですが、それがAZ内にある場合は可能だと思います。そこでSSLを使用していない場合、APIGWを使用すると、クライアントとCloudFrontの間に安全なTLS接続が導入されますが、これにはもちろん待ち時間のペナルティがあります。ただし、レイテンシは最初の確立時のみであるため、通常、安全な接続にはそれだけの価値があります。
接続が確立されるまで、またはAPIのボリュームが中程度で持続している場合、APIGWの平均レイテンシは大幅に減少すると予想されます。ただし、新しい接続を確立するときは、最大100ミリ秒の遅延が発生します。
残念ながら、あなたが説明しているユースケース（EC2-> APIGW-> EC2）は今のところ素晴らしいものではありません。 APIGWはCloudFrontの背後にあるため、世界中のクライアント向けに最適化されていますが、クライアントがEC2上にある場合は追加のレイテンシが発生します。
編集：そして、Lambdaを追加するときにわずかなペナルティしか表示されない理由は、APIGWが少数のIPを持つ単一のエンドポイントであるため、すでにLambdaへの確立された接続が多数あるためです。 APIGWの実際のオーバーヘッド（接続関連ではない）は、Lambdaオーバーヘッドと同様である必要があります。