Ірі WordPress жобасын Google Cloud-қа қалай көшірдік

Сәлем, инженерлер! Бүгін біздің командамыздың тәжірибесіндегі ең қызықты, күрделі және ауқымды кейстердің бірі — өте үлкен WordPress жобасын заманауи бұлттық инфрақұрылымға көшіру (миграция) процесі туралы егжей-тегжейлі айтып беремін. Клиенттің нақты аты-жөні мен бренд атауы NDA (құпиялылық келісімі) аясында жабық сақталады. Дегенмен, жобаның ауқымы мен маңыздылығы соншалық, бұл миграциялық процеске платформаның бас провайдері ретінде тікелей Automattic компаниясының өзі (иә, сол WordPress экожүйесін жасаушы және оны дамытушы негізгі алпауыт) қатысты. Бізге қойылған міндет классикалық болып көрінгенімен, оның ауқымы өте үлкен болды: трафигі аса жоғары, миллиондаған қолданушысы бар веб-ресурстарды толықтай автоматты түрде масштабталатын Google Cloud Platform (GCP) инфрақұрылымына, дәлірек айтсақ, Cloud Run және Cloud SQL стекіне көшіру қажет болды. Бірақ, әдеттегідей, барлық қызық пен қиындық ескі жүйелердің ішкі архитектурасында жасырынған еді.

Барлығы неден басталды: Ескі жүйенің анализі

Клиенттің бұрынғы инфрақұрылымына алғашқы техникалық аудит жүргізген кезде, біз қарапайым lift-and-shift (яғни, барымен көшіре салу) әдісінің бұл жерде мүлдем жұмыс істемейтінін бірден түсіндік. Ескі жүйе дәстүрлі виртуалды машиналарда (Virtual Machines) орналасқан, ал оның дерекқоры мен файлдық жүйесі өзара тығыз байланысып кеткен алып монолитті құрылым болатын. Трафик өте жоғары деңгейде болды — секундтық сұраныстар саны (RPS) мыңдаған мәнге жететін, ал мазмұнды басқару жүйесіндегі спагетти-код пен бейберекет жазылған плагиндер жүйені аяусыз баяулатып тұрды. Ең басты талап — көшу кезінде ешқандай downtime (жүйенің тоқтап қалуы) болмауы тиіс еді, себебі әрбір секундтық кідіріс клиент үшін мыңдаған доллар шығын әкелетін.

Біз бірден шешім қабылдадық: ескі архитектураны бөлшектеп, оны толықтай контейнерлеу (containerization) арқылы заманауи бұлттық серверсіз (Serverless) бағытқа бұру керек болды. Бұл үшін біз Docker негізіндегі контейнерлерді басқаруға арналған Cloud Run технологиясын таңдадық. Ол трафикке байланысты нөлден жүздеген инстанстарға дейін жылдам масштабталады. Ал деректерді сенімді сақтау үшін жоғары өнімділікті Cloud SQL (PostgreSQL/MySQL) жүйесін таңдап алдық. Бұған қоса, медиа файлдарды (суреттер, құжаттар, бейнелер) орталықтандырылған түрде сақтау үшін Google Cloud Storage (GCS) шешімін қолдануды жоспарладық, өйткені контейнерлердің өзі толықтай stateless (күйсіз) болуы шарт еді.

Инженерлік хардкор: Контейнерлеу және Мәліметтер базасының миграциясы

WordPress-ті контейнерге салып, оны Cloud Run ішінде іске қосу — жұмыстың тек басы ғана. Негізгі қиындық файлдар мен дерекқорды синхрондау кезінде туындады. Ескі сервердегі wp-content/uploads директориясының көлемі бірнеше терабайтты құрайтын. Біз бұл деректерді ешқандай шығынсыз және кедергісіз GCS-ке көшіру үшін арнайы Go және Python тілдерінде жазылған параллельді асинхронды скрипттер топтамасын әзірледік. Бұл скрипттер файлдардың хэш-сомаларын тексеріп, тек жаңа өзгерген файлдарды ғана жіберіп отырды.

Дерекқорды көшіру де оңай болған жоқ. Тікелей трансляция кезінде деректердің тұтастығын (data integrity) сақтау үшін біз Cloud SQL жүйесінде сыртқы репликацияны баптадық. Бірақ ең үлкен техникалық кедергі желілік қауіпсіздік пен байланыс арналарында болды. Cloud Run контейнерлері бұлттық ортада динамикалық түрде ашылып-жабылатындықтан, олардың тұрақты ішкі IP мекенжайлары болмайды. Бұл мәселені шешу үшін біз VPC Serverless Access Connector технологиясын қолдандық. Ол бұлттық контейнерлерге ішкі қауіпсіз желі арқылы Cloud SQL дерекқорына тікелей және жылдам қосылуға мүмкіндік берді.

Дегенмен, нағыз қиындық жүктемені тестілеу (load testing) кезінде басталды. Трафик күрт артқан сәтте Cloud Run автоскейлинг алгоритмі іске қосылып, жүздеген жаңа контейнерлерді секунд ішінде аша бастады. Осы кезде әрбір контейнер дерекқорға жаңа қосылым (connection) орнатуға тырысып, Cloud SQL-дің максималды қосылымдар шегіне (max connections) бірден жетіп, базаны құлатып түсірді. Бұл мәселені шешу үшін біз коннекттер пулын басқаратын PgBouncer (немесе MySQL үшін баламалы ProxySQL) құралын енгізіп, оның параметрлерін мұқият баптадық (tuning). Бұл шешім дерекқорға түсетін салмақты бірнеше есе азайтты.

Жоғарыдағы графиктен көріп отырғанымыздай, миграцияға дейінгі ескі архитектурада трафик өскен сайын жүйенің жауап беру уақыты (latency) экспоненциалды түрде артып кететін. Ал жаңа Cloud Run + Cloud SQL архитектурасында жүйе жүктемені біркелкі таратып, жауап беру уақытын тұрақты әрі төмен деңгейде сақтап тұр.

CI/CD және Инфрақұрылымды код ретінде басқару (IaC)

Жобаны басқаруды жеңілдету және болашақтағы деплойменттерді қауіпсіз ету үшін біз бүкіл инфрақұрылымды код ретінде сипаттадық (Infrastructure as Code). Бұл үшін Terraform қолданылды. Кез келген жаңа өзгеріс, мейлі ол VPC баптауы немесе Cloud Run конфигурациясы болсын, тек Git репозиторийі арқылы өтетін болды. Біз келесідей құрылымды қолдандық:

• /infrastructure/terraform — бұлттық ресурстардың сипаттамасы жазылған файлдар жиынтығы;
• /docker/wordpress — WordPress негізіндегі оңтайландырылған Dockerfile;
• .github/workflows/deploy.yml — автоматты түрде тестілеуден өткізіп, өндірістік серверге (production) кодты шығаратын CI/CD құбыры.

Әрбір деплой кезінде Docker бейнесі жинақталып, Google Artifact Registry қоймасына жіберіледі, содан кейін барып Cloud Run жаңа нұсқаны (revision) іске қосады. Бұл процесте canary deployment әдісі қолданылды: жаңа кодқа алдымен трафиктің тек 5%-ы ғана жіберіліп, қателіктердің жоқтығы тексерілді, содан кейін ғана трафик 100%-ға дейін біртіндеп арттырылды. Бұл бізге толықтай қауіпсіздік пен тұрақтылықты қамтамасыз етуге мүмкіндік берді.

DNS-пен болған қызық жағдай: "Локальді прод" хикаясы

Енді ең қызықты әрі күлкілі сәтке де келіп жеттік. Бұл оқиға дәл сол миграцияны аяқтайтын шешімді түнде (cutover night) болды. Біз бүкіл командамызбен және Automattic инженерлерімен бірге Google Meet видеоқоңырауында жиналып отырдық. Жоспар бойынша, біз ескі серверлерді "тек оқу үшін" (read-only) режиміне ауыстырып, соңғы деректерді синхрондадық және DNS-тегі A-жазбаларды жаңа Cloud Run жүйесінің жүктеме теңестіргішіне (Load Balancer) бағыттадық.

Барлық метрикалар жасыл түспен жанып тұрды, жүйе қалыпты жұмыс істеп жатқандай көрінді. Мен жаңа сайттың беттерін ашып, әкімшілік панеліне кіріп, өнімділікті тексере бастадым. Бәрі керемет, жылдамдық бұрын-соңды болмағандай жоғары! Мен қуанып: "Жігіттер, бұл керемет табыс! Сайт ұшып тұр, ешқандай кідіріс жоқ!" деп мақтана бастадым. Содан кейін чатқа біздің жас маман (джуниор әзірлеуші) жазады: "Ағалар, мен түсінбей тұрмын, біздің жаңа тестілік домен неге менде localhost-қа сілтеп тұр?".

Сол сәтте менің төбемнен жай түскендей болды. Мен өз компьютерімдегі /etc/hosts файлын ашып қарасам, ол жерде тестілік доменді локальді машинама бағыттап қойған ескі жазбаны өшіруді ұмытып кетіппін! Яғни, мен соңғы жарты сағат бойы жаңа бұлттық жүйені емес, өз компьютерімде Docker ішінде жұмыс істеп тұрған локальді WordPress-ті тексеріп, оның жылдамдығына мәз болып отырған екенмін! Менің компьютерімдегі /etc/hosts файлында келесі жазба тұрды:

Бұл қателігімді түсінген кезде бүкіл команда қатты күлді. Әрине, мен бұл жазбаны тез арада өшіріп, нақты продка кірдім. Бақытымызға орай, нақты DNS жазбалары бүкіл әлем бойынша ешқандай кедергісіз және уақытында жаңартылып үлгерген екен. Жаңа жүйе шынымен де өте жылдам және тұрақты жұмыс істеп кетті. Біз жеңілдеп, кофе ішіп, таңғы уақытта ұйықтауға кеттік.

Бұл графикте трафиктің күрт өсуі кезінде Cloud Run белсенді контейнерлерінің қалай сәйкес масштабталатынын көруге болады. Сұраныстар саны азайған сәтте жүйе контейнерлер санын автоматты түрде азайтып, ресурстарды үнемдейді. Бұл клиент үшін қаржылық тұрғыдан өте тиімді шешім болды.

Қорытынды және Нәтижелер

Бұл миграция бізге және біздің клиентімізге өте үлкен тәжірибе мен келесідей маңызды нәтижелерді әкелді:

1. Шығындарды оңтайландыру: Серверлерді үнемі қосулы ұстаудың қажеті болмай қалды. Трафик жоқ кезде Cloud Run нөлге дейін жиырылады, бұл бұлттық инфрақұрылымға кететін шығындарды 40%-ға азайтты.
2. Өнімділіктің артуы: Жауап беру уақыты (Page Load Time) орташа есеппен 2.4 секундтан 0.8 секундқа дейін қысқарды. Бұл қолданушылардың сайтта қалу ұзақтығын арттырды.
3. Нөлдік тоқтау уақыты (Zero Downtime): Клиенттің бірде-бір қолданушысы көшу процесі кезінде ешқандай қателікке немесе сайттың қолжетімсіздігіне тап болған жоқ.

Егер сіз де жоғары жүктемелі жобаларды бұлттық жүйеге көшіруді жоспарлап жүрсеңіз, Cloud Run мен Cloud SQL үйлесімділігін міндетті түрде қарастыруды ұсынамын. Ең бастысы — коннекттер пулын дұрыс баптауды және миграция алдында өз компьютеріңіздегі /etc/hosts файлын тексеруді ұмытпаңыздар! Келесі кездескенше, сәтті кодтау тілеймін!