Від вузьких місць до проривів: як Compute API переосмислює процес надання ресурсів

Керування життєвими циклами 100,000 віртуальних машин щорічно в системах кластерного провізіонування створює значні труднощі, особливо через жорсткість структур з одним станом. Ці системи часто призводять до неефективності використання ресурсів і обмеженої адаптивності, що створює «вузькі місця» у масштабуванні та виконанні змін у вимогах інфраструктури.

Ось де на допомогу приходить Compute API, наш проєкт управління хмарними ресурсами. Завдяки застосуванню моделі, орієнтованої на ресурси — де віртуальні машини (VM), диски, прикріплення і налаштування аффінітетів керуються за допомогою окремих робочих процесів — Compute API забезпечує:

• Покращене використання ресурсів: Тонке налаштування дозволяє кращу оптимізацію.
• Модульна архітектура: Окремі робочі процеси покращують масштабованість і адаптивність.
• Покращена надійність: Роз'єднання логіки забезпечує стійкість до помилок і безперебійну відновлюваність.

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

Зміст

1. Кластерне провізіонування

• Традиційне провізіонування за допомогою Terraform
• Спостереження щодокластерногопровізіонування
• Обмеження структури Git-репозиторіїв
• Чому потрібен підхід з дрібнішими ресурсами?
• Обмеження для всього кластера

1. Compute API

• Огляд
• Атомарні стани
• Часові робочі процеси
• Станова виконуваність
• Слідкування та спостережуваність
• Надійність та стійкість до помилок
• Роз'єднана логіка
• Подієвий робочий процес
• Черги завдань та робітники
• Анатомія складного робочого процесу

1. Інсайти

• Інсайти продуктивності

1. Майбутні плани

• Забезпечення політик
• Інтелектуальне розміщення
• Удосконалення та оптимізація

1. Висновок

2. Приєднуйтесь до нас

Кластерне провізіонування

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

Традиційне провізіонування за допомогою Terraform

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

Конвеєр виконується у дві стадії:

• План: Terraform порівнює поточний стан із бажаним і генерує список змін.
• Застосування: Після перевірки та затвердження плану Terraform застосовує зміни до інфраструктури.

Ілюстрація робочого процесу інфраструктури як коду на основі Git

Спостереження щодо кластерного провізіонування

Попри свою корисність, традиційна система стикається з критичними труднощами, що впливають на ефективність і надійність.

У нашій попередній статті, Покращення управління інфраструктурою Terraform: проблеми, ми розглянули «Проблеми створення ресурсів і управління станами», зокрема труднощі, такі як неочікувані ефекти зсуву стану, тривалі часи операцій та каскадні збої в кластерах. Проєкт Compute API покликаний вирішити ці проблеми.

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

• Інцидентів
• Втрати даних
• Підриву надійності

Обмеження структури Git-репозиторіїв

Залежність Terraform від єдиного файлу стану для всіх ресурсів в директорії призводить до певних ускладнень.

Структурування кластерів Terraform в окремі директорії покращує модульність, але не гарантує забезпечення через гнучкість Git.

Структура з одним станом

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

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

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

Чому потрібен підхід з дрібними ресурсами?

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

Підхід Scalengine до станів ресурсів.

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

Обмеження для всього кластера

Попри досягнення, виникли наступні обмеження:

• Обмежене оновлення ресурсів: Зміни потрібно застосовувати до всіх VM одночасно. Наприклад, неможливо оновити лише одну VM; потрібно оновлювати всі VM разом.
• Відсутність поступових оновлень: Оновлення кластерів неможливе без здатності розгортати нові образи поетапно.
• Обмеження відновлення після помилок: Помилки часто неможливо відновити за допомогою механізму повторної спроби, що вимагає вручну втручання.
• Сценарії «мертвої блокування»: Деякі помилки залишають кластери в незворотному стані, який неможливо розгорнути чи видалити.

Проте, ідеї, отримані з Scalengine — важливість тонкої деталізації, підвищена стійкість до помилок і більша адаптивність — стали основою для розробки Compute API.

Compute API

Огляд

Compute API вводить зміну парадигми, відходячи від обмежень монолітного провізіонування.

Compute API вводить модульну структуру провізіонування, де кожен ресурс — такі як VM, диски та інші ресурси — керується незалежно за допомогою часових робочих процесів.

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

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

Атомарні стани

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

Управління атомарними станами включає розбиття стану інфраструктури на менші, керовані частини.
Кожен ресурс підтримує свій стан незалежно від інших.

Розділення станів для VM, дисків та інших компонентів дозволяє вирішувати проблеми локально, не впливаючи на несуміжні ресурси.

Тонкий підхід до станів ресурсів.

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

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

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

Часові робочі процеси

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

Виконання зі станом

Часові робочі процеси працюють з точним відстеженням кроків і стійким зберіганням стану, забезпечуючи постійний прогрес.

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

Діаграма, що показує робочі процеси з станом у Temporal.

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

Слідкування та спостережуваність

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

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

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

Надійність і стійкість до помилок

Помилки робочих процесів обробляються ефективно завдяки налаштовуваним політикам повтору.

• Транзиторну проблему під час провізіонування VM можна вирішити автоматично без ручного втручання.
• Мінімізує вплив тимчасових збоїв на загальне виконання робочого процесу.

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

Розділення логіки

Розділення логіки робочих процесів від бізнес-логіки.

• Незалежне управління робочими процесами та кодом додатків, що сприяє модульності та підтримуваності.
• Команди можуть розвивати свої робочі процеси без впливу на основну бізнес-логіку, що забезпечує гнучкість в розробці.

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

Подієво-орієнтовані робочі процеси

Часовий працює з подієво-орієнтованою архітектурою.
Цей реактивний дизайн підвищує здатність системи ефективно реагувати на умови в реальному часі.

• Робочі процеси можуть бути динамічно ініційовані або активовані у відповідь на конкретні події.
• Реактивність до вхідних даних у реальному часі, що забезпечує адаптивну та ефективну поведінку системи.

Такий подієво-орієнтований підхід забезпечує більшу гнучкість системи, роблячи Compute API ідеальним для обробки динамічних навантажень та потреб в автоматизації в реальному часі.

Черги завдань та працівники

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

Забезпечуючи, що черги завдань управляють окремими, специфічними для ресурсу завданнями, такими як створення VM, провізіонування дисків чи виконання правил affinity, система може краще ізолювати та контролювати переходи станів для кожного ресурсу.

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

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

Анатомія комбінованого робочого процесу

Динамічна візуалізація комбінованого робочого процесу створення _VM._

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

1. Ізоляція: Кожен дочірній робочий процес працює незалежно, не залежачи від основного працівника, на якому він виконується.
2. Паралелізм: Ресурси, такі як VM і його диски для зберігання даних, створюються одночасно. Після завершення цих операцій виконуються наступні кроки, такі як налаштування конфігурацій Attachment у постачальника.
3. Динамічна стандартизація: Одночасно дочірній робочий процес ConfigureBase забезпечує, щоб VM відповідало стандартам Trendyol.

Після завершення налаштування Attachment налаштовуються диски на VM на фінальному етапі, роблячи їх працездатними та готовими до використання.

Інсайти

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

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

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

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

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

Нарешті, небажані ефекти ковзання, з якими часто стикаються в Terraform, коли ресурси управляються як масив, і незначні коригування можуть призвести до небажаних оновлень на несуміжних ресурсах, були ефективно вирішені. Ізоляція станів в Compute API запобігає цим каскадним проблемам, забезпечуючи більш передбачуване та надійне управління інфраструктурою.

Інсайти продуктивності

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

Стратегія Git-based plan/apply працює добре для простих операцій, але з ростом складності виникають значні уповільнення.

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

Кожен _VM має 3 диски даних, а паралелізм Terraform встановлено на значення за замовчуванням 10. Завдання GitLab Plan & Apply, ймовірно, виконуються по черзі. Ось y-вісь, яка відображає час, витрачений у хвилинах._

У порівнянні з цим, Compute API перевершує підвищену складність, забезпечуючи 60% швидше створення ресурсів та 75% швидше видалення для стандартних завдань.

Коли операції масштабуються до 30x навантаження, її ефективність зростає ще більше. Вона досягає 77% швидшого створення та 83% швидшого видалення, демонструючи свою вищу масштабованість.

Майбутні плани

Наші плани включають кілька ключових ініціатив для вдосконалення Compute API та його екосистеми.

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

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

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

Цей розвиток перетворить Compute API на повноцінне та надійне рішення для сучасної інфраструктури.

Висновок

Compute API є трансформаційним кроком у переосмисленні інфраструктури в Trendyol.

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

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

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

Ці досягнення дають Trendyol можливість не тільки задовольняти вимоги сьогодення, але й впевнено адаптуватися до майбутнього.

У міру просування Compute API в етапи впровадження, проект вступає в захоплюючий етап.
Ми будемо вдосконалювати і розширювати межі можливого і з нетерпінням чекаємо на подальші етапи цього неймовірного шляху.

Приєднуйтесь до нас

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

[

Головна - Кар'єра в Trendyol

Ми віримо в силу інклюзивного робочого середовища. Наша платформа призначена для всіх, і наше робоче середовище також таке. Кожен і…

careers.trendyol.com

](https://careers.trendyol.com/tr?source=post_page-----a17701e2fafe--------------------------------)

Перекладено з: From Bottlenecks to Breakthroughs: How the Compute API Redefines Provisioning