こんにちは。ヌーラボでBacklogのSREを担当しているZakiです。
本記事はヌーラバーブログリレー2022の22日目の記事です。

はじめに

弊社のタスク・プロジェクト管理ツールBacklogでは、 ファイル機能及びSubversion機能を提供しています。それらの機能で使用されるデータはAWS上に保存しています。具体的にはEC2上にアタッチされたEBSに保存されています。使って頂けるお客様が増えたり活用が進んだりするにつれて保存データは増えていきます。
EBSには保存できるデータの上限が、そしてEC2にはアタッチできるEBSの数の上限があるため、データの保存には制約があります。保存したデータがこの上限にいつ到達するか分からないという課題がBacklogにはありました。
その課題に対応するため、保存データが将来的にどのように増えるかを予測したのでその内容について記載します。

データ保存の上限

”はじめに”で述べたデータ保存の制約について説明していきます。
まず、EC2にアタッチできるEBSのボリューム最大サイズには上限があります。Backlogではgp3というボリュームタイプを使用しているのでボリューム最大サイズは16TiB（※1）という制限があります。
次に、一つのEC2にアタッチできるEBSの個数にも制限があり、Nitro System 上に構築されたEBS のみのインスタンスに追加のネットワークインターフェイスのアタッチがない場合は、そのEC2に最大 27 個の EBSをアタッチできます（※2）。Backlogも上記の例と同じ構成なので、最大 27 個の EBSをアタッチできます。上記のイメージを下記に図示します。

データ保存の制約

まとめると、最大16TiB * 27個のEBSをデータの保存に利用できます。
もちろん、EC2の台数を1台から2台以上に増やす、ボリュームタイプをボリューム最大サイズが64TiBであるio2 Block Express（※3）に変えるという他のアプローチもありますが、それらのアプローチは本記事の考慮外とさせて頂きます。

将来予測のための準備

将来予測を始めるにあたって、まずは現状を整理します。
Backlogではファイル機能及びSubversion機能で保存されるデータのメタデータがDBに保存されています。そのメタデータにファイルが作成された日付とファイルサイズが記録されているので、SQLを用いてデータを取得します。
取得したデータを月ごとにまとめた表を下記に記載します。”date”がファイルが作成された月で、”totalsize_per_month”が月ごとに作成されたファイルサイズです。

取得したデータの表

取得した情報をスプレッドシートに転記し、各月の容量を算出します。”total_size”はその月時点で保存されている合計のファイルサイズです。

total_sizeを追加した表

将来予測の方法

次に、total_sizeに近似する曲線を導いていきます。当初、データを一次関数、二次関数、指数関数のいずれかで近似できるのではと考え、手作業で方程式を解いて近似曲線を求めていたのですが、Googleスプレッドシートを用いて簡単に近似曲線を求めることができると分かったのでこちらを紹介します。こちらのページを参考にGoogleスプレッドシートでtotal_sizeをプロットし、下記の通りに設定したところ、近似曲線を求めることができました。

• ”トレンドライン”にチェック
• 種類：多項式
• 多項式次数：3
• ラベル：方程式を使用
• ”決定係数を表示する”にチェック

Googleスプレッドシートのグラフでは、下記のように表示されます。実際に使用したデータはセンシティブな情報になりますので、参考としてサンプルデータを用いた二次関数のグラフを記載しています。

サンプルデータを用いた二次関数と近似曲線のグラフ

さて、算出した近似曲線と元データの間でどの程度の差があり、将来予測に使えるものかを評価する必要があります。その評価をする尺度として、決定係数(R2)があります。決定係数(R2)は0~1の値の範囲をとり、1に近付くに従って相対的な残差が少ないことを表します。詳しくはwikipediaをご参照ください。
上記で算出した近似曲線は決定係数(R2)が1であり、与えられたデータに対しては当てはまるが、未知のデータに対しては当たらない過剰適合という状態の可能性があります。他の種類の関数で算出したところ、決定係数(R2)は次の通りになりました。

• 多項式次数が2の多項式：0.997
• 指数関数：0.984
• べき級数：0.994
• 線形：0.876

決定係数(R2)は1に近づくと元データとの間での差がなくなるという点で良いですが、一方で上記の過剰適合になる可能性も高くなるようです。通常業務で統計分析の経験がない私としては、どの関数を予測として採用するかは悩みどころです。結局、決定係数(R2)=1の”多項式次数が3の多項式”と実データとの差分が大きい線形は選択肢から除外することにして、残りの3つを将来予測として使うことにしました。なお、近似曲線の精度を高めていくには、一回きりの算出ではなく、半年や一年などデータを増やした状態で定期的に算出して、その都度修正していくのが良いのではと感じました。
最後に、近似曲線を用いて将来予測をする方法を説明します。将来の日付のxを用意し、上記のグラフの上部に表示された方程式にxの値を代入してyを求めます。このyが予測したtotal_sizeになります。イメージは次の通りです。

xと予測したy(total_size)の表

データ保存の上限が16TiB * 27=432TiBなので、y(total_size)が432TiBに到達するdateを求めることでデータ保存の上限に到達する日付が分かります。

将来予測して良かったこと

将来予測を実施することで、データ保存の上限に到達する日付を把握することができました。

まとめ

本記事では、Backlogのファイル機能及びSubversion機能に保存されているデータが将来的にどのように推移するかを予測しました。保存可能なデータの制約について説明し、近似曲線を用いて予測を実施することで、データ保存の上限に到達する日付を把握することができました。

本記事は以上となります。最後までご覧頂きありがとうございました。
この記事が皆さんのお役に立てれば幸いです。