Մասշտաբավորում և load balancing

01Ուղղահայաց ընդդեմ հորիզոնականի, և ինչու է stateless-ը կարևոր

Ուղղահայաց մասշտաբավորումը նշանակում է ավելի մեծ մեքենա՝ ավելի շատ CPU, RAM, ավելի արագ դիսկեր։ Այն պարզ է, կոդի փոփոխություն չի պահանջում և հաճախ ճիշտ առաջին քայլն է, բայց ունի առաստաղ, թանկանում է, և մեկ մեքենան դեռ ձախողման մեկ կետ է։ Հորիզոնական մասշտաբավորումը նշանակում է ավելի շատ մեքենաներ, որոնք load balancer-ի հետևում գործարկում են հավելվածի նույնական պատճեններ։ Այն մասշտաբավորվում է ավելի հեռու և գոյատևում է հանգույցի կորուստը, բայց միայն եթե ցանկացած ինստանս կարող է սպասարկել ցանկացած հարցում։ Դրա համար պետք է stateless հավելված․ սեսիաները Redis-ում կամ ստորագրված թոքեններում, upload-ները object storage-ում՝ լոկալ դիսկի փոխարեն, քեշը ընդհանուր պահոցում, պլանավորված job-երը գործարկվում են մեկ անգամ, ոչ թե ամեն հանգույցում, և ոչ մի կարևոր վիճակ հիշողության մեջ։ Հավելվածները stateless դարձրու վաղ, նույնիսկ մեկ սերվերի վրա, և հորիզոնական մասշտաբավորումը կդառնա պարզ։

• Սեսիաներ և քեշ՝ Redis, ոչ թե պրոցեսի հիշողություն կամ լոկալ ֆայլեր։
• Ֆայլեր՝ S3-համատեղելի object storage՝ մատուցվող CDN-ով։
• Cron՝ մեկ scheduler կամ բաշխված lock, որպեսզի job-երը N անգամ չգործարկվեն։

02Load balancer-ներ՝ L4 ընդդեմ L7, ալգորիթմներ, health check-եր

Load balancer-ը հարցումները բաշխում է ինստանսների միջև։ Layer 4 balancer-ները աշխատում են TCP/UDP կապերի հետ․ շատ արագ են, անկախ պրոտոկոլից, բայց «կույր» են URL-ների և header-ների նկատմամբ։ Layer 7 balancer-ները հասկանում են HTTP․ նրանք ավարտում են TLS-ը, ուղղորդում ըստ host-ի կամ path-ի, ավելացնում header-ներ, կրկնում ձախողված հարցումները, սեղմում և rate limit անում։ nginx-ը, HAProxy-ն, Envoy-ն, Traefik-ը և ամպային application load balancer-ները տարածված L7 տարբերակներ են։ Ալգորիթմներից են round robin (պարզ), least connections (ավելի լավ է, երբ հարցումների տևողությունը տարբեր է), weighted (խառը սարքավորում) և hashing (նույն կլիենտը՝ նույն սերվերին)։ Health check-երը հեռացնում են անսարք ինստանսները․ պասիվ ստուգումները հետևում են իրական տրաֆիկի սխալներին, ակտիվները պարբերաբար հարցում են անում health endpoint-ին։ Sticky session-ները օգտատիրոջը կապում են մեկ ինստանսի․ դրանք թաքցնում են stateful լինելը և անհավասարակշռում բեռը, ուստի նախընտրիր ընդհանուր սեսիաների պահոց, իսկ «կպչունությունը» պահիր այնպիսի դեպքերի համար, ինչպես WebSocket fallback-երը։

1upstream app {
2    least_conn;
3    server 10.0.0.11:3000 max_fails=3 fail_timeout=10s;
4    server 10.0.0.12:3000 max_fails=3 fail_timeout=10s;
5    keepalive 32;
6}
7 
8server {
9    listen 443 ssl;
10    server_name example.com;
11    # ssl_certificate / ssl_certificate_key lines go here
12    location / {
13        proxy_pass http://app;
14        proxy_http_version 1.1;
15        proxy_set_header Connection "";
16        proxy_set_header Host $host;
17        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
18        proxy_next_upstream error timeout http_502 http_503;
19    }
20}

03Քեշավորման շերտեր՝ CDN, reverse proxy, հավելված, տվյալների բազա

Ամենաէժան հարցումն այն է, որը երբեք չի հասնում քո հավելվածին։ CDN-ը քեշավորում է ստատիկ ռեսուրսները և քեշավորվող էջերը օգտատերերին մոտ edge կետերում, ինչպես նաև կլանում է պարզ DDoS տրաֆիկը։ Reverse-proxy քեշը (nginx, Varnish) կարող է մի քանի վայրկյան մատուցել կրկնվող պատասխանները, ինչը հարթեցնում է պիկերը «տաք» էջերում։ Հավելվածում Redis քեշը cache-aside պատերնով պահում է թանկ հարցումների արդյունքները TTL-ով։ Տվյալների բազան ունի իր buffer cache-ը, ուստի լավ ինդեքսները «տաք» տվյալները պահում են հիշողության մեջ։ Յուրաքանչյուր շերտի պետք է invalidation-ի հստակ պատմություն․ ռեսուրսների ֆայլանուններում տարբերակ դիր, էջերի համար օգտագործիր կարճ TTL կամ purge արա փոփոխության ժամանակ, և ջնջիր կամ թարմացրու key-երը, երբ տվյալները փոխվում են։ Պաշտպանվիր stampede-ից, երբ սիրված key-ի ժամկետը լրանում է՝ lock-երով, request coalescing-ով կամ թեթևակի պատահական TTL-ներով։

04Տվյալների բազայի մասշտաբավորում՝ pooling, ռեպլիկաներ, partitioning, sharding

Տվյալների բազաները սովորական «խցանումն» են, որովհետև պահում են վիճակ և դժվար է դրանք բազմապատկել։ Աշխատիր ըստ գնի հերթականության։ Առաջինը՝ ինդեքսներ և հարցումների շտկում, որոնք գտնում ես slow-query լոգերով և EXPLAIN-ով։ Երկրորդը՝ connection pooling․ PostgreSQL-ը յուրաքանչյուր կապի համար օգտագործում է առանձին պրոցես, ուստի հավելվածի տասնյակ ինստանսներ կարող են սպառել այն. PgBouncer-ը transaction ռեժիմում թույլ է տալիս հազարավոր կլիենտային կապերին կիսել փոքր pool։ Երրորդը՝ read replica-ներ կարդալով ծանրաբեռնված տրաֆիկի համար՝ հիշելով, որ ռեպլիկաները ուշանում են, ուստի read-your-own-writes հոսքերը պետք է գնան primary։ Չորրորդը՝ մեծ աղյուսակների partitioning (ըստ ամսաթվի կամ tenant-ի) մեկ տվյալների բազայի ներսում, որպեսզի ինդեքսները փոքր մնան և հին տվյալները էժան ջնջվեն։ Վերջինը՝ sharding․ տվյալների բաժանում մի քանի տվյալների բազաների միջև ըստ shard key-ի, օրինակ՝ tenant ID-ի։ Sharding-ը մասշտաբավորում է գրառումները, բայց դժվարացնում է միջ-shard հարցումները, տրանզակցիաները և վերահավասարակշռումը, ուստի հետաձգիր այն, մինչև չափած լինես կարիքը։

1; /etc/pgbouncer/pgbouncer.ini
2[databases]
3app = host=127.0.0.1 port=5432 dbname=app
4 
5[pgbouncer]
6listen_addr = 127.0.0.1
7listen_port = 6432
8auth_type = scram-sha-256
9auth_file = /etc/pgbouncer/userlist.txt
10pool_mode = transaction
11max_client_conn = 1000
12default_pool_size = 20

05Հերթեր, back-pressure և capacity planning

Ամեն ինչ չէ, որ պետք է տեղի ունենա հարցման ներսում։ Email-ների ուղարկում, հաշվետվությունների գեներացում, նկարների չափափոխում, ERP-ի հետ համաժամեցում՝ ուղարկիր դրանք հերթ և թող worker-ները մշակեն կայուն տեմպով։ Հերթերը կլանում են պիկերը, մեկուսացնում են դանդաղ երրորդ կողմերին և թույլ են տալիս worker-ները մասշտաբավորել վեբ սերվերներից առանձին։ Ավելացրու նաև back-pressure․ rate limit-եր ամեն կլիենտի համար, timeout-ներ ամեն արտաքին կանչի վրա, circuit breaker-ներ ձախողվող կախվածությունների համար և նրբանկատ դեգրադացիա (մատուցիր քեշավորված տվյալներ, թաքցրու ոչ էական վիջեթները) գերբեռնվածության ժամանակ։ Capacity planning-ը կապում է այս ամենը։ Չափիր ընթացիկ թողունակությունը, latency-ի պերցենտիլները (p95, p99) և ռեսուրսների օգտագործումը, load test արա k6-ի պես գործիքներով՝ կոտրման կետը գտնելու համար, պարզիր, թե որ ռեսուրսն է առաջինը հագենում, հետո պահիր պաշար (հաճախ 30-ից 50 տոկոս) պիկերի և հանգույցների ձախողման համար։ Կրկնիր խոշոր ֆիչերից հետո, որովհետև «խցանումները» տեղափոխվում են։

• Հետևիր p95/p99 latency-ին, ոչ թե միջինին. միջինը թաքցնում է դանդաղ օգտատերերին։
• Load test արա staging պատճենի վրա՝ իրատեսական տվյալների ծավալներով։
• Պլանավորիր պիկի ժամին մեկ հանգույց կորցնելը (N+1 capacity)։

06Հերթերի տեսություն, որը կարող ես կիրառել․ Little-ի օրենք և ծանրաբեռնվածություն

Little-ի օրենքը կապում է երեք թիվ․ ընթացքի մեջ գտնվող հարցումներ = ժամանման արագություն x համակարգում անցկացրած միջին ժամանակ։ Վայրկյանում 200 հարցման և մեկ հարցման համար 250 ms-ի դեպքում ցանկացած պահի մոտ 50 հարցում ընթացքի մեջ է, ինչը ցույց է տալիս, թե քանի worker, thread կամ տվյալների բազայի միացում է քեզ պետք։ Երկրորդ դասը ոչ գծային է․ երբ ռեսուրսը մոտենում է լիարժեք ծանրաբեռնվածությանը, սպասման ժամանակը ոչ թե հավասարաչափ աճում է, այլ պայթում։ 50 տոկոս զբաղված սերվերն ունի կարճ հերթեր․ 90 տոկոսի դեպքում փոքր պոռթկումներն արդեն երկար հերթեր են ստեղծում, և p99 latency-ն ցատկում է։ Ահա թե ինչու է պաշարը կարևոր, և ինչու են միջինները մոլորեցնում։ Սա նաև բացատրում է, թե ինչու գերբեռնված տվյալների բազային միացումներ ավելացնելը այն դանդաղեցնում է․ ավելի շատ զուգահեռ աշխատանքը նշանակում է ավելի շատ մրցակցություն, ոչ թե ավելի շատ throughput։ Pool-երի չափը որոշիր Little-ի օրենքով՝ պաշարով, և սահմանափակիր զուգահեռությունը, որպեսզի ավելցուկային բեռը սպասի քո վերահսկած հերթում։

• Ընթացքի մեջ = արագություն x latency․ օգտագործիր pool-երի և worker-ների չափը որոշելու համար։
• Պլանավորիր այնպես, որ պիկի ժամին հիմնական ռեսուրսները աշխատեն հագեցումից զգալիորեն ցածր։
• Սահմանափակիր զուգահեռությունը եզրում՝ փոխանակ թույլ տալու, որ այն կուտակվի տվյալների բազայում։

07Retry-ների փոթորիկներ, timeout-ների բյուջեներ և load shedding

Retry-ները օգնում են կարճատև խափանումների ժամանակ և վնասում գերբեռնվածության ժամանակ։ Եթե երեք շերտերից յուրաքանչյուրը երեք անգամ retry է անում, մեկ օգտատիրական հարցումը կարող է դառնալ 27 կանչ ամենաներքևի ծառայությանը՝ հենց այն պահին, երբ այն դժվարանում է։ Retry արա միայն մեկ շերտում, միայն իդեմպոտենտ գործողությունները, exponential backoff-ով և full jitter-ով, և retry-ները սահմանափակիր բյուջեով (օրինակ՝ retry-ները կարող են ավելացնել առավելագույնը 10 տոկոս լրացուցիչ բեռ)։ Յուրաքանչյուր հարցման տուր deadline և մնացած ժամանակը փոխանցիր downstream, որպեսզի ներքին կանչերը երբեք չգերազանցեն օգտատիրոջ համբերությունը։ Գերբեռնվածության ժամանակ մերժիր վաղ՝ 429 կամ 503 և Retry-After-ով, փոխանակ անվերջ հերթում պահելու․ արագ ձախողումն ավելի էժան է, քան դանդաղը։ Առաջնահերթություն տուր տրաֆիկին․ analytics-ը և recommendations-ը կտրիր checkout-ից առաջ։ Circuit breaker-ները դադարեցնում են անընդհատ ձախողվող կախվածության կանչերը և պարբերաբար ստուգում այն՝ ժամանակ տալով վերականգնվելու։

1# nginx: per-IP rate limit with a small burst, reject the rest fast
2limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
3limit_req_status 429;
4 
5server {
6    location /api/ {
7        limit_req zone=api burst=40 nodelay;
8        proxy_connect_timeout 2s;
9        proxy_read_timeout 10s;
10        proxy_pass http://app;
11    }
12}

08Consistent hashing և քեշի մասշտաբավորում

Երբ key-երը բաշխում ես N քեշի կամ shard հանգույցների միջև hash(key) mod N-ով, մեկ հանգույց ավելացնելը վերաքարտեզագրում է գրեթե բոլոր key-երը, քեշը դատարկվում է, և տվյալների բազան միանգամից ստանում է ամբողջ բեռը։ Consistent hashing-ը հանգույցներն ու key-երը տեղադրում է օղակի վրա․ յուրաքանչյուր key պատկանում է ժամացույցի սլաքի ուղղությամբ հաջորդ հանգույցին, ուստի հանգույց ավելացնելը կամ հեռացնելը տեղափոխում է key-երի միայն մոտ 1/N-ը։ Վիրտուալ հանգույցները (շատ կետեր մեկ սերվերի համար) հարթեցնում են բաշխումը։ Redis Cluster-ն օգտագործում է հարակից գաղափար․ 16,384 hash slot՝ բաշխված հանգույցներին, որոնք resharding-ի ժամանակ տեղափոխվում են կտորներով, և hash tag-եր, օրինակ՝ {tenant:42}, որպեսզի կապված key-երը մնան մեկ slot-ում։ Load balancer-ներում nginx-ի hash դիրեկտիվը consistent պարամետրով նույնն է անում upstream-ի ընտրության համար։ Տաք key-երի համար, որոնք մեկ հանգույցը չի կարող սպասարկել, ընդհանուր քեշի առջև ավելացրու փոքր in-process քեշ՝ կարճ TTL-ով։

09Tail latency և fan-out

Երբ մեկ հարցումը բաշխվում է շատ backend-ների, պատասխանի ժամանակը որոշում է ամենադանդաղը։ Եթե յուրաքանչյուր backend-ի դանդաղ պատասխանի հավանականությունը 1 տոկոս է, դրանցից 100-ին դիպչող հարցումը դանդաղ է ժամանակի մեծ մասում։ Tail latency-ն առաջանում է garbage collection-ի դադարներից, սառը քեշերից, աղմկոտ հարևաններից, lock-երի մրցակցությունից և հերթերից։ Պաշտպանություններ․ կրճատիր fan-out-ը նախապես հաշվարկելով կամ ապանորմալացնելով, դիր timeout-ներ յուրաքանչյուր կանչի համար և վերադարձրու մասնակի արդյունքներ, երբ ոչ էական մասերը ուշանում են, օգտագործիր hedged request-ներ՝ ուղարկելով երկրորդ պատճենը մեկ այլ ռեպլիկայի, երբ կանչը գերազանցում է p95-ը, միայն իդեմպոտենտ ընթերցումների համար, և ինստանսների չափերն ու runtime կարգավորումները պահիր միատեսակ, որպեսզի մեկ թույլ հանգույցը չքաշի ամբողջ pool-ը։ Հիմնական endpoint-ների համար միշտ ցույց տուր p99-ը և p99.9-ը p50-ի կողքին և ուսումնասիրիր ամենադանդաղ trace-երը, ոչ միայն միջինները։