Внутри S3

Отличный доклад от инженеров из Яндекса о том, как у них устроено хранилище S3. А для любителей послушать — есть запись доклада с конференции.

Это интересно, потому что внутри хранилища Яндекса лежит огромное количество файлов, и точно найдутся разные неудобные паттерны доступа и нагрузки от клиентов. Поэтому разработчики S3 набили много шишек, которыми и поделились в докладе.

⭐️ Интересные идеи

➡️ Инженеры Яндекса разработали свой сервис для работы напрямую с жёсткими дисками. Он держит более 1,000,000 RPS и работает с триллионами файлов. Про него есть отдельный доклад, который я позже обязательно посмотрю и напишу обзор. Для особо любопытных — вот ссылка.

➡️ В схему работы сразу заложено динамическое шардирование. Статика не подходит по совершенно понятной причине — добавлять бакеты будет очень сложно, а файловое хранилище точно будет быстро расти.

➡️ Фоном работают несколько процессов: mover перетаскивает чанки между бакетами, splitter делит жирные чанки на более мелкие. Процессы блокируют чанк на запись, но работают единицы секунд, поэтому негативное влияние на клиента незначительно.

➡️ Для многих внутренних процессов важно корректно вычислять счётчики (тот же расчёт квот), но при подсчёте «в лоб» они обычно страдают от конкурентности. Решением стала очередь счётчиков: каждое изменение складывается в специальную очередь, которую разгребает фоновый процесс. Этот же процесс используется для биллинга, потому что видит все изменения в бакетах.

➡️ Паттерны клиентской записи по timestamp и алфавиту неудобны для S3, потому что грузят один шард вместо распределения нагрузки на все шарды равномерно. Решение — вместо ключей использовать их хэши, что помогает избавиться от перегрева одного шарда.

Приятного чтения!

#highload@tech_fit
➖➖➖➖➖➖➖➖➖➖➖
// Понравился пост? Ставь 💛
// И обязательно подпишись на канал, чтобы не пропустить новые статьи