“スピード”は、今日のデジタル環境で重要な鍵となっています。アプリケーションの応答パフォーマンスが遅いと感じれば、消費者は簡単に競合他社のサービスに乗り換えてしまう可能性があります。最終的にアプリケーションの速度を決定するのは、応答性と適応性に優れた最適なAPIです。そして、APIの応答性を左右する重要な要素の1つが、APIゲートウェイにより生じるレイテンシーです。しかし、すべてのAPIゲートウェイのパフォーマンスは同じレベルではありません。
これが切実な問題であることは、昨年の秋にお客様からNGINXに寄せられた発言にも表れています。このお客様は消費者金融業界の大手企業ですが、ユーザが求めるデジタルエクスペリエンスを提供するには、非常に多くのアプリケーションや他のコンポーネントとやりとりをする必要があり、このような状況から「リアルタイム」APIのパフォーマンスの重要性が高まっていると述べています。このお客様が求めていたAPIの最小レイテンシー（約10ミリ秒）を実現した唯一のAPIゲートウェイが、NGINX Plusであったことは素晴らしいニュースでした。ほかにもCapital Oneなどの多くの顧客が、オープンソース版のNGINXまたはNGINX PlusをAPIゲートウェイとして使用することで、レイテンシーを低減し、スループットを向上させていると報告されています。
NGINXは、「リアルタイム」のAPIに必要とされる要因を探るため、APIのエコシステムをさらに詳しく調べました。多くの要因を検討した上で、99パーセンタイルまでの各パーセンタイルでエンドツーエンドのAPI呼び出しを30ミリ秒未満で処理することでリアルタイムAPIとみなすことができる（つまり、30ミリ秒以上かかる呼び出しは平均で100件中1件のみ）と判断しました。
API管理ソリューションの比較
NGINXが独自に実施したテストでは、NGINXのAPI管理ソリューションを使用することで、リアルタイムAPIのパフォーマンスを簡単に達成できることが一貫して示されています。このソリューションでは、NGINX Plus（API呼び出しを処理するためのAPIゲートウェイ）とNGINX Controller API Management Module（NGINX PlusインスタンスとAPIの両方の管理に使用し、APIをライフサイクル全体で定義、公開、管理、監視）を組み合わせて使用します。
ただ、この当社の主張をそのまま受け入れることができない方がいることは当然でしょう。そこで、NGINXのAPI管理ソリューションとその他の一般的ソリューションの客観的で透過性のあるベンチマークを、独立した技術調査・分析を専門とするGigaOmに委託しました。比較対象は、NGINXと同様にオンプレミスまたはクラウドにデプロイ可能なソリューションであるApigeeとKong Enterpriseの2つ、そしてフルマネージドクラウドサービスであるAmazon API GatewayとKong Cloudの2つです。
このブログではGigaOmのテスト結果の概要を紹介しますが、結論から言うと、テストされたすべての条件下でリアルタイムAPIを実現したソリューションはNGINX Plusだけでした。ソリューション、テスト手法、結果の詳細については、GigaOmの無料レポートをダウンロードしてください。
注：Apigeeのエンドユーザライセンス契約（EULA）は、Googleの明示的な許可なしにテスト結果を公開することを禁止しています。このため、残念ながらレポートとこのブログではApigeeに関する情報は含めていません。
ベンチマークの概要
リクエスト（APIコール）を生成し、APIゲートウェイで発生するレイテンシー（APIコールへの応答時間）を測定するため、GigaOmはVegetaのHTTP負荷テストツールを使用しました。テストは、「アタックレート（attack rate）」と呼ぶ数種類のRPS（1秒あたりのリクエスト数）で実行しました。アタックレートは1,000 RPSから開始し、5,000 RPS、10,000 RPS、20,000 RPSといった形で、Vegetaがエラーステータスコードを報告するまで増加して、テストを実行しました。各テストは60秒間実行され、3回繰り返されました。以下のグラフに示すように、GigaOmは、50、90、95、99、99.9、99.99の各パーセンタイルでのレイテンシーを確認し、テスト実行中に観測された最長のレイテンシー（グラフのMax）も記録しました。
結果：NGINXとKong Enterpriseの比較
GigaOmは、NGINX Plus（NGINX Controllerを使用してデプロイ）とKong Node（Kong Enterpriseを使用してデプロイ）を比較する2つのベンチマークを実施しました。最初のベンチマークでは、単一のワーカーノード（NGINX PlusまたはKong Nodeの1つのインスタンス）を使用しました。2番目のベンチマークでは、ラウンドロビンモードでオープンソース版のNGINXによってロードバランシングされた3つのワーカーノードを使用しました。（GigaOmは、オープンソース版のNGINXをロードバランサーとして使用してもNGINX Plusに有利に作用しないことを強調しています。Kongも、クラスター化されたKong Nodeインスタンスのロードバランサーとしてオープンソース版のNGINXを使用することを推奨しています。）
以下のグラフに示すように、99パーセンタイルまでは、NGINXとKongのレイテンシーの差はわずかですが、そこからKongのレイテンシーが指数関数的に高くなっていきます。99.99パーセンタイルでは、Kongのレイテンシーは2つのベンチマークでそれぞれNGINXの3倍または2倍になります。
99パーセンタイルは、APIをリアルタイムと定義できる最小値としては悪くないレベルです。しかし、99.9や99.99のように、より高いパーセンタイルで低レイテンシーを維持することが、実際のデプロイメントでは「非常に重要」であると、GigaOmは述べています。レポートでは次のように説明されています。
レイテンシーの結果は時間の経過とともにいくつかの形態となる傾向があり、スパイクの頂点では応答が「一時的に中断する」時間があります。
この「一時的な中断」が重大な問題となります。応答時間、つまりレイテンシーの中央値が30ミリ秒未満であっても、1秒以上に及ぶレイテンシーの「一時的な中断」が起こる場合、実際にはその後のユーザエクスペリエンスに累積的な影響が及びます。たとえば、ドライブスルーのファストフード店で、注文した商品を受け取るまでの待ち時間の中央値が1分であれば、かなり満足できるカスタマーエクスペリエンスであると考えられるかもしれません。しかし、自分の前にいる客の注文に何らかの問題があり、その解決に10分かかるとしたらどうでしょうか。この場合、実際の待ち時間は11分になります。「一時的な中断」の後に自分のリクエストが到着したことになるので、99.99パーセンタイルで遅延があると、それは実際の遅延になる場合があります。
分散アプリケーションでは、単一のクライアントリクエストが、実際には下流でいくつものAPIコールを生成する場合があります。その場合、高いパーセンタイルにおける大きなレイテンシーがもたらす悪影響が、さらに甚大なものとなります。たとえば、1つのクライアントリクエストによって、サブシステムに対して10個のAPIコールが作成されるときに、1%の確率で応答が遅延するとします。この場合には結果として、数学的には10%近い確率で、1つのクライアントリクエストが応答の遅延による影響を受けることになります。この計算の詳細については、「Who moved my 99th percentile latency?」（英語）をご覧ください。
図1は、単一のワーカーノードで30,000 RPSのアタックレートを使用する場合の結果を示しています。99.99パーセンタイルで、KongのレイテンシーはNGINXの3倍を上回り、リアルタイムAPIに必要とされる30ミリ秒のしきい値を超えています。対照的に、NGINX Plusは、各パーセンタイルでリアルタイムのレイテンシーを実現しています。記録された最大のレイテンシー（グラフのMax）も13ミリ秒であり、リアルタイムのしきい値の半分未満です。
図2は、3つのワーカーノードを使用したベンチマークであり、ここでも非常によく似た結果を示しています。この場合も、アタックレートは30,000 RPSです。興味深いことに、99パーセンタイルと99.9パーセンタイルでは、KongはNGINXを超えるパフォーマンスを達成していますが、99.99パーセンタイルで再びレイテンシーが急激に悪化しています。そのときのレイテンシーは、NGINXの約2倍に達しています。最初のベンチマークと同様に、NGINXはすべてのパーセンタイルでリアルタイムの30ミリ秒のしきい値を下回っています。
APIゲートウェイのパフォーマンスを測定するもう1つの方法は、単一ノードと3ノードの両方の構成において、すべてのパーセンタイルで成功率100%（5xxまたは429 [Too Many Requests]のエラーなし）およびレイテンシー30ミリ秒未満で処理できる最大RPSを判断することです。図3は、この測定により、NGINX（30,000 RPS）がKong（20,000 RPS）よりも50%高いRPSを維持していることを示しています。
結果：NGINX、Kong Cloud、Amazon API Gatewayの比較
3番目のベンチマークセットでは、NGINX PlusをKong CloudとAmazon API Gatewayに対して比較しました。Kong CloudとAmazon API GatewayがフルマネージドのSaaSソリューションであるのに対して、NGINX ControllerはPaaSソリューションであり、現在はSaaSとして提供されていません。このため、GigaOmは直接比較することには大きな問題があると強調しています。特に、使用するインスタンスのタイプ、コンピュートパワー、メモリー、ネットワーク機能といった情報について、どちらのSaaSソリューションも公表していません。したがって、NGINX Plusを比較対象とするために、最良と思われる推測を使用して設定する必要がありました。
NGINX Plusとの比較はさておき、これらのSaaSソリューションは、図4に示す2番目に低いアタックレート（5,000 RPS）でも、テストされたすべてのパーセンタイルでリアルタイムAPIを実現できないことは明らかです。SaaSソリューションのレイテンシーは、50パーセンタイルですでに30ミリ秒のしきい値の7倍を超え、99.99パーセンタイルでは80倍を超えています。したがって、どのような条件においても、Kong CloudまたはAmazon API Gatewayが30ミリ秒未満のレイテンシーで100%の成功を収めることができないことは明白です。
唯一のリアルタイムAPIソリューションとして確認されたNGINX
上記に示したとおり、GigaOmがテストしたソリューションの中で、リアルタイムAPIの処理の基準を満たし、各パーセンタイルで30ミリ秒未満のレイテンシーを達成したのはNGINXだけです。Kong Enterpriseは99パーセンタイルでリアルタイムのパフォーマンスを達成していますが、さらに高いパーセンタイルではレイテンシーが急激に悪化するため、リアルタイムAPIの処理が特に多くない実稼働環境でも不向きです。テストされたSaaSは、いずれもリアルタイムとして分類できないソリューションです。
GigaOmレポートは、NGINXの以前のベンチマークとお客様からのフィードバックの両方を検証しています。NGINX Plusは市場で最速のAPIゲートウェイであり、すべてのパーセンタイルで30ミリ秒未満のレイテンシーを維持できる唯一のAPIソリューションです。また、NGINX Controllerと組み合わせることで、独自のカスタマイズされたAPI管理ソリューションを利用できるようになります。このソリューションでは、慎重な分離によって、API管理のコントロールプレーン（NGINX Controller）がAPIゲートウェイのデータプレーン（NGINX Plus）のパフォーマンスに影響を及ぼすことは一切ありません。
ここでは、GigaOmレポートの概要を説明しました。詳細については、レポート全文（英語版）をダウンロード（無料）してご確認ください。また、NGINXのrtapiレイテンシー測定ツールを使用すると、お使いのAPIのパフォーマンスをテストできます。こちらをご覧いただくとともに、当社にお問い合わせください。貴社でのリアルタイムAPIの実現をNGINXが支援します。
