DevOps зоопарк или как 500px обслуживает более 500TB изображений

http://stackshare.io/500px/how-500px-serves-up-over-500tb-of-high-res-photos
От переводчика: Я выбрал эту статью для перевода, как яркий пример развивающегося западного стартапа с выраженными для этой группы признаками: очень много новых технологий, использование большого количества сторонних сервисов, эксперименты с архитектурой. В статье затронуты особо интересные темы связанные с построением платформы из микросервисов, DevOps и совсем мало освещенное на Хабре явление под названием ChatOps. Enjoy!


О 500px


500px — это онлайн сообщество, сформировавшееся вокруг фотографии. Миллионы пользователей со всего мира просматривают, делятся, продают и покупают самые красивые фотографии. Мы ценим дизайн, простоту кода и ответственность.
Я DevOps. В 500px, работаю над платформой: бэкенд, мониторинг, управление конфигурацией, автоматизация и конечно же развертывание системы.


Разработка


В 500px команда разработчиков разделена на 4 группы: Веб, Мобильные приложения, Качество и Тестирование, и конечно же наша команда ответственная за платформу и архитектуру, которая занимается проектированием API и бэкенда, включая управление инфраструктурой в целом.

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



Архитектура


Архитектура 500px может быть представлена как огромный Ruby on Rails монолит, окруженный целым созвездием микросервисов. Rails отвечает за веб и за API, который в свою очередь обслуживает мобильные приложения и всех наших API клиентов.

Микросервисы предоставляют различный функционал для основного приложения-монолита, а так же обрабатывают некоторые API запросы напрямую.

Rails монолит достаточно стандартный: приложение и API обслуживают запросы с помощью Unicorn, за которым стоит Nginx. У нас целые кластера этих Rails серверов, которые стоят либо за HAProxy или за LVS балансировщиками. Основные базы данных с которыми работает главное Rails приложение: MySQL, MongoDB, Redis и Memcached. Еще у нас куча Sidekiq серверов для тяжелых задач, работающих в фоне. На данный момент все это хостится на собственном железе в датацентре.

Микросервисы более интересны. На данный момент у нас их около 10 типов, каждый из которых сосредоточен на предоставлении отдельной и независимой бизнес логики платформы. Некоторые из микросервисов:
  • Поиск похожего контента, работает на Elasticsearch
  • Сервис отвечающий за прием/сохранение изображений, AWS S3
  • Фиды активности пользователей, работают на Roshi и AWS Kinesis
  • Динамическое пережатие изображений и добавление ватермарка
  • Специализированные API для наших веб и мобильных приложений


Микросервисы работают как на Amazon EC2 так и на своем железе в датацентре. В основном они написаны на Go, но есть и исключения на NodeJS или Sinatra. На самом деле, независимо от языка мы стараемся создавать наши микросервисы хорошими 12-факторными приложениями, которые позволяют снизить сложность развертывания и управления конфигурацией. Все эти сервисы работают либо за HAProxy либо за AWS Elastic Load Balancer-ами.



Использование микросервисов очень помогает, позволяя избежать сложностей за счет вынесения логики за пределы основного приложения. Все что надо знать команде фронтенд разработчиков использующей эти сервисы — это только API. А если что-то необходимо изменить в каком либо из компонентов — это легко сделать. К примеру очень просто использовать микросервис поиска, не зная ничего про ElasticSearch. Такая гибкость доказала свою пользу по мере того как мы развиваем нашу платформу, потому что она позволяет нам пробовать новые технологии безопасным, изолированным способом. Если вам интересно использование микросервисов, то бывший разработчик 500px Paul Osman в прошлом году на QConSF рассказал о нашем опыте миграции от большого монолита к микросервисам (от переводчика: очень интересно, советую посмотреть).

Обработка Изображений


Пожалуй самые интересные из микросервисов которые мы используем в 500px это обработка и обслуживание изображений. Ежемесячно мы поглощаем миллионы фотографий высокого качества от нашего сообщества и отдаем терабайты картиночного трафика с основного CDN, Edgecast. В прошлом месяце мы отдали порядка 569TB трафика, а 95-й перцентиль полосы пропускания составил около 2308Mbps. Людям действительно нравится смотреть красивые фотки!

500px родной город, Торонто

Для сохранения и раздачи графического контента работают 3 группы микросервисов в EC2, все построенные вокруг S3 где мы и храним все наши картинки. Все они написаны на Go и нам действительно понравилось использовать Go для таких вещей, потому что это позволяет писать маленькие, но очень быстрые многопоточные сервисы. А это значит мы можем их размещать на меньшем количестве машин, держа под контролем счета за хостинг.

С первым микросервисом посетители сталкиваются когда они загружают фотографии, — мы его называем Медиа Сервис. Медиа Сервис достаточно прост: он принимает загрузку, сохраняет в S3, а потом просто добавляет задачу в очередь RabbitMQ для последующей обработки.

Далее, принимающий задачи из RabbitMQ — второй микросервис, названный Конвертером. Сервис Конвертации скачивает исходное изображение из S3, производит определенное количество обработок по генерации миниатюр различого размера и опять сохраняет их в S3. Мы используем эти миниатюры в разных местах: как на сайте так и в мобильных приложениях.

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

Чтобы решить эту проблему мы недавно создали Сервис Генерации Изображений (и да, мы склонны выбирать наглядные имена для таких вещей). Этот новый сервис работает за CDN, динамично генерируя из S3 оригинала изображение любого размера или формата на лету. Он так же умеет накладывать водяные знаки или символику фотографа, что особенно нравится нашему сообществу.

Сервис Генерации Изображений достаточно высоконагруженный, кластер обрабатывает порядка 1000 запросов/секунду в часы пик. Динамическая перегенерация и наложение водяных знаков ресурсоемкий процесс, поддерживать разумное время отклика при высокой нагрузке — непростая задача. Мы упорно трудились над этой проблемой, и на пике посещений мы в состоянии поддерживать 95-процентиль времени отдачи контента ниже 180ms. Это стало возможным при помощи классной и быстрой библиотеки для обработки изображений VIPS, агрессивному кэшированию, и просто сумасшедшим оптимизациям. Вне часов пик, обычное время отдачи для картинок ниже 150ms.

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

Рабочий Процесс


Мы используем GitHub и практикуем непрерывную интеграцию (CI) для всех наших основных репозиториев.

Для Rails монолита мы используем Semaphore и Code Climate, стандартную rspec конфигурацию для юнит тестирования и небольшое количество Capybara/Selenium тестов для интеграционного тестирования. Наш 500px сотрудник и просто классный парень Devon Noel de Tilly подробно описал как мы используем эти инструменты, так что не буду здесь останавливаться.

Для наших Go микросервисов мы используем Travis CI под тесты и для сборки Debian пакетов. Travis после билда загружает собранные пакеты во временное S3 хранилище, после чего другой микросервис скачивает их, подписывает и импортирует в наш собственный Apt репозиторий. Для создания пакетов мы используем FPM, Aptly — для управления своими репозиториями. Недавно для этих задач я пробовал packagecloud.io и мне он действительно понравился, так что возможно мы перейдем на него в ближайшем будущем.

Для развертывания мы используем целую группу инструментов. На самом низком уровне мы используем Ansible и Capistrano, Chef — для управления конфигурацией. На более высоком уровне нам в 500px действительно понравилась ChatOps практика, так что мы заскриптовали все наши сценарии использования этих инструментов в всегда верного Hubot бота, которого прозвали BMO.


Каждый в 500px может с легкостью развернуть сайт или микросервис сообщением в чате:

bmo deploy <microservice name>

BMO приходит, деплоит/разворачивает то о чем его просили и отправляет лог обратно в чат! Этот простой и легкий механизм просто сотворил чудеса для улучшения видимости процесса и снижения сложности вокруг развертывания приложений. Мы используем Slack чат где и происходит общение с BMO. Если вам нужно найти определенный лог или вы забыли команду, просто запустите поиск по чату. Магия!

Другие важные инструменты


Мы мониторим все с помощью New Relic, Datadog, ELK (Elasticsearch, Logstash, Kibana), и старого доброго Nagios. Мы отправляем всю нашу почту с помощью Mandrill и Mailchimp, все платежи процессит Stripe и Paypal. Помогают нам принимать решения (прим. переводчика: BigData и аналитика) Amazon Elastic MapReduce, Amazon Redshift и Periscope.io. Для общения и синхронизации команды мы используем Slack, Asana, Everhour и Google Apps. А когда что-то идет не так, у нас есть Pagerduty и Statuspage.io чтобы держать наших пользователей в курсе.

Что дальше?


Прямо сейчас я экспериментирую c запуском нашего созвездия микросервисов в Docker контейнерах в качестве персональной среды разработки (docker-compose up), с прицелом на использование их в продакшене в будущем. У нас налажен CI процесс с помощью Travis и Docker Hub и я действительно в восторге от потенциала облачных контейнерных сервисов, таких как Joyent Triton и Amazon ECS. В процессе того как мы строим все больше и больше микросервисов и расширяем нашу архитектуру, мы также смотрим в сторону таких инструментов для распределенных систем как Consul и Apache Mesos, — все это позволит нам расти лучше и быстрее!
Метки:
Поделиться публикацией
Похожие публикации
Комментарии 19
  • +5
    Оцениваю сервис как потребитель графического контента, в смысле покупки прав на изображения для веба. 50$ за фотку? Даже и крутого качества, не многова-то ли?
    • +2
      ИМХО молодцы, откусили свой кусок пирога от рынка супер качественных фотографий. Есть своя группа покупателей и на топовый контент, особенно на западе.

      P.S. Фотки действительно классные.
      • +1
        Тоже правда ) Крутая идея, отличная реализация!
      • +1
        Вот интересный пример: 500px.com/photo/111352475/sister-tornados-under-supercell-by-kelly-delay

        Из описания:
        Редкое явление, сестры торнадо из грозовой супер-ячейки надалеко от Симла, Колорадо.
        Снимок всей моей жизни. Я пытался сфотографировать что-то подобное на протяжении 6 лет. Надеюсь вам понравится!


        Фотография свежая (пару дней), сразу попало на Mashable и другие крупные западные новостные ресурсы.
        Получается целая история у фотографии.
        • +1
          обидно, что формат для веба 72dpi, делали уж 144 за 50-то $ )
      • +3
        Интересно, как они смогли раскрутиться. ИМХО это гораздо сложнее, чем сделать качественный сервис, потому как написание сервиса, в отличие от привлечения клиентов, инженерная задача.
  • +1
    Неслабый у них зоопарк технологий!
  • +1
    Кто-то может человеческим языком объяснить что означает «DevOPS»?
    • +1
      Development Operations. Термин имхо достаточно новый. Группа лиц, поддерживающая процессы разработки и деплоймента. Что-то между сисадминов и девелоперов. В разных компаниях сдвиг может быть больше в ту или иную сторону.
      • +2
        Т.е. по сути просто эвфемизм для «и швец и жнец и на дуде игрец»? Или тут что-то другое?
        • +1
          Я бы пока назвал это скорее сисадмины-переростки, которые еще до разрабов не доросли, но уже очень интересуются автоматизацией на очень высоком уровне. То есть для работы просто необходимо уметь скриптовать (а это обычно python, ruby, perl), знать несколько инструментов типа Jenkins, Chef, Ansible, знать и уметь всякие git, svn. И это все на основе хороших знаний в администрировании серверов и знании нетворкинга. В общем ни разу ни эникейщик, на мой взгляд. Но тема модная нынче. Я на позицию DevOps Engineer перешел из IBM, где я был обычным SysAdmin.
          • 0
            Спасибо, так гораздо понятней.
          • 0
            По-моему опыту работы/общения с разными DevOps-ами в западных стартапах, как раз лучший набор это люди давно переросшие разработку вцелом, при этом сисадмины, да и еще с хорошим опытом и пониманием бизнес задач.

            ИМХО 2 наиболее часто распространенных мифа про DevOps:
            • «Вася у нас администрирует сервера — он DevOps»
            • «Мы стали использовать Ansible для 2 наших серверов, мы теперь DevOps»

            Просто использование менеджера конфигураций не сделает никого DevOps, так же как и администрирование серверов.

            Из-за «и швец и жнец и на дуде игрец» и требования выше и соответственно зарплата высокая. Очень легко приготовить блюдо DevOps «не так», выбрав на позицию либо зеленого разработчика, либо просто сисадмина, либо того кто не думает о бизнес задачах.

            Ведь очень многие стартапы побигают «от модности», используя кучу технологий вместо того чтобы реально сосредоточиться на продукте!

            — Вцелом мысль вашу понял и согласен что слово слегка слащавое и раскрученное.
    • +1
      По-старому это просто Сисадмины & Разработчики, способные не только понять что программирование — это решение бизнес задач, но и умеющие улучшить кардинально процессы с целью сделать бизнес более эффективным.

      Из этого исходят последствия в виде:
      • оптимизация процессов
      • автоматизация
      • мониторинг
      • инфраструктура Тестирования
      • отслеживание регрессий
      • средства коммуникации в команде
      • внедрение инструментов, которые делают разработку быстрее и качественнее
      • практики единого стиля кодирования, сode reviews и прочие такие мелочи
      • архитектурные изменения/улучшения в коде на основе аналитики
      • инновации и эксперименты
      • итд. список можно долго продолжать


      Итого улучшения Системы вцелом для того, чтобы бизнес работал и рос лучше.
      Те по сути человек и пароход, связывающий Бизнес & Разработку & Качество.
      • 0
        Ну вот я и смотрю, что вроде ничего принципиально нового эта концепция не несет, ведь все это и раньше делали заинтересованные люди, но теперь еще и термин появилося. Причем каждый понимает его по-своему, а в сухом остатке, едином для всех, остается только маркетинговый булшит — мол я программист, но современный и мне якобы не начхать на ваш бизнес.
        • 0
          Вообще по википедии, это не люди, а концепция тесного взяимодействия между Dev, Ops и QA.

          А есть еще NoOps

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