要約

  • IBM Cold Vaultの最低課金サイズは1オブジェクト256 KB、最低保存期間は90日。仮に4 KBのオブジェクトなら、容量の課金基準は実サイズの64倍になる。
  • 圧縮率だけでは費用を説明できない。オブジェクト数、保存期間、読み出し方、まとめて保存した後の更新や削除まで含めて、ストレージを選ぶ必要がある。

技術部門の成功、経理部門の沈黙

圧縮率が改善した。保存する中身も減った。ところが容量の請求は思ったほど下がらない。そんなとき、最初に疑うべきものは技術者の計算とは限らない。請求書が数えている「大きさ」を確かめる方が早い。

IBM Cloud Object StorageのCold Vaultには、オブジェクトごとに256 KBという最低課金サイズがある。小さくしても、この床より下へは請求上の容量が降りない。最低保存期間は90日。Vaultなら128 KBと30日である。StandardとSmart Tierには最低サイズと最低保存期間がなく、データ取得料金もない。ただし、リクエストやパブリックネットワークへの転送は別の費用項目だ。ストレージクラスの説明

ここで4 KBのオブジェクトを仮定する。Cold Vaultでは容量の課金基準が256 KBとなり、比率は64対1。Vaultでは32対1になる。この64は容量の基準を比較した数字で、料金全体の倍率は単価、時間、読み出し、リクエストなどを加えて求める。

すべて4 KBのオブジェクトで、最低保存期間を満たしているとしよう。容量料金だけでStandardより安くなるには、Cold Vaultの容量単価がStandardの64分の1を下回る必要がある。具体的な料金表をその条件に当てはめれば、初めて安いかどうかの議論ができる。「あまり読まないから冷たいクラスへ」という命名上の納得では足りない。

ギガバイトの総量が隠すもの

調達会議では、データが何ギガバイトあるかを聞く。その次に、いくつのオブジェクトに分かれているかも聞きたい。同じ内容でも、分け方によって最低課金サイズを踏む回数が変わるからだ。

多数の小さな記録を一つずつ保存すれば、それぞれに最低値がかかる。同じ記録を大きなまとまりに収めれば、最低値はそのまとまりごとに適用される。内容の情報量は同じでも、購入する課金容量は同じとは限らない。

平均サイズだけを見ても安心できない。少数の巨大なオブジェクトが平均を押し上げ、その陰に大量の小さなオブジェクトが残ることがある。必要なのはサイズの分布であり、各範囲に何個あるかという数だ。各オブジェクトについて実サイズとクラスの最低サイズの大きい方を取り、それを足す。総量を先に足してから一度だけ最低値を当てると、別の計算になってしまう。

IBMは、同じインスタンス内の同一クラスの使用量をバケット横断で集計すると説明している。会計上の集計が、個々のオブジェクトに付く最低サイズを共用枠へ変えるわけではない。料金の項目も、保存容量、リクエスト、パブリックへの転送に分かれる。課金の説明

この構造では、すでに256 KBを下回るオブジェクトをさらに圧縮しても、Cold Vaultの最低課金容量は変わらない。データ量の最適化と請求の最適化は、ここで別々の仕事になる。圧縮の成果をそのまま予算削減額として報告すると、後で数字の説明に困る。

小分けの便利さには値札がある

ならば、全部まとめればよいのか。話はそこから少し面倒になる。

独立したオブジェクトは、名前と操作の境界を持つ。一つだけ読む、一つだけ差し替える、一つだけ消す。その扱いやすさを、大きなパッケージに詰めた後も維持したければ、アプリケーション側の設計が要る。

どの記録がどこにあるかという索引を維持し、更新と削除をどう反映するかを決める。形式と読み出し方によっては必要な範囲だけ取得できるが、より多くのデータを動かす設計にもなる。復元時には、内容と索引の対応を確かめなければならない。

特によく変わる記録では、小さな更新が大きなまとまりの書き換えにつながる可能性がある。容量の最低値を踏む回数は減っても、リクエスト、取得処理、運用作業が増えれば、節約額はそちらへ移る。料金の一列が細くなっただけで、事業全体が軽くなったと喜ぶのは早い。

これはパッケージ化の欠点を数えるための話ではない。独立した操作が必要なデータには、その自由を買う理由がある。まとめて扱えるデータには、まとめる理由がある。最低課金サイズは、その判断を経済計算へ引き出している。

クラスの変更にも作業が伴う。IBMの文書ではクラスはバケット作成時に選び、既存バケットのクラスは変更できない。希望するクラスの別バケットへオブジェクトを移動またはコピーする必要がある。クラス設定 バケットに関する説明

「後で安い方へ動かす」という計画には、移動先、コピー、アプリケーションの参照先、結果確認を入れておくべきだ。将来の選択肢は大切だが、その選択肢を使うための仕事も予算に載る。

単価交渉の前に

個別の節約額を出すには、その顧客のサイズ分布、保存期間、読み出し方、適用される見積もりが必要である。

一方、調達の順番は決められる。まず実際のオブジェクト群を把握する。長く残す小さな記録と、短期間で消す小さな記録を分ける。ほとんど読まないことと、必要なとき一件ずつ読めることも区別する。ひとまとめの「コールドデータ」という言葉には、予算を作るには異なる性質が入りすぎている。

IBMは最低値を公表している。買い手には、契約前に計算する材料がある。問題は、開発側が課金単位の数を決め、調達側が単価だけを値切る組織である。双方が担当項目で好成績を出しても、請求書はその積を受け取りに来る。

一次資料

料金の仕組みは上記のIBM文書に基づく。RIPE NCCの会員記録はInternational Business Machines Corporationの名録上の同一性確認にのみ用いた。4 KBは計算のために置いた仮定である。