Створення веб-архіву петабайтного масштабу

В ідеальному світі інженера архітектура завжди прекрасна. У реальному світі високомасштабних систем доводиться йти на компроміси. Одна з фундаментальних проблем, про яку інженер повинен думати з самого початку, це жорсткий компроміс між швидкістю запису та швидкістю читання.

Зазвичай ви жертвуєте одним заради іншого. Але в нашому випадку, працюючи з петабайтами даних в AWS, цей компроміс вдарив не по швидкості, а по гаманцю.

Ми створили систему, яка ідеально записувала дані, але кожного разу, коли вона читала з архіву, вона спалювала бюджет найболючішим способом, який тільки можна уявити. Зрештою, читання петабайтів з AWS коштує грошей за передачу даних, кількість запитів та отримання даних зі сховища... Багато грошей!

Це історія про те, як ми оптимізували систему, щоб зробити її ефективнішою та економічно вигіднішою!

Частина 0: Як ми витратили $100 000 на комісії AWS!

Реальна історія: кілька місяців тому один з наших архітекторів рішень хотів отримати зразок експорту з рідкісного, малотрафікового веб-сайту, щоб продемонструвати продукт потенційному клієнту. Через помилку в API не було застосовано обмеження безпеки на кількість файлів.

Оскільки дані для цього "рідкісного" сайту були розкидані по мільйонах архівів разом із сайтами з високим трафіком, система намагалася відновити майже половину всього нашого історичного сховища, щоб знайти ці кілька сторінок.

Ця чесна помилка коштувала нам майже $100 000 комісій AWS!

Я негайно виправив помилку API (і додав суворі обмеження), але архітектурна вразливість залишилася. Це була бомба уповільненої дії...

Дозвольте мені розповісти історію архітектури Веб-архіву Bright Data: як я загнав систему в пастку "дешевого" сховища і як я вибрався з неї за допомогою Конвеєра перебудови.

Частина 1: Спадщина "Спочатку запис"

Коли я почав працювати над Веб-архівом, система вже поглинала масивний потік даних: мільйони запитів на хвилину, десятки терабайтів на день. Фундаментальна архітектура була побудована з основною метою: захопити все без втрати даних.

Вона спиралася на найбільш надійну стратегію для високопродуктивних систем: Журнал лише для додавання.

1. Дані (HTML, JSON) буферизуються.
2. Коли буфер досягає ~300 МБ, він "запечатується" в 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, але й за обсяг відновлених даних ($ за ГБ отриманих даних).

Ефект "Золотого байта"

Уявіть, що клієнт запитує 1 000 сторінок з одного домену. Оскільки логіка запису була хронологічною, ці сторінки можуть бути розкидані по 1 000 різних TAR-архівів.

Щоб надати клієнту ці 50 МБ корисних даних, відбувається катастрофа:

1. Система повинна ініціювати відновлення для 1 000 архівів.
2. Вона піднімає 300 ГБ даних з "морозильної камери" (1 000 архівів × 300 МБ).
3. AWS виставляє нам рахунок за відновлення 300 ГБ.
4. Я витягую необхідні 50 МБ і викидаю інші 299,95 ГБ 🤯.

Ми платили за відновлення терабайтів сміття лише для того, щоб витягти крупинки золота. Це була класична проблема локальності даних, яка перетворилася на фінансову чорну діру.

Частина 2: Виправлення помилки: Конвеєр перебудови

Я не міг швидко змінити метод поглинання – вхідний потік занадто паралельний і масивний, щоб сортувати "на льоту" (хоча я працюю над цим), і мені потрібне було рішення, яке працювало б і для вже архівованих даних.

Тому я розробив Конвеєр перебудови, фоновий процес, який "дефрагментує" архів.

Це асинхронний ETL-процес (Extract, Transform, Load) з кількома критичними основними компонентами:

1. Вибір: Немає сенсу сортувати дані, які клієнти не запитують. Тому я направляю всі нові дані в конвеєр, а також дані, які клієнти спеціально просили відновити. Ми переплачуємо за отримання перший раз, але це ніколи не відбувається вдруге.

   \

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, видалити оригінальні записи дня та вставити весь день назад із зміненими записами. Мені вдалося обробити 300+ днів та 160+ мільярдів операцій UPDATE всього за кілька годин на 4X-Large сховищі Snowflake.

Результат

Ця зміна радикально змінила економіку продукту:

• Точність: Тепер, коли клієнт запитує cnn.com, система відновлює лише дані, де живе cnn.com.
• Ефективність: Залежно від деталізації запиту (весь домен проти конкретних URL-адрес через регулярні вирази), я досяг зменшення на 10-80% у отриманні "сміттєвих даних" (що прямо пропорційно вартості).
• Нові можливості: Крім економії грошей на дампах, це відкрило абсолютно нові бізнес-випадки. Оскільки отримання історичних даних більше не є болісно дорогим, ми тепер можемо дозволити собі витягувати масивні набори даних для навчання моделей ШІ, проведення довгострокових маркетингових досліджень та створення баз знань для агентних систем ШІ для міркування (подумайте про спеціалізовані пошукові системи). Те, що раніше було фінансовою місією самогубства, тепер є стандартною операцією.

Ми наймаємо

Bright Data масштабує Веб-архів ще більше. Якщо вам подобається:

• Високопродуктивні розподілені системи,
• Інженерія даних у масовому масштабі,
• Створення надійних конвеєрів під реальним навантаженням,
• Доведення Node.js до абсолютних меж,
• Вирішення проблем, які не з'являються в підручниках...

Тоді я був би радий поговорити.

Ми наймаємо сильних інженерів Node.js, щоб допомогти створити наступне покоління Веб-архіву. Наявність досвіду в інженерії даних та ETL є дуже корисною. Не соромтеся надсилати своє резюме на [email protected].

Більше оновлень з'явиться, коли я продовжу масштабувати архів — і коли я продовжу знаходити нові та творчі способи його зламати!

\