system-design-primer/README-he.md

English ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة‎ ∙ বাংলা ∙ Português do Brasil ∙ Deutsch ∙ ελληνικά ∙ עברית ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | Add Translation

עזרו לתרגם את המדריך!

המדריך לתכנון מערכות (The System Design Primer)

מוטיבציה

ללמוד איך לתכנן מערכות ב-scale גדול.

להתכונן לראיונות ארכיטקטורה.

ללמוד איך לתכנן מערכות ב-scale גדול

ללמוד כיצד לתכנן מערכות סְקֵילָבִּילִיוּת יסייע לך להפוך למהנדס תוכנה טוב יותר.

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

ה-repo הזה הוא אוסף מסודר של משאבים שנועדו לעזור לך ללמוד איך לבנות מערכות ב-scale.

ללמוד מקהילת הקוד הפתוח

מדובר בפרויקט קוד פתוח (open source) שמתעדכן באופן מתמשך.

מוזמנים לתרום!

להתכונן לראיונות ארכיטקטורה

בנוסף לראיונות קידוד, ארכיטקטורה היא רכיב נדרש כחלק מתהליך ראיונות טכניים בהרבה חברות טכנולוגיות.

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

נושאים נוספים להכנה לראיונות:

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

כרטיסיות Anki

החבילות המוכנות של כרטיסיות Anki משתמשות בשיטת חזרתיות מבוססת מרווחים (Spaced Repetition) כדי לעזור לך לזכור מושגים חשובים בתכנון מערכות.

• חבילת תכנון מערכות
• חבילת תרגילים בתכנון מערכות
• חבילת תכנון מונחה עצמים

מומלצות לשימוש בדרכים.

משאב לראיונות קידוד: אתגרי קידוד אינטראקטיביים

מחפש משאבים שיעזרו לך להתכונן לראיונות קידוד?

תעיף מבט על ה-repo המקביל Interactive Coding Challenges, שמכיל חבילת Anki נוספת:

• חבילת קידוד

תרומה למדריך

ללמוד מהקהילה.

אל תהסס להגיש pull requests כדי לעזור:

• תיקון שגיאות
• שיפור קטעים קיימים
• הוספת קטעים חדשים
• תרגום לשפות נוספות

תכנים שעדיין דורשים ליטוש מסומנים בתור תחת פיתוח.

מומלץ לעיין בהנחיות לתרומה לפני התחלה.

אינדקס נושאים בארכיטקטורה

סיכומים של נושאים שונים בתכנון מערכות, כולל יתרונות וחסרונות. כל החלטה כוללת פשרות (trade-offs).

כל חלק מכיל קישורים להרחבה וללמידה מעמיקה יותר.

אינדקס נושאים

• נושאים בתכנון מערכות: התחל כאן
  • שלב 1: צפה בהרצאה על סקילביליות
  • שלב 2: קרא מאמרים על סקילביליות
  • השלבים הבאים
• ביצועים (performance) מול סקילביליות (scalability)
• שיהוי (latency) מול תפוקה (throughput)
• זמינות (availability) מול עקביות (consistency)
  • משפט CAP
    • עקביות וטולרנטיות לפיצול (CP)
    • זמינות וטולרנטיות לפיצול (AP)
• דפוסי עקביות
  • עקביות חלשה (weak)
  • עקביות לא מיידית (eventual)
  • עקביות חזקה (strong)
• דפוסי זמינות
  • גיבוי בזמן כישלון (fail-over)
  • שכפול (replication)
  • זמינות במספרים
• מערכת שמות דומיינים (DNS)
• רשתות הפצת תוכן (CDN)
  • דחיפה (Push)
  • משיכה (Pull)
• מאזן עומסים (load balancer)
  • אקטיבי-פסיבי (active-passive)
  • אקטיבי-אקטיבי (active-active)
  • איזון עומסים בשכבה 4
  • איזון עומסים בשכבה 7
  • גדילה אופקית (horizontal)
• פרוקסי 'הפוך' (Reverse Proxy)
  • מאזן עומסים לעומת פרוקסי הפוך
• שכבת האפליקציה
  • מיקרוסרביסים (microservices)
  • גילוי שירותים (service discovery)
• מסדי נתונים
  • מסדי נתונים רלציוניים (RDBMS)
    • שכפול Master-Slave
    • שכפול Master-Master
    • פדרציה (federation)
    • חלוקה (sharding)
    • דה-נורמליזציה (denormalization)
    • SQL Tuning
  • NoSQL
    • מפתח-ערך (Key-Value)
    • מסמכים (Document Store)
    • רב-עמודות (Wide Column)
    • גרפים (Graph DB)
  • SQL או NoSQL
• מטמון (Cache)
  • מטמון בצד לקוח
  • מטמון ב-CDN
  • מטמון בשרת
  • מטמון במסד נתונים
  • מטמון באפליקציה
  • מטמון ברמת שאילתה
  • מטמון ברמת אובייקט
  • מתי לעדכן את ה-cache?
    • אסטרטגיית Cache-aside
    • אסטרטגיית Write-through
    • אסטרטגיית Write-behind (write-back)
    • אסטרטגיית Refresh-ahead
• אסינכרוניות (asynchronism)
  • תורי הודעות (MQ)
  • תורי משימות
  • לחץ אחורי (Back Pressure)
• תקשורת
  • פרוטוקול Transmission control protocol (TCP)
  • פרוטוקול User datagram protocol (UDP)
  • קריאת Remote procedure call (RPC)
  • פרוטוקול Representational state transfer (REST)
• אבטחה
• נספחים
  • טבלת חזקות של 2
  • מספרי latency חשובים
  • שאלות נוספות לראיונות
  • ארכיטקטורות מהעולם האמיתי
  • ארכיטקטורות של חברות
  • בלוגים טכניים של חברות
• תחת פיתוח
• קרדיטים
• פרטי קשר
• רישיון

מדריך למידה

נושאים מוצעים ללימוד לפי לוח הזמנים לריאיון שלך (קצר, בינוני, ארוך)

ש: עבור הראיונות, האם אני אמור לדעת כל מה שכתוב כאן?

ת: לא, אתה לא צריך לדעת הכול כדי להתכונן לריאיון.

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

• כמה ניסיון יש לך
• מה הרקע הטכני שלך
• לאילו משרות אתה מתראיין
• באילו חברות אתה מתראיין
• מזל

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

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

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

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

איך לגשת לשאלת ריאיון ארכיטקטורה

איך לפתור שאלת ראיון ארכיטקטורה.

ראיון ארכיטקטורה הוא שיחה פתוחה. מצופה ממך להוביל אותה.

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

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

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

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

שלב 2: כתוב תכנון במבט על (high level design)

כתוב תכנון high level עם כל הרכיבים החשובים.

• שרטט את הרכיבים החשובים והקשרים ביניהם
• תצדיק את הרעיונות שלך

שלב 3: תכנן את הרכיבים המרכזיים

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

• יצירה ואחסון hash של ה-url המלא
  • דרכים כמו MD5 ו-Base62
  • התנגשויות hash
  • מסד נתונים SQL או NoSQL
  • סכמת הנתונים
• המרה של כתובת מקוצרת לכתובת המלאה
  • חיפוש ב-DB
• תכנון API ותכנון מונחה עצמים

שלב 4: תבצע scale לתכנון

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

• מאזן עומסים (Load balancer)
• סקיילינג אופקי (Horizontal scaling)
• שמירה במטמון (Caching)
• פיצול בסיס נתונים (Database sharding)

דון בפתרונות אפשריים וה-trade-offs. הכול הוא trade-off. התמודד עם צווארי בקבוק בעזרת עקרונות תכנון מערכת סקילבילית.

חישובים "על גב המעטפה" (מהירים)

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

• Use back of the envelope calculations
• Powers of two table
• Latency numbers every programmer should know

מקורות לקריאה נוספת

עיין בקישורים הבאים כדי להבין טוב יותר למה לצפות:

• How to ace a systems design interview
• The system design interview
• Intro to Architecture and Systems Design Interviews
• System design template

שאלות ריאיון תכנון מערכות עם פתרונות

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

הפתרונות מפנים לתוכן שנמצא בתיקיית solutions/.

שאלה	פתרון
תכנן את pastebin.com (או bit.ly)	פתרון
תכנן את ציר הזמן והחיפוש של טוויטר (או הפיד והחיפוש של פייסבוק)	פתרון
תכנן web crawler	פתרון
תכנן את Mint.com	פתרון
תכנן את מבני הנתונים של רשת חברתית	פתרון
תכנן אחסון key-value למנוע חיפוש	פתרון
תכנן את מנגנון דירוג המכירות לפי קטגוריה של אמזון	פתרון
תכנן מערכת שיכולה לגדול למיליוני משתמשים על AWS	פתרון
הוסף שאלה לתכנון מערכת	תרום

תכנן את pastebin.com (או bit.ly)

צפה בתרגיל ובפתרון

הצג/הסתר דיאגרמה

תכנן את ציר הזמן והחיפוש של טוויטר (או הפיד והחיפוש של פייסבוק)

צפה בתרגיל ובפתרון

הצג/הסתר דיאגרמה

תכנן web crawler

צפה בתרגיל ובפתרון

הצג/הסתר דיאגרמה

תכנן את Mint.com

צפה בתרגיל ובפתרון

הצג/הסתר דיאגרמה

תכנן את מבני הנתונים של רשת חברתית

צפה בתרגיל ובפתרון

הצג/הסתר דיאגרמה

תכנן אחסון key-value למנוע חיפוש

צפה בתרגיל ובפתרון

הצג/הסתר דיאגרמה

תכנן את מנגנון דירוג המכירות לפי קטגוריה של אמזון

צפה בתרגיל ובפתרון

הצג/הסתר דיאגרמה

תכנן מערכת שיכולה לגדול למיליוני משתמשים על AWS

צפה בתרגיל ובפתרון

הצג/הסתר דיאגרמה

שאלות ריאיון בתכנון מונחה עצמים עם פתרונות

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

הפתרונות מפנים לתוכן שנמצא בתיקיית solutions/.

הערה: החלק הזה עדיין בפיתוח

שאלה	פתרון
תכנן Hash Map	פתרון
תכנן מנגנון Cache בשיטת Least Recently Used	פתרון
תכנן מרכז שירות טלפוני (Call Center)	פתרון
תכנן חפיסת קלפים	פתרון
תכנן חניון	פתרון
תכנן שרת צ'אט	פתרון
תכנן מערך מעגלי	תרום
הוסף שאלה בעיצוב מונחה עצמים	תרום

נושאים בתכנון מערכות: התחל כאן

חדש בתחום תכנון מערכות?

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

שלב 1: צפה בהרצאה על סקילביליות

Scalability Lecture at Harvard

• Topics covered:
  • Vertical scaling
  • Horizontal scaling
  • Caching
  • Load balancing
  • Database replication
  • Database partitioning

שלב 2: קרא מאמר על סקילביליות

Scalability

• Topics covered:
  • Clones
  • Databases
  • Caches
  • Asynchronism

השלבים הבאים

בהמשך, נסתכל על trade-offs ב-high level:

• Performance vs scalability
• Latency vs throughput
• Availability vs consistency

נזכור כי הכול זה trade-off. לאחר מכן נצלול לנושאים ספציפיים יותר כמו DNS, CDN ו-load balancers.

ביצועים (Performance) מול סקילביליות (Scalability)

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

דרך נוספת להסתכל על ביצועים מול סקילביליות

• אם יש לך בעיית ביצועים, המערכת איטית עבור משתמש בודד.
• אם יש לך בעיית סקילביליות, המערכת מהירה עבור משתמש בודד אך איטית בעומס כבד.

מקורות וקריאה נוספת

• A word on scalability
• Scalability, availability, stability, patterns

שיהוי (Latency) מול תפוקה (Throughput)

שיהוי הוא הזמן שנדרש כדי לבצע פעולה כלשהי או להפיק תוצאה כלשהי

תפוקה היא מספר הפעולות או התוצאות ליחידת זמן.

באופן כללי, כדאי לשאוף לתפוקה מקסימלית עם שיהוי סביר.

חומרים וקריאה נוספת

• Understanding latency vs throughput

זמינות (Availability) מול עקביות (Consistency)

משפט CAP

Source: CAP theorem revisited

במערכות מחשוב מבוזרות, ניתן לתמוך רק בשניים מתוך שלושת התנאים הבאים:

• עקביות (Consistency) – כל קריאה מקבלת את הכתיבה העדכנית ביותר, או שגיאה.
• זמינות (Availability) - כל בקשה תקבל מענה, ללא הבטחה שהמידע שיחזור יהיה העדכני ביותר.
• יכולת חלוקה (Partition Tolerance) - המערכת ממשיכה לתפקד גם במקרים בהם נאבדות או מתעכבות מספר הודעות בין שרתי המערכת בגלל בעיות תקשורת.

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

בחירה ב-CP - עקביות ויכולת חלוקה

המתנה לתשובה מהמערכת (אשר סובלת מ-network partition) עלולה להסתיים בשגיאת timeout. לכן, CP הוא בחירה טובה במידה ויש הצדקה עסקית לקריאות וכתיבות אטומיות.

בחירה ב-AP - זמינות ויכולת חלוקה

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

לכן, AP הוא בחירה טובה במידה ויש הצדקה עסקית לעבוד במצב של eventual consistency או במידה והמערכת צריכה להמשיך לשרת למרות שגיאות בלתי-תלויות.

חומרים וקריאה נוספת

• CAP theorem revisited
• A plain english introduction to CAP theorem
• CAP FAQ
• The CAP theorem

דפוסי עקביות (Consistency Patterns)

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

עקביות חלשה (Weak Consistency)

לאחר כתיבה, קריאות עשויות לראות או לא לראות את הערך החדש שנכתב. הגישה כאן היא של best effort - המאמץ הטוב ביותר.

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

עקביות לא מיידית (Eventual Consistency)

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

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

עקביות חזקה (Strong Consistency)

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

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

מקורות וקריאה נוספת

• Transactions across data centers

דפוסי זמינות (Availability Patterns)

קיימים שני דפוסים משלימים לתמיכה בזמינות גבוהה: מעבר אוטומטי (fail-over) ו-שכפול (replication).

גיבוי בזמן כישלון (Fail-Over)

אקטיבי-פסיבי (Active-Passive)

במבנה אקטיבי-פסיבי, נשלחים heartbeat-ים בין השרת הפעיל לשרת הרזרבי (הפסיבי). אם ה-heartbeat נקטע, השרת הפסיבי לוקח את כתובת ה-IP של הפעיל וממשיך את השירות.

משך זמן ההשבתה תלוי אם השרת הפסיבי פועל מראש במצב 'חם' (hot standby), או שיש להפעילו ממצב 'קר' (cold standby). רק השרת הפעיל מקבל תעבורה.

סוג זה נקרא גם Master-Slave.

אקטיבי-אקטיבי (Active-Active)

במבנה אקטיבי-אקטיבי, שני השרתים מקבלים תעבורה ומחלקים ביניהם את העומס.

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

סוג זה נקרא גם Master-Master.

חסרונות של מעבר אוטומטי

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

שכפול (Replication)

עבור Master-Slave/Master-Master

נושא זה נדון בפירוט נוסף בחלק על מסדי נתונים:

• Master-slave replication
• Master-master replication

זמינות במספרים

נהוג למדוד זמינות לפי זמן פעילות (uptime) או חוסר פעילות (downtime)כאחוז מהזמן שבו השירות פועל. המדד הנפוץ הוא לפי מספר התשיעיות — לדוגמה: שירות עם זמינות של 99.99% מתואר כבעל ארבע תשיעיות.

זמינות של 99.9% — שלוש תשיעיות

Duration	Acceptable downtime
Downtime per year	8h 45min 57s
Downtime per month	43m 49.7s
Downtime per week	10m 4.8s
Downtime per day	1m 26.4s

זמינות של 99.99% — ארבע תשיעיות

Duration	Acceptable downtime
Downtime per year	52min 35.7s
Downtime per month	4m 23s
Downtime per week	1m 5s
Downtime per day	8.6s

זמינות במקביל לעומת בטור

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

בטור

כאשר שני רכיבים עם זמינות קטנה מ-100% מסודרים בטור, הזמינות הכוללת יורדת:

Availability (Total) = Availability (Foo) * Availability (Bar)

אם גם Foo וגם Bar זמינים ברמה של 99.9%, הזמינות הכוללת שלהם בטור תהיה 99.8%.

במקביל

הזמינות הכוללת עולה כאשר שני רכיבים בעלי זמינות קטנה מ־100% פועלים במקביל:

Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))

אם גם Foo וגם Bar זמינים ברמה של 99.9%, הזמינות הכוללת שלהם במקביל תהיה 99.9999%.

מערכת שמות דומיינים (DNS)

מקור: מצגת אבטחת DNS

מערכת שמות דומיינים (DNS) ממירה שם דומיין כמו www.example.com לכתובת IP.

ה-DNS בנוי בהיררכיה: כאשר ישנם כמה שרתי ניהול בשכבה העליונה. ה-router שלך או ספק האינטרנט (ISP) מספקים כתובות לשרת(י) DNS שיש לפנות אליהם בעת ביצוע חיפוש של כתובת.
שרתי DNS בשכבה נמוכה יותר, מבצעים cache למיפויים, שעלולים להיות לא עדכניים (stale) אם הרשומה המעודכנת עוד לא עברה מהשרת בשכבה הגבוהה עד למטה (propagation delays). המיפוי של ה-DNS יכול להישמר על ידי הדפדפן או מערכת ההפעלה לפרק זמן מסוים, הנקבע על ידי TTL – Time To Live.

• NS record (Name Server) – מגדירה את שרתי DNS עבור הדומיין/תת-דומיין.
• MX record (Mail Exchange) – מגדירה את שרתי הדואר לקבלת הודעות.
• A record (Address) – ממפה שם לכתובת IP.
• CNAME (Canonical Name) – ממפה שם לשם אחר (למשל example.com → www.example.com) או לרשומת A.

שירותים מנוהלים כמו CloudFlare ו-Route 53 מספקים DNS מנוהל.
חלקם מאפשרים ניתוב תעבורה בשיטות שונות:

• Weighted round robin
  • Prevent traffic from going to servers under maintenance
  • Balance between varying cluster sizes
  • A/B testing
• Latency-based
• Geolocation-based

חסרונות (DNS)

• פנייה לשרת DNS מוסיפה עיכוב קל, אם כי ברוב המקרים הוא מתמתן בזכות caching כפי שתואר קודם.
• ניהול שרתי DNS יכול להיות מורכב, ולרוב מנוהל על-ידי ממשלות, ISPs וחברות גדולות.
• שירותי DNS היו יעד לאחרונה ל-מתקפות DDoS, מה שמנע מגולשים להגיע לאתרים (למשל Twitter) בלי להכיר כתובות IP ידניות.

מקורות וקריאה נוספת

• DNS architecture
• Wikipedia
• DNS articles

רשתות הפצת תוכן (CDN)

מקור: Why use a CDN

רשת הפצת תוכן (CDN) היא רשת גלובלית ומבוזרת של שרתי proxy, אשר מנגישים תכנים ממיקומים הקרובים יותר למשתמש הקצה. בדרך כלל, קבצים סטטיים כמו HTML/CSS/JS, תמונות וסרטונים, מונגשים על ידי CDN, למרות שיש כאלו כמו CloudFront של Amazon התומכים גם בתכנים דינמיים. מיפוי ה-DNS שיתקבל ינחה את הלקוחות לאיזה שרת להתחבר.

הגשת תוכן מ-CDN משפר ביצועים משמעותית בשני אופנים:

• המשתמש מקבל תוכן מ-data center הקרוב אליו פיזית.
• השרתים אינם צריכים לשרת בקשות שה-CDN מספק במקומם.

דחיפה (Push)

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

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

משיכה (Pull)

ב-Pull CDN התוכן נשלף מהשרת המקור רק כאשר משתמש מבקש אותו לראשונה. הקבצים נשארים בשרת שלך ו-URLs מפנים ל-CDN. הבקשה הראשונית איטית יותר עד שהקובץ נשמר ב-CDN. משך הזמן שבו ישאר ה-cache נקבע על-ידי TTL – Time to Live.

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

חסרונות (CDN)

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

מקורות וקריאה נוספת

• Globally distributed content delivery
• The differences between push and pull CDNs
• Wikipedia