Як AWS-сертифікація допомагає оптимізовувати витрати на проєкті

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт, мене звати Ігор Хаустов. Я Senior Cloud Engineer в Forte Group, і зараз тісно працюю з Amazon-сервісами. В цій статті я хочу зробити короткий огляд на сертифікацію AWS, чи варто її отримувати, і поділюсь способами оптимізації бюджетів в AWS Cloud, в яких я розібрався глибше саме після отримання сертифікації, і які допомогли мені прокачати мій рівень як спеціаліста.

Про сертифікацію

Для початку коротко нагадаю про рівні сертифікації AWS. Practitioner — найпростіша і підходить для нетехнічних людей. Її складають спеціалісти напрямку Sales, HR — тобто ті, хто неглибоко розбирається в AWS.

Наступний рівень Associate — для девелопера, архітектора, SysOps. Я склав усі іспити цього рівня.

І останній рівень Professional, який необхідний для DevOps та Solutions Architect.

Також є Specialty Certifications, назва яких говорить сама за себе: вони спеціально розроблені для сертифікації в конкретних напрямках — наприклад, в data science, big data, security, machine learning. Я планую складати наступним саме в галузі security.

Поділіться в коментарях нижче, хто теж планує отримувати сертифікацію AWS і якого рівня.

Для чого потрібна сертифікація

По-перше, якщо потрібні структурованіші і глибші знання для роботи в AWS. До сертифікації я вчив AWS по відео в YouTube, читав різноманітні мануали, набивав шишки на практиці.

Але саме сертифікація допомогла мені все розставити по місцях в голові. Перед тим, як я складав сертифікацію SysOps, то знав загальні речі про CloudWatch. Але саме після сертифікації я вивчив це вздовж і впоперек і зрозумів, що в CloudWatch є круті можливості, які особливо ніхто не використовує (як, наприклад, фільтрація логів, можливість знаходити помилки по фільтрації).

Цей мобільний інструмент дуже спрощує роботу. Згадую, як освоїв, що CloudWatch-метрики можна поставити на локальні сервери, і це реально круте робоче рішення для багатьох проєктів. Сертифікація звертає увагу на такі деталі, які і роблять тебе професіоналом з problem-solving skills.

Ще один приклад. Девелопери часто пишуть connections до бази даних. Саме сертифікація допомагає розібратись, як краще це зробити, як можна пофіксити помилки, що краще зробити в коді для цього конекшену.

Крім цього, сертифікований спеціаліст починає глибше розбиратись в питаннях FinOps або, простіше, оптимізації затрат клієнта на AWS, а це вже зовсім інший рівень професіоналізму. Про це я розповім нижче в статті, адже саме складаючи іспит на сертифікацію, я заглибився в питання оптимізації бюджетів. Девелоперам сертифікація однозначно дозволяє прокачати свої навички.

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

Часто в самих клієнтів є запити на сертифікації. Більшість проєктів мають готову інфраструктуру, і саме AWS займає 40% ринку Cloud. Я помітив, що коли в Україні розпочалась повномасштабна війна, всі особливо почали заглиблюватися в клауди — це зручно і безпечно.

Наприклад, раніше дата-центри того ж ПриватБанку були розташовані в Україні. Вони зрозуміли, що якщо щось станеться з даними, ситуація вийде з-під контролю. Тому після початку повномасштабної війни ПриватБанк найняв команди спеціалістів і за 45 днів переїхав в AWS. AWS дає близько 99.95%-100% гарантії, що дані будуть в порядку і з ними нічого не станеться.

А тепер про реальні робочі моменти. До вас приходить клієнт і питає, як цей сервіс буде працювати з нашим застосунком. Можна відповісти: «Не знаю, треба читати документацію» або зразу дати відповідь. Ви швидше орієнтуєтесь у робочих питаннях, бо розумієте як все влаштовано, і клієнт бачить, що його проєктом займається тямущий спеціаліст, з яким він хоче йти далі. Ми часто чуємо від клієнтів запит, що щось не працює, чи прохання порадити рiшення, щоб отримати потужну базу даних. Сертифікація покриває це.

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

Додатково, великі компанії вимагають сертифікацію, в тому числі AWS, щоб стати лідом. І можна завчасно про це потурбуватись, якщо у вас є амбіції очолити команду.

По-третє, сертифікація дає бонуси як людині, яка її отримала, так і компанії, де вона працює. Компаніям вигідно сертифікувати спеціалістів. Одна з вимог партнерства з AWS — це AWS Certifications. До таких компаній звертається більше клієнтів. Також Amazon своєму партнеру надає фінансові стимули. Це дуже вигідно з точки зору бізнесу.

Коли ви отримуєте сертифікацію, вас додають до закритого клубу для AWS-сертифікованих. Там можна ставити питання, отримувати знижки на заходи, а також є шанс потрапити в преміум-зал. Якщо ви складаєте самі, не коштом компанії, де працюєте, — отримуєте 50% знижку на кожен наступний етап сертифікації.

І нарешті, хочу сказати, що в кризові часи потрібно вкладатися в саморозвиток. Я не зроблю відкриття, якщо скажу, що завжди найкраща інвестиція — це знання і навички, особливо, коли попереду невизначеність.

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

Далі я хочу детальніше зупинитись на одному з пунктів, чому все ж таки сертифікація потрібна. Саме процес отримання сертифікації структурував моє розуміння оптимізації витрат. А це той рівень професіоналізму, який потрібен для роботи з клієнтом.

Як оптимізувати затрати в AWS

Я вже згадував, що для оптимізації витрат в AWS існує підхід FinOps. Він дозволяє управляти витратами всієї клауд-інфраструктури. Це повноцінна централізована система, де можна контролювати витрати клієнта, зменшувати їх і використовувати найкращі практики.

Як в загальному це працює? Створюються дашборди, які дозволяють слідкувати за рахунком. В такому форматі можна легко зловити момент росту цін за базу даних.

Хороший спеціаліст буде це контролювати і шукати причини, чому так відбувається. Якщо ж знань не вистачає, то проігнорує, адже просто немає розуміння, як це змінити. Як результат, зливається бюджет, і рано чи пізно у клієнта виникнуть питання.

Саме тому я хочу зупинитись на рішеннях з оптимізації, які рекомендує AWS, і які працювали в моєму досвіді.

1. Правильне управління серверами

Купуючи сервери, аналізуйте, якої потужності вам буде вистачати. Коли ми купуємо сервери Amazon, ми купуємо потужності. Наприклад, нам не потрібна віртуальна машина, в якої 32 ГБ пам’яті, адже застосунок використовує вдвічі менше. Треба купляти сервери відповідно до метрик застосунку.

Часто купляють потужні сервери для слабшого застосунку. У мене був клієнт з потужним Redis на ec2 сервері, на який компанія витрачала $6 тис. на місяць. Нам вдалося скоротити навантаження на Redis вдвічі, і в результаті зменшити місячний AWS рахунок.

Сервісів існує дуже багато. Є безкоштовні опенсорсні рішення, які можна встановити на сервери. А є сервіси AWS, коли ти платиш за кількість запитів, даних або за час роботи. В тестах іспиту AWS буде рекомендувати використовувати AWS-сервіси. В житті ж це не завжди потрібно. Їхні сервіси непогані, але не всі сервіси є сенс використовувати.

В Amazon за всі дії платяться гроші. В AWS є ліміти на безкоштовні дії з AWS сервісами. Треба розуміти як працює застосунок, чи потрібен AWS Nat gateway, пропускна здатність якого теж коштує грошей. Якщо застосунок буде виходити в публічний інтернет, а потім повертатись в AWS, це дорого.

Тому AWS радить не виходити за межі AWS, а все робити в його середовищі. Бо це безпечно (ніхто не перехопить дані) і дешевше, а в деяких випадках — навіть безкоштовно.

У одного мого клієнта був гарний приклад оптимізації: у нього був NAT gateway, і відповідно дорогуватий трафік. Ми встановили звичайний сервер і зробили його а-ля NAT gateway. В сертифікатах не рекомендують це використовувати, але насправді в житті сервер NAT gateway дешевше і не гірше, ніж NAT gateway від Amazon. І це працює.

Хочеться сказати ще про Spot-сервери AWS. У них є пул серверів, але їх у тебе можуть забрати у будь-який момент. Наприклад, ти відправляєш риквест в Amazon на сервер певного типу. Вони дають цей сервер. Він пропрацював 2 дні.

Уявимо, що у нас застосунок на 10 серверах. Amazon забрав декілька з них, бо хтось зробив запит на такий же сервер. Застосунок нічого не відчує, якщо у нас всі ці 10 серверів мають спот-тайп, всі вони працюють як споти і застосунку потрібне тільки їхнє навантаження.

Якщо вони нічого не зберігають всередині сервера, то це ідеально. За умови, що у вас багато застосунків, воркери, big data, і потрібен тільки ресурс і потужність, то використовувати споти безпечно і економно. Навіть якщо якийсь із серверів перезапуститься, це ніяк ні на що не вплине.

Але врахуйте, що не для всіх типів застосунків це працює. Наприклад, для бази даних таку схему не можна використовувати. Треба розуміти, що використовувати на споті, а що ні.

Також, слід бути готовим ще й до такої неприємної ситуації. Буває в Amazon немає потрібних серверів. Заявка висить, а Amazon відмовляє в серверах певного типу. Тоді клієнт стукає і говорить, що застосунок не працює. Тут є свої лайфхаки: беріть не один тип сервера, а 5 типів серверів. Якщо у Amazon немає певного типу, то є інший, і застосунок продовжить працювати.

2. Saving Plan

Після правильного обрання потужностей серверів, переходимо до цього пункту. Уявимо ситуацію: нам потрібні 10 серверів для продакшена. На цих серверах буде працювати застосунок і база даних. Ми вже знаємо, що нам ці сервери підходять (їхній тип, потужність) і нам вони потрібні на 3 роки.

Ми можемо купляти saving plan. Якщо ми купуємо прямо зараз сервер на 24 години, то будемо платити найдорожчу ціну. Але якщо впевнені, що будемо його використовувати 1 рік, то можемо включити saving plan, заплатити відразу і отримати знижку 50-70%.

Насправді спеціалісти часто не підключають цей план, хоч використовують якийсь сервер дуже давно. Amazon сам часто пропонує через механізми Compute Optimizing та Cost Management вибирати слушні сервери, оптимізувати витрати і увімкнути saving plan. Не ігноруйте цього.

3. Serverless-технології

Їм не потрібна база. З ними не потрібні сервери. Вони дешеві, бо ви платите лише за виконання функції. Можна написати застосунок, який буде працювати в AWS завдяки Lambda, за який не треба буде платити. Безкоштовний рівень Lambda включає 1 мільйон безкоштовних запитів і 400 000 ГБ-секунд обчислювального часу на місяць.

У мене була задача від клієнта, який нещодавно купив новий проєкт. Цей проєкт був на Oracle Cloud. Проаналізувавши шалений білінг, вони вирішили переїхати на AWS. Я робив цей переїзд і оптимізовував витрати на білінг.

Який підхід у мене був? Взагалі я помітив, що дуже багато серверів, на яких працюють тестувальники і девелопери, активовані доба за добою, а в клауді є така схема: скільки працюєш, стільки і платиш. З цього робимо висновок, що якщо потрібно, щоб сервер працював не 24 години, а 8 годин, його можна вимикати.

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

Ще один плюс від такого рішення: можна знайти багато багів. Бо буває, вимкнувши сервери, а потім їх знову запустивши, застосунок починає себе дивно поводити. Так можна повідловлювати помилки в роботі.

Важливо: Serverless не завжди достатньо. Його не треба використовувати, якщо дуже багато риквестів у застосунку. Наприклад, щодня 1000+ запитів. Якщо ж нам потрібно, щоб система працювала постійно, не в певний час, то Serverless теж не підходить.

4. Правильно вибирати AWS Backup

Головне в бекапах — розуміти, який тип нам потрібен, бо від цього залежить сума витрат.

Чим дорожчий бекап — тим більший тип. Внизу я підібрав картинку, яка чудово візуалізує типи бекапів та їхні можливості.

При виборі бекапу треба враховувати два моменти: recovery time object (RTO) і recovery point objective (RPO). Як це працює? В нас є бекапи в різних регіонах. Якщо в якомусь стається стихійне лихо чи падає сервер, ми переходимо на сервер іншого регіону.

Тобто recovery time object — це час, протягом якого клієнти можуть переключитись на новий бекап. Наприклад, Pilot Light Backup дозволяє зробити це за 10-15 хвилин. Для багатьох сфер, як-от банківська, відсутність бекапів була б критична.

Найпопулярніші типи бекапів — pilot і warm standby. В чому різниця цих бекапів, окрім часу відновлення? В Pilot Backup, наприклад, треба відновитись в Америці чи Франції, коли сервери перестали працювати в Італії. Нам потрібна база даних, повністю всі застосунки, стораджі.

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

Warm standby дорожчий, бо дає ширші можливості. Розглянемо приклад з великим застосунком з великою кількістю даних. У нас працює база даних, сервери, критичні застосунки. Нам не потрібно повністю копіювати інфраструктуру для всіх регіонів, тому що вона гігантська, і це буде коштувати мільйони.

Раптово він «лягає» в якомусь регіоні. У нас є попередньо копія інфраструктури, але меншого об’єму, тому переїзд на неї буде адекватним рішенням, яке не помітять користувачі.

Ціна буде дорожча, ніж коли сервер вимкнений як в попередньому прикладі, але дешевше, ніж коли інфраструктура повністю скопійована.

Найкрутіший бекап — це multi-site. В цьому випадку у нас є дві однакові інфраструктури. Наприклад, щось лягає в регіоні, ми перемикаємо на новий регіон, а там все працює так само миттєво.

Ви можете змінювати розмір бекапу. Наприклад, у нас є бекап маленького розміру, ми можемо скейлити його до більшого розміру. Тобто якщо сервер купили дуже потужний і з часом зрозуміли, що є сенс зменшити, робіть це.

Якось я проводив співбесіду і запитував про бекапи. Я помітив, що люди просто знають, що можна забекапити, але не знають різниці бекапів. Сервери можуть називатись Т2, R5, Т3, D2 і т.д. (instant types), і зазвичай на це не звертають увагу. І я раніше якось теж не звертав.

Якщо вам потрібно багато пам’яті, то краще підійде тип R. Це як, наприклад, використовувати паркомісця: треба купляти відповідно до розміру машини. Не можна вантажівку ставити на місце, призначене для легкового автомобіля. Це важливо розуміти, тоді застосунок буде краще працювати.

Ось, як можна підсумувати способи оптимізації витрат, про які я розказав:

Висновки

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

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