第1回ではリスクマネジメントの全体像、そして「発生可能性の低減」に関する全般的な説明をし、第2回ではその「発生可能性の低減」のなかでもボトルネックの設計について紹介しました。今回は引き続き「発生可能性の低減」のための施策としてキャパシティプランニングを採り上げ、私たちが実際に行なっている方法をご紹介します。

キャパシティプランニングを行うには、最低でも3つの変数を求める必要があります。1つ目は1サーバーあたりのクエリ/秒上限。2つ目は予測されるアクセス需要。3つ目は安全マージンです。「⁠1サーバーあたりのクエリ/秒上限」については第2回で算出できていますので、今回はアクセス需要の予測方法と安全マージンの求め方について紹介します。

1サーバーあたりのクエリ/秒上限 * サーバー台数 * 安全マージン > アクセス数

必要とされるアクセス需要の予測精度は、サーバー予算と過負荷障害時の影響度に大きく依存します。たとえば、サーバー予算が潤沢にあれば、単純に十分なサーバーを追加することができますし、短期間の過負荷による障害を受容できるのであれば、やはり精度を求める必要はありません。

私たちの場合はどうでしょうか。まず、「⁠あけおめLINE」はビジネス上も非常に重要な機会であり、短期間の過負荷による障害は避けたいです。またPublic Cloudを利用していないこともあり、サーバーの増設がそのまま固定費の増加につながるため、サーバーコストも重要です。そのため、予測精度をあげるためのいくつかの工夫を行なっています。

3つのアクセス数の予測方法

アクセス数の予測は特定のエンジニアによる職人芸で行われがちですが、これはエンジニアリソースをスケールさせる際の障害になります。そこで私たちは、アクセス数などの予測を積極的に数式やロジックに置き換えています。

私たちの場合は、アクセス数予測に以下の3つの方法を併用しています。

1. 「あけおめLINE」のアクセス数増加率の幾何平均を用いる方法
2. 平常時と「あけおめLINE」時の間のアクセス数増加比を用いる方法
3. 前年の「あけおめLINE」のアクセス数をそのまま用いる方法

そしてこれら3つの予測方法の結果から、基本的にもっとも悲観的なものを採用するようにしています。ただし、合理的な理由がある場合は、適当な1つの予測結果を採用することがあります。また、従来の職人芸のような担当エンジニアの勘も侮ることはできません。私たちは、そういった勘や不安を後述の安全マージンとして式に含めるようにしています。

以降ではまず、上述の3つの方法それぞれについて詳しく紹介していきます。

1.「あけおめLINE」のアクセス数増加率の幾何平均

1つ目の予測方法は、アクセス数の増加率の予測値として、これまでの増加率の幾何平均を用いる方法です。「⁠幾何平均」とは、すべての値（このとき$n$個の値があるとします）を乗算したうえでその$n$乗根を取る操作で、売上の予測などにしばしば使われます。

増加率について「算術平均」（⁠すべての値を足し合わせて値の数で割る）する場合と比較すると、算術平均は「変化幅」が一定と考える一方、幾何平均は「変化率」が一定という考え方になります。これは複利的に変化していくことを意味しています。たとえば、アクセス数増加率が毎年+20%で一定であるようなサービスでは、2020年に1,000qpsであれば、2021年に1,200qps、2022年に1,440qpsと増えると考えるわけです。

増加率の幾何平均を用いて予測する利点はなんでしょうか。それは、ほかのメトリクスの変化率と比較分析可能な点です。

たとえば、私たちのサービスでは、アクティブユーザー数に比例してアクセス数が増えることが多いです。それにも関わらず、アクティブユーザー数が+10%しか増えていないのに、平時のアクセス数が+20%増えていた場合、ユーザー増加以外の要因があると考えられます。それは、アーキテクチャの変更かもしれませんし、UIの変更かもしれません。こういった変更はしばしば、過負荷の原因になります。見積もり時に事前に気づくことができれば、それを後述の安全マージンに反映して予防することが可能です。

なお、複数年にわたる増加率の幾何平均をとるためには、対象となるサービスが少なくとも数年間運用されている必要があることに注意してください。

では、具体的に表1の例を使って計算してみましょう。

まずは2020年から2023年までのアクセス数の前年比の幾何平均を求めてみましょう。下記の計算をすると、幾何平均が1.1ということがわかります。

これを最新のピークアクセス数である2023/01/01の4,000に乗算すると、2024/01/01のアクセス数の予測値が4,400と求まります。

2.平常時と「あけおめLINE」時の間のアクセス数増加比

2つ目の予測方法である平常時と「あけおめLINE」時の間のアクセス数増加比を使う方法は、必要となるデータが少なく、シンプルで精度も良いため重宝しています。

この方法では、「⁠あけおめLINE」アクセス数を下記の比例式で計算します。

  (前年平日のピークアクセス数) : (前回の「あけおめLINE」アクセス数)
= (今年の平日のピークアクセス数) : (予測したい次の「あけおめLINE」アクセス数)

なお、私たちはサーバー追加作業の時間的猶予のために、10月初旬の平日ピークタイムを平常時のデータポイントとして採用しています。この場合、11月や12月に入ったコード変更の影響が計算から漏れることになるため、その点は留意する必要があります。

ではこちらも、表2の例で具体的に計算してみましょう。

式に当てはめると、2024年の予測値は4,800となります。

1000 : 4000 = 1200 : x
x = 4000 * 1200 / 1000
  = 4800

3. 前年の「あけおめLINE」アクセス数をそのまま用いる

ここまでに説明した2つの方法は、どちらもこれまで積み重ねた複数のデータをもとに計算する方法です。そのため、サービスによっては前年より低いアクセス数予測が出ることがあります。たとえば、新しいバージョンの「LINE」アプリからはアクセスされなくなったAPIがある場合などです。

このような場合、アクセス数予測を信じるのであれば前年以下のサーバー台数にしてもよいのですが、私たちは最低でも前年と同じアクセスが来ることを想定するという意味で、前回の元旦のアクセス数をそのまま予測候補のひとつとして用いています。キャンペーンなどのユーザー行動が大きく変わるタイミングでは、普段はアクティブでないユーザーが古い「LINE」アプリを使って参加してくれることがあり、予測値以上のアクセスの可能性があるためです。

たとえば、表3のようなケースでは、2024年の予測値は4000です。

3つの予測結果から総合的に決定する

ここまで紹介してきた3つの予測方法を整理すると下記のようになります。

1. 「あけおめLINE」のアクセス数増加率の幾何平均
   • 必要なデータポイント：過去2年以上の「あけおめLINE」のアクセス数
   • 数年分のデータがあれば、前年の「あけおめLINE」アクセス数を信頼できなくても、取り除いて利用可能。ユーザー数の変化率などほかのメトリクスと比較分析にも利用可能
2. 平常時と「あけおめLINE」時の間のアクセス数増加比
   • 必要なデータポイント：前年の平常時と前年の「あけおめLINE⁠」⁠、今年の平常時のアクセス数
   • 予測精度はもっとも高いが、前年の「あけおめLINE」アクセス数が信頼できることが前提。平常時に別のキャンペーンが開催されている場合は予測精度が悪化しやすい
3. 前年の「あけおめLINE」アクセス数
   • 必要なデータポイント：前年の「あけおめLINE」アクセス数
   • サーバー台数の最低ラインを保証するために利用

これらをすべてのマイクロサービスについて計算し、基本的に悲観的な予測値を採用するようにしています。今回の例では、それぞれの予測値が4,400、4,800、4,000でしたので、もっとも悲観的な値（すなわち、もっとも大きな値）である4,800を採用します。

例外として、合理的な理由が説明できる場合は、特定の予測値を無視することがあります。たとえば前年の「あけおめLINE」に障害があってデータ自体が参考にできない場合は、ほかの予測値を採用する必要があります。また、その年にリリースされたばかりの新機能の場合は、どの方法を用いても予測することができません。そういった場合は、基本的にほかのサービスのアクセス数予測を参考にします。特に「あけおめLINE」以外のキャンペーンなど不定期なイベントによるアクセススパイクがあった場合は、そのデータの分析と蓄積が後々の自分を助けることになります。

安全マージンを決定する

ここまでで、下記の計算式における「1サーバーあたりのクエリ/秒上限」と「予測したアクセス数」を算出できました。最後にサーバー台数を見積もるために、安全マージンを決定します。

1サーバーあたりのクエリ/秒上限 * サーバー台数 * 安全マージン > アクセス数

安全マージンとは、ここまでで算出した「1サーバーあたりのクエリ/秒上限」や「予測したアクセス数」に誤差があった際（絶対にあります）に、その誤差を吸収するためのマージンです。この安全マージンは、主に2つの要素を考慮して決定します。ひとつはエンジニアの不安や職人的な勘、もうひとつはスケールアウトの迅速さです。

「エンジニアの不安や職人的な勘」とは、たとえば大規模なアーキテクチャ変更をその年に実施していたり、そもそもこういった過負荷の予防に不慣れだったりと、自身の作業に不安が残っている状態のことを言います。大規模なキャンペーンを準備するエンジニアは、キャンペーンが終了するまで、常にそういった不安からくるストレスを感じ続けます。その結果、ほかのヒューマンエラーを誘発することもあるため、エンジニアの精神衛生を改善するためにも安全マージンを確保しましょう。逆にスケールアウトが迅速に行える場合、たとえば数秒以内にオートスケールが完了するようなケースでは、安全マージンを小さくすることも可能です。

私たちの場合は、下記のような判断基準で予測に自信がある場合は1.4倍の安全マージン、予測に自信がない場合は2倍の安全マージンを取っています。

• 予測に自信があるケース（1.4倍マージン⁠）⁠
  • 3つの予測値が近い値（たとえば±10%程度）の場合
• 予測に自信がないケース（2倍マージン⁠）⁠
  • 3つの予測値が大きく離れている場合
  • 新規機能の場合
  • 月間アクティブユーザー数（MAU）の成長率とアクセス数増加率の幾何平均予測（予測方法1）が大きく離れている場合

たとえば、ある年の安全マージンの設定とその根拠は表4のようになりました。

安全マージンが決まればサーバー台数が決まるため、そのサーバー台数になるようにサーバーを追加していきましょう。こういったキャパシティプランニングの結果、私たちは代表的なマイクロサービスでは実際のアクセス数が予測値の90 - 100%程度になっています。悲観的な予測値を採用しているため、予測値を上回ることは稀です。図2はあるマイクロサービスでの「あけおめLINE」時のアクセス数です。オレンジ色のラインが予測値、赤いラインが安全マージンであり、安全マージンが予測値以上の負荷を吸収したことがわかります。

なお、ほかの機能が障害の際にフォールバック先として指定されているものについては、フォールバック分も含めたマージンが必要になることに注意してください。

今回のまとめ

今回は私たちが行っているアクセス需要の予測について紹介しました。冒頭にも記載したとおり、予測方法自体は可能なかぎり定式化したうえで、勘や不安といった要素は安全マージンというバッファに明確に分けて積むようにしています。

これにより、たとえばモニタリングダッシュボード上で予測値と安全マージンをプロットしておき、予測の正確さや安全マージンの妥当さを後から振り返るといったことが容易になります。

前回から続いて、リスクマネジメントにおいて「発生可能性の低減⁠」⁠、つまり予防について紹介しました。次回は、リスクの受容や共有など、ほかのリスクマネジメント方法について掘り下げた紹介をする予定です。