VanOnGo стає безсерверним

tech

Для того, щоб розібратися що таке AWS serverless technology, ми поговорили з Володимиром Інюточкіним, Devops Engineer компанії Vanongo.

 

Що ж таке AWS serverless technology?  

У AWS є кілька serverless-технологій, у VanOnGo ми ж активно використовуємо дві - це AWS lambda і AWS fargate. Але спочатку давайте згадаємо класичну схему.

Коли ми працюємо за класичною схемою з хмарою, ми платимо певну суму, і нам за це виділяють на постійній основі деякий набір ресурсів, які, зрештою, обраховуються на конкретних пристроях. Тобто в Амазону є дата-центри, з величезною кількістю серверів, з кондиціюванням, з резервним живленням, і так далі. Ця інфраструктура споживає електрику, і вимагає комфорту від співробітників. Тож, якщо ми працюємо за класичною схемою, то ми ці ресурси бронюємо, і чекаємо на запит від клієнта. А ресурси в цей час простоюють. У Амазона, природно, є алгоритми, як це все оптимізувати, як і будь-якого хмарного провайдера, але вони все одно не мають ККД 100%. Це була класична схема.  

А в чому суть serverless? А суть serverless у тому, що якийсь дуже-дуже недорогий ресурс, у нашому випадку це AWS API gateway, тобто АРІ шлюз, ми залишаємо очікувати запитів. Він бачить - є запит від користувача, дамо йому доступ до нас в адмінку. Після цього, замість того, щоб відправляти його в уже готове середовище, яке стоїть і чекає на цей запит, він відправляє цей запит у AWS, і той уже, на якихось вільних фізичних машинах, де ще є вільний ресурс, за процесором, за пам'яттю - обробляє відповідь. Таким чином у нас ККД по фізичному "залізу" зростає в рази як мінімум. Чому це важливо? Тому, що всі ці складові споживають велику кількість ресурсів і, відповідно, залишають чималий вуглецевий слід. 

Це десь нагадує наш OnGO Fleet і наші non-logistic фліти, коли є у певного клієнта недозавантажені машини і ми їх фактично завантажуємо нашими замовленнями. Ок, ти сказав, що ми використовуємо ще два продукта - serverless lambda и serverless fargate. Розкажи про них, будь ласка.

Суть лямбди в тому, що ми абстрагуємо наш код, над яким працюють мої колеги, від середовища, в якому це все запускається - від операційної системи, від файлової системи, настільки, наскільки це можливо. А використовується саме ізольоване середовище, яке створює сам AWS для опрацювання одного єдиного запиту, який у цю лямбду потім прилітає.  

Є так звана “function of the service” концепція. Таке є ще у кількох провайдерів, але найкраще це реалізовано, наскільки мені відомо, таки у AWS. У AWS це все досить ефективно в плані вживаних ресурсів і, відповідно, витрат.

Що це означає для компанії?

Для нас це перевага, зокрема, в тому, що ми економимо гроші, бо якби ми платили за stand by run time всіх наших лямбда функцій, якби вони були там, припустімо, у форматі контейнера, вони працювали, і ми б оплачували дуже великі рахунки.  А так ми економимо гроші, так ми економимо електрику, так ми економимо площі для AWS, тобто ми як клієнт - не створюємо надто великого запиту на розширення дата центру. І, як результат, зменшуємо загальний вуглецевий слід. 

Тобто можна сказати, що це бізнес-модель - pay as you use, правильно?  

Так, абсолютно, рау-as-you-go повний. Тобто там stand by ресурси це по суті API-гейт, який я сказав - він стоїть і чекає, але оскільки він, загалом, один на всіх, то він (API-гейт, - прим. ред.) розумно розмежовує запити через DNS по клієнтах. 

А тепер давай більш детально про fargate.

Fargate це частина послуги Amazon, яка називається ECS - elastic container service, він має два режими. Це якраз таки ось ці stand by ресурси, які ти в них купуєш і потім на цих викуплених ресурсах через АРІ ECS використовуєш ті, контейнери, які вважаєш за потрібне. Ми ж працюємо навпаки - ми працюємо в режимі fargate. Це теж чистий serverless, але він призначений вже якраз таки для того, щоб використовувати контейнери, а не функції, як у лямбді. У нас, наприклад, через fargate запускається солвер.   

Цікавий момент, фактично технологія лише називається serverless, вона ж все одно використовує якісь фізичні сервера, просто в режимі надання залишкового інвентаря? 

Так, serverless це не ідеальний термін. У будь-якому випадку, обчислення повинні проводитися в кінцевому рахунку на якомусь фізичному пристрої, який підключений до інтернету через інші пристрої. Але чому вона називається serverless, тому що клієнт не переймається обслуговуванням сервера, це бере на себе провайдер. Він робить це в автоматичному режимі, він робить це дуже ефективно, враховуючи свої best practices, під кастомні прошивки цього самого "заліза".

В результаті, це теж дуже сильно економить людські ресурси, ресурси на обслуговування, подовжує життя комп'ютерів, тому що в комп'ютерів та інших пристроїв теж є свій лайфсайкл, і на тих масштабах, якими оперує Амазон, цими лайфсайклами можна керувати, і вони це роблять досить ефективно.  

Тобто тут фактично виходить win-win-win ситуація. Win для Амазона, що вони дозавантажують свої потужності, тобто в них нема часу очікування або він зменшується. Win для VanOnGo, тому що ми купуємо ті об’єми  обчислювальних потужностей, які нам треба і коли нам треба, і, відповідно, платимо за це менше. Win для планети і суспільства, тому що зменшується карбоновий слід від цієї співпраці.  

Так, і тут з'являється взагалі таке поняття, як управління лайсайклом пристроїв. Тому що якби старі "залізяки" спробувати вкласти в класичну модель, то навряд чи хтось тоді продав у такий спосіб, грубо кажучи, через три роки після релізу процесорного сімейства. Жоден корпоративний клієнт, який купує пристрої або вітруалки, не став би якісь справді серйозні лоади пускати навіть на пристрої, яким більше 3-х років. Це було б для них економічно неефективно.  

Скільки потрібно зусиль для того, щоб користуватися цією технологією з боку нас, як клієнта Амазону?

А з нашого боку для цього потрібно зусиль більше, для цього потрібна вища кваліфікація інженерного персоналу, це означає, що потрібно наймати людей, які вміють вчитися. Чим ми, власне зараз і займаємося в компанії, по 40 годин на тиждень. Але це великий плюс для skills and abilities and knowledge наших інженерів. 

Це класна штука, це значить, що як команда ми можемо навчитися будь чому і використовувати будь-які технології і генерувати нові.