Хмара, війна і 12 волонтерів. Як EPAM бекапив дані українських університетів на сервери AWS
Після повномасштабного вторгнення українським університетам потрібно було перемістили свої дані у «хмару» — це допомогло б зберегти інтелектуальний потенціал країни у разі фізичного знищення будівель і серверів. Цим масштабним проєктом займалися спеціалісти EPAM, за що отримали відзнаку на Першій премії DOU.
Про те, як це відбувалося, чому сисадміни не завжди розуміють можливості «хмари» і як налаштування серверів AWS зменшило витрати удвічі, вони розповіли в цьому інтерв’ю. Обережно, багато технічних деталей!
У розмові взяли участь спеціалісти харківського офісу EPAM:
Денис Гриньов, керівник освітніх програм в EPAM Ukraine;
Михайло Хижняк, Service Delivery Manager;
Андрій Костромицький, EPAM Chief Talent Development Specialist & AWS Ambassador.
Денис Гриньов, керівник освітніх програм в EPAM Ukraine
«Дані університетів, які зберігалися просто в будівлях на серверах, потрібно було врятувати». Про те, як почалася співпраця
Денис Гриньов: Приблизно 15 років тому ми стали вперше контактувати з університетами Києва, Харкова і Львова. Ми шукали таланти у вишах і пропонували їм пройти співбесіду, влаштовували для них окремі зустрічі, курси. Наступним етапом стало створення спільних прикладних лабораторій. Університети були зацікавлені. По-перше, найкращих студентів ми працевлаштовували. По-друге, актуалізували програми навчання разом з активними викладачами. У доковідний час у нас діяли лабораторії в близько 30 університетах. Потім ми перейшли в онлайн, наразі укладені меморандуми про співпрацю з близько 50 університетами України.
З повномасштабним вторгненням росії ми постали перед новими викликами. Я, Михайло й Андрій були у Харкові. Це був час, коли ми, люди, шукали безпеки. Але й дані університетів, які зберігалися просто в будівлях на серверах, потрібно було врятувати.
На другий тиждень повномасштабної війни Харківський університет радіоелектроніки прийшов із запитом: «Денисе, чи можете ви якимось чином зберегти наші дані?». Після першого дзвінка ми почали комунікувати і з іншими вишами. Спрацювало сарафанне радіо. Пізніше опублікували в ЗМІ мій контакт з пропозицією допомоги.
Я згадую квартиру у Львові на Сихові, куди ми евакуювалися з Харкова, і як постійно надходили дзвінки із закладів освіти. Була велика кількість запитів, і ми не знали, скільки університетів ще звернеться. Не розуміли, які в нас ресурси, потужності, скільки буде волонтерів, хто буде ухвалювати рішення.
Ми знайшли в EPAM проєкт з акаунтом AWS, на який могли тимчасово перенести дані університетів. Запропонували вишам зосередитись на даних дистанційного навчання, які зберігалися в Moodle. Це освітня система, яку використовують більшість закладів в Україні. Наша ідея полягала в тому, щоб спочатку зробити бекап-копію даних Moodle, а потім продублювати її в клауді. Дані Moodle мали бути активними паралельно як на серверах, де вони були, так і в «хмарі». Якби щось трапилось з однією з копій, інша залишалася б активною. Ми знайшли тимчасове рішення проблеми. Воно і зараз залишається тимчасовим, хоча і масштабувалось.
У нас в підтримці є університети із західних регіонів, але на той момент ми з ними домовились, що даємо пріоритет зверненням з Херсона, Бердянська тощо. Був випадок, коли сисадмін з Бердянська вийшов з окупації просто з жорстким диском, і ми звідти взяли всі дані.
Михайло Хижняк: Бердянський педагогічний університет навіть зізнався, що якби не наша допомога, вони б уже закрилися, бо не змогли б працювати. А було й таке, що сисадмін вилазив на сосну в полі й передавав нам дані з телефону.
«Витратили 200–300 тисяч доларів». Про те, скільки спеціалістів залучено, за чий кошт втілили ініціативу та скільки вона заощадила
Михайло Хижняк: Спочатку в нас було два координатори всередині EPAM і 12 волонтерів на тимчасовій основі. Потім долучився я. На піку команда налічувала до 20 технічних фахівців. Зараз цим займається тільки дві людини. Інколи нам допомагали експерти, коли було щось складне, наприклад, Solutions-архітектори.
Денис Гриньов: Ми розуміли, що витрати певний час тимчасово лежатимуть на EPAM. Усі ці сервери та середовища розміщені на акаунті EPAM, але увесь час Amazon, за що їм велика вдячність, надають нам кредити. Пізніше вони дали знижку до 20%. На сьогодні університети досі не оплачують цей сервіс. Але це в наших планах як наступний крок.
Михайло Хижняк: Ті університети, які платитимуть самостійно, матимуть знижку 20%. Вона залишається актуальною, хоча ми поки що не знаємо, як технічно її застосувати.
Ми не можемо надати точних цифр щодо того, у скільки коштів обійшлася ініціатива, адже у нас їх немає. Ми знаємо витрати на «хмару» за весь цей час, але там є нюанси, пов’язані з витратами на експерименти, а також на неоптимізовану інфраструктуру на початку. Плюс наша зарплата. Загалом станом на сьогодні на це витратили
Щодо того, скільки потенційно це заощадило, то в нас немає даних про можливі втрати у разі найгіршого сценарію. Як і даних щодо того, скільки університети витрачали на це раніше. Але я можу надати розрахунки, які ми робили для ХНУРЕ. Вони дали запит на сервер з певною конфігурацією. Ми знайшли такий сервер у великого провайдера виділених серверів. Там він коштував близько 220 доларів на місяць, і це без бекапів. У AWS такий сервер з бекапами коштує 650 доларів на місяць, якщо його крутити 24/7 і повністю завантажувати. Але навантаження в університетів нерівномірне. Пік навантаження припадає на час пар, а от ввечері виш майже не використовує сервер. Плюс є канікули, вихідні.
Денис Гриньов: Після того як команда Михайла більш ефективно налаштувала сервери в AWS, вони стали коштувати дешевше на
Михайло Хижняк: Якщо зробити вертикальне масштабування, витрати зменшуються до 300 доларів на місяць. Вертикальне масштабування передбачає виділення більшої або меншої кількості ресурсів за розкладом. Ви можете докинути пам’яті чи додати процесор на машину. У «хмарі» це робиться у декілька кліків. У «хмарах» типу AWS оплата йде за фактичне використання.
Горизонтальне масштабування — це коли ви додаєте контейнери, машини, а коли вони вам не потрібні, вимикаєте. Вертикальне масштабування зазвичай передбачає певний незначний даунтайм. Горизонтальне масштабування може йти без даунтайму.
Ми підрахували, що з горизонтальним масштабуванням, якби невеликі сервери підіймалися за потреби, ми могли б довести цю суму до
Через рік після старту ініціативи ми дивилися на основні хмарні провайдери України для порівняння. Там сервер такої конфігурації коштує від 300 до 380 доларів на місяць. Але це без вертикального масштабування. Ми навіть не знаємо, чи можуть більшість хмарних провайдерів в Україні робити вертикальне масштабування автоматично за розкладом, а не вручну. Я думаю, що в українських провайдерів зрештою теж буде дешевше.
«Сисадміни не завжди розуміють можливості „хмари“». Про архітектуру та технічні складнощі
Михайло Хижняк: Ми використовували чотири варіанти роботи з університетами.
- Перший — це зберігання бекапів. Ми надавали місце, і вони там складали свої образи, дані як опцію останньої надії, але продовжували далі працювати з університетських серверів.
- Другий варіант — холодний резерв. Ми раз перенесли інфраструктуру, відтестували її на новому місці, але не стали на неї перемикати користувачів. Просто погасили й на вимогу університетів, коли у них були якісь зміни, підіймали, синхронізували, тестували, а потім вимикали, щоб вона не використовувала багато коштів.
- Третій варіант — гарячий резерв. Переносили все і тестували без перемикання, а потім автоматично синхронізували дані. Зазвичай рішення були простими, бо сисадміни університетів не люблять перейматися складними речами. На початку війни ми робили синхронізацію
1–2 рази на день для більшості вишів, але потім перейшли на більші паузи в1–2 тижні. Саму інфраструктуру залишали увімкнутою, але на мінімальних ресурсах, оскільки навантаження на неї не було. Якби щось відбулося з локальною інфраструктурою університету, ми могли дуже швидко перемкнутися і майже без втрати даних забезпечити роботу. - Четвертий варіант — повний переїзд. Бердянський педагогічний університет і ХНУРЕ переїжджали повністю. Університети з центральних регіонів частіше користувалися лише місцем під бекапи. Вони розуміли, що грошей на всіх не вистачить і намагалися зменшити нам бюджет. Це було дуже круто.
В останніх трьох варіантах ми перемикали домени на Route53 — сервіс DNS в AWS, щоб мати змогу швидко перемкнути інфраструктуру на нове місце.
Зазвичай до переїзду в «хмару» сисадміни університетів цікавилися, що саме вони можуть перенести. Про те, як це робити і які будуть обмеження після переїзду, деякі навіть не запитували. Беріть звідси й несіть швидше, бо невідомо, що буде.
Були цікаві історії, коли університети, користуючись можливістю, приносили майже все. А потім з’ясовували, який бюджет, і відмовлялися.
Денис Гриньов: Бувало, що університет хотів, наприклад, зберегти базу даних відділу кадрів. Ми орієнтувалися на обсяг. Якщо він був дуже великим, то зосереджувались тільки на дистанційному навчанні. Якщо була змога, брали й щось додаткове.
Михайло Хижняк: Після переїзду найчастіше потрібно було щось донести в «хмару». До нас зверталися із питаннями, чому щось припинило працювати. Декілька університетів запитували зворотний бекап, коли з хмарних серверів дані переїжджали на їхню локальну інфраструктуру. Це допомагало заощадити бюджет.
Інколи не було навіть системних адміністраторів. Наприклад, колись сисадмін щось налаштував, пішов, і на його місце нікого не призначили. Тоді ми працювали з бібліотекарями та викладачами.
Ще часом у сисадмінів велике навантаження, купа дрібної роботи, тому не завжди вони готові братися, якщо ми пропонуємо зробити щось краще.
Була також проблема з тим, що сисадміни не завжди розуміють можливості «хмари». Більшість системних адміністраторів в університетах мислять як люди, які звикли працювати із «залізом». Вони не завжди розуміють, що можуть щось взяти, використати, а потім цього позбутися. Натомість думають: ось ми взяли, а тепер хай стоїть і працює, навіть якщо воно не потрібно. На початку доводилось витрачати багато часу, щоб з’ясувати, що і навіщо їм потрібно.
Наприклад, ми отримували запит на сервер на 24 CPU і 128 Gb пам’яті. Ми запитуємо: «Навіщо вам таке?». Отримуємо відповідь: «А у нас стоїть такий сервер». Дивимось на нього, а він наполовину не завантажений. З’ясувалося, що їм такий сервер взагалі не потрібен.
Друга технічна проблема полягала в тому, що більшість університетів не мають трекінгу ресурсів. Вони не знають, наскільки ресурси завантажені. Немає історії, яка б дала змогу зрозуміти, що і як вони навантажують. Тому ми спочатку несли все, як є, а потім за фактичним використанням обрізали ресурси.
Окрема проблема — це застарілі операційні системи та застосунки. Наприклад, п’ять років тому щось поставили, і так воно досі стоїть. Працює — не чіпай.
Труднощі виникали із самописним програмним забезпеченням. Якийсь студент щось написав, воно запрацювало, він це віддав і все. Той студент уже випустився, і ніхто не знає, як воно працює та що робить.
Створювали проблеми й плагіни Moodle, написані під один інстанс, тобто їх неможливо масштабувати. Коли його писали, адмін вважав, що це працюватиме лише на одній машині на одному вебсервері, тому варіантів поставити його паралельно на дві машини вже немає. Коли сисадміни університетів кажуть, що вони без такого плагіну обійтися не можуть, а замінників немає або вони дуже дорогі, це ускладнює горизонтальне масштабування.
Ще університети не завжди вчасно робили оновлення, залишали відкритими порти. В EPAM є багато сканерів, які перевіряють безпеку. І коли ми щось приносили, наступного дня могла прийти купа критичних сповіщень, з якими треба було розібратися протягом тижня. Якщо в університеті ще й не було сисадміна, доводилося лізти на сервер і методом тика з’ясовувати, як воно працює.
Ми прагнули оновити все, що можна було, не поваливши університетські акаунти. Хоча іноді зробити всі оновлення було неможливо, наприклад, якщо була залежність від певного програмного забезпечення.
Важливо було виділяти ресурси під фактичне використання. Було багато замін дисків на дешевші. Нерідко ми з’ясовували, що частину інформації замість SSD можна зберігати на HDD, що дешевше. Застосовували горизонтальне і вертикальне масштабування. Інколи на канікули вручну вимикали сервери, що не були потрібні. Робили й захист від DDoS-атак, адже вони виїдали купу ресурсів.
Деяких специфічних технічних компетенцій нам бракувало, зокрема ми не мали досвіду роботи з Moodle. Як він налаштований, що у нього всередині. Що потрібно для того, щоб він працював нормально.
Інколи від нас потрібні були рішення, які можуть ухвалювати люди з дуже глибоким знанням баз даних, якого у девопсів зазвичай немає. Не завжди вдавалося знайти такого спеціаліста, тож доводилося розбиратися самим. Якби це була комерційна ініціатива, ми знайшли б DBA, який би нам все зробив, але йшлося про волонтерську допомогу.
Ми зверталися до AWS, щоб вони нам пояснили, як працюють промокоди та Cost Explorer, тобто як вони рахують кошти з усіма цими промокодами. З технічним питанням ми звертались до AWS один раз, коли розбирались з горизонтальним масштабуванням Moodle на ХНУРЕ. Solutions-архітектор з боку AWS швидше, ніж ми, дійшов висновку, що нам бракує горизонтального масштабування для одного з плагінів і треба міняти плагін. Допоміг досвід.
Андрій Костромицький, EPAM Chief Talent Development Specialist & AWS Ambassador
«Якщо когось цікавлять швидкі гроші, то йти треба точно не в DevOps». Про професію системного інженера й те, яких фахівців бракує
Андрій Костромицький: Systems Engineer — це професія, де необхідний рівень можна отримати тільки завдяки тривалому практичному досвіду. Є вдосталь тих, хто вважає, що вони достатньо знають, але насправді мають початковий, базовий рівень. Можна підняти сервер у «хмарі» і вважати себе хмарним спеціалістом, але цього вже недостатньо. Технології розвиваються, складність зростає, і вимоги до фахівців на всіх рівнях від Junior до Senior постійно підвищуються.
Звичайно, є менше фахівців, які можуть налаштувати ШІ в «хмарі», ніж тих, хто робить звичайні речі. Ще один популярний напрям — Data. Обробка та аналіз даних, Big Data. Таких спеціалістів теж мало. Але й попит на них значно менший, ніж, скажімо, на класичного Cloud & DevOps спеціаліста.
Щодо конкретних клаудів, то у мене є враження, що навчальні матеріали від Azure почали впроваджувати в навчальні програми українських університетів раніше, а останніми роками активно додають AWS.
Михайло Хижняк: Але це нічого не говорить про якість спеціалістів. Раніше можна було орієнтуватись на сертифікації, а нині не всі за них беруться та не всі їх складають.
Андрій Костромицький: До речі, в межах однієї AWS можна виділити різні напрями, а саме спеціалісти з безпеки, архітектори рішень, розробники та ще багато інших.
DevOps — це не просто набір інструментів та знань, це культура. Хоча без інструментів ніяк і потрібно опанувати їх. Але варто розуміти також мережі, програмування. Буває, що доводиться вивчити нову мову за два тижні. На велику команду може бути
Михайло Хижняк: Один з найскладніших моментів для інженера — це зрозуміти, що гроші є ще одним виміром ефективності роботи. Бо більшість не розуміє, чому вони взагалі мають турбуватись про витрати. Це можна порівняти з подачею води за абонентською платою або за лічильником. Якщо інженери не рахують гроші, можна спіймати великі суми. Раніше гроші були для керівника, а зараз будь-який інженер може додати тисячу доларів в момент. Інколи складно пояснити людям, що це тепер також міра їхньої ефективності.
Андрій Костромицький: Крім грошей, є ще швидкість виходу на ринок, складність підтримки, підхід до моніторингу. Наприклад, можна налаштувати моніторинг, який показуватиме все, але скільки на це буде витрачено часу та коштів? З багатьох чинників треба вміти вибрати оптимальне рішення.
Михайло Хижняк: Так, суть не в тому, щоб економити кошти, а в тому, щоб обрати оптимальний варіант з погляду користі та витрат. Наприклад, хай буде на 10 доларів дорожче, але воно працюватиме надійно.
Андрій Костромицький: Новачкам не варто розраховувати, що за кілька місяців вони опанують цей напрям з нуля та будуть готові до роботи в продакшені. Якщо когось цікавлять швидкі гроші, то йти треба точно не в DevOps.
Якщо говорити про те, що саме потрібно вивчати, то, по-перше, це мережі, бо це основа. Якщо не буде розуміння, як працюють мережеві сервіси та глобальна мережа, буде складно рухатись до більш складних питань.
По-друге, сервери та Linux, операційні системи типу Unix. Ще краще, якщо людина знає, як працюють Windows-сервери. Без розуміння, як працює всередині операційна система, буде складно.
По-третє, скриптинг. Щоб автоматизувати деякі процеси, потрібно писати скрипти, починаючи з Bash, далі Python, потім за потреби інші мови: Groovy, Ruby.
По-четверте, контейнеризація. Контейнери широко використовуються, тому треба знати, як працює Docker. Подивитися Kubernetes.
По-п’яте, CI/CD. Опанувати хоча б безплатний Jenkins. Додати до CI/CD тестування. Ознайомитись з інструментами, які використовують автоматизатори. Всередині їх налаштує автоматизатор, але DevOps повинен це інтегрувати в один робочий пайплайн.
Звісно, Git. Це для будь-кого в IT необхідно, як для офісного працівника Word.
І нарешті клауд, куди ми будемо все це деплоїти наприкінці делівері. Топові клауди — це AWS, Azure, Google Cloud. Можна почати з одного. В клауді треба знати сервери, контейнери, безсерверні рішення, сховища, бази даних, мережеві сервіси, інструменти, моніторинг, логування, різні архітектурні патерни та найкращі практики, економіку клауду та багато іншого.
«Закупівлі через тендери несумісні з „хмарами“». Про проблеми та плани
Денис Гриньов: Проєкт зі збереження даних університетів у «хмарі» триває. Нині найбільшою перешкодою для зростання є правові аспекти. Ми стикнулися з тим, що університети не можуть укласти прямий договір з AWS, тому що є обмеження оплати в еквіваленті у валюті.
Михайло Хижняк: Проблема в тому, що закупівлі через тендери несумісні з «хмарами». «Хмари» — це завжди витрати за фактом. Потрібно — використовуєш, не потрібно — не використовуєш. А тендер — це зобов’язання використати фактичну суму. Виходить так, що університети не можуть укласти договір з AWS, Microsoft або іншим хмарним провайдером, бо не знають, скільки грошей на це піде. Якщо буде потрібно сплатити більше, то до них прийде контрольно-ревізійна служба і запитає, що вони собі думають. Якщо витратять менше, буде те саме. Тому виші не дуже хочуть під це підписуватись.
Друга проблема в тому, що AWS, Microsoft і Google не беруть участі в тендерах безпосередньо. Потрібен посередник, а це знову ж таки корупційний ризик. Ми знайшли некомерційного посередника, але все одно університети бояться, бо для них це може бути потенційною проблемою. А якщо немає договору, який пройшов через тендер, то не можна дати доручення казначейству перевести гривні з рахунку університету в долари, щоб розрахуватись. При цьому доларовий облік у вишах — це окрема бухгалтерія і купа проблем зі звітами.
Хоча університетам було б вигідніше працювати з «хмарою» напряму, ніж брати сервери як «залізо» чи працювати з українськими хмарними провайдерами. Я сподіваюся, що одного дня українські провайдери зможуть конкурувати з AWS, але поки що вони не дотягують до його рівня. Сервісів у AWS більше, а вартість нижча.
В Європі 2019 року створили консорціум OCRE (Open Clouds for Research Environments). Університети об’єдналися і зробили один тендер на всі «хмари» для всіх університетів, який виграв OCRE. Там все прозоро в плані витрат, і більшість закладів можуть користуватися «хмарою». В них це іде як витрати на електроенергію, тобто якщо сьогодні потрібно більше, вони більше платять. 2022 року OCRE закінчився, з
В Україні ж ухвалили закон про хмарні ресурси, зробивши ще гірше для університетів. Тепер університет повинен закуповувати хмарні ресурси не просто через тендер, а ще й у постачальника з реєстру, якого ще немає, і ніхто не знає, хто буде в цьому реєстрі.
Денис Гриньов: Якщо говорити про наші плани, то, по-перше, продовжуємо технічно, по-друге, шукаємо рішення технічних блокерів, по-третє, продовжуємо навчати студентів. Близько 180 тисяч студентів навчаються в університетах, дані яких були перенесені в межах ініціативи. Це близько 20% від усіх студентів в Україні.
