piu lentoの日々 (piu lento days)

いつものように四苦八苦しつつも(そのため、気付いたら前回から10日も過ぎて居た)、昨日、Google Cloud Storage (Archive) (以下、GCS)への初期バックアップが終わった。約一週間掛かりだった。途中で欲が出て、予定していた音楽のファイル以外に古い写真や本など いろいろ追加したため、データ量は予定の2倍の約900GBになった。

というのは、あとにも書くが、滅多にアクセス・変更しないのであれば、現在使っているBackblaze B2(以下、B2)より維持費(アイドル時の料金)がずっと安く済むので、その分、多くのデータを保存できるからだ。

以下に、これまでに分かったことや印象・感想などを書く。

• 信頼性(GCS + duplicacy): なぜか変な問題が起こったが、(おそらくの)原因が分かって再発しなくなった。
  • 現象: チャンク(ファイルを分割したファイル)が1個なくなった。 (→ その後、問題発生時には同時アップロードスレッド数分なくなることが分かった。)
    • バックアップ時にduplicacyやGCSからエラーは出ていなかった。
    • そのチャンクは確かにGCSになかった。
  • いろいろ調べて何とか復旧した。 (→ 参照)
    • 簡単だけど面倒だ。
  • ただ、今まで(ストレージがB2の場合)は起こっていなかったので、どうしてか気になった。相性問題?
    • チャンク約6万個のうちの1個で 低い確率ではあったが、「滅多に起こらない」とは言えない。
    • 現象は異なるが、サーバからB2にバックアップしたもののprune時に たまに「チャンクがない」エラーが起こっていたので、duplicacyに問題があるのかも知れない。
      • この問題は、B2のメンテ中にアップロード(バックアップ)したせいで起こっている(やっぱり、サーバからのエラーがduplicacyに伝わってない?)と想像し、定期メンテ中のアップロードを避けるようにして様子を見ている。
    • → いろいろ調べたら、データをアップロードしているPCの一時IPv6アドレス(temporary IPv6 address)の更新の影響のようだった。
      • 直接の原因は自分で変えた設定が不適切だったことだが、他のプログラムは今まで問題なく動いていたので、そればかりとは言えない。 → 詳細は下記 「一時IPv6アドレスの更新の影響について」を参照のこと。
  • → 一回だけでなく再発したので、チャンクサイズをデフォルトにして試したが、効果はなかった(やはり再発した)。
    • アップロード速度が低下したが、バックアップのスレッド数を6に増やしたら、家のVDSLのアップロードの最高速度近くの32Mbps前後まで出るようになった。
  • duplicacyは、このような問題をcheckコマンドで検出できるのがいい。
    • rclone(ファイル単位でバックアップする)だったら おそらく通信エラーになると思うが、(duplicacyと同様に)エラーにならずにファイルの全部または一部がなくなったり、異常になったりする可能性もある。それは(何もしなかったら)バックアップ直後には検出できなので、リストア時に途方に暮れることになる。
      • バックアップ後にチェックするにしても、rcloneは管理情報は持っていないので、自分で、バックアップしたファイルがストレージにあるか調べる必要があり、なかなか面倒だ。まあ、rcloneをdry-runモード(あれば)で動かせば、ファイルの有無とサイズの違いは分かるだろうが、おそらくduplicacyより高く付きそうだ。あと、中身の異常までは分からない(それはduplicacyも同じ)。
  • 上の問題の他は、バックアップしたファイルの抜けや一部をリストアして中身をチェックをしたらOKだったので、(当然のことながら)信頼できそうだ。
    • こんなところで駄目だったら、世界中のユーザーが叩くに違いない。そもそも、そんなのはGoogleでない。
• 有用性: やっぱり(僕には)バックアップは必要不可欠だった。
  • バックアップのチェック中に誤って本物のファイルに上書きしてしまい、いくつかサイズを0にしたり変な名前のファイルを作ってしまった。
    • 原因: awkの使い方の失敗: 一時ファイル名がおかしくて上書きしたようだ。
      • 変な名前は空白のあるファイル名が分割されてしまった。
  • → でも、早速GCSからリストアして復旧できたので「セーフ」だった＾＾
    • 手元のバックアップHDDからでも良かったが、試しにやってみた。
• 料金: GCSとB2を併用した場合、通常(アイドル)時は現状(B2のみ)から4割(100円/月)近く安くなるはず。
  • 連日、コンソールを頻繁にチェックして、更新・集計のタイミングや内訳が分かり、ある程度、料金表に合う額が計算できるようになった。
    • 料金(Report)は1日2回以上更新される。
      • 項目によって更新時期・頻度が異なるようだ。
      • 内訳は金額(円)でしか出ない(データ量などは出ない)ので不便。
    • 操作の回数、送受信データ量などは、モニター(Monitoring)で ほぼリアルタイムに更新される。
      • ただし、全データ量とオブジェクト数が更新されるのは1日1回。
  • 事前の見積もりどおり、1TBのリストアをすると約2.1万円になるだろう。
    • 安くはないが、保険だし、データに値段はないので仕方ないだろう。
    • それに、維持のための料金を払える限り、一度に全部リストアする必要はないので、そうすれは安くなる。
  • 現状(初期バックアップ完了後, 10/14 10時頃)の使用量と料金
    • 使用日数: 約13日間 (約半分は試行錯誤)
    • 格納データ量: 約900GB
    • 削除したデータ量: 約700GB (試行錯誤のため)
    • 操作数: 約28万
      • Class A (主にWriteObject): 約26万
      • Class B (主にGetObjectMetadata, ListObjects): 約2.4万
    • GCSの送信データ量(≒ ダウンロード(リストア)データ量): 約13.5GB
    • GCSの受信データ量(≒ アップロード(バックアップ)データ量): 約1.6TB
    • 料金: 3055円: 以下に内訳
      • Class A操作(書き込み系): 1525円
      • Class B操作(読み出し系): 90円
      • データ取得: 90円
      • データ格納(us-west1): 31円
      • データの早期削除: 1161円
      • データのNW転送(ダウンロード): 158円
      • ※書き込み系操作と早期削除(どちらも試行錯誤を含む)が大半で、通常(アイドル)時はデータ格納以外は掛からない。
    • ※データ量の単位にはGiB, TiB(1024系)とGB, TB(SI系)の2系統があるが、いろいろな箇所・場合・プログラムで異なっていて換算や記載が煩雑なので、ここでは特に区別せず、大まかに"GB"などと書き、特に必要な場合だけ厳密に扱う。
  • 今後の予測・見積もり (USD 1= 112円とした)
    • GCSのアイドル時の予測額(月額): USD 約1.1 (約121円)
      • 格納データ量: 約900GB
    • B2: GCSへのデータの一部移行後の予測額(月額): USD 約0.24 (約27円)
      • 移行後のB2の格納データ量: 約48GB
        • 約412GBをGCSに移行すると見積った。
      • 従来
        • 月額: USD 約2.2 (約246円)
        • 格納データ量: 約460GB
    • 合計の予測額(月額): USD 約1.3 (約150円)
      • 現状の約246円(B2のみ)との差: 約-96円
• duplicacyの処理・設定: 結構手間が掛かったが、いろいろ分かったことがある。
  • チャンクサイズ
    • 大きくしてみたが、重複排除効率が下がるとのことなので、大きく(平均10MB)しないほうが良かったかも知れない。
      • 効率は大差ないとは思うし、料金も大差なさそうだ。
        • データ取り出しとNW送信が高いので。
      • バックアップしてからのサイズ変更はできない。
    • → その後、上記のチャンク消失問題の原因かも知れないと思って、デフォルト(平均4MB)に戻した(実際には無関係だった)。
    • 平均チャンクサイズと実際のファイルサイズの関係
      • 全データ量: 994,100MB, ファイル数: 332176, チャンク数: 202070
        • 平均ファイルサイズ: 3.0MB
        • 平均チャンクサイズ: 4.9MB
      • → チャンク化によって、ストレージの使用効率が約1.6倍になったと思われる。ただ、ブロック数でなく実サイズで課金されるので、料金には関係しない。
    • 重複排除の効果(実際のデータ量とストレージに保存されたデータ量の関係)
      • バックアップしたデータ量: 993,910MiB, ストレージに保存されたデータ量(チャンクの総データ量): 917,429MiB
        • 差: 約75GiB, 重複排除率: 約7.7%
      • バックアップの経過(duplicacyの出力)を眺めていたら、重複排除が効いている場合もあった(例: アップロードサイズが約1割減)が、全体としては余り効いていないようだ。
    • ※ここでのデータ量はduplicacyの出す値(表示は"MB"だがMiB系のようだ)で、単位系または処理が異なるせいか、他とは一致しない。
  • フィルタ(バックアップ・除外パターン)の設定
    • 強力だが、理解不能な癖みたいなものがあって設定が面倒。
      • 予行(dry-run)機能で試せるので、何度も試しては修正した。
    • ただ、もう少し機能があるといい。
      • 例: 更新日時でバックアップ対象にするかどうか。
  • prune処理について
    • pruneを行って不要になったチャンクを削除すると使用データ量が減って料金が下がるが、GCSの使用データ量の料金は安い反面、早期削除やアクセスの料金が高い(数十倍!)ので割に合わない。使用データ量がそれほど大きくないなら、なるべくpruneしないほうが得策だと思う。
  • 日頃のバックアップの必要性のチェック方法
    • duplicacyのバックアップの予行(dry-run)機能でバックアップ(アップロード)されるファイルが表示されてファイル更新の有無が分かるので、それを定期的(1日に1回)に自動実行し、結果を見て必要だと思ったら手でバックアップすることにした。
      • このチェックにもアクセス料金が掛かるが、今まで見たところでは それほど高くないので、頻繁過ぎなければ大丈夫そうだ。
    • ちなみに、B2へのバックアップは、基本的に上と同様に(dry-runでない)バックアップを定期的(約8時間間隔)に自動実行している。
      • ただ、PCのスリープや再起動に影響されずにバックアップの間隔をなるべく一定にしたいのと、バックアップ後にチェックをするのと、バックアップ以外にprune(2種類)を別な長い間隔(約1日, 約2週間)で行うのと、バックアップが長引いた場合に同時にpruneを実行しない(その逆も)ようにしているので、実際にはちょっと複雑な自作のスクリプトを使っている。
• その他
  • 光回線でないと(無線では)、こういうバックアップはできなかった(ちょっと する気になれない)。
    • 初期(試行も)バックアップ中のデータ量の変化(グラフの下向きがアップロード)は、以下のように、今までにない すごい傾きだ。普通の4G無線で、一週間くらい こういう通信を安定してできるだろうか?

    • 

      GCSに初期バックアップ中の送受信データ量: 上: 受信, 下: 送信; 左上から右下へ: 日, 週, 月, 年

  • ただ、家はVDSLのためアップロード速度が遅い(最大約35Mbps)のが残念だ。
    • もしアップロードも速かったら、初期バックアップは2-3日で終わっただろう(ただ、僕の準備・処理が間に合わなかったかも)。
  • GCS(Archive)は、アクセス・書き換え・削除などせず、ただファイルを追加していくだけなら安いうえに、他のクラウド アーカイブ ストレージと違って「普通に」使える(ただし高い)から結構いいと思う。
    • 以前書いたように、WORMメディアやテープのイメージで、基本的に書き込んだら放置だけど、ちょっとお金を「はずめば」普通に使えるのがいい。面倒な解凍処理が必要で半日も待たされる他のクラウド アーカイブ ストレージにはない大きなメリットだ。
    • アクセスやNW転送(ダウンロード)の料金が下がれば言うことないが・・・
    • あと、webコンソールを もう少しまともにしてくれれば・・・
      • その他、細かいこといろいろｗ
    • それから、Googleらしく「止めた」とか値上げとかがないことを祈るｗ
  • GCS(Archive)の料金は試用クレジットの約3万円に比べて概ね安いので、最初の試行や初期バックアップには充分過ぎるくらいだ(まだ9割くらい残って居る)。やりたくないが、何回でも最初からやり直せるｗ

 

という訳で、目論見・見積もりが合っていれば、「保存データ量倍増、料金4割減」(→ コストパフォーマンスは3.3倍?)という うれしいことになるはずだが、果たしてどうなるか。(何もしなければ変わらないだろうが)1-2か月は頻繁に料金をチェックし、大丈夫そうならB2のデータをGCSに移行(実際には、移行するファイルをB2へのバックアップ対象から外す)したい。※

※頻繁に変更するデータをB2に残し、そうでないものをGCSに移す。

移行後はB2の月額が1ドル未満になる予定だが、それはちゃんと請求されるのか、変な心配はあるｗ

そして、もし移行してから失敗に気付いたとしても大丈夫だ。というのは、duplicacyは履歴を保存するので、設定した期間(僕の場合、約半年)は削除済みのデータが残って居るからだ(そのため、その間は料金は安くならない)。

いざという時に、その残って居る履歴を期限で消さないようにできるのか不明だが、まあできるだろう。少なくとも、pruneしなければ消えない。

残件としては、前回書いたように、「まっさら」な状態からのリストアの手順を検討・試行をすることと、作成または更新年が新しいのでGCSにバックアップしないようにしたファイルを、定期的に(毎年)バックアップ対象に追加する(= B2からの移行)※ことがある。

※きっと、こんな作業を自動的に行う階層的ストレージ管理ソフトはあるのだろうが、エンタープライズ用で「お高い」だろうし、使うのも面倒なんだろうと思うが、実際はどうなんだろう。実はフリーであったりするのか?

 

一時IPv6アドレスの更新の影響について

IPv6のIPアドレスは固有(一応、全世界で1個)のため、プライバシーを保護するために(IPv6 privacy extension)、有効期限付きの一時アドレスというものを短期間(Linuxでは通常は1日)で変えながら使う(そうでない設定も可能)。その期限("temp_prefered_lft" (sic))が切れると、一時アドレスが更新されて変わる。ただ、古いアドレスが即座に無効になると通信が切れて問題があるので、しばらく(Linuxでは通常は6日: 最終的な期限("temp_valid_lft")の7日-上記の1日)は使えるようになっているようだ。(ここは動作からの推測)

Linuxの一時IPv6アドレスの更新処理 (推測)

1. システム起動時やNW IFの初期化時に、新しい一時アドレスが生成・割り当てられる。
   • そのアドレスは、preferred_lftが0になるまで新しい通信に使われる。
2. preferred_lftが0になった(deprecated状態)は、valid_lftが0になるまで残る。
   • そのため、通信中にアドレス更新があっても、当面は問題は起こらない。
   • ただ、そのまま延々と通信を続けた場合、valid_lftが0になった時点でアドレスがなくなるので、問題が起こる。 → 通信できなくなる?

なお、preferred_lftやvalid_lftが減るのはLinuxが動いている間だけで、スリープなどで止まっている間は減らない。また、再起動でどうなるかは不明。

当初、僕は そこを理解していなかったため(一時アドレスの設定方法については情報があるが、動作や2つの期限の違いの詳細については見付からなかった)、期限が切れても無効になったアドレスが引き続き残って居るのを見て、ちゃんと動いていないと思い、temp_valid_lftとtemp_prefered_lftを同じ1日(86400秒)にしてしまった。そうすれば、実際に毎日の期限でアドレスがガラッと変わって気持ちが良かったのだが、上記のようにアドレス更新されるとそれまでのアドレスが無効になってしまっていた。

ただ、その瞬間に通信している場面が少なかったのか、あるいは、多くのプログラムが そういう通信エラーにちゃんと対処していたためか、何も問題が起こらなかったが、duplicacy+GCSだけは違っていた。たまたま見ていた時にアドレス更新が起こったら(あとでそうだったと推測した)、しばらく(30秒-1分?)アップロードが停まり(リトライしていた?)、その時にアップロードしていたと思われる(本当にそのものかの確認はできていない)チャンクが消失した。duplicacyはエラーを出していなかったので、通信できなくなる前にGCSから成功が返って来たのか、duplicacyの通信エラー検出・対策に不備がある可能性が考えられる。

この問題をduplicacyの作者に報告したほうがいいが、そもそも設定ミスに起因するのと、再現させるのに手間が掛かるし、GCSとの相性の可能性もある(B2に対しては起こったことがない)ので保留している。

これに対処するには、まずはLinuxの一時アドレスの設定を「ちゃんとする」ことで、デフォルト(temp_valid_lft= 7日, temp_prefered_lft= 1日)に戻したら問題は起こらなくなった。ただ、可能性として、以下の場合は問題が起こるのではないか(待つのに疲れたので、実際には確認していない)。

1. 一時アドレスの更新(temp_prefered_lft)時刻の少し前にduplicacyでバックアップを開始し、
2. temp_valid_lftの期限が過ぎてもバックアップが終わらない。

この対処(予防)のために、duplicacyでのバックアップ開始前に、一時アドレスの設定を変更して固定にし(例: use_tempaddrを1にする)、バックアップ終了後に設定を戻すことを考え、そのスクリプトを作るつもりだったのだが、その前に設定をちゃんとして試していたら(バックアップの残量が少なかったため)問題が再発することなく初期バックアップが全部終わってしまったので、スクリプトは作らず仕舞いである。

ただ、今後(忘れた頃に)問題が起こる可能性があるので、バックアップ開始前に一時アドレスの有効期限(temp_valid_lft)を調べて、途中で切れそうだったら(バックアップ量によるが、暫定で1.5日にしている)メッセージを出してエラーにするようにした。

 

こぼれ話 (Azure(日本MS)を大いにディスる)

以上の話とは全く関係ないが、Azure(日本MS)はトライアルの使用状況を聞くために電話(マジで!)を掛けてくるというアフォさ。その連絡メールは、「いつがいいか知らせろ。返事しない場合はテキトーに掛けるよ」(意訳)で、「は????」としか言いようがない。

こっちは、何もしてないのに規約違反のアクティビティを検知したとかでアカウントがロックされたままで使いようがないのに、そういうことを調べもせず ただ電話すればいいという、昭和的馬鹿営業の極み。掛かって来たらブロックするのが楽しみだ。

電話で、ロックの件やAzureが使いにくいとか言うのも可能だろうが、大抵その場の「なるほど」、「検討します」だけで何も変わらず(というのは、そういうのは向こうの期待する回答じゃないため)、こっちが対応する労力が無駄なことが分かっているのでしない。

→ と書いたら、書き終わる前に(上の「いつがいいか」のメールが来た数時間後(同じ日)に)掛けて来た。留守電の声は新人らしいが、本当に非常識なヴァカだった(上司の命令どおりのことをしているだけなのか)。待ってましたとばかりにブロックリストに入れた。ヒヒヒ。って、性格悪いな。

それにしても、そんなことまで入会時に承諾したつもりはないが、(ちゃんと読まなかった)規約に書いてあったのだろうか。ただ、メールに定例の「以後、不要な場合は−」のような文言すらなかったので、日本MSのクソ意識の低さを再確認した。

バカジャネーノ!

もちろん、一応試したけど未だにロックされていてサインインできず退会できないから、試用期間が終わるのを待つしかない。こんなのを ほんのわずか(1μgくらい)にでも使えるかと思って試した僕は、本当のクソだ。

→ (10/15 9:36) 良く考えたら、アカウントを放置したら、試用期間が終わったら残ったデータに課金される可能性があるから、退会した。それがすごく分かりにくく面倒だった。

最初はMicrosoftアカウントを削除するだけでいいと思ったのでそうしたが、アカウントが削除されるまでに待機期間(30または60日)があり、その前に試用期間が終わったら課金されてしまうので、一旦アカウントを復活させてストレージのデータを削除した。更に、MSのページによれば、Azureのサブスクリプションを解除する必要もあるとのことなのでそうした。カード情報の削除は アナログな方法でしか削除できず面倒なので、放置した。さすがに退会すれば使われないだろう。

もう二度と入りたくない!

 

PS. それにしても、データ量1TB、使用料月額約1ドルなんてゴミ誤差みたいなもので、他の大規模ユーザの隙間に生きるような感じだｗ そういうユーザが居るからこそ、僕のような趣味の者でも安価だけど高い信頼性で使えるのだ。そういう点では、GCSは(小さいほうの)スケーラビリティ(スモーラビリティ??)も高いと言えるのではないか。あるいは、銀行や政府のお金の計算のように、1円(あるいは銭)から兆以上までちゃんと扱えるってことだろう。

「兆」と書くとすごく大きく感じるが、実は10¹²で、データ量などではTで、実はそれほどでもない。PやEなどを扱うITの世界は、お金の計算を超越しているのだろうか?

そういえば、僕のスマフォの契約も500MB/月と似たような領域だ(爆) こういう技術(かどうか分からないが)も きっと何かに役立つはずだ。

こういう細かいのは米粒に文字を書くとか豆本とかの日本のお家芸みたいで好きじゃないが、それ自体を目的とする訳でなく、遊びとか興味を嵩じさせてやるのなら いいのではないかな?

あと、この場合、豆本に相当するのは、大きなデータをいかに圧縮するかみたいなことだと思う。そういうのは使いにくいし、情報量を落とす(非可逆圧縮)場合もあって本末転倒なので全く興味がない。この類の いい(悪い)例はi-modeだ。

 

(11/15 14:50 重複排除の効果の項を修正, 10/17 18:51 わずかに加筆)