יתרונות הביצועים

מבוא: סיבות ומיטיגציות של זמן אחזור DNS

ככל שדפי האינטרנט הופכים למורכבים יותר, והפניית אליהם משאבים מכמה דומיינים, חיפושי DNS יכולים להפוך לצוואר בקבוק משמעותי בחוויית הגלישה. בכל פעם שלקוח צריך לשלוח שאילתה למקודד DNS ברשת, זמן האחזור יכול להיות משמעותי בהתאם לקרבה ולמספר של שרתי השמות שצריך לשלוח למקודד (יש יותר מ-2 מקרים כאלה, אבל זה יכול לקרות). לדוגמה, צילום המסך הבא מציג את התזמונים שדווחו על ידי הכלי מהירות דף למדידת ביצועים באינטרנט. כל עמודה מייצגת משאב מהדף שאליו מתבצעת הפניה. הקטעים השחורים מציינים חיפושי DNS. בדף הזה מתבצעים 13 חיפושים ב-11 השניות הראשונות שבהן הדף נטען. על אף שחלק מבדיקות המידע מבוצעות במקביל, צילום המסך מראה שנדרשים 5 זמני חיפוש טורי, ומתייחסים לכמה שניות מתוך זמן הטעינה הכולל של הדף ב-11 שניות.

יש שני רכיבים בזמני האחזור של ה-DNS:

• זמן אחזור בין הלקוח (המשתמש) לבין שרת זיהוי DNS. ברוב המקרים, הסיבה לכך היא מגבלות זמן הלוך ושוב (RTT) הרגילות במערכות ברשת: מרחק גיאוגרפי בין מכונות הלקוח למכונות השרתים, עומס ברשת, אובדן חבילות ועיכובים ארוכים בשידור חוזר (שנייה אחת בממוצע), עומס יתר בשרתים, התקפות מניעת שירות (DoS) וכו'.
• זמן אחזור בין עיבוד השרתים לשרתי שמות אחרים. מקור האחזור הזה נובע בעיקר מהגורמים הבאים:
  • מטמון חסר. אם אי אפשר לקבל תשובה מהמטמון של המקודד, אבל צריך לשלוח שאילתה רק לשרתי שמות אחרים, תוספת זמן האחזור של הרשת היא משמעותית, במיוחד אם השרתים המהימנים מרוחקים מבחינה גיאוגרפית.
  • ניהול תצורה נמוך מדי. אם יש עומס יתר על מקודדי ה-DNS, הם צריכים להוסיף לתור בקשות לפענוח DNS ולטפל בהן, והם יכולים להתחיל לשחרר ולהעביר חבילות מחדש.
  • תנועה זדונית. גם אם יש הקצאות יתר של שירות DNS, תעבורת הנתונים של DoS עלולה ליצור עומס מיותר על השרתים. באופן דומה, התקפות בסגנון Kaminsky עשויות לכלול הצפה של מקודדים באמצעות שאילתות שמובטחות לעקוף את המטמון ודורשות בקשות יוצאות לפתרון.

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

החטאות במטמון

גם אם למקודד יש שפע של משאבים מקומיים, קשה להימנע מהעיכובים הבסיסיים שקשורים לתקשורת עם שרתי שמות מרוחקים. במילים אחרות, בהנחה שהמקודד מוקצה בצורה מספיק טובה כך שההיטים מהמטמון יימשכו אפס זמן בצד השרת, החמצות של המטמון יישארו יקרות מאוד מבחינת זמן האחזור. כדי להתמודד עם החמצה, המקודד צריך לדבר עם לפחות אחד משרתי שמות חיצוניים, אבל לעיתים קרובות יותר. כשהפעלנו את סורק האינטרנט של Googlebot, הבחנו שזמן הפתרון הממוצע של שרתי שמות הוא 130 אלפיות השנייה. עם זאת, 4% עד 6% מהבקשות פשוט מפסיקות לפעול עקב אובדן מנות UDP ולא ניתן להגיע לשרתים. אם אנחנו לוקחים בחשבון כשלים כמו אובדן מנות, שרתי שמות "מתים", שגיאות בהגדרת DNS וכו', הזמן הממוצע בפועל לפתרון מקצה לקצה הוא 300 עד 400 אלפיות השנייה, אבל יש שונות גבוהה ו"זנב ארוך".

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

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

הקלות

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

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

הקצאת הרשאות מתאימה של אשכולות

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

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

איזון עומסים עבור שמירה משותפת במטמון

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

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

פיזור אשכולות שירות להשגת כיסוי גיאוגרפי רחב

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

שירות ה-DNS הציבורי של Google מתארח במרכזי נתונים ברחבי העולם, ומשתמש בניתוב anycast כדי לשלוח משתמשים למרכז הנתונים הקרוב ביותר מבחינה גיאוגרפית.

בנוסף, ב-Google Public DNS יש תמיכה בתת-רשת של לקוח EDNS (ECS) – תוסף של פרוטוקול DNS שמאפשר למקודדים להעביר את מיקום הלקוח לשרתי שמות, שיכול להחזיר תגובות רגישות למיקום שמותאמות לכתובת ה-IP של הלקוח בפועל, במקום לכתובת ה-IP של המקודד. לקבלת פרטים, ניתן לקרוא את השאלות הנפוצות האלה. שירות ה-DNS הציבורי של Google מזהה באופן אוטומטי שרתי שמות שתומכים בתת-רשת של לקוח EDNS.