Posts tagged ‘hate Microsoft’

先日書いた、このブログの海外へのプロモーション用※に、各稿の下に英語で(新聞のような)見出しやキャッチ的なものを出すことにした(そういうのの適切な英語訳が分からないので、"Keys"とした@)。最初は自分で付けていたのだが、結構面倒なので*AIにやらせることを思い付いた。

※これは、以前大嫌いだと書いたSEOの一種になるのだろうが、無理に検索の上位にしようとしている訳でなく、外国の人の目に触れる機会を作ろうとしているだけだ。

*自分で書いたにも関わらず内容を忘れて居る(このブログの主旨には合っている)のと、近頃は やたらに長く内容が多過ぎる稿が多いことが多い。そこは要改善点なのだろう(と、書いておく)。

@ちょっと強引だが、KeysはWordPressのタグとして扱っている。

それで、いろいろなAIソフト(エンジンは主にOpenAIの無料版)で各稿のサマリーやキーワードを生成しようとしたが、巷の評判とは異なり、今一つ うまく行かなかった。

最初にChatGPTで試したら、外部URLは読み込めないから使えなかった。次にWritesonicのText Summary V2を試したら、結構良さそうだった。出力に英語を指定すると、日本語の文章も英語でサマリーを出してくれる。ただ、それからKeysを作るのは手作業で それほど楽ではないし、WordPress(以下、WP)に貼るのも面倒だった。

そこで、こういう用途に使えるWPのプラグインを探したが、ほとんどなかった。: 多くはChatGPTのプロンプトを出すだけだし、投稿の編集ページでなく独立のページでしか使えないものや、有料(最初だけ無料)でしか使えないものも多かった(それを明記していないものがあって ひどい)。

使えないからアンインストールしたら"We Need to Talk!"とかいうメールを送って来て、unsubscribeしたら それにもメールを送って来た、大変鬱陶しいGetGene AIというクソもあった。

唯一残ったのはFlusso AI※(OpenAIを利用)だった。投稿の編集ページでボタンを押すだけで、Key Pointsというサマリーを作ってくれ、それを投稿と一緒に表示することもできるから便利だ。この出力は上述のWritesonicと同様だったので、どちらもOpenAIの機能を使っているのだろう。

※Flussoは 問い合わせに ちゃんと対応してくれて良い。出たばかりでユーザが少ないからだろうか。ただ、作者が自分でレビューの評価を★5にしているのは逆に損だ(ただ、一般ユーザを詐称している訳ではないので、悪意はなさそうだ)。

ただ、使ってみると、実はKey Pointsも今一つなことが分かった。箇条書きだけど なまじ文章(しかも短くない)になっているため、パッと見てもポイントがすぐには分からない。僕がネイティブでないせいはあるだろうが、文章の単語数が多い気がする。要するに、長ったらしい。(要約なのに"TL;DR"になりそうだw): 以下に、Key Pointsの出力の(良い)例(前回の稿「ちゃんと多言語対応するのは大変だ。」)を示す。

∙ The blog is primarily aimed at a Japanese audience, but some topics, such as technology, are relevant internationally, leading the blogger to consider creating an English version.

∙ The blogger initially used machine translation to create an English version of the site, using Google and Yandex, which had comparable translation quality.

∙ Google Translate was ultimately chosen because it successfully translated the name "Hamelin," and a link to the English version was added to the site.

∙ The blogger considered various options for improving the English version but decided to stick with the current setup due to the difficulty and cost involved in creating high-quality translations.

論文などなら良いが、僕がKeysとして欲しいのはツイッターのタグ※的なもの(一つの単語でなくても良く、完全な文章でなくて良い、パッと見て中身が想像できる・興味をもたせる短いフレーズ)だ。 参考までに、僕が考えたKeysは以下である。

AI translation, build multilingual website, Google and Yandex translate comparison, Google Translate, i18n, machine translation, Yandex Translate

※そういう機能のものも いくつかあったが、原文が日本語のせいか結果が全く駄目だった。

AIの出力は大筋では合っているのだが、前書きやアムランの件は余計だし(しかも、後者は読み切れていない)、Googleが すごく良いから選んだ訳ではないし、題にも書いた重要な意図(build multilingual website: 単なる英語版を作ろうと思っているのではない)は読めていない感じだ。

それ以前に、稿によっては、結果に重要な内容が書いてないことがあったので、結局、自動処理はできず、出力を確認して修正する必要がある。※ それから、OpenAIの無料版だと元の文章の長さ(単語数?)制限があって、結構多くの稿で使えなくて不便だ。

※以前も書いたが、今のAIの最大の欠点は、人間が結果を確認する必要があることだと思う。まあ、人間に依頼した(or 自分でした)作業でも同じだけど、自動化・効率向上の妨げになっている。そして、しばらくはAIに作らせたままの ひどいソフト・システムや文章が出て来そうだ。。。*

*でも、今だって、れっきとした人間に作らせたままの粗悪品が某ショッピングサイトAに蔓延しているので、AIだけが悪い訳ではではない。出す人間が悪い。

それに、ソフトやシステムだって、大企業が多額の費用を掛けて作ったものでもマトモに動かないことがあるではないか。(例: 近頃問題が発覚している、マイナンバーでの住民票発行システム)

それに比べれば、AIが作ったまま出すほうが費用対効果は良さそうだ。だから人間は不要だ。: などというのは、政治家とか有名人がTVとか配信で言いそうだが、単なるレトリックで技術的・論理的には正しくない。

原因は いろいろあり、人間とAIでは問題が起こる確率が異なるが、全部人間が悪いのは確かだ。AIが作ったまま出すのも、同じく人間が悪いために問題が起こる(現時点ではAIでなく人間が出すため)。

結局、どちらにしても、人間が真面目にやれば いいってことだ。少なくとも今は。

そういうことなら、最初にやったように、「自分で稿を読んで英語のキーワードを考えたほうが楽」という結論になって、(暇潰し?を兼ねて)順次やっている。

まあ、有料版のOpenAI(GPT4)なら強力で長さ制限もないのだろうから もう少し良くなるだろうが、料金が かなり高いので趣味には使えない。それでも、今後は手軽に使えるものが出て来ることを期待したい。

(19:18) その後、Flussoの方に勧められて、GPT-4 APIの待ちリストに登録した。GPT-4は全部有料だと誤解していたが、それが通れば無料でAPI(Flussoが使う)が使えるようだ。

そうすれば、長さの問題はクリアできる。キーワードを抽出する(Keysを作る)のは、どういうAPIがあるか調べてFlussoに要望するか、自分で作ってみたい。

 

なお、今、英語関係で一番役に立っているのはDeepL(翻訳, write(改善))だ。これもAI技術を使っているようで、普通の辞書サイトと違って生きた・「こなれた」英語にしてくれる。※ APIもあるようだが、やっぱり料金がすごく高いので使えず、もっぱらwebページで処理して結果をコピペしている。

※僕の印象なので正しいかは不明だが、日本の辞書サイトで出た、「なんか うーん」な英語をDeepL Writeに入れると、いかにも「おお これだ!」という自然なネイティブが使うような(に感じる)結果になることが多い。

なお、DeepLのは和訳は少し弱い感じ(ちょっと砕けた英語(それでも、和訳はできるしwriteは通る)は破綻する)だが、僕には英訳や英語の修正のほうが重要なので、大きな問題ではない。

 

PS. ニュースで良くなったと見て、Edge+Bingも試したが、なぜか散々だった。: 本文に書いたのと同じ稿に対する出力が全く誤っていて、なぜか全く別(別人)の文章に対するものだった。全然違う、どうして?と指摘したら、一方的にチャットを「終了」に されてしまった。ChatGPTなら続けて「どうして欲しい」と打ち込めるのに・・・

同じOpenAIを使っているはずなのに、随分作り込みが違うようだ。

使い物にならないようなので、Edgeは すぐにアンインストールした。いつものように、一瞬でもMSに期待したのが間違って居た。

PS2. 試しに この稿のGoogle翻訳での英語版を読んでみたが、やっぱり結構良い。破綻している箇所があってDeepLほどではないが、OpenAIのサマリーよりは ずっと読みやすい。

それから、どういう訳か、今回は「w」を"lol"と訳していたので感心した。

  •  1
  •  0
Keys: , , , , , , , , , , , , ,

いつものように四苦八苦しつつも(そのため、気付いたら前回から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コンソールを もう少しまともにしてくれれば・・・
        • その他、細かいこといろいろw
      • それから、Googleらしく「止めた」とか値上げとかがないことを祈るw
    • GCS(Archive)の料金は試用クレジットの約3万円に比べて概ね安いので、最初の試行や初期バックアップには充分過ぎるくらいだ(まだ9割くらい残って居る)。やりたくないが、何回でも最初からやり直せるw

 

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

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

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

そして、もし移行してから失敗に気付いたとしても大丈夫だ。というのは、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ドルなんてゴミ誤差みたいなもので、他の大規模ユーザの隙間に生きるような感じだw そういうユーザが居るからこそ、僕のような趣味の者でも安価だけど高い信頼性で使えるのだ。そういう点では、GCSは(小さいほうの)スケーラビリティ(スモーラビリティ??)も高いと言えるのではないか。あるいは、銀行や政府のお金の計算のように、1円(あるいは銭)から兆以上までちゃんと扱えるってことだろう。

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

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

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

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

 

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

  •  1
  •  0
Keys: , , , , , , , ,

以前から、手持ちの音楽のファイル全部を(ローカルな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割近く安く、(さまざまな疑念はあるがw)もし良ければ使うのも悪くはない。それに、Googleだって好きじゃないw

結論を先に書くと、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の設定でをどうするのか分からなかったが、最後にブラウザで認証・許可できることが分かった。
      • 先進的でちょっと感動したがw、rcloneのマニュアルに書いておいて欲しかった。
    • rcloneでのファイル・ディレクトリの移動に癖があるが、大きな問題はない。
      • サブコマンドmoveとmotvetoの違いなのだろう。

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

 

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

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

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

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

 

(19:27 修正・補足)

  •  1
  •  0
Keys: , , , , ,