Бид Хятадын агуу галт ханыг хэрхэн эвдсэн бэ (2-р хэсэг)

Сайн уу!

Компанийн системийн инженер Никита тантай дахин хамт байна SEMrush. Мөн энэ нийтлэлээр бид хэрхэн тойрон гарах шийдлийг олж авсан тухай түүхийг үргэлжлүүлнэ Хятадын галт хана Манай үйлчилгээний 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 (Шэньжэнь).

Тусламжийн тусламжтайгаар terraform GCP болон Али дахь бүх дэд бүтцийг тайлбарлаж, дээшлүүлсэн. Үүл хоорондын 100 Мбит/с хурдтай туннель бараг тэр дороо дээшээ гарчээ. Шэньжэнь, Тайванийн талд прокси хийх виртуал машинууд бий болсон. Шенжен хотод хэрэглэгчийн урсгалыг зогсоож, Тайвань руу хонгилоор дамжуулж, тэндээс манай үйлчилгээний гадаад IP руу шууд ордог. бид-зүүн (АНУ-ын зүүн эрэг). Туннелээр виртуал машинуудын хооронд ping хийх 24ms, энэ нь тийм ч муу биш юм.

Үүний зэрэгцээ бид туршилтын талбайг байрлуулсан Alibaba Cloud DNS. Бүсийг NS Али-д шилжүүлсний дараа нарийвчлалын хугацаа 470 мс-ээс буурчээ 50 ms. Үүнээс өмнө тус бүс нь Cloudlfare дээр байсан.

-ийн хонгилтой зэрэгцээ ази-зүүн1 Шэньжэнээс шууд өөр хонгил босгов АНУ-Зүүн4. Тэнд тэд илүү олон прокси виртуал машинуудыг бүтээж, күүки эсвэл DNS ашиглан туршилтын урсгалыг чиглүүлж, хоёр шийдлийг туршиж эхлэв. Туршилтын ванданг дараах зурагт схемийн дагуу дүрсэлсэн болно.

Хонгилын хоцрогдол дараах байдалтай болсон.
Али cn-shenzhen <—> GCP ази-зүүн1 — 24ms
Али cn-shenzhen <—> GCP us-east4 — 200ms

Catchpoint хөтчийн тестүүд маш сайн сайжирсан гэж мэдээлсэн.

Хоёр шийдлийн туршилтын үр дүнг харьцуулна уу:

шийдвэр
Дахин цаг хугацаа
Median
75 хувь
95 хувь

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

Энэ бол IPSEC хонгилоор дамжуулан ашигладаг шийдлийн өгөгдөл юм ази-зүүн1. Бид-east4-ээр дамжуулан үр дүн нь муу, алдаа их байсан тул би үр дүнг өгөхгүй.

Хоёр хонгилын туршилтын үр дүнд үндэслэн нэг нь Хятадтай хамгийн ойр бүс нутагт, нөгөө нь эцсийн цэг дээр баригдсан тул Хятадын галт ханын дороос аль болох хурдан “гарч” гарах нь чухал болох нь тодорхой болсон. боломжтой, дараа нь хурдан сүлжээг ашиглана уу (CDN үйлчилгээ үзүүлэгч, үүлэн үйлчилгээ үзүүлэгч гэх мэт). Галт ханыг давж, зорьсон газартаа нэг цохилтоор хүрэхийг оролдох шаардлагагүй. Энэ бол хамгийн хурдан арга биш юм.

Ерөнхийдөө үр дүн нь тийм ч муу биш боловч semrush.com сайтын дундаж үзүүлэлт 8.8 секунд, 75 хувь 9.4 секунд байна (ижил тест дээр).
Цааш үргэлжлүүлэхийн өмнө би богино хэмжээний уянгын ухралт хиймээр байна.

Уянгын ухралт

Хэрэглэгч сайт руу орсны дараа www.semrushchina.cn, Хятадын "хурдан" DNS серверүүдээр дамжуулан шийдэгддэг HTTP хүсэлт нь манай хурдан шийдлээр дамждаг. Хариултыг ижил зам дагуу буцаана, гэхдээ домэйн нь бүх JS скрипт, HTML хуудас болон вэб хуудасны бусад элементүүдэд тодорхойлогддог. semrush.com хуудсыг буулгах үед ачаалах шаардлагатай нэмэлт нөөцийн хувьд. Өөрөөр хэлбэл, үйлчлүүлэгч "үндсэн" А бичлэгийг шийддэг www.semrushchina.cn болон хурдан хонгил руу ороход хариу хурдан хүлээн авдаг - HTML хуудас нь:

• sso.semrush.com сайтаас ийм ийм js татаж авах,
• cdn.semrush.com сайтаас CSS файлуудыг аваарай.
• Мөн dab.semrush.com сайтаас зураг ав
• гэх мэт.

Хөтөч нь эдгээр эх сурвалжуудад зориулж "гадаад" интернет рүү нэвтэрч эхэлдэг бөгөөд хариу өгөх хугацаа нь дуусдаг галт ханаар дамжин өнгөрөх бүртээ.

Гэхдээ өмнөх тест нь хуудсан дээр нөөц байхгүй үед үр дүнг харуулдаг semrush.comзөвхөн semrushchina.cn, мөн *.semrushchina.cn нь хонгил руу орохын тулд Шенжен дэх виртуал машины хаягийг шийддэг.

Зөвхөн ийм байдлаар л Хятадын галт ханыг хурдан даван туулахын тулд бүх боломжит траффикийг өөрийн шийдлээр хамгийн дээд хэмжээнд хүргэснээр та зөвшөөрөгдөх хурд, вэб сайтын хүртээмжийн үзүүлэлтүүд, мөн шийдлийн туршилтын үнэн зөв үр дүнг авах боломжтой.
Бид багийн бүтээгдэхүүний тал дээр нэг ч код засваргүйгээр үүнийг хийсэн.

Дэд шүүлтүүр

Энэ асуудал гарсны дараа шийдэл нь бараг тэр даруй гарч ирэв. Бидэнд хэрэгтэй байсан PoC (Үзэл баримтлалын баталгаа) манай галт хананд нэвтрэх шийдлүүд үнэхээр сайн ажилладаг. Үүнийг хийхийн тулд та сайтын бүх урсгалыг энэ шийдэлд аль болох оруулах хэрэгтэй. Тэгээд бид өргөдөл гаргасан дэд шүүлтүүр 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;
    }
}

Энэ тохиргоо нь тестлээрэй 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 дахин эхэлсэн. Ажиллах хугацаа муудаж эхэлсэн тул бид хувилбар дээр ажиллаж эхэлсэн. Алибаба CEN (Cloud Enterprise Network).

CEN

CEN - энэ нь Alibaba Cloud доторх өөр өөр бүс нутгийн хоёр VPC-ийн холболт бөгөөд өөрөөр хэлбэл та үүлэн доторх аль ч бүсийн хувийн сүлжээг хооронд нь холбож болно. Хамгийн гол нь: энэ суваг нь нэлээд хатуу байдаг SLA. Энэ нь хурд болон ажиллах хугацаандаа маш тогтвортой байдаг. Гэхдээ энэ нь хэзээ ч ийм энгийн байдаггүй:

• Хэрэв та Хятадын иргэн эсвэл хуулийн этгээд биш бол үүнийг авахад маш хэцүү,
• Та сувгийн багтаамжийн мегабит тутамд төлөх шаардлагатай.

Холбох боломж байна Эх газрын Хятад и Хилийн чанад дахь, бид хоёр Али мужийн хооронд CEN үүсгэсэн: cn-shenzhen и АНУ-зүүн-1 (бидтэй хамгийн ойрхон цэг-зүүн4). Алид АНУ-зүүн-1 өөр виртуал машин босгосон тул дахиад нэгийг бий болгов хоп.

Энэ нь дараах байдалтай болсон.

Хөтөчийн туршилтын үр дүнг доор харуулав.

шийдвэр
Дахин цаг хугацаа
Median
75 хувь
95 хувь

Cloudflare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

Гүйцэтгэл нь IPSEC-ээс арай дээр юм. Гэхдээ IPSEC-ээр дамжуулан та 100 Mbit/s хурдтай, CEN-ээр дамжуулан зөвхөн 5 Mbit/s ба түүнээс дээш хурдтайгаар татаж авах боломжтой.

Эрлийз шиг сонсогдож байна, тийм ээ? IPSEC хурд болон CEN тогтвортой байдлыг хослуул.

IPSEC хонгил эвдэрсэн тохиолдолд IPSEC болон CEN-ээр дамжин өнгөрөх хөдөлгөөнийг зөвшөөрч, бид үүнийг хийсэн. Ажиллах хугацаа хамаагүй өндөр болсон ч сайтыг ачаалах хурд нь хүссэн зүйлээ үлдээсээр байна. Дараа нь би аль хэдийн ашиглаж, туршиж үзсэн бүх хэлхээг зурж, энэ хэлхээнд GCP-ийг бага зэрэг нэмэхээр шийдсэн. таг.

таг

таг Байна уу Дэлхийн ачаалал тэнцвэржүүлэгч (эсвэл Google Cloud Load Balancer). Энэ нь бидний хувьд чухал давуу талтай: CDN-ийн хүрээнд anycast IP, энэ нь танд траффикийг үйлчлүүлэгчтэй хамгийн ойр байгаа дата төв рүү чиглүүлэх боломжийг олгодог бөгөөд ингэснээр траффик Google-ийн хурдан сүлжээнд хурдан орж, "энгийн" интернетээр бага дамждаг.

Хоёр ч удаа бодолгүйгээр бид өсгөсөн HTTP/HTTPS LB Бид виртуал машинуудаа GCP-д дэд шүүлтүүртэй, арын хэсэг болгон суулгасан.

Хэд хэдэн схемүүд байсан:

• Хэрэглэх Cloudflare China Network, гэхдээ энэ удаад Origin нь глобалыг зааж өгөх ёстой IP GLB.
• Үйлчлүүлэгчдийг дуусгах cn-shenzhen, мөн тэндээс траффикийг шууд прокси таг.
• Хятадаас шууд оч таг.
• Үйлчлүүлэгчдийг дуусгах cn-shenzhen, тэндээс прокси руу ази-зүүн1 IPSEC-ээр (ин АНУ-Зүүн4 CEN-ээр дамжуулан), тэндээс GLB руу оч (тайван доор зураг, тайлбар байх болно)

Бид эдгээр бүх сонголтууд болон хэд хэдэн эрлийз хувилбаруудыг туршиж үзсэн:

• Cloudflare + GLB

Ажиллах хугацаа болон DNS алдааны улмаас энэ схем бидэнд тохирохгүй байна. Гэхдээ CF тал дээр алдаа засахаас өмнө туршилтыг хийсэн, магадгүй одоо илүү дээр байх болно (гэхдээ энэ нь HTTP-ийн завсарлагыг үгүйсгэхгүй).

• Али + GLB

Энэ схем нь ажиллах хугацааны хувьд ч бидэнд тохирохгүй байсан, учир нь GLB нь хүлээн зөвшөөрөгдсөн хугацаанд холбогдох боломжгүй, эсвэл завсарлага авснаас болж ихэвчлэн дээд урсгалаас унадаг, учир нь Хятад дахь серверийн хувьд GLB хаяг нь гадна талд хэвээр үлддэг тул ард нь байдаг. Хятадын галт хана. Ид шид болоогүй.

• Зөвхөн GLB

Өмнөхтэй төстэй сонголт нь зөвхөн Хятадад сервер ашигладаггүй: траффик шууд GLB руу очсон (DNS бүртгэл өөрчлөгдсөн). Үүний дагуу энгийн интернет үйлчилгээ үзүүлэгчдийн үйлчилгээг ашигладаг Хятадын энгийн үйлчлүүлэгчид галт ханыг нэвтрүүлэх нь Али Клоудаас хамаагүй дор байдаг тул үр дүн нь хангалтгүй байв.

• Shenzhen -> (CEN/IPSEC) -> Proxy -> GLB

Энд бид бүх шийдлүүдийн хамгийн сайныг ашиглахаар шийдсэн:

• тогтвортой байдал, CEN-аас баталгаатай SLA
• IPSEC-ээс өндөр хурдтай
• Google-ийн "хурдан" сүлжээ ба түүний дурын дамжуулалт.

Энэ схем нь иймэрхүү харагдаж байна: хэрэглэгчийн траффик нь виртуал машин дээр зогссон ч-шенжэнь. Nginx upstreams нь тэнд тохируулагдсан байдаг бөгөөд тэдгээрийн зарим нь IPSEC туннелийн нөгөө үзүүрт байрлах хувийн IP серверүүд рүү чиглэдэг бол зарим нь дээд тал нь CEN-ийн нөгөө талд байрлах серверүүдийн хувийн хаягуудыг заадаг. IPSEC-ийг бүс болгон тохируулсан ази-зүүн1 GCP-д (шийдвэрийг бий болгох үед Хятадад хамгийн ойр байсан бүс нутаг байсан. GCP нь одоо Хонг Конгод бас байрлаж байна). CEN - бүс нутаг руу АНУ-Зүүн1 Али Cloud-д.

Дараа нь хоёр захын хөдөлгөөнийг чиглүүлсэн anycast IP GLB, өөрөөр хэлбэл Google-ийн хамгийн ойрын цэгт хүрч, сүлжээгээр дамжуулан бүс нутаг руу явсан АНУ-Зүүн4 GCP-д орлуулах виртуал машинууд байсан (nginx дахь дэд шүүлтүүртэй).

Энэхүү эрлийз шийдэл нь бидний хүлээж байсанчлан технологи бүрийн давуу талыг ашигласан. Ерөнхийдөө урсгал IPSEC-ээр хурдан дамждаг, гэхдээ асуудал үүсвэл бид хурдан бөгөөд хэдхэн минутын дотор эдгээр серверүүдийг дээд урсгалаас гаргаж, хонгил тогтворжих хүртэл урсгалыг зөвхөн CEN-ээр дамжуулдаг.

Дээрх жагсаалтын 4-р шийдлийг хэрэгжүүлснээр бид хүссэн зүйлдээ хүрч, тухайн үед бизнес биднээс юу шаардаж байсан юм.

Өмнөхтэй харьцуулахад шинэ шийдлийн хөтөчийн туршилтын үр дүн:

шийдвэр
Дахин цаг хугацаа
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 үйлчилгээ үзүүлэгчдийг хайж, турших.

Би энэ тухай дараагийн, эцсийн хэсэгт хэлэх болно :)

Эх сурвалж: www.habr.com