Oracle Cloud Hangout Cafe Season 4 #5「Kubernetesのオートスケーリング」(2021年8月4日開催)

はじめに

「Oracle Cloud Hangout Cafe」(通称「おちゃかふぇ」/以降、OCHaCafe)は、日本オラクルが主催するコミュニティの1つです。定期的に、開発者・エンジニアに向けたクラウドネイティブな時代に身につけておくべきテクノロジーを深堀する勉強会を開催しています。

連載第6回の今回は、Kubernetesの最も重要な機能の1つである「オートスケーリング」について深掘りしていきます。

アジェンダ

• スケールの復習とKubernetesにおけるスケールの種類
• Podの水平スケール
• Podの垂直スケール
• Nodeの水平スケール
• Kubernetesでの各種スケールのユースケース

発表資料と動画については、下記のリンクを参照してください。
【資料リンク】
【動画リンク】

スケールの復習とKubernetesにおけるスケールの種類

初めに、従来からあるスケールの種類とその特徴を踏まえた上で、Kubernetesにおけるスケールの種類を説明します。

スケールの復習

一般的なスケールの手法としては、以下の通り大きく2種類あります。

• 水平スケール(スケールアウト)
  • アプリケーションやソフトウェアが稼働する環境の数を増やすことによって、システムの処理能力を向上させる手法
  • 処理を並列稼働させることによってスケールする
  • 縮小させる場合は「スケールイン」と呼ぶ
  

  水平スケール

• 垂直スケール(スケールアップ)
  • アプリケーションやソフトウェアが稼働する環境のリソース(CPU, メモリ...)やスペックを向上させることによってシステムの処理能力を向上させる手法
  • 捌ける処理量を増やすことによってスケールする
  • 縮小させる場合は「スケールダウン」と呼ぶ
  

  垂直スケール

この2種類のスケール手法のメリット/デメリットと、ユースケースを以下に整理します。

• 水平スケール(スケールアウト)
  • Pos(メリット)
    • システムの可用性が高まる
  • Cons(デメリット)
    • 密結合なリソースに注意が必要
    • メンテナンスが煩雑になる可能性
  • ユースケース
    • Webアプリケーション(Web/APサーバ)
    • 科学技術計算サーバ(HPCなど)

• 垂直スケール(スケールアップ)
  • Pos(メリット)
    • システム構成に変更がない
    • 分散化に不向きなシステムでも対応できる
  • Cons(デメリット)
    • サーバが故障した場合のリスクが大きい
    • ハードウェア拡張の限界がある
  • ユースケース
    • データベースサーバ
    • ストレージサーバ

これら2種類のスケール手法は、いずれかを選択するというよりかは、システム全体で適材適所で組み合わせて利用するのが最適です。

例えば、Webアプリケーションなどの一般的なワークロードの場合は水平スケール(スケールアウト)を選択し、データベースなどの密結合なリソースの場合は垂直スケール(スケールアップ)を選択するなどです。

適材適所の垂直スケールを選択

kubernetesのスケール

ここからは、Kubernetesのスケールについて説明します。Kubernetesにおけるスケール手法には大きく3種類あります。以下にそれぞれ整理します。

• Podの水平スケール(Horizontal Pod Autoscaler)
  • Podの数を増やすことによって、処理能力を向上させるスケール手法
    • CPUやメモリをはじめとして、ユーザ独自のメトリクスも判断材料に利用できる(後述)
• Podの垂直スケール(Vertical Pod Autoscaler)
  • Podが利用できるリソース(CPU, メモリ...)を増強することによって、処理能力を向上させるスケール手法
    • 主にCPUやメモリを判断材料に利用
• Nodeの水平スケール(Cluster Autoscaler)
  • Worker Nodeの台数を増やす(デプロイできるPod数を増やす)ことによって、処理能力を向上させるスケール手法
    • Podの水平スケール(Horizontal Pod Autoscaler)と組み合わせて利用することが多い

ここで、"Nodeの垂直スケール"がないと思われた方も多いでしょう。Nodeの垂直スケールはKubernetesとしては実装されていません。また、2024/5時点ではクラウドベンダーなどが提供するAPIなどを利用してNode(Compute)のリソース増強はできますが、リソースをオンラインで変更する仕組みはありません。仮にオフラインで実行するにしても、Node(Compute)のリソース変更後に再起動が必要となるため、現実的ではありません。

このような事情もあるせいか、Kubernetesとしても各ベンダーが提供するマネージドKubernetesサービスとしても、Nodeの垂直スケールは実装されていません。