DevOps зоопарк або як 500px обслуговує понад 500TB зображень

Від перекладача: Я вибрав цю статтю для перекладу, як яскравий приклад розвивається західного стартапу з вираженими для цієї групи ознаками: дуже багато нових технологій, використання великої кількості сторонніх сервісів, експерименти з архітектурою. У статті досліджено особливо цікаві теми пов'язані з побудовою платформи з микросервисов, 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 de Noel 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, — все це дозволить нам рости краще і швидше!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.