איך פרצנו את חומת האש הגדולה של סין (חלק 3)

היי!
כל הסיפורים הטובים מגיעים לסופם. והסיפור שלנו על איך המצאנו פתרון לעבור במהירות את חומת האש הסינית אינו יוצא מן הכלל. לכן, אני ממהר לחלוק איתך את האחרון, החלק האחרון בנושא זה.

בחלק הקודם דיברנו על ספסלי בדיקה רבים שהגענו ואיזה תוצאות הם נתנו. וקבענו מה יהיה נחמד להוסיף CDN! עבור צמיגות לתוך התוכנית שלנו.

אני אספר לכם איך בדקנו את Alibaba Cloud CDN, Tencent Cloud CDN ו-Akamai, ומה הגענו אליו. וכמובן, בואו נסכם.

Alibaba Cloud CDN

אנחנו מתארחים ב- Alibaba Cloud ומשתמשים מהם ב-IPSEC וב-CEN. זה יהיה הגיוני לנסות תחילה את הפתרונות שלהם.

ל- Alibaba Cloud יש שני סוגי מוצרים שעשויים להתאים לנו: CDN и DCDN. האפשרות הראשונה היא CDN קלאסי לדומיין ספציפי (תת-דומיין). האפשרות השנייה מייצגת מסלול דינמי עבור CDN (אני קורא לזה CDN דינמי), אפשר להפעיל אותו במצב של אתר מלא (לתחומי תווים כלליים), זה גם מאחסן תוכן סטטי ומאיץ תוכן דינמי על עצמו, כלומר הדינמיקה של העמוד תיטען גם דרך הספק של הספק רשתות מהירות. זה חשוב לנו, כי בעצם האתר שלנו הוא דינמי, הוא משתמש בתת-דומיינים רבים, ונוח יותר להגדיר CDN פעם אחת עבור ה"כוכבית" - *.semrushchina.cn.

כבר ראינו את המוצר הזה בשלבים המוקדמים יותר של הפרויקט הסיני שלנו, אבל אז הוא עדיין לא עבד, והמפתחים הבטיחו שהמוצר יהפוך בקרוב לזמין לכל הלקוחות. והוא עשה.

ב-DCDN אתה יכול:

• להגדיר סיום SSL עם האישור שלך,
• לאפשר האצה של תוכן דינמי,
• תצורה גמישה של שמירה במטמון של קבצים סטטיים,
• נקה את המטמון,
• שקעי אינטרנט קדימה,
• אפשר דחיסה ואפילו HTML Beautifier.

באופן כללי, הכל זהה למבוגרים וספקי CDN גדולים.

לאחר שצוין ה-Origin (המקום שאליו ילכו שרתי ה-CDN Edge), כל שנותר הוא ליצור CNAME עבור הכוכבית, תוך הפניה all.semrushchina.cn.w.kunluncan.com (CNAME זה התקבל בקונסולת Alibaba Cloud) וה-CDN יפעל.

בהתבסס על תוצאות הבדיקה, CDN זה עזר לנו מאוד. הנתונים הסטטיסטיים מוצגים להלן.

החלטה
Uptime
חציון
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 + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s

אלו תוצאות טובות מאוד, במיוחד אם משווים אותן למה שהיו המספרים בהתחלה. אבל ידענו שמבחן הדפדפן של הגרסה האמריקאית של האתר שלנו www.semrush.com פועל מארה"ב בממוצע של 8.3 שניות (ערך משוער מאוד). יש מקום לשיפור. יתר על כן, היו גם ספקי CDN שהיה מעניין לבדוק.

אז אנחנו עוברים בצורה חלקה לענקית אחרת בשוק הסיני - Tencent.

טנסנט ענן

Tencent רק מפתחת את הענן שלה - ניתן לראות זאת ממספר קטן של מוצרים. בזמן השימוש בו, רצינו לבדוק לא רק את ה-CDN שלהם, אלא גם את תשתית הרשת שלהם בכללותה:

• יש להם משהו דומה ל-CEN?
• איך IPSEC עובד עבורם? האם זה מהיר, מה זמן הפעולה?
• יש להם Anycast?

הבה נבחן את השאלות הללו בנפרד.

אנלוגי CEN

לטנסנט יש מוצר Cloud Connect Network (CCN), המאפשר לך לחבר VPCs מאזורים שונים, כולל אזורים בתוך ומחוץ לסין. המוצר נמצא כעת בבטא פנימית, ואתה צריך ליצור כרטיס המבקש להתחבר אליו. למדנו מהתמיכה שחשבונות גלובליים (אנחנו לא מדברים על אזרחים סינים או ישויות משפטיות) לא יכולים להשתתף בתוכנית בדיקות הבטא ובאופן כללי לחבר אזור בתוך סין עם אזור מחוצה לו. 1-0 לזכות עלי קלאוד

IPSEC

האזור הדרומי ביותר של טנסנט הוא גואנגג'ואו. הרכבנו מנהרה וחיברנו אותה לאזור הונג קונג ב-GCP (ואז האזור הזה כבר הפך לזמין). המנהרה השנייה באלי קלאוד משנג'ן להונג קונג הועלתה גם היא במקביל. התברר שדרך רשת Tencent השהיה להונג קונג בדרך כלל טוב יותר (10ms) מאשר משנג'ן להונג קונג ועד עלי (120ms - מה?). אבל זה לא זירז בשום צורה את העבודה של האתר שמטרתו לעבוד דרך Tencent והמנהרה הזו, שבעצמה הייתה עובדה מדהימה ושוב הוכיחה את הדברים הבאים: חביון - עבור סין זה לא אינדיקטור שבאמת שווה לשים לב בעת פיתוח פתרון להעברת חומת האש הסינית.

האצת אינטרנט של Anycast

מוצר נוסף המאפשר לך לעבוד באמצעות anycast IP הוא AIA. אבל זה גם לא זמין לחשבונות גלובליים, אז אני לא אספר לך על זה, אבל הידיעה שקיים מוצר כזה עשויה להיות שימושית.

אבל בדיקת CDN הראתה כמה תוצאות מעניינות למדי. לא ניתן להפעיל את ה-CDN של Tencent באתר מלא, רק בדומיינים ספציפיים. יצרנו דומיינים ושלחנו אליהם תנועה:

התברר של-CDN הזה יש את הפונקציה הבאה: אופטימיזציה של תנועה חוצה גבולות. תכונה זו אמורה להפחית עלויות כאשר תעבורה עוברת דרך חומת האש הסינית. כפי ש מָקוֹר צוינה כתובת ה-IP של Google GLB (GLB anycast). לפיכך, רצינו לפשט את ארכיטקטורת הפרויקט.

התוצאות היו טובות מאוד - ברמה של Ali Cloud CDN, ובמקומות מסוימים אפילו טובות יותר. זה מפתיע, כי אם הבדיקות יצליחו, אפשר לנטוש חלק נכבד מהתשתיות, המנהרות, ה-CEN, המכונות הוירטואליות וכו'.

לא שמחנו זמן רב, שכן התגלתה בעיה: בדיקות ב-Catchpoint נכשלו עבור ספקית האינטרנט China Mobile. מכל מקום קיבלנו פסק זמן דרך ה-CDN של Tencent. התכתבות עם תמיכה טכנית לא הובילה לכלום. ניסינו לפתור את הבעיה במשך יום, אבל שום דבר לא עבד.

הייתי בסין באותו רגע, אבל לא הצלחתי למצוא Wi-Fi ציבורי ברשת של ספק זה כדי לאמת את הבעיה באופן אישי. אחרת הכל נראה מהיר וטוב.
עם זאת, בשל העובדה שצ'יינה מובייל היא אחת משלושת המפעילים הגדולים ביותר, נאלצנו להחזיר תנועה ל-Ali CDN.
אבל בסך הכל, זה היה פתרון מעניין למדי שראוי לבדיקה ופתרון בעיות ממושכים יותר של בעיה זו.

Akamai

ספק ה-CDN האחרון שבדקנו היה Akamai. מדובר בספק ענק שהרשת שלו בסין. כמובן, לא יכולנו לעבור את זה.

כבר מההתחלה סיכמנו עם Akamai לתקופת ניסיון כדי שנוכל להחליף את הדומיין ולראות איך זה יעבוד ברשת שלהם. אתאר את התוצאה של כל הבדיקות בצורה של "מה אהבתי" ו"מה לא אהבתי", ואתן גם את תוצאות הבדיקה.

מה אהבנו:

• החבר'ה מאקמאי עזרו מאוד בכל השאלות וליוו אותנו בכל שלבי הבדיקה. כל הזמן ניסינו לשפר משהו בצד שלנו. הם נתנו עצות טכניות טובות.
• Akamai איטי בכ-10-15% מהפתרון שלנו דרך Ali Cloud CDN. מה שמרשים הוא שב-Origin for Akamai ציינו את כתובת ה-IP של ה-GLB, כלומר התעבורה לא עברה דרך הפתרון שלנו (אולי נוכל לנטוש חלק מהתשתית). אבל עדיין, תוצאות הבדיקה הראו שהפתרון הזה גרוע יותר מהגרסה הנוכחית שלנו (תוצאות השוואתיות למטה).
• נבדק גם Origin GLB וגם Origin בסין. שתי האפשרויות זהות בערך.
• יש מסלול בטוח (אופטימיזציה אוטומטית של ניתוב). אתה יכול לארח אובייקט בדיקה ב-Origin, ושרתי Akamai Edge ינסו לאסוף אותו (GET רגיל). עבור בקשות אלו נמדדים מהירות ומדדים נוספים, על בסיסם רשת Akamai מייעלת את המסלולים כך שהתנועה עוברת מהר יותר לאתר שלנו והיה ברור שלהפעלת התכונה הזו באמת הייתה השפעה חזקה על מהירות האתר.
• גירסת התצורה בממשק האינטרנט היא מגניבה. אתה יכול לעשות השווה עבור גרסאות, תסתכל על הבדל. הצג גרסאות קודמות.
• אתה יכול להוציא גרסה חדשה תחילה רק ברשת Akamai Staging - אותה רשת כמו הייצור, רק שדרך זו לא תשפיע על משתמשים אמיתיים. לבדיקה זו, עליך לזייף רשומות DNS במחשב המקומי שלך.
• מהירות הורדה מהירה מאוד דרך הרשת שלהם עבור קבצים סטטיים גדולים, וככל הנראה, כל קבצים אחרים. קובץ מהמטמון ה"קר" מאוחזר פעמים רבות מהר יותר מאשר אותו קובץ מהמטמון ה"קר" של Ali CDN. מהמטמון "החם", המהירות כבר זהה, פלוס מינוס.

בדיקת Ali CDN:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
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
----------
size_download:  5895467 Bytes
speed_download:  525999.000B/s

מבחן Akamai:

root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
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
----------
size_download:  5895467 Bytes
speed_download:  1868699.000B/s

שמנו לב שהמצב בדוגמה למעלה תלוי בגורמים שונים. בזמן כתיבת נקודה זו, הרצתי את המבחן שוב. התוצאות עבור שתי הפלטפורמות היו בערך זהות. זה אומר לנו שהאינטרנט בסין, אפילו עבור מפעילים גדולים וספקי ענן, מתנהג באופן שונה מעת לעת.

לנקודה הקודמת, אוסיף יתרון גדול עבור Akamai: אם עלי מציג הבזקים דומים של ביצועים גבוהים וביצועים נמוכים מאוד (זה חל על Ali CDN, Ali CEN ועלי IPSEC), אז Akamai, בכל פעם, לא משנה איך אני בודק את הרשת שלהם, הכל עובד ביציבות.
ל- Akamai יש כיסוי רב בסין והוא עובד דרך ספקים רבים.

מה לא אהב:

• אני לא אוהב את ממשק האינטרנט ואת הדרך שבה הוא עובד - הוא כל כך גרוע. אבל בעצם מתרגלים לזה (כנראה).
• תוצאות הבדיקה גרועות מהאתר שלנו.
• יש יותר שגיאות במהלך בדיקות מאשר באתר שלנו (זמן פעילות למטה).
• אין לנו שרתי DNS משלנו בסין. מכאן שיש שגיאות רבות בבדיקות עקב פסק זמן של פתרון DNS.
• הם לא מספקים את טווחי ה-IP שלהם -> אין דרך לרשום את הנכונים set_real_ip_from בשרתים שלנו.

מדדים (~3626 ריצות; כל המדדים למעט זמן פעילות, ב-ms; סטטיסטיקה לתקופת זמן אחת):

ספק CDN
חציון
75%
95%
תְגוּבָה
תגובת דף אינטרנט
Uptime
DNS
לְחַבֵּר
חכה
לִטעוֹן
SSL

עלי 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

התפלגות לפי אחוזון (ב-ms):

אחוזון
Akamai
עלי 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

המסקנה היא כזו: אופציית Akamai היא בת קיימא, אך אינה מספקת את אותה יציבות ומהירות כמו הפתרון שלנו יחד עם Ali CDN.

הערות קטנות

כמה רגעים לא נכללו בסיפור, אבל הייתי רוצה לכתוב גם עליהם.

בייג'ין + טוקיו והונג קונג

כפי שאמרתי למעלה, בדקנו מנהרה של IPSEC להונג קונג (HK). אבל בדקנו גם את CEN ל-HK. זה עולה קצת פחות, ותהיתי איך זה יעבוד בין ערים עם מרחק של ~100 ק"מ. התברר כמעניין שהשהייה בין הערים הללו גבוהה ב-100ms מאשר בגרסה המקורית שלנו (לטייוואן). מהירות, יציבות היו גם טובים יותר עבור טייוואן. כתוצאה מכך, עזבנו את HK כאזור גיבוי של IPSEC.

בנוסף, ניסינו להתקין את ההתקנה הבאה:

• סיום לקוחות בבייג'ינג,
• IPSEC ו-CEN לטוקיו,
• ב- Ali CDN השרת בבייג'ינג צוין כמקור.

תכנית זו לא הייתה כל כך יציבה, אם כי מבחינת מהירות היא בדרך כלל לא הייתה נחותה מהפתרון שלנו. לגבי המנהרה, ראיתי נפילות לסירוגין אפילו עבור CEN, שהייתה אמורה להיות יציבה. לכן, חזרנו לתכנית הישנה ופירקנו את הבימוי הזה.

להלן נתונים סטטיסטיים על חביון בין אזורים שונים עבור ערוצים שונים. אולי מישהו יתעניין בזה.

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

מידע כללי על האינטרנט בסין

כתוספת לבעיות באינטרנט שתוארו כבר בהתחלה, בחלק הראשון של המאמר.

• האינטרנט בסין די מהיר בפנים.
  • המסקנה נעשתה על סמך בדיקת רשתות Wi-Fi ציבוריות במקומות שונים שבהם רשתות אלו משמשות מספר רב של אנשים.
  • מהירויות ההורדה וההעלאה לשרתים בתוך סין היו כ-20 Mbit/s ו-5-10 Mbit/s, בהתאמה.
  • המהירות לשרתים מחוץ לסין היא פשוט דלה, פחות מ-1 Mbit/s.
• האינטרנט בסין אינו יציב במיוחד.
  • לפעמים אתרים יכולים להיפתח במהירות, לפעמים לאט (באותה שעה ביום בימים שונים), בתנאי שהתצורה לא תשתנה. ראינו זאת בדוגמה של semrushchina.cn. אפשר לייחס את זה ל-Ali CDN שפועל גם כך וכך בהתאם לשעה ביום, מיקום הכוכבים וכו'.
• אינטרנט סלולרי נמצא כמעט בכל מקום 4G או 4G+. תפסו את זה ברכבת התחתית, במעליות - בקיצור, בכל מקום.
• זהו מיתוס שמשתמשים סינים סומכים רק על דומיינים באזור ה-.cn. למדנו זאת ישירות מהמשתמשים.
  • אתה יכול לראות איך http://baidu.cn הפנה מחדש אל www.baidu.com (גם בסין היבשתית).
• משאבים רבים אכן חסומים. פרימיטיבי: google.com, פייסבוק, טוויטר. אבל משאבים רבים של גוגל עובדים (כמובן, לא בכל ה-Wi-Fi ולא נעשה שימוש ב-VPN (גם בצד הנתב, זה בטוח).
• גם תחומים "טכניים" רבים של תאגידים חסומים פועלים. משמעות הדבר היא שלא תמיד כדאי לחתוך בפזיזות את כל Google ומשאבים אחרים שנראים חסומים. אתה צריך לחפש רשימה כלשהי של דומיינים אסורים.
• יש להם רק שלוש מפעילי אינטרנט עיקריים: China Unicom, China Telecom, China Mobile. יש אפילו קטנים יותר, אבל נתח השוק שלהם לא משמעותי

בונוס: דיאגרמת פתרון סופי

סך הכל

שנה חלפה מאז תחילת הפרויקט. התחלנו עם העובדה שהאתר שלנו סירב בדרך כלל לעבוד כרגיל מסין, ופשוט GET curl לקח 5.5 שניות.

לאחר מכן, עם האינדיקטורים האלה בפתרון הראשון (Cloudflare):

החלטה
Uptime
חציון
75 אחוז
95 אחוז

Cloudflare
86.6
18s
30s
60s

בסופו של דבר הגענו לתוצאות הבאות (סטטיסטיקה של החודש האחרון):

החלטה
Uptime
חציון
75 אחוז
95 אחוז

עלי CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s

כפי שאתה יכול לראות, עדיין לא הצלחנו להשיג 100% זמן פעולה, אבל נמצה משהו, ואז נספר לך על התוצאות במאמר חדש :)

כבוד למי שקרא את כל שלושת החלקים עד הסוף. אני מקווה שמצאת את כל זה מעניין כמו שעשיתי כשעשיתי את זה.

נ.ב. חלקים קודמים

חלק מ- 1
חלק מ- 2

מקור: www.habr.com