Ինչպես մենք ճեղքեցինք չինական մեծ պատը (մաս 2)

Hi!

Նիկիտան կրկին ձեզ հետ է, ընկերության համակարգի ինժեներ SEMrush. Եվ այս հոդվածով ես շարունակում եմ պատմությունը այն մասին, թե ինչպես մենք հայտնվեցինք լուծում գտնելու համար Չինական Firewall մեր ծառայության համար semrush.com:

В նախորդ մասը Ես ասացի:

• ինչ խնդիրներ են առաջանում որոշման ընդունումից հետո «Մենք պետք է այնպես անենք, որ մեր ծառայությունը աշխատի Չինաստանում»
• Ի՞նչ խնդիրներ ունի չինական ինտերնետը:
• ինչու է ձեզ անհրաժեշտ ICP լիցենզիա:
• ինչպես և ինչու մենք որոշեցինք փորձարկել մեր փորձնական մահճակալները Catchpoint-ի հետ
• որն էր Cloudflare China Network-ի վրա հիմնված մեր առաջին լուծման արդյունքը
• Ինչպես մենք սխալ գտանք Cloudflare DNS-ում

Այս հատվածը, իմ կարծիքով, ամենահետաքրքիրն է, քանի որ կենտրոնանում է բեմադրության կոնկրետ տեխնիկական իրագործումների վրա։ Եվ մենք կսկսենք, ավելի ճիշտ՝ կշարունակենք դրանով Alibaba Cloud- ը.

Alibaba Cloud- ը

Alibaba Cloud- ը բավականին մեծ ամպային մատակարար է, որն ունի բոլոր ծառայությունները, որոնք թույլ են տալիս իրեն ազնվորեն անվանել ամպային մատակարար: Լավ է, որ նրանք հնարավորություն ունեն գրանցվել օտարերկրյա օգտատերերի համար, և որ կայքի մեծ մասը թարգմանված է անգլերեն (Չինաստանի համար սա շքեղություն է): Այս ամպի մեջ դուք կարող եք աշխատել աշխարհի շատ տարածաշրջանների, մայրցամաքային Չինաստանի, ինչպես նաև Օվկիանոսային Ասիայի (Հոնկոնգ, Թայվան և այլն) հետ։

IPSEC

Սկսեցինք աշխարհագրությունից։ Քանի որ մեր փորձարկման կայքը գտնվում էր Google Cloud-ում, մեզ անհրաժեշտ էր «կապել» Alibaba Cloud-ը GCP-ի հետ, ուստի մենք բացեցինք այն վայրերի ցանկը, որտեղ Google-ը ներկա է: Այդ պահին նրանք դեռ չունեին իրենց տվյալների կենտրոնը Հոնկոնգում։
Ամենամոտ շրջանը պարզվեց Ասիա-արևելք 1 (Թայվան): Պարզվեց, որ Ալին մայրցամաքային Չինաստանի Թայվանին ամենամոտ շրջանն է cn-shenzhen (Շենժեն):

Հետ տեռաս նկարագրեց և բարձրացրեց ամբողջ ենթակառուցվածքը GCP-ում և Ali-ում: Ամպերի միջև 100 Մբիթ/վ արագությամբ թունելը գրեթե ակնթարթորեն բարձրացավ: Շենչժենի և Թայվանի կողմից բարձրացվել են պրոքսի վիրտուալ մեքենաներ: Շենժենում օգտատերերի տրաֆիկը դադարեցվում է, թունելի միջով անցնում է Թայվան, և այնտեղից այն ուղղակիորեն անցնում է մեր ծառայության արտաքին IP-ին։ մեզ-արևելք (ԱՄՆ Արևելյան ափ): Պինգ վիրտուալ մեքենաների միջև թունելի միջոցով 24ms, ինչն այնքան էլ վատ չէ։

Միևնույն ժամանակ մենք տեղադրեցինք փորձարկման տարածք Alibaba Cloud DNS. Գոտին NS Ali-ին պատվիրակելուց հետո լուծման ժամանակը նվազեց 470 ms-ից մինչև 50 MS. Մինչ այս գոտին նույնպես Cloudlfare-ի վրա էր։

Թունելի հետ զուգահեռ դեպի Ասիա-արևելք 1 բարձրացրեց մեկ այլ թունել Շենժենից անմիջապես դեպի մեզ-արևելք4. Այնտեղ նրանք ստեղծեցին ավելի շատ վստահված վիրտուալ մեքենաներ և սկսեցին փորձարկել երկու լուծումները՝ ուղղորդելով թեստային երթևեկությունը՝ օգտագործելով Cookies կամ DNS: Փորձարկման նստարանը սխեմատիկորեն նկարագրված է հետևյալ նկարում.

Թունելների ուշացումը հետևյալն էր.
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint բրաուզերի թեստերը գերազանց բարելավում են արձանագրել:

Համեմատեք թեստի արդյունքները երկու լուծումների համար.

որոշում
Uptime
Median
75 տոկոս
95 տոկոս

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Սա տվյալներ են լուծումից, որն օգտագործում է IPSEC թունելը միջոցով Ասիա-արևելք 1. us-east4-ի միջոցով արդյունքներն ավելի վատն էին, և ավելի շատ սխալներ կային, ուստի ես արդյունքները չեմ տա:

Հիմնվելով երկու թունելների այս փորձարկման արդյունքների վրա, որոնցից մեկը ավարտվում է Չինաստանին ամենամոտ տարածաշրջանում, իսկ մյուսը՝ վերջնական նպատակակետում, պարզ դարձավ, որ կարևոր է «դուրս գալ» չինական firewall-ի տակից այնքան արագ, որքան. հնարավոր է, այնուհետև օգտագործեք արագ ցանցեր (CDN մատակարարներ, ամպային մատակարարներ և այլն): Կարիք չկա փորձել անցնել firewall-ով և մեկ հարվածով հասնել ձեր նպատակակետին: Սա ամենաարագ ճանապարհը չէ։

Ընդհանուր առմամբ, արդյունքները վատ չեն, այնուամենայնիվ, semrush.com-ն ունի միջինը 8.8 վրկ, իսկ 75 տոկոսը 9.4 վրկ (նույն թեստի վրա):
Եվ մինչ առաջ անցնելը, կցանկանայի մի կարճ քնարական շեղում անել.

Լիրիկական շեղում

Օգտագործողի կայք մտնելուց հետո www.semrushchina.cn, որը լուծում է «արագ» չինական DNS սերվերների միջոցով, HTTP հարցումն անցնում է մեր արագ լուծման միջոցով: Պատասխանը վերադարձվում է նույն ճանապարհով, սակայն տիրույթը նշված է բոլոր JS սկրիպտներում, HTML էջերում և վեբ էջի այլ տարրերում։ semrush.com լրացուցիչ ռեսուրսների համար, որոնք պետք է բեռնվեն, երբ էջը ներկայացվում է: Այսինքն, հաճախորդը լուծում է «հիմնական» A-գրառումը www.semrushchina.cn և մտնում է արագ թունել, արագ ստանում պատասխան՝ HTML էջ, որը նշում է.

• ներբեռնեք այս կամ այն ​​js-ը sso.semrush.com-ից,
• Ստացեք CSS ֆայլերը cdn.semrush.com-ից,
• և նաև մի քանի նկար վերցրեք dab.semrush.com կայքից
• եւ այլն:

Բրաուզերը սկսում է գնալ դեպի «արտաքին» ինտերնետ այս ռեսուրսների համար՝ ամեն անգամ անցնելով firewall-ով, որը խլում է արձագանքման ժամանակը:

Բայց նախորդ թեստը ցույց է տալիս արդյունքները, երբ էջում չկան ռեսուրսներ semrush.com, միայն semrushchina.cn, և *.semrushchina.cn-ը լուծում է Շենժենում գտնվող վիրտուալ մեքենայի հասցեին, որպեսզի այնուհետև մտնի թունել:

Միայն այս կերպ, չինական firewall-ը արագ անցնելու համար ձեր լուծման միջոցով հնարավոր բոլոր տրաֆիկները առավելագույնի հասցնելով, կարող եք ձեռք բերել ընդունելի արագություններ և վեբ կայքի հասանելիության ցուցիչներ, ինչպես նաև լուծումների թեստերի ազնիվ արդյունքներ:
Մենք դա արեցինք առանց թիմի արտադրանքի մեկ ծածկագրի խմբագրման:

Ենթաֆիլտր

Լուծումը ծնվեց այս խնդրի ի հայտ գալուց գրեթե անմիջապես հետո: Մեզ անհրաժեշտ էր PoC- ն (Հայեցակարգի ապացույց), որ մեր firewall ներթափանցման լուծումներն իսկապես լավ են աշխատում: Դա անելու համար դուք պետք է հնարավորինս փաթեթավորեք կայքի ամբողջ տրաֆիկը այս լուծման մեջ: Եվ մենք դիմեցինք ենթաֆիլտր nginx-ում։

Ենթաֆիլտր nginx-ում բավականին պարզ մոդուլ է, որը թույլ է տալիս փոխել պատասխանի մարմնի մի տողը մյուս տողով: Այսպիսով, մենք փոխեցինք բոլոր երևույթները semrush.com մասին semrushchina.cn բոլոր պատասխաններում:

Եվ... այն չաշխատեց, քանի որ մենք ստացանք սեղմված բովանդակություն հետնամասերից, ուստի ենթաֆիլտրը չգտավ անհրաժեշտ տողը: Ես ստիպված էի ավելացնել մեկ այլ լոկալ սերվեր nginx-ում, որն ապասեղմեց պատասխանը և փոխանցեց այն հաջորդ տեղական սերվերին, որն արդեն զբաղված էր տողը փոխարինելով, սեղմելով և ուղարկելով այն շղթայի հաջորդ պրոքսի սերվերին:

Արդյունքում, որտեղից կստանա հաճախորդը .semrush.com, ստացել է .semrushchina.cn և հնազանդորեն քայլեց մեր որոշման միջով:

Այնուամենայնիվ, բավական չէ պարզապես տիրույթը մեկ ձևով փոխելը, քանի որ հետին պլանները դեռևս սպասում են semrush.com-ին հաճախորդի կողմից հետագա հարցումներում: Համապատասխանաբար, նույն սերվերում, որտեղ կատարվում է միակողմանի փոխարինում, օգտագործելով պարզ կանոնավոր արտահայտություն, մենք ստանում ենք ենթադոմեյն հարցումից, այնուհետև մենք անում ենք. proxy_pass փոփոխականով $հյուրընկալող, ցուցադրվել է $subdomain.semrush.com. Այն կարող է շփոթեցնող թվալ, բայց այն աշխատում է: Եվ դա լավ է աշխատում: Առանձին տիրույթների համար, որոնք պահանջում են տարբեր տրամաբանություն, պարզապես ստեղծեք ձեր սեփական սերվերի բլոկները և կատարեք առանձին կոնֆիգուրացիա: Ստորև ներկայացված են nginx կոնֆիգուրացիաները՝ այս սխեմայի պարզության և ցուցադրման համար:

Հետևյալ կազմաձևը մշակում է Չինաստանից ստացված բոլոր հարցումները .semrushchina.cn:

    listen 80;

    server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;

    sub_filter '.semrush.com' '.semrushchina.cn';
    sub_filter_last_modified on;
    sub_filter_once off;
    sub_filter_types *;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $subdomain.semrush.com;
        proxy_set_header X-Accept-Encoding $http_accept_encoding;
    }
}

Այս կազմաձևը վստահված է localhost դեպի 83 նավահանգիստ, և այնտեղ սպասում է հետևյալ կազմաձևը.

    listen 127.0.0.1:8083;

    server_name *.semrush.com;

    location / {
        resolver 8.8.8.8 ipv6=off;
        gunzip on;
        proxy_pass https://$host;
        proxy_set_header Accept-Encoding gzip;
    }
}

Կրկնում եմ, դրանք կտրված կոնֆիգուրացիաներ են:

Դրա նման. Դա կարող է բարդ թվալ, բայց դա բառերով է: Իրականում ամեն ինչ ավելի պարզ է, քան շոգեխաշած շաղգամը :)

Շեղումների ավարտը

Որոշ ժամանակ մենք ուրախ էինք, քանի որ IPSEC թունելների անկման մասին առասպելը չհաստատվեց: Բայց հետո թունելները սկսեցին ընկնել։ Օրական մի քանի անգամ մի քանի րոպե: Մի քիչ, բայց դա մեզ չէր սազում։ Քանի որ երկու թունելներն էլ ավարտվել էին Ալիի կողմից նույն երթուղղիչով, մենք որոշեցինք, որ գուցե սա տարածաշրջանային խնդիր է, և մենք պետք է բարձրացնենք պահեստային շրջանը:

Նրանք վերցրեցին այն: Թունելները սկսեցին խափանվել տարբեր ժամանակներում, բայց ձախողումը մեզ համար լավ աշխատեց nginx-ի վերին հոսանքի մակարդակում: Բայց հետո թունելները սկսեցին ընկնել մոտավորապես նույն ժամին 🙂 Եվ 502-ը և 504-ը նորից սկսեցին: Գործողության ժամանակը սկսեց վատանալ, ուստի մենք սկսեցինք աշխատել տարբերակի վրա: Alibaba CEN (Cloud Enterprise Network):

CEN

CEN - սա Alibaba Cloud-ում տարբեր շրջաններից երկու VPC-ների միացումն է, այսինքն՝ դուք կարող եք միմյանց հետ միացնել ամպի ներսում գտնվող ցանկացած տարածաշրջանի մասնավոր ցանցերը: Եվ ամենակարևորը՝ այս ալիքն ունի բավականին խիստ SLA. Այն շատ կայուն է ինչպես արագությամբ, այնպես էլ ժամանակի ընթացքում: Բայց դա երբեք այդքան պարզ չէ.

• դա շատ դժվար է ձեռք բերել, եթե դուք Չինաստանի քաղաքացիներ կամ իրավաբանական անձ չեք,
• Դուք պետք է վճարեք ալիքի յուրաքանչյուր մեգաբիթ հզորության համար:

Միանալու հնարավորություն ունենալը Չինաստան Չինաստան и արտասահմանյան, մենք ստեղծեցինք CEN երկու Ալի շրջանների միջև. cn-shenzhen и մեզ-արևելք-1 (մեզ ամենամոտ կետը-արևելք4): Ալիում մեզ-արևելք-1 բարձրացրեց ևս մեկ վիրտուալ մեքենա, որպեսզի լինի ևս մեկը գայլուկ.

Պարզվեց այսպես.

Բրաուզերի փորձարկման արդյունքները հետևյալն են.

որոշում
Uptime
Median
75 տոկոս
95 տոկոս

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Կատարումը մի փոքր ավելի լավ է, քան IPSEC-ը: Բայց IPSEC-ի միջոցով դուք կարող եք պոտենցիալ ներբեռնել 100 Մբիթ/վ արագությամբ, իսկ CEN-ի միջոցով՝ միայն 5 Մբիթ/վ և ավելի արագությամբ:

Հիբրիդ է թվում, չէ՞: Միավորել IPSEC արագությունը և CEN կայունությունը:

Սա այն է, ինչ մենք արեցինք՝ թույլ տալով երթևեկությունը ինչպես IPSEC-ով, այնպես էլ CEN-ով IPSEC թունելի խափանման դեպքում: Uptime-ը դարձել է շատ ավելի բարձր, բայց կայքի բեռնման արագությունը դեռ շատ ցանկալի է թողնում: Այնուհետև ես գծեցի բոլոր այն սխեմաները, որոնք մենք արդեն օգտագործել և փորձարկել էինք, և որոշեցի փորձել ավելացնել մի փոքր ավելի շատ GCP այս շղթայում, մասնավորապես. գլխարկ.

գլխարկ

գլխարկ - Ից Global Load Balancer (կամ Google Cloud Load Balancer): Դա մեզ համար կարևոր առավելություն ունի՝ CDN-ի համատեքստում ունի anycast IP, որը թույլ է տալիս երթևեկել դեպի հաճախորդին ամենամոտ տվյալների կենտրոն, որպեսզի երթևեկությունը արագ մտնի Google-ի արագ ցանց և ավելի քիչ անցնի «սովորական» ինտերնետով:

Առանց երկու անգամ մտածելու, մենք բարձրացրինք HTTP/HTTPS LB Մենք տեղադրեցինք մեր վիրտուալ մեքենաները ենթաֆիլտրով GCP-ում և որպես backend:

Կային մի քանի սխեմաներ.

• Օգտագործման համար Cloudflare China Network, բայց այս անգամ Origin-ը պետք է նշի գլոբալ IP GLB.
• Դադարեցնել հաճախորդներին ժամը cn-shenzhen, և այնտեղից վստահված երթևեկությունը ուղղակիորեն դեպի գլխարկ.
• Գնացեք ուղիղ Չինաստանից դեպի գլխարկ.
• Դադարեցնել հաճախորդներին ժամը cn-shenzhen, այնտեղից վստահված անձի Ասիա-արևելք 1 IPSEC-ի միջոցով (in մեզ-արևելք4 CEN-ի միջոցով), այնտեղից գնացեք GLB (հանգիստ, ստորև կլինի նկար և բացատրություն)

Մենք փորձարկեցինք այս բոլոր տարբերակները և ևս մի քանի հիբրիդային տարբերակներ.

• Cloudflare + GLB

Այս սխեման մեզ չէր համապատասխանում ժամանակի և DNS սխալների պատճառով: Բայց թեստն իրականացվել է նախքան սխալի շտկումը CF-ի կողմում, երևի թե հիմա ավելի լավ է (սակայն, սա չի բացառում HTTP-ի ժամանակի դադարեցումը):

• Ալի + ԳԼԲ

Այս սխեման մեզ չէր համապատասխանում նաև գործարկման ժամանակի առումով, քանի որ GLB-ն հաճախ դուրս էր գալիս հոսանքին հակառակ՝ ընդունելի ժամանակում միանալու անհնարինության պատճառով, քանի որ Չինաստանի ներսում գտնվող սերվերի համար GLB հասցեն մնում է դրսում, հետևաբար՝ հետևում: Չինական firewall. Կախարդանքը չեղավ.

• Միայն GLB

Նախորդին նման տարբերակ, միայն թե ինքը սերվերներ չի օգտագործել հենց Չինաստանում. երթևեկությունը ուղղակիորեն գնում է GLB (DNS գրառումները փոխվել են): Համապատասխանաբար, արդյունքները գոհացուցիչ չեն եղել, քանի որ սովորական ինտերնետ պրովայդերների ծառայություններից օգտվող սովորական չինացի հաճախորդները firewall-ն անցնելու հարցում շատ ավելի վատ իրավիճակ ունեն, քան Ali Cloud-ը։

• Շենժեն -> (CEN/IPSEC) -> վստահված անձ -> GLB

Այստեղ մենք որոշեցինք օգտագործել բոլոր լուծումներից լավագույնը.

• կայունություն և երաշխավորված SLA CEN-ից
• բարձր արագություն IPSEC-ից
• Google-ի «արագ» ցանցը և դրա ցանկացած կայանը:

Սխեման մոտավորապես այսպիսի տեսք ունի. օգտատերերի տրաֆիկը դադարեցվում է վիրտուալ մեքենայի վրա ch-shenzhen. Nginx վերին հոսքերը կազմաձևված են այնտեղ, որոնցից մի քանիսը մատնանշում են մասնավոր IP սերվերները, որոնք գտնվում են IPSEC թունելի մյուս ծայրում, իսկ որոշ վերին հոսքեր մատնանշում են CEN-ի մյուս կողմում գտնվող սերվերների մասնավոր հասցեները: IPSEC-ը կազմաձևված է տարածաշրջանում Ասիա-արևելք 1 GCP-ում (լուծման ստեղծման ժամանակ Չինաստանին ամենամոտ տարածաշրջանն էր: GCP-ն այժմ ունի նաև Հոնկոնգում առկայություն): CEN - դեպի տարածաշրջան մեզ-արևելք1 Ali Cloud-ում։

Այնուհետև երթևեկությունը երկու ծայրից ուղղվեց դեպի anycast IP GLB, այսինքն՝ Google-ի ներկայության մոտակա կետին և իր ցանցերով գնացել տարածաշրջան մեզ-արևելք4 GCP-ում, որտեղ կային փոխարինող վիրտուալ մեքենաներ (ենթաֆիլտրով nginx-ում):

Այս հիբրիդային լուծումը, ինչպես և մենք սպասում էինք, օգտվեց յուրաքանչյուր տեխնոլոգիայի առավելություններից: Ընդհանուր առմամբ, երթևեկությունն անցնում է արագ IPSEC-ով, բայց եթե խնդիրներ սկսվեն, մենք արագ և մի քանի րոպեով հեռացնում ենք այս սերվերները վերևից և ուղարկում երթևեկությունը միայն CEN-ով, մինչև թունելը կայունանա:

Վերը նշված ցանկից 4-րդ լուծումն իրականացնելով՝ մենք հասանք այն ամենին, ինչ ուզում էինք և ինչ բիզնեսը մեզանից պահանջում էր տվյալ պահին։

Բրաուզերի փորձարկման արդյունքները նոր լուծման համար՝ համեմատած նախորդների հետ.

որոշում
Uptime
Median
75 տոկոս
95 տոկոս

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN / IPsec + GLB
99.79
13s
16s
25s

CDN

Մեր ներդրած լուծումում ամեն ինչ լավ է, բայց չկա CDN, որը կարող է արագացնել երթևեկությունը տարածաշրջանային և նույնիսկ քաղաքային մակարդակում: Տեսականորեն սա պետք է արագացնի կայքը վերջնական օգտագործողների համար՝ օգտագործելով CDN մատակարարի արագ հաղորդակցման ուղիները: Եվ մենք անընդհատ մտածում էինք այդ մասին: Եվ հիմա եկել է նախագծի հաջորդ կրկնության ժամանակը. CDN մատակարարների որոնում և փորձարկում Չինաստանում:

Եվ այս մասին կպատմեմ հաջորդ՝ վերջին մասում :)

Source: www.habr.com