こんにちは！

当社では、AIを使用した動画変換や動画生成サービスを展開しておりますが、このようなサービスは推論過程（つまり、動画生成をするときの計算処理）でもGPUに高負荷の計算を行わせる必要があります。

その為、GPUが動画を生成している過程ではユーザーは生成結果を待つことになります。特に画像や動画生成には膨大な計算処理が発生するため、待ち時間も長くなり、従来のSAASのように一瞬で応答という体験は難しく、長ければ数十秒～数分、数十分と待ち時間が発生する場合があります。

このようなサーバーシステムを設計する際、「１つのサーバーで、いや、１つのGPUで何人のユーザーをサポートできるのか？」という問いは常に重要です。

特に、同時に1件しか処理できない変換サーバーなど、制約のあるシステムでは正確な容量計算が不可欠です。

本記事では、キューイング理論に基づいてこのような変換サーバーの最適ユーザー数を計算する方法を解説いたします。また、実用的な計算ツールもご紹介します。

問題設定

では、シンプルな問題設定をしてみましょう

• 同時に1件の変換しか処理できないサーバーがある
• 1件の変換に平均5分かかる
• ユーザーは不規則にサービスにアクセスする
• ピーク時間にはアクセスが集中する

この状況で、快適なサービスを提供するには１台のサーバーで何人のユーザーまでサポートすべきでしょうか？

キューイング理論の基礎

この問題はキューイング理論（待ち行列理論）で解くことができます。

キューイング理論は、限られたリソースに対する需要が重なった場合の待ち行列の振る舞いを数学的に分析する理論です。

サーバーが1台で、到着がポアソン分布、サービス時間が指数分布に従うと仮定すると、これはM/M/1モデルと呼ばれるシステムになります。

計算モデルの導出

まず、基本的なパラメータを定義しましょう

• t_p: 処理時間（分/件）
  変換サーバーが1件の処理リクエストを完了するのにかかる平均時間です。例えば、ファイル変換ならファイルの読み込み、処理、出力までの全工程を含みます。この値が小さいほど、サーバーの処理能力は高くなります。例：5分/件
  
• μ (mu): サービス率（件/時間）= 60分 ÷ t_p
  1時間あたりに処理できる最大リクエスト数を表します。1時間（60分）を1件あたりの処理時間（t_p）で割ることで算出されます。例えば処理時間が5分なら、μ = 60分 ÷ 5分 = 12件/時間となります。これはサーバーの理論上の最大処理能力です。
  
• ρ (rho): 目標システム利用率
  サーバーの稼働率の目標値で、0〜1の値をとります。キューイング理論によれば、安定した運用のためには0.7〜0.8程度に設定することが推奨されます。ρが1に近づくと待ち行列が急速に増加し、ユーザー体験が悪化します。例：0.8（80%の稼働率）
  
• P_c: ピーク係数
  平均的なアクセス時間帯と比較して、最も混雑する時間帯のアクセス数の比率です。例えば、P_c = 2.5は、ピーク時のアクセス量が平均の2.5倍になることを意味します。この値は過去のアクセスログから算出するか、類似システムの実績から見積もります。
  
• H: 稼働時間（時間/日）
  システムが1日に稼働している時間の合計です。24時間365日稼働のシステムなら24時間、業務時間内のみ利用可能なシステムなら、例えば8-20時の12時間などとなります。
  
• P_a: アクセス確率（1日あたりの利用確率）
  登録ユーザー1人が1日のうちにシステムを利用する確率です。例えば、P_a = 0.3は、各ユーザーが30%の確率で1日にシステムを利用することを意味します。全ユーザーが毎日利用するシステムならP_a = 1となります。
  
• F: 1ユーザーあたりの1日の変換回数
  ユーザーがシステムを利用する日に、平均して実行する変換処理の回数です。例えば、F = 2は、システムを利用する日には平均して2回の変換処理を行うことを意味します。ユーザーの利用パターンによって変わる値です。
  

キューイング理論によれば、システムが安定するためには利用率ρが1未満である必要があります。実際には、待ち時間を合理的な範囲に抑えるために、ρ = 0.7〜0.8程度に設定することが推奨されます。

計算手順

１台のサーバーでサポート可能な総ユーザー数

N = R ÷ r_u

1ユーザーあたりの1日の平均リクエスト数

r_u = P_a × F

1日の総処理可能リクエスト数

R = λ_a × H

ピーク時も安定稼働させるための平均到着率

λ_a = λ_s ÷ P_c

安定稼働時の平均到着率

λ_s = ρ × μ

サービス率の計算

μ = 60 ÷ t_p

これらをまとめると、最終計算式は以下になりますね！

N = (ρ × μ × H) ÷ (P_a × F × P_c)

この式に基づいて、サーバー1台でサポートできる最適ユーザー数を計算できます。

さて、自分で計算するのも面倒なので、ツールをご準備いたしました♪

最適ユーザー数計算ツール

以下のツールを使って、サーバーの最適ユーザー数を簡単に計算できます。各パラメータを調整すると、サポート可能なユーザー数がリアルタイムで更新されます。

実際の運用上の考慮事項

上記ツールは理解促進のためシンプルな条件設定と計算モデルを使用しておりますが、実際のシステム運用では以下のような追加要素も考慮する必要があります

1. ピーク時間の分析

実際のアクセスパターンを収集・分析することで、より正確なピーク係数を把握できます。例えば、システムログを分析して時間帯別のアクセス分布を作成し、平均値との比率を求めることでピーク係数を算出できます。

2. 処理時間のばらつき

実際の処理時間は一定ではなく、変動します。変換内容によって処理時間が大きく異なる場合は、平均処理時間だけでなく、最大処理時間や処理時間の分散も考慮することが重要です。

3. アクセス確率の見直し

ユーザーのアクセス頻度は時間帯や曜日、季節、サービスのバズり度合いによっても変化します。長期的なデータ収集を通じて、より正確なアクセス確率を見積もることで、計算精度を向上させることができます。

4. ユーザー体験の考慮

サーバー容量を計算する際、技術的な限界だけでなく、ユーザー体験も重要です。例えば、待ち時間が長くなりすぎないよう、余裕を持った設計が必要です。目標システム利用率を0.7程度に設定するのはこのためです。

パラメータの自動最適化：機械学習の活用

上記の考慮事項をベースに、実際のサービス運用データを活用して継続的に最適化していくことが理想的です。

さてさて、最適化といえば、当社も得意な機械学習の出番です。

データ収集とモニタリング

最適な容量計算のために、以下のようなデータを継続的に収集します

• アクセスログ: 時間帯別、曜日別、季節別のアクセスパターン
• 処理時間ログ: 各変換処理の実行時間と処理内容の関係
• 待ち時間データ: ユーザーがキューに入ってから処理開始までの待機時間
• ユーザー行動データ: キャンセル率、リトライ率、利用頻度など

機械学習によるパラメータ最適化

収集したデータを基に、以下のパラメータを機械学習モデルで自動的に更新・最適化できます

1. ピーク係数の動的予測
   • 時系列分析（ARIMA, Prophet）を用いて、曜日や季節に応じた将来のピーク係数を予測します
     ・ARIMAは、Auto-Regressive Integrated Moving Average（自己回帰和分移動平均）の略で、時系列データの予測に広く使われる統計モデルです。
     ・Prophetは、Facebookが開発した時系列予測ツールで、大規模なデータに対しても効率的に予測を行えます。
     
   • 特別なイベントやプロモーション時、意図しないバズりなど異常値（スパイク）検出と自動調整
     
2. 処理時間の予測モデル
   • 変換内容の特徴（動画種類、ファイルサイズなど）から処理時間を予測する回帰モデル
   • ユーザー別、コンテンツ別などの軸での処理時間傾向の学習
     
3. アクセス確率の個別化
   • ユーザーのセグメンテーションによる細分化されたアクセス確率モデル
   • ユーザーの行動履歴に基づいた予測モデルの構築
     
4. 最適システム利用率の自動調整
   • ユーザー満足度と処理効率のバランスを最適化するための強化学習
   • ユーザーのフィードバックデータを活用した利用率の調整

実装アプローチ

あとは機械学習ベースの最適化システムの実装とおなじです。データパイプラインをつくって、各種ログデータを効率的に集約していきます。
ログデータから週次でトレーニングにいれて、上記変数を予測します。予測された変数をもとに１台のGPUサーバーでさばけるユーザー数をより精度高く見積もり、サーバの増強戦略を検討します。ユーザー増加に追いつくようにサーバーを増強していくイメージですね。

こうした変数は実際にサービスを運用していかないとわからないので、本ブログのように最初は経験値をもとに設定しています。

まとめ

変換サーバーの容量計算は、単純に「1時間に何件処理できるか」という計算だけでは不十分で、ユーザーの行動パターン、ピーク時の集中度、システムの安定性などを総合的に考慮する必要があります。

本記事でご紹介した計算モデルは、キューイング理論に基づく１つの実践的なアプローチですが、あり、多くの長時間処理GPUサーバーシステムの容量計画に応用できるとおもいますが、あくまで理論的な見積もりであるため実際のシステム容量を決定する際は、実測データに基づく調整や、パフォーマンステストを併用するのが良いようにおもいます。