第1回ではリスクマネジメントの全体像、そして
キャパシティプランニングを行うには、最低でも3つの変数を求める必要があります。1つ目は1サーバーあたりのクエリ/秒上限。2つ目は予測されるアクセス需要。3つ目は安全マージンです。
1サーバーあたりのクエリ/秒上限 * サーバー台数 * 安全マージン > アクセス数
必要とされるアクセス需要の予測精度は、サーバー予算と過負荷障害時の影響度に大きく依存します。たとえば、サーバー予算が潤沢にあれば、単純に十分なサーバーを追加することができますし、短期間の過負荷による障害を受容できるのであれば、やはり精度を求める必要はありません。
私たちの場合はどうでしょうか。まず、
3つのアクセス数の予測方法
アクセス数の予測は特定のエンジニアによる職人芸で行われがちですが、これはエンジニアリソースをスケールさせる際の障害になります。そこで私たちは、アクセス数などの予測を積極的に数式やロジックに置き換えています。
私たちの場合は、アクセス数予測に以下の3つの方法を併用しています。
- 「あけおめLINE」
のアクセス数増加率の幾何平均を用いる方法 - 平常時と
「あけおめLINE」 時の間のアクセス数増加比を用いる方法 - 前年の
「あけおめLINE」 のアクセス数をそのまま用いる方法
そしてこれら3つの予測方法の結果から、基本的にもっとも悲観的なものを採用するようにしています。ただし、合理的な理由がある場合は、適当な1つの予測結果を採用することがあります。また、従来の職人芸のような担当エンジニアの勘も侮ることはできません。私たちは、そういった勘や不安を後述の安全マージンとして式に含めるようにしています。
以降ではまず、上述の3つの方法それぞれについて詳しく紹介していきます。
1.「あけおめLINE」のアクセス数増加率の幾何平均
1つ目の予測方法は、アクセス数の増加率の予測値として、これまでの増加率の幾何平均を用いる方法です。
増加率について
増加率の幾何平均を用いて予測する利点はなんでしょうか。それは、ほかのメトリクスの変化率と比較分析可能な点です。
たとえば、私たちのサービスでは、アクティブユーザー数に比例してアクセス数が増えることが多いです。それにも関わらず、アクティブユーザー数が+10%しか増えていないのに、平時のアクセス数が+20%増えていた場合、ユーザー増加以外の要因があると考えられます。それは、アーキテクチャの変更かもしれませんし、UIの変更かもしれません。こういった変更はしばしば、過負荷の原因になります。見積もり時に事前に気づくことができれば、それを後述の安全マージンに反映して予防することが可能です。
なお、複数年にわたる増加率の幾何平均をとるためには、対象となるサービスが少なくとも数年間運用されている必要があることに注意してください。
では、具体的に表1の例を使って計算してみましょう。
日時 | ピークアクセス数 | 前年比 |
---|---|---|
2020/ |
3,000 | N/ |
2021/ |
3,200 | 1. |
2022/ |
3,250 | 1. |
2023/ |
4,000 | 1. |
2024/ |
????? | ???? |
まずは2020年から2023年までのアクセス数の前年比の幾何平均を求めてみましょう。下記の計算をすると、幾何平均が1.
これを最新のピークアクセス数である2023/
2.平常時と「あけおめLINE」時の間のアクセス数増加比
2つ目の予測方法である平常時と
この方法では、
(前年平日のピークアクセス数) : (前回の「あけおめLINE」アクセス数)
= (今年の平日のピークアクセス数) : (予測したい次の「あけおめLINE」アクセス数)
なお、私たちはサーバー追加作業の時間的猶予のために、10月初旬の平日ピークタイムを平常時のデータポイントとして採用しています。この場合、11月や12月に入ったコード変更の影響が計算から漏れることになるため、その点は留意する必要があります。
ではこちらも、表2の例で具体的に計算してみましょう。
日時 | ピークアクセス数 |
---|---|
2022/ |
1,000 |
2023/ |
4,000 |
2023/ |
1,200 |
2024/ |
????? |
式に当てはめると、2024年の予測値は4,800となります。
1000 : 4000 = 1200 : x
x = 4000 * 1200 / 1000
= 4800
3. 前年の「あけおめLINE」アクセス数をそのまま用いる
ここまでに説明した2つの方法は、どちらもこれまで積み重ねた複数のデータをもとに計算する方法です。そのため、サービスによっては前年より低いアクセス数予測が出ることがあります。たとえば、新しいバージョンの
このような場合、アクセス数予測を信じるのであれば前年以下のサーバー台数にしてもよいのですが、私たちは最低でも前年と同じアクセスが来ることを想定するという意味で、前回の元旦のアクセス数をそのまま予測候補のひとつとして用いています。キャンペーンなどのユーザー行動が大きく変わるタイミングでは、普段はアクティブでないユーザーが古い
たとえば、表3のようなケースでは、2024年の予測値は4000です。
日時 | ピークアクセス数 |
---|---|
2023/ |
4,000 |
2024/ |
????? |
3つの予測結果から総合的に決定する
ここまで紹介してきた3つの予測方法を整理すると下記のようになります。
- 「あけおめLINE」
のアクセス数増加率の幾何平均 - 必要なデータポイント:過去2年以上の
「あけおめLINE」 のアクセス数 - 数年分のデータがあれば、前年の
「あけおめLINE」 アクセス数を信頼できなくても、取り除いて利用可能。ユーザー数の変化率などほかのメトリクスと比較分析にも利用可能
- 必要なデータポイント:過去2年以上の
- 平常時と
「あけおめLINE」 時の間のアクセス数増加比 - 必要なデータポイント:前年の平常時と前年の
「あけおめLINE」、今年の平常時のアクセス数 - 予測精度はもっとも高いが、前年の
「あけおめLINE」 アクセス数が信頼できることが前提。平常時に別のキャンペーンが開催されている場合は予測精度が悪化しやすい
- 必要なデータポイント:前年の平常時と前年の
- 前年の
「あけおめLINE」 アクセス数 - 必要なデータポイント:前年の
「あけおめLINE」 アクセス数 - サーバー台数の最低ラインを保証するために利用
- 必要なデータポイント:前年の
これらをすべてのマイクロサービスについて計算し、基本的に悲観的な予測値を採用するようにしています。今回の例では、それぞれの予測値が4,400、4,800、4,000でしたので、もっとも悲観的な値
例外として、合理的な理由が説明できる場合は、特定の予測値を無視することがあります。たとえば前年の
安全マージンを決定する
ここまでで、下記の計算式における
1サーバーあたりのクエリ/秒上限 * サーバー台数 * 安全マージン > アクセス数
安全マージンとは、ここまでで算出した
「エンジニアの不安や職人的な勘」
私たちの場合は、下記のような判断基準で予測に自信がある場合は1.
- 予測に自信があるケース
(1. 4倍マージン) - 3つの予測値が近い値
(たとえば±10%程度) の場合
- 3つの予測値が近い値
- 予測に自信がないケース
(2倍マージン) - 3つの予測値が大きく離れている場合
- 新規機能の場合
- 月間アクティブユーザー数
(MAU) の成長率とアクセス数増加率の幾何平均予測 (予測方法1) が大きく離れている場合
たとえば、ある年の安全マージンの設定とその根拠は表4のようになりました。
サービス名 | サービスの説明 | 安全マージン | 安全マージンの根拠 | |
---|---|---|---|---|
capability-server | LINEスタンプ送信時の検証 | 1. |
ユーザー数や機能が安定していて、3種の予測見積もりでもほぼ同じ予測値が出るため | |
shop-server | 複数のマイクロサービスからのレスポンスの集約 | 2倍 | インフラマイグレーションに伴い、サーバースペックが大きく変更されたため | |
shop-proxy for LIFF | LINE Front-end Framework |
2倍 | 多くの機能がネイティブアプリ実装からWebViewベースに移行し、アクセス数需要の予測精度に不安があったため |
安全マージンが決まればサーバー台数が決まるため、そのサーバー台数になるようにサーバーを追加していきましょう。こういったキャパシティプランニングの結果、私たちは代表的なマイクロサービスでは実際のアクセス数が予測値の90 - 100%程度になっています。悲観的な予測値を採用しているため、予測値を上回ることは稀です。図2はあるマイクロサービスでの
なお、ほかの機能が障害の際にフォールバック先として指定されているものについては、フォールバック分も含めたマージンが必要になることに注意してください。
今回のまとめ
今回は私たちが行っているアクセス需要の予測について紹介しました。冒頭にも記載したとおり、予測方法自体は可能なかぎり定式化したうえで、勘や不安といった要素は安全マージンというバッファに明確に分けて積むようにしています。
これにより、たとえばモニタリングダッシュボード上で予測値と安全マージンをプロットしておき、予測の正確さや安全マージンの妥当さを後から振り返るといったことが容易になります。
前回から続いて、リスクマネジメントにおいて