タグ: MongoDB

『150日の亡霊』顛末記-Wasabiクラウドストレージの理解不足による重課金の罠-(長文)

概要

筆者は

  • AWS Lightsail → Web Arena Indigo
  • Wasabiクラウドストレージ

で、各種Webサービスを個人的に運用しています。これまで両者は安価で性能も満足いくものだったのですが
2024年11月~2025年3月に至るまで、Wasabiクラウドストレージの高額請求がありました。(解決は2025年4月)

今回、この失敗を記すことで自分と同じような状況に陥りそうな人への注意喚起並びに「こういう落とし穴もあるんだ」という参考にしていただければ幸いです。

時間がない人向けの要約

  1. Wasabiクラウドストレージの仕様を理解していなかったため通常の20倍以上の請求が届いた。
  2. 原因はクラウドストレージの超・超高頻度のファイル書き換え(削除&作成)が発生したため。
  3. この原因を作ったのはGrowi(MongoDB)とNextcloud
  4. これらサービスを停止したものの「最低保持期間ポリシー」の存在により、自動的に発生したファイル書き換えの分の課金が発生した。
  5. 完全解決に至るまでの合計請求額は5ヶ月で544.93$!(2025/04/16でのレート換算で77624.73円)
  6. 教訓
  • クラウドストレージの仕様(特に料金体系)は見ておくこと。
  • クラウドストレージはネットにあるSSDではない。
  • 相性のいい運用方法と相性最悪の運用方法がある。
  • 新しいWebサービスを稼働したらきちんと請求を見ること。
  • 「今まで大丈夫だったからと言って次も大丈夫」ではない。
  1. ビジネスでこれをやってたら請求額はこの数十倍も普通にあった。個人での失敗だからこそ「笑えない笑い話」で済んだ。

GrowiのDB格納先を変更。(mongod.conf編集)

GrowiのDB保存先を、冗長性を持たせたディスクに移設したときのメモです。

動作を確認した環境

  • Ubuntu 20.04
  • MongoDB v4.4.13
  • Growi 6.1.14

さっくりとした手順

  1. MongoDBサービスを停止します。
  2. DBの格納ディレクトリを作成します。
  3. MongoDBの設定ファイルを編集します。
  4. MongoDBサービスを再開します。
  5. 格納ディレクトリが変わったことを確認します。

MongoDBの停止

これは確実に行ってください。でないと、作業中にDBが書き換えられ不具合が発生する可能性があります。
(共有Wikiであればなおさらです)

sudo systemctl stop mongodb

systemctl status mongodb
# inactive(dead)を確認します

新規格納ディレクトリの作成

sudo mkdir /home/mongodb
# 任意の保存ディレクトリを作成します

sudo chown -R mongodb:mongodb /home/mongodb

ls -ld /home/mongodb
# ディレクトリの所有者がmongodbであることを確認します

既存データのコピー

  • ディレクトリ移動
cd /var/lib/mongodb && pwd

ll
# .wtで終わるファイルがあることを確認します
  • ファイルコピー
sudo cp -pir * /home/mongodb
# 先ほど作成したディレクトリにコピーします
  • ファイルコピー確認
cd /home/mongodb && pwd

ll
# コピーしたファイル一式があることを確認します

設定ファイル修正

  • 設定ファイルのバックアップ取得
sudo cp -pi /etc/mongod.conf /path/to/backup/mongod.conf.$(date +%Y%m%d)
# 任意のバックアップディレクトリを指定します。

diff -u /etc/mongod.conf /path/to/backup/mongod.conf.$(date +%Y%m%d)
# バックアップが保存されたか、差分がないことで確認します。
  • 設定ファイル編集

/etc/mongod.conf を教義・信仰に沿ったエディタで修正します。

  • 編集内容
  dbPath: /home/mongodb
  • 差分内容
-  dbPath: /var/lib/mongodb
+  dbPath: /home/mongodb

設定反映 (MongoDB再開)

sudo systemctl start mongod.service

systemctl status mongod.service
# active(running)を確認します

設定反映確認

  • ブラウザでの確認
  1. MongoDBを利用しているアプリ(Growi)にアクセスします。
  2. 正常にアクセスできて、Wikiの閲覧や編集、作成ができることを確認します。
  • サーバでの確認
cd /home/mongodb && pwd

ls -lart
# .wtファイルの更新時刻がブラウザで編集した時と同じであることを確認します。

cd /var/lib/mongodb && pwd

ls -lart
# .wtファイルの更新時刻が操作前と同じことを確認します。

事後作業(必要に応じて)

問題なく稼働することが確認されたら、元の保存ファイルを削除(退避)させます。

Growiの管理者パスワードリセット。

あらまし

検証の繰り返しで再作成する羽目になったgrowi。幸いDBデータは残っていたのでデータそのものは無事だったのですが、管理者パスワードを忘れてしまいました。

そこで、以下の通りにパスワードをリセットさせました。

前提

  • Growiのバージョンは2022年9月時点で最新の5.1.4。
  • 登録の制限:公開(だれでも登録可能)

手順

参考:
https://blog.akky.me/blog/change-growi-password-manually/

上記URLにあるように、環境変数'PASSWORD_SEED'を確認しようとしましたが、再作成の際に変数を失念。

なので、搦め手を用いました。

ユーザー登録を行います。(Growi Web画面)

Growiのトップ画面「新規登録はこちら」から

  • ユーザーID
  • 名前
  • メールアドレス (管理者と同じメールアドレスは登録できないので注意してください)
  • パスワード

を設定して新規登録します。このとき、パスワードは「リセットを行いたい管理者パスワード(上書きを行いたいパスワード)」にします。

ログインできることを確認したので、ここからはターミナルでの操作になります。

mongodbに接続します。(Growiがインストールされたサーバ)

管理者権限で実施しました。

mongo growi

上記で新規登録をしたユーザのデータを確認します。(Growiがインストールされたサーバ)

db.users.find({email: "上記登録をしたメールアドレス"});

パスワードのハッシュ値を確認します。(Growiがインストールされたサーバ)

出力されたデータの以下の値を確認します。アカウント情報がずらっと出てくる中で、

"password" : "ハッシュ化されたパスワード値",

これを控えておきます。

管理者パスワードを上書きます。(Growiがインストールされたサーバ)

db.users.update({email: "管理者のメールアドレス"}, {$set: {password: "先程控えておいたパスワードのハッシュ値"}}); 
# WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 }) と表示されればOKです

上書きしたパスワードでログインします。(Growi Web画面)

この手順でなんとか管理者でログインできました。

後処理を行います。(Growi Web画面)

管理>ユーザー管理 へと進み、一時的に作成したユーザを停止したり管理者に昇格させたりしてください。

Powered by WordPress & Theme by Anders Norén