Membangun Arsip Web Skala Petabyte

Dalam dunia ideal seorang insinyur, arsitektur selalu indah. Dalam dunia nyata sistem skala tinggi, Anda harus membuat kompromi. Salah satu masalah mendasar yang harus dipikirkan insinyur sejak awal adalah pertukaran sengit antara Kecepatan Menulis dan Kecepatan Membaca.

Biasanya, Anda mengorbankan satu untuk yang lain. Tetapi dalam kasus kami, bekerja dengan petabyte data di AWS, kompromi ini tidak menghantam kecepatan kami–melainkan dompet kami.

Kami membangun sistem yang menulis data dengan sempurna, tetapi setiap kali membaca dari arsip, sistem ini menghabiskan anggaran dengan cara yang paling menyakitkan yang bisa dibayangkan. Bagaimanapun, membaca petabyte dari AWS membutuhkan biaya untuk transfer data, jumlah permintaan, dan pengambilan kelas penyimpanan... Banyak uang!

Ini adalah kisah tentang bagaimana kami mengoptimalkannya untuk membuatnya lebih efisien dan hemat biaya!

Bagian 0: Bagaimana Kami Berakhir Menghabiskan $100.000 dalam Biaya AWS!

Kisah nyata: beberapa bulan yang lalu, salah satu arsitek solusi kami ingin mengambil sampel ekspor dari situs web langka dengan lalu lintas rendah untuk mendemonstrasikan produk kepada calon klien. Karena bug di API, batas keamanan pada jumlah file tidak diterapkan.

Karena data untuk situs "langka" ini tersebar di jutaan arsip bersama dengan situs-situs berlalu lintas tinggi, sistem mencoba memulihkan hampir setengah dari seluruh penyimpanan historis kami untuk menemukan beberapa halaman tersebut.

Kesalahan jujur itu akhirnya menghabiskan biaya hampir $100.000 dalam biaya AWS!

Sekarang, saya segera memperbaiki bug API (dan menambahkan batasan ketat), tetapi kerentanan arsitektur tetap ada. Itu adalah bom waktu...

Izinkan saya menceritakan kisah arsitektur Web Archive Bright Data: bagaimana saya mengarahkan sistem ke dalam jebakan penyimpanan "murah" dan bagaimana saya keluar menggunakan Pipeline Pengaturan Ulang.

Bagian 1: Warisan "Tulis-Dulu"

Ketika saya mulai bekerja pada Web Archive, sistem sudah menelan aliran data yang besar: jutaan permintaan per menit, puluhan terabyte per hari. Arsitektur dasar dibangun dengan tujuan utama: menangkap semuanya tanpa kehilangan data.

Ini mengandalkan strategi paling tahan lama untuk sistem throughput tinggi: Log Append-only.

1. Data (HTML, JSON) di-buffer.
2. Setelah buffer mencapai ~300 MB, data "disegel" ke dalam arsip TAR.
3. Arsip terbang ke S3.
4. Setelah 3 hari, file dipindahkan ke S3 Glacier Deep Archive.

Untuk fase ingesti, desain ini sempurna. Menyimpan data di Deep Archive hanya membutuhkan biaya recehan, dan throughput penulisan praktis tidak terbatas.

Masalahnya: Nuansa Harga Itu

Arsitektur bekerja sempurna untuk penulisan... sampai klien datang meminta data historis. Saat itulah saya menghadapi kontradiksi mendasar:

• Sistem Menulis berdasarkan Waktu: Arsip dari pukul 12:00 berisi campuran cnn.com, google.com, dan shop.xyz.
• Sistem Membaca berdasarkan Domain: Klien bertanya: "Berikan saya semua halaman dari cnn.com selama setahun terakhir."

Di sinilah letak kesalahan yang menginspirasi artikel ini. Seperti banyak insinyur, saya terbiasa berpikir tentang latensi, IOPS, dan throughput. Tetapi saya mengabaikan model penagihan AWS Glacier.

Saya berpikir: "Yah, mengambil beberapa ribu arsip memang lambat (48 jam), tetapi tidak terlalu mahal."

Kenyataannya: AWS menagih tidak hanya untuk panggilan API, tetapi juga untuk volume data yang dipulihkan ($ per GB yang diambil).

Efek "Byte Emas"

Bayangkan klien meminta 1.000 halaman dari satu domain. Karena logika penulisan bersifat kronologis, halaman-halaman ini bisa tersebar di 1.000 arsip TAR yang berbeda.

Untuk memberikan klien 50 MB data yang berguna, terjadilah bencana:

1. Sistem harus memicu Restore untuk 1.000 arsip.
2. Sistem mengangkat 300 GB data dari "freezer" (1.000 arsip × 300 MB).
3. AWS menagih kami untuk memulihkan 300 GB.
4. Saya mengekstrak 50 MB yang diperlukan dan membuang 299,95 GB lainnya 🤯.

Kami membayar untuk memulihkan terabyte sampah hanya untuk mengekstrak butiran emas. Ini adalah masalah klasik Lokalitas Data yang berubah menjadi lubang hitam finansial.

Bagian 2: Memperbaiki Kesalahan: Pipeline Pengaturan Ulang

Saya tidak bisa dengan cepat mengubah metode ingesti–aliran masuk terlalu paralel dan besar untuk diurutkan "secara langsung" (meskipun saya sedang mengerjakan itu), dan saya membutuhkan solusi yang juga berfungsi untuk data yang sudah diarsipkan.

Jadi, saya merancang Pipeline Pengaturan Ulang, proses latar belakang yang "mendefragmentasi" arsip.

Ini adalah proses ETL (Extract, Transform, Load) asinkron, dengan beberapa komponen inti penting:

1. Seleksi: Tidak masuk akal untuk mengurutkan data yang tidak diminta klien. Oleh karena itu, saya mengarahkan semua data baru ke dalam pipeline, serta data yang secara khusus diminta klien untuk dipulihkan. Kami membayar lebih untuk pengambilan pertama kali, tetapi tidak pernah terjadi kedua kalinya.

   \

2. Pengacakan (Pengelompokan): Beberapa pekerja mengunduh file yang tidak diurutkan secara paralel dan mengatur buffer berdasarkan domain. Karena sistem bersifat asinkron, saya tidak khawatir aliran masuk akan membebani memori. Para pekerja menangani beban dengan kecepatan mereka sendiri.

   \

3. Penulisan Ulang: Saya menulis file yang diurutkan kembali ke S3 di bawah awalan baru (untuk membedakan file yang diurutkan dari yang mentah).

• Sebelum: 2024/05/05/random_id_ts.tar → [cnn, google, zara, cnn]
• Sesudah: 2024/05/05/cnn/random_id_ts.tar → [cnn, cnn, cnn...]

1. Pertukaran Metadata: Di Snowflake, tabel metadata hanya bisa ditambahkan. Melakukan MERGE INTO atau UPDATE sangat mahal.

• Solusinya: Saya menemukan bahwa jauh lebih efisien untuk mengambil semua catatan untuk hari tertentu, menuliskannya ke tabel terpisah menggunakan JOIN, menghapus catatan hari asli, dan memasukkan kembali seluruh hari dengan catatan yang dimodifikasi. Saya berhasil memproses 300+ hari dan 160+ miliar operasi UPDATE hanya dalam beberapa jam pada gudang Snowflake 4X-Large.

Hasilnya

Perubahan ini secara radikal mengubah ekonomi produk:

• Akurasi Tepat: Sekarang, ketika klien meminta cnn.com, sistem hanya memulihkan data di mana cnn.com berada.
• Efisiensi: Tergantung pada granularitas permintaan (seluruh domain vs URL spesifik melalui regex), saya mencapai pengurangan 10% hingga 80% dalam pengambilan "data sampah" (yang berbanding lurus dengan biaya).
• Kemampuan Baru: Selain menghemat uang untuk dump, ini membuka kasus penggunaan bisnis yang sama sekali baru. Karena mengambil data historis tidak lagi mahal secara menyakitkan, kini kami mampu mengekstrak dataset besar untuk melatih model AI, melakukan riset pasar jangka panjang, dan membangun basis pengetahuan untuk sistem AI agentic untuk bernalar (pikirkan mesin pencari khusus). Apa yang sebelumnya merupakan misi bunuh diri finansial kini menjadi operasi standar.

Kami Sedang Merekrut

Bright Data sedang menskalakan Web Archive lebih jauh lagi. Jika Anda menikmati:

• Sistem terdistribusi throughput tinggi,
• Rekayasa data pada skala besar,
• Membangun pipeline andal di bawah beban dunia nyata,
• Mendorong Node.js hingga batas absolutnya,
• Memecahkan masalah yang tidak muncul di buku teks…

Maka saya ingin berbicara dengan Anda.

Kami merekrut insinyur Node.js yang kuat untuk membantu membangun generasi berikutnya dari Web Archive. Memiliki pengalaman rekayasa data dan ETL sangat menguntungkan. Jangan ragu untuk mengirimkan CV Anda ke [email protected].

Update lebih lanjut akan datang saat saya terus menskalakan arsip—dan saat saya terus menemukan cara-cara baru dan kreatif untuk merusaknya!

\