Главная » Хабрахабр » [Перевод] Как восемь человек масштабируют highload-проект. Опыт Unsplash

[Перевод] Как восемь человек масштабируют highload-проект. Опыт Unsplash

Фото: Alex Smith | Unsplash

Добрый день!

Основная задача нашего отдела — разработка функционала, который видят пользователи нашего сайта и приложений. Меня зовут Виктор Пряжников, я работаю в отделе Features компании Badoo. Подход автора импонирует мне своей прагматичностью и чем-то напомнил «Вы — не Google», поэтому я решил её перевести. Когда мне попалась на глаза статья сооснователя Unsplash Люка Чессера, она заинтриговала меня тем, что им удаётся развивать сравнительно большой проект совсем маленькой командой.

Одна из самых забавных вещей в разработке Unsplash — большой масштаб и популярность продукта.

запросов от unsplash.com и тысяч сторонних приложений, через наш пайплайн обработки данных проходят миллионы событий, в наши ленты добавляются 60 млн. В обычный день наш API обрабатывает больше 10 млн. изображений. обновлений, и мы обслуживаем 60 млн.

У нас нет отдельного DevOps-инженера, и каждый член команды тратит бОльшую часть своего времени на эксперименты и разработку новых фич для обеспечения дальнейшего развития продукта.
Хотя мы уже достигли многого с Unsplash, мы всё ещё находимся в самом начале его пути как продукта и бизнеса. В то же время наша команда сравнительно мала: два дизайнера, три человека, работающих с фронтендом, два — с бекендом и один дата-инженер. д. Нам по-прежнему есть что доказывать, и это значит, что нужно, чтобы вся команда была сфокусирована на решении проблем, уникальных для Unsplash, а не тех, которые есть у любой другой компании, вроде организации выкладок, безопасности сети, построения инфраструктуры, управления зависимостями и т.

К сожалению для тех, кто ищет серебряную пулю, здесь её не будет: это просто здравый смысл и набор принципов, который мы заимствовали у других. За последние три года мы выработали набор принципов, которые позволяют нам фокусироваться на росте и избегать проблем масштабирования.

1. Используйте скучные очевидные решения

Или будьте прагматичны.

д), нового паттерна («функциональное всё!») или новой архитектуры («микросервисы, на помощь!»), перепробуйте все очевидные варианты. Прежде чем приступить к внедрению нового инструмента, базы данных (RethinkDB, RocksDB и т.

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

2. Фокусируйтесь на решении проблем пользователей, а не технологий

Unsplash — это продуктовая, а не технологическая компания. Мы получили кучу денег от инвесторов, чтобы сфокусироваться на решении проблем нашего продукта и рынка, а не пытаться добиться трёхпроцентного снижения операционных расходов на применение общих технологий.
Мы тратим своё время на использование готовых технологий таким образом, который поможет решить проблемы наших пользователей и увеличить сообщество Unsplash. Это задачи, уникальные для Unsplash, и, если мы преуспеем в создании чего-то нового и ценного, мы можем отложить оптимизацию на более поздний срок, когда эти 3% оптимизации смогут стать главным источником роста.

Это заставляет нас платить немного больше прямо сейчас, но зато позволяет отложить внутреннюю разработку этих технологий на какое-то время и переложить её на плечи наших будущих коллег. Наших потенциальных коллег, которые слышали о масштабах Unsplash и маленькой команде, использовании изображений и искусственного интеллекта, будущих фичах, может смутить тот факт, что мы используем много работающих «из коробки» технологий, сервисов и фреймворков.

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

3. Тратьте деньги на решение технологических проблем

Обратная сторона фокуса на продуктовых проблемах заключается в дополнительных расходах на доступ к готовым технологиям и сторонним сервисам.

Говорят, что моей первой реакцией на любую проблему будет вопрос: «А вы пробовали решить её с помощью денег?». Это стало чем-то вроде шутки внутри нашей команды. Но это не шутка, а один из моих любимых подходов к решению проблем.

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

Когда мы тратим деньги на решение технологических проблем, мы развязываем руки команде, позволяя ей сфокусироваться на неповторяющихся сложных проблемах вроде поиска способа увеличения размера базы пользователей на 40% в текущем квартале.

Итак, это три довольно простых, но абстрактных принципа, которым мы следуем.

Но как они выглядят на практике?

Если вы посмотрите на архитектуру Unsplash, то увидите, что она очень простая и почти что скучная (по крайней мере, по стандартам 2017 года).


Упрощённая схема основных частей, из которых состоит Unsplash

Heroku — это какая-то магия, которая разделяет части приложения и процесса разработки так, что членам нашей команды не нужно быть знакомыми с ней, чтобы разрабатывать и выкладывать эксперименты. Мы используем Heroku везде, где это возможно, чтобы упрощать выкладку, конфигурирование, тестирование, поддержку и масштабирование наших основных приложений.

При его написании мы активно используем фреймворки, созданные другими людьми, которые, являясь экспертами в своих областях, разработали решения, успешно работающие в 95% наших сценариев использования. Мы агрессивно минимизируем объём кода, который пишем для бизнес-логики приложения (фиолетовые области на картинке).

В прошлом мы пробовали и другие базы данных, но всегда возвращались к этим трём, поскольку уверены в том, что понимаем, как они ведут себя под нагрузкой. Мы активно используем в продакшене Redis, Elasticsearch и Postgres.

Также мы активно используем очереди задач, асинхронно обрабатывая множество операций, таких как обновление, агрегация и синхронизация данных между разными источниками.

Для обработки данных мы используем Snowplow, открытый интегрированный фреймворк, написанный на Scala, который избавляет нашу команду от необходимости думать об организации входа и выхода, а не о самой обработке.

Ещё мы используем целый набор облачных сервисов для мониторинга, таких как Datadog, New Relic, Sentry и Logentries, вместо того чтобы разворачивать и поддерживать собственный StatsD или ELK-стек.

Если они добавляют какой-то новый функционал, то наша команда делает одно изменение в URL — и наши пользователи тоже получают доступ к этому функционалу. Хостинг и инфраструктуру по отдаче наших изображений мы передали на аутсорс в imgix, ведущую компанию по работе с динамическими изображениями.

Stream упрощает для нас обработку миллиардов действий и предоставляет простой API для входа и выхода, который работает с такой производительностью, на создание которой своими силами наша команда потратила бы месяцы, а то и годы. Мы записываем все действия наших пользователей в сервис Stream, используя их опыт построения и оптимизации высоконагруженных персональных лент.

Мы не тренируем алгоритмы распознавания изображений сами, а вместо этого используем TinEye для обратного поиска изображений и Google Vision для распознавания и классификации изображений.

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

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

За последний год мы разделили наше единое приложение, написанное на Ruby on Rails, на Rails API, веб-приложение на Node.js + React и создали отдельное приложение по работе с данными, которое собирает и обрабатывает все наши внутренние и продуктовые метрики.

Разделив проблемы и технологии наших приложений, наша команда также получила возможность использовать лучшие инструменты в каждой из областей: Это позволило нашей команде создавать функционал, который казался почти невозможным на нашем старом стеке, состоящем только из Rails.

  • На фронтенде мы используем React и Webpack вместе с небольшим сервером на Express для поддержки серверного рендеринга и проксирования запросов к API. Мы намеренно не стали привязывать инструменты нашей команды фронтенда к бэкенду временными хаками вроде react-rails или webpacker. JavaScript-сообщество, без сомнения, выпускает лучшие инструменты для работы с фронтендом, поэтому работа напрямую с JavaScript позволяет нашей команде быстрее доставлять до пользователей функционал высокого качества.
  • На бекенде наша команда продолжает использовать лучший фреймворк для разработки простых web-приложений: Rails. Экосистема Ruby on Rails поставляет лучшие инструменты для функционала на стороне бекенда, и, поскольку этот фреймворк широко используется, любая проблема с ним уже найдена кем-то, документирована, и с большой долей вероятности для неё уже есть решение.
  • На стороне работы с данными наша команда использует небольшой сервер на Express для сбора и организации обработки данных. Сама обработка происходит в Snowplow, который работает в кластере AWS, где для него есть готовые образы, упрощающие конфигурирование и развёртывание. Это позволяет нашему единственному дата-инженеру Тиму тратить большую часть времени на передачу данных в Snowplow и получение результатов оттуда таким образом, который делает их лёгкими для понимания и получения инсайтов остальными членами команды.

Мы активно занимаемся написанием тестов, измерением производительности с помощью таких инструментов, как Scientist и Datadog, раскладыванием изменений в виде экспериментов и максимально автоматизируем работу с нашей инфраструктурой.

Мы разрабатываем новый внутренний API на базе GraphQL для ускорения не зависящих друг от друга итераций экспериментов, новых фич и продуктов, так как мы поняли, что наш API на базе REST ломается без высокого уровня координации между командами данных, дизайна, фронтенда и бекенда — лучше мы будем тратить это время на фичи, а не изменения JSON.

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

Я думаю, что у большинства людей, дочитавших до этого места, в голове один из трёх выводов:

  1. Unsplash очень простой, поэтому вы и можете использовать этот подход. То, чем я занимаюсь, гораздо сложнее, поэтому мы вынуждены делать всё по-другому.
  2. Я разработчик. Это звучит очень скучно —  я хочу заниматься созданием новой системы распознавания изображений с высокой нагрузкой!
  3. Круто! Мне всё равно, просто дайте мне красивые бесплатные фото, которые я могу использовать.

Но их не так много. Люди с выводом №1, вы правы: есть компании, которые делают гораздо более сложные вещи, чем мы. Мы все создаём такие же системы, но сфокусированные на немного других вещах, и это причина, по которой используемые решения могут быть абстрагированы в виде фреймворков и переиспользованы в разных проектах (поэтому большинство постов о найме так похожи друг на друга).

Если вам хочется раздвигать границы технологий, то идите работать в компанию, чья миссия — делать это. Люди с выводом №2, это зависит от того, что вы находите интересным. Их не так много, но большинство других компаний просто не занимается этим.

Людям с выводом №3 я скажу: «Да, совершенно верно!» В конце концов, это то, ради чего мы всё это и делаем.

Главное отличие заключается в том, что наш проект гораздо больше и использовать внешние сервисы для нас зачастую очень дорого. Нам в Badoo близки принципы, про которые рассказывает автор. Некоторые наши решения достаточно старомодны, поскольку были созданы довольно давно, но переход на аналогичные новые только ради моды не окупит затраченных на него ресурсов. При этом многие наши решения очень простые и мы стараемся аккуратно подходить к их изменениям, сравнивая стоимость внедрения и эксплуатации новой технологии с той пользой, которую мы от неё получим. При этом мы готовы внедрять новые технологии, если понимаем, что они способны принести реальную пользу (например, PHP 7, Go, Cassandra, Tarantool, Exasol).


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Переезд с Ubuntu на Windows 10, Hyper-V и избавление от железного маршрутизатора

Купив новый ноутбук, я с сожалением заметил, что моя любимая Ubuntu больше не поддерживает работу сенсоров и вентиляторы постоянно жужжат, делая работу не комфортной. В тоже время, если загрузить предустановленную Windows 10 Pro с оригинального жесткого диска, то наступает приятная ...

«Монстры в играх или как удивить игрока»

Привет, друзья! Уже подошёл третий материал в цикле статей, который вы встречаете очень положительно, за что вам огромное спасибо! Сегодня продолжим разбирать монстров по кусочкам Knee Deep In The Dead! И так, сегодня статья будет наполнена массой примеров и отлично ...