アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化

by M-Yamashita

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介山下雅人クラウド経費・クラウド債務支払 SRE チームリーダーバックエンドエンジニアとSREの経験を活かして活動中 Kaigi on Rails Organizer

Slide 3

Slide 3 text

今日話すこと AWS移行プロジェクト - オンプレミスからクラウドへ障害と課題発見 - アクセスピーク時のオートスケール問題 KEDA導入 - リクエスト数に応じたスケーリングデータ活用最適化 - 適切なレプリカ数の導出

Slide 4

Slide 4 text

AWS環境への移行プロジェクト

Slide 5

Slide 5 text

過去のマネーフォワードのアーキテクチャについて

Slide 6

Slide 6 text

（マネーフォワード中出氏, ITmedia Cloud Native Week 2022春基調講演, 2022年より引用）

Slide 7

Slide 7 text

桃園脱却

Slide 8

Slide 8 text

クラウド経費・クラウド債務支払のAWS環境移行 🏢 移行前 📟 オンプレミスVM 🗃️ 共有DB → ☁️ 移行後 🚀 EKS 🗄️ 専用DB

Slide 9

Slide 9 text

AWS環境におけるオートスケール設計

Slide 10

Slide 10 text

そもそもなぜオートスケールが必要なのかビジネス面から考えてみる

Slide 11

Slide 11 text

AIの力を借りて考える Illustration © unDraw.co

Slide 12

Slide 12 text

ビジネス面から見たオートスケールの必要性機会損失の防止と顧客体験の最大化キャンペーンや突発的なアクセスピーク時でもサービスを安定稼働させることで、販売機会の損失を防ぐインフラコストの最適化アクセスピーク時以外はリソースを自動で縮小し、過剰なリソース確保によるコストを削減事業成長への迅速な対応サービスの利用者増加や事業拡大に伴い、将来的に増大するアクセスピークにも柔軟に対応ビジネスの成長をITインフラが支えられるようにする

Slide 13

Slide 13 text

クラウド経費・クラウド債務支払におけるアクセスピークとは？

Slide 14

Slide 14 text

アクセスピークの特徴利用ユーザーは月末月初にかけて経費申請や承認をするためにアクセスすることが多い確定申告時期〜年度始め付近にかけてもアクセスが多くなる月初〜月末におけるリクエスト数の遷移

Slide 15

Slide 15 text

アクセスピーク時におけるオートスケール設計 📊 分析対象メトリクス: CPU使用率、メモリ使用量観察期間: 1日および1週間目的: リクエスト数との相関関係を調査 ⚙️ 設計方針リクエスト増加パターンを分析し、適切な閾値を設定する

Slide 16

Slide 16 text

リクエスト数とCPU使用率の関係 1日の推移午前中: リクエスト数とCPU使用率が上昇日中: 高い水準を維持夜間: 両メトリクスが減少傾向 1週間の推移平日: 日中に両メトリクスが増加月曜日が最もアクセスが集中土日: 両メトリクスともに低い水準で推移リクエスト数とCPU使用率に相関あり

Slide 17

Slide 17 text

リクエスト数とメモリ使用量の関係 1日の推移終日: リクエスト数の変動に関わらずメモリ使用量は横ばいで推移 1週間の推移平日・休日: メモリ使用量は常に横ばいで推移リクエスト数とメモリ使用量には相関なし

Slide 18

Slide 18 text

過去データから導いた考察 CPU使用率がボトルネックになると想定リクエスト数とCPU使用率の連動性を確認メモリ使用量が横ばいであったため、CPU使用率が先にネックになると想定オートスケール機能にはHPAを採用 Kubernetesの基本機能、豊富な他社事例と運用ノウハウ AWS環境での運用経験不足をカバー KEDAの選択肢もあったが必要になった時に検討と判断

Slide 19

Slide 19 text

CPU使用率の閾値検討 HPAではRequest値を基準とした閾値となっている確実にスケールされることを考慮閾値を60%に設定 https://kubernetes.io/docs/tasks/run- application/horizontal-pod-autoscale/

Slide 20

Slide 20 text

迎えたAWS環境への移行当日

Slide 21

Slide 21 text

迎えたAWS環境への移行当日 AWS移行、無事完了！🎉

Slide 22

Slide 22 text

2024年12月月初 AWS環境に移行後初のアクセスピーク日

Slide 23

Slide 23 text

鳴り響くアラート ⚠️ Slackでの外形監視エラー 🔥 p95レスポンスタイムの異常増加 ⚠️ HPAによるスケールが機能せずシステム全体が危機的状況に陥る

Slide 24

Slide 24 text

暫定対策状況把握アクセス数に対してpodが不足していた CPU閾値をトリガーとしたHPAが機能していなさそうメモリ不足の傾向が見られる緊急対応 minReplicasを大幅に増加 podのメモリ割り当てを増加アクセスピークを乗り切ることに成功

Slide 25

Slide 25 text

振り返り: なぜ問題が起きたのか

Slide 26

Slide 26 text

障害の振り返り: CPU使用率メトリクスの推移障害発生期間: アプリ全体でCPU使用率は50%以下程度で推移 HPAのCPU閾値は60%のためスケールしなかった障害発生期間におけるCPU使用率の推移グラフ

Slide 27

Slide 27 text

障害の振り返り: メモリ使用率の推移障害発生期間: アプリ全体でメモリ使用率が100%近くで推移 livenessProbe(プロセス生存確認)がメモリ不足の影響で失敗メモリ不足によりアプリケーションが不安定になりPodが停止障害発生期間におけるメモリ使用率の推移グラフ

Slide 28

Slide 28 text

障害の振り返り: そして悪循環へ

Slide 29

Slide 29 text

障害の振り返り: 今後の対応方針緊急対応（短期対策）暫定的にminReplicasを増加させサービス継続月末月初のアクセスピークに対応可能な体制を確保根本対策（長期解決策）リソース最適化: メモリ割り当ての見直しと適正化スケール機能強化: オートスケール設計の見直し閾値最適化: CPU使用率の閾値を実態に合わせて調整

Slide 30

Slide 30 text

オートスケール設計の改善ポイント

Slide 31

Slide 31 text

オートスケール設計の改善ポイント閾値設定の根本的見直し CPU使用率との相関性に依存したスケール設計負荷の根本原因であるリクエスト数を直接監視データ分析における注意点相関関係は「現時点での傾向」として参考程度に留める将来的にボトルネックとなるリソースは変化する可能性あり

Slide 32

Slide 32 text

新技術導入における慎重なアプローチなぜ最初からKEDAを選ばなかったのか？新しい技術スタックへの学習コストの高さトラブル発生時の対応ノウハウの不足段階的導入のメリットまずは実績のあるHPAで運用開始問題が発生してから改善を検討する段階的アプローチ結果として今回の経験により最適解が見えた

Slide 33

Slide 33 text

オートスケール改善のアプローチ検討障害の根本原因を解決するために、複数のアプローチを検討データ活用アプローチアクセスパターンの分析結果を活用予測可能な負荷変動への対応技術改善アプローチより適切な監視メトリクスの採用柔軟なスケーリング機能の導入

Slide 34

Slide 34 text

静的 vs 動的スケーリングの判断静的スケーリング（cron）固定的なスケジュールでは細かな調整が困難突発的なアクセス変動に対応できない動的スケーリングリアルタイムでの負荷変動に柔軟対応より精密なリソース管理が可能動的スケーリングでより適切な監視指標が必要

Slide 35

Slide 35 text

KEDAを活用したリクエスト数ベースのオートスケーリングへ

Slide 36

Slide 36 text

Kubernetes Event-Driven Autoscalingとはイベントをトリガーにアプリケーションをオートスケーリング可能メッセージキューの長さやDBの行数など様々な"イベント"をトリガーに指定可能コスト効率の最大化 (ゼロスケールイン) Podの数を自動的に0台にまでスケールイン可能 https://keda.sh/

Slide 37

Slide 37 text

KEDAの役割 Operator: イベントソースを監視しインスタンス数を調整 Metrics Server: 外部メトリクスを HPAに提供し、スケーリングを判断 Scalers: 各イベントソースに接続、現在の使用状況を取得 CRDs: カスタムリソースを使用してアプリケーションがスケーリングをすべきかを定義

Slide 38

Slide 38 text

オートスケール再設計: リクエスト数の閾値追加 Datadogとの連携 Datadogでリクエスト数をモニタリング中 Datadogのリクエスト数を参照取得したリクエスト数に応じてオートスケールさせる閾値算出の進め方移行前の性能試験におけるエンドポイントに着目 AWS環境上の同エンドポイントにおける処理能力から算出

Slide 39

Slide 39 text

KEDAの閾値をどう決めるか？- 私たちのアプローチ

Slide 40

Slide 40 text

基準値の算出 - データ分析から平均処理能力を算出

Slide 41

Slide 41 text

Podの処理能力を定量化する

Slide 42

Slide 42 text

実用的なKEDAの閾値を導き出す KEDAで使用するリクエスト閾値の確定

Slide 43

Slide 43 text

オートスケール再設計: CPU使用率は継続採用リクエスト数では捉えきれない負荷への対応アクセス数が閾値に満たない状況でもCPU使用率が上昇するケースを考慮システム可用性の向上 Datadogサービス停止時のフェイルセーフ機能として動作監視システムの単一障害点を回避し、サービス継続性を確保リクエスト数とCPU使用率の二重監視体制により信頼性向上

Slide 44

Slide 44 text

オートスケール再設計: CPU使用率閾値の最適化問題の特定設定していた60%閾値では反応が遅すぎることが判明閾値の調整変更前: 60% → 変更後: 45%（15%の緩和）期待される効果アクセスピーク時の早期スケールアウト実現サービス応答性の改善とユーザー体験の向上

Slide 45

Slide 45 text

オートスケール再設計: メモリ使用率を組み込むか？検討結果メモリ使用率は閾値として採用しない理由ガベージコレクション実行により使用率が不規則に変動するスケーリングトリガーとしての予測可能性と信頼性に欠けるメモリ集約的なアプリケーションは事前設定で対応すべき

Slide 46

Slide 46 text

KEDA設計の最終仕様採用する監視指標リクエスト数: エンドポイントの処理能力に基づく閾値設定 CPU使用率: 障害時の検証結果を反映し45%に設定（従来60%から緩和）除外する監視指標メモリ使用率: ガベージコレクションによる不規則な変動のため除外

Slide 47

Slide 47 text

オートスケール再設計後のKEDA適用日中: アクセス増加に伴い正常にスケールアウトが動作夜間: アクセス減少に伴いスケールインが正常に動作 KEDAによるスケールアウト・スケールインの動作結果

Slide 48

Slide 48 text

最適なレプリカ数の導出

Slide 49

Slide 49 text

KEDAを活用できたので次はレプリカ数を見直す

Slide 50

Slide 50 text

移行当時のレプリカ数事前性能試験の結果に基づいて設定 AWS環境移行時に性能試験を実施し、HPAの適切なレプリカ数を算出 minReplicas: 平常時のアクセスを処理するのに必要な台数 maxReplicas: アクセスピーク時に対応できる台数

Slide 51

Slide 51 text

アクセス数比率でレプリカ数を最適化最小アクセス数における理想現在のminReplicasの約1/3の台数で稼働可能現状 minReplicasの台数のまま夜間も稼働課題余剰コストが毎日発生夜間と日中のアクセス数比率

Slide 52

Slide 52 text

KEDAでのminReplicaCount決定までの流れメトリクス分析夜間のCPU使用率: 10%程度夜間のリクエスト数: 数千程度負荷要因の考慮外部要求: 外部API、社内プロダクト連携内部処理: 夜間バッチ、定期データ処理これらを総合的に考慮してminReplicaCountの目標値を決定

Slide 53

Slide 53 text

目標値に向けたminReplicaCountの削減の進め方案1: 一気に削減メリット: コスト削減を即座に実現リスク: 予想外の挙動でサービス影響の可能性案2: 段階的削減メリット: 安全性を確保しながら削減リスク: コスト削減の効果実現に時間がかかる案2を採用: 段階的な削減と監視で目標値を目指す

Slide 54

Slide 54 text

クラウド経費・クラウド債務支払での監視方法について

Slide 55

Slide 55 text

常時監視 AWS移行時から監視設定済みアラート設定 Datadogで各種メトリクスの閾値監視通知異常検知時にSlackへ自動通知対応 SREをメインに調査、対応

Slide 56

Slide 56 text

フィードバックと対応既存の会議体制を活用参加者・体制 SREチーム + 開発メンバー週次で定期開催確認内容各種メトリクス確認、異常波形の原因特定・対応情報共有・連携双方の実施済み変更を共有し、システム状況を理解

Slide 57

Slide 57 text

minReplicaCount削減と監視のサイクルを構築

Slide 58

Slide 58 text

段階的なminReplicaCountの削減実施 minReplicaCount削減結果 AWS環境移行時と比較し60%削減に成功サービス影響なしで実現 →段階的なアプローチによる安全な最適化完了

Slide 59

Slide 59 text

レプリカ数の最適化達成

Slide 60

Slide 60 text

まとめ技術的改善オートスケーリング: ピーク時も最適なレプリカ数で稼働運用自動化: 手動でのレプリカ調整が不要にコスト最適化リソース効率化: 必要な時に必要な分だけ稼働大幅なコスト削減: minReplicaCount 60%減を達成チーム効率化工数削減: 監視・調整作業からの解放価値創出: 機能開発・改善により多くの時間を投入可能