Helló!
Minden jó történetnek vége szakad. A történetünk arról, hogyan találtunk ki egy gyors megoldást a Kínai Tűzfal áthidalására, nem kivétel. Így hát sietek megosztani veletek az utolsó, befejező részt erről a témáról.
A korábbi részben bemutattuk a számos tesztkörnyezetet, amelyeket kitaláltunk, és milyen eredményeket hoztak. Ott tartottunk, hogy nem ártana hozzáadni CDN-t! a sémánk gördülékenysége érdekében.
Elmondom nektek, hogyan teszteltük az Alibaba Cloud CDN-t, a Tencent Cloud CDN-t és az Akamai-t, és végül melyik mellett döntöttünk. És természetesen összegzünk.
Alibaba Cloud CDN
Az Alibaba Cloudon hosztolunk, IPSEC-et és CEN-t használunk tőlük. Logikus lenne először a megoldásaikat kipróbálni.
Az Alibaba Cloudnak két típusa van a termékeink közül, amelyek megfelelhetnek nekünk: -szolgáltató). Ők figyelik a és DCDN. Az első lehetőség egy klasszikus CDN adott domain (almadomain) számára. A második lehetőség a következőképpen kódolható: Dynamic Route for CDN (én dinamikus CDN-nek hívom), ezt aktiválni lehet Full-site módban (wildcard domainekhez), statikus tartalmat is gyorsít, és a dinamikus tartalmat is gyorsítja, ami azt jelenti, hogy az oldal dinamikája is a szolgáltató gyors hálózatai révén fog betöltődni. Ez számunkra fontos, mert főként dinamikus honlapunk van, sok almadoménnyel, és egyszerűbb beállítani a CDN-t egyetlen alkalommal a „csillag” — *.semrushchina.cn számára.
Már láttuk ezt a terméket a korábbi kínai projektünk korai szakaszaiban, de akkor még nem működött, és a fejlesztők ígérték, hogy hamarosan elérhető lesz minden ügyfél számára. És ez megtörtént.
A DCDN-ben lehet:
- SSL terminálást beállítani a saját tanúsítványunkkal,
- dinamikus tartalom gyorsítását aktiválni,
- rugalmasan beállítani a statikus fájlok cache-elését,
- cache purge-ot végezni,
- websocketeket átjárni,
- tömörítést aktiválni, sőt akár HTML Beautifier-t is.
Összességében minden úgy működik, mint a nagyobb CDN-szolgáltatóknál.
Miután megadtuk az Origin-t (azt a helyet, ahová a CDN edge szerverek fognak menni), létre kell hozni egy CNAME-t a csillagra, amely hivatkozik a all.semrushchina.cn.w.kunluncan.com (ez a CNAME az Alibaba Cloud konzoljából származik), és a CDN működésbe lép.
A tesztek alapján ez a CDN nagyon jól segített nekünk. Az alábbiakban találhatóak a statisztikák.
Megoldás
Uptime
Medián
75. percentilis
95. percentilis
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
Ali CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s
Ezek nagyon jó eredmények, főleg, ha azokat összehasonlítjuk a kezdeti számokkal. De tudtuk, hogy az amerikai verziónk böngészőtesztje a www.semrush.com weboldalon átlagosan 8,3 másodperc alatt fut le az Egyesült Államokból (nagyon közelítő érték). Van hová fejlődni. Főleg, hogy érdekes CDN-szolgáltatók is voltak, akiket érdemes volt tesztelni.
Így fokozatosan áttérünk a kínai piacon egy másik óriásra — Tencent.
Tencent Cloud
A Tencent Cloud még csak fejlesztés alatt áll — ezt a termékek kis számával is lehet látni. Használata során nemcsak a CDN-jüket akartuk letesztelni, hanem az általános hálózati infrastruktúrájukat is:
- van-e olyanuk, mint a CEN?
- hogyan működik az IPSEC náluk? Gyorsan működik? Milyen az uptime?
- van-e Anycast-juk?
Ezeket a kérdéseket külön-külön fogjuk átvenni.
CEN analógia
A Tencentnek van egy terméke Cloud Connect Network (), amely lehetővé teszi a különböző régiókból származó VPC-k összekapcsolását, beleértve a Kínán belüli és kívüli régiókat is. A termék jelenleg belső bétatesztelés alatt áll, és jegyet kell kérni a kapcsolódáshoz. A támogatástól megtudtuk, hogy a globális fiókoknak (kínai állampolgárok és jogi személyek nem számítanak) nem engedélyezett részt venni a bétatesztelésben és a Kínán belüli és a kívüli régiók összekapcsolásában. 1-0 az Ali Cloud javára.
IPSEC
A Tencent legdélebbi régiója — Guangzhou. Alapítottunk egy alagutat, és összekapcsoltuk Hongkong régiójával a GCP-ben (akkor már elérhető volt ez a régió). Ugyanakkor egy második alagutat is emeltünk az Ali Cloud szhenzmeni régiójából Hongkongba. Kiderült, hogy a Tencent hálózatán keresztül a késleltetés Hongkongba egyáltalán jobb (10 ms), mint Shenzhenből Hongkongba az Ali-nál (120 ms — mi?). De ez semmilyen módon nem gyorsította fel a weboldal működését, amely a Tencent-en és ezen az alagúton keresztül működött, ami önmagában meglepő tény volt, és ismét bebizonyította a következőt: a késleltetés — Kínában nem mérvadó szempont a kínai tűzfalon való átkelés megoldásának fejlesztése során.
Anycast Internet Acceleration
Egy másik termék, amely lehetővé teszi a működést anycast IP-n keresztül — . De ez is elérhetetlen a globális fiókok számára, így erről nem tudok beszélni, de hasznos lehet tudni, hogy létezik ilyen termék.
A CDN tesztelése viszont meglehetősen érdekes eredményeket mutatott. A Tencent CDN-jét nem lehet teljes weboldalra aktiválni, csak egyedi domainekre. Létrehoztunk domaineket, és forgalmat irányítottunk rájuk:
Kiderült, hogy ez a CDN rendelkezik egy ilyen funkcióval: Határokon Átnyúló Forgalom Optimalizálása. Ez a funkció csökkentené a költségeket a forgalom áthaladása során a kínai tűzfalon. Mint Eredet a google-i GLB (GLB anycast) IP címe lett megadva. Ezzel szerettük volna egyszerűsíteni a projekt architektúráját.
Az eredmények nagyon jók voltak — az Ali Cloud CDN szintjén, és helyenként még annál is jobbak. Ez meglepő, mivel sikeres tesztek esetén lemondhatnánk a jelentős infrastruktúra, alagutak, CEN, virtuális gépek stb. egy részéről.
Sajnos nem örültünk sokáig, mivel egy probléma derült ki: a Catchpoint tesztek megbuktak a China Mobile internet-szolgáltatónál. Bármilyen helyszínről időtúllépést kaptunk a Tencent CDN-en. A műszaki támogatással folytatott levelezés semmire sem vezetett. Körülbelül egy napig próbáltuk megoldani ezt a problémát, de végül nem jártunk sikerrel.
Abban a pillanatban Kínában voltam, de nem tudtam nyilvános Wi-Fi-t találni ennek a szolgáltatónak a hálózatán, hogy személyesen ellenőrizhessem a problémát. Egyébként minden gyorsnak és jónak tűnt.
Azonban mivel a China Mobile a három legnagyobb szolgáltató közé tartozik, kénytelenek voltunk visszairányítani a forgalmat az Ali CDN-re.
Összességében ez egy elég érdekes megoldás volt, ami hosszabb tesztelést és ennek a problémának a megoldását igényli.
Akamai
Az utolsó CDN-szolgáltató, akit teszteltünk—ez Akamai. Ez egy hatalmas szolgáltató, amely saját hálózattal rendelkezik Kínában. Természetesen nem hagyhattuk figyelmen kívül.
Kezdetektől fogva megállapodtunk az Akamaival egy tesztidőszakról, hogy át tudjuk állítani a domént, és megnézhessem, hogyan működik a hálózatukon. A tesztelés eredményét „Ami tetszett” és „Ami nem tetszett” formájában fogom leírni, valamint bemutatom a teszteredményeket.
Ami tetszett:
- Az Akamai csapata nagyon segítőkész volt minden kérdésben, és végigkísértek minket a tesztelés minden szakaszában. Folyamatosan próbálták javítani a dolgokat a saját oldalukon. Jópár jó műszaki tanácsot adtak.
- Az Akamai körülbelül 10-15%-kal lassabban működik, mint a megoldásunk az Ali Cloud CDN-en. Meglepetés, hogy az Akamai esetében az Eredet IP címe GLB volt, tehát a forgalom nem a mi megoldásunkon keresztül haladt (potenciálisan lemondhatunk az infrastruktúra egy részéről). De a teszteredmények mégis azt mutatták, hogy ez a megoldás kevésbé hatékony, mint a jelenlegi megoldásunk (a összehasonlító eredmények alább találhatók).
- Az Eredet GLB-ként és az Eredet Kínában is tesztelve lett. Mindkét változat körülbelül egyforma.
- Van Biztos Útvonal (automatikus útvonaloptimalizálás). Tesztobjektumot hozhatunk létre az Origin-nál, és az Akamai Edge szerverek megpróbálják azt lekérni (normál GET módszerrel). Ezeknél a kéréseknél mérjük a sebességet és egyéb metrikákat, amelyek alapján az Akamai hálózata optimalizálja az útvonalakat, hogy a forgalom gyorsabban áramoljon a weboldalunkhoz, és látható legyen, hogy ennek a funkciónak a bekapcsolása valóban jelentős hatással volt a weboldal sebességére.
- A konfiguráció verziókezelése a webes felületen remek. Készíthetünk összehasonlítást a verziók között, megnézhetjük a diffet. Megtekinthetjük a korábbi verziókat.
- Új verziót először csak a Staging Akamai hálózatra telepíthetünk - ez egy ugyanolyan hálózat, mint a production, csupán ez az út nem érinti a valós felhasználókat. Ehhez DNS-rekordok hamisítását kell végezni a helyi gépen.
- Nagyon gyors betöltési sebesség az ő nagy statikus fájljaik hálózatán, és láthatóan bármilyen más fájl esetén is. Egy "hideg" cache-ből származó fájl többszörösen gyorsabban elérhető, mint ugyanaz a fájl az Ali CDN "hideg" cache-ből. A "forró" cache-ből viszont a sebesség már nagyjából azonos.
Ali CDN teszt:
root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
% Teljes % Fogadott % Xferd Átlagos Sebesség Idő Idő Idő Jelenlegi
Letöltés Feltöltés Összes Elköltött Hátra Sebesség
100 5757k 0 5757k 0 0 513k 0 --:--:-- 0:00:11 --:--:-- 526k
time_namelookup: 0.004286
time_connect: 0.030107
time_appconnect: 0.117525
time_pretransfer: 0.117606
time_redirect: 0.000000
time_starttransfer: 0.840348
----------
time_total: 11.208119
----------
letöltési_ábra: 5895467 Bytes
letöltés_sebesség: 525999.000B/sAkamai teszt:
root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
% Teljes % Fogadott % Xferd Átlagos Sebesség Idő Idő Idő Jelenlegi
Letöltés Feltöltés Összes Elköltött Hátra Sebesség
100 5757k 0 5757k 0 0 1824k 0 --:--:-- 0:00:03 --:--:-- 1825k
time_namelookup: 0.509005
time_connect: 0.528261
time_appconnect: 0.577235
time_pretransfer: 0.577324
time_redirect: 0.000000
time_starttransfer: 1.327013
----------
time_total: 3.154850
----------
letöltési_ábra: 5895467 Bytes
letöltés_sebesség: 1868699.000B/sMegjegyeztük, hogy a fenti példa helyzete különböző tényezőktől függ. E pont írásakor újra elvégeztem a tesztet. Az eredmények mindkét platform számára nagyjából azonosak voltak. Ez arra utal, hogy az internet Kínában, még a nagy operátorok és felhőszolgáltatók esetében is, időnként eltérően viselkedik.
A korábbi ponthoz hozzáfűzök egy nagy előnyt az Akamai-nál: ha az Ali esetében láthatók ilyen kiugró teljesítmények és nagyon alacsony (ez vonatkozik az Ali CDN-re, Ali CEN-re és az Ali IPSEC-re), akkor az Akamai-nál minden alkalommal, bármennyire is tesztelem a hálózatukat, minden stabilan működik.
Az Akamai valóban nagy lefedettséggel rendelkezik Kína területén, és sok szolgáltatón keresztül dolgozik.
Ami nem tetszett:
- Nem tetszik a webszerver felülete és a működési séma - teljesen nullának érződik. De elvileg hozzászokik az ember (valószínűleg).
- A tesztelési eredmények rosszabbak, mint a mi platformunké.
- A tesztek során több hiba fordult elő, mint a mi platformunknál (a rendelkezésre állás alacsonyabb).
- Nincsenek saját DNS-szervereik Kínában. Ebből adódóan sok hiba lép fel a tesztek során a DNS feloldás időtúllépése miatt.
- Nem biztosítanak saját IP tartományokat -> nincs lehetőség a helyes megadásra set_real_ip_from a szervereinken.
Metrikák (~3626 futás; minden metrika, kivéve a rendelkezésre állást, ms-ben; statisztika egy időszakon belül):
CDN Szolgáltató
Medián
75%
95%
Válasz
Weboldal Válasz
Uptime
DNS
Kapcsolódás
Várakozás
Betöltés
SSL
Ali CDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200
Akamai
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50
Eloszlás Percentilis alapján (ms-ben):
Percentilis
Akamai
Ali CDN
10
7,092
6,942
20
7,775
7,583
30
8,446
8,092
40
9,146
8,596
50
9,783
9,195
60
10,497
9,770
70
11,371
10,383
80
12,670
11,255
90
15,882
13,165
100
91,592
91,596
Az eredmény az: az Akamai megoldás életképes, de nem nyújt ugyanazt a stabilitást és sebességet, mint a saját megoldásunk az Ali CDN-nel.
Kis megjegyzések
Néhány részlet nem került bele a történetbe, de szeretném ezt is megemlíteni.
Peking + Tokió és Hongkong
Ahogy korábban már említettem, teszteltük az IPSEC alagutat Hongkongba (HK). De teszteltük a CEN-t is HK-ba. Ez egy kicsit olcsóbb, és érdekelt, hogyan fog működni a városok között, amelyek távolsága ~100 km. Érdekesnek tűnt, hogy a késleltetés ezen városok között 100 ms-mal magasabb, mint az eredeti megoldásunknál (Tajvan irányába). A sebesség és a stabilitás szintén jobb volt Tajvan irányában. Végül a HK-t hagytuk tartalékként IPSEC régióként.
Ezen kívül próbáltunk egy ilyen telepítést indítani:
- a kliens terminálása Pekingben,
- IPSEC és CEN Tokióba,
- az Ali CDN-t jelöltük meg egy origin szerverként Pekingben.
Ez a séma nem volt annyira stabil, bár sebességben összességében nem maradt el a mi megoldásunktól. Ami az alagutat illeti, láttam időszakos leállásokat még a CEN esetében is, amelynek stabilnak kellett volna lennie. Ezért visszatértünk a régi sémához, és lebontottuk ezt a staginget.
Az alábbiakban statisztikát adunk a késleltetésről a különböző régiók és különböző csatornák között. Lehet, hogy valakit érdekel.
IPsec
Ali cn-beijing <—> GCP asia-northeast1 — 193ms
Ali cn-shenzhen <—> GCP asia-east2 — 91ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms
CEN
Ali cn-beijing <—> Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms
Általános információk az internetről Kínában
Mint az internetes problémák kiegészítése, amelyek a cikk elején le vannak írva.
- Az internet Kínában viszonylag gyorsan működik belül.
- A következtetés a különböző helyszíneken elérhető nyilvános Wi-Fi hálózatok tesztelésének alapján készült, ahol ezeket a hálózatokat sok ember használja.
- A letöltési és feltöltési sebesség Kínán belüli szerverekre körülbelül 20 Mbit/s és 5-10 Mbit/s volt.
- A Kínán kívüli szerverekhez való sebesség viszont elenyésző, kevesebb mint 1 Mbit/s.
- Az internet Kínában nem túl stabil.
- Néha a weboldalak gyorsan nyithatók meg, néha lassan (ugyanabban az időpontban különböző napokon), feltéve, hogy a konfiguráció nem változik. Ezt láttuk például a semrushchina.cn esetében. Ezt ráfoghatjuk az Ali CDN-re, amely szintén változósan működik az időjárás és egyéb tényezők függvényében.
- A mobilinternet szinte mindenhol 4G vagy 4G+. Működik a metróban, liftekben — szóval, mindenhol.
- Ami azt illeti, hogy a kínai felhasználók csak .cn végű domainekben bíznak — ez egy mítosz. Közvetlenül a felhasználóktól tudtuk meg.
- Látható, ahogy átirányít a www.baidu.com-ra (a szárazföldi Kínában is).
- Sok forrás valóban blokkolva van. Egyszerű: google.com, Facebook, Twitter. De sok Google szolgáltatás működik (persze nem minden Wi-Fi-n és VPN-t nem használnak (a router oldalán is, ez biztos).
- Sok „technikai” domain is működik a megblokkolt vállalatok számára. Ez azt jelenti, hogy nem mindig kell meggondolatlanul eltávolítani az összes Google-t és egyéb látszólag blokkolt forrást. Érdemes keresni egy tiltott domain listát.
- Összesen három fő internetszolgáltatójuk van: China Unicom, China Telecom, China Mobile. Vannak kisebbek is, de piacuk részesedése elenyésző.
Bónusz: az összesített megoldási séma
Result
Egy év telt el a projekt indítása óta. Az elején azzal kezdtük, hogy a weboldalunk egyáltalán nem működött normálisan Kínából, a GET curl akár 5,5 másodpercet is igénybe vett.
Ezután, az első megoldási mutatók (Cloudflare) alapján:
Megoldás
Uptime
Medián
75. percentilis
95. percentilis
Cloudflare
86.6
18s
30s
60s
Végül eljutottunk ezekhez az eredményekhez (az utolsó hónap statisztikája):
Megoldás
Uptime
Medián
75. percentilis
95. percentilis
Ali CDN + CEN/IPsec + GLB
99.86
8,8s
9,5s
13,7s
Mint látható, a 100%-os üzemidőt eddig nem sikerült elérni, de majd kitalálunk valamit, és később beszámolunk az eredményekről egy új cikkben :)
Aki, aki a végéig elolvasta mindhárom részt — tisztelet. Remélem, ugyanúgy érdekelt titeket, mint engem, amikor ezt csináltam.
P.S. Az előző részek
Forrás: habr.com
