NGINX、Opsani、Prometheus でクラウドの Kubernetes コストを 70% 削減

「最悪の事態だ」というのはよく使われるフレーズかもしれませんが、クラウド コンピューティングのコストが急増している場合には有効なフレーズです。 いくつかの要因が重なり合って、この最悪の事態を引き起こしています。

1. ワークロードを展開する人は、その費用を支払う人ではない
2. オンデマンドでプログラム的にインフラストラクチャを利用するのは簡単
3. 簡単にアクセスできるコードリポジトリにより、他の誰かが書いた既存のコードから機能を「借りる」ことが可能になる
4. CI/CDパイプラインとSREプラクティスは、開発者がコードを迅速に統合してデプロイするのに役立ちます。

これらすべてをまとめると、新しいアプリの目的に合わせて合理化も最適化もされていない既存のコード ブロックを活用して、開発者が新しい機能を迅速に展開する動機付けとなる状況が生まれます。市場投入までの時間が最も重要であるため、最適化は後回しにされます (非常に後回しにされます)。 最適化されていないコードがパフォーマンスに悪影響を与える場合は、API 呼び出しを行うだけで、より強力なインフラストラクチャをプロビジョニングできます。 問題は解決しました!

問題をさらに複雑にしているのは、コードを書く人と料金を支払う人の間に、考え方と組織構造の両面で隔たりがあることです。 企業のクラウドコストが増加するにつれて、CFO は苦労します。 しかし、クラウド料金の高騰を引き起こした開発者は、迅速な製品提供で報酬を得ている一方で、自分たちが作り出した下流の財務問題についてはまったく無知である。

この問題を解決するために、F5 NGINX とOpsani は提携して、 F5 NGINX Ingress Controllerサブスクライバーが既存の展開からさらなるメリットを得られる最適化ソリューションを提供しています。 Opsani Servo コンテナがKubeNestワークロードにデプロイされ、Prometheus を活用してレート、エラー、期間 (RED) メトリックを収集すると、NGINX Ingress Controller は最適化されたソリューションになります。 Opsani は、機械学習を活用した自律最適化機能を使用してインフラストラクチャを継続的に最適化し、適切な量のリソースが消費されてパフォーマンスが向上し、コストが削減されるようにします。

クラウド最適化によるコスト削減

NGINX ユーザーは、クラウド コストを削減する最も基本的な方法、つまり、レイテンシを最小限に抑えながら超高速のパフォーマンスを実現する軽量ツールを使用することをすでによく知っています。 そしてもちろん、Kubernetes の世界では、シンプルでありながら強力なツールが、デプロイメントを成功させるための前提条件となります。 このブログでは、次の 3 つのツールを活用して、コストを削減しながらパフォーマンスを向上させる方法について説明します。

• NGINX Ingress コントローラ– F5 NGINX Plusをベースとした Ingress コントローラ。イベント ハンドラや構成の再読み込みなしでバックエンド エンドポイントの変更に動的に適応するため、他の NGINX ベースの Ingress コントローラよりも大幅に優れたパフォーマンスを発揮します。
• Opsani – CI/CD パイプラインに CO を追加し、コードを迅速に提供し、可能な限り低コストでそのコードを最適化して最適なパフォーマンスを実現できるようにする、独自の継続的最適化サービス (COaaS) ソリューションです。
• Prometheus – 監視とアラートのための人気のオープンソース プロジェクト。 NGINX Plus Prometheus モジュールを使用すると、NGINX Plus に基づく NGINX Ingress Controller は数百のメトリックを Prometheus サーバーにエクスポートします。

NGINX Plus ベースの NGINX Ingress Controller バージョンの最も強力な使用例の 1 つは、ライブ モニタリング ( NGINX Plus ダッシュボード経由) と履歴データ (Prometheus 経由) を使用してKubernetes の可視性を向上させる機能です。 さらに、NGINX Ingress Controller はワークロードのフロントエンドとしての役割で、レート、エラー、期間 (RED) のメトリックを収集し、それらを (Prometheus 経由で) Opsani に提供できます。 Opsani は機械学習を使用して、メトリックを現在展開されているインフラストラクチャと相関させ、NGINX Ingress Controller、アプリ、またはテクノロジー スタック全体を最適化する変更を推奨します。 Opsani を設定して、NGINX Ingress Controller に設定されたレイテンシとパフォーマンスのしきい値について警告することもできます。

数字で見る - 最適化テストの結果

Opsani と Prometheus を使用してNGINX Plus ベースのNGINX Ingress Controller をデプロイした場合に期待できる結果の例を見てみましょう。 スクリーンショットに示されているように、Opsani の概要ページには、時間の経過に伴うトラフィック量 (1 秒あたりのリクエスト数、または RPS) が報告され、ベースライン設定と比較した最適化のメリットが強調表示されます。ここでは、インスタンス コスト (1 時間あたり) が 70% 削減され、 P50 応答時間が 5% 向上しています。

私たちは、これらの結果が、最もよく知られている Ingress コントローラーの 1 つである、Kubernetes コミュニティによって GitHub kubernetes/ingress-nginxリポジトリで管理されている NGINX オープンソース ベースの Ingress コントローラーと比べてどうなのか疑問に思いました。 (確立されたNGINX の慣例に従い、このブログの残りの部分ではこれを「コミュニティ Ingress コントローラー」と呼ぶことにします。 NGINX Plus ベースのNGINX Ingress Controller バージョンは、NGINX オープンソース ベースの姉妹版 NGINX Ingress Controller とともに、NGINX エンジニアリング チームによって GitHub nginxinc/kubernetes-ingressリポジトリで管理されています。

2 つの Ingress コントローラのパフォーマンスを 3 つのトポロジでテストしました。

• トポロジ 1 –標準プロセスを使用してデプロイされたコミュニティ Ingress コントローラ。 メトリックは、applicationポッドのサイドカー コンテナー内で、テスト対象のapplicationにインラインで Envoy プロキシを追加することによって収集されました。

  

• トポロジ 2 – Helmを使用してデプロイされた、NGINX Plus に基づく NGINX Ingress コントローラー。 メトリックの収集が最適化パフォーマンス プロセスに影響を与えないように、コミュニティ Ingress Controller と同じ Envoy デプロイメントと構成を使用してメトリックが収集されました。

  

• トポロジ 3 – NGINX Plus をベースにした NGINX Ingress コントローラー。これも Helm を使用してデプロイされます。 メトリックは Prometheus を使用して収集されました。

  

表はテストの結果をまとめたものです。 ご覧のとおり、NGINX Ingress コントローラーは、コミュニティ Ingress コントローラーよりも優れたコスト削減、CPU 最適化、メモリ最適化を実現します。 これは、NGINX Ingress Controller のより効率的な負荷分散によるものと考えられます。

P50 応答時間の結果は、Prometheus が Envoy サイドカー メカニズムに必要な余分なホップを排除するため、メトリックを収集するための理想的な方法であることを示しています。 Envoy は、コミュニティ Ingress コントローラーの P50 応答時間には影響しませんが、NGINX Ingress コントローラーでは実際にレイテンシが 4% 悪化します。 対照的に、Prometheus は NGINX Ingress Controller を使用した場合の P50 応答時間を 5% 改善します。

テストの実行方法については、付録を参照してください。

Opsani が NGINX Ingress コントローラを最適化する方法

Opsani は、動的な環境で負荷分散が不十分な場合でもapplicationsを最適化できます。 あらゆる種類のメトリック入力を活用することもできますが、ネットワーク メトリックを収集する既存のツールから入力が行われると、接続されたサービスの最適化が大幅に改善されます。 この目的のために、シンプルなデプロイメント プロセスを使用して Opsani を NGINX Ingress Controller と統合します。

NGINX が Ingress コントローラーである環境 (これは今日の多くのapplicationsに当てはまります) では、 NGINX Plus ベースのNGINX Ingress コントローラーの使用に簡単に切り替えることで、applicationの機能に影響を与えることなく、より効率的な負荷分散アルゴリズムが提供されます。 2 つ目の利点は、NGINX Ingress Controller によって負荷分散されたapplicationsのメトリックも利用できるようになることです。

唯一の追加要件は、最適化名前空間の下にapplicationを含む単一の Opsani ポッドをデプロイすることです。 NGINX Plus ベースのNGINX Ingress Controller 用の Opsani テンプレートは、Ingress サービスでメトリック エンドポイントを指定して、最適化に必要なapplication固有のメトリックを取得します。 Opsani エンジンは、3 つまたは 4 つのピーク期間からのメトリックを処理することで、わずか数時間以内に最適な最適化レベルに到達します。 現在までに、ピーク負荷の最適化を 30% から 70% まで達成しました。

Opsani と NGINX Ingress Controller を使い始める

NGINX Ingress ControllerとOpsaniの無料トライアルを入手し、NGINX Ingress Controller と Opsani および Prometheus のスクリプトと構成ファイルについては、 GitHub リポジトリをご覧ください。

付録： テスト方法

前提条件

• NGINX Plus ベースのNGINX Ingress Controller はコンテナとして構築されます。
• Kubernetes が構成され、レジストリ アクセス シークレットが利用可能になり、安全なプライベート Docker レジストリへのアクセスが提供されます。
• NGINX Plus ベースのNGINX Ingress Controller は、Helm を介してIngress名前空間にデプロイされます。
• NGINX VirtualServer リソースは、最適化されるサービス (通常はデフォルトでフロントエンド サービス) を指すように構成されます。 例については、GitHut リポジトリのfrontend-virtualserver.yaml を参照してください。

トポロジと構成

Opsani インスタンスを 3 つ作成します。 トポロジ 1 と 2では、すべての Opsani アカウントで利用可能な標準の Opsani Dev テンプレートを使用し、applicationのフロントエンドに NGINX Ingress Controller を配置して、applicationサービスにポイントするだけです。

トポロジ 3では、同じデフォルト テンプレートを使用し、GitHub リポジトリのopsani-manifests-nginx-plus.yamlで定義されている ConfigMap を使用して Servo 構成を変更します。 標準テンプレートと同様に、ConfigMap 内の次の変数に適切な値を置き換えます。

• {{ NAMESPACE }} – ターゲットリソースの名前空間
• {{ DEPLOYMENT }} – ターゲットのデプロイメント
• {{ CONTAINER }} – ターゲットapplicationコンテナ名

さらに、applicationのデプロイメントで公開されたドキュメントに従って、 OPSANI_ACCOUNT_NAME 、 OPSANI_APPLICATION_NAME 、およびOPSANI_TOKENを設定します。

Opsani Dev のデフォルトのServoXには Prometheus インスタンスが含まれていますが、代わりに、ClusterRole 構成の必要性を減らすために、NGINX Ingress Controller と同じ名前空間に Prometheus インスタンスをデプロイします。

また、Servo ポッドが正しいインスタンスを見つけてクエリを実行できるようにサービスを構成します。 このアーティファクトはopsani-manifests-nginx-plus.yamlでカバーされています。

Bank of Anthosがサンプル Webapplicationとして実行され、Ingress が検証されたら、Ingress Prometheus インスタンスを起動します。 最後に、 opsani-manifests-nginx-plus.yamlファイルを適用して Opsani の最適化を開始できます。