Китайские товары: просто, дёшево, надёжно

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

Автор в докладе рассмотрит архитектуру текущего решения:
- как драматически уменьшить зависимость от внешнего API, которое ты не контролируешь;
- как не погибнуть при синхронизации данных;
- двойное кэширование и почему оно помогает работать быстро, надежно и стабильно;
- преимущества избыточной репликации данных и почему иногда дешевле поднять и переехать на новый кластер, чем пытаться оптимизировать старый;
- когда действительно нужна консистентность и почему иногда не стоит пытаться её достигать;
- за какими метриками нужно следить, чтобы не было “разрывов”.

Transcript

1. Китайские товары: просто, дёшево, надёжно Тарасов Александр
2. 2 Кто я?
3. Китайские товары: просто, дёшево, надёжно
4. Мнение докладчика может не совпадать с официальной позицией его работодателя, начальника, коллег или других специалистов. 
 Все представленные в докладе сведения, примеры, выводы и другую информацию вы можете использовать на свой страх и риск. За все ваши действия ответственность несёте только вы сами. 4 Минздрав предупреждает
5. 0| Вместо предисловия
6. 6 71 млн Посещают нас в месяц 5,5 млн Заходят в маркетплейс Одноклассники в цифрах 2 000 Принятых решений в секунду
7. 7 Китайские товары. Взгляд пользователя
8. 8 Одна платформа – много витрин
9. 9 Мы – одна из таких витрин
10. • Сервис внутри сервиса • Отдельный раздел с точки зрения пользователя • Отдельный сервис с точки зрения архитектуры 10 Китайские товары
11. • Сервис внутри сервиса • Отдельный раздел с точки зрения пользователя • Отдельный сервис с точки зрения архитектуры • Сторонние API • Логистика, информация о товарах • Покупка, оплата и т.д. 11 Китайские товары
12. • Экономичность • Надёжность • Простота 12 Принципы, которыми руководствовались
13. 13 Можно ли достичь всех трёх?
14. 1| Когда ты не контролируешь API
15. • Сторонний Mall Platform API • Мы не мастер-система • Как контролировать? 15 Что нас волнует?
16. 16 Как это могло было бы быть, но не стало Запросы 
 от пользователя Mall Platform Данные Web/Mobile
17. • Платформа недоступна/"тормозит" • Не можем купить • Не можем показать товары 17 Почему так не надо делать?
18. • Платформа недоступна/"тормозит" • Не можем купить • Не можем показать товары • Влияем на платформу • Много запросов в пиковые часы • DDoS-атаки 18 Почему так не надо делать?
19. • Платформа недоступна/"тормозит" • Не можем купить • Не можем показать товары • Влияем на платформу • Много запросов в пиковые часы • DDoS-атаки • Время ответа • Зависим от мощностей платформы • Ограничиваем себя в возможностях 19 Почему так не надо делать?
20. 20 Как это могло было бы быть, но тоже не стало Запросы 
 от пользователя OK Gateway Проксируем Данные Web/Mobile Mall Platform
21. 21 Как это могло было бы быть, но тоже не стало Запросы 
 от пользователя OK Gateway Проксируем Данные Web/Mobile Mall Platform
22. • Платформа недоступна/"тормозит" • Не можем купить • Не можем показать товары • Влияем на платформу • Много запросов в пиковые часы • DDOS-атаки • Время ответа • Зависим от мощностей платформы • Ограничиваем себя в возможностях 22 Причины те же
23. 23 А надо ли проксировать всё? Запросы 
 от пользователя OK Gateway Проксируем Данные Web/Mobile Mall Platform
24. 24 100% -> 1%
25. 25 Как это есть сейчас. Простая схема Запросы 
 от пользователя OK Mall Храним данные, проксируем 1% Процессинг заказов Web/Mobile Mall Platform
26. 26 Принципиальная архитектурная схема NewSQL Cassandra
27. 27 Graceful Degradation NewSQL Cassandra
28. 28 NewSQL Cassandra Graceful Degradation
29. NewSQL Cassandra 29 Graceful Degradation
30. • Минимизировали зависимость от внешнего API • Можем контролировать влияние на платформу • Можем реализовывать уникальные фичи • Повысили отказоустойчивость сервиса 30 Итоги #1
31. • Какие данные хранить? • Как эти данные хранить? • Как синхронизировать данные? 31 Какие вопросы надо решить?
32. 2| Хранение данных
33. • Данные для отображения витрины • Можем потерять • Но не очень хотим это делать • Данные заказов пользователей • Терять нельзя • Статистические данные • Нужно собрать и доставить в хранилище 33 Разные данные – разные требования
34. • Данные для отображения витрины • Embedded Cassandra без транзакций • Данные заказов пользователей • Общий NewSQL (C*One) • Статистические данные • Kafka + Hadoop • DWH 34 Храним данные наиболее эффективно https://habr.com/ru/company/odnoklassniki/blog/417593/
35. • Данные для отображения витрины • Embedded Cassandra без транзакций • Данные заказов пользователей • Общий NewSQL (C*One) • Статистические данные • Kafka + Hadoop • DWH 35 Храним данные наиболее эффективно
36. 36 Типичная витрина
37. • Что храним? • Информация о товарах (название, описание) • Варианты товаров (пары цвет-размер) • Рейтинги, отзывы 37 Данные для отображения витрины
38. • Что храним? • Информация о товарах (название, описание) • Варианты товаров (пары цвет-размер) • Рейтинги, отзывы с других фронтов • Требования • Можем потерять, но не очень хотим это делать • latency < 50 мс • Не менее 2 000 rps 38 Данные для отображения витрины
39. • Что храним? • Информация о товарах (название, описание) • Варианты товаров (пары цвет-размер) • Рейтинги, отзывы с других фронтов • Требования • Можем потерять, но не очень хотим это делать • latency < 50 мс • Не менее 2 000 rps • 98% всех запросов к сервису – запросы к витрине 39 Данные для отображения витрины
40. • Embedded Cassandra • Базируется на собственном форке • Три инстанса (replication factor = 3) • Key-Value-схема хранения данных • Без обратных индексов 40 Cassandra as a Persistent Cache https://www.youtube.com/watch?v=k2efjgRxMp8
41. • Embedded Cassandra • Базируется на собственном форке • Три инстанса (replication factor = 3) • Key-Value-схема хранения данных • Без обратных индексов • Capacity • > 100 млн. записей • TTL = пожизненно 41 Cassandra as a Persistent Cache
42. 42 Схема хранения данных в Cassandra DC1 DC2 DC3 • 8 vCPU • 12 GB Mem • 512 GB HDD
43. 43 Схема хранения данных в Cassandra DC1 DC2 DC3 • Replication Factor = 3 • Write -> Quorum • Read -> Local
44. 44 Схема хранения данных в Cassandra DC1 DC2 DC3 • Replication Factor = 3 • Write -> Quorum • Read -> Local
45. 45 Схема хранения данных в Cassandra DC1 DC2 DC3 • Replication Factor = 3 • Write -> Quorum • Read -> Local
46. 46 Простота менеджмента DC1 DC2 DC3 • Replication Factor = 3 • Write -> Quorum • Read -> Local
47. 47 Схема ввода нового кластера scp -r user@OLD:/data user@NEW:/data
48. 48 Схема ввода нового кластера
49. • Очень простая схема хранения данных • Очень простой менеджмент • Очень надёжно 49 Cплошные плюсы
50. 50 А хватит ли одной Кассандры?
51. • 2000 rps up to 1000 rows / 1 instance • Latency > 50ms 51 Хватит ли одной Кассандры?
52. • 2000 rps up to 1000 rows / 1 instance • Latency > 50ms • Ок для витрины – не ок для ленты 52 Хватит ли одной Кассандры?
53. • Добавить ещё нод • Шардинг • Увеличивать replication factor 53 Какие варианты?
54. • Добавить ещё нод • Шардинг • Увеличивать replication factor • Кэш • 99% запросов за “горячими” товарами • Можно не увеличивать количество инстансов 54 Какие варианты?
55. 55 Схема двойного кэширования Requests L1 Cache In-Memory L2 Cache Cassandra Client
56. • Off-Heap Map • Имплементацию можно найти в one-nio • Позволяет хранить десятки гигабайт без ущерба для Java Heap 56 In-Memory Cache
57. • Off-Heap Map • Имплементацию можно найти в one-nio • Позволяет хранить десятки гигабайт без ущерба для Java Heap • Shared Memory • Обеспечивает быстрый старт сервиса без потери данных 57 In-Memory Cache
58. • Off-Heap Map • Имплементацию можно найти в one-nio • Позволяет хранить десятки гигабайт без ущерба для Java Heap • Shared Memory • Обеспечивает быстрый старт сервиса без потери данных • Capacity • 10 млн. записей (10% от всей базы) • TTL = 24 часа 58 In-Memory Cache
59. 59 Как работает In-Memory Cache
60. 60 Консистентность кэша под угрозой
61. 61 Спасение в синхронизации при апдейтах Cassandra Mutation Listener
62. 62 Hit Rate > 99%
63. 63 Схема хранения данных в Cassandra DC1 DC2 DC3 • 8 vCPU • 12 GB Mem • 512 GB HDD • 32 GB Shared Memory
64. • Профиль работы определяет технические решения • Двойное кэширование – быстро и надёжно • Простота хранения – простота управления 64 Итоги #2
65. • Какие данные хранить? • Как эти данные хранить? • Как синхронизировать данные? 65 Какие вопросы надо решить?
66. 3| Синхронизация данных
67. • Большой импорт • Снапшот состояния внешней системы в виде набора JSON-файлов • Обновление более 16 млн. записей 67 Синхронизация данных
68. • Большой импорт • Снапшот состояния внешней системы в виде набора JSON-файлов • Обновление более 16 млн. записей • Event-Based-апдейты • Чтение новых событий из Kafka 68 Синхронизация данных
69. • Большой импорт • Снапшот состояния внешней системы в виде набора JSON-файлов • Обновление более 16 млн. записей • Event-Based-апдейты • Чтение новых событий из Kafka • Real-Time-апдейты • Актуализация данных через API перед покупкой товара 69 Синхронизация данных
70. • Большой импорт • Снапшот состояния внешней системы в виде набора JSON-файлов • Обновление более 16 млн. записей • Event-Based-апдейты • Чтение новых событий из Kafka • Real-Time-апдейты • Актуализация данных через API перед покупкой товара 70 Синхронизация данных
71. • Окно “в ночи” • Большой импорт провоцирует интенсивный Compaction 71 Особенности большого импорта
72. • Окно “в ночи” • Большой импорт провоцирует интенсивный Compaction • Replace-Only • Чтение, сверка данных - дорого (чтение в Кассандре дороже записи) • Данные по ключу всегда перетираются полностью 72 Особенности большого импорта
73. • Окно “в ночи” • Большой импорт провоцирует интенсивный Compaction • Replace-Only • Чтение, сверка данных - дорого (чтение в Кассандре дороже записи) • Данные по ключу всегда перетираются полностью • Append-Only • Удаление через флаг • Накопление ненужных данных 73 Особенности большого импорта
74. 74 График, который бы вы не хотели видеть
75. 75 Как сказывается на бизнесе
76. 76 Коварный Compaction • Если не успевает • Увеличивается количество SSTable (бывало и 13363) • java.lang.OutOfMemoryError: Java heap space
77. 77 Коварный Compaction • Если не успевает • Увеличивается количество SSTable (бывало и 13363) • java.lang.OutOfMemoryError: Java heap space • Не самые приятные последствия • Резко увеличивается latencу (и таймауты тоже происходят) • Перестают работать снапшоты (тоже не успевают) • Инстансы долго стартуют (более чем в 10 раз)
78. 78 Боремся с Compaction'ом • Больше потоков для обработки • Увеличили с 1 до 4
79. 79 Боремся с Compaction'ом • Больше потоков для обработки • Увеличили с 1 до 4 • Диски решают • Заменили HDD на SSD • Убрали снапшоты • Размазывание данных по “шпинделям"
80. 80 Боремся с Compaction'ом • Больше потоков для обработки • Увеличили с 1 до 4 • Диски решают • Заменили HDD на SSD • Убрали снапшоты • Размазывание данных по “шпинделям" • Тюнинг параметров • MemtableThroughputInMB: 2MB -> 512MB
81. 81 Платим за стабильность DC1 DC2 DC3 • 12 vCPU • 16 GB Mem • 2 x 512 GB SSD • 32 GB Shared Memory
82. 82 А что там с консистентностью?
83. 83 Консистентность и пользователь
84. • Ночной импорт • Восстановление потерянной за день информации • Полное восстановление информации 84 Меры восстановления консистентности
85. • Ночной импорт • Восстановление потерянной за день информации • Полное восстановление информации • Event-Based-апдейты • Актуализация данных близкая к реальному времени • Восстановление потерянной информации 85 Меры восстановления консистентности
86. • Ночной импорт • Восстановление потерянной за день информации • Полное восстановление информации • Event-Based-апдейты • Актуализация данных близкая к реальному времени • Восстановление потерянной информации • Real-Time-апдейты • Проверка консистентности данных на момент покупки 86 Меры восстановления консистентности
87. • Внешний источник данных • Любая информация всегда приходит с задержкой 87 Eventual Consistency как предел мечтаний
88. • Внешний источник данных • Любая информация всегда приходит с задержкой • Пользователь, который покупает • Лаг по времени между показом товара и принятием решения о покупке 88 Eventual Consistency как предел мечтаний
89. • Внешний источник данных • Любая информация всегда приходит с задержкой • Пользователь, который покупает • Лаг по времени между показом товара и принятием решения о покупке • Проще и дешевле быть немного неконсистентным • Менее 1% показа новой цены пользователю 89 Eventual Consistency как предел мечтаний
90. 90 Синхронизация заказов
91. 91 Обработка заказов
92. • Шедулер с шардингом • Сплит по доменам по order_id • Разбиение до 256 доменов (реально используется 8) • Каждый инстанс шедулера обрабатывает свой домен 92 Асинхронная обработка заказов
93. 93 Асинхронная обработка заказов
94. 94 Не сразу, но заказы обработались
95. • Плюсы • Минимизируется конкурентность обработки заказов • Постоянная сверка с мастер-системой • Независимость от внешней системы 95 Преимущества и недостатки
96. • Плюсы • Минимизируется конкурентность обработки заказов • Постоянная сверка с мастер-системой • Независимость от внешней системы • Минусы • Ограниченная параллелизация • Ручное перераспределение доменов 96 Преимущества и недостатки
97. N| Выводы
98. • Сразу минимизировали влияние внешнего API 98 Выводы
99. • Сразу минимизировали влияние внешнего API • Начали с простых и экономичных решений 99 Выводы
100. • Сразу минимизировали влияние внешнего API • Начали с простых и экономичных решений • Повышали надёжность и эффективность, не усложняя решение 100 Выводы
101. 101 Q&A