Будуємо сховище для даних з Google Cloud Platform

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

Привіт! Я Ігор Хаустов, Senior Cloud Engineer в Forte Group, і це моя друга стаття на DOU про клауди. Я вже розповідав про AWS-сертифікацію і про оптимізацію витрат в AWS. Цього разу я зупинюсь на альтернативному клауді — Google Cloud Platform. Тож якщо вам цікаво, як тут все працює, які рішення вона пропонує та як підвищити свій рівень володіння цією платформою, залишайтесь зі мною.

Кількість інформації росте в геометричній прогресії. Щодня створюється приблизно 328,77 мільйонів терабайт даних. До кінця 2023 року буде згенеровано близько 120 зетабайт даних, а у 2025 — приблизно 181 зетабайт даних. Цікава річ: на відео припадає більше половини інтернет-трафіку даних у світі.

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

Розпочнемо наш аналіз Google Cloud зі сховища. Існує три варіанти сховища, у кожного з яких своя місія:

1. Object Storage.
2. Block Storage.
3. Filestorage.

Варіанти сховища на Google Cloud Platform. На основі матеріалу.

Найкращі практики використання Cloud Storage

Основна функція Object Storage — зберігати файли. Тут зберігаються різні типи даних: фото, відео, бекапи, документи, відео, стрими, картинки, які ми робимо на телефон. У цих даних є власні ID-номери. Це все об’єкти, які ми не можемо зберігати у звичних нам базах даних. Тут є бакет — своєрідне «відро даних», де зберігаються ці об’єкти.

Такі платформи, як Instagram і Facebook, обов’язково використовують Object Storage для зберігання об’єктів користувачів. У бакеті можна зберігати навіть сайт, наприклад, якийсь маленький лендинг — візитівку з контактами й основною бізнес-інформацією. Це роблять для того, аби не витрачати гроші на хостинг, а іноді туди завантажують навіть фронтенд, адже це набагато дешевше за будь-який хостинг. Ціна залежить від регіону та типу бакета. Як приклад ціна у Європі.

На основі матеріалу.

Також з’являється можливість використовувати сервіс Cloud CDN.

З Google Cloud, як і з будь-якого клауду, можна складати іспити та отримувати сертифікацію під різні напрями. У них теж є багато правил, вимог і стандартів. Зараз я працюю з клієнтом з медичної сфери. У нашій роботі ми постійно керуємось стандартами HIPAA (The Health Insurance Portability and Accountability Act). Наприклад, контроль версій об’єктів, щоб забезпечити архів даних і що дозволить відновити видалення в разі випадкового стирання даних.

Також на бакет можна додавати період утримання. Наприклад, два роки в цьому бакеті ніхто не може видаляти чи заміняти файли, навіть з правами адміна, аби випадково не прибрати нічого важливого. Ми встановлюємо lock retention policy — термін зберігання файлів. Дуже важливо пам’ятати, що його можна лише збільшити. Наприклад, ми ставимо пʼять років, і вже не можемо зменшити до двох чи одного року, а лише збільшити цей термін.

У Cloud Storage бажано не завантажувати конфіденційну інформацію, як-от паролі, банківські ID і подібне. Окрім того, коли пишемо застосунок (з API, який звертається до цього Cloud Storage), потрібно врахувати один момент. Завжди робіть для нього back of retry period (exponential backoff retry after 1, 4, 8, 16 секунди).

Як це працює? Наприклад, Google отримує пʼять тисяч запитів на секунду і, якщо раптом у наступну секунду їх прийде 15 тисяч, він не встигне обробити такий різкий перепад запитів. У цьому випадку вас і врятує back of retry period, який автоматично робить повторний запит через певні секунди, якщо не отримує відповідь з першого разу.

Є в Google Cloud Storage ще така зручна штука як Fuse. Ми можемо примонтувати бакет на Macbook чи Linux і бачити всі дані (картинки, відео), відкриваючи це як звичайну папку, яка насправді буде розташована в Storage. Це як, грубо кажучи, вставити флешку. Тільки в цієї флешки є перевага — у об’ємі даних 5 TB.

На Cloud Storage вигідно зберігати бекапи, обираючи для них різні варіанти бакету. Часта схема переїзду на клауд саме через перенесення даних на Storage. Ви завжди можете архівувати певні дані, перенести на бакет бекапи чи архіви, а потім уже поступово налаштовувати всю роботу на клауді. Архівне зберігання — це найдешевший, надійний сервіс зберігання даних для архівування даних, онлайн-резервного копіювання та аварійного відновлення. На відміну від «найхолодніших» послуг зберігання, які пропонують інші хмарні постачальники, ваші дані доступні протягом мілісекунд, а не годин чи днів.

Функції Block Storage та FileStore

Наступною складовою Google Cloud Platform є Block Storage. Базова місія Block Storage — запустити віртуальну машину. Block-девайси працюють, як диски віртуальної машини, які зберігаються в клауді. Диски потрібні для роботи віртуальної машини, а також для застосунків, щоб зберігати дані на диску (чи декількох дисках), які монтуються для серверу.

І останньою складовою є FileStore. Він схожий на Object Storage, але працює за протоколом NFSv3 (Network File Systems). FileStorage встановлює доступ між серверами. Проєкти зазвичай не обходяться одним сервером. Наприклад, у нас є 20 серверів, і нам потрібно, аби на них усіх був доступ всередині сервера до одних і тих даних, щоб не звертатись до Object Storage. Ми можемо створити FileStore і примонтувати його до цих 20 серверів. Так, ми в реальному часі можемо відстежувати, хто які дії виконує з даними — щось видаляє чи додає.

Особливості роботи з сервісами бази даних клауду

Наступною складовою організації сховища даних на Google Cloud Platform є вибір сервісу баз даних. Вони діляться на дві великі групи — реляційні і нереляційні.

Вибір сервісів на Google Cloud Platform. На основі матеріалу.

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

Як працює Cloud SQL Service? Створюється database → далі таблиця → в ній є звичні нам поля (column) з інформацією. Під кожного користувача створюється сторінка з полями його даних: іменем, поштою, контактним номером телефону. Саме за цими даними потім зчитується інформація про користувача і те, чи є він взагалі в базі даних.

Розглянемо приклад роботи застосунку та його бази даних. Найпростіший варіант застосунку — з одним Primary Instance сервером MySQL. Зазвичай з такого варіанту починають стартапи. Невеликі проєкти також зазвичай використовують один сервер.

Стандартний приклад роботи Client Application та його бази даних з високою доступністю. На основі матеріалу.

Із застосунку відбувається звернення на IP-адресу Cloud SQL-сервера про те, чи відбулась транзакція. За нормальних умов цей запит йде на primary-сервер, обробляється, і тоді надається потрібна інформація. Але що робити, якщо цей сервер перестав відповідати чи працювати?

Застосунок так само перестане працювати. Причиною може бути те, що трапилась надзвичайна ситуація і фізично сервер вийшов з ладу. Остання причина звучить як катастрофа для проєкту. Сподіватись на один сервер небезпечно, особливо, якщо проєкт розвивається та планує розширюватися. Ми переходимо до нового рівня, а саме: застосування Highly Availability — найкращих практик будівництва клауд SQL-серверу. Далі я зупинюсь детальніше на рішеннях, які рекомендують клауди зазвичай:

1. Створити Read-replica сервер.
2. Створити Standby Instance сервер.

Зупинімося конкретніше на цих варіантах.

Створюємо Read-replica сервер

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

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

Яке може бути рішення? Можна створити Read-Replica — ще один сервер, що відображає зміни в Primary-екземплярі майже в реальному часі, на якому можна читати дані. Тобто ми записуємо дані на Primary, а читаємо на Read-Replica. Так, ми прискорюємо наш застосунок і збільшуємо його можливості.

Необхідність такого сервера легко пояснити на прикладі регіональності. Клієнт з США не буде читати дані з Європи. Ми створюємо Read-replica, аби він швидко міг прочитати дані свого регіону. Тож якщо ваш бізнес орієнтований на різні регіони, вам можуть бути потрібні репліки. Якщо клієнт з Америки хоче запитати застосунок, чи він зареєстрований, то це можна зробити з Read-Replica-серверу. Але створити нового користувача можна лише на Primary Instance-сервері. Це як один приклад реплікації, більше можна подивитись у таблиці.

На основі матеріалу.

Створюємо Standby Instance-сервер

Ще одним варіантом є створення Standby Instance. Саме він врятує застосунок, якщо в регіоні А трапилась складна ситуація або застосунок не може достукатись до Primary Instance. У таких випадках він перемикається з Primary на Standby Instance — свою копію даних і страховку від втрати даних. Якщо нічого ніколи не станеться і не вийде з ладу, то цей сервер і не буде потрібен. Але це в ідеальному світі, а в нашому ж статись може що завгодно.

Можливо, ви подумаєте, навіщо нам Standby, якщо у нас вже є Read-Replica. Але на Standby Instance не можна так просто зайти та використовувати його як Read-Replica. Ми не можемо, як у випадку з Read-Replica, записувати дані на Primary, а читати з Standby.

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

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

No-SQL — нереляційні бази даних Cloud Datastore

Перейдемо до особливостей роботи з нереляційними сервісами. Нереляційна база даних зберігає дані в не табличній формі та, як правило, є більш гнучкою, ніж традиційні структури реляційної бази даних на основі SQL. Також плюсом цього сервісу є те, що він може автоматично скейлиться, тому нам не потрібні репліки (як в SQL). Й у нього інший синтаксис — GQL. У яких випадках ми його використовуємо?

1. Для зберігання даних про досвід споживачів. Наприклад, ви купили товар, і вас запитують, сподобався він чи ні. Потім цей відгук відправляють сюди, а не в базу даних.
2. Персоналізовані дані.
3. Сенсорні дані. Наприклад, саме тут користувач знаходить інформацію про статус посилки й чи надіслана вона. Відбувається аналіз даних на логістичних складах: за допомогою сенсору отримується інформація про те, чи пройшла посилка лінію пакування. Цими даними немає сенсу забивати базу даних.
4. Дані CMS (Content Management System).
5. Повідомлення й історія листування. Саме тут перебуває ваша історія листування в соцмережах, тоді як дані про вас як про нового користувача приходять після реєстрації в SQL.

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

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

Що потрібно знати про цей сервіс?

1. Імпорт та експорт застосовують SQL для масивних наборів даних.
2. Запити до джерел даних дата сетів: Cloud Storage, GCP SQL, BigTable, Google Drive, використовуючи постійні або тимчасові зовнішні таблиці.
3. Береться плата за виконання складних запитів.
4. Потрібно використовувати функцію insert ID, щоб уникнути дублікатів.

Приклад моделі машинного навчання в Google Cloud

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

Безсерверна архітектура BigQuery дозволяє використовувати запити SQL, щоб відповідати на найбільші запитання вашої компанії без керування інфраструктурою. Масштабований механізм розподіленого аналізу BigQuery дозволяє запитувати терабайти за секунди та петабайти за хвилини.

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

Які у нас можуть бути приклади використання машинного навчання та BigQuery в Google Cloud? Наприклад, Twitter — це відкрита соціальна платформа, яка є домом для світу різноманітних людей, точок зору, ідей та інформації. Плануючи стандартизувати та спростити свій підхід до обробки даних у всіх своїх операціях, Twitter поступово переніс свої операції на BigQuery в Google Cloud.

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

Дякую усім, хто дочитав цей матеріал до кінця. Пишіть в коментарях, які ще ви використовуєте в роботі SQL Highly Availability практики й діліться своїм досвідом з Google Cloud Platform.