Я працюю в аутсорсі, де головний принцип можна описати фразою "продавай багато, роби швидко". Чим швидше зробимо, тим більше заробимо. І, бажано, щоб все працювало не на милицях та соплях, а з прийнятним рівнем якості. Я розповім про свій досвід, коли за стислий термін потрібно було розробити промо-сервіс.
дано: root-аккаунт на AWS, відсутність обмежень на вибір стека технологій, один бекендер, і один місяць на розробку.
Завдання: промо-сервіс, де користувачі люди завантажують від одного до чотирьох відео тривалістю від однієї до чотирьох секунд, які потім вбудовуються в оригінальний відеоряд.
Рішення
Писати свій велосипедний сервіс у такі стислі терміни — так собі затія. Крім того, щоб сервіс справлявся з навантаженнями і всі бажаючі отримали заповітне відео, буде потрібно інфраструктура. І бажано не з цінником від літака. Тому одразу орієнтуємось на готові рішення з мінімальною кастомізацією.
Стандартне рішення для роботи з відео - FFmpeg, кроссплатформенна консольна утиліта, яка через аргументи дозволяє і нарізати, і накладати звук. Справа за малим - написати обгортку і випустити її в життя. Пишемо прототип, який склеює два відео, і починається найцікавіше. Бібліотека на .NET Core 2 повинна крутитися на будь-якій віртуалці, тому беремо інстанс AWS EC2 і все запрацює
Прихований текстні, не запрацює
.
FFmpeg хоч і спрощує завдання, але для реального рішення потрібно створити ЕС2 інстанс, спроектувати для нього мережну інфраструктуру, включаючи Load Balancer. Просте завдання по деплою з нуля трохи ускладнюється, а інфраструктура починає вимагати гроші негайно — щогодини з клієнтського рахунку знімається сума за рантайм.
Наш сервіс не передбачає Long-Running процесів, не вимагає великої та жирної реляційної бази даних і чудово вкладається в подійну архітектуру з ланцюжком викликів мікросервісів. Рішення напрошується само собою — ми можемо відмовитися від ЕС2 і реалізувати true-serverless додаток на зразок стандартних Image Resizer на базі AWS Lambda.
До речі, незважаючи на явну нелюбов розробників AWS до .NET, вони підтримують .NET Core 2.1 як рантайм, що дає повний спектр можливостей для розробки.
І вишенька на торті – AWS надає окремий сервіс для роботи з відеофайлами – AWS Elemental MediaConvert.
Суть роботи неймовірно проста: беремо S3-посилання на вихідне відео через AWS Console, .NET SDK або просто JSON пишемо, що хочемо зробити з відео і викликаємо сервіс. Він сам реалізує черги для обробки запитів, сам вивантажує результат в S3 і, найголовніше, генерує CloudWatch Event на кожну зміну статусу. Це дозволяє нам реалізувати лямбду-тригери на завершення процесингу відео.
Приблизно так виглядає фінальний варіант архітектури
Весь бекенд розміщується у двох лямбдах. Ще одна – для ротації вертикальних відео, оскільки така робота не може бути виконана за один прохід.
Фронт у вигляді SPA-додатка, написаного на JS і скомпиленого через pug, розмістимо у публічному S3 кошику. Для завантаження самих відео нам не потрібен серверний код — достатньо відкрити REST-ендпоінти, які нам передбачає S3. Єдиний момент — не забуваймо налаштувати політики та CORS.
Підводні камені
- AWS MediaConvert з якоїсь невідомої причини накладає звук тільки на кожен відеофрагмент окремо, а нам потрібна задерикувата пісня із заставки цілком.
- вертикальні відео потрібно обробляти окремо. AWS не любить чорні смуги та кладе ролики на 90°.
Ізі ковзанка
Незважаючи на всю красу Stateless, необхідно відстежувати, що потрібно зробити з відео: склеїти або накласти звук на готовий відеоряд. На щастя, MediaConvert підтримує передачу метаданих через свої Job, і ми завжди можемо застосувати простий прапор на вигляд “isMasterSoundJob”, розпаривши ці метадані на будь-якому етапі.
Serverless чудово дозволяє працювати NoOps - підходом, який передбачає непотрібність окремої команди, що відповідає за інфраструктуру проекту. Тому справа була за малим — розгортаємо рішення на AWS без участі сисадмінів, яким завжди є чим зайнятися.
А щоб все це прискорити, максимально автоматизуємо деплою скриптом на AWS CloudFormation, що дозволяє деплоїти однією кнопкою прямо з VS. У результаті, файл на 200 рядків коду дозволяє викотити готове рішення, хоча синтаксис CloudFormation з незвички може шокувати.
Разом
Serverless – не панацея. Але дуже полегшить життя ситуаціях із трьома лімітами: «обмежені ресурси—короткий термін—мало грошей».
Характеристики додатків, яким підходить Serverless
- без Long-Running процесів. Хард ліміт API Gateway – 29 секунд, хард ліміт лямбди – 5 хвилин;
- описується Event-Driven архітектурою;
- розбивається на слабопов'язані компоненти на кшталт SOA;
- не потребує великої роботи зі своїм станом;
- написано на .NET Core Для роботи з .NET Framework, як і раніше, знадобиться як мінімум Docker з відповідним рантаймом.
Переваги Serverless-підходу
- знижує витрати на інфраструктуру;
- знижує витрати на доставку рішення;
- автоматична масштабованість;
- розробка на вістрі технічного прогресу.
Недоліки на конкретному прикладі
- Розподілений трейсинг та логування – частково вирішується через AWS X-Ray та AWS CloudWatch;
- незручне налагодження;
- Cold Start за відсутності навантаження;
- User-hostile інтерфейс AWS – універсальна проблема 🙂
Джерело: habr.com