以前の記事でも触れましたが、筆者はWasabiの「Timed Deleted Storage（90日最低保存期間）」によって、一度約8万円という高額請求を経験しました。
もちろん、Wasabiそのものが悪いサービスというわけではありません。
バックアップ用途のように、一度保存したデータを長期間保持する使い方であれば非常に優秀です。問題だったのは、私が動かしていたアプリケーションとの組み合わせでした。
当時の環境では、MongoDBを利用するサービスが大量の一時ファイルや更新データを短時間で生成・削除しており、その挙動がWasabiの90日最低保存期間と最悪の相性になってしまいました。
さらにNextcloudでも、サムネイル生成やプレビュー画像、一時ファイルなどが絶えず作られては削除されます。
アプリケーションとしてはごく正常な動作です。しかし、Wasabiでは「90日以内に削除されたオブジェクト」であっても、残りの保存期間分がTimed Deleted Storageとして課金対象になります。
結果として、利用容量以上に「削除したデータ」が積み上がり、気付いた頃には非常に大きな請求になっていました。
この経験以降、筆者は運用を大きく見直しました。
NextcloudのデータはローカルSSDへ退避し、一時ファイルの保持期間も短縮。キャッシュやサムネイルの扱いも見直したことで、Timed Deleted Storageは12MB程度まで抑え込めています。
現在では当時のようなペナルティはほぼ発生しておらず、運用自体は十分安定しています。それでも、根本的な問題は残っていました。
実際に保存しているデータは20GB程度しかありません。（というか、Nextcloudを限定的な使い方しかしていないため増やせないという）
さらに、今後導入を考えているPiwigoのようなフォトギャラリーでは、サムネイル生成や画像整理が日常的に行われます。
「この操作をするとTimed Deleted Storageが増えるかもしれない。」
そんなことを気にしながらアプリケーションを導入したり、設定を考えたりするのは、本来あるべき運用ではありません。
サービスに合わせてアプリケーションを制限するのではなく、アプリケーションが本来の動きをしても問題にならないストレージを選びたい。
そう考え、オブジェクトストレージそのものを見直すことにしました。
Backblaze B2を候補に選んだ理由
移行先として最初に候補へ挙がったのは、Cloudflare R2とBackblaze B2でした。
どちらも個人利用では人気の高いサービスですが、筆者が重視したのは「料金」そのものではなく、「運用中に余計なことを考えなくて済むか」という点です。
Wasabiで最も苦労したのは、保存容量ではありません。「削除する」という、ごく普通の操作にコストが発生することでした。Backblaze B2では、料金はByte-Hoursという時間単位で計算されます。
サムネイルや一時ファイルを数分だけ作成して削除した場合、その数分間しか課金されません。アプリケーションが普通に動けば、料金も普通に計算される。
もちろん、小容量利用でのコスト面も魅力です。
最低利用容量はなく、10GBまでは無料。筆者のように20GB程度しか保存していない環境であれば、月額は数十円程度に収まります。
また、以前は「日本から利用するには代理店経由なのでは」と思い込んでいましたが、実際には本家サイトからそのまま個人契約でき、クレジットカードやPayPalにも対応していました。
Backblaze B2のアカウントを作成する
移行先をBackblaze B2に決めたら、まずはアカウントを作成します。
公式サイトから 「B2 Cloud Storage」 を選択し、メールアドレスとパスワードを登録するだけで利用を開始できます。個人利用でも特別な手続きは必要なく、クレジットカードやPayPalでそのまま契約できます。
途中で保存先リージョンを選択しますが、 US West を選択しました。物理的に日本へ比較的近く、レイテンシも十分実用的です。
認証メールで本人確認を済ませると、管理画面へログインできます。
Bucketを作成する
続いて、データを保存するためのBucketを作成します。
左メニューから B2 Cloud Storage → Buckets を開き、「Create a Bucket」を選択します。
設定は次のようにしました。
- Bucket Name：任意（グローバルで一意）
- Visibility：Private
- Default Encryption：今回は無効
- Object Lock：無効
Object Lockはランサムウェア対策や改ざん防止には非常に有効な機能ですが、通常のファイルサーバー用途では「削除できない」という制約が先に立ってしまいます。
バックアップ専用のバケットであれば検討する価値がありますが、今回は日常的に更新されるストレージなので無効のままとしました。
最初に変更しておきたい設定
Bucketを作成したら、最初に確認しておきたい項目があります。
それが Lifecycle Settings です。
初期設定では Keep all versions となっており、同じファイルを上書きすると以前のバージョンが残り続けます。Backblaze B2はデフォルトでファイルの世代管理を行うため、このままでは古いバージョンも保存容量に含まれます。
筆者の用途では世代管理は不要だったため、
Keep only the last version of the file
へ変更しました。これで最新版のみを保持する運用になります。もちろん、バックアップ用途で利用するのであれば「Keep all versions」の方が適しています。
ここは「どちらが正しい」という話ではなく、用途に合わせて選択する部分です。
アプリケーションキーを発行する
続いて、Linuxから接続するためのAPIキーを作成します。
管理画面の Application Keys から Add a New Application Key を選択します。
今回は次のように設定しました。
- Key Name：任意
- Bucket：作成したBucketのみ
- Access：Read and Write
- Allow List All Bucket Names：有効
最後の Allow List All Bucket Names は忘れやすい項目です。
rcloneなどがBucket一覧を取得する際に利用するため、有効にしておく方が扱いやすくなります。
キーを作成すると
が表示されます。
このうち applicationKeyはこの画面でしか表示されません。 あとから確認できないため、安全な場所へ保管しておきます。
Ubuntu 24.04へrcloneを導入する
Backblaze B2への接続には、今回は rclone を採用しました。
以前はs3fsを利用していましたが、VFSキャッシュや同期機能などを考えると、現在ではrcloneの方が扱いやすい場面が多くなっています。
Ubuntu 24.04であればAPTからそのまま導入できます。筆者は好みでaptitudeを用いています。
sudo aptitude update
sudo aptitude install -y rclone fuse3
導入後以下で確認します。
rclone version
rcloneを設定する
設定は一般ユーザーで行います。
rclone config
を実行し、新しいRemoteを作成します。主な設定は以下の通りです。
- New remote
- 名前：任意
- Storage：Backblaze B2
- Account：keyID
- Key：applicationKey
途中で
Permanently delete files on remote removal, otherwise hide files.
という質問が表示されます。筆者はここだけ true を選択しました。Backblaze B2は削除しても「Hidden Version」として残すことができますが、今回の目的は「不要なデータを残さない運用」です。
そのため、削除時は完全削除となるよう hard_delete=true を設定しています。
なお、ファイルを上書きした場合の旧バージョン保持はLifecycle設定の対象になるため、先ほどBucket側で「Keep only the last version」に変更した意味もここで生きてきます。
接続を確認する
設定が終わったら、最後に接続できることを確認します。
rclone lsd 設定した名前:
設定が正しければ、作成したBucket一覧が表示されます。
続いて簡単なファイルをアップロードしてみます。
echo "Hello, Backblaze B2 from Linux!" > test-b2.txt
rclone copyto -P test-b2.txt \
名前:バケット名/test-b2.txt
アップロード後は、
rclone ls 名前:バケット名
で存在を確認できます。さらに削除も試してみます。
rclone delete \
名前:バケット名/test-b2.txt
今回は、削除後もTimed Deleted Storageのような最低保存期間を気にする必要はありません。短時間だけ存在したファイルは、その存在していた時間だけが課金対象となります。
これで、ようやく「削除すると料金が増えるかもしれない」という制約から解放されました。
もちろん、料金が安くなったことも嬉しいのですが、それ以上に「アプリケーションが本来の動作をしても気にしなくて良い」という安心感の方が、筆者にとっては大きな収穫だったように思います。
