Розроблення в Google Cloud: обирайте модель роботи, а не перелік служб

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

Головний вибір стосується моделі роботи. Керована платформа Cloud Run залишає невелику площу інфраструктури для придатних контейнерних служб. Google Kubernetes Engine дає більше контролю над плануванням і платформою, але потребує сильнішої відповідальності за Kubernetes. Compute Engine зберігає гнучкість віртуальних машин разом з обов’язком їх адмініструвати. Керовані бази даних, обмін повідомленнями, аналітика, керування ідентифікацією, мережа й спостережуваність передають Google окремі види роботи, однак клієнт і далі відповідає за поведінку застосунку, керування даними, правила доступу, налаштування, рішення про відновлення й реагування на аварії.

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

Обирайте служби Google Cloud за доказами про навантаження

Cloud Run підходить службам HTTP без локального сталого стану, API, споживачам подій, завданням і вебзастосункам, які передбачувано запускаються та відповідають його моделі виконання. Автоматичне масштабування може слідувати за попитом і зменшувати кількість примірників до нуля, а мінімальна кількість примірників — скорочувати затримку першого запуску. Установлюйте паралельність, процесор, пам’ять, обмеження запитів і найбільшу кількість примірників за вимірюваннями. Верхня межа також захищає бази даних і залежні API від різкого масштабування. Зберігайте сталий стан поза контейнером, правильно завершуйте роботу, робіть операції безпечними для повторення й перевіряйте повторні спроби.

Google Kubernetes Engine виправдовує вартість платформи, коли навантаження потребують API Kubernetes, особливого планування, складної будови служб, допоміжних контейнерів, власних контролерів, переносності або спільної внутрішньої платформи з компетентними відповідальними. До перенесення визначте відповідальність за групу вузлів, простори імен, облікові сутності робочих навантажень, мережу, правила, оновлення, резервні копії, ресурси й чергування. Не обирайте GKE лише тому, що система має кілька служб: Cloud Run або модульний застосунок можуть дати той самий результат для бізнесу з меншою площею експлуатації.

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

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

Використовуйте Pub/Sub, щоб роз’єднати виробників і споживачів там, де затримана чи повторна доставка припустима й свідомо обробляється. Визначте схеми повідомлень, припущення про порядок, безпечне повторне виконання, повторні спроби, правила недоставлених повідомлень, повторне відтворення, строки зберігання, цільовий розмір черги та розслідування повідомлень, що постійно спричиняють помилку. «Опубліковано» не доводить завершення операції бізнесу. Пов’язуйте повідомлення з результатами предметної області й забезпечте звіряння після часткової відмови.

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

Проєктуйте синхронні API й асинхронні події як договори бізнесу. Шлюз API або розподілювач навантаження може централізувати маршрутизацію, TLS, обмеження частоти та окремі частини підтвердження особи, але не виправить нечіткої відповідальності чи небезпечного дозволу доступу на сервері. Визначте час очікування, безпеку повторів, поділ результатів на сторінки, квоти, розвиток схеми, значення помилок і сумісність споживачів. Кешуйте лише за явних правил актуальності, скасування, захисту даних і відмов. Розміщуйте CDN і засоби на межі мережі лише там, де це виправдовують виміряні географія, рух даних або характер атак.

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

Створіть засоби контролю, що роблять керовану хмару придатною до експлуатації

Створіть базове хмарне середовище до того, як продуктові команди почнуть заводити не пов’язані між собою проєкти. Ієрархія ресурсів Google Cloud розміщує організацію над папками й проєктами, завдяки чому дозволи IAM і правила організації успадковуються. Будуйте її за справжнім адмініструванням, середовищами, ризиком, оплатою й делегуванням, а не за декоративною організаційною схемою. Відділяйте робоче середовище від неробочих, централізуйте видимість оплати й доступ до аудиту, визначте створення проєктів та відповідальність за них і застосовуйте контрольні обмеження через код. Аварійний доступ має бути вузьким, спостережуваним і перевіреним.

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

Проєктуйте мережу за потоками довіри й руху даних: вхідний і вихідний рух, DNS, доступ між службами, приватні з’єднання зі службами, розподіл навантаження, правила міжмережевого захисту, гібридні з’єднання та контрольоване адміністрування. Перебування «всередині VPC» не є рішенням про дозвіл. Перевіряйте справжність робочих навантажень і дозволяйте запити на рівнях служби та даних. Фіксуйте класи й потоки даних, щоб місце зберігання, шифрування, строки, вивантаження та обов’язки постачальників можна було перевірити, а не припускати.

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

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

Спостережуваність пов’язує діагностичні дані з результатами користувачів і бізнесу. Використовуйте структуровані журнали, показники, ланцюжки викликів, записи аудиту, позначки випусків та ідентифікатори зв’язку; контролюйте чутливий вміст і строки зберігання. Панелі показників мають показувати потік запитів, затримку, помилки, вичерпання ресурсів, актуальність, чергу, стан залежностей, витрачання допустимого запасу помилок SLO і доречні витрати. Кожне сповіщення потребує відповідального, дієвого порогу, оперативної інструкції, порядку підвищення рівня реагування й перегляду. Перевіряйте, чи зберігаються діагностичні дані під час відмов, які треба дослідити.

Вартість є сигналом архітектури. Призначайте проєкти, позначки, бюджети й відповідальних за витрати; відділяйте сталу основу від змінного попиту; стежте за вартістю одиниці на клієнта, запит, завдання чи набір даних поряд із рахунком. Добирайте розмір ресурсів за фактичним використанням, обмежуйте автоматичне масштабування, видаляйте невикористані ресурси після визначеного строку, контролюйте обсяг журналів і запитів, беріть довгострокові зобов’язання лише за обґрунтованого попиту та включайте до повної вартості підтримку, передавання даних, ліцензії, перенесення, відновлення й час інженерів. Скорочення витрат, яке порушує SLO або перекладає ручну роботу на людей, не є оптимізацією.

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

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

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

GARNO.TECH проєктує, створює, оновлює й експлуатує вебзастосунки, API, продукти SaaS, процеси даних і корпоративні системи в Google Cloud. Співпраця може дати оцінку архітектури й базового хмарного середовища, перевірку Cloud Run або GKE, інфраструктуру як код, CI/CD і спостережуваність, оновлення баз даних та інтеграцій, відпрацювання відновлення, контроль витрат або поетапне перенесення. Корисною вихідною точкою є навантаження, його користувачі, наявні докази й відмова, якої бізнес не може допустити.

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

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

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