Архитектура хранения и отдачи фотографий в badoo

Архитектура хранения и отдачи фотографий в Badoo

Артем Денисов, Badoo

330 млн. пользователей3 Pb фотографий3,5 млн. новых фотографий в день80 тыс. запросов в секунду за фото

Тривиальный пример


photos1

photos2

photosN


place_id

place_id: 1..5

place_id: 6..11

place_id: m..n

photos1

photos2

photosN

Тривиальный пример: проблемы

! Ограниченная вместимость


! Ограниченная вместимость! Нетипичная конфигурация машин


! Ограниченная вместимость! Нетипичная конфигурация машин! Цена


Используем систему хранения данных

bphotos1

bphotos2

bphotosN Storage Area Network (SAN)

! Меньше $/Gb

bphotos1

bphotos2



! Меньше $/Gb! Больше плотность размещения

bphotos2


bphotos1


! Меньше $/Gb! Больше плотность размещения! Быстрая деградация чтения (>500 rps per host)

bphotos2


bphotos1


Характер нагрузки

Чтение преобладает над записью:

7*109 reads / 3.5*106 writes per day


Горячий dataset небольшой




Горячий dataset небольшойКажется, нам нужен кэш с LRU



Кэшированиеbphotos1

bphotos2


photoscache1

photoscacheN

Структура фотокэша

bphotos


bphotosLocal cache


Local cache

proxy_pass

proxy_store bphotos


Local cache

BufferHot cacheCold cache

proxy_pass

proxy_store bphotos


Local cache


Access log

<photo_path> <served_by>

proxy_pass

proxy_store bphotos


Local cache


Access log


proxy_pass

proxy_store bphotos

Cache manager daemon


Local cache


Access log


proxy_pass

proxy_store bphotos

Cache manager daemonХранит статистику запросов по файлам


Local cache


Access log


proxy_pass

proxy_store bphotos

Cache manager daemonХранит статистику запросов по файламЧасто запрашиваемые -> Hot cache


Local cache


Access log


proxy_pass

proxy_store bphotos

Cache manager daemonХранит статистику запросов по файламЧасто запрашиваемые -> Hot cacheРедко запрашиваемые -> Cold cache


Local cache


Access log


proxy_pass

proxy_store bphotos

Cache manager daemonХранит статистику запросов по файламЧасто запрашиваемые -> Hot cacheРедко запрашиваемые -> Cold cacheПостепенно удаляет из Cold cache

Как распределять запросы?

photoscache2

photoscache1

photoscache3


Round-robin?

photoscache2

photoscache1

photoscache3


Round-robin?Hash % count?

photoscache2

photoscache1

photoscache3


Round-robin?Hash % count?hash(“example_url”) = 5server_idx0 = 5 % 3 = 2photoscache2

photoscache1

photoscache3


Round-robin?Hash % count?hash(“example_url”) = 5server_idx0 = 5 % 3 = 2server_idx1 = 5 % 4 = 1


photoscache2

photoscache1

photoscache3

Round-robin?Hash % count?


Round-robin?Hash % count?Consistent hashing?photoscache2

photoscache1

photoscache3

Consistent hashing0

hash(sharding_key)

Consistent hashing0

hash(sharding_key)

A

Consistent hashing0

hash(sharding_key)

BA

Consistent hashing0

hash(sharding_key)

BA

C

Consistent hashing0

hash(sharding_key)

BA

C

BA

C

Резервный фотокэшphotoscache1

bphotos

photoscache2

photoscache3

photoscache4(reserve)

Load balancer

Резервный фотокэшphotoscache1

Load balancer

photoscache2

photoscache3

photoscache4(reserve)

bphotos

Кэширование. Результаты- Hitrate (количество попаданий в кэш) 98%- Из 80k только 1600 rps доходят до bphotos

Кэширование. Результаты- Hitrate (количество попаданий в кэш) 98%- Из 80k только 1600 rps доходят до bphotos- 3 точки присутствия (Прага, Майами, Гонконг)

Кэширование. Результаты- Hitrate (количество попаданий в кэш) 98%- Из 80k только 1600 rps доходят до bphotos- 3 точки присутствия (Прага, Майами, Гонконг)

+

- Поддержка webp, progressive jpeg- Динамический resize/crop- Динамические вотермарки, фильтры (blur, pixelize)

Почему не CDN?- Хочется больше контроля и предсказуемости

Почему не CDN?- Хочется больше контроля и предсказуемости- Система развивалась постепенно

Почему не CDN?- Хочется больше контроля и предсказуемости- Система развивалась постепенно- Много специфической логики на фотокэшах

Почему не CDN?- Хочется больше контроля и предсказуемости- Система развивалась постепенно- Много специфической логики на фотокэшах- Невысокая сложность поддержки итогового решения

Почему не CDN?- Хочется больше контроля и предсказуемости- Система развивалась постепенно- Много специфической логики на фотокэшах- Невысокая сложность поддержки итогового решения

Современный CDN — хорошая альтернатива в условиях дефицита ресурсов и времени

Хранение. 2013 годbphotos1

bphotos2


photoscache1

photoscacheN


bphotos2


photoscache1

photoscacheN

80 x bphotos = ~560Tb данных40 x photoscache

X 2 ДЦ


bphotos2


photoscache1

photoscacheN

1 x POINT OF FAILURE


bphotos2


photoscache1

photoscacheN



bphotos2


photoscache1

photoscacheN

3 x POINT OF FAILURE! MAINTENANCE


bphotos2


photoscache1

photoscacheN

3 x POINT OF FAILURE ! DATA LOSS! MAINTENANCE

Резервирование v.1

bphotos

Main partitionLocal FS Fiber

Storage Area Network

bphotos

Local FS

Main partition

Backup partitionFiber


Fiber



Async queue

bphotos

Local FS

Main partition



Fiber



Async queue

bphotos

Local FS

Main partition



Fiber

Storage Area NetworkBuffer partition


Async queue

bphotos

Local FS

Main partition



Fiber


! NO DATA LOSS


Async queue

bphotos

Local FS

Main partition



Fiber


! NO DATA LOSS! POINT OF FAILURE


Async queue

bphotos

Local FS

Main partition



Fiber


! NO DATA LOSS! POINT OF FAILURE! MAINTENANCE


Dphotos

Async queue

bphotos

Local FS

Main partition



Fiber


Dphotos

Async queue

bphotos

Local FS

Main partition

Backup partition

Buffer partition

Dphotos

dphotosN

Buffer partition

Main partition

dphotosN+1

Buffer partition

Main partition

Dphotos

dphotosN

Async queue

Buffer partition

Main partition

dphotosN+1

Buffer partition

Main partition

Dphotos. Upload

Async queue

dphotosN

dphotosN+1Round robin + health checks

Load balancer

Dphotos. Отдача

photoscache

Async queue

dphotosN

dphotosN+1Round robin + health checks


photoscache

Async queue

dphotosN

dphotosN+1

HIT

Round robin + health checks


Async queue

dphotosN

dphotosN+1

MISS

Round robin + health checks

photoscache

Dphotos. Отказоустойчивость

dphotosN

Async queue

Buffer partition

Main partition

dphotosN+1

Buffer partition

Main partition

Dphotos. Результаты- Отказоустойчивость

Dphotos. Результаты- Отказоустойчивость- Простая эксплуатация

Dphotos. Результаты- Отказоустойчивость- Простая эксплуатация- Двойной запас по чтению

Dphotos. Результаты- Отказоустойчивость- Простая эксплуатация- Двойной запас по чтению- Сложность разработки


Так хранить локально — это хорошо или плохо?- Проще в эксплуатации


Так хранить локально — это хорошо или плохо?- Проще в эксплуатации- Производительнее


Так хранить локально — это хорошо или плохо?- Проще в эксплуатации- Производительнее- В 1.5 раза дороже, чем SAN

Итоги

Итоги

photoscache

Итоги

photoscache

CDN

Итоги

photoscache dphotos

CDN Storage layer

Итоги

photoscache dphotos

CDN Storage layer

Local drives

Итоги

photoscache dphotos


CDN Storage layer

Local drives

Итоги

- А надо ли улучшать? Сначала измерь

Итоги

- А надо ли улучшать? Сначала измерь http://pinba.org

http://pinba.org/

Итоги

- А надо ли улучшать? Сначала измерь http://pinba.org- Чтение -> кэш- Запись -> шардинг

http://pinba.org/

Итоги

- А надо ли улучшать? Сначала измерь http://pinba.org- Чтение -> кэш- Запись -> шардинг- Immutable фотки

http://pinba.org/

Итоги

- А надо ли улучшать? Сначала измерь http://pinba.org- Чтение -> кэш- Запись -> шардинг- Immutable фотки- Resize на лету

http://pinba.org/

Итоги

- А надо ли улучшать? Сначала измерь http://pinba.org- Чтение -> кэш- Запись -> шардинг- Immutable фотки- Resize на лету- Инкрементальные асинхронные бэкапы - это хорошо

http://pinba.org/

Итоги

- А надо ли улучшать? Сначала измерь http://pinba.org- Чтение -> кэш- Запись -> шардинг- Immutable фотки- Resize на лету- Инкрементальные асинхронные бэкапы - это хорошо- Если что-то может сломаться - оно сломается

http://pinba.org/

Архитектура хранения и отдачи фотографий в badoo

Technology