Production ենթակառուցվածք՝ լավագույն setup-ը յուրաքանչյուր փուլի համար

01Սկզբունքներ՝ մինչև դիագրամները

Լավ ենթակառուցվածքը ձանձրալի է՝ կանխատեսելի deploy-ներ, հստակ պատասխանատվություն և ձախողումներ, որոնք նկատվում են և վերականգնելի են։ Գործիքներ ընտրելուց առաջ պատասխանիր չորս հարցի։ Որքա՞ն downtime կարող է հանդուրժել բիզնեսը (availability target)։ Որքա՞ն տվյալ կարող է այն կորցնել (RPO), և որքա՞ն արագ պետք է վերականգնվի (RTO)։ Ո՞վ է այն շահագործելու գիշերվա ժամը 3-ին։ Ինչքա՞ն է ամսական բյուջեն։ Հետո աճիր քայլերով։ Յուրաքանչյուր քայլ պետք է վերացնի իրական bottleneck կամ ռիսկ, որը կարող ես անվանել՝ տվյալների բազան, որը կռվում է հավելվածի հետ հիշողության համար, մեկ սկավառակի վրա խրված upload-ներ, մեկ սերվեր, որը single point of failure է, կամ թիմ, որը deploy է անում տասնյակ ծառայություններ։ Հաջորդ փուլին չափազանց վաղ անցնելը ավելացնում է ծախս և բարդություն՝ առանց օգուտի, իսկ չափազանց ուշ անցնելը նշանակում է outage-ներ։ Ինչ փուլ էլ լինի, ենթակառուցվածքը նկարագրված պահիր կոդով կամ գոնե գրավոր runbook-ներով, որպեսզի այն կարելի լինի վերակառուցել։

02Փուլ 1՝ ճիշտ արված մեկ VPS

MVP-ի, փոքր բիզնեսի կայքի կամ ներքին գործիքի համար մեկ լավ կարգավորված սերվերը (2-ից 8 GB RAM) հաճախ լավագույն ընտրությունն է՝ էժան, արագ, հեշտ հասկանալի։ nginx-ը terminate է անում HTTPS-ը և route է անում հավելվածներին, PHP-FPM-ը և Node-ը աշխատում են իրենց օգտատերերով, տվյալների բազան և Redis-ը լսում են localhost-ում, worker-ները աշխատում են supervisor-ի կամ systemd-ի տակ։ Docker Compose-ը լավ տարբերակ է այս ամենը վերարտադրելի փաթեթավորելու համար։ Այն «ճիշտ արված» դարձնողը հավելվածների շուրջ ամեն ինչն է՝ hardening baseline-ը, Cloudflare-ը առջևում, տվյալների բազայի գիշերային dump-երը՝ պատճենված սերվերից դուրս, provider-ի snapshot-ները, uptime-ի և սկավառակի alert-ները և script արված deploy release թղթապանակներով։ Դրա թուլությունն այն է, որ այն single point of failure է, ուստի վերականգնման արագությունը կարևոր է․ պետք է կարողանաս այն վերակառուցել script-երից և backup-ներից ժամերի ընթացքում, և պետք է դա գոնե մեկ անգամ փորձած լինես։

• Cloudflare (DNS, WAF, CDN) → nginx → app պրոցեսներ → լոկալ DB/Redis։
• Backup-ները off-site, snapshot-ները միացված, restore-ները ստուգված։
• Տիպիկ արժեք՝ ամսական տասնյակ դոլարներ։

03Փուլ 2՝ app սերվեր + managed տվյալների բազա + object storage + CDN

Երբ տվյալները արժեքավոր են դառնում, կամ տվյալների բազային ավելի շատ հիշողություն է պետք, state-ը տեղափոխիր app սերվերից դուրս։ Managed տվյալների բազան բերում է ավտոմատ backup-ներ, point-in-time recovery և ոչ պարտադիր standby։ Օգտատերերի upload-ները գնում են S3-համատեղելի object storage լոկալ սկավառակի փոխարեն և սպասարկվում են CDN-ի միջոցով։ Session-ները և cache-ը գնում են Redis՝ managed կամ private սերվերի վրա։ App սերվերն այժմ չի պահում ոչ մի եզակի տվյալ, և դա է հիմնական փոփոխությունը․ կարող ես այն վերակառուցել կամ փոխարինել ցանկացած պահի, resize անել քիչ ռիսկով և հետագայում ավելացնել երկրորդը։ Կոնֆիգուրացիան և secret-ները գալիս են environment փոփոխականներից, և deploy-ները կառուցում են նույն artifact-ը staging-ի և production-ի համար։ Այս փուլը շատ շահութաբեր պրոդուկտների համար «ոսկե միջինն» է և լավ caching-ի ու index-ների դեպքում կարող է զարմանալի քանակությամբ traffic տանել։

• App սերվերը stateless է՝ միայն կոդ + config։
• Տվյալների բազա՝ managed, հասանելիություն միայն private ցանցով, PITR-ը միացված։
• Ֆայլեր՝ object storage + CDN․ upload-ներ սերվերի սկավառակի վրա չկան։

04Փուլ 3՝ load balancer, մի քանի app սերվեր, replica-ներ և queue-եր

Երբ մեկ app սերվերն այլևս բավարար չէ, կամ բիզնեսը պետք է գոյատևի սերվերի ձախողումից, երկու կամ ավելի նույնական app սերվերների առջևում դիր load balancer, իդեալում՝ տարբեր availability zone-ներում։ Load balancer-ը health-check է անում դրանք և դադարեցնում է traffic ուղարկել կոտրվածին։ Deploy-ները անցնում են սերվերներով մեկ առ մեկ։ Տվյալների բազան ստանում է read replica-ներ ծանր կարդալու traffic-ի և հաշվետվությունների համար, և standby՝ failover-ի համար։ Դանդաղ աշխատանքը (email-ներ, PDF-ներ, նկարների մշակում, webhook-ներ, import-ներ) տեղափոխվում է background queue-եր՝ առանձին worker սերվերներով, որպեսզի վեբ request-ները արագ մնան, և պոռթկումները կլանվեն։ Զգույշ եղիր թաքնված state-ի հետ․ ֆայլերի upload-ները, session-ները, պլանավորված job-երը (scheduler-ը գործարկիր միայն մեկ node-ի վրա կամ օգտագործիր lock) և in-memory cache-երը բոլորը պետք է լինեն ընդհանուր կամ համակարգված։ Replication lag-ը նաև նշանակում է, որ օգտատերը կարող է replica-ից անմիջապես չկարդալ այն, ինչ հենց նոր գրել է։

05Փուլ 4՝ կոնտեյներներ և Kubernetes

Կոնտեյներները յուրաքանչյուր ծառայություն փաթեթավորում են իր dependency-ների հետ, ուստի նույն image-ը աշխատում է laptop-ի վրա, CI-ում և production-ում։ Docker Compose-ը մեկ կամ մի քանի սերվերի վրա շատ բան է ծածկում։ Kubernetes-ը (կամ managed այլընտրանք, ինչպես ECS-ը, Cloud Run-ը կամ managed Kubernetes ծառայությունը) ավելացնում է scheduling շատ մեքենաների վրա, self-healing, rolling update-ներ, autoscaling և service discovery։ Այն իրեն արդարացնում է, երբ գործարկում ես շատ ծառայություններ, մի քանի թիմ deploy է անում անկախ, կամ traffic-ը խիստ տատանվում է։ Գինը իրական է՝ պլատֆորմ, որը պետք է սովորել և շահագործել, ավելի շատ YAML, ցանցը և անվտանգությունը սխալ կարգավորելու ավելի շատ ձևեր և սովորաբար ավելի բարձր հաշիվ։ Managed control plane-ը հեռացնում է ցավի մի մասը, բայց ոչ workload-երի բարդությունը։ Շատ հաջողված պրոդուկտների այն երբեք պետք չի գալիս․ ընդունիր այն, երբ դրա բացակայության համակարգման ծախսը հստակորեն ավելի բարձր է։

06Միջավայրեր, secret-ներ, DR, monitoring և ծախսեր

Յուրաքանչյուր փուլի պետք է առնվազն staging միջավայր, որը տարբերակներով և կոնֆիգուրացիայով կրկնում է production-ը, իր տվյալների բազայով և credential-ներով, որպեսզի փոփոխությունները ստուգվեն, մինչև հաճախորդները կտեսնեն դրանք։ Secret-ները ներարկվում են ըստ միջավայրի env ֆայլերից կամ secrets manager-ից, երբեք չեն կիսվում staging-ի և production-ի միջև, երբեք Git-ում չեն։ Disaster recovery-ն նշանակում է գրավոր, փորձարկված քայլեր՝ որտեղ են backup-ները, ինչպես վերակառուցել սերվերը, ինչպես failover անել տվյալների բազան, ով է որոշում։ Monitoring-ն ունի երեք մաս՝ մետրիկաներ (CPU, հիշողություն, սկավառակ, latency, սխալների մակարդակ, queue-ի երկարություն, օրինակ՝ Prometheus-ով և Grafana-ով), կենտրոնացված հավաքված log-եր (Loki կամ hosted ծառայություն) և alert-ներ, որոնք ինչ-որ մեկին արթնացնում են միայն օգտատերերի վրա իրական ազդեցության դեպքում, գումարած արտաքին uptime ստուգումներ։ Ծախսերը վերանայիր ամեն ամիս․ չօգտագործվող սերվերները, չափազանց մեծ instance-ները, հին snapshot-ները և egress-ի վճարները լուռ կուտակվում են։

• dev → staging → production, նույն build artifact-ը առաջ է տեղափոխվում։
• Alert՝ ըստ ախտանիշների (սխալներ, latency, downtime), հետաքննություն՝ մետրիկաներով և log-երով։
• Ռեսուրսները tag արա ըստ նախագծի և միջավայրի՝ տեսնելու, թե ուր է գնում գումարը։

07Սերվերների տեղափոխում կամ միավորում առանց տվյալների կորստի

Կայքերը նոր սերվեր տեղափոխելը կամ մի քանի սերվեր ավելի քչի մեջ միավորելը հիմնականում ուշադիր հաշվառում է։ Նախ inventory՝ հին սերվերի յուրաքանչյուր domain, հավելված, տվյալների բազա, cron job, worker, certificate, mailbox, environment ֆայլ և upload թղթապանակ։ Նոր սերվերը կառուցիր քո baseline-ից, հետո պատճենիր կոդը, ֆայլերը և տվյալների բազաները և ստուգիր․ գործարկիր հավելվածները hosts-file override-ով, համեմատիր տողերի և ֆայլերի քանակները, ստուգիր log-երը։ Մեկ օր առաջ իջեցրու DNS TTL-ը։ Cutover-ի ժամանակ հին հավելվածը կարճ ժամանակով դիր maintenance ռեժիմի, գործարկիր ֆայլերի վերջնական incremental sync և տվյալների բազայի թարմ dump, import արա այն, հետո փոխարկիր DNS-ը (Cloudflare proxy-ով՝ ակնթարթորեն)։ Հին սերվերը թող աշխատի, անձեռնմխելի, մինչև նորի վրա traffic-ը, տվյալները և backup-ները օրերով ստուգվեն․ միայն դրանից հետո շահագործումից հանիր այն՝ վերջնական backup-ից հետո։

1# 1. Initial copy of code and uploads (preserves owners, permissions, links)
2rsync -aHAX --info=progress2 [email protected]:/var/www/shop/ /var/www/shop/
3 
4# 2. At cutover: maintenance mode on the old server, then final delta sync
5ssh [email protected] 'cd /var/www/shop && php artisan down'
6rsync -aHAX --delete [email protected]:/var/www/shop/storage/ /var/www/shop/storage/
7 
8# 3. Fresh database copy streamed directly to the new server
9ssh [email protected] 'mysqldump --single-transaction --routines --triggers shop_db' | mysql shop_db
10 
11# 4. Verify before switching DNS
12mysql -e "SELECT COUNT(*) FROM shop_db.orders;"
13ssh [email protected] "mysql -e 'SELECT COUNT(*) FROM shop_db.orders;'"
14curl -sI --resolve example.com:443:127.0.0.1 https://example.com | head -1

08Հասանելիության մաթեմատիկա. «ինը»-եր, dependency-ներ և error budget-ներ

Հասանելիության թիրախը վերածվում է downtime-ի կոնկրետ թույլատրելի ծավալի։ 30-օրյա ամսվա ընթացքում 99.5 տոկոսը թույլ է տալիս մոտ 3.6 ժամ, 99.9 տոկոսը՝ մոտ 43 րոպե, իսկ 99.99 տոկոսը՝ մոտ 4.3 րոպե, ինչին ոչ մի մարդկային on-call գործընթաց չի կարող հասնել առանց ավտոմատ failover-ի։ Հաջորդաբար միացված dependency-ները բազմապատկվում են. եթե հավելվածին պետք են սերվերը, database-ը և payment API-ն, յուրաքանչյուրը 99.9 տոկոս, ամբողջ ճանապարհը մոտավորապես 99.7 տոկոս է։ Զուգահեռ ավելորդությունը բարձրացնում է այն. երկու անկախ app սերվեր, որոնցից յուրաքանչյուրը ձախողվում է ժամանակի 0.1 տոկոսում, միասին անհասանելի են ընդամենը մոտ 0.0001 տոկոս, եթե դրանց ձախողումները իսկապես անկախ են, ինչը հաճախ խախտում են ընդհանուր database-ները, ռեգիոնները կամ deploy-ները։ Ձեր SLO-ի և 100 տոկոսի միջև տարբերությունը error budget-ն է։ Երբ այն առողջ է, ֆունկցիաներն ավելի արագ release արեք, երբ սպառված է, դանդաղեցրեք և ներդրում արեք հուսալիության մեջ։ Սա հուսալիության շուրջ վեճերը վերածում է թվի, որի շուրջ համաձայն են և՛ բիզնեսը, և՛ ինժեներները։

09Deploy ռազմավարություններ և expand-contract migration-ներ

Rolling deploy-ը load balancer-ի հետևում instance-ները փոխարինում է մեկ առ մեկ. էժան է, բայց որոշ ժամանակ հին և նոր տարբերակները միասին են տրաֆիկ սպասարկում։ Blue-green-ը աշխատեցնում է ամբողջական երկրորդ միջավայր և տրաֆիկը փոխում է միանգամից՝ ակնթարթային rollback-ով հետ փոխելու միջոցով, release-ի ընթացքում կրկնակի արժեքով։ Canary-ն տրաֆիկի փոքր բաժին, ասենք 5 տոկոս, ուղարկում է նոր տարբերակին և լայնացնում է այն միայն այն դեպքում, եթե error rate-երը և latency-ն առողջ են մնում։ Բոլոր երեքը պահանջում են, որ կոդի երկու տարբերակ կարողանա աշխատել նույն database-ի դեմ։ Expand-contract pattern-ը դա հնարավոր է դարձնում. նախ expand (ավելացրեք նոր սյունակը կամ աղյուսակը՝ nullable, առանց որևէ բան հեռացնելու), deploy արեք կոդ, որը գրում է երկուսում էլ և կարդում նորից, backfill արեք խմբաքանակներով, և միայն հետագա release-ում contract արեք՝ հեռացնելով հին սյունակը։ Երբեք մի վերանվանեք կամ մի հեռացրեք սյունակը նույն release-ում, որը դադարում է այն օգտագործել։ Հենց այս կարգապահությունն է, ոչ թե deploy գործիքը, որ zero-downtime release-ները դարձնում է իրական։

• Release 1. ավելացրեք nullable սյունակ, deploy արեք կոդ, որը գրում է հինում և նորում։
• Backfill արեք փոքր խմբաքանակներով, ոչ պիկային ժամերին, առաջընթացը log անելով։
• Release 2. կարդացեք միայն նոր սյունակը։ Release 3. հեռացրեք հինը։

10Alert-ներ այն բանի վրա, ինչ զգում են օգտատերերը. SLO-ներ և burn rate-եր

CPU-ի կամ հիշողության վրա alert-ները աղմուկ են ստեղծում. 90 տոկոս CPU-ով սերվերը, որն արագ է սպասարկում յուրաքանչյուր հարցում, նորմալ է։ Փոխարենը մարդկանց page արեք ախտանիշների վրա՝ ախտորոշելիս օգտագործելով RED մեթոդը ծառայությունների համար (rate, errors, duration) և USE-ը ռեսուրսների համար (utilisation, saturation, errors)։ Ամենահուսալի pattern-ը Google SRE workbook-ի burn-rate alert-ն է. alert արեք, երբ error budget-ը սպառվում է շատ ավելի արագ, քան SLO-ն թույլ է տալիս, ստուգված երկար և կարճ պատուհանով, որպեսզի այն արագ գործարկվի իրական incident-ների ժամանակ և արագ լուծվի դրանցից հետո։ Մեկ ժամ պահպանվող 14.4 burn rate-ը սպառում է 30-օրյա budget-ի 2 տոկոսը, ինչն արժե ինչ-որ մեկին արթնացնել։ Ավելի դանդաղ burn-երը դառնում են ticket-ներ, ոչ թե page-եր։ Վերահսկեք Prometheus label-ների cardinality-ն. user ID-ները կամ ամբողջական URL-ները որպես label ստեղծում են միլիոնավոր series և կարող են վայր գցել մոնիթորինգի համակարգը հենց այն պահին, երբ այն ձեզ պետք է։

1groups:
2  - name: slo
3    rules:
4      - alert: ErrorBudgetFastBurn
5        expr: |
6          (sum(rate(http_requests_total{status=~"5.."}[1h]))
7            / sum(rate(http_requests_total[1h]))) > (14.4 * 0.001)
8          and
9          (sum(rate(http_requests_total{status=~"5.."}[5m]))
10            / sum(rate(http_requests_total[5m]))) > (14.4 * 0.001)
11        for: 2m
12        labels:
13          severity: page
14        annotations:
15          summary: "99.9% SLO error budget burning 14x too fast"

11Capacity planning Little-ի օրենքով

Little-ի օրենքն ասում է, որ համակարգում հարցումների միջին քանակը հավասար է ժամանման արագությանը բազմապատկած դրանում անցկացրած ժամանակով։ Վայրկյանում 200 հարցման և 250 ms միջին պատասխանի ժամանակի դեպքում ցանկացած պահի մոտ 50 հարցում ընթացքի մեջ է, ուստի ձեզ պետք է առնվազն 50 PHP-FPM worker կամ համարժեք concurrency՝ գումարած պաշար։ Եթե latency-ն կրկնապատկվում է, որովհետև database-ը դանդաղում է, նույն տրաֆիկին պետք է 100 worker, ահա թե ինչու են դանդաղ dependency-ները այդքան հանկարծակի սպառում worker pool-երը։ Պլանավորեք պիկերի, ոչ թե միջինների համար. շատ պրոդուկտներ պիկային ժամերին կամ արշավների ժամանակ տեսնում են միջինից երեքից տասն անգամ ավելի տրաֆիկ։ Կայուն վիճակում utilisation-ը պահեք մոտ 50-ից 70 տոկոս, որպեսզի ձախողված node-ը կամ պիկը չտապալի մնացածը։ Launch-երից առաջ load test արեք k6-ի նման գործիքով՝ ավելացնելով բեռը, մինչև latency-ն թեքվի, և գրանցեք, թե որտեղ է այն թեքվում. այդ թիվը ձեր իրական թողունակությունն է։ Արժեքը հետևում է նույն տրամաբանությանը. right-size արեք ըստ չափված պիկերի և հետևեք egress-ին ու storage-ին, որոնք լուռ աճում են։