Benchmarking Envoy Proxy, HAProxy, and NGINX Performance on Kubernetes

Kubernetes 上のEnvoy Proxy、HAProxy、NGINXパフォーマンスのベンチマーク

一般的なKubernetesデプロイメントにおいて、Kubernetesサービスへのすべてのトラフィックは イングレスを通して流れていきます。イングレスはインターネットからバックエンドサービスへトラフィックの代理（プロキシ）をします。このようにイングレスはパフォーマンスに対してのcritical path上にあります。ベンチマークとパフォーマンスの測定には色々な種類の方法があります。

プロキシパフォーマンスを測定する方法で最も一般的なのは、おそらくロースループットです。このタイプのテストでは、トラフィックの量の増加はプロキシを通って送信されます。そしてプロキシが加工できる最大のトラフィック量が測定されます。これの典型的な測定方法は1秒間に処理を行うHTTPリクエストの数(RPS)での測定です。

現実では、しかしほとんどの組織では、モダンなプロキシのスループット制限をプッシュしようとはしません。さらに言えば、スループットは直線的にスケールします。プロキシがスループット上でマックスになると、セカンドインスタンスは効果的にスループットをダブルにするためにデプロイされます。

この記事では異なるタイプのパフォーマンスについてご紹介します。レイテンシーについてです。プロキシがリクエストを解析し、適切な宛先にルーティングするため、プロキシを介した各リクエストにはわずかなレイテンシーが生じます。スループットと違い、レイテンシーは単純にプロキシの数をスケールアウトするだけでは改善されません。そして重要なのは、レイテンシーは、重要なビジネスメトリック上で重大な影響を及ぼすということです。.

Edge Proxies in Kubernetes

Kubernetes上のEdge Proxyについてです。間違いなく、現在人気の高いL7プロキシは Envoy Proxy、 HAProxy、 NGINXの三つです。Kubernetesではそれらのプロキシは直接デプロイされるのではなく、一般的にコントロールプレーンを通してコンフィギュアされます。この記事ではそれら３つの人気のあるオープンソースコントロールプレーン/プロキシのコンビネーションをKubernetes上でテストします：

• ingress-nginx、Kubernetesのための最も一般的なイングレスで、NGINX上で構築されます。私たちは nginx-ingress-controller:0.25.0を使いましたが、これはOpenResty 1.15.8ベースのもので、次にはNGINX 1.15.8をベースにしています。
• HAProxyイングレスコントローラー（https://github.com/jcmoraisjr/haproxy-ingress）、バージョン 0.7.3。これは1.8.21がベースになっています。私たちは公式なHAProxyイングレスコントローラーを使おうとしましたが、テストの時点では、公式なコントローラーが8つのコンフィグレーションオプションのみをエクスポーズするというので、ベンチマークには使用できませんでした。最近では、 25のコンフィグレーションオプションまで広がっています。
• Ambassador Pro。これはEnvoy Proxy上で構築され、 opt Compilationモードを使います。オープンソースのAmbassadorは現在 dbg モードを伴うEnvoyを使用していて、最適化をコンパイルしません。私たちは近い将来、最適化されたEnvoyのビルドを使用するように、オープンソースのAmbassadorに切り替える予定です。

Benchmarking latency on Kubernetes

Kubernetes上のベンチマークレイテンシーについてです。

コンテナ化した環境はelastic（伸縮自在）でephemeral（短命）です。コンテナはユーティライゼーションの変化に伴い生成され、壊されます。コンテナ化したマイクロサービスの新しいバージョンがデプロイされ、新しいルートが登録されました。デベロッパーたちは、リアルワールドメトリックデータ上のタイムアウト、レート制限、また他のコンフィグレーションパラメータを調整しようと思うでしょう。

我々のベンチマークでは、HTTP / 1.1リクエストの安定したストリームを、TLS経由でエッジプロキシを介して3つのポッドで実行されているバックエンドサービス(https://github.com/hashicorp/http-echo)に送信します。TLSターミネーションを実行するためにedge proxyはコンフィギュアされます。それから我々は、このプロセスの間レイテンシーをサンプリングしながら、４つのポッドにバックエンドサービスをスケールアップし、30秒ごとに３つのポッドへそれをスケールダウンしました。そしてこの工程を３回繰り返しました。30秒のインターバルで3つの変化が起きたことによりルートコンフィグレーションの変化をシミュレーションします。

• CORS ヘッダー
• カスタムレスポンスヘッダーの追加
• リクエストパスのリライト

それから、我々は、ベースのコンフィグレーションに戻ります。リクエストの10％のレイテンシーを測定し、グラフ上のレイテンシーを個別にプロットします。

Test Setup

テストの設定です。すべてのテストは n1-standard-1 ノード上のGoogle Kubernetes Engineで走らされました。３つのノードポールは使用されていました：一つがイングレスのため、もう一つはバックエンドサービス、もう一つがロードジェネレーターのためです。それぞれのノードポールは３つの別々のノードで構成されています。それぞれのイングレスはイングレス ノードポールの中のそれぞれのノードに割り当てられました。そしてイングレス全部がエンドポイントをサービスするためやkube-proxyのバイパスするためにルートに直接にコンフィギュアされました。 Vegetaはロードを生成するために使われました。Ambassadorを使って、私たちは kube-proxyをバイパスするためにエンドポイントのルーティングをコンフィギュアしました。

一般的には、２つの例外はありましたが、全てのイングレスのためのデフォルトのコンフィグレーションが使用されました：

• NGINXを使って、接続を再利用するため、デフォルト100～2147483647の keep-alive-requestsを増加しました。
• Ambassadorを使って, エンドポイントのルーティングがバイパスの kube-proxyによってユーティライズされました。 (これをNGINX やHAProxyのために変更する必要はありませんでした。なぜならば、デフォルトでエンドポイントのルーティングを使っているからです。)

多くのエンジニアたちがテストのコンシステンシー（一貫性）をテストするためにたくさんのテストランが実施されました。

Results: 100 RPS

1秒あたり100リクエストのロードで、バックエンドサービスが約1000msに拡大または縮小するときにHAProxyにリクエストします。それらのスパイクのデュレーションは約900 msです。

NGINXはHAProxyよりもわずかながら優れたパフォーマンスを有しています。レイテンシーのスパイクは約750ms(

最初のスケールアップを除く）です。それらのレイテンシースパイクはおよそ900 ms続きます。

AmbassadorとEnvoy Proxyを使用することで、我々は明確によりよいパフォーマンスを見ることができました。ここでグラフの異なるY軸に注意してください。 25msのスタートアップレイテンシースパイク以外のレイテンシースパイクの明確なパターンは発生しません。 ほとんどの遅延は5ミリ秒未満です。

コンテクストの中でこれらの数字を全部見るために、共有のスケールを伴った単一のグラフ上でのすべてのレイテンシーナンバーをオーバーレイしました：

Results: 500 RPS

500 RPSで、HAProxyに対する我々はより大きなレイテンシースパイクが見られます。これはデュレーションとレイテンシーの両方で増加します。レイテンシーは最大10秒までスパイクし、これらのレイテンシースパイクは数秒続くことがあります。

このシナリオでは、NGINXのパフォーマンスはHAProxyよりも大幅に向上し、100 RPSの場合と同様の持続時間で1秒前後に一貫したレイテンシースパイクが発生します。

Ambassador / Envoyを使用すると、一般にレイテンシーは10ミリ秒未満のままです。 また、約200msのテストの終わりになるにつれ、原因不明の大きなレイテンシースパイクが発生します。 （これは私たちのテストに関連するものだと思いますが、現在さらなる調査を行っているところです。）

もう一度言いますが、我々はすべての数字を統合されたチャート上のコンテクストの中で見ることができます：

Results: 1000 RPS

最後に、1000 RPSでテストしました。HAProxyレイテンシースパイクはより悪化しました。リクエストによっては25秒かかる場合があります。

NGINXはかなりの差でHAProxyをアウトパフォームします。しかし、レイテンシーは、ポッドがスケールアップやスケールダウンをしている時にスパイクします。

面白いことに、ルートコンフィグレーションを調整するときに、つまり、顕著なレイテンシーが以前に観測されていなかったときに、大幅なレイテンシースパイクが見られます。

Ambassador/Envoyを使うことで、短いスタートアップレイテンシスーパイクと別の異常なレイテンシスーパイクが見られます。 全体のレイテンシーは優れたままで、通常は10ms未満です。

もう一度言いますが、我々はすべての数字を統合されたチャート上のコンテクストの中で見ることができます：

まとめ

elastic環境で（負荷のかかる状況で）リスポンスのレイテンシーの計測することは、重要ですがイングレスのパフォーマンスはよく見落とされがちです。組織がKubernetesにより多くのワークロードをデプロイするにつれ、エンドユーザーエクスペリエンスを最適化するための重要な考慮事項は、イングレスソリューションが低いレスポンスレイテンシーを出し続けることです。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。