piu lentoの日々 (piu lento days)

先日から試している、長期間変更しないデータの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はずっと良い(というか当たり前に使える)ので、すごい落差を感じる。

 

 

希望・期待・・・

まあ、個人的に一番好ましいのは、Backblaze B2がアーカイブクラスのサービスを出してくれることだが、難しいのではないか。まず、今時テープとかありえないし(彼らも慣れてないし)クソ使いにくいので、HDDやSSDを使うとしたら、どうやって料金を下げるのだろうか。それが無理なので、今のように単一サービスで通しているのだろう。

が、何か引き換え(アーカイブは滅多にアクセス・変更しないことからの何か)があれば、実現できそうな気がする。とりあえずは、GoogleのようにNW転送料金を高くする??

通常時はストレージの電源を切っておいて、アクセス時だけonにすることも考えられる(それなら何時間も掛からない)が、信頼性が下がる可能性があるので(HDDは何年間も動かさないと固まってしまう)、余りメリットがなさそうだ。「それでもいい」という代わりに安くするのはありかも知れないが、本当に駄目になっていたらバックアップの意味がないし(それを避けるために、冗長化するとか たまに動かす?)、制御が面倒で(停めて浮いた電気代より)高く付く気もする。

 

なお、現実的な解はGCSかAzureだろう。MSは大¹⁰嫌いだが、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でも指定できるはず(試しては居ない)。

以前から、手持ちの音楽のファイル全部を(ローカルなHDD以外に)クラウドストレージにもバックアップしたいと思って居たが※、データ量が大きくて(800GB近い)料金がかさむので、貴重なものだけ(約130GB)に絞っていた。

※実は、そもそも その必要性には疑問がある。CDなどを買えば再び手に入るものをバックアップすることに意味があるかだ。ただ、仮に全部消失した場合、再び買って揃えるにはお金も手間も掛かるし、CDだったらPCに復旧(リッピング)させるには相当な手間が要り、その気力は起こらないだろうから、それが不要になる点では意味がある。

ただ、全部消失するような事態になったら、バックアップがあったとしても復旧させる気が起こるかは疑問だ。だから、ストレージの料金をなるべく安くし、無駄だったとしても「保険」として割り切れるようにしたい。

あるいは、「いかにも」だが、仮にバックアップする意味は全くなかったとしても、こういう技術の知識・経験が得られる価値はある。

それから、音楽以外にビデオのファイルもバックアップできればいいが、さすがにデータ量が桁違いに大きい(約3TB)から料金がかさむだろうし、随分前から そういうビデオを観る(観た)ことがないので、「消失したら諦める」で良いと考えている。

その後、変更やダウンロードが高く付くなど使い方に制限はあるものの料金の安い、archive(またはnear line) storageというカテゴリ(貯金で言えば、利率は高いものの、ATM手数料が高く、最短解約期間制限のある定期のようなもの。国債のほうが近いかも)があることを知り、それを試してみようと思って居た。面倒だったのと別件がいろいろあったので延期していたが、昨日から試し始めた。

まず、料金の安い いくつかのサービスの料金を比較した。

• Microsoft Azure Blob Storage (以下、Azure(クラスはArchive)。他も同)
  • Archiveの料金: USD 0.00099/GB/月〜 (サーバの場所によって異なる。Googleも同じ)
    • 例: 500GBの場合、約USD 約0.50/月, 800GBの場合、約USD 約0.79/月 (アクセス関連の料金は含まない。以下同)
  • データ取得時間: 最大15時間
• Google Cloud Storage (以下、GCS)
  • Archiveの料金: USD 0.0012/GB/月〜
    • 例: 500GBの場合、USD 0.60/月, 800GBの場合、約USD 0.96/月
  • データ取得時間: 1秒未満 ("sub-second")
• Amazon S3 (以下、S3)
  • Glacier Deep Archiveの料金: USD 0.00099/GB/月〜
    • 例: 500GBの場合、約USD 約0.50/月, 800GBの場合、約USD 約0.79/月
  • データ取得時間: 12時間以内
• [比較] Backblaze B2 Cloud Storage (archiveではない。以下、B2)
  • 料金: USD 0.005/GB/月
    • 例: 500GBの場合、USD 2.5/月, 800GBの場合、USD 4.0/月

※データ取得時間は下の「補足・訂正」の記載時に追加した。

それらのうち、バックアップに使う予定のソフト(rclone)が対応していて最安と思われる、AzureとGCSを試すことにした。

なお、S3の料金は、以前調べた時(高い地域を見たようだ)はUSD 0.002/GB/月だったので却下したのだが、今調べると(例えばオレゴンは)Azure並みなので、追って再検討したい。

同じく、以前は気付かなかったS3のIntelligent-Tiering(アクセス頻度で自動でストレージのクラス(→ コスト)を変える)が なかなか良さそうで、理想的に働けば(そうは問屋が許さなそうだが)、B2から全部移行しても料金を節約できるかも知れない。

一方、すぐに分かったS3の欠点は、AzureやGCSのような無料試用額・期間(例: GCSは約3万円, 90日)がないことだ。これは結構大きく、料金システムが複雑で簡単には見積もれないことと相まって、気軽には試せない。やっぱりAmazonはセコいのかね。

→ 下の「補足・訂正」に書いたように、S3はAzure同様データ取得時間が長いのと、他と異なって無料で気軽に試用できないため、見送ることにした。 (17:53)

上記のように、現在使っているB2に比べて料金が1/5前後と かなり安いから、うまく使えれば行けそうだ。また、Azure(S3も)はGCSより2割近く安く、(さまざまな疑念はあるがｗ)もし良ければ使うのも悪くはない。それに、Googleだって好きじゃないｗ

結論を先に書くと、Azureは全く論外だった。一番のポイントはストレージ内でファイル・ディレクトリの移動ができないことだ。(補足・訂正あり。下記参照) 例えば、ストレージに保存(バックアップ)する時に場所を間違えてしまったら直せないのだ。それから、保存後に気が変わっても移動できない。もちろん、コピーするか再度保存(アップロード)すればいいが、時間もお金も掛かる。

SMBならできるという情報もあったが、インターネットで使うものなのか?? TCP版があるのだろうか?

馬鹿馬鹿しい・面倒以前に、こういうファイルシステムの基本機能がなかったら使いものにならない。「安けりゃ いいってもんじゃない」の典型ではなかろうか。良く使う人が居るものだ。Azureに決める人(お偉いさんや客?)は そういうこと分からず、現場が苦しんでいるのかも知れない。もちろん、ストレージ以外に すごくいいことがあるのかも知れないが、どうだろうね・・・

一方、GCSはもちろんファイル・ディレクトリの移動ができる。当たり前のことだ。書くまでもないけど一応書いた。 (← 実は違っていた。下記参照)

ところが、書いたあとで別件(できればsym-linkもバックアップしたい)を思い出し、それに対応するためには別のバックアッププログラム duplicacyを使うことになり、それならファイルの移動は関係ないので、安いAzureが いいかも知れないので、まとまり次第、更新・追加する。 (11:29)

補足・訂正

その後、GCSもファイル・ディレクトリの移動はできないことが分かった。ディレクトリの移動はできず、ファイルの移動はサーバ内でのコピーと削除で実現されるので、Azureと同様だ。ただ、GCSは、Archiveでも高速にファイルにアクセス(取得)できるという大きなメリットがあることが分かった。Azureでは解凍(rehydrate)にものすごく時間が掛かる(30分どころではなく、「最大15時間」である)。S3は「12 時間以内」だ。まさに、待ってたら日が暮れる。

目的は保険的なバックアップなので、必ずしも高速に取得できる必要はないが、いつ使えるようになるのか分からないのでは不便だ。なので、GCSは少し高いけどその価値がありそうだ。

それにしても、GCSの高速性はどのように実現しているのだろうか。単に全部同じストレージ(HDD?)を使い、料金や最小保持期間でコストを回収しているのだろうか?

 

→ 結局、Azureは やっぱり使えないことが分かり、GCSが良さそうだという結論は変わらない。 (16:42)

また、rcloneとduplicacyの使い勝手や予想コストなどを比較し、sym-linkなどは当初は諦めてrcloneを使い、必要な時に対処することにした。 (17:48)

 

以下に、それぞれを試してのメモ・感想・気付いたことを示す。

Azure

• 初期設定で いろいろ難しい単語・概念が出て来て複雑。
  • ストレージなのに仮想ネットとか言われてもねえ・・・
• コンソール(web)が使いにくい・分かりにくい。
  • 日本語訳で更に悪くなっている。 → 少ししてから英語に切り替えて、ちょっとマシになった。
  • 機能が少な過ぎる。
    • ファイルの移動やコピーすらできない。
  • → StorageExplorer(Linux版)を試そうとするが、.NETのライブラリが要るようで、動かなかった。
    • 調べたら、それでもファイル・ディレクトリの移動はできないようだ。
  • ただし、Metrics(使用状況のグラフ表示)はGCSよりずっと使いやすい。
• ファイルシステムの基本機能が不足している。
  • ファイル・ディレクトリの移動ができない。 ← 実装としてはGCSも同様だった。
  • ルートのファイル名に小文字しか使えない。 ← どうやら、これはGCSでの「バケット名」だったようで、GCSも同じだった。
• 地域は、料金の安い westus2 (US西部)にした。
• アップロード速度は悪くない。: 30Mbps以上出ていた。
• ファイルの取得にものすごく時間が掛かる(仕様では最大15時間)。
• 料金の更新は即時ではない。翌日? (当然か)
  • GCSも同じ。
• 全般的に料金は安いが、Read操作が異常に高い(USD 5/10000ops)のが気になる。
  • これが いつどのくらい効くのか、今ひとつ分からない。

GCS

• 初期設定は概ね分かりやすかった。
  • ただ、分からないので無設定(デフォルト)にした項目も結構あった。
• コンソール(web)はAzureよりずっと使いやすい。
  • Azureよりずっと分かりやすく、使いやすかった。
    • ただし、他のGoocle Cloudのサービスで懲りているので、英語版で使った。
  • 機能は概ね充分だが、以下が不便だった。
    • (バケットなどの)ストレージのデータ使用量が分からないのは不便。。。
      • → rclone sizeで分かる。
    • プロジェクトの名前が変えられない? → 随分探してできた。
  • わずかに面倒なところがある。
    • 例: Monitoringのストレージの地域が最初は必ずデフォルトになり、設定してもリロードするとリセットされてしまう。
• ファイルシステムの機能は普通・常識的で問題ない。
  • ディレクトリの移動はできない。
  • ファイルの移動は内部的にはコピーと削除になる。
• 地域は、料金の安い us-west1 (オレゴン)にした。
  • 土地勘がないため、オレゴンは遅そうなイメージだったが、下記のように速度は問題なかった。
• 全般的に料金は安いが、最小保存期間が365日と かなり長いのが気になる。
  • 大量のデータを短期間で消すと高く付きそうだ。
  • Azureは180日。
• アップロード速度は悪くない。: 30Mbps以上出ていた。Azureより少し速かった。
• ファイルの取得は高速。普通のストレージと同じ感覚で使える。
• その他
  • 無料試用分(USD 300)を得るため、現在のGoogleのアカウントとは完全に別に作った。
    • 混同・誤用・クッキーなどのmixを避けるため、ブラウザも別にした。
    • アカウント登録時に電話番号が要る(SMSでの認証がある)ので困ったが、そろそろ解約かと思っていた楽天モバイルが使えた。
  • アクセスのための認証情報(パスワード)がなく、rcloneの設定でをどうするのか分からなかったが、最後にブラウザで認証・許可できることが分かった。
    • 先進的でちょっと感動したがｗ、rcloneのマニュアルに書いておいて欲しかった。
  • rcloneでのファイル・ディレクトリの移動に癖があるが、大きな問題はない。
    • サブコマンドmoveとmotvetoの違いなのだろう。

というわけで、無料試用分・期間(90日)一杯はGCSを試してみて、料金や使い勝手が問題なければ本格的に使うつもりだ。

 

PS. 予想もしていなかったのだが、「面倒で使えない奴」と烙印を押した楽天モバイルのSIMが、上記のようにGCSの認証に役に立った。今後も何かに使えそうなので、このまま残すのも悪くない気がしている。

PS2. 完全に個人的な意見なのだが、下に出ているページのアイコンを見るだけで、AzureとGCSは どちらも同じような色遣いなのに、いかにMicorsoftにセンス・美意識がないかを強く感じる。なんで四角、しかも正方形なんだろうかと思う。「1000%ない」と思う。

それだけじゃ見た目だけになるから追加すると、ページの説明にしたって、Azureは"Blob storage"(しかも、そのあとに「テキストデータ」と出て来る・・・)だが、GCSは"Object storage"と、明らかにGCSが正確で分かりやすい。

こういうところから、「MSはクソ過ぎて大っ嫌い、Googleは好きじゃない」という感想になるｗ

 

(19:27 修正・補足)