先日から試している、長期間変更しないデータのGoogle Cloud Storage(以下、GCS)でのアーカイブ保存(バックアップ)。やってみないと分からないことは多いもので、予想していなかったことが いろいろあった。
バックアップ方法 (使用プログラム・設定)
当初はrcloneで始めたのだが、使っているうちに少し不満な点が出た。Sym-linkに対応していないことである。当初は それほど使っていないと思って、(例えばバックアップ時にsym-link一覧も保存し、)リストアする時にでも対処すればいいと思って居たのだが、実は結構使っていた。音楽についてはそうでもないが、写真(当初は予定していなかったが、古いものは対象にしたくなった)では多用していることに気付いた。
書いたあとで思い付いたが、バックアップ時に(一覧でなく)sym-linkだけを格納したtarを一緒に保存すればいいかも知れない。これなら、面倒な作業やスクリプトなどが要らず、コマンド一発で復元できる。ちょっと考えよう。 (17:39)
スクリプトを作れば いくらでも復活できるが、(それにしたって動作確認やデバッグは必要なので、)なるべく手間のないほうがいいと思うので、duplicacy(ファイルをチャンク(数MB程度のブロック)に分割して保存しているので、sym-linkも保存できる)を再検討した。
すると、duplicacyでは、sym-link対応の他にも、ファイルの移動や名前変更の時に再転送が不要になる場合があることが分かり※、なかなかいい感じになった。
※詳細な動作や条件は把握していないが、ファイルをブロックに分割して保存しており、同じブロックが書き込み済みなら再度書き込まない(重複排除, deduplication)ため。実際にバックアップ済みディレクトリを移動してから再度バックアップしたら、アップロードなしで済んだ。
なお、duplicacyで定期的に実行するprune(ファイルの更新・削除のために不要になったブロックを削除する)処理のコストは不明だが、ストレージ自体のコストは安いし、そもそも変更しない前提のファイルをバックアップしているので、pruneしなくてもいいかも知れない。
この辺りは昔のWORM光ディスクでの保存に似ている感じだ。
そして、昨日からduplicacyに切り替えて試していたら、新たに気になることが出た。上に書いたように、ファイルをブロックに分割するので、ブロックが小さいと書き込み・読み出し回数が増えたりストレージ内のファイル(オブジェクト)数が増えて、効率が悪くなったり料金が増えたりするのではないかということだ。試算してみると、当然ながら、ブロックが大きいほうが書き込みのコストは小さかった。
そこで、今朝、デフォルトのチャンクサイズが平均4MB(1..16MB)なのを、8MB(2..64MB)に変更して試して居る。
ただ、バックアップやリストア、それに伴うNW転送に関してはファイル数でなくデータ量に課金されるので、チャンクサイズはトータルのコストには余り効かないようだ。それでも、チャンクの管理(実際にあるかは不明: チャンク一覧やpruneの時か)のための操作数は減るので、その分のコストは下がるはずだ。あと、バックアップ速度は少し速くなった気がする。
運用コスト (料金・費用・手間)
料金をチェックしたら意外に高かった。昨日は72円で、4日目の今朝は85円になっていた。※
※絶対値としては とても安いが、まだデータ量が少ないのに予定している月額(< USD 1)を容易に超えそうな勢いなので、不安になった。
いろいろ試したせいもあるが、それでも なんか高いので調べてみたのだが、GCSは料金の内訳が出ないので、どの処理・操作が主因なか分からなかった。それで、1GBくらいをアップロード(バックアップ)した時の処理数や転送量と料金表で試算してみたが、上の料金には合わなかった。
気になったので、試しにリストア時の費用も試算した。想定している上限の約1TBをリストアする場合を計算したら、思わぬことが分かった。※ NW転送(外向き、"egress")とデータ取り出しのコストがかなり高いのだ。上に書いた、書き込み(リストアでは読み出し)操作よりずっと高い。
※上記のように自分で試算した額と請求額が合わないので、下の試算も合わない可能性があるが、データ取得と転送については合わない理由がないと思う。
以下に約1TBをリストアする場合の料金の試算結果を示す。 (USD → JPYは今は約111円のようだが、とりあえず120円とした。)
- データ要求操作(get= Class B(USD 0.50/10000 reqs)とする)
- duplicacyのチャンクサイズが平均10MBの場合
- 1024 * 1024 (MB) / 10 (MB) = 104858 チャンク → 104858 /10000 * 0.50= USD 5.2
- データ取得(アーカイブからの取り出し) (USD 0.05/GB): チャンクサイズには関係ない)
- 1024 (GB) * 0.05= USD 51.2
- データ転送 (Egress to Asia: USD 0.12/GB): チャンクサイズには関係ない)
- 1024 (GB) * 0.12= USD 123
- 合計: USD 179 → 約2.1万円
合計額もそうだが、データ転送コストの高さに驚いた(ボッタクリ??)。他社(Azure, S3)はこの数分の一(Azureは書いてなかったので無料なのかも知れないが、不明)なので、Googleは ここらでコストを回収しているのだろうか?
データ転送料金はArchiveだけでなく全クラスに共通なので、普通に使っている人は かなり高くついていそうだ。だから、実はGCSのユーザーは少ないのだろうか? そして、Googleの多くの過去のサービスのように消滅してしまう?? あるいは、電気代のように逆従量制(?)なので、大規模ユーザーが多いのか?
なお、ブロック分割しないrcloneでも同様に試算したが、データ要求操作のコストは安いものの他より1桁小さいので、合計はUSD 3程度しか安くならなかった。
それで、またAzureやS3に目が移りかけたのだが、当然ながら いいことばかりではない。次が主要な判断事項となった。
どちらがいいか?
- リストアすることは まずないので、リストア関連料金は高くてもいい? (平常時(保存だけ)の運用コストがBackblaze B2より安ければいい?)
- 候補: GCS
- 即座にリストアできる。
- duplicacyが使える。
- リストアに手間や時間(解凍時間)が掛かってもいいから、特にリストア時の料金が安いほうがいい?
- 候補: S3かAzure
- リストアできるようになるまで(「解凍」)、10時間以上掛かる。
- duplicacyは使えない。(バックアップ時にストレージに保存されたconfigが取得できないし、(あるかは不明だが)チャンクが読めないので) → configだけクラスを変えればいいかも知れない。
- rcloneでもファイルの属性が読めるか不明。: 実体でないから おそらくできる。
- AzureはデフォルトのクラスをArchiveにできないので(CoolかHot)、バックアップ後に変更しなくてはならず、使いにくい。S3は不明。
- S3やAzureでリストア時に解凍すると、クラスが上がって保存料金が高くなる(約10倍)可能性がある。
- 短期間なら問題ないが、リストア後にクラスを戻す手間が増える。
滅多に使わないのだから、まず起こらない場合の手間を惜しまずに運用費を安くすべきなのか、そうは言ってもたまに間違いを起こして(僕は これが結構あるｗ)使う可能性はあるから、手軽に・間違いなく使えるほうがいいのか。 (当然ながら、今の考えは後者である。) − 悩ましいところだが、GCSの試用期間・額はたっぷりあるので、試行錯誤しながら考えたい。
余談だが、GCSの試用額(この額・枠のことを"credit"というのだろうか?)約3万円が無期限で使えれば、僕が使う予定の十年分以上になるから即座に決めるが、そんな うまい話はないｗｗｗ
書いたあとで、掲示板のまとめのマイナンバーカードに関するスレッドを読んで、上の2つの選択肢はマイナンバーカードと運転免許証の関係に似ていると思った。マイナンバーカードは無料だけど、随分手間が掛かる(そもそも、さほど便利でない)。一方で運転免許証は、取る時も維持にも多少お金が掛かるけど、面倒さは少なく、手軽に幅広く便利に使える。
「どっちがいい?」と聞かれれば(聞く人すら居ないだろうが)、間違いなく後者に決まっている。
細かいこと
GCSを使っていて、(やっぱり)気になること・不満なことが出て来た。
- 料金の詳細(内訳)が分からないのが不便。Web(コンソール)では見られない。 → コンソールのBillingのReportsの右側のフィルタを設定すると項目ごとの料金を表示できる。が、円なので使用量は分からない。逆算するにしても、正確には分からない。 (10/5 7:41)
- B2では分かる。予測額も出る。
- 月の料金請求時(確定時)まで分からない?
- 料金(当日までの合計額)が出るのが遅い。: 10時頃更新?: 毎日の0:00 UTCから集計するとしたら、仕方ないか。
- データ量などが更新されるのが1日1回なのも不便。
- リアルタイムに出ず、更新は料金より遅い(午後3時頃?)。 (→ 図: 最下部の"Total bytes"と"Total ojects"が実際より小さい。: 前者は、少なくとも、右下の"Rec bytes"(≒ 書き込んだデータ量)程度はあるはずだし、実際に求めても そのとおり。)
- B2では月1回なので、仕方ない?
- Web(コンソール)の監視系、料金系が 今ひとつうまく動かなかったり、使いにくい場合がある(要するに、出来が悪い・詰めが甘い)。
- Googleらしい? ここら辺はAzureのほうが良さそうな気がする。
- B2はずっと良い(というか当たり前に使える)ので、すごい落差を感じる。
GCSのwebのモニタ画面 (苦労して見やすくした。)
希望・期待・・・
まあ、個人的に一番好ましいのは、Backblaze B2がアーカイブクラスのサービスを出してくれることだが、難しいのではないか。まず、今時テープとかありえないし(彼らも慣れてないし)クソ使いにくいので、HDDやSSDを使うとしたら、どうやって料金を下げるのだろうか。それが無理なので、今のように単一サービスで通しているのだろう。
が、何か引き換え(アーカイブは滅多にアクセス・変更しないことからの何か)があれば、実現できそうな気がする。とりあえずは、GoogleのようにNW転送料金を高くする??
通常時はストレージの電源を切っておいて、アクセス時だけonにすることも考えられる(それなら何時間も掛からない)が、信頼性が下がる可能性があるので(HDDは何年間も動かさないと固まってしまう)、余りメリットがなさそうだ。「それでもいい」という代わりに安くするのはありかも知れないが、本当に駄目になっていたらバックアップの意味がないし(それを避けるために、冗長化するとか たまに動かす?)、制御が面倒で(停めて浮いた電気代より)高く付く気もする。
なお、現実的な解はGCSかAzureだろう。MSは大10嫌いだが、GCS(RCP)のwebコンソールや料金(アカウンティング)関係のいい加減さには ものすごく呆れたし、みすみすぼったくられるのも嫌なので、コスト次第ではAzureも充分ある。あと、AWSはもっと試用できるようにして欲しい。まあ、そもそも彼らは僕みたいな「最大1TB」とか「月1ドル未満」なんていう超小物じゃなく、PBオーダーの人たちを相手にしているのだろうから、仕方ないとは思う。 (18:49)
↓
ちょっと試そうとAzureにサインインしようとしたら、何も規約違反をしていないのに、なぜかアカウントがロックされていたので、Azureの検討はしない。やっぱりMSは最低だ。わずかにでも期待したのが馬鹿だった。 (19:21)
結局、
上記のように、Azureは「やる気あるの?」レベル(調べたら、何もしてないのにアカウントがロックされるのは良く起こるようで、Officeなどが使えなくなって困る人が多いようだ)だしS3は「一見さんお断り」なので、(他に選択肢がなくて)GCSを使うことにした。その関係で、バックアッププログラムをrcloneにする理由がほとんどなくなったので、duplicacyを使うことにした。今日から少しずつ音楽などのファイルをバックアップして、様子(特に料金)をみていく。 (10/5 10:58)
おまけ: duplicacyでちょっと引っ掛かったこと。
GCSのアクセストークンのファイル(例: gcs-token.json)を、ストレージの初期化時(duplicacy init実行時)に指定した場所から移動したら、エラーでアクセスできなくなってしまった。
ヘルプやドキュメントには変更の仕方が載っていなくて、また初期化が必要かと がっかりしたが、設定ファイルやPC内にはそれが格納されている気配がなく、当然、クラウド側には保存されていない(トークンがないとアクセスできない)から、どうにかしているはずだと思ってソースを見たら、分かった。
- 初期化時に設定したパスは、LinuxではGnome keyringに格納されている。 (使っているとは思いもよらなかった。見付からないのも当然である。)
- seahorseコマンドで変更可能。: Default keyringの"gcs_token - duplicacy"
- また、設定ファイル(.duplicacy/profile)中の"keys"ブロックに"gcs_token"のキーでパスを書けば変更できる(duplicacy set -key X -value Yでも設定できるはずだが、試していない)。
"keys": {
"gcs_token": "/home/user/GCS/gcs-token.json"
}
- また、環境変数DUPLICACY_GCS_TOKEN, DUPLICACY_PASSWORDでも指定できるはず(試しては居ない)。
