Документ описывает архитектуру хранения и отдачи фотографий в платформе Badoo, обслуживающей 330 миллионов пользователей и обрабатывающей 3,5 миллиона новых фотографий ежедневно. Освещаются проблемы, такие как ограниченная вместимость и необходимость кэширования, а также предлагаются решения, которые включают использование системы хранения данных и алгоритмов распределения запросов. Также рассматриваются итоги по отказоустойчивости и эффективности кэширования, с высоким уровнем попаданий в кэш.

1. Архитектура хранения и отдачи
фотографий в Badoo
Артем Денисов, Badoo

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

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

4. Тривиальный пример
photos1
photos2
photosN

5. Тривиальный пример
place_id
place_id: 1..5
place_id: 6..11
place_id: m..n
photos1
photos2
photosN

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

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

8. ! Ограниченная вместимость
Тривиальный пример: проблемы

9. ! Ограниченная вместимость
! Нетипичная конфигурация машин
Тривиальный пример: проблемы

10. ! Ограниченная вместимость
! Нетипичная конфигурация машин
! Цена
Тривиальный пример: проблемы

11. Используем систему хранения данных
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)

12. ! Меньше $/Gb
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)
Используем систему хранения данных

13. ! Меньше $/Gb
! Больше плотность размещения
bphotos2
bphotosN
Storage Area Network
(SAN)
bphotos1
Используем систему хранения данных

14. ! Меньше $/Gb
! Больше плотность размещения
! Быстрая деградация чтения (>500 rps per host)
bphotos2
bphotosN
Storage Area Network
(SAN)
bphotos1
Используем систему хранения данных

15. Характер нагрузки
Чтение преобладает над записью:
7*109 reads / 3.5*106 writes per day

16. Характер нагрузки
Горячий dataset небольшой
Чтение преобладает над записью:
7*109 reads / 3.5*106 writes per day

17. Характер нагрузки
Горячий dataset небольшой
Кажется, нам нужен кэш с LRU
Чтение преобладает над записью:
7*109 reads / 3.5*106 writes per day

18. Кэширование
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)
photoscache1
photoscacheN

19. Структура фотокэша
bphotos

20. Структура фотокэша
bphotos
Local cache

21. Структура фотокэша
Local cache
proxy_pass
proxy_store bphotos

22. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
proxy_pass
proxy_store bphotos

23. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos

24. Структура фотокэша
Local cache
Buffer
Hot cache
Cold cache
Access log
<photo_path>
<served_by>
proxy_pass
proxy_store bphotos
Cache manager daemon

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

29. Как распределять запросы?
photoscache2
photoscache1
photoscache3

30. Как распределять запросы?
Round-robin?
photoscache2
photoscache1
photoscache3

31. Как распределять запросы?
Round-robin?
Hash % count?
photoscache2
photoscache1
photoscache3

32. Как распределять запросы?
Round-robin?
Hash % count?
hash(“example_url”) = 5
server_idx0 = 5 % 3 = 2photoscache2
photoscache1
photoscache3

33. Как распределять запросы?
Round-robin?
Hash % count?
hash(“example_url”) = 5
server_idx0 = 5 % 3 = 2
server_idx1 = 5 % 4 = 1

34. Как распределять запросы?
photoscache2
photoscache1
photoscache3
Round-robin?
Hash % count?

35. Как распределять запросы?
Round-robin?
Hash % count?
Consistent hashing?photoscache2
photoscache1
photoscache3

36. Consistent hashing
0
hash(sharding_key)

37. Consistent hashing
0
hash(sharding_key)

38. Consistent hashing
0
hash(sharding_key)
A

39. Consistent hashing
0
hash(sharding_key)
B
A

40. Consistent hashing
0
hash(sharding_key)
B
A
C

41. Consistent hashing
0
hash(sharding_key)
B
A
C

42. Consistent hashing
0
hash(sharding_key)
B
A
C
B
A
C

43. Резервный фотокэш
photoscache1
bphotos
photoscache2
photoscache3
photoscache4
(reserve)
Load balancer

44. Резервный фотокэш
photoscache1
Load balancer
photoscache2
photoscache3
photoscache4
(reserve)
bphotos

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

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

47. Кэширование. Результаты
- Hitrate (количество попаданий в кэш) 98%
- Из 80k только 1600 rps доходят до bphotos
- 3 точки присутствия (Прага, Майами, Гонконг)
+
- Поддержка webp, progressive jpeg
- Динамический resize/crop
- Динамические вотермарки, фильтры (blur, pixelize)

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

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

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

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

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

53. Хранение. 2013 год
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)
photoscache1
photoscacheN

54. Хранение. 2013 год
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)
photoscache1
photoscacheN
80 x bphotos = ~560Tb данных
40 x photoscache
X 2 ДЦ

55. Хранение. 2013 год
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)
photoscache1
photoscacheN
1 x POINT OF FAILURE

56. Хранение. 2013 год
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)
photoscache1
photoscacheN
2 x POINT OF FAILURE

57. Хранение. 2013 год
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)
photoscache1
photoscacheN
3 x POINT OF FAILURE

58. Хранение. 2013 год
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)
photoscache1
photoscacheN
3 x POINT OF FAILURE
! MAINTENANCE

59. Хранение. 2013 год
bphotos1
bphotos2
bphotosN
Storage Area Network
(SAN)
photoscache1
photoscacheN
3 x POINT OF FAILURE ! DATA LOSS
! MAINTENANCE

60. Резервирование v.1
bphotos
Main partition
Local FS Fiber
Storage Area Network

61. bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Резервирование v.1

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

67. Dphotos
Async queue
bphotos
Local FS
Main partition
Backup partition
Fiber
Storage Area Network
Fiber
Storage Area Network
Buffer partition

68. Dphotos
Async queue
bphotos
Local FS
Main partition
Backup partition
Buffer partition

69. Dphotos
Async queue
bphotos
Local FS
Main partition
Backup partition
Buffer partition

70. Dphotos
dphotosN
Buffer partition
Main partition
dphotosN+1
Buffer partition
Main partition

71. Dphotos
dphotosN
Async queue
Buffer partition
Main partition
dphotosN+1
Buffer partition
Main partition

72. Dphotos. Upload
Async queue
dphotosN
dphotosN+1Round robin + health checks
Load balancer

73. Dphotos. Отдача
photoscache
Async queue
dphotosN
dphotosN+1Round robin + health checks

74. Dphotos. Отдача
photoscache
Async queue
dphotosN
dphotosN+1
HIT
Round robin + health checks

75. Dphotos. Отдача
Async queue
dphotosN
dphotosN+1
MISS
Round robin + health checks
photoscache

76. Dphotos. Отдача
Async queue
dphotosN
dphotosN+1
MISS
Round robin + health checks
photoscache

77. Dphotos. Отказоустойчивость
dphotosN
Async queue
Buffer partition
Main partition
dphotosN+1
Buffer partition
Main partition

78. Dphotos. Отказоустойчивость
dphotosN
Async queue
Buffer partition
Main partition
dphotosN+1
Buffer partition
Main partition

79. Dphotos. Отказоустойчивость
dphotosN
Async queue
Buffer partition
Main partition
dphotosN+1
Buffer partition
Main partition

80. Dphotos. Отказоустойчивость
dphotosN
Async queue
Buffer partition
Main partition
dphotosN+1
Buffer partition
Main partition

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

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

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

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

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

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

87. Dphotos. Результаты
- Отказоустойчивость
- Простая эксплуатация
- Двойной запас по чтению
- Сложность разработки
Так хранить локально — это хорошо или плохо?
- Проще в эксплуатации
- Производительнее
- В 1.5 раза дороже, чем SAN

88. Итоги

89. Итоги

90. Итоги
photoscache

91. Итоги
photoscache
CDN

92. Итоги
photoscache dphotos
CDN Storage layer

93. Итоги
photoscache dphotos
CDN Storage layer
Local drives

94. Итоги
photoscache dphotos
Storage Area Network
CDN Storage layer
Local drives

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

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 на лету
- Инкрементальные асинхронные бэкапы - это хорошо
- Если что-то может сломаться - оно сломается