Макс Шульце, Lead Data Engineer, що працює над створенням озера даних у Zalando.
Джерело: aws.amazon.com
Заснована в 2008 році Zalando є провідною європейською онлайн-платформою для моди та способу життя з понад 32 мільйонів активних клієнтів. Я є провідним інженером з обробки даних у Zalando та постійним внеском у хмарну подорож компанії. У цій публікації я розповідаю, як Amazon Simple Storage Service (Amazon S3) стала наріжним каменем інфраструктури даних нашої компанії. По-перше я розкажу про бізнес-потребу Zalando в отриманні даних і те, як його історичний стек технологій надавав різнорідну інформацію. Потім я розповім про те, як ми вирішили перейти на AWS, зокрема за допомогою Amazon S3 для створення озера даних. Насамкінець я поділюсь тим, як наше використання Amazon S3 змінювалося з часом, від надання співробітникам доступу до даних до оптимізації наших витрат на зберігання за допомогою різних класів зберігання Amazon S3.
Сподіваюся, ви зможете навчитися з мого досвіду та того, як ми створили найкращі практики, які допомагають нам управляти компанією, що керується даними у масштабі кількох петабайтів.
Попередня історія технології Zalando
У 2015 році Zalando був роздрібним продавцем одягу, ІТ-середовище якого працювало як великий локальний моноліт. Основні частини інфраструктури, будь то на транзакційній чи аналітичній стороні, були безпосередньо інтегровані та залежали одна від одної. Водночас зі збільшенням складності систем зросла кількість команд, яким потрібно було мати свої сегменти. Потім було прийнято рішення перетворити компанію з «просто» онлайн-магазину на платформу для моди. Поставити таку мету означало підготуватися до масштабування. Розглянувши потреби нашого бізнесу на сьогоднішній день і майбутнє, для компанії було логічним рішенням перейти до хмари. Ми оцінили кілька хмарних постачальників, і AWS було обрано як хмарний постачальник через його довговічність, доступність і масштабованість. Ми також розглянули розгалужену екосистему послуг, які пропонує AWS, якими ми могли б скористатися в майбутньому. Монолітну інфраструктуру Zalando було розбито на мікросервіси, що призвело до створення команд із наскрізною відповідальністю за свою частину технологічного ландшафту в ізольованому просторі розробки та операцій.
Зміна нашої технічної інфраструктури безпосередньо вплинула на ландшафт даних компанії. Центральні бази даних, до яких зверталися багато компонентів, стали децентралізованими серверними частинами, а зв’язок здійснювався через REST API. Наше центральне сховище даних із прямим підключенням до сховищ транзакційних даних мало справлятися з децентралізованою генерацією даних без прямого доступу. Щоб подолати ці труднощі, була створена центральна команда з метою створення озера даних у Zalando (Схема 1). Було два початкових стимули для запуску озера даних: наявність центрального архіву даних у цьому новому розподіленому середовищі та створення механізму розподілених обчислень для компанії.
Після зняття обмежень щодо розміру реляційних баз даних виявилося, що компанія вже виробляє набагато більше потенційно цінних даних. Нам потрібен був варіант зберігання даних, який міг би впоратися зі зростаючими обсягами, і будь-який варіант, який ми обрали, мав бути масштабованим, надійним і доступним. Дивлячись на портфоліо послуг AWS, Amazon S3 був очевидним вибором для роботи в якості базового рівня нового центрального озера даних компанії.
Нашим першочерговим завданням у створенні щойно налаштованого та порожнього озера даних була інтеграція основних джерел даних компанії. На той час була створена центральна шина подій, основною метою якої було обслуговування зв’язку між розподіленими мікросервісами. Другу основну мету було додано завдяки введенню компонента архіватора для збереження копій усіх опублікованих повідомлень в озері даних. Основні бізнес-процеси вже спілкувалися через шину подій, що робило її вміст надзвичайно цінним для аналітичної обробки. Конвеєр прийому побудований на основі безсерверних компонентів для виконання основних вимог підготовки даних, як-от переформатування та перерозподіл. Цей конвеєр описано більш детально в цьому дописі у блозі.
Ось 5-хвилинне відео «Це моя архітектура» про те, як ми побудували безсерверний конвеєр обробки даних про події та перемістили дані в наше озеро даних:
Поки тривав перехід до хмари, було ще багато цінних наборів даних, створених і збережених у вихідному сховищі даних у нашому центрі обробки даних. Одним із таких наборів, наприклад, була центральна логіка продажів компанії. Другий центральний конвеєр подбав про те, щоб набори даних сховища даних (DWH) також були доступні в озері даних. Третім елементом головоломки були дані веб-відстеження, які були значними за розміром необроблених даних і неймовірно цінними в поєднанні з уже наявними наборами даних. Ці три конвеєри забезпечили постійне живлення початкового озера даних компанії.
Докладно про параметри служби S3
Постійне збільшення нашого озера даних на Amazon S3 призвело до різних ситуацій, які полегшили використання різноманітних функцій, наданих S3. У решті цього допису в блозі я розповідаю про функції, які використовує Zalando, включаючи їхні переваги та відповідні випадки використання.
Обмін даними та доступ до них
Якщо цим ніхто не користується, немає сенсу зберігати великі обсяги даних. З цієї причини першим і найважливішим завданням, яке ми мали вирішити, був обмін даними. У Zalando багато команд мають власні облікові записи AWS, які негайно висувають вимоги щодо обміну даними між обліковими записами. Найпростіший спосіб зробити це – політика сегментів. Політики сегментів дозволяють приєднати визначення безпосередньо до сегмента, яке вказує принципалів (наприклад, ролі), які мають право на деякі дії, які їм дозволено виконувати. Прикладом такої дії є GetObject на певному ресурсі, як-от конкретний префікс у вашому сегменті. Це дуже зручно для початку роботи та дуже добре працює для невеликої кількості підключень до інших облікових записів. Через деякий час все більше і більше людей хотіли отримати доступ до даних. Мало того, що керування політикою зростаючого сегмента стало трохи громіздким, зрештою ми навіть досягли верхньої межі його розміру.
Оскільки виникла потреба змінити підхід до більш ізольованого та більш масштабованого, ми почали використовувати ролі IAM. Ролі IAM працюють дуже подібно до політик сегментів для цього конкретного випадку використання. Ви додаєте вбудовану політику, яка виглядає дуже схожою на ту частину попередньої політики сегмента, вказуючи дії на певних ресурсах. Єдиною відмінністю є принципал, який вирішується довірчими відносинами з цільовим обліковим записом. У самій ролі ви вказуєте номер облікового запису, якому довіряєте, що з їхнього боку дає їм змогу взяти на себе створену роль і отримати через неї доступ.
Резервне копіювання та відновлення даних
Якщо у вас є велике озеро даних, яке використовується багатьма для різних виробничих цілей, ви починаєте думати про резервне копіювання своїх даних і забезпечення відновлення в разі інцидентів. Найпростіший спосіб зробити це — увімкнути версії для ваших виробничих сегментів. Управління версіями дає змогу зберігати попередні версії на випадок, якщо потрібно отримати доступ до старішої версії або відновити видалені версії, навіть якщо вони невидимі через стандартні виклики S3 API. По суті, кожен префікс перетворюється на стек об’єктів, з яких лише останній буде доступним за замовчуванням.
Керування версіями є зручним у випадку, якщо у вашому конвеєрі даних виникли помилки і вам потрібно відкотити результат. Що ще важливіше, керування версіями також працює для видалення даних. Замість того, щоб фактично видаляти ваші об’єкти, він розміщує маркер видалення поверх стека цього об’єкта, що робить його невидимим, але все ще доступним за запитом. У 2017 році ця функція була для нас порятунком. Усім відомі історії нових столярів, які випадково скинули базу даних виробництва. Під час масштабного інциденту повна історія наших даних веб-відстеження була видалена, терабайти наших об’єктів зникли. Завдяки ввімкненню керування версіями ми змогли відновити їх усі протягом одного дня, просто знявши з них маркери видалення.
Якщо ви шукаєте додаткові способи резервного копіювання своїх даних, розгляньте S3 міжрегіональної реплікації (CRR). Ми рано почали використовувати CRR, що дозволяє зберігати копії ваших даних у фізично іншому регіоні AWS. Зручний спосіб реалізувати це — копіювання ваших виробничих сегментів в інший регіон і поєднання цього з негайним архівуванням вмісту цільового сегмента в Amazon S3 Glacier.
Оптимізація витрат на зберігання
У якийсь момент Amazon S3, незважаючи на чудову модель ціноутворення, стає ціллю для оптимізації витрат. Те, що є незначним для гігабайтів і терабайтів даних, стає значною частиною вашого хмарного рахунку в масштабі кількох петабайтів.
Щоб вирішити цю проблему, ви повинні розуміти, якими даними ви насправді володієте. Зараз наша організація охоплює майже 400 команд із понад 8000 сегментами S3. Неможливо зрозуміти ваше сховище лише за допомогою людини. S3 Inventory – це функція, яка надає базову інформацію про кожен об’єкт у ваших налаштованих сегментах. Такі прості речі, як розмір об’єктів і позначки часу last_modified, можуть визначити, скільки років вашим даним і наскільки вони впливають на розподіл витрат. Якщо у вас увімкнено керування версіями, це спосіб зрозуміти, скільки об’єктів не є останньою версією, і чи потрібно запускати для них очищення.
Повний потенціал інвентаризації S3 реалізується, коли ви поєднуєте її з журналами доступу S3. Хоча на даний момент ви усвідомлюєте вплив збережених даних на ваші витрати, журнали доступу S3 дозволяють розрізняти гарячі та холодні дані. До яких наборів даних високої цінності постійно звертаються, а які масиви даних мають значний розмір, але їх ніхто ніколи не читає? Останні є легкими кандидатами для операцій з очищення та значної економії коштів.
Amazon S3 постачається з різними класами сховища, які відповідають різним вимогам і шаблонам доступу. S3 Standard – це клас зберігання за умовчанням. Це забезпечує найвищу доступність і найнижчу вартість для отримання даних. Однак є дешевші варіанти, коли мова йде про чисті витрати на зберігання, які мають компроміси щодо двох інших характеристик. S3 Standard-Infrequent Access (S3 Standard-IA) – найкращий варіант для об’єктів, які не торкаються протягом тривалого часу, але мають залишатися доступними (для нечастого пошуку історичних даних). Це приблизно на 40% дешевше за зберігання, тоді як вартість запитів на доступ приблизно подвоюється. S3 Glacier і S3 Glacier Deep Archive є ще більш економічно ефективними класами зберігання, обмінюючись на меншу швидкість пошуку. Вони ідеально підходять для великих обсягів малодоступних даних.
Хоча класи зберігання чудово допомагають зменшити ваші витрати, коли ви точно знаєте свої дані та варіанти використання, обробка їх вручну є досить складним завданням. S3 Intelligent-Tiering дозволяє автоматично переходити об’єкти між класами зберігання на основі попередньо визначених критеріїв. Ми щорічно економимо 37% витрат на зберігання, використовуючи Amazon S3 Intelligent-Tiering для автоматичного переміщення об’єктів, яких не торкалися протягом 30 днів, до S3 Standard-IA. Потім ми повертаємо їх до S3 Standard, коли до них потрібен доступ.
Ми щорічно заощаджуємо 37% витрат на зберігання, використовуючи Amazon S3 Intelligent-Tiering для автоматичного переміщення до S3 Standard-IA об’єктів, яких не торкалися протягом 30 днів.
Багато наборів даних з часом втрачають цінність. Хоча S3 Intelligent-Tiering може заощадити ваші гроші на зберіганні даних, через деякий час ви можете виконати очищення з правильно вибраним часом зберігання. Політики життєвого циклу — це чудовий спосіб налаштувати такий час зберігання, але вони надають ще більше функцій. Наприклад, ви можете визначити переходи класів зберігання або тегування об’єктів для подальшого спеціального використання. Серед інших випадків використання ми використовуємо політики життєвого циклу як простий спосіб очистити набори даних, які згідно із законом можна зберігати лише протягом певного часу.
Заключні зауваження
Подорож Zalando до хмари пройшла довгий шлях. Створення озера даних на Amazon S3 дозволило співробітникам у всій організації працювати з даними, до яких вони раніше не мали доступу. Наразі існує кілька каналів даних, як централізовано, так і нашими внутрішніми користувачами, які постійно збільшують обсяг передавання в Amazon S3. Нам вдалося зменшити витрати на сховище та заощадити до 40% щорічно за допомогою різноманітних сервісів Amazon S3. Наприклад, ми використовували S3 Intelligent-Tiering і політики життєвого циклу, щоб налаштувати час збереження для видалення невикористаних даних. Натомість наші внутрішні користувачі можуть отримувати та аналізувати інформацію з даних, які ми зберігаємо, і в кінцевому підсумку покращити досвід наших клієнтів, коли вони здійснюють покупки через наш веб-сайт і мобільні програми.
На завершення я хотів би дати пораду для тих із вас, хто зараз запускає своє озеро даних Amazon S3. Під час створення озера даних на Amazon S3 є багато варіантів того, як створити макет даних, вибираючи різні сегменти та префікси в них. Зрештою, важливо не лише вибрати назву та план дистрибуції, але й дотримуватися цього плану. Коли ви дійдете до масштабу тисяч бакетів, потрібно докласти багато зусиль для очищення та організації зберігання даних, щоб гарантувати глобальну керованість.
Відтоді, як Zalando почав налаштовувати своє початкове озеро даних на основі Amazon S3, інфраструктура даних Zalando, і сам S3 значно змінилися. За останні 5 років ми мали можливість використовувати багато вже доступних функцій. Повертаючись до початку 2020 року, Zalando повністю використовує децентралізацію сховища, коли команди використовують власні сегменти для зберігання та обміну наборами даних за допомогою централізованого управління та підходу до керування даними. З надходженням терабайт на день і загальним об’ємом пам’яті 15 ПБ, який постійно зростає, ми постійно оцінюємо нові функції хмарного сховища та впроваджуємо інновації в техніках керування даними.
Зателефонуйте нам за номером +38 (044) 277-23-23 або надішліть нам листа за адресою aws@wiseit.com.ua, і ми детальніше розповімо вам про хмарні рішення AWS та їх переваги.