NGINX、Kong、AmazonのAPI管理ソリューションをベンチマーク：APIをリアルタイムで提供できるか？

NGINX | 2020年7月14日

スピードは、今日のデジタル環境において極めて重要です。アプリのパフォーマンスが遅すぎると、消費者は簡単に競合サービスへ乗り換えてしまいます。アプリの速度を最終的に左右するのは、応答性、健全性、適応性に優れたAPIです。また、APIの応答性を決める重要な要因の1つが、APIゲートウェイによって生じるレイテンシーです。ただし、すべてのAPIゲートウェイが同等のパフォーマンスを発揮するわけではありません。

昨秋、消費者信用業界の大手企業であるNGINXのお客さまから、ユーザーが期待するデジタル体験を提供するために通信を必要とするアプリやその他のコンポーネントが増えるにつれ、「リアルタイム」のAPIパフォーマンスがますます重要になっているとのお話を伺い、この点を改めて実感しました。お客さまが必要としていた最短10ミリ秒（ms）という極めて低いAPIレイテンシを実現できたAPIゲートウェイはNGINX Plusだけだったと知り、非常にうれしく思いました。ほかにも多くのお客さま（Capital Oneなど）から、NGINX Open SourceまたはNGINX PlusをAPIゲートウェイとして使用することで、レイテンシを短縮し、スループットを向上させた事例を伺っています。

そこで、APIエコシステムをさらに詳しく調査し、APIが「リアルタイム」であるための条件を明らかにすることにしました。さまざまな要因に基づいて検討した結果、リアルタイムAPIでは、API呼び出しをエンドツーエンドで30 ms未満に処理する必要があると判断しました。この条件は99パーセンタイルまでのすべてのパーセンタイルで満たす必要があります（つまり、30 msを超える呼び出しは平均で100回に1回のみです）。

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

F5独自のテストでは、API呼び出しを処理するAPIゲートウェイとしてNGINX Plusを使用し、NGINX Controller API Management ModuleでNGINX PlusインスタンスとAPIの両方を管理するF5のAPI管理ソリューションにより、リアルタイムのAPIパフォーマンスを容易に実現できることが一貫して示されています。このモジュールでは、APIの定義、公開、管理、監視をライフサイクル全体にわたって行えます。

しかし、F5の説明だけでは判断できないとお考えになるかもしれません。そこで、独立系の技術調査・分析会社であるGigaOmに、F5のAPI管理ソリューションと市場で広く利用されている他のソリューションについて、客観的かつ透明性の高いベンチマーク評価を依頼しました。対象は、NGINXと同様にオンプレミスまたはクラウドに導入できる2つのソリューション、ApigeeとKong Enterprise、およびフルマネージド型クラウドサービスであるAmazon API GatewayとKong Cloudです。

このブログでは、GigaOmによるテスト結果をまとめています（先に結論をお伝えすると、テストしたすべての条件でAPIをリアルタイムに配信できたのはNGINX Plusだけでした）。各ソリューション、テスト方法、結果の詳細については、F5の担当者までお問い合わせください。

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

ベンチマークの概要

GigaOmは、Vegeta HTTP負荷テストツールを使用してリクエスト（API呼び出し）を生成し、GigaOmが「攻撃レート」と呼ぶさまざまな1秒あたりのリクエスト数（RPS）において、APIゲートウェイによって生じるレイテンシー（API呼び出しに対するレスポンスが返されるまでの時間）を測定しました。GigaOmは、攻撃レートを1,000 RPSから開始し、5,000、10,000、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つのベンチマークを実施しました。最初のベンチマークでは、ワーカーノードは1台（NGINX PlusまたはKong Nodeの1インスタンス）でした。2つ目のベンチマークでは、3台のワーカーノードに対し、NGINX Open Sourceを使用してラウンドロビン方式で負荷分散を行いました。（GigaOmは、NGINX Open Sourceをロードバランサーとして使用してもNGINX Plusが有利になることはなく、Kongもクラスタ化されたKong Nodeインスタンスに使用するロードバランサーとしてNGINX Open Sourceを推奨していると強調しています。）

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

99パーセンタイルは、APIをリアルタイムと定義するうえで妥当な最低基準です。しかしGigaOmは、実環境への導入では、99.9パーセンタイルや99.99パーセンタイルといった、より高いパーセンタイルでも低レイテンシを維持することが「極めて重要」であると指摘しています。レポートでは次のように説明しています。

レイテンシーの測定結果は、時間の経過に伴って複数のピークを示す傾向があり、スパイクの頂点は応答時間の一時的な「停滞」を表します。

こうした一時的な遅延は重要です。応答時間またはレイテンシの中央値が30 ms未満でも、1秒以上の遅延が一時的に発生すると、その後のユーザー体験に累積的な影響が及びます。たとえば、ファストフード店のドライブスルーで、商品を受け取るまでの待ち時間の中央値が1分なら、良好な顧客体験だと感じるでしょう。しかし、前の顧客の注文に問題があり、解決に10分かかったらどうでしょうか。実際の待ち時間は11分になります。一時的な遅延の後にリクエストが処理待ちの列に加わるため、99.99パーセンタイルで発生した遅延が、自分のリクエストの遅延にもなり得ます。

高パーセンタイルで異常に大きなレイテンシーが生じることによる悪影響は、1件のクライアントリクエストから複数のダウンストリームAPI呼び出しが発生する可能性がある分散アプリケーションでは、さらに深刻になります。たとえば、1件のクライアントリクエストによって、応答が遅くなる確率が1%のサブシステムに対して10件のAPI呼び出しが行われるとします。その場合、この1件のクライアントリクエストが遅い応答の影響を受ける確率は10%近くになることを数学的に示せます。計算の詳細については、99パーセンタイルのレイテンシーはどこへ行った？

図1は、単一のワーカーノードに対して30,000 RPSの攻撃レートで実施した結果を示しています。99.99パーセンタイルでは、KongのレイテンシはNGINXの3倍を超え、リアルタイムAPIのしきい値である30 msを上回っています。一方、NGINX Plusはすべてのパーセンタイルでリアルタイムのレイテンシを達成しており、記録された最大（最大）レイテンシの13 msでさえ、リアルタイムのしきい値の半分未満です。

図1. 1ノード構成で30,000 RPSを処理するNGINX ControllerとKong Enterprise

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

図2. 3ノード構成で30,000 RPSの場合のNGINX ControllerとKong Enterprise

APIゲートウェイのパフォーマンスを評価するもう1つの方法は、単一ノード構成と3ノード構成の両方について、成功率100%（5xxまたは429 [Too Many Requests]エラーなし）かつ、すべてのパーセンタイルでレイテンシが30 ms未満となる、処理可能な最大RPSを特定することです。図3に示すように、この指標では、NGINXはKongより50%高いRPSを維持しています（30,000対20,000）。

図3. エラーなしで達成した最大スループット

結果：NGINXとKong CloudおよびAmazon API Gatewayの比較

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 msというしきい値の7倍を超えており、99.99パーセンタイルでは、そのしきい値を8,000%以上上回っています。つまり、Kong CloudまたはAmazon API Gatewayが、レイテンシを30 ms未満に抑えながら100%の成功率を達成できる条件は存在しないことが明らかです。

図4. 1ノード、5,000 RPSでのNGINX Controller、Amazon API Gateway、Kong Cloud

唯一のリアルタイムAPIソリューションとしてのNGINXを検証

要約すると、GigaOmがテストしたソリューションのうち、リアルタイムAPI処理の基準を満たし、すべてのパーセンタイルで30 ms未満のレイテンシを達成したのはNGINXだけです。Kong Enterpriseは99パーセンタイルではリアルタイム性能を達成していますが、それより高いパーセンタイルではレイテンシが大幅に急増するため、中程度の量であってもリアルタイムAPI処理を必要とする本番環境には適していません。テストした2つのSaaSソリューションはいずれも、リアルタイムに分類できません。

GigaOmのレポートは、当社が以前実施したベンチマークと、お客さまから寄せられた声の両方を裏付けています。NGINX Plusは市場最速のAPIゲートウェイであり、すべてのパーセンタイルで30 ms未満のレイテンシーを維持できる唯一のAPIソリューションです。さらに、NGINX Controllerと組み合わせることで、独自のアーキテクチャを採用したAPI管理ソリューションを利用できます。APIゲートウェイのデータプレーン（NGINX Plus）とAPI管理のコントロールプレーン（NGINX Controller）が慎重に分離されているため、コントロールプレーンがデータプレーンのパフォーマンスに影響を及ぼすことは一切ありません。

F5のrtapiレイテンシ測定ツールを使用して、お客さまのAPIパフォーマンスをテストできます。ツールをお試しのうえ、F5までお問い合わせください。APIのリアルタイム化をどのように支援できるか、ご相談いただけます。