Я провожу выходные за исследованиями, изучением и созданием контента для этой рассылки.
Для меня было бы очень важно, если бы вы потратили несколько секунд своего времени и заглянули на сайт Clumio.
По крайней мере, посмотрите, почему им удалось собрать $75 млн. Даже Atlassian использует их для Jira.
Это поддерживает мою работу. Теперь давайте продолжим шоу.
С ростом расходов на хранилище Amazon S3 и потенциально разрушительными последствиями для бизнеса от потери данных вам необходим комплексный подход к сокращению ненужных расходов и защите от рисков. Лоуренс Миллер, консультант многонациональных корпораций, имеющий многочисленные сертификаты по сетевым технологиям, написал краткий том, в котором изложен путь к успеху в управлении резервным копированием и соблюдении требований для озер данных S3.
Помните, как трудно было раньше найти музыку?
Раньше люди пользовались проигрывателями пластинок. А потом кассетными проигрывателями. А потом MP3-плеерами.
Люди пиратили музыку через Napster и LimeWire.
Чтобы слушать музыку на ходу, приходилось носить с собой отдельные устройства.
А потом все изменилось.
Этот революционный продукт проложил путь таким компаниям, как SoundCloud сегодня.
Как инженеры, мы можем извлечь много ценных уроков, анализируя эволюцию архитектуры SoundCloud за последние два десятилетия.
Масштабирование — это проблема роскоши
С самого начала команда инженеров оптимизировала работу с учетом имеющихся возможностей.
Вместо того чтобы разрабатывать архитектуру, которая могла бы поддерживать миллионы пользователей, они начали с простой настройки: приложение Ruby on Rails (называемое Mothership), веб-сервер Apache и база данных MySQL.
Первоначальная архитектура SoundCloud
SoundCloud был запущен в 2008 году. Высокой доступности не было. Фактически архитектура даже не была асинхронной.
Если в треке публиковался новый комментарий, общение блокировалось до тех пор, пока все подписчики не будут уведомлены.
В чем может быть причина этого?
Ответ возвращает нас к оптимизации возможностей. Они использовали простой технический стек, который команда хорошо знала, и сосредоточились на предоставлении ценности своим пользователям.
В результате SoundCloud удалось быстро развиваться и создать «прилипчивую» платформу с хорошим соответствием продукта рынку.
Сторонние приложения, интегрирующиеся с SoundCloud, использовали те же самые API, что и внутреннее приложение инженерной группы.
Вскоре после этого Apache был заменен на Nginx (постепенные изменения).
SoundCloud меняет веб-серверы
Nginx обеспечил улучшенный пул соединений и упростил настройку маршрутизации между различными средами.
Продуктовый магазин и почта
По мере роста SoundCloud рос и трафик.
И по мере роста трафика росла проблема: некоторые рабочие нагрузки выполнялись намного дольше других (сотни миллисекунд).
Это была проблема Nginx в то время. А точнее HTTP/1.
В компьютерных сетях есть такое понятие, как Блокировка очереди (HoL). Это происходит, когда более медленные запросы засоряют соединения, а другие запросы зависают в ожидании обработки.
Представьте себе ожидание в очереди в продуктовом магазине на кассе. Поскольку у первого покупателя тележка полная товаров, остальная часть очереди задерживается.
Пример блокировки HoL в продуктовом магазине
Возникает вопрос: как текущая архитектура может обрабатывать запросы одновременно?
Когда архитектура SoundCloud только разрабатывалась (2008 г.), параллельная обработка запросов в Rails все еще считалась незрелой.
Вместо того чтобы тратить больше времени на аудит зависимостей, команда инженеров решила остаться с существующей моделью:
-
Один параллелизм на процесс сервера приложений.
-
Несколько процессов на хост.
Несмотря на то, что на хост приходится несколько процессов, SoundCloud уже испытывает высокий трафик. Несколько длительных запросов могут легко воссоздать проблему блокировки HoL.
Например, при использовании 5 процессов вместо 1 система теоретически сможет обрабатывать в среднем в 5 раз больше медленных запросов.
Опять же, представьте себя в почтовом отделении. Вы ждете в очереди свободного работника, который поможет вам с посылкой. Чем больше людей, тем выше вероятность задержек (люди с несколькими посылками).
Как можно решить эту проблему HoL?
Инженерная группа пришла к выводу. Им нужна была система, которая никогда не стояла в очереди. Или, по крайней мере, очередь с минимальным временем ожидания.
Для этого им нужно было убедиться, что каждый сервер приложений Rails никогда не получает более одного запроса одновременно.
Они внесли следующие изменения:
-
Гарантировано, что серверы не имеют состояния.
-
Добавлен HAProxy на инфраструктуру.
-
Настроенный бэкэнд с максимальным количеством подключений 1.
Опять же, простые дизайнерские решения.
Синхронный в асинхронный
Эти новые изменения, возможно, решили проблему HoL, но длительные запросы по-прежнему остаются проблемой сами по себе.
Одним из примеров являются уведомления пользователей.
Когда пользователь загружает новый трек на SoundCloud, подписчики пользователя уведомляются об этом. Это может быть нормально для пользователей с меньшим количеством подписчиков, но для более популярных пользователей возникали огромные задержки.
На самом деле, разветвление уведомлений часто превышали десятки секунд. Эти длительные запросы должны были быть заданиями (очередями).
Помните, как в этой архитектуре все было синхронно?
Поскольку хранилище также быстро росло для звуков и изображений, команда решила выгрузить активы в Amazon S3. Хранилище хорошо масштабировалось, в то время как транскодирование вычисления остались в Amazon EC2.
«Один брокер, чтобы поставить их всех в очередь».
Рабочие места делятся на две основные категории в зависимости от продолжительности рабочего времени:
-
Интерактивный — время работы менее 250 мс
-
Партия – все остальное
Определение точек шкалы
На тот момент количество пользователей SoundCloud достигло сотен тысяч.
Команда инженеров понимала, что для дальнейшего развития архитектуры необходимо разделить пути чтения и записи.
Затем пути чтения и записи можно оптимизировать по отдельности.
Одним из направлений деятельности был виджет.
Как оказалось, наибольший объем запросов SoundCloud пришелся на одну конечную точку, предоставляющую данные для виджета.
-
Полные страницы
-
DOM-фрагменты
-
Частично визуализированные шаблоны
-
Ответы API только для чтения
Эти улучшения производительности решили проблемы с ЦП (движком рендеринга и средой выполнения) на уровне приложений.
Еще одной областью внимания стала панель мониторинга — персонализированное представление действий пользователя.
Когда панель управления получает обновление, соответствующие пользователи получают уведомление на всех устройствах и в сторонних приложениях.
Путь чтения необходимо было оптимизировать для последовательного доступа каждого пользователя в течение определенного периода времени.
Путь записи необходимо было оптимизировать для случайного доступа, когда одно событие может повлиять на индексацию миллионов пользователей.
Чтобы учесть эти оптимизации, Кассандра была выбрана в качестве системы хранения и Elasticsearch был выбран для улучшения поиска. Эти решения обеспечили постоянство и масштабируемость.
Окончательная монолитная архитектура выглядела так:
Монолитная архитектура SoundCloud
История продолжается
SoundCloud был известен как «YouTube для аудио» и обладал уникальными функциями, такими как проигрыватель формы волны, комментарии к трекам и возможность совместной работы.
Архитектурные решения, принятые инженерной группой в первые годы ее существования, позволили компании стать адаптивной и ориентированной на продукт.
Основные выводы из раннего успеха SoundCloud можно свести к трем пунктам:
-
Оптимизируйте возможности. Сосредоточьтесь на продукте.
-
Масштабирование — проблема роскоши. Архитектор для роста с течением времени.
-
Определите точки масштаба. Тщательно определите точки интеграции для органического роста.
В следующей части этой серии мы узнаем о переходе SoundCloud на архитектуру микросервисов и о трудностях масштабирования до сотен миллионов пользователей.
Если вы дочитали до этого места, спасибо за прочтение! Надеюсь, вам понравилось.
Если я допустил ошибку, пожалуйста, дайте мне знать.
Ресурсы
2024-07-01 10:22:36
1719863829
#Эволюция #архитектуры #SoundCloud #часть
