はじめに
こんにちは。プラットフォーム開発本部 第一開発部 ユーザーレビューグループの作田です。
DMMのユーザーレビューサービスを支えるバックエンドチームで、システムの開発・運用を担当しています。
本稿では、月間6億件以上のリクエストを処理するユーザーレビューサービスのバックエンドAPI（以下、レビューAPI）におけるリソース最適化の取り組みについてご紹介します。
背景と課題
DMMのユーザーレビューサービスは、連携しているECサービスの特性上、夜間にピークを迎え、レビューAPIへのリクエスト数は平常時の2倍以上に増加します。一方で、早朝のオフピークにはリクエスト数が大幅に減少するため、時間帯によってリソースが過剰となり、無駄なコストが発生しているという課題がありました。
時間帯ごとのレビューAPIリクエスト推移
しかし、運用開始後にリソースを見直すのは今回が初めての試みであり、どのように最適な設定を決定するかが課題でした。
そこで、レビューAPIのリソースを効率的に使用するため、KubernetesのPodスペックを調整しました。
適切なリソース設定は、サービスのパフォーマンス維持だけでなく、クラウドコスト削減にも直結するため、非常に重要な取り組みとなります。
スペックの調整
現状の設定
これまでは、スケーリングなしで3台のPodでピーク時のリクエストを処理できるように設定されていました。
その結果、約1年の運用を経てモニタリング結果を分析[1]したところ、平常時のCPU使用率は10〜20%程度にとどまり、リソースを過剰に割り当てられていることが確認できました。
更新前のCPU利用率
更新前のPod数の推移
更新前のリソース設定は以下の通りです。
初期のリソース設定値
| 項目 |
設定値 |
説明 |
| cpuRequest |
1000m |
CPUのリクエスト値 |
| cpuLimit |
1500m |
CPUの上限値 |
| averageUtilization |
70 |
HPA[2]のCPU利用率のスケール基準 |
| minReplicas |
3 |
最小Pod数 |
| maxReplicas |
20 |
最大Pod数 |
新しい設定
リソースの最適化を図るため、CPUリクエスト値を1000mCPUから300mCPUに調整し、CPUの上限値もそれに合わせました。
この調整は、モニタリング結果から現在のレビューAPIの平均CPU使用量を確認し、その値を基準に次の方法で算出しました。
CPUリクエスト値は、averageUtilization = 70% を基準にスケーリングできるように、全体の平均CPU使用量を minReplicas × 70% で割ることにより算出しています。
CPUリクエスト値の計算式
cpuRequests = 平均CPU使用量 / (minReplicas * averageUtilization)
cpuRequests = 620m / (3 * 70%)
cpuRequests = 295
cpuRequests ≒ 300
更新後のリソース設定は以下の通りです。
調整後のリソース設定値
| 項目 |
設定値 |
説明 |
| cpuRequest |
300m |
CPUのリクエスト値 |
| cpuLimit |
600m |
CPUの上限値 |
| averageUtilization |
70 |
HPAのCPU利用率のスケール基準 |
| minReplicas |
3 |
最小Pod数 |
| maxReplicas |
20 |
最大Pod数 |
成果と効果
今回のリソース最適化により、リソース消費の削減、HPAの適切な活用、コスト削減の3つの改善を実現しました。
以下、それぞれの成果について詳しく説明します。
1. リソース消費量の削減
今回の調整により、約1vCPU分のリソース消費量を削減し、リソースを効率的に利用できるようになりました。
調整の前後の cpuRequest と 平均Pod数 から算出したところ、約1000mCPUの削減となりました。
調整前後のリソース消費量の比較
| 項目 |
調整前 (2024/11) |
調整後 (2025/01) |
削減量 |
| cpuRequest |
1000m |
300m |
- |
| 平均Pod数 |
3.02個 |
6.77個 |
- |
| CPUリクエスト総量 |
3020mCPU |
2031mCPU |
-約1000mCPU |
更新後のCPU利用率
2. HPAの安全な活用
HPAを導入したことで、ピーク時には必要なリソースを確保しつつ、オフピーク時にはリソースを抑える動的なスケール調整ができるようになりました。
1日あたりスケールの変動が約20回発生していますが、これまで障害や不具合の報告はなく、安定した運用を維持できています。
更新後のPod数の推移
3. コスト削減
リソースの最適化により、無駄なリソース確保を抑えた結果、年間約 $319 のコスト削減の期待ができます。
前述の通り、約1vCPU分のリソース消費量削減をもとに算出しました。
削減コストの試算
- Amazon EC2 m5.4xlarge（16vCPU） の年間コスト[3]:
$5110
- 1vCPU あたりのコスト:
$5110 ÷ 16 = 約$319
まとめ
今回の取り組みでは、ユーザーレビューAPIのCPUリソース最適化を目的に、KubernetesのPodスペックを調整しました。
CPUリソースのリクエスト値を適切に調整したことで、リソース効率が大幅に向上しました。さらに、HPAを活用することで、トラフィックの変動に対して柔軟にスケールが可能となりました。
本記事が、読者の皆さまの参考になれば幸いです。
また、本取り組みは、MSA Platformチーム[4]の支援のもと、私たち以外のプラットフォームチームでも対応が必要な課題です。そうした中で、私たちは先陣を切って課題に挑戦し、具体的な成果を出すことができました。今回の実績は、後続のチームの足掛かりとなり、組織全体の効率化にも貢献できると考えています。
このような技術課題に挑戦し、サービスの成長を支えたいエンジニアをDMMでは募集しています。
ご興味のある方は、ぜひ募集ページをご覧ください！
補足
