Конференція Хабра – історія не дебютна. Раніше ми проводили досить великі заходи Тостер на 300-400 осіб, а зараз вирішили, що актуальними будуть невеликі тематичні зустрічі, напрямок яких можете ставити і ви, наприклад, у коментарях. Перша конференція такого формату відбулася в липні і була присвячена бекенд-розробці. Учасники слухали доповіді про особливості переходу з бекенду в ML та про влаштування сервісу «Квадрюпель» на порталі «Держпослуги», а також взяли участь у круглому столі, присвяченому Serverless. Тим, хто не зміг відвідати захід особисто, у цьому пості ми розповідаємо найцікавіше.
З бекенд-розробки до машинного навчання
Чим займаються дата-інженери у ML? Чим подібні і чим відрізняються завдання бекенд-розробника та ML-інженера? Який шлях слід пройти, щоб змінити першу професію на другу? Про це розповів Олександр Парінов, який пішов у машинне навчання після 10 років бекенду.
Олександр Парінов
Сьогодні Олександр працює архітектором систем комп'ютерного зору в X5 Retail Group і контриб'є в Open Source проекти, пов'язані з комп'ютерним зором і глибоким навчанням (github.com/creafz). Його скіли підтверджує участь у топ-100 світового рейтингу Kaggle Master (kaggle.com/creafz) — найпопулярнішої платформи, яка проводить змагання з машинного навчання.
Навіщо переходити на машинне навчання
Півтора роки тому Джефф Дін, глави Google Brain – проекту Google з дослідження штучного інтелекту на основі глибокого навчання – розповів, як півмільйона рядків коду в Google Translate замінили нейронною мережею на Tensor Flow, що складається лише з 500 рядків. Після навчання мережі якість даних зросла, а інфраструктура спростилася. Здавалося б, ось наше світле майбутнє: більше не доведеться писати код, достатньо робити нейронки та закидати їх даними. Але на практиці все набагато складніше.
ML-інфраструктура в Google
Нейронні мережі - це лише невелика частина інфраструктури (маленький чорний квадратик на зображенні вище). Потрібно ще багато допоміжних систем, щоб отримувати дані, обробляти їх, зберігати, перевіряти якість тощо, потрібна інфраструктура для навчання, розгортання машинного навчання в продакшені, тестування цього коду. Всі ці завдання схожі на те, чим займаються бекенд-розробники.
Процес машинного навчання
Чим відрізняється ML від бекенда
У класичному програмуванні ми пишемо код, і це диктує поведінку програми. У ML у нас є невеликий код моделі та багато даних, якими ми закидаємо модель. Дані в ML дуже важливі: та сама модель, навчена різними даними, може показувати зовсім різні результати. Проблема полягає в тому, що майже завжди дані розрізнені та лежать у різних системах (реляційні бази даних, NoSQL-бази, логи, файли).
Версіонування даних
ML вимагає версіонування як коду, як і класичної розробці, а й даних: необхідно чітко розуміти, у чому навчалася модель. Для цього можна скористатися популярною бібліотекою Data Science Version Control (dvc.org).
Розмітка даних
Наступне завдання – розмітка даних. Наприклад, відзначити всі предмети на картинці чи сказати, якого класу вона належить. Цим займаються спеціальні сервіси на кшталт «Яндекс.Толоки», роботу з якими спрощує наявність API. Складнощі виникають через «людський фактор»: підвищити якість даних і звести помилки до мінімуму можна, доручаючи одне й те завдання кільком виконавцям.
Візуалізація у Tensor Board
Логування експериментів необхідне порівняння результатів, вибору кращої за якимись метриками моделі. Для візуалізації є великий набір коштів, наприклад, Tensor Board. Але для зберігання експериментів якихось ідеальних способів немає. У невеликих компаніях часто обходяться excel-табличкою, у великих використовують спеціальні платформи для зберігання результатів у БД.
Платформ для машинного навчання безліч, але жодна з них не закриває і 70% потреб
Перша проблема, з якою доводиться стикатися під час виведення навченої моделі в продакшн, пов'язана з улюбленим інструментом дата-саентистів Jupyter Notebook. У ньому немає модулярності, тобто на виході виходить така «портянка» коду, не розбитого на логічні шматки – модулі. Все перемішано: класи, функції, конфігурації тощо. Цей код важко версіонувати і тестувати.
Як із цим боротися? Можна упокоритися, як Netflix, і створити свою платформу, що дозволяє прямо в продакшені запускати ці ноутбуки, передавати їм на вхід дані та отримувати результат. Можна змусити розробників, які котять модель у продакшн, переписати код нормально, розбити на модулі. Але за такого підходу легко помилитися, і модель працюватиме не так, як замислювалося. Тому ідеальний варіант – заборонити використовувати Jupyter Notebook для коду моделей. Якщо, зрозуміло, дата-саєністи на це погодяться.
Модель як чорна скринька
Найпростіший спосіб вивести модель у продакшн – використовувати її як чорну скриньку. У вас є якийсь клас моделі, вам передали ваги моделі (параметри нейронів навченої мережі), і якщо ви цей клас ініціалізуєте (викличте метод predict, подайте на нього картинку), то на виході отримаєте якесь передбачення. Що відбувається всередині – не має значення.
Окремий процес-сервер із моделлю
Можна також підняти якийсь окремий процес і надсилати його через чергу RPC (з картинками або іншими вихідними даними. На виході ми отримуватимемо предикти.
Приклад використання моделі у Flask:
@app.route("/predict", methods=["POST"])
def predict():
image = flask.request.files["image"].read()
image = preprocess_image(image)
predictions = model.predict(image)
return jsonify_prediction(predictions)
Проблема такого підходу – обмеження продуктивності. Припустимо, у нас є код на Phyton, написаний дата-саентистами, який гальмує, а ми хочемо вичавити максимальну продуктивність. Для цього можна використовувати інструменти, які перетворюють код нативний або конвертують його в інший фреймворк, заточений під продакшн. Такі інструменти є для кожного фреймворку, але ідеальних не існує, доведеться допилювати самостійно.
Інфраструктура в ML така сама, як у звичайному бекенді. Є Docker та Kubernetes, тільки для Docker потрібно поставити рантайм від NVIDIA, який дозволяє процесам усередині контейнера отримати доступ до відеокарт у хості. Для Kubernetes потрібен плагін, щоб він міг зменшувати сервери з відеокартами.
На відміну від класичного програмування, у випадку з ML в інфраструктурі з'являється багато різних рухомих елементів, які потрібно перевіряти та тестувати, наприклад, код обробки даних, пайплайн навчання моделі та продакшн (див. схему вище). Важливо протестувати код, який зв'язує різні шматки пайплайнів: шматків багато, і проблеми часто виникають на межах модулів.
Як працює AutoML
Сервіси AutoML обіцяють підібрати оптимальну для ваших цілей модель та навчити її. Але треба розуміти: у ML дуже важливі дані, результат залежить від їхньої підготовки. Розміткою займаються люди, що загрожує помилками. Без жорсткого контролю може вийти сміття, а автоматизувати процес поки що не виходить, потрібна перевірка з боку фахівців – дата-саентистів. Ось на цьому місці і "ламається" AutoML. Але він може бути корисним для підбору архітектури – коли ви вже підготували дані та хочете провести серію експериментів для пошуку кращої моделі.
Як потрапити до машинного навчання
Потрапити в ML найпростіше, якщо ви розробляєте на Python, який використовується у всіх фреймворках для глибокого навчання (та звичайних фреймворках). Ця мова практично є обов'язковою для даної сфери діяльності. С++ застосовується для деяких завдань із комп'ютерним зором - наприклад, у системах керування безпілотними автомобілями. JavaScript та Shell – для візуалізації та таких дивних речей, як запуск нейронки у браузері. Java та Scala використовується при роботі з Big Data та для машинного навчання. R та Julia люблять люди, які займаються матстатистикою.
Отримувати практичний досвід для початку найзручніше на Kaggle, участь в одному з конкурсів платформи дає більше, ніж рік вивчення теорії. На цій платформі ви можете взяти чийсь викладений та прокоментований код та спробувати його покращити, оптимізувати під свої цілі. Бонус – ранг на Kaggle впливає на вашу зарплату.
Інший варіант - піти бекенд-розробником до ML-команди. Зараз багато стартапів, які займаються машинним навчанням, в яких ви наберетеся досвіду, допомагаючи колегам у вирішенні їхніх завдань. Нарешті, можна вступити в одне із угруповань дата-саентистів — Open Data Science (ods.ai) та інші.
Додаткову інформацію на тему доповідач розмістив за посиланням
«Квадрюпель» — сервіс таргетованих повідомлень порталу «Держпослуги»
Євген Смирнов
Наступним виступав начальник відділу розробки інфраструктури електронного уряду Євген Смирнов, який розповів про Квадрюпеля. Це сервіс таргетованих повідомлень порталу «Держпослуги» (gosuslugi.ru) - найбільш відвідуваного державного ресурсу Рунету. Денна аудиторія становить 2,6 млн, всього на сайті зареєстровано 90 млн користувачів, з них 60 млн — підтверджені. Навантаження на API порталу – 30 тис. RPS.
Технології, що використовуються в бекенді «Держпослуг»
«Квадрюпель» — сервіс адресного оповіщення, за допомогою якого користувач отримує пропозицію про послугу в найбільш вдалий момент шляхом налаштування спеціальних правил інформування. Основними вимогами розробки сервісу були гнучкі налаштування і адекватний час розсилки.
Як працює Квадрюпель
На схемі вище показано одне з правил роботи «Квадрюпеля» на прикладі ситуації з необхідністю заміни прав водія. Спочатку сервіс шукає користувачів, у яких термін придатності закінчується за місяць. Їм виставляється банер із пропозицією отримати відповідну послугу та надсилається повідомлення на електронну пошту. Для тих користувачів, у яких термін уже минув, банер та email змінюються. Після успішного обміну прав користувач отримує інші повідомлення – з пропозицією оновити дані у посвідченні.
З технічної точки зору це groovy-скрипти, в яких написаний код. На вході – дані, на виході – true/false, співпало/не співпало. Усього понад 50 правил – від визначення дня народження користувача (поточна дата дорівнює даті народження користувача) до складних ситуацій. Щодня за цими правилами визначається близько мільйона збігів — людей, яких треба сповістити.
Канали повідомлень «Квадрюпеля»
Під капотом "Квадрюпеля" знаходиться БД, в якій зберігаються дані користувачів, і три додатки:
- Працівник призначений для оновлення даних.
- API відпочинку забирає та віддає на портал та на мобільний додаток самі банери.
- Планувальник запускає роботи з перерахунку банерів або масового розсилання.
Для оновлення даних бекенд подієво орієнтований. Два інтерфейси – рест або JMS. Події багато, перед збереженням та обробкою вони агрегуються, щоб не робити зайвих запитів. Сама БД, табличка, в якій зберігаються дані, виглядає як key value сховище – ключ користувача та саме значення: прапорці, що позначають наявність або відсутність відповідних документів, їх термін дії, агрегована статистика на замовлення послуг цим користувачем та інше.
Після збереження даних ставиться завдання JMS, щоб негайно перерахувалися банери – це потрібно відразу відображати на вебі. Система запускається ночами: у JMS накидаються завдання з інтервалами користувачів, за якими треба перерахувати правила. Це підхоплюють обробники, які зайняті перерахунком. Далі результати обробки потрапляють у наступну чергу, яка або зберігає банери в БД, або відправляє завдання завдання на нотифікацію користувача. Процес займає 5-7 годин, він легко масштабується за рахунок того, що можна або докинути обробників, або підняти інстанси з новими обробниками.
Сервіс працює досить добре. Але обсяг даних зростає, оскільки користувачів стає більше. Це призводить до збільшення навантаження на базу навіть з урахуванням того, що Rest API дивиться в репліку. Другий момент - JMS, який, як з'ясувалося, не дуже підходить через велике споживання пам'яті. Високим є ризик переповнення черги з падінням JMS та зупинкою обробки. Підняти JMS після цього без очищення логів неможливо.
Вирішувати проблеми планується за допомогою шардування, що дозволить балансувати навантаження на базу. Також у планах змінити схему зберігання даних, а JMS поміняти на Kafka – більш стійке до відмови рішення, яке врегулює проблеми з пам'яттю.
Backend-as-a-Service Vs. Serverless
Зліва направо: Олександр Боргарт, Андрій Томіленко, Микола Марков, Ара Ісраєлян
Бекенд як сервіс або Serverless-рішення? В обговоренні цього актуального питання на круглому столі брали участь:
- Ара Ісраєлян, технічний директор CTO та засновник Scorocode.
- Микола Марков, Senior Data Engineer у компанії Aligned Research Group.
- Андрій Томіленко, керівник відділу розробки RUVDS.
Модератором розмови став старший розробник Олександр Борґарт. Ми наводимо дебати, в яких брали участь і слухачі у скороченому варіанті.
- Що таке Serverless у вашому розумінні?
Андрій: Це модель обчислень – Lambda-функція, яка повинна обробляти дані так, щоб результат залежав лише від даних. Термін пішов чи то від Гугла, чи то від Амазона та його сервісу AWS Lambda. Провайдеру простіше обробляти таку функцію, виділивши під це пул потужностей. Різні користувачі можуть незалежно зважати на одних і тих же серверів.
Микола: Якщо просто - ми переносимо якусь частину своєї IT-інфраструктури, бізнес-логіки в хмару, на аутсорс
ара: З боку розробників - непогана спроба заощадити ресурси, з боку маркетологів - заробити більше грошей
— Serverless — те саме, що й мікросервіси?
Микола: Ні, Serverless – це більше організація архітектури Мікросервіс - атомарна одиниця якоїсь логіки. Serverless - підхід, а не "окрема сутність".
ара: Функцію Serverless можна запакувати в мікросервіс, але від цього вона перестане бути Serverless, перестане бути Lambda-функцією. У Serverless робота функції починається лише тоді, коли її запитують.
Андрій: Вони відрізняються часом життя Lambda-функцію ми запустили та забули. Вона відпрацювала кілька секунд, і наступний клієнт може обробити свій запит на іншій фізичній машині.
— Що краще масштабується?
ара: При горизонтальному масштабуванні Lambda-функції поводяться абсолютно так само, як мікросервіси.
Микола: Яка задаси кількість реплік – стільки їх і буде, немає жодних проблем із масштабуванням у Serverless. У Kubernetes зробив репліка-сет, запустив 20 інстансів де-небудь, і тобі повернулося 20 знеособлених посилань. Уперед!
— Чи можна писати бекенд на Serverless?
Андрій: Теоретично, але сенсу в цьому немає Lambda-функції будуть упиратися в єдине сховище – нам потрібно забезпечити гарантованість. Наприклад, якщо користувач провів якусь транзакцію, то при наступному зверненні він має побачити: транзакцію проведено, кошти зараховано. Всі функції Lambda будуть блокуватися на цьому виклику. За фактом купа Serverless-функцій перетвориться на єдиний сервіс з однією вузькою точкою звернення до бази даних.
— У яких ситуаціях є сенс застосування безсерверної архітектури?
Андрій: Завдання, в яких не потрібне загальне сховище - той же майнінг, блокчейн Там, де треба багато рахувати. Якщо у вас купа обчислювальних потужностей, то ви можете визначити функцію типу «порахуй хеш чогось там…» Але ви можете вирішити проблему зі зберіганням даних, взявши, наприклад, від Амазона та Lambda-функції та їх розподілене сховище. І вийде, що ви пишете стандартний сервіс. Lambda-функції звертатимуться до сховища та видаватиме якусь відповідь користувачу.
Микола: Контейнерчики, які запускаються в Serverless, вкрай обмежені ресурсами. Там мало пам'яті та решти. Але якщо у вас вся інфраструктура розгорнута повністю на якійсь хмарі – Google, Амазон – і у вас із ними постійний контракт, є бюджет на все це, тоді для якихось завдань можна використовувати Serverless-контейнери. Необхідно знаходитись саме всередині цієї інфраструктури, тому що все заточено під використання у конкретному оточенні. Тобто, якщо ви готові зав'язати все на інфраструктуру хмари – можете поекспериментувати. Плюс у тому, що не доведеться зменшувати цю інфраструктуру.
ара: Що Serverless не вимагає від вас менеджувати Kubernetes, Docker, ставити Kafka і так далі - це самообман. Ті ж Амазон і Гугл це менеджують і ставлять. Інша річ, що у вас є SLA. З тим самим успіхом можна віддати все на аутсорсинг, а не програмувати самостійно.
Андрій: Сам Serverless недорогий, але доводиться багато платити за інші амазонівські сервіси – наприклад, базу даних З ними народ уже судився за те, що вони драли шалені гроші за API gate.
ара: Якщо говорити про гроші, то потрібно враховувати такий момент: вам доведеться розгорнути на 180 градусів всю методологію розробки в компанії, щоб перевести весь код на Serverless На це піде багато часу та коштів.
— Чи гідні альтернативи платним Serverless Амазона і Гугла?
Микола: У Kubernetes ви запускаєте якийсь job, він відпрацьовує та вмирає – це цілком собі Serverless з погляду архітектури Якщо хочеться реально цікаву бізнес-логіку створити з чергами, з базами, треба трохи більше над цим подумати. Це все вирішується, не виходячи з Kubernetes. Тягти додаткову реалізацію я б не став.
— Наскільки важливо моніторити те, що відбувається у Serverless?
ара: Залежить від архітектури системи та вимог бізнесу По суті, провайдер повинен надавати звітність, яка допоможе девопсу розібратися у можливих проблемах.
Микола: В Амазоні є CloudWatch, куди стримаються всі логи, у тому числі і з Lambda Інтегруйте пересилання логів та використовуйте якийсь окремий інструмент для перегляду, аллертингу тощо. У контейнери, які ви стартуєте, можна напхати агентів.
— Давайте підіб'ємо підсумок.
Андрій: Думати про Lambda-функції корисно Якщо ви створюєте сервіс на коліні – не мікросервіс, а такий, що пише запит, звертається до БД і надсилає відповідь – Lambda-функція вирішує цілу низку проблем: з багатопоточністю, масштабованістю та іншим. Якщо у вас логіка побудована подібним чином, то в майбутньому ви зможете ці Lambda перенести в мікросервіси або скористатися сервісами на кшталт Амазона. Технологія корисна, цікава ідея. Наскільки вона виправдана для бізнесу – це поки що відкрите питання.
Микола: Serverless краще застосовувати для operation-завдань, ніж для розрахунку якоїсь бізнес-логіки. Я завжди сприймаю це як event processing. Якщо у вас в Амазоні він є, якщо ви в Kubernetes – так. Інакше вам доведеться досить багато зусиль докласти, щоб підняти Serverless самостійно. Потрібно дивитися конкретний бізнес-кейс. Наприклад, у мене зараз одне із завдань: коли з'являються файли на диску у певному форматі – потрібно їх заливати в Kafka. Я це можу використовувати WatchDog чи Lambda. З точки зору логіки підходять обидва варіанти, але по реалізації Serverless складніше, і я віддаю перевагу більш простому шляху, без Lambda.
ара: Serverless – ідея цікава, застосовна, дуже технічно красива Рано чи пізно технології дійдуть до того, що будь-яка функція підніматиметься менше, ніж за 100 мілісекунд. Тоді в принципі відпаде питання про те, чи критично для користувача час очікування. При цьому застосування Serverless, як уже говорили колеги, повністю залежить від бізнес-завдання.
Ми дякуємо нашим спонсорам, які нам дуже допомогли:
- Простір IT-конференцій «» за майданчик для конференції.
- Календар IT-заходів та видання «» за інформаційну підтримку та новини.
- «» за подарунки.
- за співтворчість.
- "Асоціацію електронних комунікацій" за залученість та досвід.
- Головного спонсора - за все!
Джерело: habr.com