ストレージを信じるということ

Share

ストレージに求められるのは、便利さと信頼性の両方だ。この二つが揃っている限り、裏側がどんな技術で動いていようと気にする必要はない。ファイルを保存して、必要なときに取り出せる。それだけのことが当たり前に機能し続けること。ストレージへの信頼とは、つまるところそういうことだと思う。

ところが、ストレージには他の技術レイヤーにはない厄介な性質がある。

不可逆性という特殊性

ソフトウェアにおける抽象化とは、内部の複雑さを隠して、使う側に必要な操作だけを見せる設計思想だ。ファイルを「保存」するとき、実際にディスク上でどのようにデータが書き込まれているかを意識する必要がないのは、この抽象化が正しく機能しているからにほかならない。

多くの技術レイヤーでは、抽象化が破綻しても回復の手段がある。計算の誤りはやり直せる。通信の途切れは再送できる。しかしストレージの喪失は、バックアップが存在しなければ取り返しがつかない。破綻したときに巻き戻せないという不可逆性が、ストレージを特別な領域にしている。

同じ性質を持つ分野は他にもある。たとえば暗号鍵の管理がそうだ。秘密鍵を紛失すれば、署名能力は不可逆的に失われる。共通しているのは、「普段は裏側を知らなくていい」という信頼が、「裏側が壊れたとき誰が責任を取るのか」という問いと常にセットになっているという構造だ。

クラウドであれば、その責任はプロバイダが負う。NASであれば、それは自分自身だ。便利さと信頼性が両立している限り、この問いは表に出てこない。しかし一度発火すれば、被害は取り返しのつかないものになりうる。

サブスクリプションの構造

クラウドストレージに限らず、ソフトウェアのサブスクリプションモデルに抵抗を覚える人は少なくない。気持ちはわかる。しかし、買い切りとサブスクリプションのインセンティブ構造を比較すると、直感とは異なる側面が見えてくる。

買い切りモデルでは、販売した時点で開発者の収益は確定する。その後もソフトウェアを維持し続ける経済的な動機は、構造上、弱い。もちろん評判やブランド価値の維持といった間接的な動機はあるが、直接的な収益との結びつきは薄くなる。

サブスクリプションモデルでは、ユーザーが継続利用することが収益に直結する。だからサービスを安定的に提供し続ける動機が、ビジネスの構造そのものに組み込まれている。「月額を取られ続ける」という不満と、「だからこそ維持される」という事実は、矛盾なく両立する。

ただし、サブスクリプションにはもう一つの動機が内在している。解約を防ぐことが収益に直結するならば、乗り換えコストを意図的に高くする動機も同時に生まれる。データのエクスポートを煩雑にする。独自フォーマットに囲い込む。APIを制限する。こうした施策は、サービスを「維持する」動機と「離脱させない」動機が表裏一体であることを示している。

ここには信頼と依存の境界がある。どちらも、外から見れば「相手に任せて自分は関与しない」という形をとる。しかし信頼は離脱の自由を前提に成立するのに対し、依存は離脱の困難さによって維持される。サブスクリプションを使い続けるほどデータと習慣が蓄積され、最初は信頼だったものが、いつの間にか依存に変質していることがある。しかもその境目は明確でないから、当人にも気づきにくい。

NASという選択肢

NAS(Network Attached Storage)は、手元にストレージサーバーを置いて自分で管理するという選択だ。クラウドにデータを預けることに不安がある人にとって、データが物理的に自分の管理下にあるという事実は、一つの安心材料になる。

たとえばSynologyのNASは、ハードウェアは買い切りでありながら、DSM(DiskStation Manager)と呼ばれるOSが継続的にアップデートされる。ファイルシステムにはBtrfsが採用されており、スナップショットやデータのチェックサム検証によるデータ保護機能が提供される。なお、SynologyはBtrfsのネイティブRAID機能ではなく、LVM/MDベースのRAID構成の上にBtrfsを載せるという設計を採っている。これはBtrfsのRAID5/6実装に既知の安定性の問題があるためで、実用上は合理的な判断とされている。

このように「ハードは買い切り、ソフトウェアエコシステムは実質的に継続提供」という構造が、NASの信頼感を支えている面がある。純粋な買い切りハードウェアだけでは、長期にわたる安定運用は難しい。

一方で、NASは自己管理が前提だ。ディスクの故障対応、ファームウェアの更新、バックアップ戦略の設計と検証。これらはすべて所有者の責任になる。クラウドが信頼の委託だとすれば、NASは信頼の引き受けだ。便利だが、その便利さの維持にかかるコストも自分で背負うことになる。

データは増え続けるが、全部残すべきとは限らない

保存すべきデータが増え続けるのは事実だ。しかし、「増えた分はすべて保持すべきだ」という前提は自明ではない。

タグもフォルダ分けも検索用のメタデータも何もない巨大なアーカイブがあったとして、そこから必要なものを取り出せなければ、保存していないのと実質的には変わらない。ストレージの問題に見えて、実は検索と意味づけの問題であることが多い。

セマンティック検索やマルチモーダル検索といった技術の発展は、「まず保存して、検索は後からどうにかなる」という方向を後押ししている。技術が「全部残す」という戦略を事後的に正当化しつつある状況は、確かに興味深い。

ただ、何を残し何を手放すかを判断する行為そのものが、アーカイブに輪郭を与えるという側面もある。すべてを無差別に保持するということは、何も選んでいないということでもある。保存するという行為に意志が伴わなければ、それはアーカイブではなく、ただの堆積だ。

コールドストレージは個人に必要か

アクセス頻度の極めて低いデータを低コストで保持する手段として、コールドストレージという領域がある。

Meta(旧Facebook)はかつて、Blu-rayディスクを用いたコールドストレージシステムを自社開発した。1ラックに約10,000枚のBlu-rayディスクを格納し、約1ペタバイトの容量を実現するこのシステムは、従来のHDDベースの構成と比べてストレージコストを約50%、消費エネルギーを約80%削減したと報告されている。保存対象は、ユーザーがアップロードした古い写真や投稿など、ほぼアクセスされないが削除もできないデータだった。

クラウドサービスとしては、AWSのS3 Glacier Deep Archiveが約1米ドル/TB/月という低コストのアーカイブストレージを提供しており、個人が利用する事例も見られる。ただし、データの取り出しに12時間から48時間を要すること、最低保存期間が180日に設定されていること、リクエスト料金やデータ転送料金が別途発生することを考慮すると、運用は単純ではない。

こうした手段の本質は、「消すわけにはいかないが、ほぼ二度とアクセスしないデータ」を最小のコストで維持することにある。Metaにとっての目的はユーザーデータの長期保持とコスト最適化であり、アーカイブそれ自体が目的なのではない。アーカイブを目的としない限り、個人がこの領域に踏み込む必然性は薄いと言える。

ほとんどの人はこの問題の外にいる

NASとクラウドの二重化は、データの保全を真剣に考える層にとっては定番の手法とされる。しかし率直に言えば、大切なデータをUSBメモリに入れて保管しているだけで、世の中全体の平均からすれば十分に意識の高い部類に入る。

ストレージの冗長性について議論する人は、そもそもストレージを「問題」として認識できるだけのデータを持ち、それを失うことのコストを肌で理解している人だ。この問題について考えていること自体が、すでに多数の人とは異なる立場にいることを意味する。

これはストレージに限った話ではなく、あらゆるインフラに共通する構造だ。うまく機能しているインフラは、使っている人にとって透明になる。電気が来ることも、水道が出ることも、通信がつながることも、正常に動いている限りは意識の外にある。それが見えているということ自体が、見えていない人とは違う世界にいるということだ。

そしてこの構造には、ひとつの脆弱性がある。誰かがそのレイヤーを注視している限りは問題は表面化しにくいが、誰も見ていないレイヤーが生まれたとき、破綻は不可視のまま進行する。

何のために残すのか

ストレージの選択を突き詰めていくと、最終的に行き着くのは「このデータは誰のためにあるのか」という問いだ。

その答えが「自分のため」であれば、やるべきことはシンプルになる。自分が生きている間、必要なデータに手が届く状態を維持すること。それ以上の冗長性は、多くの場合、過剰だ。

もし誰かに引き継ぎたいデータがあるなら、問題はストレージの選択ではなく、そのデータを他者が読み解ける形に整えておくことの方に移る。それはもはやストレージの話ではなく、ドキュメンテーションの話だ。

大抵の人にとって、信頼できるストレージがひとつと、その控えがひとつあれば十分だと思う。技術的な正解よりも大事なのは、自分が何に信頼を置いているかを自覚していることかもしれない。

Read more

Dependabotの対応が面倒なのでRenovateを導入する

Dependabotくんはある程度の依存関係の更新を通知してくれるが、山のようにprojectを抱えているとなんとも痒いところに手が届かない。 ということで、Renovateを使ってみる。 Build software better, togetherGitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.GitHub ここからGitHub Appを入れる。 あとは、指示に従ってポチポチするだけで、超かんたんだった。 感想 自動化最高。

By Sakashita Yasunobu

nodejsのバグを見つけたのでPRを投げてみた

概要 要するに、node --testで特定のバイナリを標準出力に書くと、テストランナーが固まったり、異常終了したりするバグです。 バグ自体は既知のものだったようで、修正がされていました。 test_runner: infinite loop in FileTest#drainRawBuffer when child stdout contains FF 0F followed by large size bytes · Issue #62693 · nodejs/nodeVersion v25.9.0 (also reproduced on v24.14.1 LTS, v22.21.0 LTS, v23.4.0) Platform Darwin 25.

By Sakashita Yasunobu
青空文庫のParser

青空文庫のParser

青空文庫のParserを作ってます。 GitHub - P4suta/aozora: Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks.Pure-functional Rust parser for 青空文庫記法 (Aozora Bunko notation): ルビ, 傍点, 縦中横, 外字, 返り点, indent containers, page breaks. - P4suta/aozoraGitHubP4suta Rustで作ってますが、配布物はcargoのほかにnpm/pypiでも入手できます Documentation * Playground — try it in

By Sakashita Yasunobu