הגדרת Yandex Cloud CDN: נקודות תורפה בהפצה
הגדרת Yandex Cloud CDN מתחילה לא מהפעלת ההפצה, אלא ממענה לשאלה: מה יקרה למקור כאשר המטמון יפסיק לחפות עליו. כל עוד התעבורה קטנה, ה-proxying נראה כתוספת בחינם — בקשות עוברות לנקודת הנוכחות הקרובה, ושרת המקור עוסק רק במילוי הראשון של המטמון וברענון עותקים מיושנים.
עם גידול הבקשות, הסכמה הזו נשברת בכמה מקומות בבת אחת, וכל נקודת תורפה של המקור נראית בלוגים הרבה לפני שהמשתמש מבחין בהשהיה.
המקור הראשון לבעיות — החמצות מטמון. די בכך שבכתובת של סטטי יהיה פרמטר משתנה, כדי שבמקור לא יבחינו בין גרסאות של המשאב, או כדי שהתשובה תישלח עם כותרת שאוסרת אחסון. כל החמצה היא בקשה נפרדת לאפליקציה, ואפילו שיעור החמצות של אחוזים בודדים הופך זרימה חלקה לעומס שהבקאנד לא תוכנן אליו.
התרחיש השני הרסני יותר: מפולת בקשות בעת החלפות. לאחר העלאה של build חדש או כאשר תוקף המוצרים פג באופן המוני, עשרות אלפי עותקים מתבקשים בו-זמנית, וכל זה מגיע למקור במטח אחד.
עוזרים זמני אחסון שונים לפי סוגי תוכן, מסירת עותק מיושן עם רענון ברקע, וחימום כפוי של כתובות מפתח לפני פתיחת התעבורה.
השלישי — ניתוקי חיבורים ועומס מיותר על האפליקציה. אם הפצת סטטי ודינמיקה עוברות דרך אותו פתח, המקור מבזבז משאבים על הקמת חיבורים במקום עיבוד בקשות, וניסיונות חוזרים לאחר timeout מכפילים ומשלשים את הזרימה. הגבלת פניות בו-זמניות למקור וזמני timeout נכונים מסירים את סוג הכשלים הזה.
נסביר איך זה נסגר ברמת ההגדרה של Yandex Cloud CDN: כללי מטמון, התנהגות בהחמצה והפרדה בין סטטי לדינמיקה.
מה משתנה לאחר ההטמעה: מהירות ועמידות
לאחר העברת התעבורה לרשת ההפצה של Yandex Cloud, בקשות המבקרים מטופלות על ידי הצמתים הקרובים אליהם, והמקור עונה רק על החמצות מטמון.
שיעור הפגיעות נקבע על ידי מדיניות: עבור סטטי — תמונות, סגנונות, סקריפטים, גופנים — הוא מגיע ל-85–95%, עבור עמודים עם התאמה אישית הוא נשאר באזור 50–70%.
ככל שמפתח המטמון מתאר ביתר דיוק את וריאנט המשאב — פרמטרי query, גרסאות שפה ואזור — כך גבוהות הפגיעות וכך קטן הסיכון למסור גרסאות שונות של אותו עמוד.
זמן התגובה של העמוד יורד פי כמה: סטטי מגיע מצומת קרוב למבקר, חיבור מאובטח נוצר בפרימטר, ולעתים קרובות הבקשה כלל לא מגיעה למקור. בדוח זה נראה לא לפי הממוצע, אלא לפי האחוזון ה-95 — דווקא הוא מראה שלא בקשה בודדת מאטה, אלא הזנב של ההתפלגות.
השינוי הגדול ביותר הוא בסוג הכשלים. המקור מפסיק להיות נקודת כשל יחידה: שיא התעבורה נבלם בפרימטר, ולא נתקע בתקרת החיבורים והמעבד שלו. אם המקור אינו זמין או עונה לאט, הפרימטר מוסר תוכן שנשמר קודם במטמון — המבקר רואה עמוד במקום שגיאה.
הזמינות בעומס שיא מפסיקה להיות תלויה ברגע: מבצע מכירות, הכרזה, פרסום אצל ערוץ גדול — התעבורה גדלה פי כמה, וזמן התגובה נשאר באותו סדר גודל. פריקת העומס מהמקור נמדדת ישירות: כמה בקשות הגיעו אליו מול המספר הכולל.
פגיעות במטמון, זמן תגובה ושיעור שגיאות נלקחים לפני ואחרי ההחלפה — ההשפעה צריכה להיראות במספרים, לא במילים.
תרחישי הפצה: מטמון בקצה, פרוקסי, היברידי
תרחיש ההפצה ב-Yandex Cloud CDN קובע איזה חלק מהבקשות מגיע למקור ואיזה נסגר בצומת הקרוב למשתמש. הבחירה נעשית לא 'לפי הטעם', אלא לפי פרופיל התעבורה: חלק הסטטי, תדירות העדכון, דרישות פרטיות והשהיה מותרת של הבית הראשון.
שלוש תצורות עבודה מכסות כמעט את כל המשימות, ובתוך אותו דומיין משלבים אותן לפי נתיבים או לפי סוגי תוכן. התצורה ההיברידית מסירה מהמקור את רוב התעבורה ובמקביל אינה דורשת זמן חיים אחיד של תשובה עבור כל הדומיין.
| וריאנט | מתי מתאים | מגבלות |
|---|---|---|
| מטמון בקצה | תמונות, סקריפטים, גופנים, קבצי build: עדכון בקבוצות, אין דרישות קשיחות לעדכניות | התיישנות עד לביטול; במקרה של מפתח מטמון שגוי, חלק מהבקשות יקבלו תשובה של אחר |
| פרוקסי בקשות | אזור אישי, תשלום, רשימות אישיות: התשובה נבנית עבור משתמש מסוים | אין מטמון — כל השיא עובר למקור, ההשהיה שווה למרחק אליו |
| תצורת הפצה היברידית | אתר משולב: סטטי דרך הקצה, דינמיקה ישירות, חלק מהנתיבים נשמר במטמון לפי כללים | כללי מטמון, ביטול וכותרים יש לתאם עם האפליקציה |
כללי מטמון נכתבים בנפרד עבור כל קבוצת נתיבים: זמן חיים של תשובה, מפתח מטמון עם או בלי התחשבות בפרמטרי query, עקיפת מטמון עבור בקשות מאומתות ו-cookies, וביטול כפוי בעת העלאת release. כך סטטי חי בקצה שעות, וכרטיס מוצר לא מוסר מחיר של מוצר אחר.
איך עוברת ההטמעה: שלבים ונקודות בדיקה
הגדרת Yandex Cloud CDN היא לא 'להפעיל האצה', אלא העברת נקודת המפגש של התעבורה מהמקור לגבול הרשת. העבודה מתבצעת ברצף: תחילה מתעדים מה המקור באמת מוסר, לאחר מכן בונים תצורה, בודקים אותה בסביבת production ורק אז מעבירים את המשתמשים.
- ביקורת המקור. בודקים אילו סוגי תוכן השרת מוסר, אילו כותרות מטמון הוא מציב, כיצד הוא עונה בשגיאות ובבקשות עם פרמטרים. כאן גם מבררים מה אסור לשמור במטמון — אחרת ההפצה תתחיל למסור נתונים מיושנים.
- תצורת הפצה. מפרידים דומיינים ונתיבים: מה עובר דרך הרשת, מה נשאר במקור, אילו בקשות עוקפות את המטמון ולפי איזה סימן.
- הגדרת מטמון ותעודות. זמן חיים לפי סוגי תוכן, מפתח מטמון, כללי איפוס; תעודה בגבול, שרשרת אמון, הפניה לפרוטוקול מאובטח עבור כל תתי-הדומיינים.
- בדיקת מטמון. שיעור פגיעות, עדכון לאחר פרסום, התנהגות כאשר המקור אינו זמין — עבור כל כלל מריצים בקשות בדיקה לפני ההחלפה.
- החלפת תעבורה. מעבירים בהדרגה: תחילה חלק מהבקשות או דומיין לא עדיפותי, עוקבים אחרי שיעור השגיאות וזמן התגובה, ושומרים על אפשרות חזרה להפצה ישירה.
- מסירה. התצורה נשמרת כקוד, מתוארים תרחישי תורנות — לעדכן תוכן, לראות סטטיסטיקה, להסיר עומס מהמקור בעת תקלה.
נקודות בדיקה — לאחר הביקורת, לפני ההחלפה, ויממה לאחריה: בהן רואים שהתצורה מחזיקה את העומס ואינה שוברת תרחישים קיימים.
מה נשאר אצלכם: תצורות, תרשימים, נהלים
את כל הארטיפקטים מעבירים ב-repository שלכם ובתיעוד הפנימי — לא בהתכתבות ולא בהערות אישיות של מהנדס. חודש לאחר ההפעלה, משמרת תורנות צריכה לדעת להרים את ההפצה ולהסביר כל החלטה, בלי לחפש את המחבר. לכן רשימת הפלט קבועה, וכל סעיף נבדק בקבלה.
- תצורות משאבים של Yandex Cloud CDN: קבוצות origin, מקורות, בדיקות זמינות, timeouts והצמדה ל-load balancer — בקבצים דקלרטיביים עם ניהול גרסאות ב-repository.
- כללי מטמון: זמני חיים לפי סוגי תוכן, מפתחות מטמון תוך התחשבות בפרמטרים של שורת query ובכותרות, התנהגות נפרדת לבקשות מאומתות.
- מדיניות גישה: חתימת בקשות למקור, הגנה מפני hotlink, הגבלות לפי referer ו-geo, כללי עקיפת מטמון לבדיקות דיבוג.
- תרשים הפצה — מסלול הבקשה מהלקוח דרך נקודת הנוכחות ועד למקור, עם נקודות מטמון, אזורי כשל ולוגיקת החלפה.
- תיעוד TLS: שרשרת תעודות, סדר הנפקה וחידוש, הצמדה לדומיינים ודרך החלפה חירום עם פקיעה.
- נהל משמרת תורנות: אילו מדדים לבדוק, מה נחשב לאירוע, ספי תגובה, סדר ביטול מטמון וחזרה לתצורה קודמת.
מקרה בוחן: איך פרקו עומס מהמקור בלי לכתוב מחדש את האתר
את פלטפורמת ההפצה הרכיבו על Yandex Cloud, אך תצורת המטמון המקורית פעלה נגד המקור. המקור מסר גם סטטי וגם API: כללי המטמון היו כלליים, פרמטרי query נכנסו למפתח, ולכן סקריפטים זהים נחשבו לאובייקטים שונים.
בשעות מבצע, המקור קיבל כמעט את כל התעבורה, זמן התגובה עלה משבריר שנייה לכמה שניות, וחלק מהבקשות הסתיימו בשגיאה.
התוכן חולק למחלקות ונכתבו כללי מטמון בפרויקט. סטטי עם גרסאות מוסר בזמן אחסון ארוך, עמודים ונתונים — בקצר, ותשובות API אישיות עוברות מחוץ למטמון. מהמפתח הוסרו פרמטרים מיותרים, והושארו אלו שמשפיעים על התוכן, והדחיסה הועברה לקצה — המקור הפסיק לבזבז משאבים על מה שכבר נמצא ברשת ההפצה.
חזרה למקור בשעות שיא
למקור נוספה פלטפורמת גיבוי, והוגבלה תדירות הפניות מרשת ההפצה, כדי שזינוק החמצות לא ייפול בזרימה אחת. כותרות ניהול ותגיות גרסה נוצרות על ידי ה-build עצמו: לאחר release התוכן החדש נמשך פעם אחת, ולא בכל בקשה.
תוצאה בגדלים מדידים
שיעור התשובות מרשת ההפצה עלה מכ-55% ל-93%, ועומס השיא על המקור ירד פי ארבעה. זמן התגובה של סטטי התקצר בערך פי 2.5, והכשלים בשעות שיא נעלמו: קודם היו כמה אפיזודות למבצע, עכשיו אפס. התצורה מחזיקה זינוק גבוה פי 3-4 מהרגיל בלי שינויים באפליקציה — האתר לא נכתב מחדש.
במה שונה רשת קצה מ-load balancer?
ה-load balancer עובד בתוך המתאר שלכם: מקבל חיבור, בוחר backend חי לפי בדיקות זמינות ומפזר זרימות בין אזורים. תחום האחריות שלו — פיזור בקשות ועמידות האפליקציה בכשלים, אבל כל בקשה בכל זאת מגיעה לשרת, כולל בקשות לסטטי.
רשת הקצה פותרת משימה אחרת — מסירת סטטי ותשובות שמורות במטמון קרוב יותר למבקר. הנקודה הקרובה למשתמש מקבלת את החיבור, מסיימת TLS בצד שלה ומוסרת תשובה מוכנה מהמטמון, בלי להעלות בקשה לשרת המקור (origin). פגיעה במטמון מטופלת בגבול, והחמצה עוברת למתאר.
מטמון מול איזון עומסים — אלו גם מדדי יעילות שונים. ב-load balancer מסתכלים על שיעור הבדיקות המוצלחות ועל אחידות פיזור העומס, וברשת הקצה — על שיעור הפגיעות במטמון ועל מהירות מסירת הסטטי.
כלי אחד לא מחליף את האחר: ה-load balancer לא מחזיק תוכן אצל המשתמש, ורשת הקצה לא עוקבת אחרי בריאות ה-backends.
בפועל בונים אותם לשרשרת: התעבורה מגיעה לרשת הקצה, היא מוסרת סטטי ותשובות הניתנות לשמירה במטמון, ואת השאר מעבירה ל-load balancer, שמפזר את הבקשות בין instances חיים. ההגדרות המרכזיות כאן — כללי מטמון לפי סוגי תוכן, זמן חיים של אובייקטים וביטול נכון לאחר release. טעות בהן נותנת או סטטי מיושן אצל המבקרים, או מעבר מלא של התעבורה לשרת המקור וגידול בהשהיות.
אנחנו מפרידים בין התפקידים בשלב התכנון: תחילה מעריכים איזה חלק מהתעבורה בכלל ניתן לשמור במטמון, לאחר מכן מגדירים כללים בגבול, ורק אחר כך נוגעים בתצורת האיזון. כך הגבול מסיר עומס, וה-load balancer עוסק במה שהוא נועד לו.
שאלות טכניות נפוצות לפני ההטמעה
לפני ההתחלה בדרך כלל עולות אותן שאלות — הן נוגעות לא לפונקציונליות, אלא לאיך שהשכבה החדשה תסתדר עם תשתית קיימת. להלן תשובות קצרות לכל סעיף; אם המצב שלכם שונה, נבחן בנפרד.
כבר הגדרנו כללי מטמון — האם נצטרך לכתוב אותם מחדש?
לא, אנחנו יורשים אותם. הכותרות שה-origin מוסר נשארות שכבת בסיס, ומעליהן מוסיפים רק את הנדרש: TTL ארוך לסטטי, עקיפת מטמון ל-API ולאזורים עם אימות. עבור כל כלל קובעים עדיפות, כדי שכלל על נתיב לא יתנגש עם כלל על סוג קובץ.
איך לשנות את כתובת ה-origin בלי השבתה למבקרים?
מקור חדש עולה לצידו ונבדק בבקשות זמינות לפני ההחלפה. לאחר מכן מעבירים את התעבורה ב-TTL קצר, ואת הישן מחזיקים כגיבוי חם — החזרת הרשומה מאפשרת חזרה בתוך דקות, בלי להגדיר מחדש את המבקרים בצד Yandex Cloud.
איך הלקוח מקבל גרסה עדכנית של העמוד אם התוכן עודכן?
באמצעות ביטול: לפי כתובת מדויקת, לפי מסכת קבצים או לפי קבוצת אובייקטים. סטטי נוסף גם עם גרסאות בכתובת — בעת release הקישורים משתנים, ומהמטמון לא מגיע build ישן. עבור גרסאות דחוסות ומובייל מתחשבים בייצוגים שונים של אותה כתובת.
מה לעשות עם תעודות — להנפיק חדשות או לחבר משלכם?
אפשריות שתי האפשרויות: הנפקה מנוהלת עם חידוש אוטומטי לדומיין ולתתי-דומיינים, או חיבור התעודה שלכם. המפתח הפרטי במקרה זה לא עוזב את אזור האחריות שלכם, ותוקף התעודה נשלט בנפרד, כדי שהחידוש לא יהיה תלוי ב-release.
ה-origin סגור לגישה חיצונית — השכבה תוכל למשוך ממנו?
כן. את המקור פותחים רק לכתובות של השכבה, ופניות אחרות נדחות — אי אפשר להגיע ישירות לעקוף את המטמון. עבור אובייקטים פרטיים מנפיקים קישורים חתומים עם זמן חיים מוגבל.
נדון בתצורת הפצת התוכן שלכם
כדי שהניתוח יהיה ענייני ולא כללי, התחילו מההקשר: היכן נמצא התוכן, מי הצרכנים שלו ומה קריטי עבורכם — מהירות מסירה, עלות תעבורה, עמידות בכשלים של הפלטפורמה.
לפי הנתונים האלה המהנדסים שלנו יקבעו אילו קבוצות מטמון כדאי להקים, איך להגדיר כותרות ניהול מטמון ב-origin והאם נדרש מתאר נפרד לדינמיקה. להלן — מה לשלוח כדי שנחזור עם הערכה ותוכנית עבודה להפצה דרך Yandex Cloud CDN.
- רשימת דומיינים ותתי-דומיינים שעבורם מתוכננת ההפצה, עם ציון הראשי והמשניים.
- תיאור origin: bucket סטטי, שרת web משלכם או כמה מקורות, וכיצד מתפזרת ביניהם התעבורה.
- נפח התוכן ופרופיל העומס: חלק הסטטי והדינמיקה, סוגי קבצים, נפח מסירה משוער ביממה וזינוקי שיא.
- גיאוגרפיה של הקהל ודרישות TLS: תעודות משלכם או הנפקה בצד השירות, והאם נדרשת הפניה כפויה לפרוטוקול מאובטח.
- כללי עדכון תוכן: באיזו תדירות משתנים הקבצים, האם נדרש ניקוי ממוקד של מטמון לפי תגיות, ובאיזו מהירות הגרסה החדשה צריכה להיות גלויה.
- תצורת ההגנה והגישות הנוכחית: מי מנהל את אזור ה-DNS, אילו תפקידים נדרשים למהנדסים שלנו ומה נשאר בשליטתכם.
- מגבלות וכל העדפות: זמן תגובה מותר, דרישות למעבר למקור גיבוי ואופן העבודה כאשר ה-origin אינו זמין.
תארו את המשימה בצורה חופשית — גם אם חלק מהנתונים עדיין לא ידוע, זה מספיק כדי להתחיל. נשאל שאלות הבהרה לפי סדר הניתוח, נתעד את תצורת ההפצה ונחזור עם הערכה ותוכנית עבודה: שלבי הגדרה, נקודות בדיקה וקריטריונים לקבלה.