なぜ、この問題が起きたのか？（ストレージの違い）
「150日の亡霊」との戦いを記録する前に、なぜ今回のような問題が発生したのか、その背景にあるストレージ技術の違いについて少し触れておきたいと思います。
特に、「Wasabiクラウドストレージ」と、普段我々がPCやVPSで利用している「SSD」との違いを理解することが重要です。
Wasabiに用いられているオブジェクトストレージとは？
前述の通り、Wasabiは非常に安価なGB単価が魅力の「オブジェクトストレージ」サービスです。
AWS S3と互換性のあるAPIを持ち、データ転送量（下り）が無料という特徴があります。
しかし、今回の問題の核心となったのが「最低90日間保持ポリシー」です。
これは、一度アップロードされたデータは、たとえ 削除または上書き（※） しても90日間は課金対象として残り続ける、という重要なルールでした。
(※ オブジェクトストレージの特性上、ファイルの更新は古いファイルの削除と新しいファイルの作成として扱われます)
もちろん、削除されずに保存されている通常のデータ（アクティブストレージ）については、Wasabiの安価な月額GB単価で課金されます。この90日ポリシーは、あくまで削除または上書きされたデータに適用されるものです。
オブジェクトストレージ vs 通常のSSD/HDD
PCの内蔵SSDや、VPSのローカルストレージは、通常「ファイルストレージ」や「ブロックストレージ」と呼ばれる方式です。
これらは、私たちが普段フォルダやファイルとして認識している階層構造でデータを管理し、ファイルの一部を直接書き換える（上書き更新する）ことができます。ファイルを削除すれば、基本的にはその領域は解放され、空き容量が増えます。
一方、Wasabiのような「オブジェクトストレージ」は、データを「オブジェクト」という単位で扱います。各オブジェクトは、データ本体と、それに関連する情報（メタデータ）で構成され、一意のIDで管理されます。
ここでの大きな違いは、オブジェクトは基本的に変更できない（イミュータブル） という点です。ファイルを「更新」したい場合、オブジェクトストレージでは実際には以下の操作が行われます。
- 新しいバージョンのオブジェクトを作成（アップロード）
- 古いバージョンのオブジェクトを削除
つまり、更新＝「削除＋新規作成」 となるのです。Wasabiでは、この「削除」された古いバージョンのオブジェクトに対して、「最低90日間保持ポリシー」が適用され、課金が発生します。
s3fsのようなツールを使うと、オブジェクトストレージをあたかも通常のフォルダのように扱うことができますが、その裏側では上記のようなオブジェクト操作が行われていることを理解しておく必要がありました。
なぜ以前の運用（Redmine/BookStack/Piwigoの添付ファイル）では問題なかったのか？
以前の構成では、RedmineやBookStackの添付ファイルや画像データのみをWasabiに保存していました。これらのデータは、
- 一度アップロードされたら、頻繁には更新・削除されない
という性質を持っています（Write Once, Read Manyに近い）。
そのため、Wasabi上での「削除＋新規作成」操作が非常に少なく、「最低90日間保持ポリシー」の影響をほとんど受けませんでした。当時の請求額（月8ドル強）の大部分は、実際のデータ保存量（アクティブストレージ）が1TB未満だったために発生する「Minimum Active Storage（最低利用料金）」によるものだったのです。
主犯と従犯、GrowiとNextcloudとオブジェクトストレージの「破滅的な相性の悪さ」
しかし、Growi (MongoDB) と Nextcloud のデータ格納先をWasabiに変更したことで、この状況は一変しました。これらのアプリケーションは、その特性上、超・超高頻度でファイルの書き換え（＝Wasabi上での削除＋新規作成） を行うのです。
Growiとの相性の悪さ
特にGrowi (MongoDB) においては、以下の技術的な理由からWasabiとの相性が極めて悪かったと言えます。
- MongoDBのストレージ管理方式と不一致:
- MongoDB(WiredTiger)はデータをページ単位で管理し、書き換えのたびにページ全体が更新されることがあるため、オブジェクトストレージ上では大きな変更とみなされる。
- → これがWasabiの「削除後も90日間課金が続く」仕組みと相性が非常に悪かったのです。
- ログファイルやジャーナルファイルの大量発生:
- MongoDBはデータの整合性を保つために「ジャーナルファイル」を作成するが、これが頻繁に書き換わる（そしてローテーションされる）ため、Wasabiの最低保持期間90日に引っかかりやすく、不要なコスト増加につながりました。
- WiredTigerエンジンの特性:
- MongoDBのデフォルトエンジン「WiredTiger」は、ストレージの圧縮やバックグラウンドでの最適化（コンパクション）でもファイルの書き換えを行うため、Wasabiのようなオブジェクトストレージとは相性がよくありません。
.wtファイルの高頻度な書き換えは編集画面で特に顕著。Growi v7から導入されたWebSocketは、違うブラウザー・セッションでも編集状況をリアルタイムに同期します。しかも、それはWikiページの編集画面を開きっぱなしにしていると、その分、大量のデータのやりとり（つまりデータの削除と作成）が発生。
この、リアルタイムの編集同期という便利な機能もまた、オブジェクトストレージとの相性が劇的に悪かったのです。
Nextcloudとの相性の悪さ
Nextcloudのサムネールも、「都度、動的に作成。表示が終わったら削除する」という特徴があります。
これはRedmineやPiwigoのように、アップロードした時点でサムネールを作成し、後は書き換えない点と真逆の姿勢です。
こちらは、上記に示したログの抜粋です。
2F24-11-30+10-33-12+3750.jpg.ocTransferId1304092901.part "DELETE /wasabi_bucket/hoge/fuga/files/Photos/24-11-30%2010-33-12%203750.jpg.ocTransferId1304092901.part" ここの.partとは、Nextcloudのモバイルアプリがサーバへとデータを送る際に、ファイルを分割して統合する処理を行っています。
A.jpgというファイルを
- A01.part
- A02.part
- A03.part
などと分割してNextcloudサーバに送信。サーバはそれらをA.jpgに統合。統合が済んだら当然これらのファイルは不要となるので「削除」が行われます。このとき、NWの不具合などで何度も送信をリトライするのであれば、当然、この削除作業は何度も行われます。
つまり、
- 主犯：Growi(MongoDB)の.wtファイルの超・超高頻度の書き換え
- 従犯：Nextcloudのサムネール作成の書き換えやバックグラウンド処理でのファイルアップロードによるファイルの結合処理
により、多いときでは683,606 GB-dayという途方もないデータ量が発生しました。これは、
- 1TB（1024GB)
- 667.58 TB-day
- 1PB (1024TB)
- 0.652 PB-day
という、「テラバイトどころかペタバイトでも十分換算できる」、言葉通りの意味で桁違いな数値となります。
経過観察と亡霊の「威力偵察」（2024年12月～2025年1月）
ここは、以下の表を見ていただきましょう。毎日、一定時間、Wasabiクラウドストレージのダッシュボードにアクセスして
- ダッシュボード上の削除されたストレージ量
- 請求額の変動
を記録していました。
| 日付 | 削除されたストレージ量 (TB, 請求書) | 削除されたストレージ量 (TB, ダッシュボード) | 比率 (%) | 予想請求額 (\$) | 前日比増分 (\$) | 増加率 (%) |
|---|---|---|---|---|---|---|
| 2024-12-11 | 22 | 21.62 | 98.27 | 36.91 | 5.44 | 17.3 |
| 2024-12-12 | 22 | 21.61 | 98.23 | 42.19 | 5.28 | 14.3 |
| 2024-12-13 | 22 | 21.61 | 98.23 | 47.46 | 5.27 | 12.5 |
| 2024-12-14 | 22 | 21.61 | 98.23 | 52.71 | 5.25 | 11.1 |
| 2024-12-15 | 22 | 21.61 | 98.23 | 58.00 | 5.29 | 10.0 |
| 中略 | ||||||
| 2024-12-25 | 22 | 21.51 | 97.77 | 110.47 | 5.25 | 5.0 |
| 2024-12-26 | 22 | 21.51 | 97.77 | 115.72 | 5.25 | 4.8 |
| 2024-12-27 | 21 | 21.50 | 102.38 | 120.96 | 5.24 | 4.5 |
| 2024-12-28 | 21 | 21.50 | 102.38 | 126.19 | 5.23 | 4.3 |
| 2024-12-29 | 21 | 21.50 | 102.38 | 131.43 | 5.24 | 4.2 |
| 2024-12-30 | 21 | 21.50 | 102.38 | 136.68 | 5.25 | 4.0 |
| 2024-12-31 | 21 | 21.50 | 102.38 | 141.91 | 5.23 | 3.8 |
| 2025-01-01 | 21 | 21.50 | 102.38 | 147.15 | 5.24 | 3.7 |
| 2025-01-02 | 21 | 21.49 | 102.33 | 152.39 | 5.24 | 3.6 |
| 2025-01-03 | 21 | 21.49 | 102.33 | 157.63 | 5.24 | 3.4 |
| 2025-01-04 | 21 | 21.49 | 102.33 | 162.88 | 5.25 | 3.3 |
- 確定した請求額（税込み）
- 179.07$
でした。
とはいえ、これは一種の救いでした。
- 確かに日々請求額は上がってはいるが、日々5.24$ほどで頭打ち。
- 高額ではあるが支払えない額ではない。
特に後者で「なんとか我慢できる」というデータを取れたのが非常に大きかったです。
また、削除されたストレージ量（請求書）に関しても、22→21と数字だけ見れば少ない額ですが「1TB(1024GB)」減ったというのは確実な進歩です。
つまり、実際の支払額を知ることで亡霊がどれほどのダメージを与えてくるのかというのを知ることができた1ヶ月でした。
経過観察と亡霊の「威力減少」 (2025年1月～2025年2月)
2025年1月もは日々5$の請求が続きましたが、転機が訪れます。
| 日付 | 削除されたストレージ量 (TB, 請求書) | 削除されたストレージ量 (TB, ダッシュボード) | 先日比 (TB) | 比率 (%) | 計測時の予想請求額 ($) | 前日比増分 ($) | 増加率 (%) |
|---|---|---|---|---|---|---|---|
| 2025/01/05 | 21 | 21.49 | - | 102.3 | 5.48 | - | - |
| 2025/01/06 | 21 | 21.49 | 0 | 102.3 | 10.71 | +5.23 | +95.45% |
| (中略） | |||||||
| 2025/01/29 | 21 | 20.89 | -0.57 | 99.5 | 131.03 | +5.09 | +4.04% |
| 2025/01/30 | 20 | 20.27 | -0.62 | 101.4 | 135.98 | +4.95 | +3.78% |
| 2025/01/31 | 20 | 19.59 | -0.68 | 101.4 | 140.78 | +4.80 | +3.53% |
| 2025/02/01 | 19 | 18.93 | -0.66 | 101.4 | 145.42 | +4.64 | +3.30% |
| 2025/02/02 | 18 | 18.11 | -0.82 | 101.4 | 149.88 | +4.46 | +3.07% |
| 2025/02/03 | 17 | 17.46 | -0.65 | 101.4 | 154.18 | +4.30 | +2.87% |
| 2025/02/04 | 17 | 16.79 | -0.67 | 101.4 | 158.32 | +4.14 | +2.62% |
特に顕著だったのは2025年1月29日のデータ。0.57TB。つまり「583.68GB」もの減少が見られます。この90日前は、将に、「Growiをインストールした日」でした。また、2025年2月2日の0.82TBは極めて大きな減少幅です。
この月の請求額は172.54$（税込み）だったものの、90日の猶予がなくなりつつある証拠であり、亡霊の暴威が去って行く瞬間でした。
去りゆく亡霊 (2025年2月～2025年3月)
そして、2025年2月～2025年3月は、特に大きな変化が見られました。
| 日付 | 削除されたストレージ量 (TB, 請求書) | 削除されたストレージ量 (TB, ダッシュボード) | 先日比 (TB) | 比率 (%) | 計測時の予想請求額 ($) | 前日比増分 ($) | 増加率 (%) |
|---|---|---|---|---|---|---|---|
| 2025/02/05 | 16 | 16.25 | -0.64 | 3.83% | 4.26 | N/A | N/A |
| 中略 | +1.23 | +8.53% | |||||
| 2025/02/10 | 13 | 13.11 | -0.72 | 3.04% | 22.18 | +6.52 | +41.64% |
| 2025/02/11 | 12 | 12.36 | -0.75 | 2.79% | 25.28 | +3.10 | +13.97% |
| 2025/02/12 | 12 | 11.63 | -0.73 | 2.63% | 28.24 | +2.96 | +11.71% |
| 中略 | |||||||
| 2025/02/21 | 7 | 7.02 | -0.65 | 1.10% | 49.54 | +3.64 | +7.93% |
| 2025/02/22 | 7 | 6.54 | -0.48 | 1.02% | 51.29 | +1.75 | +3.53% |
| 2025/02/23 | 7 | 6.07 | -0.47 | 0.93% | 51.52 | +0.23 | +0.45% |
| 2025/02/24 | 5 | 5.49 | -0.58 | 0.81% | 54.45 | +2.93 | +5.69% |
| 2025/02/25 | 5 | 5.00 | -0.49 | 0.74% | 55.85 | +1.40 | +2.57% |
| 2025/03/01 | 3 | 2.86 | -0.45 | 0.41% | 59.48 | +0.23 | +0.39% |
| 2025/03/02 | 2 | 2.39 | -0.47 | 0.34% | 60.93 | +1.45 | +2.44% |
| 中略 | |||||||
| 2025/03/04 | 2 | 1.28 | -0.58 | 0.18% | 61.84 | +0.68 | +1.11% |
- 2025年2月10日～2025年2月12日の90日前は自宅療養のためGrowiを特に頻繁に使っていた
- 2025年2月21日の90日前はGrowiやNextcloudのアップデートを集中的に行っていた
時期と一致しています。これは、「主原因がGrowiであった」ことを裏付けると同時に、逆説的に「Wasabiクラウドストレージの課金計算は全く間違いではなかった」を示すことでもあります。
この月の請求額は64.12$。この期間のダッシュボードの計測は「苦しみではなく楽しみ」だったことを覚えています。
消えた亡霊(2025年3月～)
| 日付 | 削除されたストレージ量 (GB, ダッシュボード推定値) | 削除されたストレージ量 予想値(GB, 請求書ベース) | 先日比 (GB) | 比率 (%) | 計測時の予想請求額 ($) \$ | 前日比増分 () | 増加率 (%) |
|---|---|---|---|---|---|---|---|
| 2025/03/05 | 801.52 | - | - | - | 0.65 | - | - |
| … (中略) … | … | … | … | … | … | … | … |
| 2025/04/02 | 0.00952 | 0.010 | 0 | 0.00% | 7.21 | +0.24 | +3.44% |
| 2025/04/03 | 0.00952 | 0.010 | 0 | 0.00% | 7.43 | +0.22 | +3.05% |
| 2025/04/04 | 0.00952 | 0.010 | 0 | 0.00% | 7.68 | +0.25 | +3.36% |
そして、決定的となったのは、2025年3月7日頃。つまり、Growiを停止した日から90日経過した時です。
削除されたストレージ量は初日こそGB単位だったのですが、日が経つにつれてMBに変化。そして日々の増加額は0.24$になりました。
この月の請求額は$7.98。つまり、Growi/Nextcloudをインストールする前の状況になったのです。
コメントを残す