Amazon EKSへのNGINX Ingress Controllerのデプロイ：テスト方法

Amir Rawdatソリューションエンジニア

NGINXでは、ソフトウェアを最大限に活用していただくための方法を常に追求しています。NGINXが提供する重要なリソースの1つが、ソリューション概要とサイジングガイドです。さまざまなコンピューティング能力で期待できるパフォーマンスを実証的にテストすることで、既存のインフラストラクチャを活用してアプリケーションデリバリーのパフォーマンスを最大化し、想定するパフォーマンスとスケールに必要な運用コストを正確に算出できるよう支援します。

このたび、NGINX Ingress Controllerソリューション概要を更新し、Amazon Elastic Kubernetes Service（EKS）のサイジングガイドラインを追加しました。この概要では、Amazon EKSのさまざまなインスタンスタイプでNGINX Ingress Controllerを実行した場合に期待できるパフォーマンスと、月間総所有コスト（TCO）の見積もりを示しています。本ブログでは、これらの数値を算出した方法を説明するとともに、同様のテストを実施するために必要な情報をすべてご紹介します。

トポロジー

次の図は、テストで使用したトポロジーを示しています。

• 管理者は、以降のセクションに記載されているコマンドを実行してテストを行うユーザーです。
• Amazon ECR（Elastic Container Registry）は、テストで使用する公式のNGINX Plus Ingress Controller Dockerイメージをホストしています。詳しくは「NGINX Plus Ingress Controllerのデプロイ」を参照してください。
• Amazon EC2（Elastic Compute Cloud）は、wrkを実行してリクエストを生成するc5n.9xlargeイメージをホストします。詳しくは「テスト方法」を参照してください。
• Amazon EKS（Elastic Kubernetes Service）は、NGINX Plus Ingress Controllerとバックエンドアプリケーション用のc5n.9xlargeイメージをホストします。詳しくは「Amazon EKSクラスターの作成」を参照してください。
• NGINX Plus Ingress Controllerは、wrkが生成したリクエストをバックエンドアプリケーションにプロキシし、アプリケーションからのレスポンスを返します。詳しくは「Deploying NGINX Plus Ingress Controller」を参照してください。
• バックエンドアプリケーションは、NGINXによってプロキシされたリクエストに応答します。詳しくは「バックエンドPodのデプロイ」を参照してください。

Amazon EKSクラスターの作成

EKSクラスターをデプロイする前に、図中の「Admin」アイコンで示されているローカルマシンで、次の手順を実行します。

1. Amazon EKSの公式コマンドラインインターフェイスである「eksctl」をダウンロードします。マシンに「eksctl」がすでにインストールされている場合は、必ず最新バージョンに更新してください。
2. 適切なAWS管理者認証情報を「${HOME}/.aws/credentials」ファイルに追加します。
3. このブログ用のYAMLファイルをGistリポジトリからダウンロードします。
4. GitHubのrbac.yaml（NGINX App Protectを使用している場合は、ap-rbac.yaml）を、NGINX Ingress Controllerリポジトリからダウンロードします。

EKSクラスターをデプロイするには、ローカルマシンで次のeksctlコマンドを実行します。（--nodesフラグは省略しています。デフォルトでは、このコマンドによってテストに必要な2つのノード（NGINX Plus Ingress Controller用と基本バックエンドアプリケーション用）が作成されるためです。）

注：EKSクラスターは、us-west-1以外の任意のリージョンにデプロイできます。このリージョンでは、Amazon Marketplace for ContainersでNGINX Plus Ingress Controllerイメージをサブスクライブすることはサポートされていません（次のセクションを参照）。

# eksctl create cluster --instance-types=c5n.9xlarge --managed --ssh-access=true --ssh-public-key=/path/to/public-key

SSH経由でクラスターノードに接続するには、次のコマンドを実行します。テスト中は、NGINX Plus Ingress Controllerノードに接続してhtopコマンドを実行し、wrkクライアントからの負荷によってノードのCPU使用率が100%に達することを確認する必要があります。

# ssh -i /path/to/private-key ec2-user@<public-IP-address-of-EKS-node>

NGINX Plus Ingress Controllerのデプロイ

Amazon EKSへのNGINX Plus Ingress Controllerのデプロイが、これまで以上に簡単になりました。

1. EKSクラスター用のOIDC IDプロバイダー（IdP）を作成します。

# eksctl utils associate-iam-oidc-provider --region=<eks-cluster-region> --cluster=<eks-cluster-name> --approve

1. EKS用の標準的なペアであるiamserviceaccount（IAMロールとサービスアカウント（IRSA））を作成し、NGINX Plus Ingress Controllerイメージの使用状況を監視してデプロイを承認するためのAWSMarketplaceMeteringRegisterUsage IAMポリシーをアタッチします。このコマンドにより、iamserviceaccountにリンクするアノテーションが付いたサービスアカウントが自動的に作成されます。

# eksctl create iamserviceaccount --name <service-account-name> --namespace nginx-ingress --cluster <eks-cluster-name> --region <eks-cluster-region> --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve

1. RBAC用のYAMLファイルで、nameの値を、subjectsフィールド内で、前の手順で設定したservice-account-nameと一致するように編集します。該当箇所は、rbac.yamlの104行目とap-rbac.yamlの23行目です。必要に応じてnamespaceの値（105行目または24行目）も編集してください。ただし、上記のコマンドではデフォルト値のnginx-ingressを使用しています。
2. YAMLファイルを適用します（必要に応じてap-rbac.yamlに置き換えてください）。

# kubectl apply –f rbac.yaml

1. ローカルマシンにDockerクライアントソフトウェアをインストールします。
2. Subscribe to the NGINX Plus Ingress Controller (Premium Edition)のリスティングをAmazon Marketplace for Containersでサブスクライブします。
3. NGINX Plus Ingress ControllerのDockerイメージをホストするAmazon ECRで、Dockerクライアントを認証します。
4. 次の値を編集します：nginx-ingress.yaml:
   • kubernetes.io/hostname（nodeSelectorフィールド内、23行目）– EKSクラスター内のNGINX Plus Ingress Controllerノードのラベル。kubectl get nodes --show-labelsコマンドで取得します
   • serviceAccountName（24行目）— iamserviceaccount IRSAの名前。service-account-nameとしてステップ2で指定したものです。
   • image（containersフィールド内、26行目）– Amazon ECR内のNGINX Plus Ingress Controller Dockerイメージの場所
5. YAMLマニフェストを適用します：

# kubectl apply –f nginx-ingress.yaml

バックエンドPodのデプロイ

バックエンドアプリケーションをデプロイするには、次の手順を実行します。

1. In backend-deployment.yamlで、kubernetes.io/hostnameの値をnodeSelectorフィールド（15行目）で編集し、kubectl get nodes --show-labelsコマンドで取得したラベルに置き換えます。
2. YAMLマニフェストを適用します：

# kubectl apply –f backend-deployment.yaml

1. バックエンドアプリケーションを3つのレプリカにスケールし、wrkによって生成される負荷を処理できるようにします：

# kubectl scale deployment web-server-payload --replicas=3

テスト方法

Amazon EC2でホストされているクライアントc5n.9xlarge AMIで、次のwrkコマンドを実行します。各テスト実行時にNGINX Plus Ingress ControllerインスタンスのCPU使用率が100%に達するよう、必要に応じて値を調整してください。

# wrk -t <number-of-threads> -c <number-of-connections> -d 180s http[s]://<address-of-NGINX-Plus-Ingress-Controller>

• The –cオプションでは、作成するTCP接続数を指定します。CPU使用率が100%に達するよう、必要に応じてこのオプションを設定してください。接続数は最大500です。
• The –dオプションでは、トラフィックを生成する時間（各テスト実行の継続時間）を指定します。このオプションを180秒（3分）に設定します。
• The –tオプションでは、作成するスレッド数を指定します。CPU使用率が100%になるよう、必要に応じて最大16スレッドまで設定してください（テスト実行中にクライアントで使用する各CPUにつき1スレッド）。

テストでは、2021年7月時点でGitHubから入手可能だったバージョンのwrkを使用しました。テストを再現する際は、最新バージョンの使用を推奨します。

テストを実行し、次の2つのパフォーマンス指標を収集します。

• 1秒あたりのリクエスト数（RPS） – NGINX Plus Ingress Controllerが1秒あたりに処理できるリクエスト数を、一定期間で平均した値です。この場合、http://スキームをwrkコマンドで使用します。NGINX Plus Ingress Controllerは1 KBのファイル（静的コンテンツ）へのリクエストを受け付け、バックエンドのアプリケーションPod間で負荷分散します。このファイルは、小さなCSSファイルやJavaScriptファイル、または非常に小さな画像とほぼ同じサイズです。
• 1秒あたりのSSL/TLSトランザクション数（TPS） – NGINX Plus Ingress Controllerが1秒あたりに確立して処理できる新規HTTPS接続の数です。この場合、https://スキームをwrkコマンドで使用します。2048ビットの鍵長のRSAとPerfect Forward Secrecyを使用します。SSL暗号スイートはECDHE-RSA-AES256-GCM-SHA384です。クライアントは、それぞれ新しい接続を使用して一連のHTTPSリクエストを送信します。クライアントとNGINX Plus Ingress ControllerはTLSハンドシェイクを実行してセキュアな接続を確立します。その後、NGINX Plus Ingress Controllerがリクエストを解析し、0 KBのレスポンスを返します。リクエストの処理が完了すると、接続は閉じられます。

「Amazon EKSクラスターの作成」で説明したように、簡略化のため、各テスト実行時にNGINX Plus Ingress Controllerをc5n.9xlargeインスタンス上で実行できます。各テスト実行時に使用可能なCPU数（「パフォーマンス分析」の表に記載されている1～36）を制御するには、worker_processesディレクティブのパラメーターを設定します。

使用ソフトウェア

テストには、以下のソフトウェアを使用しました。

• The client machine running wrkを実行するクライアントマシンが、Ingress Controllerによってプロキシされるトラフィックを生成しました。テストには、2021年7月時点でGitHubから入手可能だったバージョンのwrkを使用しました。テストを再現する際は、最新バージョンの使用を推奨します。
• NGINX Plus Ingress Controllerバージョン1.11.0
• 3台すべてのマシンで、OpenSSL 1.0.2k–fipsを搭載したAmazon Linux 2 LTSを実行

パフォーマンス分析

前述のとおり、すべてのテスト実行でNGINX Plus Ingress Controllerをc5n.9xlargeインスタンス上で稼働させ、使用するCPU数はworker_processesディレクティブで制御しました。以下の表に、各CPU数に対応するc5nファミリーのインスタンスタイプと、そのインスタンスタイプの月間TCOを示します。

この表は、テスト方法に記載されたテストに基づき、NGINX Plus Ingress Controllerで利用可能なCPU数ごとに達成したRPSとSSL TPSを示しています。

CPU数を増やしてもRPSは比例して増加せず、実際にはCPU数が多くなるほど向上率が低下する傾向がある点に注意してください。16コアを超えると向上率はさらに低下します。これは、c5n.9xlargeインスタンスではハイパースレッディングが有効で、18コア、1コアあたり2スレッド、合計最大36 CPUを搭載しているためです。ハイパースレッディングによるRPSの向上はわずかです。

SSL TPSとCPU数の関係も線形ではありませんが、16 CPUを超えてスケールするまでは、それほど大幅には伸びが鈍化しません。ハイパースレッディングは、TLSハンドシェイクなど、CPU負荷が高く並列化可能な処理のパフォーマンスを向上させます。そのため、18 CPUを超えてスケールした場合でも、SSL TPSのパフォーマンスは向上します。

まとめ

Amazon EKSで稼働するNGINX Plus Ingress Controllerの想定パフォーマンスを判断するために利用できる、デプロイの詳細を紹介しました。この情報は、他のEKSインスタンスファミリーのテストや、Kubernetesの本番ワークロードに求められるパフォーマンスとスケーリングの要件を満たす、手頃な価格のソリューションのプロビジョニングに活用できます。

HTTP RPSの測定結果では、CPU数を2倍にするにつれてパフォーマンス向上率が低下し、約300,000 RPSに収束することが示されています。一方、SSL TPSの測定結果では、TLSハンドシェイクがCPUに依存する処理であるため、ハイパースレッディング（1コアあたり2スレッドを使用）を開始した後も、CPU数を2倍にするにつれてパフォーマンスがほぼ直線的に向上することが示されています。

ソリューション概要をご覧いただき、NGINX Plus Ingress Controllerのパフォーマンスを実際にお試しください。今すぐ始めましょう。

NGINX Open SourceでNGINX Ingress Controllerをお試しいただくには、ソースコードを入手するか、DockerHubからビルド済みコンテナをダウンロードできます。

著者について

Amir Rawdatソリューションエンジニア

Amir Rawdatのその他のブログ記事