Amazon EKS に NGINX Ingress Controller をデプロイする: テスト方法

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によって生成されたリクエストをバックエンド アプリケーションにプロキシし、アプリケーションの応答を返します。 NGINX Plus Ingress Controller のデプロイを参照してください。
• バックエンド アプリケーションは、 NGINX によってプロキシされたリクエストに応答します。 「バックエンド ポッドのデプロイ」を参照してください。

Amazon EKS クラスターの作成

EKS クラスターをデプロイする前に、図の管理者アイコンで表されるローカル マシンで次の手順を実行します。

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

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

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

# eksctl クラスターを作成 --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@< EKS ノードのパブリック IP アドレス>

NGINX Plus Ingress Controllerの導入

NGINX Plus Ingress Controller を Amazon EKS にデプロイすることが、これまでになく簡単になりました。

1. EKS クラスター用の OIDC アイデンティティ プロバイダー (IdP) を作成します。

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

2. EKS の標準のIAM ロールとサービス アカウント(IRSA) のペアであるiamserviceaccountを作成し、NGINX Plus Ingress Controller イメージの使用状況を監視し、デプロイメントを承認するためのAWSMarketplaceMeteringRegisterUsage IAM ポリシーをアタッチします。 このコマンドは、 iamserviceaccountにリンクする注釈が付いたサービス アカウントを自動的に作成します。

   # eksctl create iamserviceaccount --name <サービスアカウント名> --namespace nginx-ingress --cluster < eks クラスター名> --region < eks クラスターリージョン> --attach-policy-arn arn:aws:iam::aws:policy/AWSMarketplaceMeteringRegisterUsage --approve
   

3. RBAC の YAML ファイルで、 subjectsフィールドのnameの値を編集し、前の手順で設定したservice-account-nameと一致させます。 これは、 rbac.yamlの 104 行目とap-rbac.yamlの 23 行目にあります。 必要に応じて namespace の値も編集します (行 105 または行 24)。ただし、上記のコマンドではデフォルトのnginx-ingressが使用されます。

4. YAML ファイルを適用します (必要に応じてap-rbac.yamlを置き換えます)。

   # kubectl apply –f rbac.yaml
   

5. ローカル マシンにDocker クライアントソフトウェアをインストールします。

6. Amazon Marketplace for ContainersでNGINX Plus Ingress Controller (Premium Edition)のリストに登録します。

7. NGINX Plus Ingress Controller Docker イメージをホストする Amazon ECR を使用して Docker クライアントを認証します。

8. nginx-ingress.yamlで次の値を編集します。

   • nodeSelectorフィールドのkubernetes.io/hostname (行 23) – EKS クラスター内の NGINX Plus Ingress Controller ノードのラベル。kubectl get nodes --show- labelsコマンドから取得されます。
   • serviceAccountName (行 24) —手順 2でservice-account-nameとして指定されたiamserviceaccount IRSA の名前。
   • コンテナフィールドのイメージ（26行目） – Amazon ECR 内の NGINX Plus Ingress コントローラー Docker イメージの場所

9. YAML マニフェストを適用します。

   # kubectl apply –f nginx-ingress.yaml
   

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

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

1. backend-deployment.yamlで、 nodeSelectorフィールド (行 15) のkubernetes.io/hostnameの値を編集し、 kubectl get nodes --show-labelsコマンドから取得したラベルを置き換えます。

2. YAML マニフェストを適用します。

   # kubectl apply –f バックエンドデプロイメント.yaml
   

3. バックエンド アプリケーションを、 wrkによって生成される負荷を処理するのに十分な 3 つのレプリカまで拡張します。

   # kubectl スケールデプロイメント web-server-payload --replicas=3
   

テスト方法

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

# wrk -t <スレッド数> -c <接続数> -d 180s http[s]://< NGINX-Plus-Ingress-Controller のアドレス>

• –cオプションは、作成する TCP 接続の数を指定します。 最大 500 の接続で CPU 使用率を 100% にするには、必要に応じてこのオプションを設定します。
• –dオプションは、トラフィックを生成する期間 (各テスト実行の期間) を指定します。 このオプションを 180 秒 (3 分) に設定します。
• –tオプションは、作成するスレッドの数を指定します。 このオプションは、CPU 使用率を 100% にするために必要に応じて設定します (テスト実行中にクライアントで使用される CPU ごとに 1 つずつ、最大 16 個のスレッド)。

2021 年 7 月に GitHub で利用可能なバージョンのwrk を使用しました。テストを再現する場合は、現在のバージョンを使用することをお勧めします。

テストを実行して、2 つのパフォーマンス メトリックを収集します。

• 1 秒あたりのリクエスト数 (RPS) – NGINX Plus Ingress Controller が 1 秒あたりに処理できるリクエストの数 (一定期間の平均)。 この場合、 wrkコマンドでhttp://スキームを使用します。

  NGINX Plus Ingress Controller は、 1 KB のファイル (静的コンテンツ) のリクエストを受け入れ、バックエンド アプリケーション ポッド間で負荷分散します。 ファイルのサイズは、小さな CSS または JavaScript ファイル、あるいは非常に小さな画像とほぼ同じです。

• 1 秒あたりの SSL/TLS トランザクション数 (TPS) – NGINX Plus Ingress Controller が 1 秒あたりに確立して処理できる新しい HTTPS 接続の数。 この場合、 wrkコマンドでhttps://スキームを使用します。 2048 ビットのキー サイズと Perfect Forward Secrecy を備えた RSA を使用します。SSL 暗号はECDHE-RSA-AES256-GCM-SHA384です。

  クライアントは、それぞれ新しい接続で一連の HTTPS リクエストを送信します。 クライアントと NGINX Plus Ingress Controller は TLS ハンドシェイクを実行して安全な接続を確立し、その後 NGINX Plus Ingress Controller がリクエストを解析して0 KB の応答を返します。 要求が満たされると接続は閉じられます。

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

使用ソフトウェア

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

• wrk を実行しているクライアント マシンは、Ingress Controller がプロキシするトラフィックを生成しました。 2021 年 7 月に GitHub で利用可能だったバージョンのwrk を使用しました。テストを再現する際には、現在のバージョンを使用することをお勧めします。
• NGINX Plus Ingress コントローラー バージョン 1.11.0
• Amazon Linux 2 LTS は、OpenSSL 1.0.2k–fips を搭載した 3 台のマシンすべてで実行されました。

パフォーマンス分析

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

この表は、 「テスト方法論」で説明されているテストから、NGINX Plus Ingress Controller で使用可能なさまざまな数の CPU で達成された RPS と SSL TPS の数を報告しています。

RPS は CPU の数が増えても直線的に増加しないことに注意してください。実際、CPU の数が増えると、改善率は低下する傾向があります。 c5n.9xlarge インスタンスはハイパースレッディングが有効になっており、18 個のコアとコアあたり 2 つのスレッドを備え、合計で最大 36 個の CPU を搭載するため、16 コアを超えると改善率がさらに低下します。 ハイパースレッディングでは、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 に依存するため、ハイパースレッディング (コアごとに 2 つのスレッドを使用) を開始した場合でも、CPU の数を 2 倍にするとパフォーマンスがほぼ直線的に増加することを示しています。

ソリューション概要を確認し、NGINX Plus Ingress Controller のパフォーマンスをご自身でテストして、今すぐ始めましょう。

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