הגדרת Cloudflare CDN: מטמון, Workers ואבטחה מלאה

הגדרת Cloudflare CDN: היכן המטמון נשבר ומאין מגיעים שיאי הכשלים

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

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

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

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

מה נותן מטמון מנוהל: תגובתיות, שיעור פגיעות, עמידות

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

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

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

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

מצבי עבודה של CDN: כללי מטמון, דינמיקה, הגנה

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

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

סדר היישום: ממיפוי תעבורה ועד מסירה

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

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

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

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

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

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

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

לאחר המסירה אתם מנהלים את התצורה בעצמכם — אנחנו נשארים בקשר לשינויים ולפיתוח התרשים.

מה נשאר בפרויקט: תצורות, מדיניות, נהלים

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

כל סעיף סוגר סוג אחר של שאלות — מניתוב תעבורה ועד לפעולות התורן בעת תקלה. בהמשך — מה בדיוק נשאר בפרויקט לאחר המסירה.

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

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

ניתוח מקרה: התעבורה גדלה, והכשלים בקצה ירדו

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

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

תוצאה במדדים

שיעור הפגיעות במטמון עלה מ-61% ל-93%, הכשלים בקצה ירדו ל-0.4% — תחילה באותה תעבורה, ואחר כך בתעבורה כפולה. זמן התגובה בקצה התקצר כמעט פי חמישה, והעומס על המקור ירד בערך פי ארבעה: המגבלה הקשיחה הקודמת הפסיקה להיות צוואר הבקבוק.

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

במה שונה מטמון בקצה ממטמון באפליקציה?

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

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

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

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

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

ספקות טכניים נפוצים לפני תחילת העבודה

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

המיתוג יעבור בלי השבתה?

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

היכן גבול האחריות לכללים?

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

מה עם האבטחה של רשת הקצה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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