- コンピュータ利用の問題解決に向けたモデルの事前学習のため、9,000万時間分の動画データ保存を目標に、サンフランシスコ都心でストレージクラスタを自前構築
- オンプレミス方式を選択し、年間**$354k（約5億ウォン）**で30PBの保存インフラを運用可能。AWSなら$12m（約170億ウォン）で、約34倍のコストを削減
- 多くのパブリッククラウドとは異なり、高可用性と完全性を重視せず、学習データの特性上データ損失を許容する戦略を適用
- シンプルなRustおよびNginxベースのソフトウェアで運用し、CephやMinIOのような複雑なシステムの代わりに自作の200行プログラムで管理
- プロジェクトの進行では、物理配置やネットワーク構成、ケーブル管理など、現実的な試行錯誤とノウハウを数多く経験
序論と背景
- コンピュータ利用のためのモデル事前学習には、大容量の動画データが必要
- 一般的なテキストLLM（例: LLaMa-405B）は約60TBのデータでも十分だが、動画ベースの学習には500倍多い保存容量が求められる
- AWSのようなパブリッククラウドを使うと年間1,200万ドルかかる一方、コロケーションセンターを借りて自前構築することで、これを約35万4,000ドルまで大幅に削減できた
- 大容量データを自前で保管することで、データコストが最大の制約だった問題を解決
なぜ自前で構築したのか
- クラウドは高信頼性、冗長性、データ完全性に焦点を当てるが、事前学習用データは
5%の損失も許容できるほどクリティカルではない
- こうした特性により、一般企業よりはるかに緩い信頼性要件を選べた（
13ナインの信頼性ではなく2ナインを適用）
- ストレージ価格が実際の原価に比べて大幅に高く設定されている
- データが最大のコスト要因であり、十分に予測可能な範囲ではローカルデータセンター構築の方が有利だと判断
コスト比較: クラウド vs 自前構築
- 月次の継続費用: インターネット $7,500 + 電力 $10,000 = 合計 $17,500
- 一時費用: ハードドライブ $300,000、シャーシ $35,000、CPUノード $6,000、設置費 $38,500、労務費 $27,000、ネットワークおよびその他設置費 $20,000 → 合計 $426,500
- 減価償却（3年）込みで月間固定費は $29,500 と試算
- AWS 月額 $1,130,000、Cloudflare R2 月額 $270,000、自前構築 月額 $29,500
- AWS: TBあたり約38ドル/月
- Cloudflare: TBあたり約10ドル/月
- 自前構築: TBあたり1ドル/月
- 大規模モデル学習ではCloudflareでさえ内部システムへの高負荷によりrate-limitの問題が発生したが、自前環境では100Gbps専用回線で解決
構築とプロセス
- 迅速な構築のために
Storage Stacking Saturday(S3)を計画し、知人の協力と専門コントラクターを投入
- 36時間で2,400台のハードドライブをラックに搭載し、30PBのハードウェアを完成
- ソフトウェアは Rust（書き込み担当、200行） + nginx（読み取り担当） + SQLite（メタデータ追跡）
- Ceph、MinIO、Weka、Vastなどは複雑さやコストの問題から使わなかった（複雑すぎる、必要性がない、保守負担が大きいなど）
- すべてのドライブをXFSでフォーマット
プロジェクトのフィードバックと教訓
うまくいった点
- 冗長性と性能のトレードオフを適切に適用し、100Gネットワークをほぼ使い切る形で活用
- 物理的に近い場所に構築してデバッグと保守のしやすさを確保
- ベンダーはeBayで探しつつ、実際の購入は個別サプライヤーと直接取引し、保証の重要性を重視
- 100Gインターネット回線には多くの利点があり、ネットワーク問題も自前でデバッグしやすい
- 高品質なケーブル管理が後のトラブルシューティングで大いに役立った
- 複雑なオープンソースのストレージシステムではなく、シンプル化の原則を適用して保守負担を最小化
- 時間と労働コストの予測も正確で、削減効果を明確に確認できた
難しかった点と試行錯誤
- フロントローダーの採用により、2,400台のHDDを1台ずつ手作業で装着する手間が発生
- ストレージ密度が不足しており、初期設計でもっと高密度を採用していれば労力を減らせた可能性
- デイジーチェーンは速度ボトルネックを招き、各シャーシに個別のHBA接続を行うのが理想
- ネットワーク部品はブランド互換性が重要で、特に光トランシーバーで顕著
- ネットワーク構成の実験と設定に時間がかかり、DHCP/NATではなく性能と利便性重視で構成した（firewall/secure linkの最小要件のみ適用）
- 物理的なアクセス性や、セットアップ時のモニター/キーボード配線の重要性を痛感
試してみる価値のあるアイデア
- KVMとIPMIの活用でリモート管理を効率化
- 管理用イーサネットネットワークを別系統で構成することを推奨
- ネットワークのオーバープロビジョニング（例: 400G内部ネットワークの検討も価値あり）
- より高密度なサーバー（90-drive Supermicro/20TB HDDなど）により
ラック数削減、消費電力削減、CPU集約効果などで有利
どうやって自前構築できるか
ストレージ構成
- CPUヘッドノード10台（Intel RR2000など、各サーバーあたりデュアル Intel Gold 6148/128GB ECC DDR4 RAMを推奨）
- CPU負荷の高い機能（ZFSなど）は、より高性能な機材を選択可能
- DS4246シャーシ100台（各24台のHDDを搭載）
- 3.5" HDD 2,400台（可能ならSASドライブ推奨、速度面で有利）
- 12TB、14TBなどさまざまな容量を組み合わせ、大容量ほど配置や中古価値の面で有利
- 物理搭載のためのレール/ブラケット類、機器配線およびケーブル
- ネットワーク問題のデバッグ用にcrash cart（モニター+キーボード）を複数
ネットワークインフラ
- 100GbEスイッチ（中古のAristaなど、QSFP28ポート）
- 各サーバー用HBA（推奨: Broadcom 9305-16Eなど）、HBAポートとシャーシの接続方式
- ネットワークカード（Mellanox ConnectX-4など、必ずイーサネットモード）
- DAC/AOCケーブル—ラック間距離を考えるとDACに互換性面の利点あり
- CPUヘッドノード購入時は、HBA/NICを事前搭載したサプライヤーの利用を推奨
- シリアルケーブル、管理用イーサネットの別ネットワーク（バックアップ用無線アダプター + miniスイッチの代替案）
データセンター要件
- キャビネットあたり3.5kWの消費電力、42U基準で4U×10 + 2U×1構成を想定
- 3PB/キャビネット、スイッチ用に予備の42Uキャビネット1本、またはシャーシ1Uで代替
- 専用100Gクロスコネクト（通常はQSFP28 LR4の光1対）を用意し、フォームファクタとブランド互換性を事前確認することが必須
- オフィスに近い立地（コロケーション）を推奨。問題発生時に迅速な物理対応ができ、デバッグと運用の生産性を最適化できる
初期設定のヒント
- スイッチを最初にローカルコンソールで設定し、100GbEアップリンクポート設定と光トランシーバー互換性を先に検証
- 必要に応じてISP光回線をNICに直結してリンクアップを確認してからスイッチへ移行
- Ubuntuインストール中にNetplanでノードのネットワーク設定を終える方が容易
- ノードをインターネット接続した後、各DS4246を1ケーブルずつ接続→フォーマット/マウント→状態確認の順で進め、配線不良やディスク不良を早期検出
性能・安定性の注意点とセキュリティ
- 学習データ専用というセキュリティ前提のもと、グローバルIP直結 + ポートファイアウォール + nginx secure_linkで簡素に運用
- 顧客データを扱う場合、この構成は不適切であり、DHCP/NAT/細分化されたファイアウォールが必須
- デイジーチェーンは管理と配線は容易だが帯域ボトルネックを招くため、可能ならシャーシごとの専用HBAを推奨
- 光トランシーバーはブランドロックインが強く、FS.com と Amazon を併用調達しつつ、仕様とブランド一致を厳密に確認
結論と意味
- $1/TB-月水準の超低コスト自前ストレージで30PBの動画事前学習を現実化し、クラウド比で10〜38倍のコスト削減を達成
- シンプルなアーキテクチャと現場へのアクセス性が時間とリスクを減らし、100G専用回線がI/Oボトルネックを解消
- 大規模マルチモーダル・動画モデル時代の中核的な競争力は低コスト大容量データインフラであり、このアプローチは少人数でも実装可能な実践的リファレンスを示す
締めくくりと協力案内
- 本記事を参考に類似のストレージクラスタを構築した場合は、改善点や経験の共有を歓迎
- 大規模なコンピュータ利用モデルの事前学習、および一般化・人間の価値に結びついたAI研究の人材を募集中（連絡先: jobs@si.inc）
1件のコメント
Hacker Newsのコメント
キャリアを始めた頃はオンプレミスが当たり前の環境だった。長く使うハードウェアには結局手をかけることになり、各サーバーごとに状態が蓄積していく。時間が経ってハードウェア性能が不足してくると、社内チームを通じて既存リストから新しいハードウェアを選び、追加費用の承認も取らなければならず面倒だった。ハードウェアの入れ替えや、ペットのように大事にしてきた機材をきっちり切り離して新しい機材へ移行する過程で、プロジェクトが遅れることもあった。クラウドが登場したときは「もう絶対にクラウドへ移行すべきだ」と思っていた。でも時間が経つと、自分や組織はハードウェアを直接管理する方法を忘れてしまい、結局その技能を取り戻さない限り、かつて良い選択だったクラウドがだんだん魅力の薄い選択肢になっていく。だから、こうした技術をまた育て直すきっかけをくれてありがたい。
私たちは少し特殊な状況だ。初期の段階からハイパースケールクラウドを運用費として賄えない立場だったので、やむを得ず自前の技術を育ててきた。思ったほど難しくはなく、しばらくはこのやり方を続けるつもりだ。ただ、言及されていた状態の蓄積という問題は少し見え始めている。
記憶している限り、オンプレミスはいつもコストが安かった。物流上の障害がいろいろ消えて、請求書が1本になる便利さはあった。クラウドがもてはやされていた頃の助言は、常にオンプレミスを使い、トラフィックが急に増減するときだけクラウドを使え、というものだった。ところが一時的なスケール用途が次第に常用になり、開発者たちは新しいマシンをすぐ立ち上げることに依存するようになった。今では誰もがクラウドをデフォルトの状態だと考えている。その過程で実際のコストを正しく感知する基盤を失い、クラウドとオンプレミスのコスト差はますます開いていった。
Dockerは、サーバーをペットではない存在にしてくれる非常に優れたツールだ。ラック内のサーバーが単なる別のK3やK8ノードとして扱われるので、ペットのように扱わなくて済む。この点が本当に良い。VMについても似たことは言えるが、結局VM自体がペットになってしまう。もちろんイメージを作ったりスナップショットを取ったりはできるが、Dockerで感じる変化とは違う。
もう一度こういう挑戦をやってみるか、という冗談半分の問い。
.incの2文字ドメインを平然と買えるほど金のあるスタートアップは、資金が過剰すぎるということだ。昔のスタートアップでオフィスにAeronチェアが何脚あるか数えるのと同じ現象で、良い兆候ではない。
未使用の.incの2文字ドメインは年額2300ドルで売られている。開発者1人分の人件費の5%にも満たない額だ。
.incドメイン名に実質的な価値があるのかは疑問だ。
面白い記事だった。読みながら疑似体験を楽しめた。こういう体験をもっと面白く見るには、写真がもう少し多ければよかったと思う。
技術的な内容が詳しく書かれていてよかった。気になるのは、コロケーションスペースをどうやって確保したのかという点だ。ブローカーを使ったのか、価格交渉で最初の見積もりと実際に払った金額がどれくらい違ったのか知りたい。
リンクされていたDiscordのブログ記事も興味深かった。主には真面目な内容だが、こんな面白い部分もあった。ワールドカップでゴールが入ると、そのデータが監視グラフにすぐ反映され、チームメンバーは会議中にサッカーを見ていたことを業務用モニタリングだと言い張れた。実際のシステム使用量の話でもあり、Discordが「1ペタバイト未満」のストレージでメッセージを保存している根拠として引用されていた。推測だが、この記事のノードサイズと台数で計算すると、以前のクラスターは708TB、新しいセットアップは648TB程度になるらしい（成長余地込み）。
ストレージ自体は非常に安い。ただ、トレーニングとネットワーキングのセットアップ部分が理解できない。他のコメントではGPUが1か所にまとまっていないとあったので、そうなると複数サイト間で100Gbpsだけで学習データをやり取りしなければならない。これでは事前学習の過程でボトルネックにならないか心配だ。
この規模のワークロードなら、AWSや他のクラウドでもプライベート見積もりは十分取れるはずだ。S3なら0.5PBになった時点で個別見積もりをもらえる。全体コストが自前で管理するより安いという意味ではないが、CSPの小売価格とeBayで調達した機材+無償労働（ピザ代を除く）を比べるのは完全な比較ではない。
AWSやクラウドではegress費用が本当に核心だ。その部分は交渉しようとしてもまったく譲ってくれない。AIトレーニング用途では、そもそも使い物にならないレベルだ。Cloudflareの見積もりは、マネージドなオブジェクトバケットストレージの中でも安い方だ。自前でクラスターを構築すると、マネージドサービスとの差は小さくなってきた。自前構築は交渉力にもつながる。しかしマネージドバケットは、単純な事前学習用ストレージとしてはオーバースペックすぎる。Glacierはアーカイブ用途としてはコストパフォーマンスが良いが、ML用途にぴったり合う製品はまだない。
具体的にどの程度のディールが可能なのか気になる。半額以上の割引もあり得るのだろうか。
ドライブの取り付け作業を一緒にやれて楽しかった。これほど大量のデータを実際に扱う作業は、いちばんワクワクする体験だ :P
ディスク故障率への言及がない。数か月経ったあと状態がどうなっているのか気になる。
以前に投稿した経験だが、ディスクアレイをいくつも立ち上げた際に大量のドライブ故障が発生したことがある。金曜の午後にラックをセットアップし、週末の間は触らずに簡単なシェルスクリプトでデータの読み書きテストを回しておいた。月曜に来てみると、ほぼ半分近いディスクが壊れていて、しかもログは何も残っていなかった。ストライピングの過程に問題があったのか、ストレステストで壊れたのか、知る術はなかった。工場不良のロットだったらしく、同じ会社の他の顧客も何人も苦情を出していた。メーカーが全数交換してくれて、本番投入が遅れただけで済んだ。その後は1年間まったく故障しなかった。
最近は10年前と比べてディスク故障率が非常に低くなった。以前は1週間に10台以上交換していたが、今ではまれに起きる程度だ。Backblazeのハードディスク統計を見れば十分だと思う。
そのクラスターではエンタープライズ向けドライブを使っているとのことだが、コストを節約しようとすると後で大きな損失になることもある。個人的にホームサーバー用に中古ドライブを使ってみたが、性能のばらつきが大きすぎてあまり良くなかった。
いい指摘だ。