Next gen cloud-native платформи: приклади від TemaBit, Fozzy Group [ukr]

Доброго дня! Глобальність ти! Не бачив, але прийшов. І ми запам'ятаємо, щоб взяти участь у цьому івенті. Сьогодні поговоримо про те, як компанія Temabit будує платформу в хмарному середовищі в Marney. І фокус буде на тому, як ми будуємо архітектуру, а саме, щоб пояснити, що таке еволюційна архітектура на практиці. Ми розглянемо нашу нову платформу, яка має нас забезпечити, щодо обліку товарів в групі, і розглянемо, як ми будували цю архітектуру, проаналізуємо цей еволюційний процес.

Але спочатку трошки більше про саму групу. Це важливо для розуміння масштабів нашої роботи і контексту, який впливає на наші рішення. На даний момент Fozzy Group - це другий і третій ритейл в Україні, представлений мережею Silpo-Inform. Ми охоплюємо різні формати, включаючи супермаркети Silpo, магазини біля Donbas-Fora, та діпромаркети Fozzy. Наша діяльність включає десятки інших бізнесів у сфері ритейлу та виробництва, що становить близько 50-60 тисяч роздрібних точок. Fozzy Group - один із найбільших роздрібних ланцюгів в Україні, що працює в багатьох секторах, включаючи банки та аеропорти. Не менш важливим аспектом є те, що ІТ-бізнес єдиний в Україні, з більше ніж 100 тисячами спеціалістів, двома центрами досліджень і розвитку, які успішно функціонують вже понад 10 років.

Це саме ті люди, які бачать нашу компанію, наші сайти, та роздрібні точки кожен день. Такий досвід стає важливим, оскільки він визначає вашу взаємодію з нашою мережею, де ви працюєте. Мене звуть Сергій Медведєв, я представляю Європу і є партнером з ІТ-архітектури в нашій компанії. Я маю значний досвід у ІТ та розпочав свою кар'єру з Архітектури Організаційних ІТ-систем. Протягом років я працював у різних компаніях та інженерних областях, і в 2023 році приєднався до Fozzy Group.

Давайте перейдемо до конкретик. Сьогодні ми розглянемо нову товарну платформу, відому як Commodity Accounting Platform (КАП). Це виробниче рішення, що відповідає на чотири ключові питання, такі як "що?", "де?", "скільки?" і "як часто?". Ми розглянемо, як ця платформа вирішує завдання обліку товарів в наших точках продажу, що включають більше 1400 магазинів, складів та центрів по всій країні. Для забезпечення нас інформацією про наявність товарів ми маємо справу з сотнями тисяч товарних позицій, що охоплюють широкий асортимент продукції. Досягнення цієї мети вимагає розподілу та відстеження більше ніж 250 тисяч активних позицій товарів, а також обробки близько 10 мільйонів транзакцій в день. Це викликає значні виклики, оскільки нам необхідно надійно відповідати на питання про наявність товарів і їх розподіл в режимі реального часу, щоб забезпечити оптимальний інвентаризаційний процес.

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

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

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

Тепер, щодо архітектури, наша система розпочинається з гіпотези, яку ми створюємо, роблячи припущення, як ми можемо її реалізувати. У нас немає одного стеку через велику кількість різних проєктів. Тут нам на думку приходять наші опенсорси. Оскільки у нас є сотні різних ключів, представлених нами, які будуються на змінних факторах революційного товару, виникає ідея архітектурного стилю, такого як CQRS (Command Query Responsibility Segregation). Ми вважаємо, що опенсорсинг може надати нам кращу форму, оскільки він забезпечує демократизацію і збереження історії подій. Відповідно, надійність цієї системи стає надзвичайно важливою, а аудит є ключовим елементом відслідковування того, що відбувається в системі. Загалом, архітектура нашої системи базується на гнучкості, розподілених обчисленнях та використанні опенсорсингу для побудови ефективної бізнес-логіки.

Це дає нам можливість різноманітно інтерпретувати факти. Ці різні інтерпретації відображаються у різних лініях проекцій. Отже, базуючись на базах даних, де ми формуємо ці проекції, оптимізовані для конкретних продуктів, наприклад, кількість Coca-Cola в нашій мережі, або в конкретному магазині сільськогосподарського та комунального господарства, чи в господарчому центрі та інше. Це визначає історію наших проєктів. Якщо ми спрямуємо свій погляд праворуч на картинку, то побачимо історію, таку як КВА, КОМА, КВА Республіка, а пізніше ми матимемо КОМАН, КОМАН-Інтеншн. Важливо пам'ятати, що є два типи повідомлень у нас: КОМАН-Інтеншн і КОМАН-Інтеншн. Команда вказує на те, що, наприклад, в нашому господарчому центрі відправлено фургон з 25 тисячами. Це стає фактом, який буде включений у наші командні бонуси, що потраплять до агрегата, що фіксує цей факт і відповідає бізнес-логіці. Цей інвойт також буде переданий через event-bus до вент-хенд, який, в свою чергу, живитиме наші проєкти.

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

Вибачте за технічний характер мови, але це необхідно для нашої теми. Це показує, як ми залежимо від техніки та чому важливі правильні архітектури. І, знову ж таки, у нас є проблема, яку я вирішив, перемикаючись на резервний канал. Це лише один із прикладів того, як технічні аспекти можуть впливати на роботу. Також ми розглядали SQL REST, як історію про редундантність. Ми обрали рішення вибором конкретного артикула як агрегата. Кожен артикул представляє окремий ряд івентів, які фіксують зміни або дії з цим товаром. І тепер ми спробуємо знайти переваги та недоліки цього підходу. Плюси включають точність розрахунків, єдність бізнес-логіки та можливість додавати нові проєкти без необхідності змінювати всю систему. Однак існує серйозний недолік.

З точки зору бізнесу та обліку, ми працюємо з документами. Ви оплачуєте товар на касі, і отримуєте документ - чек. Ми повинні обробити цей чек, з якого виникають зміни в конкретних артикулах. Проте в нашій доменній моделі ми все організували за територією змін артикулів. Отже, нам потрібно додати ще один обмежувач, який буде представляти сам документ. Оскільки документ - це те, що ми подаємо в податкову, чек повинен бути зареєстрований в податковій. Таким чином, виникають дві дії, які мають бути виконані послідовно: обробка документу (чека) і обробка наших артикулів (зокрема, алкоголю). Отже, у нас є розподілена транзакція, але це призводить до двох проблем.

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

І потім мінус 50. 550. Кінцева цифра та сама, але послідовність неправильна. Ми говорили, що у нас на залишках купують інформаційний систем. Аналіз потреб, замовлення, дозакази і так далі. Тобто, у нас може ця цифра, яка 450 була, вона триггер для того, щоб замовити нову партію молока, яку треба в магазин. А у нас ніколи цієї цифри не було. І, відповідно, у нас послідовність в часі може прийматися на правильні рішення. Тому для нас послідовність дій, послідовність купів, це принципово важлива штука. Але, як ми бачимо, поки що ми не змогли з точки зору архітектури побудувати тему, яка цілює. Відповідно, у нас є проблема. І ця проблема в тому, що послідовність не коректна. Відповідно, ми вже пробували артікул, ми пробували документ, і щось нічого не виходить. Тобто треба щось більш радикальне нам змінювати. І ось ми переходимо до історії про стрім-процесінг.

В чому суть історії стрім-процесінгу? Коли ми починаємо говорити про стрім-процесінг, всі починають говорити про Kafka, але ми , не будемо відрізнятися. І Kafka будується навколо топіків. Що таке топік? Це поєднання однодетних конкретних структур, конкретно там, де трошки. І в топіку є дуже важлива штука, яка називається partition. Що таке partition? Це поєднання івентів, які мають один і той самий ключ. І що гарантує нам топік? Що послідовність обробки івентів в partition завжди гарантована та сама, в якій послідовності вони будуть відпрацьовані. Тобто, наші проблеми, як розкладати правильну послідовність змін кількості товарів, потрібно використовувати ID, артікул, як конюч. І тоді всі зміни по ключу будуть відпрацьовані з тієї послідовності, в якій вони пішли цей дох. Як ми тепер будуємо сам процесінг?

Для цього ми використовуємо stream processing. Як би все не звучало. Stream processing – це окрема штучка, окрема коробочка, яка ведеться до Kafka. Тобто, Kafka сама по собі – це фактична логіка, тобто, послідовності стрімів, стрім-івентів в наших топіках. А Kafka processing – це те, де ми можемо реалізувати вже бізнес-логіку, тобто, як інтерпретувати ці івенти. Відповідно, ми говоримо про те, що нам потрібно завантажити в топік Kafka-івенти. Далі ці івенти потрапляють в Kafka Streams. В Kafka Streams у нас відбувається бізнес-логіка, як накладання бізнес-логічних операцій, процесів на ці івенти і переклад результатів в інші топіки. І таким чином ми можемо робити послідовність цих перекладів між стрімами з якимось там сполаченням даних або референсом блоку, в яких у нас є оброблені вже наші дані, які ми вантажуємо в зовнішню систему, в якій зберігається стиль. В нашому веб-паку є такі наші івенти, якій розподілили залишки по нашом бізнесі, і так далі. Відповідно, якщо спробуємо спроєктувати наступний крок нашої революційної еволюції, як це буде відбуватись, для того, щоб ми оптимальність документу забезпечили і для того, щоб ми оформлювали послідовність івенту. І таким чином почали пропонувати.

Ми беремо і говоримо, що у нас є два вихідні сторіджі. Перший сторідж — це сторідж для самих документів, який у нас внизу. Зліва ми бачимо, що у нас є бюджет-стор. Лівий, наприклад, може бути естер. В ньому зберігається документ as-is. Плюс ми зберігаємо нет інформації по цьому документу в нашому вайн-стрімі, який дозволяє нам аудит документу, який створений, не редагували і так далі. У нас є історія самого документу, але без змін артікулу, в який привноситься документ. А от зміни по артікулу ми окремо маємо закинути справку як івенти, які потім в папці стрімс будуть оброблені і розраховані залишки. Операція ця називається дуепроекція, якими будуть користуватися наші клієнти. Тобто у нас на викладі з'являється нова абсолютно архітектура, я хочу ще раз підкреслити на секундочку, наша рідна частини не змінилася. Це дуже важливо. Тобто наша рідні частини, на яку зав'язані сотні або тисячі консерварів, не змінилася. При тому, що абсолютно повністю змінили архітектуру нашого рішення, з точки зору рідної частини.

Це мега-важливий аспект. Якщо ми підберемо підходи, то що отримаємо? Гарантована автоматизація нашого документу стає реальністю, оскільки наш документ зберігається як об'єкт. Дані передаються як об'єкт на дангл, на контейнер, на ворота і т. д. Онлайн-системи забезпечать розбиття цих даних на окремі операції в архітектурі Kafka Stream. Kafka Stream гарантує послідовність операцій, незалежно від того, які послідовності документів ми виконуємо. Операції, якими ми завершимо стрім, гарантовано відповідатимуть послідовностям, які ми дозволяємо. Таким чином, логіка розрахунку плюсів і мінусів за певною позицією буде коректно змінюватися, і наша частина, оптимізована для операцій, необхідних бізнесу, продовжить працювати.

Ми перейшли на третій крок, еволюційно вирішуючи окремі проблеми, оскільки важко було передбачити все заздалегідь. Однак еволюція дозволила нам ефективно розв'язувати окремі завдання. На рівні ПІОСІ ми могли вирішити питання, а не просто проектувати всю систему. Ситуація вимагала змін архітектури, і ми змінювали її, але команди продовжували працювати. Здатність системи еволюціонувати - це одна з ключових задач архітектора. Архітектор повинен проектувати систему так, щоб вона могла підтримувати невпинні зміни вимог і залишатися адаптованою до них.

Насправді, наша система використовує Marketing Web на екрані, для захисту використовуємо Amazon, який пакує наші проекції і сервіси. З архітектурної точки зору у нас внутрішній репозиторій, бюджетний сервіс для аудиту документів, веб-процесор для обчислення завдань, оркестратори для координації операцій. Еволюційний підхід дозволяє ефективно реагувати на зміни, а архітектор повинен думати в категоріях 3-10 років при проектуванні системи. Ну і на завершення хотів ще підкреслити, що ця презентація була про eventual evolutionary architecture. І цей підхід, який дозволяє бізнесам і архітектурі і дизайну і інформувати дозволи здебільшого потреб. Дякую за увагу. На цьому все.