ペタバイト規模のウェブアーカイブの構築

エンジニアの理想世界では、アーキテクチャは常に美しいものです。しかし、大規模システムの現実世界では、妥協が必要です。エンジニアが最初に考えなければならない基本的な問題の一つは、書き込み速度と読み取り速度のトレードオフという厄介な問題です。

通常、一方を犠牲にして他方を得ます。しかし私たちの場合、AWSでペタバイト規模のデータを扱う中で、このトレードオフは速度ではなく財布に打撃を与えました。

私たちは完璧にデータを書き込むシステムを構築しましたが、アーカイブからデータを読み取るたびに、想像できる限り最も痛ましい方法で予算を燃やしていました。結局のところ、AWSからペタバイト単位のデータを読み取るには、データ転送、リクエスト数、ストレージクラスの取り出しにお金がかかります...それもかなりの金額です！

これは、より効率的でコスト効果の高いシステムに最適化した方法についての話です！

パート0：AWSの料金で10万ドルを使うことになった経緯

実話です：数ヶ月前、私たちのソリューションアーキテクトの一人が、見込み客に製品をデモンストレーションするために、珍しい低トラフィックのウェブサイトからサンプルエクスポートを取得しようとしました。APIのバグにより、ファイル数の安全制限が適用されませんでした。

この「珍しい」サイトのデータが高トラフィックサイトと一緒に何百万ものアーカイブに散らばっていたため、システムは数ページを見つけるために私たちの歴史的ストレージの半分近くを復元しようとしました。

この正直なミスにより、最終的にAWSの料金で約10万ドルのコストがかかりました！

すぐにAPIのバグを修正し（厳格な制限を追加しました）、しかしアーキテクチャの脆弱性は残ったままでした。それは時限爆弾のようなものでした...

Bright DataのWebアーカイブアーキテクチャの話をしましょう：私がシステムを「安価な」ストレージの罠に陥れ、再配置パイプラインを使ってどのように脱出したかについてです。

パート1：「書き込み優先」のレガシー

Webアーカイブの作業を始めたとき、システムはすでに膨大なデータストリームを取り込んでいました：毎分数百万のリクエスト、1日に数十テラバイト。基盤となるアーキテクチャは主要な目標を持って構築されていました：データ損失なくすべてをキャプチャすること。

それは高スループットシステムのための最も耐久性のある戦略に依存していました：追記専用ログ。

1. データ（HTML、JSON）がバッファリングされます。
2. バッファが約300 MBに達すると、TARアーカイブに「封印」されます。
3. アーカイブはS3に送られます。
4. 3日後、ファイルはS3 Glacier Deep Archiveに移動します。

取り込みフェーズでは、この設計は完璧でした。Deep Archiveにデータを保存するコストはわずかで、書き込みスループットは事実上無制限です。

問題：価格設定のニュアンス

このアーキテクチャは書き込みには完璧に機能していました...クライアントが歴史的データを求めてくるまでは。そのとき、私は基本的な矛盾に直面しました：

• システムは時間で書き込む：12:00のアーカイブにはcnn.com、google.com、shop.xyzの混合が含まれています。
• システムはドメインで読み取る：クライアントは「昨年のcnn.comのすべてのページを教えてください」と尋ねます。

ここに、この記事のきっかけとなった間違いがあります。多くのエンジニアと同様に、私はレイテンシ、IOPS、スループットについて考えることに慣れていました。しかし、AWS Glacierの課金モデルを見落としていました。

私は考えました：「まあ、数千のアーカイブを取得するのは遅い（48時間）けど、そんなに高くはないだろう」と。

現実：AWSはAPIコールだけでなく、復元されたデータの量（取得したGBあたりの$）に対しても課金します。

「ゴールデンバイト」効果

クライアントが単一ドメインから1,000ページをリクエストすると想像してください。書き込みロジックが時系列だったため、これらのページは1,000の異なるTARアーカイブに分散している可能性があります。

クライアントにこの50 MBの有用なデータを提供するために、災害が発生します：

1. システムは1,000のアーカイブの復元をトリガーする必要があります。
2. 「冷凍庫」から300 GBのデータを取り出します（1,000アーカイブ × 300 MB）。
3. AWSは300 GBの復元に対して請求します。
4. 必要な50 MBを抽出し、残りの299.95 GBを捨てます🤯。

私たちは金の粒を抽出するためだけに、テラバイト単位のゴミを復元するために支払っていました。これは財政的なブラックホールに変わった古典的なデータ局所性の問題でした。

パート2：間違いを修正する：再配置パイプライン

取り込み方法をすぐに変更することはできませんでした—入力ストリームはあまりにも並列で大規模なため、「オンザフライ」でソートすることはできません（それに取り組んでいますが）。また、すでにアーカイブされたデータにも対応するソリューションが必要でした。

そこで、アーカイブを「デフラグメント」するバックグラウンドプロセスである再配置パイプラインを設計しました。

これは非同期ETL（抽出、変換、ロード）プロセスで、いくつかの重要なコアコンポーネントがあります：

1. 選択：クライアントが要求していないデータをソートすることは意味がありません。したがって、すべての新しいデータをパイプラインに送るとともに、クライアントが特に復元を要求したデータも送ります。最初の取得には過剰に支払いますが、2回目は発生しません。

   \

2. シャッフリング（グループ化）：複数のワーカーが並列で未ソートのファイルをダウンロードし、ドメインごとにバッファを整理します。システムは非同期なので、入力ストリームがメモリをオーバーロードすることを心配する必要はありません。ワーカーは自分のペースで負荷を処理します。

   \

3. 書き直し：ソートされたファイルを新しいプレフィックスの下でS3に書き戻します（ソートされたファイルと生のファイルを区別するため）。

• 変更前：2024/05/05/random_id_ts.tar→[cnn, google, zara, cnn]
• 変更後：2024/05/05/cnn/random_id_ts.tar→[cnn, cnn, cnn...]

1. メタデータスワップ：Snowflakeでは、メタデータテーブルは追記専用です。MERGE INTOやUPDATEを行うことは非常にコストがかかります。

• 解決策：特定の日のすべてのレコードを取得し、JOINを使用して別のテーブルに書き込み、元の日のレコードを削除し、修正されたレコードで1日分全体を再挿入する方が効率的であることがわかりました。4X-Large Snowflakeウェアハウスで、わずか数時間で300日以上と1600億以上のUPDATE操作を処理することができました。

結果

この変更により、製品の経済性が根本的に変わりました：

• ピンポイントの精度：今では、クライアントがcnn.comを要求すると、システムはcnn.comが存在するデータのみを復元します。
• 効率性：リクエストの粒度（ドメイン全体vs正規表現による特定のURL）に応じて、「ゴミデータ」の取得を10%から80%削減することができました（これはコストに直接比例します）。
• 新しい機能：ダンプでお金を節約するだけでなく、全く新しいビジネスユースケースが解禁されました。歴史的データの取得が苦痛なほど高価ではなくなったため、AIモデルのトレーニング、長期的な市場調査、エージェントAIシステムが推論するための知識ベースの構築（特化した検索エンジンを考えてください）のために大規模なデータセットを抽出することができるようになりました。以前は財政的な自殺ミッションだったものが、今では標準的な操作になりました。

採用中です

Bright DataはWebアーカイブをさらに拡大しています。あなたが以下を楽しむなら：

• 高スループットの分散型システム、
• 大規模なデータエンジニアリング、
• 実世界の負荷の下で信頼性の高いパイプラインを構築すること、
• Node.jsを限界まで押し上げること、
• 教科書には載っていない問題を解決すること...

ぜひお話ししましょう。

次世代のWebアーカイブの構築を支援する強力なNode.jsエンジニアを募集しています。データエンジニアリングとETLの経験があると非常に有利です。お気軽に履歴書をvadimr@brightdata.comまでお送りください。

アーカイブの拡大を続けながら—そして新しい創造的な方法でそれを壊し続けながら—さらなる更新が来る予定です！

\