インフラ・運用見積もり
ログを30日残すには、どれくらいの容量が必要？
使うツール
ログの保存先が埋まりそうなので、まず30日分の容量を知りたい。『一行は短いから大丈夫』では、件数が増えたときの見積もりになりません。逆に、圧縮前の量だけを見て過大に見積もることもあります。イベント数、一件当たりのバイト数、保持日数、圧縮後の割合、保存する総コピー数へ分解して考えます。
一日10万件、一件500byteから始める
events per day: 100000
bytes per event: 500
days: 30
compression ratio: 1
stored copies: 1ログ保存容量へこの条件を入れると、合計は1,500,000,000byteです。一日分は50,000,000byteで、それが30日あります。容量単位で表すと1.5GB、約1.397GiBです。結果にGiBと出ている数字をGBのつもりで読むと、容量の見積もりがずれるので、単位も一緒に確認します。
入力欄の『区間あたりのイベント数』は、この公開画面の設定では一日あたりとして計算されます。毎秒100件という測定を使う場合は、先に100×86,400＝8,640,000件/日へ換算します。100をそのまま入れると、一日100件という非常に小さい量を見積もることになります。測定の集計間隔と入力の間隔をそろえることが最初の確認です。
圧縮率0.5は、元の半分を保存する仮定
同じ条件で圧縮率を0.5にすると750,000,000byte、0.25なら375,000,000byteです。この欄は『圧縮後サイズ÷圧縮前サイズ』の倍率で、50という百分率を直接入れる欄ではありません。1なら圧縮による削減なし、0.5なら半分です。『50%削減』と『50%残る』はこの例では同じでも、25%削減なら残る割合は0.75になる点に注意します。
圧縮率はログの内容と方式に依存します。繰り返しが多いログと、既に圧縮・暗号化されたデータを含むログを同じ比率で扱う根拠はありません。代表的な実データで確認できない場合は、0.5を実測済みとして扱わず、1と0.5などの仮定を比較します。実ログを外部へ送って圧縮率を調べる機能はありません。
複製数は、追加分ではなく保存する総数
圧縮率0.5で総コピー数を2にすると、750,000,000byteが二つで1,500,000,000byteになります。この計算では、原本一つと追加レプリカ一つなら2です。サービスの設定で『レプリカ1』が追加分一つを意味する場合、その数字をそのままこの欄へ写すと、総コピー二つを一つとして見積もることになります。
バックアップや別地域へのコピーを含めるかは、見積もる範囲を先に決めます。すべて同じサイズのコピーとして数えるモデルなので、保存期間や圧縮方式が違う保管先は、別々に計算して合計する方が条件を説明しやすくなります。コピー数を増やしたことだけで、復旧できるバックアップが完成したと判断することもできません。
一件500byteは、何を含んだ数字か
メッセージ本文だけでなく、時刻、レベル、リクエストID、JSONのキーや区切りなども保存されるなら、その分を平均サイズへ含めます。表示上の文字数とUTF-8のバイト数は違います。日本語や絵文字を含むログでは特に、文字数をそのままbyteへ置き換えないようにします。短い代表例なら文字数・バイト数ツールで違いを確認できます。
一行を一イベントと仮定できない場合もあります。スタックトレースが複数行に分かれたり、集約処理が複数行を一つのイベントへまとめたりします。イベント数を測った単位と、平均サイズを測った単位が同じかを確認します。総バイト数を対応するイベント数で割る方法なら、どの単位で平均を取ったかが明確になります。
30日を90日にすると、三倍になる前提
一日10万件、一件500byte、圧縮なし、総コピー一つの条件なら、90日で4,500,000,000byteです。保存期間だけを三倍にすると容量も三倍になります。しかし、今後イベント数が増える見込みなら、同じ一日10万件を全期間へ適用してよいかを考えます。新機能やログレベルの変更で、一件のサイズまで変わることもあります。
一時的な障害でログが急増する場合、平均値だけでは短期の最大使用量を説明できません。通常時と増加時を分けた見積もりを作り、実際の保存先の使用量で確認します。ツールはピークを自動予測せず、過去のログを読み込んで傾向を分析する機能もありません。
ログ本文の量と、検索システムのディスク量は別
検索用の索引、管理情報、作業領域、ファイルシステムの余裕は、この基本の本文容量へ自動的に追加されません。保存製品によって構造が違うため、根拠のない一律倍率を実測値として付けることもできません。公式の容量説明や、自分たちのデータを使った測定で追加分を確認し、本文の概算と分けて記録します。
保持日数の設定と、実際に古いデータが消えて空き容量へ反映される時刻も、製品によって同じとは限りません。この計算は定常的に指定日数分を保持するモデルで、削除待ちや切替直後の一時的な増加は再現しません。結果をそのままディスク容量の上限へ合わせるのではなく、何を含んだ見積もりかを確認して使います。
一日の平均と、障害時の増加を分けて見積もる
一日10万件は、一秒10万件とは大きく違います。この画面の一日当たり件数へ秒間の値を入れるなら、一日86,400秒を掛けてそろえます。一秒100件が一日中続く仮定では一日864万件です。ただし、ある一秒の最大値を一日全体へ延ばすとピークがずっと続く見積もりになります。平均、通常の多い日、障害が続いた日など、何を想定した数かを分けて入力してください。計算機はその件数を実際に測った値へ変えることはありません。
障害時にはエラーの発生頻度だけでなく、一件の大きさも変わります。短いアクセス記録から長いスタックトレースへ変われば、通常時の平均500byteでは足りないかもしれません。件数を二倍にするだけの試算と、一件サイズも二倍にする試算では、後者の量は四倍です。どの変数を変えたかを残すと、容量増加の理由が分かります。この画面は複数シナリオを同時保存するものではないので、比較に必要な条件と結果は利用者の明示的なコピーなどで記録します。
保存期間を延ばす判断では、何を後から調べたいかも考えます。必要な項目を落として容量だけ減らすと、事故の時系列や対象を追えなくなる場合があります。逆に、不要な本文や秘密情報を多く残すことを容量が足りるという理由で正当化もしません。このツールは保存方針を決めるものではなく、決めた件数・サイズ・日数の積を見えるようにします。取得項目、保存期間、閲覧権限などの運用条件と容量の計算を、別々に確認する材料として使います。