Hi!
Mae Nikita gyda chi eto, peiriannydd system o'r cwmni SEMrush. A chyda'r erthygl hon rwy'n parhau â'r stori am sut y gwnaethom feddwl am ateb i'w datrys Mur gwarchod Tsieineaidd ar gyfer ein gwasanaeth semrush.com.
В Dywedais:
- pa broblemau sy’n codi ar ôl i’r penderfyniad gael ei wneud “Mae angen i ni wneud i’n gwasanaeth weithio yn Tsieina”
- Pa broblemau sydd gan y Rhyngrwyd Tsieineaidd?
- pam mae angen trwydded ICP arnoch chi?
- sut a pham y penderfynon ni brofi ein gwelyau prawf gyda Catchpoint
- beth oedd canlyniad ein datrysiad cyntaf yn seiliedig ar Cloudflare China Network
- Sut y daethom o hyd i nam yn Cloudflare DNS
Y rhan hon yw'r mwyaf diddorol, yn fy marn i, oherwydd ei bod yn canolbwyntio ar weithrediadau technegol penodol o lwyfannu. A byddwn yn dechrau, neu yn hytrach yn parhau, gyda Alibaba Cloud.
Alibaba Cloud
Alibaba Cloud yn ddarparwr cwmwl eithaf mawr, sydd â'r holl wasanaethau sy'n caniatáu iddo alw'i hun yn ddarparwr cwmwl yn onest. Mae'n dda eu bod yn cael y cyfle i gofrestru ar gyfer defnyddwyr tramor, a bod y rhan fwyaf o'r wefan yn cael ei chyfieithu i'r Saesneg (ar gyfer Tsieina mae hyn yn foethusrwydd). Yn y cwmwl hwn, gallwch weithio gyda llawer o ranbarthau'r byd, tir mawr Tsieina, yn ogystal ag Oceanic Asia (Hong Kong, Taiwan, ac ati).
IPSEC
Dechreuon ni gyda daearyddiaeth. Gan fod ein gwefan brawf wedi'i lleoli ar Google Cloud, roedd angen i ni “gysylltu” Alibaba Cloud â GCP, felly fe wnaethom agor rhestr o leoliadau lle mae Google yn bresennol. Ar y foment honno nid oedd ganddynt eu canolfan ddata eu hunain yn Hong Kong eto.
Trodd y rhanbarth agosaf allan i fod asia-dwyrain1 (Taiwan). Trodd Ali allan i fod y rhanbarth agosaf o dir mawr Tsieina i Taiwan cn-henzhen (Shenzhen).
Gyda terraform disgrifio a chodi'r seilwaith cyfan yn GCP ac Ali. Aeth twnnel 100 Mbit yr eiliad rhwng y cymylau i fyny bron yn syth. Ar ochr Shenzhen a Taiwan, codwyd peiriannau rhithwir dirprwyol. Yn Shenzhen, mae traffig defnyddwyr yn cael ei derfynu, yn cael ei ddirprwyo trwy dwnnel i Taiwan, ac oddi yno mae'n mynd yn uniongyrchol i IP allanol ein gwasanaeth yn ni-dwyrain (Arfordir y Dwyrain UDA). Ping rhwng peiriannau rhithwir trwy dwnnel 24ms, sydd ddim mor ddrwg.
Ar yr un pryd, fe wnaethom osod ardal brawf ynddo Alibaba Cloud DNS. Ar ôl dirprwyo'r parth i NS Ali, gostyngodd yr amser datrys o 470 ms i ms 50. Cyn hyn, roedd y parth hefyd ar Cloudlfare.
Yn gyfochrog â'r twnnel i asia-dwyrain1 codi twnnel arall o Shenzhen yn uniongyrchol i us-dwyrain4. Yno fe wnaethon nhw greu mwy o beiriannau rhithwir dirprwyol a dechrau profi'r ddau ddatrysiad, gan lwybro traffig prawf gan ddefnyddio Cwcis neu DNS. Disgrifir y fainc brawf yn sgematig yn y ffigur canlynol:
Daeth yr hwyrni ar gyfer twneli fel a ganlyn:
Ali cn-Shenzhen <—> GCP asia-ddwyrain1 — 24ms
Ali cn-Shenzhen <—> GCP us-east4 — 200ms
Adroddodd profion porwr Catchpoint welliant rhagorol.
Cymharwch ganlyniadau profion ar gyfer dau ddatrysiad:
penderfyniad
Uptime
Canolrif
75 Canradd
95 Canradd
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
Mae hwn yn ddata o ddatrysiad sy'n defnyddio twnnel IPSEC trwy asia-dwyrain1. Trwom ni-ddwyrain4 roedd y canlyniadau'n waeth, ac roedd mwy o wallau, felly ni fyddaf yn rhoi'r canlyniadau.
Yn seiliedig ar ganlyniadau'r prawf hwn o ddau dwnnel, y mae un ohonynt yn cael ei derfynu yn y rhanbarth agosaf at Tsieina, a'r llall yn y gyrchfan derfynol, daeth yn amlwg ei bod yn bwysig “dod i'r amlwg” o dan y wal dân Tsieineaidd cyn gynted ag y bo modd. bosibl, ac yna defnyddio rhwydweithiau cyflym (darparwyr CDN , darparwyr cwmwl, ac ati). Nid oes angen ceisio mynd trwy'r wal dân a chyrraedd pen eich taith mewn un swoop disgyn. Nid dyma'r ffordd gyflymaf.
Yn gyffredinol, nid yw'r canlyniadau'n ddrwg, fodd bynnag, mae gan semrush.com ganolrif o 8.8s, a 75 Canradd 9.4s (ar yr un prawf).
A chyn symud ymlaen, hoffwn wneud digression telynegol byr.
Treuliad telynegol
Ar ôl i'r defnyddiwr ddod i mewn i'r wefan www.semrushchina.cn, sy'n datrys trwy weinyddion DNS Tsieineaidd “cyflym”, mae'r cais HTTP yn mynd trwy ein datrysiad cyflym. Dychwelir yr ymateb ar hyd yr un llwybr, ond nodir y parth ym mhob sgript JS, tudalen HTML ac elfennau eraill o'r dudalen we semrush.com am adnoddau ychwanegol y mae'n rhaid eu llwytho pan fydd y dudalen wedi'i rendro. Hynny yw, mae'r cleient yn datrys y “prif” record A www.semrushchina.cn ac yn mynd i mewn i'r twnnel cyflym, yn derbyn ymateb yn gyflym - tudalen HTML sy'n nodi:
- lawrlwythwch js o'r fath o sso.semrush.com,
- Cael y ffeiliau CSS o cdn.semrush.com,
- a hefyd tynnu rhai lluniau o dab.semrush.com
- ac yn y blaen.
Mae'r porwr yn dechrau mynd i'r Rhyngrwyd “allanol” ar gyfer yr adnoddau hyn, bob tro yn mynd trwy wal dân sy'n bwyta amser ymateb.
Ond mae'r prawf blaenorol yn dangos y canlyniadau pan nad oes adnoddau ar y dudalen semrush.com, dim ond semrushchina.cn, a *.semrushchina.cn yn penderfynu cyfeiriad y peiriant rhithwir yn Shenzhen er mwyn mynd i mewn i'r twnnel wedyn.
Dim ond yn y modd hwn, trwy wthio'r holl draffig posibl i'r eithaf trwy eich datrysiad ar gyfer pasio'r wal dân Tsieineaidd yn gyflym, a allwch chi gael cyflymder derbyniol a dangosyddion argaeledd gwefan, yn ogystal â chanlyniadau gonest profion datrysiad.
Gwnaethom hyn heb olygu un cod ar ochr cynnyrch y tîm.
Is-hidlydd
Ganwyd yr ateb bron yn syth ar ôl i'r broblem hon ddod i'r wyneb. Roedd angen PoC (Prawf o Gysyniad) bod ein datrysiadau treiddiad wal dân yn gweithio'n dda iawn. I wneud hyn, mae angen i chi lapio holl draffig y safle yn yr ateb hwn cymaint â phosibl. A gwnaethom gais yn nginx.
Is-hidlydd yn fodiwl eithaf syml yn nginx sy'n eich galluogi i newid un llinell yn y corff ymateb i linell arall. Felly rydym yn newid pob digwyddiad semrush.com ar semrushchina.cn ym mhob ateb.
Ac... ni weithiodd oherwydd cawsom gynnwys cywasgedig o'r backends, felly ni ddaeth yr is-hidlydd o hyd i'r llinell ofynnol. Roedd yn rhaid i mi ychwanegu gweinydd lleol arall i nginx, a oedd yn dad-gywasgu'r ymateb a'i drosglwyddo i'r gweinydd lleol nesaf, a oedd eisoes yn brysur yn ailosod y llinyn, ei gywasgu, a'i anfon at y gweinydd dirprwy nesaf yn y gadwyn.
O ganlyniad, ble byddai'r cleient yn derbyn .semrush.com, derbyniodd .semrushchina.cn a cherddodd yn ufudd trwy ein penderfyniad.
Fodd bynnag, nid yw'n ddigon newid y parth un ffordd yn unig, oherwydd mae'r backends yn dal i ddisgwyl semrush.com mewn ceisiadau dilynol gan y cleient. Yn unol â hynny, ar yr un gweinydd lle mae'r amnewid un ffordd yn cael ei wneud, gan ddefnyddio mynegiant rheolaidd syml rydyn ni'n cael yr is-barth o'r cais, ac yna rydyn ni'n ei wneud dirprwy_pass gyda newidyn $ gwesteiwr, arddangos yn $subdomain.semrush.com. Gall ymddangos yn ddryslyd, ond mae'n gweithio. Ac mae'n gweithio'n dda. Ar gyfer parthau unigol sydd angen rhesymeg wahanol, crëwch eich blociau gweinydd eich hun a gwnewch gyfluniad ar wahân. Isod mae cyfluniadau nginx byr er mwyn eglurder ac arddangosiad o'r cynllun hwn.
Mae'r config canlynol yn prosesu pob cais o Tsieina i .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;
}
}Mae'r cyfluniad hwn yn dirprwyon i localhost i borth 83, ac mae'r ffurfwedd ganlynol yn aros yno:
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;
}
}Rwy'n ailadrodd, mae'r rhain yn configs tocio.
Fel yna. Efallai ei fod yn edrych yn gymhleth, ond mae mewn geiriau. Yn wir, mae popeth yn symlach na maip wedi'u stemio :)
Diwedd gwyriad
Am gyfnod roeddem yn hapus oherwydd ni chadarnhawyd y myth am dwneli IPSEC yn cwympo. Ond yna dechreuodd y twneli ddisgyn. Sawl gwaith y dydd am ychydig funudau. Ychydig, ond nid oedd hynny'n addas i ni. Gan fod y ddau dwnnel wedi'u terfynu ar ochr Ali ar yr un llwybrydd, fe wnaethom benderfynu efallai mai problem ranbarthol oedd hon a bod angen i ni godi'r rhanbarth wrth gefn.
Fe wnaethon nhw ei godi. Dechreuodd y twneli fethu ar wahanol adegau, ond gweithiodd y methiant yn iawn i ni ar y lefel i fyny'r afon yn nginx. Ond yna dechreuodd y twneli ddisgyn tua'r un amser 🙂 A dechreuodd 502 a 504 eto. Dechreuodd Uptime ddirywio, felly dechreuon ni weithio ar yr opsiwn gyda Alibaba CEN (Cloud Enterprise Network).
CEN
CEN - dyma gysylltedd dau VPC o wahanol ranbarthau o fewn Alibaba Cloud, hynny yw, gallwch chi gysylltu rhwydweithiau preifat unrhyw ranbarthau o fewn y cwmwl â'i gilydd. Ac yn bwysicaf oll: mae gan y sianel hon weddol llym CLG. Mae'n sefydlog iawn o ran cyflymder a uptime. Ond nid yw byth mor syml â hynny:
- mae'n anodd IAWN ei gael os nad ydych chi'n ddinasyddion Tsieineaidd neu'n endid cyfreithiol,
- Mae angen i chi dalu am bob megabit o led band sianel.
Cael y cyfle i gysylltu Tir mawr Tsieina и tramor, fe wnaethon ni greu CEN rhwng dau ranbarth Ali: cn-henzhen и us-dwyrain- 1 (pwynt agosaf atom-east4). Yn Ali us-dwyrain- 1 codi peiriant rhithwir arall fel bod un arall hop.
Trodd allan fel hyn:
Mae canlyniadau profion y porwr isod:
penderfyniad
Uptime
Canolrif
75 Canradd
95 Canradd
Cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
CEN
99.75
16s
21s
27s
Mae'r perfformiad ychydig yn well nag IPSEC. Ond trwy IPSEC gallwch o bosibl lawrlwytho ar gyflymder o 100 Mbit yr eiliad, a thrwy CEN yn unig ar gyflymder o 5 Mbit yr eiliad a mwy.
Swnio fel hybrid, iawn? Cyfuno cyflymder IPSEC a sefydlogrwydd CEN.
Dyma a wnaethom, gan ganiatáu traffig trwy IPSEC a CEN pe bai twnnel IPSEC yn methu. Mae Uptime wedi dod yn llawer uwch, ond mae cyflymder llwytho'r safle yn dal i adael llawer i'w ddymuno. Yna lluniais yr holl gylchedau yr oeddem eisoes wedi'u defnyddio a'u profi, a phenderfynais geisio ychwanegu ychydig mwy o GCP i'r gylched hon, sef cap.
cap
cap - A yw (neu Google Cloud Load Balancer). Mae ganddo fantais bwysig i ni: yng nghyd-destun CDN mae ganddo anycast IP, sy'n eich galluogi i gyfeirio traffig i'r ganolfan ddata sydd agosaf at y cleient, fel bod traffig yn mynd i mewn i rwydwaith cyflym Google yn gyflym a bod llai yn mynd trwy'r Rhyngrwyd “rheolaidd”.
Heb feddwl ddwywaith, codasom HTTP/HTTPS LB Fe wnaethom osod ein peiriannau rhithwir gydag is-hidlydd yn GCP ac fel backend.
Roedd sawl cynllun:
- Defnyddio Rhwydwaith Cloudflare Tsieina, ond y tro hwn dylai Origin nodi byd-eang IP GLB.
- Terfynu cleientiaid yn cn-henzhen, ac oddi yno dirprwy y traffig yn uniongyrchol i cap.
- Ewch yn syth o Tsieina i cap.
- Terfynu cleientiaid yn cn-henzhen, oddi yno dirprwy i asia-dwyrain1 trwy IPSEC (yn us-dwyrain4 trwy CEN), oddi yno ewch i GLB (yn dawel bach, bydd llun ac esboniad isod)
Fe wnaethon ni brofi'r holl opsiynau hyn a sawl un hybrid arall:
- Cloudflare + GLB
Nid oedd y cynllun hwn yn addas i ni oherwydd gwallau uptime a DNS. Ond cynhaliwyd y prawf cyn i'r nam gael ei drwsio ar yr ochr CF, efallai ei fod yn well nawr (fodd bynnag, nid yw hyn yn eithrio cyfnodau HTTP).
- Ali + GLB
Nid oedd y cynllun hwn hefyd yn addas i ni o ran uptime, gan fod GLB yn aml yn disgyn allan o'r lan yr afon oherwydd amhosibl cysylltu o fewn amser derbyniol neu amser terfyn, oherwydd ar gyfer gweinydd y tu mewn i Tsieina, mae'r cyfeiriad GLB yn parhau i fod y tu allan, ac felly y tu ôl i'r wal dân Tsieineaidd. Ni ddigwyddodd yr hud.
- GLB yn unig
Opsiwn tebyg i'r un blaenorol, dim ond nad oedd yn defnyddio gweinyddwyr yn Tsieina ei hun: aeth y traffig yn uniongyrchol i GLB (newidiwyd y cofnodion DNS). Yn unol â hynny, nid oedd y canlyniadau'n foddhaol, gan fod gan gleientiaid Tsieineaidd cyffredin sy'n defnyddio gwasanaethau darparwyr Rhyngrwyd cyffredin sefyllfa lawer gwaeth wrth basio'r wal dân nag Ali Cloud.
- Shenzhen -> (CEN/IPSEC) -> Dirprwy -> GLB
Yma fe benderfynon ni ddefnyddio'r atebion gorau oll:
- sefydlogrwydd a CLG gwarantedig gan CEN
- cyflymder uchel o IPSEC
- Rhwydwaith “cyflym” Google a'i anycast.
Mae'r cynllun yn edrych rhywbeth fel hyn: mae traffig defnyddwyr yn cael ei derfynu ar beiriant rhithwir yn ch-henzhen. Mae Nginx i fyny'r afon wedi'i ffurfweddu yno, ac mae rhai ohonynt yn cyfeirio at weinyddion IP preifat sydd wedi'u lleoli ar ben arall twnnel IPSEC, ac mae rhai i fyny'r afon yn pwyntio at gyfeiriadau preifat gweinyddwyr yr ochr arall i'r CEN. IPSEC wedi'i ffurfweddu i'r rhanbarth asia-dwyrain1 yn GCP (oedd y rhanbarth agosaf at Tsieina ar yr adeg y crëwyd yr ateb. Mae gan GCP bresenoldeb hefyd yn Hong Kong bellach). CEN - i'r rhanbarth us-dwyrain1 yn Ali Cloud.
Yna cyfeiriwyd traffig o'r ddau ben i anycast IP GLB, hynny yw, i'r pwynt agosaf o bresenoldeb Google, ac aeth trwy ei rwydweithiau i'r rhanbarth us-dwyrain4 yn GCP, lle roedd peiriannau rhithwir newydd (gydag is-hidlydd yn nginx).
Manteisiodd yr ateb hybrid hwn, yn ôl ein disgwyl, ar fanteision pob technoleg. Yn gyffredinol, mae traffig yn mynd trwy IPSEC cyflym, ond os bydd problemau'n dechrau, rydym yn gyflym ac am ychydig funudau yn cicio'r gweinyddwyr hyn allan o'r lan yr afon ac yn anfon traffig yn unig trwy CEN nes bod y twnnel yn sefydlogi.
Trwy weithredu'r 4ydd datrysiad o'r rhestr uchod, fe wnaethom gyflawni'r hyn yr oeddem ei eisiau a'r hyn yr oedd y busnes yn ei ddisgwyl gennym ar yr adeg honno.
Canlyniadau profion porwr ar gyfer y datrysiad newydd o'i gymharu â rhai blaenorol:
penderfyniad
Uptime
Canolrif
75 Canradd
95 Canradd
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
Mae popeth yn dda yn yr ateb a roddwyd ar waith gennym, ond nid oes unrhyw CDN a allai gyflymu traffig ar lefel ranbarthol a hyd yn oed dinas. Mewn egwyddor, dylai hyn gyflymu'r wefan ar gyfer defnyddwyr terfynol trwy ddefnyddio sianeli cyfathrebu cyflym y darparwr CDN. Ac roeddem yn meddwl amdano drwy'r amser. Ac yn awr, mae'r amser wedi dod ar gyfer iteriad nesaf y prosiect: chwilio a phrofi darparwyr CDN yn Tsieina.
A dywedaf wrthych am hyn yn y rhan olaf, nesaf :)
Ffynhonnell: hab.com