WEBVTT

00:00:00.000 --> 00:00:03.240
אתה מערך את האתר במקום אחד, נניח מרכז נתונים בווירג'יניה.

00:00:03.360 --> 00:00:08.280
זה עובד מצוין עבור לקוחות בניו יורק או בשיקגו, אבל מה לגבי מישהו בתוקיו, לונדון או סידני?

00:00:08.440 --> 00:00:14.360
בכל פעם שאותו אדם מבקר באתר שלך, הבקשה שלא צריכה לחצות אוקיינוסים ויבשות רק כדי להגיע לשרת שלך.

00:00:14.500 --> 00:00:19.900
כל תמונה, כל תעינת דף, כל קריאת API עושים את אותו מסע ארוך, והעיכוב הזה מצטבר במהירות.

00:00:19.900 --> 00:00:26.480
למעשה, מחקרים מראים שאפילו עיכוב של שנייה אחת בתעינת דף יכול לעלות לך בהמרות ולהבריח מבקרים מתוסכלים.

00:00:26.620 --> 00:00:30.700
אבל הנה העניין, מה קורה כשהאתר שלך הופך ויראלי או שרשת בוטים החליטה לתקוף?

00:00:30.820 --> 00:00:35.040
השרת היחיד שלך בווירג'יניה סופג מכה אנושה, הוא מועט, ואף עלול לקרוס לחלוטין.

00:00:35.180 --> 00:00:36.580
אתה נתקע ללא תוכנית גיבוי.

00:00:36.760 --> 00:00:41.620
אפשר לפתור את בעיית הזמינות על ידי יצירת עותקים של האתר באזורים שונים, בתוקיו, לונדון או סאופולו.

00:00:41.620 --> 00:00:44.140
זה עוזר. אבל עכשיו יש לך בעיה חדשה.

00:00:44.280 --> 00:00:46.160
איך שולחים כל מבקר למיקום הנכון?

00:00:46.300 --> 00:00:49.380
אתה לא רוצה שמישהו מיפן יגיע בטעות לשרת שלך בארצות הברית.

00:00:49.540 --> 00:00:53.820
אתה זקוק לדרך חכמה לניתוב תעבורה, וזה בדיוק המקום שבו Azure Front Door נכנס לתמונה.

00:00:53.980 --> 00:00:56.920
הכירו את שוטר התנועה הגלובלי, זהו Azure Front Door.

00:00:57.060 --> 00:01:00.900
תחשבו על Azure Front Door כשוטר תנועה גלובלי, לא רק אחד בצומת בודד,

00:01:00.900 --> 00:01:03.620
אלא אלפים מהם שמוצבים בצמתים מרכזיים ברחבי העולם.

00:01:03.780 --> 00:01:07.120
בכל פעם שמישהו מבקר באתר שלך, השוטר הקרוב ביותר ניגש, ואומר,

00:01:07.280 --> 00:01:07.760
אתה בתוקיו.

00:01:07.880 --> 00:01:10.000
החנות המהירה ביותר עבורך נמצאת בסינגפור.

00:01:10.140 --> 00:01:11.260
תן לי לקחת אותך לשם.

00:01:11.400 --> 00:01:14.040
אז במה זה שונה ממאזן עומסים, לוד בלנסר, רגיל.

00:01:14.220 --> 00:01:18.500
רוב מאזני העומסים עובדים בשכבה 4, ומסתכלים על כתובות IP ופורטים כדי לנתב תעבורה.

00:01:18.500 --> 00:01:22.380
זה בסדר לצרכים בסיסיים, אבל Azure Front Door עובד בשכבה 7,

00:01:22.660 --> 00:01:25.380
כלומר הוא מבין תעבורת HTTP ו-HTTPS.

00:01:25.380 --> 00:01:29.100
הוא יכול להסתכל על הכתובת שהוא קלדה, לבדוק את כותרות הדפדפן,

00:01:29.340 --> 00:01:33.440
לראות איזה תוכן מבוקש, ולקבל החלטות ניתוב חכמות על סמך כל אלה.

00:01:33.540 --> 00:01:36.460
במקום רק לומר, האב הזה הולך לשרת ההוא,

00:01:36.680 --> 00:01:41.280
Front Door יכול לומר, הבקשה עלי API הולכת למד BACK-END בארצות הברית,

00:01:41.560 --> 00:01:44.500
אבל הבקשה על התמונות הולכת לעותק השמור בטוקיו.

00:01:44.660 --> 00:01:47.680
עכשיו, הנה מה שמאפשר את כל זה מאחורי הקלעים.

00:01:47.680 --> 00:01:50.960
Azure Front Door פועל על הרשת הגלובלית של מייקרוסופט,

00:01:50.960 --> 00:01:55.840
עם מעל 210 נקודות נוכחות ביותר ממינוס 130 מטרופולינים ברחבי העולם.

00:01:56.020 --> 00:01:58.560
תחשבו על כל נקודת נוכחות כעל עמדת תנועה קטנה,

00:01:58.820 --> 00:02:02.360
משרד מקומי בכל עיר מרכזית שיכול לטפל בבקשה הראשונית במהירות.

00:02:02.540 --> 00:02:04.180
כאשר משתמש מבקר באתר שלך,

00:02:04.320 --> 00:02:08.280
הוא מתחבר לנקודה הקרובה ביותר במקום לנסוע כל הדרך לשרת המקור שלך בווירג'יניה.

00:02:08.420 --> 00:02:12.760
הנקודה הזו מנתבת את הבקשה שלו דרך הרשת הפרטית של מייקרוסופט אל השרת האחורי שלך.

00:02:12.760 --> 00:02:15.500
זה חשוב, כי האינטרנט הציבורי הוא בלתי צפוי.

00:02:15.620 --> 00:02:18.620
התעבורה שלך עשויה לעבור טרייסר תחנות ברשתות שונות,

00:02:18.820 --> 00:02:21.400
כשכל אחת מוסיפה השיה ואובדן נתונים פוטנציאלי.

00:02:21.500 --> 00:02:23.040
הרשת הפרטית של מייקרוסופט,

00:02:23.160 --> 00:02:26.800
לעומת זאת, היא רשת מהירה שמחברת את מרכזי הנתונים שלהם ישירות.

00:02:27.000 --> 00:02:30.460
לכן, ברגע שהבקשה שלך מגיעה לנקודת הנוכחות הקרובה ביותר,

00:02:30.660 --> 00:02:32.700
המשך המסע מתבצע על כביש מהיר ואמין.

00:02:32.840 --> 00:02:34.640
אתה מקבל זמני טעינה מהירים יותר,

00:02:34.640 --> 00:02:37.620
השיה נמוכה וחוויה טובה יותר למשתמשים בכל מקום,

00:02:37.820 --> 00:02:39.780
בין אם הם בטוקיו, לונדון או סאו פאולו.

00:02:39.880 --> 00:02:41.540
וכל זה קורה באופן אוטומטי,

00:02:41.640 --> 00:02:43.960
בלי שהמבקרים שלך ידעו אפילו שזה קיים.

00:02:44.160 --> 00:02:45.540
שלוש שכבות של עמידות,

00:02:45.800 --> 00:02:47.140
כך AFD נשאר פעיל.

00:02:47.300 --> 00:02:48.820
עכשיו, אולי אתם חושבים,

00:02:48.960 --> 00:02:51.300
הרעיון של שוטר תנועה גלובלי נשמע נהדר,

00:02:51.540 --> 00:02:53.200
אבל מה קורה אם השוטר עצמו קורס?

00:02:53.320 --> 00:02:56.400
אם Azure Front Door הוא נקודת הכניסה היחידה לאפליקציה כולה,

00:02:56.400 --> 00:02:58.360
זו נקודת קשל מרכזית גדולה, נכון.

00:02:58.520 --> 00:02:59.720
מייקרוסופט חשבה על זה.

00:02:59.840 --> 00:03:01.940
הם בנו שלוש שכבות של עמידות בפרונט דור,

00:03:02.140 --> 00:03:03.440
כך שהוא כמעט אף פעם לא מושבט.

00:03:03.520 --> 00:03:04.720
תן לי להסביר לך עליהן.

00:03:04.860 --> 00:03:06.980
שכבה ראשונה, החזית, פרונט אנד,

00:03:07.140 --> 00:03:09.920
זוכרת 210 נקודות הנוכחות שציינתי.

00:03:09.920 --> 00:03:12.660
כל אחת מהן היא עמדת תנועה עצמאית לחלוטין.

00:03:12.800 --> 00:03:16.420
נקודות אלו נמצאות ביותר מ-130 מיקומים ברחבי העולם,

00:03:16.420 --> 00:03:19.980
ופועלות בתוך מרכזי הנתונים של מייקרוסופט ומתקני שותפים.

00:03:20.140 --> 00:03:22.520
כל נקודה כוללת מספר ערונות שרתים

00:03:22.520 --> 00:03:25.380
עם בקרים בקצה המתפקדים כמאזן או מסי מובנה.

00:03:25.700 --> 00:03:27.660
אם שרת אחד בתוך נקודה כושל,

00:03:27.920 --> 00:03:31.060
הבקר מנתב את התעבורה לשרת תקין בתוך אותה נקודה.

00:03:31.060 --> 00:03:32.700
ואם נקודה שלמה מושבטת,

00:03:32.880 --> 00:03:34.940
כאן נכנס לפעולה ניתוב Anycast IP.

00:03:35.100 --> 00:03:38.800
הבקשה של המבקר שלך מנותבת אוטומטית לנקודה הקרובה ביותר הבאה.

00:03:38.900 --> 00:03:41.360
ללא הפרעה וללא התערבות ידנית, זה פשוט קורה.

00:03:41.480 --> 00:03:43.340
שכבה שנייה, שכבת הגיבוי, Fallback.

00:03:43.480 --> 00:03:45.300
אבל מה קורה אם נקודה אחת עמוסה מדי?

00:03:45.420 --> 00:03:48.920
נניח שיש זינוק עצום בתעבורה או שמספר נקודות באזור מושבטות בבת אחת.

00:03:49.000 --> 00:03:51.080
הנקודות הנותרות עלולות לא לעמוד באומס.

00:03:51.260 --> 00:03:53.380
זה הרגע שבו שכבת הגיבוי נכנסת לתמונה.

00:03:53.380 --> 00:03:55.880
זהו סט נפרד של נקודות, עשרות מהן, לא מאות,

00:03:56.020 --> 00:03:57.900
שמריצות את אותה תוכנה והארכיטקטורה בדיוק.

00:03:58.060 --> 00:04:01.300
הן נמצאות רק במרכזי הנתונים של מייקרוסופט, לא במתקני שותפים.

00:04:01.420 --> 00:04:05.260
כאשר נקודת חזית צריכה להפחית עומס, היא מעבירה בקשות לשכבת הגיבוי הזו.

00:04:05.380 --> 00:04:07.780
אותו תהליך זיכרון מתמון, אותו ניתוב, אותה הבטחה.

00:04:07.880 --> 00:04:09.760
המבקרים שלך לעולם לא יבחינו בהבדל.

00:04:09.880 --> 00:04:12.600
הם אולי יקבלו את התוכן מעט לאט יותר, אבל הם עדיין יקבלו אותו.

00:04:12.600 --> 00:04:14.480
השכבה השלישית, מגן התעבורה.

00:04:14.660 --> 00:04:15.800
זהו הגוף המפקח.

00:04:15.920 --> 00:04:19.440
תחשבו על זה כעל מרכז פיקוד גלובלי שמשקיף על כל רשת הפרונט דור.

00:04:19.440 --> 00:04:23.220
הוא מנטר דפוסי תעבורה, רמות אומס ותקינות בכל נקודות הנוכחות, פופס.

00:04:23.340 --> 00:04:27.880
כשהוא מזהה שנקודות מסוימות הופכות לעמוסות מדי, הוא לא רק מחכה ששכבת הגיבוי תיכנס לפעולה.

00:04:27.880 --> 00:04:32.680
הוא מסיד תעבורה באופן יזום על ידי עדכון האופן שבו הדי-נס פותר את נקודת הקצה של הפרונט דור שלכם.

00:04:32.780 --> 00:04:38.000
הוא יכול לעבור מכתובת אייפי גלובלית מסוג אניקסט לכתובת אזורית ולהעביר לקוחות לקבוצות אחרות של נקודות נוכחות לחלוטין.

00:04:38.120 --> 00:04:40.080
הוא יכול אפילו לחצות יבשות במידת הצורך.

00:04:40.220 --> 00:04:43.080
מגן התעבורה הוא מה שגורם לפרונט דור להרגיש כמעט קסום.

00:04:43.080 --> 00:04:47.360
הוא מבצע אופטימיזציה מתמדת מאחורי הקלעים ומתאים נתיבים עוד לפני שנוצרות בעיות.

00:04:47.460 --> 00:04:49.080
כעת, עליי לציין מה שהוא כאן.

00:04:49.240 --> 00:04:52.740
באוקטובר 2025, Azure Front Door סבל מהשוות המשמעותית.

00:04:52.900 --> 00:04:59.800
שינוי בהגדרות דילג על אימותי בטיחות וגרם לי בעיות נרחבות בMicrosoft 365, בסבוקס לייב ובאלפי אתרי לקוחות.

00:04:59.900 --> 00:05:01.200
מייקרוסופט למדה מכך.

00:05:01.200 --> 00:05:04.380
הם הסירו את כל העיבוד הסינכרוני מצינור ההגדרות.

00:05:04.560 --> 00:05:07.060
כעת, כל נתיב קוד נבדק במהלך הפריסה.

00:05:07.060 --> 00:05:12.740
הם צמצמו את זמן החזרה לאחור, רולבק, מממינוס 4 שעות לשעה אחת, והם מכוונים למד מינוס 10 דקות עד מרץ 2026.

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

00:05:18.200 --> 00:05:20.020
העניין הוא שאף מערכת אינה מושלמת.

00:05:20.020 --> 00:05:26.060
אך הארכיטקטורה התלת שכבתית של Front Door תוכננה לשרוד הפסקות אזוריות, עומסי תעבורה ואפילו כמה תאויות בהגדרות.

00:05:26.160 --> 00:05:28.180
עבור רוב היישומים, זה יותר ממספיק.

00:05:28.340 --> 00:05:35.280
עבור מערכות קריטיות באמת, ניתן לשלב את Azure Traffic Manager לפני הפרונט דור כי נתיב חירום, אך זהו נושא מתקדם ליום אחר.

00:05:35.420 --> 00:05:36.400
איך הוא מנתב תעבורה?

00:05:36.640 --> 00:05:38.620
ניתוב הוא קבוצות מקור, Origin Groups.

00:05:38.700 --> 00:05:45.240
אז יש לנו שוטר תעבורה גלובלי עם מעל 210 עמדות ושלוש שכבות גיבוי, אבל איך הוא באמת מחליט לאן לשלוח כל מבקר?

00:05:45.240 --> 00:05:47.180
כאן נכנסות לתמונה קבוצות המקור.

00:05:47.340 --> 00:05:50.400
קבוצת מקור היא בעצם אוסף של שרתי Hey Back End שלכם.

00:05:50.500 --> 00:05:55.100
תחשבו על זה כעל רשימת החנויות שלכם, המקומות האמיתיים שבהם האתר או האפליקציה שלכם פועלים.

00:05:55.260 --> 00:05:58.500
ייתכן שיש לכם שרת אחד בצפון אמריקה, אחד באירופה ואחד באסיה.

00:05:58.620 --> 00:06:00.240
כולם נכנסים לאותה קבוצת מקור.

00:06:00.400 --> 00:06:03.040
כעת, פרונט דור לא סתם שולח תעבורה לכולם בעיוורון.

00:06:03.160 --> 00:06:04.700
הוא בודק ללא הרף אם הם פעילים.

00:06:04.920 --> 00:06:06.800
זה נקרא בדיקת תקינות, Health Probe.

00:06:06.800 --> 00:06:15.400
בכל כמה שניות, כל נקודת נוכחות של פרונט דור שולחת פינג לשרתים שלכם על ידי פנייה לנתיב ספציפי, בדרך כלל לשורש האתר או לנקודת קצה יהודית לתקינות כמו Health.

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

00:06:21.400 --> 00:06:25.660
זה כמו שוטר תנועה שבודק עם חנות באמת פתוחה לפני שהוא מכניס אליה לקוחות.

00:06:25.800 --> 00:06:30.640
אבל ברגע שיש לך מספר שרתים תקינים, השאלה היא איזה מהם צריך לקבל את המבקר.

00:06:30.640 --> 00:06:37.380
פרונט דור משתמש בשלושה גורמים כדי להחליט עדיפות, זמן השעיה ומשקל, והם פועלים יחד בסדר מסוים.

00:06:37.560 --> 00:06:38.760
ראשית, העדיפות.

00:06:38.900 --> 00:06:41.620
ניתן להגדיר שרת אחד כראשי ואחר כגיבוי.

00:06:41.760 --> 00:06:44.960
קבעה את הראשי לעדיפות אחת ואת הגיבוי לעדיפות שתיים.

00:06:45.100 --> 00:06:47.760
בתנאים רגילים, כל התעבורה מגיעה לשרת הראשי.

00:06:47.840 --> 00:06:50.280
כך שאם הראשי נופל, התעבורה עוברת לגיבוי.

00:06:50.420 --> 00:06:55.580
פשוט, נכון, זה נהדר עבור הגדרות פעיל סביל שבהן אתה רוצה שאזור אחד יטפל בהכל, אלא אם כן הוא נכשל.

00:07:00.640 --> 00:07:06.400
אם יש אותה עדיפות, פרונט דור שולח תעבורה לזה עם זמן ההשעיה הנמוך ביותר, זמן התגובה המהיר ביותר ממקום המבקר.

00:07:06.500 --> 00:07:11.740
לכן, משתמש בלונדון ינותב לשרת האירופי שלך, בעוד שמשתמש בתוקיו ינותב לשרת האסיאטי.

00:07:11.860 --> 00:07:14.960
יש גם הגדרת רגישות, כברירת מחדל 50 מילי שניות.

00:07:15.140 --> 00:07:20.180
אם שני שרתים נמצאים בטווח של 50 מילי שניות זה מזה, פרונט דור מחשיב אותם למהירים באותה מידה.

00:07:20.180 --> 00:07:23.520
זה מונע מעבר מתמיד בין שרתים שהם בעצם באותה מהירות.

00:07:23.520 --> 00:07:26.360
וכאשר זמן ההשעיה זהה, כאן נכנס המשקל לתמונה.

00:07:26.520 --> 00:07:29.260
ניתן להקצות משקלים כדי לפצל את התעבורה בין שרתים.

00:07:29.380 --> 00:07:31.860
נניח שאתה רוצה לבדוק גרסה חדשה של האפליקציה שלך.

00:07:31.980 --> 00:07:35.200
תוכל לתת לשרת הנוכחי שלך משקל של 90 ולחדש משקל של 10.

00:07:35.420 --> 00:07:39.800
זה אומר שבערך 9 מתוך 10 מבקרים ילכו לגרסה הישנה ואחד מתוך 10 ילך לחדשה.

00:07:39.800 --> 00:07:45.280
זה מושלם להפצות הדרגתיות, בדיקות A, B או סתם איזון או מסים בין שרתים בעלי קיבולת שונה.

00:07:45.420 --> 00:07:46.620
הנה הדבר החשוב.

00:07:46.620 --> 00:07:48.440
כל זה קורה באופן אוטומטי.

00:07:48.560 --> 00:07:52.080
אתה מגדיר את קבוצת המקור פעם אחת, ופרונט דור מטפל בשאר.

00:07:52.180 --> 00:07:57.080
הוא בוחן את השרתים שלך, מודד זמן השעיה, מכבד עדיפויות ומפיץ תעבורה על סמך משקל.

00:07:57.220 --> 00:08:00.820
והוא עושה את כל זה בקצה לפני שהבקשה בכלל מגיעה לבקנד שלך.

00:08:00.820 --> 00:08:05.080
זה אומר שהשרתים שלך לא צריכים להבין מאיפה הגיעה התעבורה או איך לנתב אותה.

00:08:05.160 --> 00:08:08.800
הם פשוט מגישים תוכן, הבטחה בקצה, ה-WF ומעבר לו.

00:08:08.920 --> 00:08:10.540
אז עכשיו בואו נדבר על הבטחה.

00:08:10.540 --> 00:08:16.700
מכיוון שפרונט דור יושב ממש בקצה הרשת של מייקרוסופט, זה המקום המושלם לעצור התקפות לפני שהן בכלל מגיעות לשרתים שלך.

00:08:16.840 --> 00:08:19.720
תחשוב על זה כעל נקודת בידוק ביטחוני בכניסה לבניין.

00:08:19.880 --> 00:08:22.240
כל מי שרוצה להיכנס חייב לעבור דרכה קודם.

00:08:22.240 --> 00:08:28.460
נקודת ביקורת זו נקראת חומת אש של יישומי אינטרנט או WF, והיא מובנית בתוך פרונט דור סטנדרד ופרימיום כ-1.

00:08:28.580 --> 00:08:31.140
היא חוסמת התקפות אינטרנט נפוצות באופן אוטומטי.

00:08:31.140 --> 00:08:42.720
דברים כמו SQL Injection, שבו תוקף מנסה להחדיר פקודות מסד נתונים זדוניות לשדה תופס, או Cross-Site Scripting, שבו מחדירים סקריפטים לדפים שלכם, או התקפות DDOS, שבהן מנסים להציף את השרתים שלכם בתעבורה.

00:08:42.720 --> 00:08:47.360
ה-WF קולט את כל זה בקצה, Edge, וחוסם אותו עוד לפני שהמקור שלכם רואה מה שהוא בכלל.

00:08:47.520 --> 00:08:50.520
מעבר להגנות האוטומטיות, ניתן ליצור גם חוקים מותאמים אישית.

00:08:50.520 --> 00:08:55.760
למשל, אם האתר שלכם מיועד רק ללקוחות באירופה, אתם יכולים לחסום תעבורה מאזורים אחרים לחלוטין.

00:08:55.880 --> 00:09:00.500
או אולי שמתם לב לטווח IP ספציפי שממשיך לסרוק את האתר שלכם, אתם יכולים לחסום גם אותו.

00:09:00.500 --> 00:09:04.860
ניתן גם לסנן על בסיס כותרות בקשה, דפוסי URL, או אפילו הדפדפן שבו משתמשים.

00:09:04.980 --> 00:09:08.160
ה-WF מעניק לכם שליטה מדויקת מאוד על מי נכנס ומי לא.

00:09:08.280 --> 00:09:10.120
כאן נכנסים לתמונה מסלולי התמכור.

00:09:10.120 --> 00:09:14.520
גרסת הסטנדרד מעניקה לכם חוקי WF מותאמים אישית שבהם אתם מגדירים מה לחסום ומה לאשר.

00:09:14.660 --> 00:09:19.700
גרסת הפרימיום מרחיקה לכת ומוסיפה ערכות חוקי מנוהלות המופעלות על ידי ה-Threat Intelligence של מייקרוסופט,

00:09:19.700 --> 00:09:24.360
שמתעדכנות ללא הרף על סמך דפוסי התקפה מהעולם האמיתי שמייקרוסופט מזהה ברחבי הרשת שלה.

00:09:24.460 --> 00:09:30.180
פרימיום כוללת גם הגנה מפני בוטים שחוסמת באופן אוטומטי שורקים אוטומטיים, גנבי פרטי התחברות ובוטים אחרים.

00:09:30.360 --> 00:09:35.760
והיא מוסיפה תמיכה בפריבט לינק, המאפשרת לכם להתחבר למקורות שלכם דרך חיבור רשת פרטי במקום האינטרנט הציבורי.

00:09:35.860 --> 00:09:39.600
זה אומר ששרתי הבקנד שלכם יכולים להיות מוסתרים לחלוטין מהעולם החיצון.

00:09:39.600 --> 00:09:41.540
רק פרונט דור יכול להגיע עליהם.

00:09:41.660 --> 00:09:43.340
זהו עניין משמעותי מאוד להבטחה.

00:09:43.460 --> 00:09:45.540
הרבה התקפות לא מכוונות אל הפרונט דור.

00:09:45.720 --> 00:09:47.500
הן מנסות למצוא את הדלת האחורית.

00:09:47.500 --> 00:09:53.920
אם לשרת המקור שלכם יש כתובת אי-פי ציבורית, תוקפים יכולים לסרוק אותו ישירות ולעקוף את כל הגנות הפרונט דור שלכם.

00:09:54.060 --> 00:09:59.020
עם פריבט לינק, זה לא אפשרי כי למקור אין נקודת קצה ציבורית והוא נגיש רק דרך פרונט דור.

00:09:59.020 --> 00:10:02.500
אז, גם אם מי שהוא מגלה את האיפ של השרת שלכם, הוא לא יכול להגיע אליו.

00:10:02.620 --> 00:10:04.200
התוצאה היא הגנה רב-שכבתית.

00:10:04.320 --> 00:10:06.340
ה-WF חוסם התקפות ברמת היישום.

00:10:06.480 --> 00:10:08.680
חוקים מותאמים אישית מטפלים בדרישות הספציפיות שלכם.

00:10:08.680 --> 00:10:10.740
הגנה מפני בוטים עוצרת איומים אוטומטיים.

00:10:10.900 --> 00:10:13.180
ו-Private Link שומר על המקורות שלכם בלתי נראים.

00:10:13.300 --> 00:10:16.340
כל זה קורה בקצה לפני שהתעבורה בכלל מגיעה לתשתית שלכם,

00:10:16.540 --> 00:10:19.800
כך שהשרתים שלכם נשארים ממוקדים בהגשת תוכן ולא בלחימה בהתקפות.

00:10:19.800 --> 00:10:22.220
Caching, מה שהופך דברים למהירים עוד יותר.

00:10:22.380 --> 00:10:27.500
אז, עברנו על ניתוב והבטחה, אבל יש תכונה נוספת שהופכת את פרונט דור לממש שימושי, הקאצ'ינג.

00:10:27.620 --> 00:10:31.400
הנה הרעיון, חלק גדול מהתוכן באתר שלכם לא משתנה לעיתים קרובות.

00:10:31.540 --> 00:10:36.440
תמונות, קבצי CSS, ספריות JavaScript, תמונות מוצרים, ואולי אפילו קמד אפי HTML.

00:10:36.760 --> 00:10:39.500
אם כל מבקר חייב למשוך אותם משרת המקור שלך,

00:10:39.500 --> 00:10:43.560
אתה מבזבז זמן ורוחב פס כי השרת צריך לאבד את אותה בקשה שוב ושוב,

00:10:43.820 --> 00:10:46.360
ולשלוח את אותם בתים ברחבי האינטרנט בכל פעם.

00:10:46.500 --> 00:10:50.540
מתמון, קאצ'ינג, פותר זאת על ידי שמירת עותק של תוכן סטטי בנקודת הקצה, פופ.

00:10:50.540 --> 00:10:55.360
בפעם הבאה שמישהו יבקש את אותו קובץ, הפופ יגיש אותו באופן מיידי מבלי ליצור קשר עם המקור שלך.

00:10:55.500 --> 00:10:58.120
זה כמו להחזיק מחסן קטן ליד כל עמדת תנועה.

00:10:58.220 --> 00:11:02.660
במקום לשלוח כל לקוח חזרה למפעל הראשי, אתה פשוט נותן לו את מה שכבר נמצא על המדף.

00:11:02.660 --> 00:11:04.340
הבדל הביצועים הוא דרמטי.

00:11:04.440 --> 00:11:08.320
במקום הלוך חזור מעבר לאוקיינוס, התגובה מגיעה משרת באותה עיר.

00:11:08.480 --> 00:11:10.080
מילי שניות במקום שניות.

00:11:10.080 --> 00:11:15.920
ושרת המקור שלך מקבל הפסקה כי הוא מטפל בפחות בקשות ויכול להתמקד בדברים הדינמיים שבאמת דורשים עיבוד.

00:11:16.060 --> 00:11:18.300
עכשיו, מטמון אינו אוטומטי עבור הכל.

00:11:18.480 --> 00:11:21.020
אתה שולט במה שישמר במטמון ולכמה זמן.

00:11:21.020 --> 00:11:30.700
פרונט דור מכבד כותרות בקרת מטמון סטנדרטיות מהמקור שלך, כמו Max Age או S Maxage, וניתן גם להגדיר כללי מטמון ישירות, תוך עקיפת הכותרות של המקור במידת הצורך.

00:11:30.700 --> 00:11:35.800
כשאתה מעדכן תוכן, אתה יכול לרוקן את המטמון ולומר לפרונט דור לזרוק את העותקים הישנים ולמשוך חדשים.

00:11:35.980 --> 00:11:40.840
זה חשוב לדברים כמו השקות מוצרים או שינויי מחירים שבהם הגרסה החדשה צריכה להיות בנויה באופן מיידי.

00:11:40.840 --> 00:11:44.020
הנה העניין, פרונט דור אינו מיועד רק לתוכן סטטי.

00:11:44.020 --> 00:11:55.560
גם עבור תוכן דינמי כמו ממשקי API, דפים מותאמים אישית או אגלות קניות, הוא עדיין מעיץ את המסירה כי ברגע שהבקשה מגיעה לאפופ הקרוב ביותר, היא עוברת למקור שלך דרך תשתית הבקיבון הפרטית של מייקרוסופט במקום דרך האינטרנט הציבורי.

00:11:55.660 --> 00:11:58.660
אותו בקבון פרטי הוא מהיר ואמין יותר מהרשת הפתוחה.

00:11:58.760 --> 00:12:01.740
אז, גם בקשות שלא נמצאות במטמון מקבלות דחיפה במהירות.

00:12:01.940 --> 00:12:05.200
זהו אחד ההבדלים המרכזיים בין פרונט דור ל-CDN מסורתי.

00:12:05.200 --> 00:12:08.060
CDN שומר תוכן סטטי במטמון וזה בערך הכל.

00:12:08.220 --> 00:12:11.220
פרונט דור שומר תוכן סטטי במטמון ומעיץ את כל השאר.

00:12:11.380 --> 00:12:13.080
זו עסקה של שניים במחיר אחד.

00:12:13.260 --> 00:12:15.160
דרגות תמחו, איזו מהן לבחור?

00:12:15.300 --> 00:12:17.880
טוב, בואו נדבר על כסף כי זו השאלה הגדולה.

00:12:18.000 --> 00:12:20.720
כמה זה עולה ואיזו דרגה כדאי לך באמת לבחור?

00:12:20.880 --> 00:12:23.220
לפני שנצלול למספרים, הנה למה זה משנה.

00:12:23.220 --> 00:12:25.660
הדרגה שאתה בוחר לא רק משפיעה על התג המחיר,

00:12:25.860 --> 00:12:28.980
היא גם קובעת את ההבטחה והתכונות הזמינות להגנה על האפליקציה שלך.

00:12:29.080 --> 00:12:31.320
כפי שאתה יודע, פרונט דור מגיע בשלוש גרסאות.

00:12:31.460 --> 00:12:32.980
קלאסי, קלאסיק, הוא הישן.

00:12:33.100 --> 00:12:36.320
הוא עדיין עובד, אבל מייקרוסופט ממליצה לא להשתמש בו עבור פרויקטים חדשים.

00:12:36.500 --> 00:12:38.220
הגרסה הקלאסית בדרך החוצה.

00:12:38.340 --> 00:12:42.740
לא יהיו משאבים חדשים אחרי 2025 והוצאה מלאה משירות בית מינוס 2027.

00:12:42.740 --> 00:12:46.160
אז, אם אתה מתחיל מאפס, אתה מסתכל על סטנדרד או פרימיום.

00:12:46.320 --> 00:12:47.800
הנה הפירוט הפשוט ביותר.

00:12:47.940 --> 00:12:50.920
העלות של סטנדרד היא 35 דולר לחודש קדמי בסיס.

00:12:51.080 --> 00:12:53.540
העלות של פרימיום היא 330 דולר לחודש.

00:12:53.720 --> 00:12:55.980
זה קפיצה גדולה, אבל הנה החלק המעניין.

00:12:56.120 --> 00:12:59.460
תעריפי העברת הנתונים לגיגה בית זהים בין שתי השכבות.

00:12:59.620 --> 00:13:04.860
בצפון אמריקה ובאירופה, תעבורה יוצאת עולה קף מינוס 8.25 סנט לגיגה בית עבור 10 התורביתים הראשונים.

00:13:04.860 --> 00:13:07.740
העברה מקצה למקור עולה קף מינוס 2 סנט לגיגה בית.

00:13:07.880 --> 00:13:09.100
אותו תמחור בשניהם.

00:13:09.220 --> 00:13:12.040
אז מה מקבלים בתמורה למד מינוס 300 הדולרים הנוספים?

00:13:12.180 --> 00:13:12.700
תכונות.

00:13:12.820 --> 00:13:17.260
פרימיום מוסיפה חוקי WAF מנוהלים המופעלים על ידי מודיעין איומים של מייקרוסופט,

00:13:17.480 --> 00:13:20.040
חוקים שמתעדכנים אוטומטית לפי דפוסי תקיפה אמיתיים.

00:13:20.240 --> 00:13:22.660
אתם מקבלים גם הגנת בוטים, תמיכה בפרייבט לינק,

00:13:22.760 --> 00:13:26.480
כדי שהמקור שלכם יישאר מוסתר מהאינטרנט הציבורי וניתוח הבטחה מעמיק יותר.

00:13:26.480 --> 00:13:28.560
סטנדרד נותן לכם איזון עומסים גלובלי,

00:13:28.720 --> 00:13:29.400
איחסון במתמון,

00:13:29.620 --> 00:13:31.860
העצה דינמית וחוקי WAF מותאמים אישית.

00:13:31.980 --> 00:13:34.660
ניתן לחסום טווחי IP, מדינות או דפוסי בקשות.

00:13:34.820 --> 00:13:37.800
פשוט לא מקבלים את ערכות החוקים המנוהלות או את הפרייבט לינק.

00:13:37.900 --> 00:13:39.140
גם עלויות הבקשות שונות.

00:13:39.320 --> 00:13:43.260
סטנדרד עולה קף מינוס 9 סנט לכל 10,000 בקשות עבור 250 מיליון הבקשות הראשונות.

00:13:43.360 --> 00:13:45.540
פרימיום עולה קף מינוס 15 סנט לכל 10,000.

00:13:45.760 --> 00:13:47.560
בקנה מידה גדול, ההפרש הזה מצטבר.

00:13:47.560 --> 00:13:48.440
אז איך בוחרים?

00:13:48.620 --> 00:13:49.740
הנה כלל האצבע שלי.

00:13:49.900 --> 00:13:51.760
אם אתם מפעילים אתר או API טיפוסי,

00:13:51.920 --> 00:13:54.100
משהו שזקוק לביצועים גלובליים והבטחה בסיסית,

00:13:54.260 --> 00:13:55.100
התחילו עם סטנדרד.

00:13:55.220 --> 00:13:57.280
דמי הבסיס של 35 דולר הם משתלמים,

00:13:57.460 --> 00:14:00.260
וחוקי ה-WAF המותאמים אישית מטפלים ברוב האיומים הנפוצים.

00:14:00.380 --> 00:14:03.480
תמיד אפשר לשדרג מאוחר יותר אם צורכי ההבטחה שלכם יגדלו.

00:14:03.580 --> 00:14:06.900
אם אתם בתעשייה מוסדרת, בריאות, פיננסים, ממשלה,

00:14:07.160 --> 00:14:09.000
או אם אתם מטפלים במידע לקוחות רגיש,

00:14:09.000 --> 00:14:10.620
פרימיום שווה את העלות הנוספת.

00:14:10.680 --> 00:14:14.240
תחוקי ה-WAF המנוהלים תופסים איומים שאולי לא הייתם חושבים לחסום.

00:14:14.400 --> 00:14:16.480
פרייבט לינק שומר על המקורות שלכם בלתי נראים,

00:14:16.660 --> 00:14:19.520
והגנת בוטים עוצרת התקפות אוטומטיות שסטנדרד לא היה תופס.

00:14:19.660 --> 00:14:23.700
דבר אחרון, אם אתם מגישים רק תוכן סטטי ולא זקוקים לניתוב או לתכונות הבטחה,

00:14:23.840 --> 00:14:25.540
CDN מסורתי עשוי להיות זול יותר.

00:14:25.740 --> 00:14:27.900
Azure CDN של מייקרוסופט עדיין קיים,

00:14:27.900 --> 00:14:30.920
ועבור הספקה סטטית טהורה ולעיתים קרובות חסכוני יותר.

00:14:31.060 --> 00:14:34.380
אבל עבור רוב היישומים האמיתיים שבהם אתם זקוקים לניתוב,

00:14:34.500 --> 00:14:36.020
הבטחה, מתמון והעצה,

00:14:36.260 --> 00:14:38.420
פרונט דור סטנדרד הוא נקודת האיזון האידיאלי.

00:14:38.520 --> 00:14:40.600
נסכם הכל בדוגמה מהעולם האמיתי.

00:14:40.780 --> 00:14:42.740
הרשו לי להוביל אתכם בתרחיש מהעולם האמיתי,

00:14:42.880 --> 00:14:45.400
כדי שתוכלו לראות בדיוק איך כל החלקים האלו עובדים יחד.

00:14:45.520 --> 00:14:47.520
דמיינו שאתם מפעילים אתר מסחר אלקטרוני.

00:14:47.520 --> 00:14:50.560
יש לכם שרתים בשלושה אזורים, צפון אמריקה, אירופה ואסיה.

00:14:50.680 --> 00:14:54.060
הלקוחות שלכם נמצאים בכל מקום, מיפן ועד ברזיל ודרום אפריקה.

00:14:54.180 --> 00:14:58.220
ללא פרונט דור, לקוח בטוקיו מתחבר ישירות לשרת שלכם בארצות הברית.

00:14:58.320 --> 00:15:02.160
כל תמונה, דף מוצר ובקשה תשלום צריכים לחצות את האוקיינוס השקה.

00:15:02.300 --> 00:15:05.760
זה איתי, ואם השרת שלך בארצות הברית מושבת, הלקוח פשוט רואה שגיאה.

00:15:05.860 --> 00:15:07.360
עכשיו, נוסיף את פרונט דור.

00:15:07.360 --> 00:15:09.400
הלקוח בטוקיו פותח את האתר שלך.

00:15:09.400 --> 00:15:12.520
הדפדפן שלו מגיע למיקום אזור הקרוב ביותר, נקרא לו טוקיו.

00:15:12.640 --> 00:15:15.740
המיקום הזה בודק את תקינות שלושת השרתים שלך, כולם תקינים.

00:15:15.880 --> 00:15:16.700
הוא מודד שיהוי.

00:15:16.860 --> 00:15:21.560
השרת האסיאטי מגיב הכי מהר, לכן הוא מנתב את הבקשה לשם על גבי התשתית הפרטית של מייקרוסופט.

00:15:21.640 --> 00:15:23.680
הדף נטען תוך פחות משנייה במקום שלוש.

00:15:23.840 --> 00:15:27.240
עכשיו, תארו לעצמכם שהשרת האסיאטי עמוס מדי במהלך מבצע מחירות בזה.

00:15:27.240 --> 00:15:30.360
בדיקות התקינות של פרונט דור מזהות את העלייה בשיהוי.

00:15:30.360 --> 00:15:33.900
הוא מתחיל להעביר תעבורה לשרת האירופי, האופציה הטובה הבאה.

00:15:34.000 --> 00:15:39.980
לקוחות עדיין מקבלים חוויה מהירה, אולי לא מהירה כמו השרת האסיאטי, אבל עדיין מהירה יותר מלהגיע עד ארצות הברית.

00:15:40.160 --> 00:15:43.660
כל המעבר האוטומטי מתבצע ללא צורך של אף אחד לגעת בהגדרות.

00:15:43.840 --> 00:15:45.780
בינתיים, ה-WAF פועל בקצה.

00:15:45.780 --> 00:15:49.080
הוא חוסם ניסיון הזרקת סיקוואל מבוטנד שסורק את תופס התשלום שלך.

00:15:49.220 --> 00:15:52.120
הוא חוסם תעבורה מטווחים של כתובות IP זדוניות מוכרות.

00:15:52.140 --> 00:15:55.360
והוא מגביל קצב בקשות מכתובת IP שסורקת את כתלוג המוצרים שלך.

00:15:55.500 --> 00:15:57.920
אף אחת מהתקפות האלו לא מגיעה לשרתי המקור שלך.

00:15:58.060 --> 00:16:00.380
צוות ה-Back-End שלך אפילו לא יודע שהן קרו.

00:16:00.480 --> 00:16:05.960
והתוכן הסטטי, תמונות מוצרים, קבצי CSS וספריות JavaScript, כולם נשמרים במטמון במקום בטוקיו.

00:16:05.960 --> 00:16:08.760
המבקר הראשון טוען אותם ממקור הנתונים האסיאטי.

00:16:08.860 --> 00:16:11.860
המבקר השני מקבל אותם מהמטמון בקצה באופן מיידי.

00:16:11.860 --> 00:16:17.580
מבקרים חוזרים נהנים מזמני טעינה כמעט מיידיים כי כל מה שהם צריכים כבר נמצא במקום הקצה לידם.

00:16:17.720 --> 00:16:23.280
כל זה ניתוב מהיר, מעבר אוטומטי, אבטחת קצה ותוכן שמור במטמון עובד יחד בצורה חלקה.

00:16:23.420 --> 00:16:25.360
הלקוחות שלך לעולם לא ידעו שזה שם.

00:16:25.520 --> 00:16:27.240
הם פשוט רואים אתר מהיר ואמין.

00:16:27.240 --> 00:16:28.580
הנה מה שצריך לזכור.

00:16:28.740 --> 00:16:35.340
Azure Front Door פועל כשוטר תנועה גלובלי שמנתב משתמשים לשרת המהיר ביותר, שומר תוכן בקצה וחוסם התקפות לפני שהן מגיעות אליך.

00:16:35.340 --> 00:16:37.160
הוא בנוי על שלוש שכבות של עמידות.

00:16:37.380 --> 00:16:39.940
כך שגם עם אזור מושבת, האתר שלך נשאר פעיל.

00:16:40.120 --> 00:16:45.920
עבור רוב הפרויקטים, שכבת הסטנדרד בית מינוס 35 דולר בלבד לחודש היא האיזון המושלם בין ביצועים לעלות.

00:16:46.060 --> 00:16:49.320
שדרג לפרימיום כשאתה זקוק להבטחה מתקדמת או לקישור פרטי.

00:16:49.320 --> 00:16:52.080
תתחיל בקטן עם שרת מקור אחד ותצמח משם.

00:16:52.240 --> 00:16:53.760
Front Door גדל יחד איתך.

00:16:53.900 --> 00:16:58.200
אם לאפליקציית האינטרנט שלך יש משתמשים הפזורים על פני אזורים, הגדר פרופיל Front Door עוד היום.

00:16:58.200 --> 00:17:01.420
אפילו שרת בודד מקבל העצה גלובלית ויתרונות הבטחה.

00:17:01.540 --> 00:17:06.280
הרשמו בפלטפורמת הפודקסטים המועדפת עליכם ושתפו זאת עם מי שמתחיל את המסע שלו בענן.