Hi!
Nikita bersamamu lagi, seorang insinyur sistem dari perusahaan SEMrush. Dan dengan artikel ini saya melanjutkan cerita tentang bagaimana kami menemukan solusi solusinya Firewall Tiongkok untuk layanan kami semrush.com.
В Saya bilang:
- masalah apa yang muncul setelah keputusan dibuat “Kami perlu membuat layanan kami berfungsi di Tiongkok”
- Masalah apa yang dihadapi Internet Tiongkok?
- mengapa Anda memerlukan lisensi ICP?
- bagaimana dan mengapa kami memutuskan untuk menguji testbed kami dengan Catchpoint
- apa hasil dari solusi pertama kami berdasarkan Cloudflare China Network
- Bagaimana kami menemukan bug di Cloudflare DNS
Bagian ini menurut saya paling menarik karena fokus pada teknis implementasi staging secara spesifik. Dan kita akan memulai, atau lebih tepatnya melanjutkan, dengan Alibaba Cloud.
Alibaba Cloud
Alibaba Cloud adalah penyedia cloud yang cukup besar, yang memiliki semua layanan yang memungkinkannya menyebut dirinya sebagai penyedia cloud. Ada baiknya mereka memiliki kesempatan untuk mendaftar untuk pengguna asing, dan sebagian besar situs diterjemahkan ke dalam bahasa Inggris (untuk China ini adalah sebuah kemewahan). Di cloud ini, Anda dapat bekerja dengan banyak wilayah di dunia, Tiongkok daratan, serta Asia Oseanik (Hong Kong, Taiwan, dll.).
IPSEC
Kami mulai dengan geografi. Karena situs pengujian kami berlokasi di Google Cloud, kami perlu “menghubungkan” Alibaba Cloud dengan GCP, jadi kami membuka daftar lokasi di mana Google hadir. Saat itu mereka belum memiliki pusat data sendiri di Hong Kong.
Ternyata wilayah terdekat adalah asia-timur1 (Taiwan). Ali ternyata merupakan wilayah daratan Tiongkok yang paling dekat dengan Taiwan cn-shenzhen (Shenzhen).
Dengan terraform mendeskripsikan dan mengangkat seluruh infrastruktur di GCP dan Ali. Terowongan 100 Mbit/s di antara awan naik hampir seketika. Di sisi Shenzhen dan Taiwan, mesin virtual proksi dimunculkan. Di Shenzhen, lalu lintas pengguna dihentikan, diproksi melalui terowongan ke Taiwan, dan dari sana lalu lintas langsung menuju ke IP eksternal layanan kami di AS-Timur (Pantai Timur AS). Ping antar mesin virtual melalui terowongan 24ms, yang tidak terlalu buruk.
Pada saat yang sama, kami menempatkan area pengujian DNS Cloud Alibaba. Setelah mendelegasikan zona ke NS Ali, waktu resolusi berkurang dari 470 ms menjadi 50 ms. Sebelumnya, zona tersebut juga berada di Cloudlfare.
Sejajar dengan terowongan ke asia-timur1 mengangkat terowongan lain dari Shenzhen langsung ke kami-timur4. Di sana mereka menciptakan lebih banyak mesin virtual proxy dan mulai menguji kedua solusi tersebut, merutekan lalu lintas pengujian menggunakan Cookie atau DNS. Bangku tes dijelaskan secara skematis pada gambar berikut:
Latensi untuk terowongan ternyata sebagai berikut:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200 md
Tes browser Catchpoint melaporkan peningkatan yang luar biasa.
Bandingkan hasil tes untuk dua solusi:
keputusan
Uptime
rata-rata
75 Persentil
95 Persentil
cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
Ini adalah data dari solusi yang menggunakan terowongan IPSEC via asia-timur1. Melalui us-east4 hasilnya lebih buruk, dan lebih banyak kesalahan, jadi saya tidak akan memberikan hasilnya.
Berdasarkan hasil pengujian dua terowongan ini, salah satunya diakhiri di wilayah terdekat dengan Tiongkok, dan yang lainnya di tujuan akhir, menjadi jelas bahwa penting untuk “keluar” dari bawah firewall Tiongkok secepatnya. mungkin, lalu gunakan jaringan cepat (penyedia CDN, penyedia cloud, dll.). Tidak perlu mencoba melewati firewall dan mencapai tujuan Anda dalam satu gerakan. Ini bukan cara tercepat.
Secara umum, hasilnya lumayan, namun semrush.com memiliki median 8.8 detik, dan 75 Persentil 9.4 detik (pada pengujian yang sama).
Dan sebelum melanjutkan, saya ingin membuat penyimpangan lirik singkat.
Penyimpangan liris
Setelah pengguna memasuki situs www.semrushchina.cn, yang diselesaikan melalui server DNS Tiongkok “cepat”, permintaan HTTP melewati solusi cepat kami. Respons dikembalikan melalui jalur yang sama, tetapi domain ditentukan di semua skrip JS, halaman HTML, dan elemen halaman web lainnya semrush.com untuk sumber daya tambahan yang harus dimuat saat halaman dirender. Artinya, klien menyelesaikan A-record "utama". www.semrushchina.cn dan masuk ke terowongan cepat, dengan cepat menerima respons - halaman HTML yang menyatakan:
- unduh js ini dan itu dari sso.semrush.com,
- Dapatkan file CSS dari cdn.semrush.com,
- dan juga mengambil beberapa gambar dari dab.semrush.com
- dan sebagainya.
Browser mulai mengakses Internet "eksternal" untuk mendapatkan sumber daya ini, setiap kali melewati firewall yang memakan waktu respons.
Namun pengujian sebelumnya menunjukkan hasil ketika tidak ada sumber daya di halaman semrush.com, hanya semrushchina.cn, dan *.semrushchina.cn memutuskan ke alamat mesin virtual di Shenzhen untuk kemudian masuk ke terowongan.
Hanya dengan cara ini, dengan mendorong semua kemungkinan lalu lintas secara maksimal melalui solusi Anda untuk melewati firewall China dengan cepat, Anda dapat memperoleh indikator kecepatan dan ketersediaan situs web yang dapat diterima, serta hasil pengujian solusi yang jujur.
Kami melakukan ini tanpa satu pun pengeditan kode di sisi produk tim.
Subfilter
Solusinya lahir segera setelah masalah ini muncul. Kami membutuhkan PoC (Bukti Konsep) bahwa solusi penetrasi firewall kami benar-benar berfungsi dengan baik. Untuk melakukan ini, Anda perlu menggabungkan semua lalu lintas situs ke dalam solusi ini sebanyak mungkin. Dan kami melamar di nginx.
Subfilter adalah modul yang cukup sederhana di nginx yang memungkinkan Anda mengubah satu baris di badan respons ke baris lain. Jadi kami mengubah semua kejadian semrush.com pada semrushchina.cn dalam semua jawaban.
Dan... tidak berhasil karena kami menerima konten terkompresi dari backend, sehingga subfilter tidak menemukan baris yang diperlukan. Saya harus menambahkan server lokal lain ke nginx, yang mendekompresi respons dan meneruskannya ke server lokal berikutnya, yang sudah sibuk mengganti string, mengompresinya, dan mengirimkannya ke server proxy berikutnya dalam rantai tersebut.
Akibatnya, di mana klien akan menerima .semrush.com, dia menerimanya .semrushchina.cn dan dengan patuh menjalani keputusan kami.
Namun, mengubah domain saja tidak cukup, karena backend masih mengharapkan semrush.com pada permintaan berikutnya dari klien. Oleh karena itu, di server yang sama tempat penggantian satu arah dilakukan, dengan menggunakan ekspresi reguler sederhana kami mendapatkan subdomain dari permintaan, dan kemudian kami melakukannya proxy_pass dengan variabel $host, dipamerkan di $subdomain.semrush.com. Ini mungkin tampak membingungkan, tetapi berhasil. Dan itu bekerja dengan baik. Untuk masing-masing domain yang memerlukan logika berbeda, cukup buat blok server Anda sendiri dan buat konfigurasi terpisah. Di bawah ini adalah konfigurasi nginx yang dipersingkat untuk kejelasan dan demonstrasi skema ini.
Konfigurasi berikut memproses semua permintaan dari Tiongkok ke .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;
}
}Konfigurasi ini proksi ke localhost ke port 83, dan konfigurasi berikut menunggu di sana:
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;
}
}Saya ulangi, ini adalah konfigurasi yang dipotong.
Seperti itu. Ini mungkin terlihat rumit, tetapi itu benar dalam kata-kata. Faktanya, semuanya lebih sederhana dari lobak kukus :)
Akhir dari penyimpangan
Untuk sementara kami senang karena mitos tentang jatuhnya terowongan IPSEC tidak terbukti. Tapi kemudian terowongan mulai runtuh. Beberapa kali sehari selama beberapa menit. Sedikit, tapi itu tidak cocok untuk kami. Karena kedua terowongan diakhiri di sisi Ali pada router yang sama, kami memutuskan bahwa mungkin ini adalah masalah regional dan kami perlu meningkatkan wilayah cadangan.
Mereka mengambilnya. Terowongan mulai gagal pada waktu yang berbeda, tetapi failover tersebut berfungsi dengan baik bagi kami di level upstream di nginx. Tapi kemudian terowongan mulai runtuh pada waktu yang hampir bersamaan 🙂 Dan 502 dan 504 dimulai lagi. Waktu kerja mulai menurun, jadi kami mulai mengerjakan opsi dengan Alibaba CEN (Jaringan Perusahaan Cloud).
CEN
CEN - ini adalah konektivitas dua VPC dari wilayah berbeda dalam Alibaba Cloud, yaitu, Anda dapat menghubungkan jaringan pribadi dari wilayah mana pun dalam cloud satu sama lain. Dan yang paling penting: saluran ini memiliki aturan yang cukup ketat SLA. Ini sangat stabil baik dalam kecepatan maupun uptime. Namun tidak pernah sesederhana itu:
- SANGAT sulit mendapatkannya jika Anda bukan warga negara Tiongkok atau badan hukum,
- Anda harus membayar untuk setiap megabit bandwidth saluran.
Memiliki kesempatan untuk terhubung daratan Cina и Luar negeri, kami membuat CEN antara dua wilayah Ali: cn-shenzhen и kami-timur-1 (titik terdekat ke us-east4). Di Ali kami-timur-1 mengangkat mesin virtual lain sehingga ada satu lagi lompat.
Ternyata seperti ini:
Hasil tes browser di bawah ini:
keputusan
Uptime
rata-rata
75 Persentil
95 Persentil
cloudflare
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
CEN
99.75
16s
21s
27s
Performanya sedikit lebih baik dibandingkan IPSEC. Namun melalui IPSEC Anda berpotensi mengunduh dengan kecepatan 100 Mbit/s, dan melalui CEN hanya dengan kecepatan 5 Mbit/s dan lebih.
Kedengarannya seperti hibrida, bukan? Kombinasikan kecepatan IPSEC dan stabilitas CEN.
Inilah yang kami lakukan, mengizinkan lalu lintas melalui IPSEC dan CEN jika terjadi kegagalan terowongan IPSEC. Uptime menjadi jauh lebih tinggi, namun kecepatan memuat situs masih jauh dari yang diinginkan. Kemudian saya menggambar semua sirkuit yang telah kami gunakan dan uji, dan memutuskan untuk mencoba menambahkan sedikit GCP lagi ke sirkuit ini, yaitu Cap.
Cap
Cap - Apakah (atau Penyeimbang Beban Google Cloud). Ini memiliki keuntungan penting bagi kami: dalam konteks CDN yang dimilikinya IP siaran apa pun, yang memungkinkan Anda merutekan lalu lintas ke pusat data yang paling dekat dengan klien, sehingga lalu lintas dengan cepat masuk ke jaringan cepat Google dan lebih sedikit yang melewati Internet “biasa”.
Tanpa berpikir dua kali, kami bangkit HTTP/HTTPS LB Kami memasang mesin virtual kami dengan subfilter di GCP dan sebagai backend.
Ada beberapa skema:
- Menggunakan Jaringan Cloudflare Cina, tapi kali ini Origin harus menentukan global IP GLB.
- Hentikan klien di cn-shenzhen, dan dari sana proksi lalu lintas langsung ke Cap.
- Langsung dari China ke Cap.
- Hentikan klien di cn-shenzhen, dari sana proksi ke asia-timur1 melalui IPSEC (dalam kami-timur4 via CEN), dari sana menuju GLB (tenang saja nanti ada gambar dan penjelasannya dibawah)
Kami menguji semua opsi ini dan beberapa opsi hybrid lainnya:
- Cloudflare + GLB
Skema ini tidak cocok untuk kami karena waktu aktif dan kesalahan DNS. Namun pengujian dilakukan sebelum bug diperbaiki di sisi CF, mungkin sekarang lebih baik (namun, ini tidak mengecualikan batas waktu HTTP).
- Ali + GLB
Skema ini juga tidak cocok untuk kami dalam hal uptime, karena GLB sering keluar dari upstream karena ketidakmampuan untuk terhubung dalam waktu atau batas waktu yang dapat diterima, karena untuk server di China, alamat GLB tetap berada di luar, dan oleh karena itu berada di belakang. firewall Tiongkok. Keajaiban tidak terjadi.
- Hanya GLB
Opsi yang mirip dengan yang sebelumnya, hanya saja tidak menggunakan server di China sendiri: lalu lintas langsung menuju ke GLB (catatan DNS diubah). Oleh karena itu, hasilnya tidak memuaskan, karena klien China biasa yang menggunakan layanan penyedia Internet biasa memiliki situasi yang jauh lebih buruk dalam melewati firewall daripada Ali Cloud.
- Shenzhen -> (CEN/IPSEC) -> Proksi -> GLB
Di sini kami memutuskan untuk menggunakan solusi terbaik:
- stabilitas dan jaminan SLA dari CEN
- kecepatan tinggi dari IPSEC
- Jaringan "cepat" Google dan siarannya.
Skemanya terlihat seperti ini: lalu lintas pengguna pada mesin virtual dihentikan ch-shenzhen. Upstream Nginx dikonfigurasi di sana, beberapa di antaranya mengarah ke server IP pribadi yang terletak di ujung lain terowongan IPSEC, dan beberapa upstream menunjuk ke alamat server pribadi di sisi lain CEN. IPSEC dikonfigurasikan ke wilayah asia-timur1 di GCP (merupakan wilayah yang paling dekat dengan Tiongkok pada saat solusi ini dibuat. GCP kini juga hadir di Hong Kong). CEN - ke wilayah kami-timur1 di Ali Cloud.
Kemudian lalu lintas dari kedua ujung diarahkan ke siaran IP GLB, yaitu ke titik terdekat keberadaan Google, dan melalui jaringannya hingga ke wilayah tersebut kami-timur4 di GCP, yang di dalamnya terdapat mesin virtual pengganti (dengan subfilter di nginx).
Solusi hibrid ini, seperti yang kami harapkan, memanfaatkan keunggulan masing-masing teknologi. Secara umum, lalu lintas melewati IPSEC dengan cepat, tetapi jika masalah mulai terjadi, kami dengan cepat dan selama beberapa menit mengeluarkan server ini dari upstream dan mengirimkan lalu lintas hanya melalui CEN hingga terowongan stabil.
Dengan menerapkan solusi ke-4 dari daftar di atas, kami mencapai apa yang kami inginkan dan apa yang dibutuhkan bisnis dari kami pada saat itu.
Hasil pengujian browser untuk solusi baru dibandingkan dengan yang sebelumnya:
keputusan
Uptime
rata-rata
75 Persentil
95 Persentil
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
Semuanya baik-baik saja dalam solusi yang kami terapkan, namun belum ada CDN yang dapat mempercepat lalu lintas di tingkat regional bahkan kota. Secara teori, ini akan mempercepat situs bagi pengguna akhir dengan menggunakan saluran komunikasi cepat dari penyedia CDN. Dan kami memikirkannya sepanjang waktu. Dan sekarang, waktunya telah tiba untuk proyek berikutnya: mencari dan menguji penyedia CDN di Tiongkok.
Dan saya akan menceritakannya kepada Anda di bagian terakhir berikutnya :)
Sumber: www.habr.com