NGINX では、お客様が当社のソフトウェアを最大限に活用できるようにするための方法を常に模索しています。 弊社が提供するソリューション概要とサイジング ガイドは、重要なリソースの 1 つです。さまざまなレベルのコンピューティング能力で期待できるパフォーマンスを実験的にテストすることで、既存のインフラストラクチャでアプリケーション配信のパフォーマンスを最大化し、準備しているパフォーマンスとスケールに対する正確な運用コストを決定できるように支援します。
最近、 NGINX Ingress Controller ソリューション概要を更新し、Amazon Elastic Kubernetes Service (EKS) のサイズ設定ガイドラインを追加しました。 この概要では、Amazon EKS のさまざまなインスタンスタイプで実行される NGINX Ingress Controller で達成できると期待されるパフォーマンスと、推定される月間総所有コスト (TCO) について説明します。 このブログでは、これらの数値をどのようにして導き出したか、また、同様のテストを独自に行うために必要なすべての情報について説明します。
次の図は、テストに使用されたトポロジを示しています。
wrk が
実行されてリクエストを生成する c5n.9xlarge イメージをホストします。 テスト方法を参照してください。wrk
によって生成されたリクエストをバックエンド アプリケーションにプロキシし、アプリケーションの応答を返します。 NGINX Plus Ingress Controller のデプロイを参照してください。EKS クラスターをデプロイする前に、図の管理者アイコンで表されるローカル マシンで次の手順を実行します。
eksctl を
ダウンロードします。 すでにマシンにeksctl
がインストールされている場合は、必ず最新バージョンに更新してください。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 を Amazon EKS にデプロイすることが、これまでになく簡単になりました。
EKS クラスター用の OIDC アイデンティティ プロバイダー (IdP) を作成します。
# eksctl utils associate-iam-oidc-provider --region=< eks-cluster-region > --cluster=< eks-cluster-name > --approve
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
RBAC の YAML ファイルで、 subjects
フィールドのname
の値を編集し、前の手順で設定したservice-account-name
と一致させます。 これは、 rbac.yamlの 104 行目とap-rbac.yamlの 23 行目にあります。 必要に応じて namespace の値も編集します (行 105 または行 24)。ただし、上記のコマンドではデフォルトのnginx-ingress
が使用されます。
YAML ファイルを適用します (必要に応じてap-rbac.yamlを置き換えます)。
# kubectl apply –f rbac.yaml
ローカル マシンにDocker クライアントソフトウェアをインストールします。
Amazon Marketplace for ContainersでNGINX Plus Ingress Controller (Premium Edition)のリストに登録します。
NGINX Plus Ingress Controller Docker イメージをホストする Amazon ECR を使用して Docker クライアントを認証します。
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 イメージの場所YAML マニフェストを適用します。
# kubectl apply –f nginx-ingress.yaml
バックエンド アプリケーションをデプロイするには、次の手順を実行します。
backend-deployment.yamlで、 nodeSelector
フィールド (行 15) のkubernetes.io/hostname
の値を編集し、 kubectl
get
nodes
--show-labels
コマンドから取得したラベルを置き換えます。
YAML マニフェストを適用します。
# kubectl apply –f バックエンドデプロイメント.yaml
バックエンド アプリケーションを、 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 を
使用しました。テストを再現する際には、現在のバージョンを使用することをお勧めします。前述のように、 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 のパフォーマンスは向上します。
AWSインスタンスタイプ | CPU | RPSA | SSL TPS (RSA) | 平均月間TCO |
---|---|---|---|---|
c5n.大きい | 1 | 45,000 | 6,700 | 100ドル |
c5n.大きい | 2 | 80,000 | 12,600 | 100ドル |
c5n.特大 | 4 | 135,000 | 23,000 | 200ドル |
c5n.2xlarge | 8 | 175,000 | 40,000 | 400ドル |
c5n.4xlarge | 16 | 237,000 | 68,500 | 795ドル |
c5n.9xlarge | 32 | 290,000 | 88,800 | 1790ドル |
c5n.9xlarge | 36 | 300,000 | 92,800 | 1790ドル |
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からビルド済みのコンテナーをダウンロードします。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"