Duolingo | Відправка понад 6 мільйонів сповіщень за 5 секунд

User is familiar with Duolingo and works on projects related to large-scale notifications.

Огляд

Duolingo — це найпопулярніша платформа для вивчення мов, з 31,4 мільйонами активних користувачів щодня. Надсилання сповіщень користувачам є викликом, особливо коли кампанія сповіщень націлена на мільйони користувачів. До речі, нижче наведено приклад деяких сповіщень.

У наведеному нижче прикладі вимога від маркетингової команди полягала в тому, щоб надіслати понад 6 мільйонів сповіщень за 5 секунд у певний момент часу (доволі конкретний, оскільки це повинно було бути зроблено відразу після показу реклами під час Супербоула 2024 року).
Back in 2022, Coinbase launched its bouncing QR code campaign during the Super Bowl, and it was so popular that it crashed their site.

Проблеми

• Поточна система зазвичай обробляє 10 000 сповіщень на секунду, а вимога полягала в тому, щоб надіслати сповіщення в 80 разів швидше.
• Розробники виявили проблему з Android-додатком. Коли він надсилає сповіщення, воно відправляє запит назад на сервер. Це трохи схоже на атаку DDoS.
• Система повинна продовжувати обробляти органічний трафік.
• Вимоги постійно змінювались (Чи можемо ми додати іконку до сповіщення? Чи можемо ми надіслати їх в інші міста? Чи можна локалізувати пуш-сповіщення на різні мови? Чи можемо використати постачальника для цього?)
• Одним із принципів роботи Duolingo є спочатку тестувати.
  Meaning the solution should be tested before that day.
• The system should be able to scale at that rate. There are multiple technologies involved (Apple, Android APIs, AWS services scale limits, Rate limits of some services, etc.)
• The system should be ready as close to the Super Bowl day as possible. Because if they scaled the system a couple of days before the event, that would cost a lot.

Рішення

По-перше, зміни вимог повинні бути уточнені. Тобто, можна вносити деякі зміни в останні кілька днів, але деякі зміни заборонені, наприклад, “Чи можемо ми додати 2 мільйони користувачів за день до події, після того, як ми вже фактично затвердили список аудиторії?” Відповідь була ні, тому що це не можна протестувати так швидко. І якщо це не протестовано, то вони не запускають.

Проблема швидкості, а саме 800,000 запитів на секунду. У Duolingo є багато сервісів на AWS.
Деякі з сервісів, пов'язаних з цим проєктом, — це S3, DynamoDB та SQS. За кілька місяців до початку будь-якої маркетингової кампанії команда отримує список користувачів з DynamoDB (userId та deviceId) і зберігає його в S3. Коли настане день, інженери масштабують ASG (колекція інстансів EC2) та інстанси EC2. Після цього робітники отримують дані з S3, де ми попередньо зберегли всю інформацію, і зберігають ці дані в пам'яті. Дані будуть відображенням від userId до deviceId.

Після цього API сервер насправді відправляє більше 50 повідомлень у чергу FIFO (First In, First Out) SQS. Проміжний робітник, отримавши ці повідомлення, надсилає більше 10,000 SQS повідомлень до наступної черги. Нарешті, останній рівень робітників для сповіщень відправляє сповіщення, викликаючи API для пакетної відправки APNS та FCM. Це API для сповіщень від Apple та Google.

Але сама SQS має ліміт на кількість повідомлень у процесі обробки — 120,000 повідомлень на секунду.
Просто щоб відправити мільйони сповіщень за 5 секунд. Для цього вони використовували техніку пакетної обробки. Вони об'єднали 500 користувачів iOS в одне повідомлення, 250 для Android, що дозволило їм не перевищити ліміт.

Чи зможе AWS забезпечити всі необхідні ресурси вчасно? Для вирішення цієї проблеми вони зв'язалися з технічним контактним з AWS, який допоміг скласти документ з управління інфраструктурними подіями, що містив детальні кроки, такі як коли і як масштабувати ресурси, а також конкретні кроки щодо кешування, лімітів з'єднання кешу та лімітів Dynamo. Спеціалізований кластер ECS також допоміг вирішити деякі проблеми.

Тестування

На початку (під час фази MVP) тестування проводилося за допомогою тихих сповіщень. Це порожнє повідомлення, яке надсилається на клієнтські пристрої, щоб побачити, що відбувається. Одним із виявлених вузьких місць була кількість потоків.
Оскільки вони використовують Python для розробки додатків, є деякі відомі проблеми, пов'язані з багатопоточними програмами. Зменшення кількості потоків з 10 до 5, а потім до 1 допомогло подолати цю проблему.

Інша проблема виникла, коли вони намагалися масштабувати як сервіс сповіщень (призначений для цього проєкту), так і бекенд. Сервіс повинен був чекати, поки всі інші бекенд сервіси не масштабуються, щоб він міг масштабуватись, або навпаки. Ось чому вони виділили окремий кластер ECS, який згадувався раніше.

Тестування доступності як сервісу сповіщень, так і бекенду в межах 3-годинного вікна також вдалося.

Тестування рішення на реальних користувачах/пристроях було проведено за допомогою деяких існуючих кампаній, наприклад, акції/сповіщення, пов'язані з Хелловіном, використовували новий сервіс сповіщень, який спочатку доставив 1 мільйон сповіщень. У січні вони протестували 4 мільйони користувачів з повідомленням "Ласкаво просимо назад після Нового року".
Що також спрацювало чудово.

Один з внутрішніх інструментів, званий Zombie mode, справді допоміг процесу тестування. Zombie mode — це режим, коли, після того як він увімкнений, пристрій користувача припиняє надсилати запити до бекенду на певний час, поки не спробує перевірити цей прапор знову. Це допомогло в ситуаціях, коли бекенд не може впоратися з напливом трафіку і потребує часу для відновлення. Завдяки цьому режиму тестування з реальними користувачами стало більш комфортним.

Результати кампанії насправді були чудовими. 99% сповіщень було надіслано за 5.7 секунд, 95% — за 3.9 секунди.

Уроки, які були засвоєні

• Будьте відкритими до дизайну, але суворими щодо тестування: Вони визнали, що їхній дизайн був далеко не ідеальним, але вибрали такий, що дозволяв проводити ітерації та тестування.
  Вони зрозуміли, що тестування є критично важливим для забезпечення правильності роботи системи.

• Пріоритет стійкості та надійності: Система повинна бути спроектована так, щоб впоратися з такими проблемами, як одночасні дії багатьох користувачів, без виникнення помилок, наприклад, дублювання сповіщень. Це підкреслює важливість передбачення та вирішення потенційних проблем у дизайні системи.

• Плануйте для можливих збоїв і реагуйте активно: Вони прийняли, що все може піти не так, і застосували проактивний підхід. Вони створили детальне керівництво для інженерів, яке описує, які дії потрібно вжити в критичні моменти, включаючи резервні плани для різних сценаріїв збоїв, таких як повний збій сповіщень.
  Це відображає їхній підхід до вирішення проблем з підготовкою та активним пошуком рішень.

Перегляньте джерело, щоб дізнатися більше про виклики, рішення та тестування.

👏 та підпишіться на нові статті! 🖥️

[https://youtu.be/J_sGZnAJhbw?si=iySQQoAhIcUlrNsJ]

Перекладено з: Duolingo | Sending 6M+ Notifications Within 5 Seconds