G Bank がフルスタック クラウド コンテナ環境でコストを削減し、効率を高める方法を模索 - 基礎

序文

リソース使用の背景

現在、多くの金融企業は、ビジネス アプリケーション開発のアジャイルな反復、運用環境の迅速な展開、ビジネス負荷の柔軟なスケーリング、アプリケーション システムの完全なライフ サイクル管理を実現するために、コンテナーにビジネス アプリケーションを展開し始めています。企業の金融技術革新と金融シナリオ革新を支援し、金融業界の境界を広げ、金融サービスをより多様化し、ユーザーのより多くの潜在的なニーズを活用し、ユーザーの定着率とサービス体験を向上させ、企業の競争力を総合的に強化します。

現在、G 銀行のデジタル変革における重要なステップとしてのクラウド コンピューティングの活用は、決定的な段階に達しています。社内の視点から見ると、クラウドコンピューティングが周辺システムからコアシステムへと移行するにつれて、クラウドコンピューティングの利用は深みに入り、目標はクラウドをいかに使うかから、いかにうまく使うかへと変化しました。セキュリティと信頼性、コスト管理、パフォーマンスの最適化は、現在の G-Cloud 使用計画で重点を置く必要がある 3 つの重要な側面です。外部から見ると、一方では世界経済が下降局面にあり、他方では最近、大手インターネット企業の一部でシステムクラッシュが発生し、クラウド利用のリソース最適化と安全な運用に関する業界の議論が再びピークに達しています。

クラウド リソースのコストを削減し、効率を高めるプロセスにおいて、品質を損なうことなくコストを削減することが目標であり、システムの安定性、効率性、安全な運用を犠牲にしてコストを削減することはできません。この記事では、ビジネスの円滑な運営を効果的に確保するという前提に基づいて、一般的なコンテナ環境のリソース最適化手法を検討し、リソース使用率を向上させてクラウドコストを制御する方法を検討してまとめます。

リソース使用の背景

理解を容易にするために、コンテナ環境のアプリケーション アーキテクチャを図 1 に示すようにアプリケーション層、スケジューリング層、リソース層に分けます。各層のリソース使用状況を 1 つずつ説明します。

図1 コンテナ環境アプリケーションインフラストラクチャ

アプリケーション層

Kubernetes は、Request と Limit を使用して、コンテナの CPU およびメモリ リソースの要件を記述します。

リクエスト: コンテナによって予約されたリソースの量。コンテナが実際にこれらのリソースを使用しない場合でも、Kubernetes はこれらのリソースをコンテナ用に予約し、他のコンテナはリソース プール内のこれらのリソースを申請できません。

制限: コンテナが使用するリソースの上限を制限します。実際の操作中にコンテナが超えることのできないリソースしきい値。コンテナによって使用されるリソースがこの値を超えると、K8s は後続の対応する操作をトリガーします。 CPU については、CPU は圧縮可能なリソースであるため、コンテナが使用する CPU が制限設定値を超えると、CPU スロットリングのサービス低下を引き起こし、アプリケーションの処理速度に影響を与えます。ただし、メモリなどの圧縮できないリソースの場合、メモリ使用量が制限値を超えると、OOMKilled がトリガーされます。

実際のビジネスでの使用では、行 G はほとんどのサービスに対してリクエストと制限を設定し、制限はリクエストの 2 倍以上になります (制限がリクエストより大きい場合、実際には物理リソースの過剰販売になります)。図 2 の G 行にあるクラスター ワーカー ノードの CPU 使用率の線形グラフから、CPU 制限率が 209.14% であり、ノード上のアプリケーションが 109.14% 過剰に使用されていることがわかります。アプリケーション リソースをある程度過剰に販売し、Pod の展開密度を高めることで、クラスターの全体的な使用率を効果的に向上できます。

図2: クラスターワーカーノードにおけるCPUの過剰販売

スケジューリングレイヤー

Kubernetes では、スケジューリングとは、ノード上の Kubelet がこれらの Pod を実行できるように、適切なノードに Pod を配置することを指します。ネイティブ Kubernetes スケジューラ Kube-scheduler には、Pod をスケジュールするときに事前選択と最適化の 2 つの段階が含まれます。

事前選択フェーズでは、ポッドのスケジューリング要件を満たすすべてのノードが選択されます。 PodFitsResurces 戦略は、候補ノードの利用可能なリソースが Pod の Request リソース要求を満たしているかどうかを確認します。

最適化フェーズでは、事前選択に合格した各ノードに優先スコアが与えられます。 LeastRequestedPriority 戦略では、事前に選択されたノード リストからリソース使用量が最も少ないノードを優先的に選択します。 BalancedResourceAllocation 戦略は、事前に選択されたノードから CPU とメモリの使用が最もバランスの取れたノードを優先します。

ネイティブ Kubernetes スケジューラの戦略から、Pod リクエスト値のリクエスト構成の精度が、クラスター ノードのリソース使用率とクラスターの負荷分散に直接影響することがわかります。

リソースレイヤー

ノード リソースは Pod によって完全に使用できないため、Kubernetes がノード上のコンピューティング リソースをどのように分割するかという疑問が生じます。 Kubernetes は、図 3 に示すように、ノード上のコンピューティング リソースを複数の部分に分割します。

• システム予約済み: sshd など、Kubernetes でスケジュールしたり使用したりできない、システムによって予約されたコンピューティング リソース。
• Kubernetes 予約済み: Kubernetes が Dockerd、Kubelet、Kube-proxy などのために予約するコンピューティング リソース。この部分により、Kubernetes の正常な動作が保証されます。
• 削除スレッド: ノードのメモリまたはディスク リソースが不足してしきい値に達すると、kubelet は Pod の QoS 優先度に従って Pod によって占有されているリソースを回収します。
• フラグメント リソース: 通常、ノードにはポッドのスケジュールのリソース要件を満たすことができないリソース フラグメントがいくつか残っています。
• ノード割り当て可能容量: Kubernetes によってスケジュールおよび使用できるコンピューティング リソース。計算方法は次の通りです: [ノード割り当て可能容量] = [ノード容量] - [システム予約済み] - [Kubernetes予約済み] - [エビクションスレッド] - [フラグメントリソース]

図3 ノード次元におけるコンピューティングリソース

リソースが十分に活用されない理由

アプリケーション層

• 従来のリソース評価および割り当て方法を使用してクラウド上のリソースを割り当てる

コンテナ リソース仕様のリソース要求と制限を入力すると、Kubernetes ユーザーは混乱します。アプリケーション管理者は、トラフィックの変動に対処し、業務の安定性を確保するために、より多くの冗長リソースを予約する必要があり、その結果、リソースの冗長性が過剰になり、使用率が不十分になります。図4では、ある教育システムのCPU要求率は2%～5%（要求率=使用値/要求値）となっています。リソース仕様の要求値設定に冗長性があり、リソース利用率に改善の余地があります。

図4 教育プロジェクトの資源利用率

• コンテナの自動伸縮性に注意し、オンデマンドの自動拡張と収縮を効果的に使用しない

アプリケーション層で弾力性のある機能を有効にしてビジネスを強化することは、私たちが注力する必要がある問題です。数秒でコンテナを起動する機能により、ビジネスの必要に応じてリソースを割り当てるために、弾力的なスケーリングを使用できます。調査と探索を進める中で、G 銀行はオンライン取引事業のトラフィックにはピークと谷があることを発見しました。このようなビジネスにおいて弾力的な拡大と縮小が可能になれば、大量の資源の無駄を回避できます。図 5 は、オンライン取引プロジェクトのマイクロサービス モジュールの CPU 使用率を示しています。ビジネスでは毎日突然のトラフィックのピークがあり、他の時間帯にはトラフィックが低く、明らかなトラフィックのピークと谷があることがわかります。コンテナの極めて高い弾力性を活用してリソースの最適化を実現するのに非常に適しています。

図5 オンライン取引プロジェクトにおけるマイクロサービスモジュールのCPU使用率

スケジューリングレイヤー

• ネイティブスケジューリングでは実際の使用シナリオに対応できない

Kubernetes はデフォルトでネイティブ スケジューラ Kube-scheduler を使用します。その主な役割は、新しく作成された Pod に最も適したノードを見つけることです。調査プロセス中に、G は、ネイティブ Kubernetes スケジューラはリソース要求に基づいてのみスケジュールを設定できるため、一部のノード ポッドの実際のリソース使用量は、適用するリソース要求とは大きく異なることが多いことを発見しました。これにより、クラスターの負荷が不均一になり、一部のノードのリソース使用率が不十分になります。 Kubernetes のネイティブ スケジューリング機能とリソース バインディング機能は、複雑なコンピューティング シナリオのニーズを満たすことができなくなりました。図 6 は、クラスター ノードの CPU 使用率を示しています。ネイティブ スケジューラを使用すると、各ノードの CPU 使用率が均一ではなく、一部のノードではリソースが十分に活用されていないことがわかります。

図6 クラスターノードのCPU使用率

リソースレイヤー

• リソースの断片化により、リソースプールが十分に活用されない

Kubernetes スケジューラは将来の Pod サイズとノードの追加を予測できないため、時間の経過とともに、ノードに多くのリソースが残っている場合でも、最終的にはどのノードも Pod のリソース スケジューリングを満たすことができない状況に陥ります。これにより、リソース不足という誤った認識が生じます。 G 行のクラスター ノードの CPU リソース使用量と、図 7 および図 8 に示す Pod ビジネス リソース仕様を組み合わせると、ノードの合計コンピューティング リソースは 16 コアであり、13.15 コアが要求されていますが、ビジネス要求仕様は 4 コアであるため、ノード上の少なくとも 2 コアのリソース フラグメントが他の Pod によってスケジュールできないことがわかります。

図7. G行のクラスターノードのCPU使用率

リソース最適化対策

リソース利用に影響を与える上記の要因を分析することにより、以下の対応する改善策が講じられます。

アプリケーション層

• クラウドの特性に応じてリソース評価方法を最適化し、常駐リソースの割り当てを標準化

これは、ユーザーが冗長なリソースを過剰に申請するという一般的な状況を対象としています。リソース適用面では、G銀行は非機能テストを通じて将来一定期間の業務部門の事業計画を評価し、準拠性があり一定の冗長性を持つリソース仕様を整理します。リソース最適化の面では、コンテナのリソース使用状況を継続的に収集し、概要分析を行い、履歴データとインテリジェントアルゴリズムに基づいてコンテナごとにリソース仕様の合理的な推奨値を生成し、リソースの評価と割り当ての基準を形成します。リソース運用面では、リソース使用状況の追跡を強化し、リソース運用データを監視し、リソース利用情報を毎日公開するとともに、プロジェクト運用分析レポートと総合パフォーマンススコアを毎月公開し、各プロジェクトチームによるリソース配置の最適化とリソース効率の向上を支援します。

図 9 に示すリソース使用率の傾向チャートから、ある電子プロジェクトにおけるリソース使用率が低いという問題に対処するための是正措置が講じられた後、使用率が大幅に上昇したことがわかります。

図9: 電子プロジェクトにおけるリソース利用最適化のトレンドチャート

• 十分なテストを行った後、弾力性のある技術を効果的に推進し、ビジネスを強化します。

オンライン サービスの使用量は負荷状況に応じて変動するため、リソース仕様を設定する際には、周期的な特性を十分に考慮し、弾力性のあるリソースを使用して、トラフィックの谷間のリソース使用量を減らし、ピーク前に時間内に容量を増やすことができるようにする必要があります。 Kubernetes は、インジケーターベースの自動水平弾性拡張および収縮 HPA などの自動拡張機能を提供します。これにより、ワークロードの CPU またはメモリ使用量に応じて Pod レプリカの数を自動的に拡張または縮小し、弾性機能を使用してオンデマンドのリソース割り当てを実現できます。

図 10 と 11 から、ある業務の CPU 負荷が目標しきい値を 45 秒間超えると、Pod が自動的に 3 つのレプリカに拡張されることがわかります。弾力的な拡張と縮小により、企業は冗長リソースの構成を削減し、容量リスクを回避できます。

図10 容量拡張後の平均CPU使用率

図11: Podレプリカの数を増やす

スケジューリングレイヤー

• スケジューリングは実際のリソース負荷を認識します

ネイティブ Kubernetes スケジューラは、実際のノード負荷に基づいて Pod をスケジュールするのではなく、リクエストの静的構成に依存するため、クラスター内の各ノードに不均衡な負荷が発生します。現在のノードのリアルタイム リソース レベルを動的に取得し、それに応じてスコアを付けて、スケジューリング結果に介入し、各コンピューティング ノードのリソース使用量のバランスを取り、リソース プールのリソース供給を最大限に活用したいと考えています。

リソースレイヤー

• リソースの断片化の再調整

ネイティブ Kubernetes スケジューラは、その時点のクラスターのリソース記述に基づいて最適なスケジューリング決定を行います。ただし、静的データに基づくスケジューリングでは、将来のリソースの動的な変化に適応できない場合があります。特定のポッドを識別してノード間で移行することで、利用可能なリソースフラグメントを統合し、リソースプールのリソースの断片化を解決し、既存のリソースをより有効に活用して、不要な費用を節約したいと考えています。

要約する

この記事では、まずコンテナ環境の各レイヤーでのリソース使用の背景を紹介し、実稼働環境でのリソース使用の実践を通じて、リソース使用率が予想よりも低い理由を分析し、最後に対応するソリューションを提案します。

クラウド リソースの最適化は、盲目的に低コストを追求することではなく、ビジネス価値を確保しながら入出力比率を効果的に向上させることです。最適化では、最適なソリューションを実現するために複数の指標を調整する必要があります。最良の結果を得るためには、システムのセキュリティ、安定性、スケーラビリティ、パフォーマンスを常に無視してはなりません。つまり、クラウドへの移行とクラウドの使用は段階的なプロセスであり、クラウド リソースの最適化も反復的なプロセスです。最終的に最良の結果を達成するには、ビジネス クラウド移行のサイクル全体をカバーして、閉ループ、継続的な追跡、継続的な分析、継続的な最適化を形成する必要があります。

この記事は、G-Bank のフルスタック クラウド コンテナ環境でコストを削減し、効率を高める方法を紹介する記事です。今後、G-Bank のコンテナ クラウド リソース最適化の実践と利点を紹介する一連の記事が随時更新され、クラウドの効率性を最大限に活用してお客様に優れたサービスを提供できるようになります。