Astana Hub стартапынан Enterprise-ке дейін: неліктен архитектураны бірінші күннен дұрыс қалау керек

Сәлем, хастлерлер, фаундерлер және қатал B2B-директорлар! Бүгін біз ерте ме, кеш пе әрбір табысты стартапты басып озатын ауырсыну туралы сөйлесетін боламыз. Елестетіп көріңізші: сіз Astana Hub-та инкубациядан өттіңіз, seed-раундты көтердіңіз, өнім "ұшты". Пайдаланушылар мыңдап тіркеліп жатыр, инвесторлар қол соғуда, фаундер Forbes-ке сұхбат беруде. Және осы салтанатты сәтте... сіздің сайтыңыз құлайды. Және жатады. Серверді қайта жүктеудің ешқайсысы көмектеспейді, өйткені деректер базасы бұғатталған, ал оның қалай жұмыс істейтінін білетін жалғыз Senior-әзірлеуші бір апта бұрын жұмыстан шығып кеткен.

ОЗАТ зертханасында біз өз табысының тұтқынына айналған жобалармен үнемі кездесеміз. Бизнес өсуге дайын, сату бөлімі лидтер генерациялайды, бірақ IT-инфрақұрылым: "Мен шаршадым, мен кетемін" дейді. Бұл неге орын алады? Өйткені Time-to-Market (өнімді нарыққа шығару жылдамдығы) соңына түскенде, архитектура көбінесе таяқтардан, көк оқшаулағыш таспадан және StackOverflow-дан жиналады. Бұл мақалада біз стартаптан Enterprise-ке өту инфарктсыз және миллиондаған шығынсыз өтуі үшін бірінші күннен бастап дұрыс іргетасты қалай қалау керектігін талдаймыз.

MVP эйфориясы және "кейін қайта жазамыз" синдромы

Шынымызды айтайық: MVP (Minimum Viable Product) жасаған кезде сіздің басты мақсатыңыз — гипотезаны тексеру. Сіз Laravel немесе Django-да монолитті жылдам жинайтын, мұның бәрін айына 10 доллар тұратын бір виртуалды серверде (VPS) өрістететін және деректер базасын сол жерде баптайтын студенттерді немесе фрилансерлерді жалдайсыз. Және бұл өнім өмірінің алғашқы екі айы үшін мүлдем қалыпты жағдай.

Мәселе MVP сәтті деп танылған кезде, оған жарнамалық бюджеттер құйыла бастағанда, ал архитектура бұрынғы күйінде қалғанда басталады. Атақты "кейін қайта жазамыз" синдромы пайда болады. Бірақ бизнес жаңа фичаларды талап етеді, бэклог ісінеді, ал рефакторинг ешқашан келмейтін "келесі тоқсанға" қалдырылады. Техникалық қарыз экспоненциалды түрде өсіп, кодтық базаны спагетти салынған қазанға айналдырады.

Сәтсіздікке ұшырайтын типтік стартап-монолиттің анатомиясы

Алғашқы елеулі жүктеме кезінде бұзылатын архитектура қалай көрінеді?

• Stateful-сервер: Пайдаланушылар аватарларды немесе құжаттарды жүктейді және олар қосымша айналып тұрған сервердің қатты дискісінде сақталады. Егер сервер "өлсе", файлдар да өледі. Егер сіз жүктемені теңестіру үшін екінші сервер қосуға тырыссаңыз, пайдаланушылардың жартысы өз аватарларын көрмейді.
• Сол сервердегі деректер базасы: Қосымша мен СҚБЖ (мысалы, PostgreSQL немесе MySQL) бірдей процессор ядроларын және жедел жадыны бөліседі. База "ауырлай" бастағанда, ол барлық ресурстарды жейді, ал қосымша жады жетіспеушілігінен құлайды (OOM Killer).
• Hardcoded құпиялар: Деректер базасының құпия сөздері мен төлем шлюздерінің API-кілттері тікелей кодта немесе GitHub-тағы жалпыға қолжетімді (немесе нашар қорғалған) репозиторийге жіберілетін конфигурациялық файлдарда жатады.
• FTP немесе git pull арқылы деплой: Жаңа нұсқаны шығару үшін әзірлеуші SSH арқылы продакшн-серверге кіреді, git pull жазады, сервисті қайта іске қосады және ештеңе бұзылмауы үшін дұға етеді. Әрбір жаңарту кезіндегі Downtime (тоқтап тұру уақыты) — бұл норма.

ОЗАТ-тың нақты кейсі: EdTech-стартап эфир кезінде қалай құлап қала жаздады

Бізге перспективалы білім беру стартапы жүгінді. Олар тікелей эфирде өз платформасын атап өтуі тиіс ірі блогермен (миллионник) жарнамалық интеграция туралы келісті. Эфир алдындағы таңертең фаундер сақтандыруды шешіп, бізден аудит жүргізуді сұрады.

Біз олардың инфрақұрылымын ашып, классикалық көріністі көрдік: Node.js бэкенді, React фронтенді, MongoDB деректер базасы, тіпті Redis айналып тұрған бір қуатты бөлінген сервер. Бәрі бір үйіндіде. Деректер базасының салмағы 50 ГБ шамасында болды және бірде-бір кастомды индексі болмады.

Біз эфирге 8 сағат қалғанда шұғыл түрде не істедік:

1. MongoDB-ді автоматты масштабтау және бэкаптары бар басқарылатын кластерге (Cloud Database) шығардық.
2. Статиканы (суреттер, сабақ бейнелері) Cloud Storage-ке көшіріп, Cloud CDN қостық.
3. Node.js қосымшасын Docker-контейнерге орап, оны Google Cloud Run-да өрістеттік.
4. Ең ауыр сұраныстар үшін деректер базасында индекстер жасадық.

Блогер жобаны атап өткен кезде сайтқа бірден 15 000 адам кірді. Cloud Run бірнеше секундта 50 қосымша контейнерді көтерді. Деректер базасы индекстер мен бөлінген ресурстардың арқасында жүктемені оңай көтерді. Сайт ұшты. Фаундер өзінің мыңдаған тіркеулерін алды, ал біз — тағы бір лоялды клиентке ие болдық. Егер олар ескі архитектурада қалғанда, сервер бірінші минутта-ақ "жатып қалар" еді, ал жарнамалық бюджет босқа кетер еді.

12-Factor App ережелері: Стартапқа арналған Киелі кітап

Егер сіз жобаңыздың масштабтала алғанын қаласаңыз, 12-Factor App принциптерін басынан бастап енгізіңіз. Бұл хипстер-әзірлеушілердің қыңырлығы емес, бұл қанмен жазылған индустрия стандарттары. Міне, олардың ең маңыздылары:

1. Stateless (Күйсіз қосымша)

Сіздің қосымшаңыз ешқандай деректерді локальді сақтамауы керек. Кез келген серверді кез келген уақытта "өлтіріп", жаңасын іске қосуға болады, ал пайдаланушы мұны байқамауы керек. Файлдар — объектілік қоймаға (Cloud Storage/S3). Сессиялар — Redis-ке. База — жеке басқарылатын серверге (Cloud SQL).

2. Қоршаған орта айнымалыларындағы конфигурация

Құпия сөздерді ешқашан кодта сақтамаңыз. Secret Manager пайдаланыңыз. Код әзірлеу, тестілеу және продакшн орталары үшін бірдей болуы керек. Тек қоршаған орта айнымалылары ғана ерекшеленуі тиіс.

3. Автоматтандырылған CI/CD

Деплой бір түймені басу арқылы (немесе Git-те тармақтарды біріктіру кезінде автоматты түрде) орындалуы керек. Cloud Build, GitLab CI немесе GitHub Actions пайдаланыңыз. Код Docker-бейнесіне жиналуы, автотесттермен тексерілуі және содан кейін ғана серверлерге таратылуы тиіс (қате болған жағдайда тоқтап қалмай дереу кері қайтуға болатындай етіп Blue/Green немесе Canary deployment стратегияларын пайдаланған жөн).

Бұлт неге жас бизнестің ең жақын досы?

Көптеген стартаптар мұны "қымбат" деп санап, Google Cloud немесе AWS сияқты бұлттық провайдерлерден қорқады. Және жергілікті хостерлерден арзан серверлерді жалға алуға барады. Бірақ иеленудің нақты құнын (TCO) есептеп көрейік.

Арзан VPS пайдаланған кезде бэкаптарды өзіңіз баптайсыз, деректер базасының репликациясын өзіңіз көтересіз, баланстау скрипттерін өзіңіз жазасыз. Сіз "темірді" жұмыс жағдайында ұстап тұру үшін DevOps-инженеріңіздің (оның нарықтағы бағасы айына $3000-нан басталады) ондаған сағатын жұмсайсыз.

Google Cloud-та сіз басқарылатын сервистерді (Managed Services) пайдаланасыз. Мысалы, Cloud SQL. Сіз бір түймені басасыз, ал Google-дің өзі деректер базасын өрістетеді, күнделікті бэкаптарды өзі жасайды, ақауларға төзімділік үшін (High Availability) репликацияны өзі баптайды және қауіпсіздік патчтарын өзі орнатады. Сіздің әзірлеушіңіз Linux баптауларын шұқумен емес, бизнес-логикамен айналысады.

Ал Cloud Run (Serverless) сияқты сервистер тек нақты жұмыс уақыты үшін төлеуге мүмкіндік береді. Егер түнде сіздің сайтыңызға ешкім кірмесе, Cloud Run нөлге дейін масштабталады және сіз $0 төлейсіз. Бұл күтпеген трафигі бар стартап үшін тамаша модель.

Инфрақұрылым код ретінде (IaC)

Тағы бір жиі кездесетін қате — инфрақұрылымды бұлттық провайдердің веб-интерфейсінде "шертіп" жасау. Бүгін сіз сервер жасадыңыз, ертең база қостыңыз, бүрсігүні брандмауэрді баптадыңыз. Một айдан кейін сіз қандай порттар ашық екенін және бәрі неге жұмыс істеп тұрғанын есіңізге түсіре алмайсыз. Ал егер біреу байқаусызда базаны өшіріп тастаса, сіз ортаны жылдам қалпына келтіре алмайсыз.

ОЗАТ-та біз Terraform пайдаланамыз. Инфрақұрылым кодпен сипатталады. Жаңа сервер қалайсыз ба? Сіз код жазасыз, оны ревью жасайсыз және terraform apply командасын іске қосасыз. Сіздің барлық архитектураңыз құжатталған, нұсқаланған және жаһандық апат болған жағдайда 15 минут ішінде басқа аймақта нөлден бастап өрістетіле алады.

Архитектураны инвесторларға қалай таныстыруға болады

Инвесторлар ақылдырақ бола бастады. Олар енді тек әдемі презентация мен конверсия метрикаларына қарамайды. Due Diligence (мәміле алдындағы терең тексеру) кезінде венчурлық қорлардың техникалық сарапшылары сіздің кодыңыз бен инфрақұрылымыңызға міндетті түрде кіреді.

Және егер олар FTP арқылы деплой жасайтын бір сервердегі монолитті көрсе, пайдаланушылар саны 10 есе өскенде, жүйені нөлден қайта жазу үшін оларға тағы миллион доллар құюға тура келетінін түсінеді. Бұл үлкен қауіп. Бірақ егер сіз оларға Google Cloud-тағы микросервистік архитектураны, бапталған CI/CD, IaC және орталарды (Dev/Stage/Prod) нақты бөлуді көрсетсеңіз — сіздің компанияңыздың бағасы (valuation) автоматты түрде өседі, өйткені сіз Enterprise деңгейіне дайынсыз.

Архитектураны бірінші күннен дұрыс қалау — бұл артық төлем емес, бұл сіздің тыныштығыңыз бен бизнесіңіздің болашағына салынған инвестиция. Серверлерді "тізеде" жинауды доғарыңыз және жалғызмүйіздер (unicorns) жұмыс істейтін технологияларды пайдаланыңыз.

Дұрыс және инфарктсыз масштабталыңыз!