NGINX、Kong、Amazon の API 管理ソリューションのベンチマーク: API をリアルタイムで配信していますか?

スピード – アプリのパフォーマンスが遅すぎると消費者が簡単に競合他社に乗り換えてしまう今日のデジタル環境では、スピードが重要です。 アプリの速度は、最終的には応答性が高く、健全で、適応性の高い API によって決まります。API の応答性における重要な要素の 1 つは、API ゲートウェイによって発生する遅延です。 しかし、すべての API ゲートウェイが同じレベルで動作するわけではありません。

この点を私たちが痛感したのは、消費者信用業界の大手企業である NGINX の顧客から、ユーザーが期待するデジタル エクスペリエンスを提供するために通信する必要のあるアプリやその他のコンポーネントが増えるにつれて、「リアルタイム」 API パフォーマンスの重要性が高まっているという話を聞かされた昨年の秋でした。 お客様が必要とする超高速 API レイテンシ (10 ミリ秒 (ms) 未満) を実現できる API ゲートウェイは NGINX Plus のみであることを知って、私たちは非常に満足しました。 他の多くの顧客、 のような キャピタルワンは、NGINX Open Source または NGINX Plus を API ゲートウェイとして使用して、レイテンシを削減し、スループットを向上させた方法についても共有してくれました。

私たちは、API エコシステムをさらに深く調べ、API を「リアルタイム」にする要素を解明することにしました。 さまざまな要因に基づいて、リアルタイム API は、99 パーセンタイルまでのすべてのパーセンタイルで、エンドツーエンドで API 呼び出しを 30 ミリ秒未満で処理する必要がある(つまり、平均して 100 回の呼び出しのうち 1 回だけが 30 ミリ秒を超える) と判断しました。

API管理ソリューションの比較

当社独自のテストでは、API 管理ソリューションを使用することで、リアルタイムの API パフォーマンスを簡単に実現できることが一貫して示されています。このソリューションは、API 呼び出しを処理するための API ゲートウェイとしてのNGINX Plusと、ライフサイクル全体にわたって定義、公開、管理、監視する際に NGINX Plus インスタンスと API の両方を管理するNGINX Controller API 管理モジュールを組み合わせたものです。

しかし、私たちの言うことをそのまま信じたくないかもしれないことも理解しています。 そこで当社は、独立系技術調査分析会社であるGigaOm に、当社の API 管理ソリューションと市場で人気の他のソリューション（NGINX のようにオンプレミスまたはクラウドに導入できる 2 つのソリューション、 ApigeeとKong Enterprise 、および 2 つのフルマネージド クラウド サービス、 Amazon API Gatewayと Kong Cloud）の客観的かつ透明性のあるベンチマークを依頼しました。

このブログでは、GigaOmのテスト結果をまとめています（ネタバレ： NGINX Plus は、テストされたすべての条件でリアルタイムに API を配信しましたが、他のソリューションではそうではありませんでした。 ソリューション、テスト方法、結果に関する詳細については、当社のチームのメンバーにお問い合わせください。

注記： Apigee エンドユーザー使用許諾契約 (EULA) では、Google の明示的な許可なしにテスト結果を公開することを禁止しているため、残念ながらレポートにもこのブログにも Apigee に関する情報は含まれていません。

ベンチマークの概要

GigaOm は、 Vegeta HTTP 負荷テスト ツールを使用してリクエスト (API 呼び出し) を生成し、1 秒あたりのリクエスト数 (RPS) ごとに API ゲートウェイがもたらすレイテンシ (API 呼び出しに対する応答を返すのにかかる時間) を測定しました。GigaOm ではこれを「攻撃率」と呼んでいます。 GigaOm は、攻撃レートを 1,000 RPS から開始し、Vegeta がエラー ステータス コードを報告するまで、5,000、10,000、20,000 などと徐々に上げていくテストを実行しました。 各テスト実行は 60 秒間続き、3 回繰り返されました。 以下のグラフに示すように、GigaOm は 50 パーセンタイル、90 パーセンタイル、95 パーセンタイル、99 パーセンタイル、99.9 パーセンタイル、99.99 パーセンタイルでレイテンシをキャプチャし、テスト実行中に観測された最長レイテンシ (グラフのMax ) も記録しました。

結果： NGINX 対 コングエンタープライズ

GigaOm は、NGINX Plus (NGINX Controller を使用して展開) と Kong Node (Kong Enterprise を使用して展開) を比較する 2 つのベンチマークを実施しました。 最初のベンチマークでは、単一のワーカーノード（NGINX Plus または Kong Node の 1 つのインスタンス）がありました。 2 番目では、NGINX Open Source によってラウンドロビン モードで負荷分散された 3 つのワーカー ノードがありました。 (GigaOm は、NGINX Open Source をロードバランサーとして使用しても NGINX Plus の利点は生まれないことを強調しており、Kong でさえ、クラスター化された Kong Node インスタンスに使用するロードバランサーとしてこれを推奨しています。)

次のグラフに示すように、NGINX と Kong のレイテンシの差は 99 パーセンタイルまではごくわずかですが、その時点で Kong のレイテンシは指数関数的に増加し始めます。 99.99 パーセンタイルでは、Kong のレイテンシは 2 つのベンチマークでそれぞれ NGINX の 3 倍または 2 倍になります。

99 パーセンタイルは、API をリアルタイムとして定義するための適切な最小値ですが、GigaOm は、実際の展開では、99.9 パーセンタイルや 99.99 パーセンタイルなどのより高いパーセンタイルで低レイテンシを維持することが「非常に重要」であると指摘しています。 報告書では次のように説明されている。

レイテンシの結果は時間の経過とともに多峰性を示す傾向があり、スパイクの頂点は応答時間の「ヒクツキ」を表します。

これらのしゃっくりは重要です。 応答時間または遅延の中央値が 30 ミリ秒未満であっても、遅延が 1 秒以上発生すると、その後のユーザー エクスペリエンスに累積的な影響が生じます。 たとえば、食べ物の平均待ち時間が 1 分であるファーストフードのドライブスルーを訪れた場合、おそらくそれは良い顧客体験であると思うでしょう。 しかし、目の前の顧客の注文に問題があり、解決に 10 分かかる場合はどうでしょうか? 実際の待ち時間は 11 分になります。 中断の後にリクエストが順番に届いたため、遅延した 99.99 パーセンタイルの遅延があなたの遅延にもなる可能性があります。

高いパーセンタイルでの異常に大きなレイテンシの悪影響は、単一のクライアント要求によって複数のダウンストリーム API 呼び出しが生成される可能性がある分散アプリケーションではさらに顕著になります。 たとえば、1 つのクライアント要求によってサブシステムへの API 呼び出しが 10 回作成され、応答が遅くなる可能性が 1% であるとします。 結果として、1 つのクライアント要求が遅い応答によって影響を受ける確率はほぼ 10% であることが数学的に示されます。 計算の詳細については、 「Who moved my 99th percentile delay?」を参照してください。

図 1 は、単一のワーカー ノードでの 30,000 RPS 攻撃率の結果を示しています。 99.99 パーセンタイルでは、Kong のレイテンシは NGINX の 3 倍を超え、リアルタイム API の 30 ミリ秒のしきい値を超えています。 対照的に、NGINX Plus はすべてのパーセンタイルでリアルタイムのレイテンシを実現します。記録された最高 (最大) レイテンシの 13 ミリ秒でさえ、リアルタイムしきい値の半分未満です。

図 2 は、3 つのワーカー ノードを使用したベンチマークで、攻撃率が 30,000 RPS の場合の非常に類似した結果を示しています。 興味深いことに、Kong は 99 パーセンタイルと 99.9 パーセンタイルで NGINX を上回っていますが、99.99 パーセンタイルで再び大きなレイテンシー スパイクが発生し、今回は NGINX の約 2 倍のレイテンシーに達しています。 最初のベンチマークと同様に、NGINX はすべてのパーセンタイルで 30 ミリ秒のリアルタイムしきい値を下回っています。

APIゲートウェイのパフォーマンスを測定するもう1つの方法は、100%の成功率で処理できる最大RPSを決定することです（ 5xxまたは429単一ノード構成と 3 ノード構成の両方で、すべてのパーセンタイルで[リクエストが多すぎます]エラーと 30 ミリ秒未満のレイテンシが実現しました。 図 3 は、この測定により、NGINX が Kong よりも 50% 高い RPS を維持していることを示しています。 30,000対20,000。

結果： NGINX 対 Kong Cloud と Amazon API ゲートウェイ

3 番目のベンチマーク セットでは、GigaOm は NGINX Plus を Kong Cloud および Amazon API Gateway と比較しました。 GigaOm は、Kong Cloud と Amazon API Gateway は完全に管理された SaaS サービスであるのに対し、NGINX Controller は PaaS サービスであり、現在は SaaS として利用できないことから、直接比較することは非常に問題があると強調しています。 特に、どちらの SaaS サービスも、使用するインスタンス タイプ、コンピューティング能力、メモリ、またはネットワーク機能を明らかにしていません。 そのため、GigaOm は NGINX Plus 用に同等の設定を推測する必要がありました。

NGINX Plus との比較はさておき、図 4 に示されている 2 番目に低い攻撃率 (5,000 RPS) でも、テストされたどのパーセンタイルでも SaaS オファリングは API をリアルタイムで配信できないことがすぐにわかります。 50 パーセンタイルでは、SaaS オファリングのレイテンシはすでに 30 ミリ秒のしきい値の 7 倍を超えており、99.99 パーセンタイルではそのしきい値を 8000% 以上超えています。 明らかな意味は、Kong Cloud または Amazon API Gateway が 30 ミリ秒未満のレイテンシで 100% の成功を達成できる条件は存在しないということです。

NGINX が唯一のリアルタイム API ソリューションであることを検証

要約すると、NGINX は、GigaOm によってテストされ、リアルタイム API 処理の基準を満たし、すべてのパーセンタイルで 30 ミリ秒未満のレイテンシを達成した唯一のソリューションです。 Kong Enterprise は 99 パーセンタイルでリアルタイム パフォーマンスを実現しますが、より高いパーセンタイルではレイテンシーが大幅に上昇するため、中程度の量のリアルタイム API 処理を必要とする実稼働環境には適していません。 テストされた SaaS ソリューションはいずれもリアルタイムとして分類できません。

GigaOm レポートは、当社のこれまでのベンチマークとお客様から寄せられた意見の両方を検証しています。 NGINX Plus は市場最速の API ゲートウェイであり、すべてのパーセンタイルで 30 ミリ秒未満のレイテンシを維持できる唯一の API ソリューションです。 また、NGINX コントローラーと組み合わせると、独自に設計された API 管理ソリューションにアクセスできるようになります。このソリューションでは、慎重な分離により、API 管理コントロール プレーン (NGINX コントローラー) から API ゲートウェイ データ プレーン (NGINX Plus) のパフォーマンスにまったく影響がありません。

rtapiレイテンシ測定ツールを使用して、独自の API パフォーマンスをテストできます。 ぜひご確認いただき、弊社にご連絡の上、 API をリアルタイム化する上でどのようにサポートできるかご相談ください。