KiB を GB に変換

1 キビバイトはちょうど 1,024 バイトです。この名前は 1998 年に、「キロバイト」に 1,000 の意味を返してやるために導入されました。もっとも、定着したとは言いがたい状況です。

1 ギガバイトは 10 億バイトです。ディスクのメーカー、通信のデータ容量、動画のサイズが使っているのと同じ十進の意味です。

倍率は 0.000001 で、これをそのまま持ち歩く人はまずいません。0.000001 に丸めると 0.39 % ずれます。小さい数では見えもしませんが、1,000 KiB あたりで、ずれは丸ごと 1 単位になります。

丸める前に知っておく価値があるのは、ずれの大きさそのものではなく、それを無視できなくなる地点のほうです。それより下なら短い倍率が賢明で、それより上なら上の入力欄を使ってください。あちらは書き出す前に丸めません。

KiB 1 つはひとつ下の単位の 1,024 倍で、kB 1 つは 1,000 倍です。このページでは 0 GB と 0 GB の差——2.4 %——になり、段を上がるごとにこの隔たりは開いていきます。写真 1 枚では丸め誤差でしかないものが、ハードディスクでは目に見える割合になるのはそのためです。

「容量が消えた」という話の中身は、これだけです。kB で売られたディスクには、書いてあるとおりのバイト数が入っています。それを 1,000 ではなく 1,024 で割り、名前は kB のまま表示しているのが Windows です。macOS は 10.6 以降ディスクの容量を十進の単位で数えているので、同じディスクが 2 台のパソコンで違う大きさに見えることがあります。減ったものはなく、丸めているのでもありません。同じバイト数に、名前が 2 つあるだけです。

ウェブシステムの計測側は2進法の単位で数えます。それを生み出すツールがそうしているからです。オブジェクトの平均サイズはファイル一覧やビルドレポート、ストレージバケットの要約から来ていて、そのどれもが1,024で割っています。商用側は10進法のギガバイトで数えます。転送が売買される単位は、両者を区別する必要が生じるずっと前からそうだったからです。

1つのオブジェクトではこの差は現れず、1か月分のトラフィックでは現れます。平均250KiBのリクエスト100万件は256,000,000,000バイト、つまり256GBです。1,024ではなく1,000で計算すると250GBになり、これはトラフィックにちょうど比例して増える6ギガバイトの過小評価です。リクエストを倍にすれば不足も倍になります。

信頼できる順序は、できるだけ長くバイトのまま持つことです。オブジェクトあたりのサイズをキビバイトで取り、1,024を掛けてバイトにし、件数を掛けてから、最後に10億で割ってください。最後の割り算より前のすべての段階は整数演算で正確なので、丸めの判断が必要になるのは最後の1回だけです。

逆の順序——各オブジェクトをギガバイトに変換してから合計する——は項目ごとに丸め誤差を入れ、その項目数こそが合計を大きくしている当のものです。この方法で組まれたスプレッドシートは、どの行を見ても見えない理由で数パーセントずれることがあり、それはあとから見つけるのがとても難しくなります。

アクセスログはキビバイトではなくバイトを記録していて、この計算にとって数少ない朗報です。bytes-sent フィールドはリクエストごとの生の数値なので、その列を合計して10億で割れば、単位の疑問なしに10進法のギガバイトが得られます。数字がすでに KiB で要約されて届く場合——ダッシュボードやレポート、同僚のメッセージ——は変換を適用する必要があり、その要約が何を丸めたのかを確かめる価値があります。

ログが平均値だけでは分からないもう1つのことは分布の形です。平均オブジェクトサイズが250KiBというのは、1万件の小さなレスポンスと一握りの非常に大きなものかもしれません。平均に基づく予測は合計としては正しくても、キャッシュの挙動や接続数、サイズ制限の効果といった運用上のあらゆる帰結については間違っています。合計はいちばん簡単な部分です。

ペイロードは転送のすべてではありません。応答ヘッダーはリクエストごとに数百バイトを追加し、キャッシュされているかどうかに関わらず送られます。プロトコルの折衝は新しい接続のたびにバイトを消費し、リダイレクトは2回転送を発生させ、再試行された失敗リクエストは試行ごとに数えられます。小さなオブジェクトの集まりでは、このオーバーヘッドが全体のかなりの部分を占めることがあり、そのどれもストレージの一覧が示すオブジェクトサイズには現れません。

これは単位の補正と一緒に述べておく価値があります。両方が同じ方向に働き、混同しやすいからです。プロバイダーが予測より多い使用量を報告してきたら、単位のずれはその2.4パーセントを説明し、それ以上ではありません。それを超える分はモデルが考慮していなかったトラフィックであり、算術ではなくリクエストのパターンを探すほうが時間を有効に使えます。

オブジェクトの平均サイズをキビバイトで取り、1,024を掛けてバイトにし、想定リクエスト件数を掛けて10億で割ってください。100KiBのオブジェクト1,000万件のリクエストは1,024,000,000,000バイト、つまり1,024GB、1.024TBです。この最後の数字自体が有用な目安になります。100キビバイトのオブジェクト1,000万件は、ほぼちょうど10進法の1テラバイトです。

そのあとは不確かさを正直に扱ってください。単位について4桁の精度を持ちながらリクエスト件数については2倍もあいまいな予測は、変換したところでより正確にはなりません。合計はトラフィックの見積もりが導く幅として示し、少なくとも算術自体が誤差を足さないよう、正確な係数を使ってください。

照合はどちらの側もバイトで行うのがいちばんうまくいきます。プロバイダーが請求してきたギガバイトを10億倍してバイトに戻し、自分のログに記録されたバイト数を合計して、この2つの整数を比べてください。そのあとに残る差には、単位のない丸めた数字どうしを比べるより、はっきりした原因があるはずです。

およそ2.4パーセントの差は、経路のどこかにあるキビバイトとキロバイトの取り違えを示しています。たいてい2進法のツールが作った要約を10進法として読んでいる場合です。7.4パーセントの差は同じ間違いが1つ上の接頭辞で起きていることを示します。差の大きさを認識するほうが、原因をたどるより早いことがよくあります。