Highload2016
"Архитектура хранения и отдачи фотографий в Badoo", Артём Денисов
В докладе будет рассмотрен процесс построения масштабируемой отказоустойчивой системы хранения, отдачи и обработки фотографий с точки зрения разработчика.
На примере Badoo, я расскажу о стандартном пути эволюции такого рода проектов. Детально разберу каждый этап и остановлюсь на основных сложностях и неочевидных проблемах.
Вместе с рассказом о наших решениях и подходах будут рассмотрены возможные альтернативы, их плюсы и минусы (вплоть до "мы небольшой стартап, как сделать что-нибудь похожее, но по-быстрому и на коленке").
Основные тезисы:
- Эволюция и типичные узкие места каждого из 3-х компонентов системы (хранение, отдача, обработка).
- Как отдавать фотографии? Когда лучше использовать сторонний CDN, а когда написать свой?
- Что лучше - хранить оригинал фото и ресайзить его на лету или заранее нарезать типовые размеры?
- Как сделать эффективное кэширование? Что такое consistent hashing и зачем он нужен?
- Где лучше хранить фотографии? Локальные диски, облачные хранилища, кластерные ФС?
- Надо ли их бэкапить и как часто? Что может пойти не так?
13. ! Меньше $/Gb
! Больше плотность размещения
bphotos2
bphotosN
Storage Area Network
(SAN)
bphotos1
Используем систему хранения данных
14. ! Меньше $/Gb
! Больше плотность размещения
! Быстрая деградация чтения (>500 rps per host)
bphotos2
bphotosN
Storage Area Network
(SAN)
bphotos1
Используем систему хранения данных
25. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos
Cache manager daemon
Хранит статистику запросов по файлам
26. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos
Cache manager daemon
Хранит статистику запросов по файлам
Часто запрашиваемые -> Hot cache
27. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos
Cache manager daemon
Хранит статистику запросов по файлам
Часто запрашиваемые -> Hot cache
Редко запрашиваемые -> Cold cache
28. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos
Cache manager daemon
Хранит статистику запросов по файлам
Часто запрашиваемые -> Hot cache
Редко запрашиваемые -> Cold cache
Постепенно удаляет из Cold cache
46. Кэширование. Результаты
- Hitrate (количество попаданий в кэш) 98%
- Из 80k только 1600 rps доходят до bphotos
- 3 точки присутствия (Прага, Майами, Гонконг)
47. Кэширование. Результаты
- Hitrate (количество попаданий в кэш) 98%
- Из 80k только 1600 rps доходят до bphotos
- 3 точки присутствия (Прага, Майами, Гонконг)
+
- Поддержка webp, progressive jpeg
- Динамический resize/crop
- Динамические вотермарки, фильтры (blur, pixelize)
49. Почему не CDN?
- Хочется больше контроля и предсказуемости
- Система развивалась постепенно
50. Почему не CDN?
- Хочется больше контроля и предсказуемости
- Система развивалась постепенно
- Много специфической логики на фотокэшах
51. Почему не CDN?
- Хочется больше контроля и предсказуемости
- Система развивалась постепенно
- Много специфической логики на фотокэшах
- Невысокая сложность поддержки итогового решения
52. Почему не CDN?
- Хочется больше контроля и предсказуемости
- Система развивалась постепенно
- Много специфической логики на фотокэшах
- Невысокая сложность поддержки итогового решения
Современный CDN — хорошая альтернатива в условиях
дефицита ресурсов и времени
62. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Резервирование v.1
63. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Buffer partition
Резервирование v.1
64. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Buffer partition
! NO DATA LOSS
Резервирование v.1
65. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Buffer partition
! NO DATA LOSS
! POINT OF FAILURE
Резервирование v.1
66. Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Buffer partition
! NO DATA LOSS
! POINT OF FAILURE
! MAINTENANCE
Резервирование v.1
85. Dphotos. Результаты
- Отказоустойчивость
- Простая эксплуатация
- Двойной запас по чтению
- Сложность разработки
Так хранить локально — это хорошо или плохо?
- Проще в эксплуатации
86. Dphotos. Результаты
- Отказоустойчивость
- Простая эксплуатация
- Двойной запас по чтению
- Сложность разработки
Так хранить локально — это хорошо или плохо?
- Проще в эксплуатации
- Производительнее
87. Dphotos. Результаты
- Отказоустойчивость
- Простая эксплуатация
- Двойной запас по чтению
- Сложность разработки
Так хранить локально — это хорошо или плохо?
- Проще в эксплуатации
- Производительнее
- В 1.5 раза дороже, чем SAN
96. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
97. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
98. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
- Immutable фотки
99. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
- Immutable фотки
- Resize на лету
100. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
- Immutable фотки
- Resize на лету
- Инкрементальные асинхронные бэкапы - это хорошо
101. Итоги
- А надо ли улучшать? Сначала измерь http://pinba.org
- Чтение -> кэш
- Запись -> шардинг
- Immutable фотки
- Resize на лету
- Инкрементальные асинхронные бэкапы - это хорошо
- Если что-то может сломаться - оно сломается