Kubernetes のユースケースと導入が業界全体で拡大し続けるにつれて、Kubernetes インフラストラクチャのフットプリントが大幅に増加していることがわかります。 この増加により、特に大規模環境のクラウドのコストを抑制する方法を模索するようになりました。Kubernetes のコストは、使用している基盤となるクラウドのインフラストラクチャ コストだけによって決まるわけではありません。 アプリケーションのアーキテクチャと Kubernetesの構成 (ノード構成、自動スケーリングルール、podリソース・リクエスト、スケジューラなど) は、リソースの消費と使用率に大きな影響を与えます。 したがってこれらの要因は、最終的な収益と Kubernetes クラウドの請求額に影響を与えます。
最近光栄にも、OCI の顧客で北欧諸国最大の損害保険サービス企業である Tryg Insurance を Cloud Native Computing Foundation (CNCF) テクニカルウェビナーにお招きする事ができました。 そのセミナーでTryg の Varsha Naik 氏は、大規模環境にて動的で適切なサイジングを実施することで、Kubernetes クラウドのコストを 50% 削減した方法を共有しました。
Tryg が、アプリの使用状況を正確に測定してKubernetes 環境を構成し、リソース使用率を最適化するためにサイズ変更を自動化するパターンについては、この先の文を読み進めてください。こうした変更により、パフォーマンスを損なうことなくKubernetes コストが大幅に削減されました。
Tryg 社の Kubernetes スケール
シンボル名 TRYGにてNasdaq OMX コペンハーゲンに上場していてデンマークに本拠を置く Tryg は、ノルウェー、スウェーデン、フィンランドでも事業展開するスカンジナビアの保険会社です。TRYG は北欧最大の損害保険会社で、民間、商業、法人部門にわたる幅広い保険商品を 530 万人以上の顧客に提供しています。 これらのサービスは、自動車保険、住宅保険、健康保険、労働者賠償責任保険、商業財産保険、団体生命保険などに及びます。
Tryg の Kubernetes ベースのアプリケーションは、すべての商品ラインにわたるすべての保険金請求の処理を担当し、さまざまなデータソースからの大量のリアルタイムの構造化データと非構造化データを処理します。そのスタックには、Strimzi Kafka、PostgresSQL、Kafka Connect、Prometheus、Elasticsearch、Grafana、Kibana を使用したさまざまな監視やアラート技術など、さまざまなテクノロジーが含まれています。
Tryg は、Oracle Container Engine for Kubernetes (OKE) 上で実行される 5 つのクラスタで大規模な Kubernetes 環境を運用しています。各クラスタには 5,000 個の vCPU、12.7 TB のメモリ、307 TB のストレージがあり、クラスタあたり 2,150 個のpodを実行できるキャパシティがあります。
Kubernetesのサイジングの課題
Kubernetes の設定で性能とコストのバランスをとり、サービス・レベル・アグリーメント (SLA) を満たすことは困難な場合があります。 クラスタのサイズ、Computeのシェイプ、スケーリング、リソース要求は、サービス体験と関連コストに影響を与える多くの要因の 1 つです。ただし、アプリケーションのニーズを正確に見積もったり、コストパフォーマンスの最適なポイントを見つけるために動的に調整することは、多くの場合困難です。 アーキテクチャとアプリのポートフォリオの複雑さ、可視性の欠如、自動化、ワークロードの動的な性質、実行中の他のアプリケーションへの依存関係などにより、問題が複雑になっています。
Tryg の請求処理アプリケーションの場合、それを構成する複数のコンポーネントにはさまざまな要件があり、より多くの CPU を必要とするもの、データ処理のためにより多くのメモリを必要とするもの、および I/O スループットの向上を必要とするものがありました。 この複雑さにより、各マイクロサービスのニーズを満たすように Kubernetesの環境を微調整することが困難になりました。 また、クラスタには決まった数のworkerノードがあったため、ピーク時の使用やアイドル時間に関係なく同じコストが発生しました。
解決策: Kubernetesのリソースを最適化し、動的サイズ変更を自動化してコストを削減
Tryg は、Kubernetes によって消費されるクラウドのリソースに影響を与える次の重要な要素を最適化しました。
ノード・リソースの最適化
Tryg は、Kubernetes のworkerノードのシェイプに Oracle Cloud Infrastructure (OCI) flex シェイプを使用して、Kubernetes 環境を微調整するという課題に取り組み始めました。flexシェイプにより、選択したcomputeに対して CPU とメモリをきめ細かく割り当てることができます。標準のVM では、より大きなインスタンス サイズに「ジャンプ」することで、決まった間隔で CPU とメモリの両方を一緒にスケーリングする必要があります。 対照的にflexシェイプを使用すると、要求の厳しいワークロードであっても、特定のアプリケーションのニーズに合わせて CPU または RAM を細かく増減でき、パフォーマンス、リソース使用率を最適化し、コストを削減するために過剰なプロビジョニングを回避できます。
Tryg は、適切な数の OCPU (2 つの VCPU に相当) とメモリを使用して OKE のworkerノードを構成しました。 また、アプリケーション・コンポーネントごとに個別のノード プールを確立し、固有の要件に適切に対処できるようにしました。 ノードのサイズが重要な要素であることが判明し、高い CPU リソースとメモリリソースを備えた大規模なノードを割り当てると、computeリソースとメモリリソースを全て利用し切る前にノード上の永続ボリュームの制限に達してしまうことがわかりました。 一方で、より多くの小規模ノードを割り当てすぎると、workerノードのサブネットのサイズが適切に設定されていないと、IP アドレスが枯渇する危険があります。
ノード・シェイプの最適化
アプリケーションの多様なニーズを満たすために、Tryg は OCI の次のflexシェイプ・ハードウェア・オプションを使用しました。
- 一部の Java サービスおよび Strimzi (Apache Kafka ソリューション) を実行するための AMD64 workerノード
- パフォーマンスが重要なコンポーネント用の ARM64 ノード。 これらのノードは、AMD64 シェイプよりも安価でありながら、高いパフォーマンスと信頼性を備える
- 低レイテンシーと最適なパフォーマンスを実現するために、Tryg は Postgres DB を Kubernetes クラスタで実行。DenseIO VM は、遅延を大幅に削減するローカルディスク・ストレージを提供
Tryg は、Kubernetes Node Affinity、nodeSelector、taintとtolerationを利用して、特定のワークロードを優先workerノードに割り当てました。
podの水平自動スケーリング: 需要に基づきpodのレプリカを動的に調整
ステートフル・アプリケーションの Kubernetes クラスタのアイドル時間中のコストを削減するために、Tryg は水平pod自動スケーリング (HPA) を実装しました。 HPA は需要に基づいてpodのレプリカの数を調整し、必要に応じてレプリカを増減します。 HPA を使用するには、CPU とメモリの使用率に閾値を設定し、使用率が閾値を超えたり下回ったりしたときに、レプリカを作成・削除します。 Tryg が HPA を実装した方法であるカスタムメトリクスを使用することもできます。
Tryg は、特定のアプリケーション固有のメトリクスを Prometheus サーバに公開しました。 カスタム メトリックの閾値はPrometheus サーバによって Kubernetes API を介して設定され、HPA に送信されました。
図 1. 水平pod自動スケーリングと Prometheus サーバを使用したアーキテクチャ
図 2. HPA が使用率に基づいてpodをスケールアップおよびスケールダウンした結果
HPA はピーク期間とアイドル期間に適切な数のpodを動的に割り当てましたが、Tryg の Kubernetes クラスタは依然として静的に構成されていたため、ピーク期間とアイドル期間に同じ数のworkerノードが割り当てられていました。 workerノードの数はコストに影響するため、HPA だけではコスト削減にはつながりませんでした。
クラスタオートスケーラ: 需要に基づいてworkerノードを動的に調整
workerノードの固定数に対処するために、Tryg は Kubernetes クラスタオートスケーラを実装しました。podの需要に基づいてworkerノードの数を自動的にスケールし、必要に応じてスケールアップ・スケールダウンします。 クラスタオートスケーラは、特定のノードプールをスケーリングする機能やノードのスケーリング速度などの機能も提供します。
図 3. スケジュールされていないpodをアップスケーリングするクラスタオートスケーラ
図 4. 使用率に基づいてプロビジョニングされたノード
HPA を Kubernetes クラスタオートスケーラと組み合わせて使用すると、ピーク期間とアイドル期間に応じてワーカー ノードの数が調整されました。 この組み合わせにより、Tryg は大幅なコストを節約することができました。 ただし、さらに多くの作業を行うことができます。
垂直pod自動スケーリング: アイドル時のデフォルト・キャパシティの排除
podのCPUやメモリリソースのリクエストを指定するとき、通常、ピーク時の使用率予想に基づいて見積もりを行い、計算にバッファを追加することがよくあります。 この調整により、pod内の CPU とメモリのリクエストが過剰にプロビジョニングされる可能性があります。クラスタあたり 2,000 を超えるpodがある場合、これらの未使用のリソースが急速に蓄積し、コストが高くなる可能性があります。
次のグラフは、Tryg の Kubernetes クラスタ内のpodレベルでの実際の使用量と比較した、割り当てられた CPU およびメモリリソースを示しています。
図 5. 割り当てられたリソースと比較した実際のリソース使用率
podレベルでの使用率の具体的な数値を取得するために、Tryg は垂直pod自動スケーリング (VPA) を導入しました。 VPA は、podごとに要求されたリソースと実際の使用率との間のギャップに対処する Kubernetes アドオンです。
VPA は、アプリケーションの CPU とメモリの使用量に基づいてpodのリソースの割り当てを自動的に変更することで、リソースの使用率を向上させるように設計されています。 ただし、HPA が CPU とメモリの使用率を閾値として使用するように構成されている場合、VPA は HPA と連携できません。 Tryg は、HPA 実装にカスタム メトリックを採用することで VPA を HPA と共に利用することができ、その結果、podのスケーリングを管理するための包括的なソリューションが実現しました。 VPA はpodのリソースの割り当てを調整しますが、HPA はpodレプリカの数を変更します。
図 6. VPA 後のリソースの割り当てと使用率
まとめ
SLA を満たし、拡大する Kubernetes 環境の規模をコスト効率の高い方法でサポートするには、パフォーマンスとコストの適切なバランスを見つけることが不可欠です。Kubernetes には、リソース消費とクラスタのパフォーマンスを制御するためのいくつかの手段が用意されています。 これらの最適化を実装し、動的なサイズ変更のために HPA と VPA を組み合わせることにより、Tryg は環境を最適化し、Kubernetesのコストを50%削減することができました。より小さなフットプリントで大規模に。これらの節約は業績に大きな影響を与えます。
詳細については、Tryg の CNCF ウェビナーのリプレイをご覧ください。
詳細については、次のリソースを参照してください。