How to choose the elasticity strategy of K8S

まえがき
マイクロサービスアーキテクチャの登場により、巨大なモノリシックアプリケーションが分割され、ビジネス間の開発と連携がより柔軟になりました。ビジネストラフィックが増加するシナリオでは、一部のアプリケーションコンポーネントの処理能力を拡張する必要が生じることが多いです。K8S はアプリケーションレベルで HPA を提供しており、HPA 関連のオープンソースコミュニティでは KEDA などの弾力性コンポーネントが開発され、マイクロサービスアプリケーションがビジネス指標に基づいた弾力性ポリシーを実装する可能性を開いています。ただし、HPA が正常に動作するための重要な前提条件は、クラスターリソースの充足を確保することです。そのため、ユーザーは事前にクラスター処理能力を拡張するか、常にクラスターリソースの冗長性を維持する必要があります。
クラスターリソースの弾力性という課題に対し、K8S コミュニティは Cluster Autoscaler (CA) と Virtual Kubelet (VK) の 2 つのソリューションを提示しています。本記事では、マイクロサービスアプリケーションの形態と特徴に焦点を当て、CA と VK の適用シーンを分析し、マイクロサービスアーキテクチャにおけるアプリケーションのクラスターリソース弾力性の選択方法をまとめます。




マイクロサービスアプリケーションの形態と特徴
マイクロサービスアプリケーションアーキテクチャでは、マイクロサービスアーキテクチャが巨大なアプリケーションシステムを個別のアプリケーションコンポーネントに分割します。これらのコンポーネントは RPC を通じて接続され、外部に対して完全なサービスを提供します。各コンポーネントは独立しており、ほとんどのコンポーネントは水平スケーリングによってサービス処理能力を調整できます。非コアリンクのコンポーネントは、遅延拡張や拡張なし、さらにはリソースを放棄するための縮小も可能です。
マイクロサービスアーキテクチャの弾力性シナリオには、5 つの主要な特徴があります。
・水平スケーリングによるシステム処理能力の調整：外部リソースが十分な場合、マイクロサービスアプリケーションコンポーネントの水平スケーリングにより、業務システムの処理能力を向上できます。
・アプリケーション間の依存関係：単一のマイクロサービスアプリケーションでは完全なサービスを提供できず、単一のマイクロサービスコンポーネントの拡張だけではシステム処理能力をごく限定的にしか向上できません。依存サービスと一緒にシステム処理能力を拡張することで、初めて効果的にシステム処理能力を向上できます。
・アプリケーション自体のステートレス性：マイクロサービスアプリケーション自体がステートフルな場合、水平拡張に不利です。たとえば、ディスクへの強い依存があると、同じノードでディスク IO が競合し、処理能力縮小時に状態データの処理も考慮する必要があります。そのため、可能な限りステートレスなアプリケーションに改造する必要があります。
・高速起動とサービスのオンライン・オフライン時のトラフィック無損失：サービスの無損失なオンライン・オフライントラフィック処理は、自動スケーリングシナリオにおいて非常に重要です。特に高トラフィック・高同時実行のシナリオでは顕著です。ヘルスプローブの作用下で、拡張されたばかりの Pod が K8s によって継続的に再起動されると、最終的に拡張が無効になります。
・トラフィックの周期性：ほとんどのマイクロサービスアプリケーションはオンラインサービス向けであるため、80/20 の法則で説明できます。つまり、80% のトラフィックが 20% の時間に処理されます。ビジネストラフィックの最も顕著な特徴は周期的な変動であり、その変化はしばしば急速です。そのため、マイクロサービスアプリケーションのスケーリングと縮小の応答速度は、業務システムの安定性に重要な役割を果たします。
マイクロサービスアプリケーションアーキテクチャでアプリケーションの弾力性を設定する際に考慮すべきは、システム処理能力を計測する適切な指標を選択することです。クラスターリソースの弾力性を設定する際に考慮すべきは、拡張後のコンピューティングリソースがアプリケーションのニーズを満たせるかどうかです。
K8S クラスターリソース弾力性技術ソリューション
まえがきで述べたように、K8S コミュニティは 2 つの「標準回答」フレームワークを提示しており、リソース弾力性の具体的な実現はクラウドベンダーの技術形態と製品機能に依存します。
仮想ノード：VK
Virtual Kubelet は、kubelet の定義に基づいて提唱された「仮想ノード」の概念であり、クラウドベンダーがクラウドサービスを「仮想ノード」としてパッケージ化し、Kubernetes クラスターに追加できるようにします。仮想ノードの背後には、クラウドベンダーの大規模なリソースプールがあります。そのため、理論上は仮想ノードのリソースは無制限と考えられますが、実際の状況はクラウドベンダーの規模と製品能力によって判断されます。
ノードスケーリング：CA
Cluster Autoscaler は、K8S コミュニティが提供するクラスターノードスケーリングソリューションです。CA はクラスター内のすべての Pod イベントを監視します。リソース不足により Pod がスケジュールできない場合、CA はスケーリンググループ情報に基づいてシミュレーション拡張およびスケジューリング計算を実行し、事前に設定されたノード拡張戦略に従って実際のノード拡張を実行します。同時に、CA はクラスター全体のリソース使用率を監視します。使用率が事前に設定された縮小しきい値を下回った場合、CA はシミュレーション縮小スケジューリング計算を実行します。さまざまな影響要因を排除した後、縮小可能なノードのテインティング、ドレイニング、削除という一連の操作を実行します。
各方式の特徴の比較
CA ベースの実ノードスケーリングと VK ベースの仮想ノードにはそれぞれ特徴があります。主な違いは以下のとおりです。
つまり、CA は実ノードをスケーリングして完全な K8S 機能を提供しますが、応答速度は遅くなります。VK はクラウドベンダーのリソースプールに支えられ、秒レベルの無制限なリソース弾力性を提供しますが、実ノードが存在しないため、一部の K8S 機能が失われます。
クラウドベンダーのソリューション
VK と CA の 2 つの主要なリソース弾力性技術方向において、各クラウドベンダーも対応する製品を展開し、対応するソリューションを提供しています。
サーバーレス方向には、主にサーバーレスインスタンスとサーバーレスクラスターがあります。サーバーレスインスタンス製品には ECI、Fargate、ACI があり、高速で無制限のリソースが特徴です。サーバーレスクラスター製品には Alibaba Cloud の ASK や Google の GKE Autopilot などがあります。クラウドベンダーがすべてのクラスターリソースを管理し、ユーザーは運用保守なしでそのまま利用できます。
ノードスケーリング方向では、AWS がオープンソースコンポーネント Karpenter もリリースしています。Karpenter は CA のスケーリンググループの概念を迂回することで、スケーリング時のリソース選択をより柔軟にしています。
リソース弾力性戦略の選択と考慮事項
リソースの弾力性に関して、まず考慮すべきは処理能力です。つまり、新しいコンピューティングリソースがビジネス利用要件を満たせるかどうかです。VK 技術ベースの弾力性ソリューションは、アーキテクチャ設計、セキュリティ、パフォーマンスなどの要因による制限を受け、ノード特性やコンテナ特権などの機能において天然の制約があります。これらの機能が必要なビジネスアプリケーションは、可能な限り関連する依存関係を排除するよう改造すべきです。
次に考慮すべきはコスト効率です。企業アプリケーションにとって、コスト予算は避けて通れない話題です。異なる料金体系や課金モデルは最終的に異なるリソースコストをもたらし、それが特定の技術への好みに影響します。現在のサーバーレスシナリオでは、コンピューティングリソースは一般的に従量課金モードを採用しています。長期間実行されるアプリケーションの場合、前払い方式のコンピューティングリソースがより多くのコスト削減を実現できるかどうかは、さらなる調査と実践が必要です。コストのレベルにはリソースコストだけでなく、運用保守コスト、チームの技術学習コスト、特定クラウドベンダーへの依存に伴う移行コストも含まれます。この観点は無視できません。同時に、技術チームとしては、対応する技術ソリューションを選択して運用保守コストを削減し、チーム学習コストを低減すると同時に、このコスト削減とチーム成長がもたらす便益との関係を理性的に見極める必要があります。
効率はビジネス収益コストに影響する重要な要素の一つです。受信トラフィックから、HPA が指標に応じた応答、リソース弾力性によるアクション実行、アプリケーション起動からサービス開始に至るまで、各リンクに時間コストがかかります。通常、時間コストは小さいほど良いですが、時間コストに敏感でないビジネスもあります。スケーリングの各リンクに対し、対応する技術ソリューションが開発されています。たとえば、HPA の受動的応答に対し、Alibaba Cloud は AHPA のインデックス予測による先行拡張機能を展開しています。たとえば、Java アプリケーションの起動は遅いですが、GraalVM や Alibaba Dragonwell はコールドスタートアップの改善に取り組んでいます。明確なビジネスサイクルを持つアプリケーションには、事前にタイミング弾性スケーリングを設定することで、これらの問題を自然に解決できます。
最後に、考慮すべきシナリオ上の課題もあります。現在のアプリケーションアーキテクチャのアップグレード、移行、再構築において、高い弾力性を考慮に入れ、適切な技術を選択する必要があります。
以上を総合的に考慮し、一般的なシナリオにおいてクラスター弾性タイプを選択する際に必要な要素をまとめたリソース弾力性選択戦略図を作成しました。


まとめ
マイクロサービスアーキテクチャでは、ビジネスの観点からアプリケーションコンポーネントを整理・分割する必要があります。コアリンクコンポーネントについては、これらのコンポーネントの堅牢性を最大限に確保し、高可用性・高弾力性のアーキテクチャに調整して、コアビジネスの長期的な安定稼働を実現する必要があります。周辺リンクコンポーネントについては、コストと高可用性・高弾力性がもたらす便益のトレードオフを評価する必要があります。
K8S リソースの弾力性に関する課題では、既存の技術手段の中で互換性、効率、コストを考慮し、自社のビジネスに適したクラスター弾力性戦略を選択する必要があります。