©MIXI Podのオートスケーリングに苦戦し続けている話 2024/09/27 [みてね x アソビュー] EKS運用お困り事例紹介 @ojima-h

©MIXI 生島 光 ソフトウェアエンジニア 株式会社MIXI みてね事業部 SREチーム 甘いものが好きです。 よろしくお願いします。 @ojima-h

©MIXI Podオートスケーリングとは？

©MIXI Podオートスケーリングとは？ 負荷に応じてPodの数を自動的に増減させる仕組み Pod Pod Pod Pod Pod Pod Pod Pod Pod Pod ユーザーが増えてきたら Podも増やす ユーザーが減ってきたら Podも減らす

©MIXI Podオートスケーリングはコスト最適化のために重要 ● Podオートスケーリングを適切に利用すると、Pod数を減らすことでEC2コストを削減 することができる。 ● ユーザー体験に影響を与えないことが大前提 ○ Pod数を減らしすぎると、パフォーマンスが劣化する ○ 負荷の増加に応じて、素早くPod数を増やさないといけない

©MIXI HorizontalPodAutoscaler (HPA) ● Kubernetesでは HorizontalPodAutoscaler を利用する ● HorizontalPodAutoscalerでは、Pod数を調整したい対象のDeploymentと、オートスケー リングの基準となるメトリクス、その目標値を定義します。 ● メトリクスはサービスの負荷と連動するものを選びます ● 指定したメトリクスが目標値くらいになるようにPod数を調整する。 ● よく使われるメトリクスは “CPU利用率” CPU利用率が下がってき たら… CPU利用率が目標値まで上がるように Podを減らす CPU利用率が上がってき たら… CPU利用率が目標値まで下がるように Podを増やす

©MIXI みてねとPodオートスケーリング ● 『家族アルバム みてね』（以下、みてね）のバックエンドは、主に２種類のコンポー ネントで構成されている ● ① Webサーバー ○ ユーザーからのリクエストを直接受ける ○ レスポンスの遅延は許されない ● ② ジョブワーカー ○ 非同期ジョブを実行する ○ 多少の遅延は許される ● それぞれにPodオートスケーリングを適用している Webサーバー ジョブ キュー ジョブワーカー

©MIXI Podオートスケーリングお困りポイント

©MIXI CPU利用率を基準にしたオートスケーリングのお困りポイント ● CPU利用率が意図せぬ要因により下がってしまうことがある。 ○ 本来は、サービスの負荷の低下にともなってCPU利用率が下がることを期待している。 ● 例えば… ○ サービスから呼び出している外部APIのレスポンスタイムが悪化する ○ 異常に大きなファイルを処理することによりIO処理の比率が増える そうなると サービス負荷は下がっていないのに、CPU利用率が低下する → サービス負荷は下がっていないのに、Pod数が減少する → 必要なPod数を下回り、サービスのパフォーマンスが悪化する❗ （障害に発展したことも複数回…）

©MIXI どうやって解決する？ ● ジョブワーカーの場合 ● Webサーバーの場合 Webサーバー ジョブ キュー ジョブワーカー

©MIXI ジョブワーカーのオートスケーリング ● CPU利用率以外のメトリクスを使いたい そこで、KEDA と Prometheus を組み合わせて、任意のメトリクスをオートスケーリングの 基準として使えるようにしました。 各種 Prometheus Exporter 各種 コンポーネン ト 各種 コンポーネン ト 各種 コンポーネン ト 各種 Prometheus Exporter 各種 Prometheus Exporter Prometheus KEDA Horizontal Pod Autoscaler 詳しくは弊社ブログで紹介しています https://team-blog.mitene.us/k8s-scale-pods-with-keda-4bac421735a0

©MIXI ジョブワーカーのオートスケーリング ● どんなメトリクスを採用するかが問題 ● いろいろ試行錯誤しました - ジョブキューの長さ - ワーカー稼働率 - 補正つきワーカーの稼働率

©MIXI ジョブワーカーのオートスケーリング ①「ジョブキューの長さ」を基準にしたオートスケーリング ● 「ジョブキューの長さ」=ジョブキューに存在する待機中のジョブの数 ○ 待機中のジョブに加えて実行中のジョブも数えるケースもある ● 「ジョブキューの長さ」に比例するようにPod数を調整する あるワーカーのPod数 → Pod数が振動してしまい イマイチ

©MIXI ジョブワーカーのオートスケーリング ②「ワーカー稼働率」を基準にしたオートスケーリング ● 「ワーカー稼働率」=ジョブワーカーのプロセスのうち、ジョブを処理中のプロセス の割合 ● 「ワーカー稼働率」が常に80%程度になるように調整する ● CPU利用率のように、外部要因により低下することがない → いい感じ！ 黄色 – プロセス数 緑色 – 稼働中のプロセス数 乖離が大きい ただ、常に２割のプロセスが暇しているので コスト効率がイマイチ

©MIXI ジョブワーカーのオートスケーリング ③「補正付きワーカー稼働率」を基準にしたオートスケーリング ● 「補正付きワーカー稼働率」=キューにジョブが滞留している間だけ、ワーカー稼働 率に1.2の係数を掛ける “ワーカー稼働率” ✖ (“ジョブキューが滞留している” ? 1.2 : 1) ● ジョブキューが滞留している時、ワーカーはフル稼働しているはず = 「補正付きワーカー稼働率」は 120% になる

©MIXI ジョブワーカーのオートスケーリング ③「補正付きワーカー稼働率」を基準にしたオートスケーリング ● 「補正付きワーカー稼働率」が100%になるように調整する ● 負荷が上がっていく時 – ジョブが滞留し始めると、ワーカー稼働率120%と見なされス ケールアウトする ● 負荷が下がっていく時 – ワーカーが暇になり始めると、稼働率100%になるようにス ケールインする → とてもいい感じ！ ←切り替えのタイミング 黄色 – プロセス数 緑色 – 稼働中のプロセス数

©MIXI どうやって解決する？ ● ジョブワーカーの場合 ● Webサーバーの場合 Webサーバー ジョブ キュー ジョブワーカー

©MIXI Webサーバーのオートスケーリング 現在進行形で困ってます！！！ 特に外部APIを呼び出している箇所 外部APIのレスポンスタイム悪化に引きづられて、 みてねWebサーバーのPod数が減少してしまう事象が発生 タイムアウトを短くしたりAPI呼び出し回数を減らしたりし てなんとかやり過ごしている

©MIXI Webサーバーのオートスケーリング 現在進行形で困ってます！！！ リクエスト数？ コネクション数？ リクエストキュー？ 遅延は許されない… メトリクスが反映されるまでのタイムラグは？ 調整ミスったら即障害… 何か試すにしても、ジョブワーカーよりリスクが大きい Load Average？

©MIXI まとめ

©MIXI まとめ ● ジョブワーカーのオートスケーリングは、いろいろ試行錯誤したが今はいい感じ ● Webサーバーのオートスケーリングは、お困り中！ ● 何かアイデアあったら教えてください