Создание веб-архива петабайтного масштаба

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

Обычно жертвуют одним ради другого. Но в нашем случае, работая с петабайтами данных в 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 всего за несколько часов на хранилище Snowflake 4X-Large.

Результат

Это изменение радикально изменило экономику продукта:

• Точность: Теперь, когда клиент запрашивает cnn.com, система восстанавливает только те данные, где находится cnn.com.
• Эффективность: В зависимости от детализации запроса (весь домен или конкретные URL через регулярные выражения), я достиг сокращения на 10-80% в извлечении "мусорных данных" (что прямо пропорционально стоимости).
• Новые возможности: Помимо экономии денег на дампах, это открыло совершенно новые бизнес-кейсы. Поскольку извлечение исторических данных больше не является мучительно дорогим, мы теперь можем позволить себе извлекать массивные наборы данных для обучения моделей ИИ, проведения долгосрочных маркетинговых исследований и создания баз знаний для агентных систем ИИ для рассуждений (представьте специализированные поисковые системы). То, что раньше было финансовой миссией самоубийства, теперь стандартная операция.

Мы нанимаем

Bright Data масштабирует Веб-архив еще дальше. Если вам нравится:

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

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

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

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

\