DAVID מלאן: בסדר, ברוכים השבים. לפני שאנחנו צוללים לתוך מחשוב ענן, חשבתי לעצור לרגע אם יש לך שאלות מצטיינות או נושאים שעלו במהלך ארוחת הצהריים כי עלול להיות עכשיו עניינים. קהל: [לא ברור] DAVID מלאן: אישור. בסדר. קהל: [לא ברור] DAVID מלאן: לא, כמובן. טוב, בסדר אני מקווה כל שלך מתעוררות בעיות בשעות הקרובות ומחר במיוחד. אבל בואו נסתכל, אם כן, על שם בדיון האחרון על הגדרת אתר אינטרנט מוביל, באופן כללי יותר כשמדובר ענן מחשוב, הגדרת ארכיטקטורת שרת, סוגי החלטות כי מהנדסים מפתחים ומנהלים צריך לעשות כשמדובר לעשות יותר מאשר רק שנרשם אינטרנט מארח 10 $ לחודש כאשר אתה בעצם רוצה לבנות את תשתית משלך. וננסה לקשור את זה בחזרה, למשל, כדי Dropbox ועוד כמוהם. אז בואו נתחיל לשקול מה מתעורר בעיות כעסק מבצעים טובים יותר ובעיות טובות להתעורר. אז במקרה מאוד פשוט שיש לחברה כמה שיש לו שרת אינטרנט, שאולי יש לך, נניח, שרת אנחנו פשוט נצייר שנראה כך. וגם בימים אלה, רוב servers-- ובואו למעשה לשים תמונה זה פשוט כל כך שזה קצת פחות מעורפל. אז מעמד של Dell server-- חזרה היום, יש היו מחשבי מיינפריים שתפסתי חדרים שלמים. בימים אלה, אם היית להשיג שרת, זה עשוי להיראות משהו קטן כזה. שרתים נמדדים במה נקראים יחידות מתלות, או רוס. ואחד RU הוא 1.5 אינץ ', שהוא תקן התעשייה. אז זה נראה כמו שרת שני RU. אז זה 3 סנטימטרים. והם בדרך כלל 19 אינץ 'רחב, כלומר כל סוג של חומר הוא טופל. אז אם אתה מסתכל בתוך נתונים center-- ולא רק שרת אחד, אבל בואו תסתכל על גוגל מרכז הנתונים ולראות אם אנחנו לראות תמונה יפה תמונות Google. זה הרבה יותר טוב ממה שאתה מואר בדרך כלל תמצא, ועוד הרבה סקסי מחפש כתוצאה מכך. אבל זה מה שנראה כמו זוג מאה שרתים כל על גודל באותה, למעשה, ב מדף אחר מדף לאחר מדף אחר מדף בתוך מרכז הנתונים. משהו כמו זה- זה עשוי בהחלט להיות, של גוגל מאז אני בגוגל גוגל. אבל זה יכול להיות נציג של כללי יותר מרכז הנתונים שבו רבים חברות משתפות ממוקמות בדרך כלל. וגם שיתוף הממוקם בדרך כלל אומר כי אתה הולך למקום כמו Equinix או ספקים אחרים שיש להם גדולים מחסנים שיש המון כוח, המון קירור, בתקווה המון ביטחון, וכלובי פרט תוחם דלפקים שירת, ואתה גם לשכור מדפים או שאתה מביא בין המדפים. חברות בודדות, חברות סטארט-אפ במיוחד, יהיה איזשהו ביומטריה להיכנס לכלוב שלהם, או מפתח, או כרטיס מפתח. אתה פותח את הדלת. ובתוככי יש רק טביעת רגל ברגל רבועה כי אתה משלם עבור, בתוך שבו אתה יכול לשים כל דבר שאתה רוצה. ואתה בדרך כלל לשלם עבור החשמל. ואתה משלם עבור עקבות. ואז אתה משלם עצמך עבור השרתים כי אתה מביא להיכנס לחלל הזה. ומה לאחר מכן יש אפשרות לעשות הוא לשלם למישהו עבור קישוריות שירותי האינטרנט שלך. ניתן לשלם כל מספר של ספקים, שלכולם בדרך כלל נכנסים כי מרכז הנתונים. אבל השאלה המעניינת האמיתית היא, מה הולך למעשה על המדפים האלה? הם עשויים טובים ויפים נראה כמו מה שזה עתה ראינו. אבל הם ממלאים פונקציות שונות אולי צריך לעשות דברים שונים. ובואו למעשה להניע את הדיון הזה בשאלה, מה הבעיה מתחיל להתעורר אם אתה מוצלח? אז יש לך אתר אינטרנט כי שהבנייה. ואולי היא מוכרת יישומונים או משהו כזה. ואתה כבר עושה טוב מאוד עם מכירות של יישומונים מקוונים. ואתה מתחיל לחוות כמה סימפטומים, אתר האינטרנט שלך. מה יכול להיות חלק הסימפטומים הטכניים שמשתמשים מדווחים כעסק גדל ורועם ואת אתר האינטרנט שלך הוא נהנה מזה? קהל: [לא ברור] DAVID מלאן: כן, בדיוק. אז ייתכן שיש לך האטה של ​​האתר שלך. ולמה אולי זה קרה? ובכן, אם נניח, עבור לצורך הדיון עכשיו, כי אתה מחובר לרשת צבאות אינטרנט מסחריים אלה כי דיברנו על לפני ארוחת הצהריים, כי אתה משלם כמה מספר דולרים כדי לחודש, ואתה כבר שילם עבור העלות השנתית של התחום שלך שם, כי האינטרנט המארח הוא כנראה overselling משאביהם במידה מסוימת. אז אולי יש לך את שם משתמש וסיסמא בשרת שלהם. אבל אז אולי כמה אחרים, או מספר עשרות אחרים, או אולי אפילו כמה מאה, משתמשים אחרים. ואתרי אינטרנט לחיות פיסיים על אותו השרת. למה זה אפשרי? ובכן בימים אלה, שירת ככה בדרך כלל יש כוננים קשיחים מרובים, אולי כששת או יותר כוננים קשיחים, ולכל אחת מהן יכול להיות באותה מידה כמו 4 טרה בימים אלה. אז ייתכן שיהיה 24 טרה-בייט של שטח רק שרת אחד קטן כזה. וגם אם אתה גונב כמה שמרחב עבור יתירות, למטרות גיבוי, זה עדיין די הרבה מקום. ובוודאי, אתר טיפוסי לא צריך כל כך הרבה שטח. רק רישום משתמשים ואחסון יומני הזמנות לא לוקח כל כך הרבה שטח. אז אתה יכול לחלק את זה די קצת ולתת לכל משתמש רק פרוסה קטנה של זה. בינתיים, מחשב ככה בימים אלה יש בדרך כלל CPUs-- המרובה ולא רק אחד, אולי שניים, אולי ארבעה, אולי 16, או אפילו יותר. וכל אחד המעבדים האלה יש משהו שנקרא גרעין, שהוא סוג של כמו מוח בתוך מוח. אז למעשה כמעט כל אחד כאן עם מחשבים ניידים מודרניים יש כנראה ליבה כפולה או מרובע ליבה CPU-- וכנראה רק אחד מעבד בתוך מחשב נייד בימים אלה. אבל מחשבים שולחניים מתלה מחשבים כמו עשוי להיות לכך לא מעט מעבד יותר, וב ליבות בתורו. ולמען האמת, אפילו מחשבי מקינטוש ומחשבי שלנו היום, אתה באמת לא צריך כפול ליבות או מרובע ליבות לבדוק את הדוא"ל שלך. אם יש כל צוואר בקבוק כאשר מדובר באמצעות מחשב, אתה האדם הם כנראה דבר איטי על מחשב. ואתה לא הולך להיות מסוגל לבדוק את הדואר האלקטרוני שלך מהר יותר אם אתה יש פי ארבעה מעבדים או ליבות רבים. אבל אותו סוג של אמיתי של שרת. אתר בודד אחד לא יכול בהכרח צריך יותר מאחד CPU או ליבה אחת, אחת מוח קטן בפנים ותעסוק כל החשיבה ואת העיבוד. אז יצרנים יש דומה התחילו לחתוך את המשאבים הללו כך אולי האתר שלך מקבל אחד ליבה, האתר שלך מקבל ליבה אחת, או אולי אנחנו משתפים ליבה אחת כזו. כמו כן, אנו משתפים שטח דיסק. ואנחנו גם משתפים RAM, או זיכרון גישה אקראית מלפני, מתוכם יש גם כמות סופית. וזה המפתח. לא משנה כמה יקר המחשב היה, יש עדיין סופי כמות המשאבים בו. וכך יותר ויותר אתה לנסות לצרוך משאבים אלה, הדברים האיטיים והמתונים יותר עשויים להיות. אבל למה? למה דברים היו להאט בתור סימפטום של שרת להיות עמוס? מה קורה? קהל: [לא ברור] DAVID מלאן: כן, בדיוק. שהצעתי קודם לכן כי RAM הוא סוג של זיכרון. זה נדיפים, לפי זה איפה אפליקציות ונתונים הם מאוחסנים כשהם בשימוש. וכך ולכן יש רק מספר סופי דברים שאתה כנראה יכול לעשות בבת אחת. וזה גם יותר מהר, וזה דבר טוב. אבל זה גם יקר יותר, וזה דבר רע. וזה גם כן נוכח תחתון כמויות מנפח הדיסק, דיסק קשיח מרחב, אשר נוטה להיות זול יותר. במילים אחרות, אתה אולי יש 4 טרה-בתים דיסק של שטח במחשב. אבל ייתכן שיהיו 4 ג 'יגה בייט, או 64 ג'יגה-בייט, ב סדר גודל, גורם של 1,000 פחות, של זיכרון RAM במחשב. אז מה עושה מחשב לעשות? ובכן, נניח שאתה יש 64 ג 'יגה בייט של RAM בשרת כזה, אשר יהיה די נפוץ, אם לא נמוך בימים אלה. אבל נניח שיש לך כל כך הרבה משתמשים עושים כל כך הרבה דברים כי אתה סוג של מעין צריך 65 ג'יגה-בייט של זיכרון כדי להתמודד עם כל זה שימוש בו זמנית? ובכן, אתה יכול פשוט לומר, מצטער, כמה מספר המשתמשים פשוט לא יכול לגשת לאתר. וזה הוא המדד של המוצא האחרון, בהחלט. או שאתה, כמו הפעלה המערכת, כמו Windows או Mac OS או Linux או Solaris או כל מספר מערכות הפעלה אחרות בשרת זה, רק יכול להחליט, אתה יודע מה? יש לי רק 64 ג'יגה-בייט של זיכרון RAM. אני די צריך 65. אז אתה יודע מה? אני הולך לקחת 1 ג'יגה שווה של נתונים ב- RAM זה היה לגשת לאחרונה לפחות ופשוט להזיז אותו בדיסק באופן זמני, להעתיק אותו ממש מהצום זיכרון לזיכרון האיטי כדי שאוכל ואז להתמודד עם זה צורך ג'יגה ה -65 עבור זיכרון, לעשות קצת חישוב עליו. לאחר מכן, כאשר סיימתי עושה את זה, אני רק אזיז כי בדיסק, להזיז את זה RAM האחר שמתי זמנית בדיסק בחזרה לתוך החומרה בפועל כך אני סוג של ריבוי משימות. אז אני סוג של שם את הדברים זמני בחלל איטי זה כך אני יוצר את האשליה של טיפול לכולם. אבל יש האטה. למה? ובכן, חלק פנימי של אלה קשים דיסקים בימים אלה הם מה? במקום זאת, מה שעושה קשה לנהוג שונה RAM כמיטב אתה יודע עכשיו? קהל: [לא ברור] DAVID מלאן: מניח את הדעת, נכון. קהל: [לא ברור] DAVID מלאן: אז נכון מאוד. וזה הוא תופעת לוואי או תכונה העובדה RAM כי הוא אכן מהיר יותר. ולכן אתה רוצה להשתמש בו לשימוש שוטף. ודיסק הוא איטי. אבל זה קבוע, או בלתי-נדיף. אז אתה משתמש בו עבור אחסון לטווח ארוך. אבל במונחים של יישום, אם אני מסתכל למעלה מה שנקרא DIMM, זיכרון Inline Dual מודול, זה מה פיסת זיכרון RAM בדרך כלל עשוי להיראות. אז בתוך Mac-- שלנו זה באג. בתוך של מחשבי מקינטוש ומחשבי שלנו, שולחן העבודה שלנו מחשבים יהיו חייבים מקלות זיכרון, כפי שאתם מכנים אותם, או רכיבי DIMM, או ברכיבי זיכרון בחזרה באותו היום, של זיכרון שנראה כמו זה. המחשבים הניידים שלנו כנראה יש דברים הם שליש בגודל או חצי הגודל. הם קצת יותר קטנים, אבל באותו מעט idea-- פיסות סיליקון ירוק רקיק או פלסטיק יש שבבי שחורה קטנה עליהם עם המון חוטים מקשרים הכל. ייתכן שתהיה חבורה שלמה של אלה בתוך המחשב. אבל ממסעדה כאן היא זה לגמרי אלקטרוני. יש רק אלקטרונים זורם על המכשיר הזה. לעומת זאת, אם נסתכל החלק הפנימי של כונן קשיח ולמשוך תמונה כאן, שהיית במקום רואה דבר כזה, אשר יש חשמל עובר את זה בסופו של דבר. אבל מה גם קופץ החוצה בך על הדבר הזה? קהל: [לא ברור] DAVID מלאן: כן, יש כנראה חלקים נעים. זה כמו סוג של תקליט ישן שחקן או שחקן הפטיפון. וזה פחות או יותר הוא. זה קצת יפה מכל ש-- בעוד שחקן הפטיפון בשימוש חריצי הפרוטוקול, זה בעצם משתמש חלקיקים מגנטיים קטנטנים כי אנחנו לא יכולים לראות די. אבל אם חלקיק מגנטי קטן נראה כך, זה נחשב 1. ואם זה נראה כך, צפון-דרום במקום צפון-דרום, זה יכול להיות 0. ואנחנו נראה מחר כיצד אנו יכולים לבנות מזה דברים מעניינים יותר. אבל דבר זה יש להעביר פיזית ללא ספק הולך לרוץ לאט יותר יותר ממהירות האור, אשר בתיאוריה הוא מה אלקטרונים עשויים לזרום, למרות מציאותי לא ממש. אז מכני devices-- הרבה יותר איטי. אבל הם זולים יותר. ואתה יכול להתאים כל כך הרבה נתונים נוספים בתוך מהם. אז העובדה שיש קיים משהו בעולם נקרא זיכרון וירטואלי, משתמש בדיסק קשיח כזה כאילו היה RAM שקוף למשתמש, פשוט על ידי הזזת נתונים מה- RAM לדיסק הקשיח, ואחר כך הזיז אותה בחזרה כאשר אתה צריך זה שוב, יוצר האטה. כי אתה ממש צריך להעתיק אותו ממקום אחד למשנהו. והדבר שאתה העתקתו ו מן הוא למעשה איטי יותר מאשר זיכרון RAM איפה אתה רוצה שזה יהיה. כאן-- הפתרון החלופי אם אתה לא אוהב את זה להאט, והזיכרון הווירטואלי שלך הוא מין בן שקורסת תחת העומס, מה פתרון אחר לבעיה זו? קהל: [לא ברור] DAVID מלאן: ובכן, להגדיל את הזיכרון הווירטואלי נתנו לנו לעשות את זה על בקנה מידה גדול עוד יותר. יכולנו להתמודד עם 66 ג'יגה בייט שווה הצרכים זיכרון, או 67 ג'יגה-בייט. אבל נניח שאני לא אוהב האטה זו, למעשה אני רוצה לכבות וירטואלי זיכרון אם זה בכלל אפשרי, מה עוד יכולתי לזרוק בעיה זו כדי לפתור את זה, איפה אני רוצה להתמודד עם יותר משתמשים ועוד דרישות זיכרון יש ממה שאני פיזי כרגע? קהל: [לא ברור] DAVID מלאן: למרבה הצער לא. אז המעבד ואת הליבות הם ב הם משאב מוגבל. ואין אנלוגי בהקשר זה. אם כי, שאלה טובה. אז רק כדי להיות ברור, גם אם בתוך המחשב הזה הוא, נניח, מקל של זיכרון RAM שנראית כך-- וכך אנחנו נתקשר RAM זה. ושוב כאן הוא כונן הדיסק הקשיח. ואני רק אצייר זה באופן ציורי כעיגול קטן. ישנם 0 ו -1 בשני נתוני these--, נצטרך להכליל בה. בעיקרו של דבר, אם משתמש הוא הפעלת יישום כמו, נניח, אתר שדורש זו RAM הרבה לכל משתמש, כי מה שאני מציע, בדרך של הדבר הזה נקרא זיכרון וירטואלי, הוא פשוט להעביר באופן זמני כי כאן כל כך שעכשיו אני יצליח להעביר את הזיכרון של מישהו אחר דרישות שם. ואז כאשר זה נעשה, אני יכול להעתיק את זה בחזרה למעלה וזה הולך כאן, ובכך נעים מה שרציתי שם במקום אחר לְגַמרֵי. אז יש רק הרבה switcheroo, הוא takeaway כאן. אז אם אתה לא אוהב את זה, ואתה לא רוצה לשים משהו על הכונן הקשיח, של דבר במה את המובן מאליו הפתרון העסקי של האדם לבעיה, או מהנדס הפתרון, לצורך העניין, גם? קהל: [לא ברור] DAVID מלאן: כן, אני מתכוון פשוטו כמשמעו לזרוק כסף על הבעיה. ולמעשה, זהו מושלם עניין לחלק את הרמה הגבוהה דיונים של מחשוב ענן. בגלל הרבה הוא מונע על ידי החלטות פיננסיות, אפילו לא בהכרח טכנולוגי. אם 64 הופעות של זיכרון RAM הן קטנות מדי, טובות, למה לא לקבל 128 ג 'יגה בייט של זיכרון RAM? למה לא לקבל 256 ג 'יגה בייט של זיכרון RAM? ובכן, למה לא? קהל: [לא ברור] DAVID מלאן: ובכן, זה עולה יותר כסף, בטוח. ואם כבר יש לך חילוף שטח דיסק קשיח, ביעילות, או באופן שקול, שטח דיסק קשיח כך הרבה יותר זול באותה מידה אתה יכול להשתמש בו. אז שוב, יש סחר זה את זה ראינו עוד קודם לכן על הבוקר, שם באמת לא בהכרח תשובה נכונה, יש רק לטוב ולרע תשובה על סמך מה אתה באמת אכפת. אז יש גם מציאות טכנולוגית. אני לא יכול לקנות מחשב, למיטב ידיעתי, עם טריליון ג'יגה-בייט של RAM עכשיו. זה פשוט פיזי לא קיים. אז יש איזה גבול עליון. אבל אם אי פעם אפילו קנו עבור Mac הצרכן או PC, מדי, בדרך כלל יש עקומה זו של תכונות שם עשוי להיות טוב, טוב יותר, ומחשב הטוב ביותר. ואת המחזירה השולית על קניית הדולר שלך המחשב הטוב ביותר לעומת המחשב הטוב יותר לא יכול להיות כמעט הכי גבוה כמו לבלות קצת יותר כסף מקבל את המחשב הטוב יותר על מחשב טוב. במילים אחרות, אתה משלם פרמיה כדי לקבל את החלק העליון של הקו. ומה אנחנו רואים דיון של מחשוב ענן זה מה נפוץ מאוד אלה ימים, ומה חברות כמו גוגל מוקדם לפופולרי, לא שמה עבור ובנייה באמת מפוארת, יקרה מחוזקת מחשבים עם המון המון הכל, אלא לקנות או לבנות די מחשבים אבל המון צנועים מהם, ושימוש משהו שהוא בדרך כלל קנה מידה אופקית נקרא במקום קנה המידה אנכית. אז קנה מידה אנכית פירושו לקבל יותר RAM, דיסק נוסף, יותר מהכל, וכאילו להשקיע אנכי בחומרה שלך כך אתה רק מקבל את למיטב הטובים שבטובים, אבל אתה משלם עבור זה. קנה המידה האופקי הוא סוג של לקבל את דברי רובד תחתונים, מודל הטוב, או אפילו המודל הגרוע, אבל לקבל הרבה מהם. אבל ברגע שאתה מקבל המון them-- למשל, במקרה זה, שרת אינטרנט, אם שרת אחד זה או אינטרנט מארח אחד אינו מספיק, ואז פשוט אינטואיטיבית, פתרון לבעיה זו של עומס או עומס על השרתים שלך גם לקבל הוא שרת גדול או, מה שאני מציע כאן במקום קנה המידה של במאונך כביכול, יהיה, אתה יודע מה? רק לקבל עוד אחד מכל אלה. או אולי אפילו לקבל שליש. אבל עכשיו יצרנו בעיה הנדסית מטבעו של העסק הזה או החלטה פיננסית. מה הבעיה הנדסת עכשיו? קהל: [לא ברור] DAVID מלאן: כן, איך לעשות אתה מתחבר אליהם ו-- מצטער? קהל: [לא ברור] DAVID מלאן: נכון, כי אני עדיין לכם-- אם אני להחזיר אותי לתוך התמונה הזאת, אם זה המחשב הנייד שלי איפשהו באינטרנט, הנמצא כעת בין אותי ואת החברה שאנחנו מדברים עליו, עכשיו אני צריך להבין, שאליה שרת אני שולח למשתמש המסוים הזה? ואם יש משתמשים אחרים, כמו זו, ולאחר מכן זה אחד כאן, ואולי זה הוא משתמש, זה המשתמש הוא B, זה C הוראות, וזה שרת 1, 2, ו 3-- עכשיו תשובה אינטואיטיבית אולי כאן יהיה פשוט, נשלחנו משתמש עד 1 ו- ב 2 ו- C ל -3. ואנחנו יכולים להתמודד עם 3 פעמים כמו משתמשים רבים. אבל זה פשטני מדי. כיצד אתם מחליטים מי לשלוח לאן? אז בואו ננסה למצוא היגיון בתוך זה. אז נניח שמחשבים A, B, ו- C הם לקוחות, ושרתים 1, 2, ו -3 אופקי מדורג שרתים. אז הם פחות או זהים. כולם פועלים באותה תוכנה. וכולם יכולים לעשות את אותו הדבר. אבל הסיבה שיש לנו שלושתם כל כך שנוכל לטפל בשלושה פעמים כל כך הרבה אנשים בבת אחת. אז אנחנו יודעים שלנו דיון לפני הצהריים שיש חומרה שביניהם המחשבים הניידים לבין שירת. אבל אנחנו פשוט יהיו של להכליל עכשיו כמו האינטרנט או בענן. אבל אנחנו יודעים כי בביתי, יש כנראה נתב הביתה. ליד השרתים, יש כנראה שרת נתב, DNS, DHCP. לא יכול להיות שום דבר אנחנו רוצים בסיפור הזה. אז איך אנחנו מתחילים להחליט, כשמשתמשים הולך something.com, באיזה שרת לניתוב למשתמש? כיצד נוכל להתחיל לספר את הסיפור הזה? קהל: איזון עומסים? DAVID מלאן: איזון עומסים. למה אתה מתכוון? קהל: חוזר איפה את השימוש ביותר הוא ואיזה מהם יש את רוב המשאבים הזמינים. DAVID מלאן: אוקיי, אז תן לי להציג סוג של חומרה חדשה שלא אנחנו עדיין דנו, אשר הוא בדיוק זה, איזון עומסים. זה גם יכול להיות רק בשרת. זה יכול להיראות בדיוק כמו זה שראה לפני רגע. איזון עומסים באמת רק פיסת תוכנה שאתה מפעיל על פיסת חומרה. או שאתה יכול לשלם לספק, כמו Citrix או אחר, סיסקו או אחר. ניתן לשלם עבור החומרה שלהם, המהווה איזון עומסי חומרה. אבל זה רק אומר שהם מותקנת מראש איזון עומסים תוכנה על החומרה שלהם מכר אותו לכולכם יחד. אז אנחנו פשוט נצייר את זה בתור מלבן לענייננו. איך עכשיו אני יכול ליישם איזון עומסים? במילים אחרות, כאשר משתמש רוצה בקרו באתר שלי, בקשתם איכשהו או אחר, כנראה בדרך של אלה נתבים שדיברנו עליה קודם לכן, הולך בסופו של דבר להגיע איזון עומסים זה, אשר לאחר מכן צריך לקבל החלטה ניתוב דמוי. אבל זה ניתוב לסוג של מטרה נעלה עכשיו. זה לא רק על מקבל מנקודה א 'לנקודה ב מדובר בהחלטה אשר נקודה B הוא הטוב ביותר בין them-- 1, 2, או 3 במקרה זה. אז איך אני מחליט אם ללכת 1, 2, 3? מה עלול קופסה שחורה זו, אם אפשר לדבר, להיות עושה מבפנים? גם זה עוד דוגמה ב מדע של הפשטת מחשב. אני ממש משכתי איזון עומסים כמו קופסה שחורה בדיו שחורה, בתוך אחד מהם הוא כמה מעניין היגיון, או קסם אפילו, מתוכם צריך לבוא 1 א decision--, 2, או 3. ואת הקלט הוא רק א קהל: [לא ברור] DAVID מלאן: אני מצטער? קהל: [לא ברור] DAVID מלאן: בסדר, איך ניתן לסווג את סוגי העסקאות כאן? קהל: הצגת דף אינטרנט לעומת שאילתות מסד נתונים. DAVID מלאן: מניח את הדעת, זה טוב. אז אולי משתמש זה רוצה להציג דף אינטרנט. ואולי זה אפילו תוכן סטטי, משהו שמשתנה לעיתים רחוקות, אם בכלל. וזה נראה כמו פעולה פשוטה למדי. אז אולי אנחנו פשוט באופן שרירותי, אבל סביר, אומר, שרת 1, המטרה בחיים שלו היא רק כדי לשרת את תוכן סטטי, קבצים כי רק לעתים נדירות, אם בכלל, שינוי. אולי זה את התמונות בדף. אולי זה הטקסט בדף או סוג כזה אחר של דברים מעניינים, דבר הטרנזקציות, דבר דינמי. לעומת זאת, אם משתמש א 'בדיקה מתוך עגלת הקניות שלו או שלה, דורש מסד נתונים, מקום לאחסון ולזכור אותה עסקה, גם אולי כי הבקשה צריך ללכת לשרת 2. אז זה טוב. אז נוכל לטעון איזון מבוסס לסוג בקשות. אחרת איך נוכל לעשות זאת? איזה עוד-- קהל: בהתבסס על השרת של ניצול קיבולת. DAVID מלאן: נכון, על אישור. אז הזכרת קודם לכן, כרים. אז מה אם אנחנו מספקים קלט על [לא ברור] בין שרתי 1, 2, ו -3 כדי איזון עומסים זה כך הם פשוט כל הזמן ליידע שאיזון העומסים מה מעמדם? כמו, היי, איזון עומסים, אני בניצולת של 50%. במילים אחרות, יש לי משתמש חצי ממספר כפי שאני באמת יכול להתמודד עכשיו. היי, איזון עומסים, אני ב -100 ניצול%. היי, איזון עומסים, 0% ניצול. שאיזון העומסים, אם זה מתוכנן בצורה כי יכול לקחת הערות אלה כקלט, הוא יכול ואז להחליט, אווה, מספר 2 הוא ב 100%. הרשה לי לשלוח אין בקשות עתיד אליו מלבד המשתמשים כבר מחובר. הבחור הזה ב 0%. בואו לשלוח הרבה תנועה אליו. הבחור הזה אמר שהוא ב 50%. בואו לשלוח כמה תנועה אליו. אז זה יהיה מרכיב, כי נוכל לקחת עומס בחשבון. וזה הולך להשתנות עם הזמן. אז ההחלטות תשתנינה. אז זה טכניקה ממש טובה, אחד זה נפוץ. מה עוד יכולנו לעשות? ובואו למעשה רק לסכם כאן. אז את ההחלטות כאן יכולות להיות לפי סוג התנועה, אני אקרא לזה. זה יכול להיות מבוסס על עומס. בוא נראה אם ​​אנחנו לא יכולים לבוא עם כמה אחרים. קהל: [לא ברור] DAVID מלאן: מיקום. אז זה אחד טוב. אז location-- כיצד ניתן למנף את המידע הזה? קהל: [לא ברור] DAVID מלאן: אה, זה טוב. ועל כמה אלפיות שניים זה היה ירידה של על סמך מה שראינו זה הבוקר, היית אומר? קהל: [לא ברור] DAVID מלאן: ובכן, המבוסס על נתיבי עקבות ראינו קודם לכן, וזה רק מידה של משהו מחוספס, לפחות כמה זמן זה לוקח עבור נתונים להגיע מנקודה א 'ל-ב' מרגיש כמו כל דבר היה מקומי, מה, כמו 74 אלפיות השנייה, פלוס מינוס? ואז משהו 100 פלוס, 200 פלוס היה כנראה בחו"ל. וכך על בסיס זה לבד, נראה סביר להניח כי עבור משתמש בארה"ב כדי לגשת לשרת אירופאי עלול לקחת פעמיים או שלוש פעמים כל עוד, אפילו אלפיות השנייה, ממה שזה עשוי לקחת אם כי השרת אותר כאן גיאוגרפית, או להיפך. לכן, כאשר הצעתי מוקדם יותר באותו במיוחד ברגע שאתה לחצות את אלפית שנייה 200 סף, פחות או יותר, בני אדם מתחילים לשים לב. ואת מסלול הזכר הוא רק בהנחת נתונים גולמיים, לא מעניינים. כאשר יש לך אתר אינטרנט, אתה צריך לקבל המשתמש הוריד תמונות או סרט קבצים, כמות גדולה של טקסט, בבקשות הבאות. ראינו כשביקרנו, מה היה זה, פייסבוק או אמזון מוקדם יותר, יש המון דברים כי צריך להיות הורדה. אז זה הולך להוסיף למעלה. אז רבות-שניות אולי לא בלתי סביר. אז טוב, הגיאוגרפיה היא מרכיב אחד. אז בחברות למעשה כמו Akamai, אם שמעת מהם, או אחרים לקחו זמן גיאוגרפיה בחשבון. ומתברר כי מטבעו של כתובת ה- IP, כתובת ה- IP של המחשב הנייד שלי, אתה יכול להסיק, עם הסתברות כלשהי, היכן אתה נמצא בעולם. ואכן יש שירותי צד שלישי אתה יכול לשלם מקיימי מסדי נתונים של כתובות IP ואזורים גיאוגרפיים כי בסבירות גבוהה תהיה כאשר נכון שאל איפה בעולם הוא כתובת ה- IP הזו? וכך למעשה מה חברות אחרות להשתמש בזה? אם אתה צריך Hulu או Netflix, אם יצא לך פעם הייתה נסיעה לחו"ל, ואתה מנסה לראות משהו Hulu, ואתה לא בארה"ב, ייתכן שתראה הודעה אומר, לא בארצות הברית. מצטערים, אינך יכול לצפות בתוכן זה. קהל: [לא ברור] DAVID מלאן: אה, באמת? אבל כן, כך למעשה זה יישום מושלם של משהו מאוד טכני לבעיה בפועל. אם היית VPN מ אירופה או אסיה או בכל מקום בעולם הארגוני שלך המטה בניו יורק או מקום בו אתה נמצא, אתה הולכים ליצור את המראה אתרים מחוץ כי אתה בעצם בניו יורק, למרות שאתה פיזי די רחוק. עכשיו אתה המשתמש הולך יודע שאתה מתרחק ממנו בעליל. אבל אתה גם הולך להרגיש את זה כי מאותם אלפיות נוספים. זה מרחק נוסף ואת הצפנה שקורה VPN הולך להאט דברים. אז היא עשויה או לא להיות חוויה נהדרת. אבל Hulu ו- Netflix הולכים לראות עליך יושב איפשהו בניו יורק, כפי שאתה כבר שלוקטת בבירור. מה פתרון מושלם לזה. בסדר, אז הגיאוגרפיה היא החלטה אחת. מה עוד נוכל להשתמש בו כדי להחליט כיצד לתנועת מסלול מ- A, B, ו- C עד 1, 2, ו -3, שוב, לשים הכובע ההנדסי הנרחב בנושא? כל זה נשמע מאוד מסובך. אה, אני אפילו לא יודע איפה להתחיל ביישום אלה. תן לי משהו יותר פשוט. מהי הדרך הפשוטה ביותר לעשות את ההחלטה הזו? קהל: האם השרת זמין? DAVID מלאן: האם השרת זמין? אז לא רע. זה טוב. זה סוג של nuancing של עומס. אז בואו נשמור כי בקטגורית העומס. אם אתה זמין, אני פשוט הולך לשלוח את הנתונים שם. אבל זה עלול לחזור אליה כבומרנג במהירות. כי אם אני משתמש ההיגיון הזה, ואם אני תמיד שואל 1, מי אתה, מי אתה, אתם נמצאים, ואם התשובה היא תמיד כן, אני הולך לשלוח 100% מכלל התעבורה לו, 0% לכולם. ובשלב מסוים, אנחנו הולכים להכות האטה או אתר זמין. אז מה מעט טוב יותר כי אך עדיין די פשוט כמעט ולא פיקח כמו לקחת את כל נתונים נוספים אלה בחשבון? קהל: עלות לכל שרת. DAVID מלאן: עלות לכל שרת. אוקיי, אז בואו נהפוך כי בקטגורית העומס, מדי. כי מה שתמצאו חברה, מדי-- שאם אתה שדרוג השרתים שלך לאורך זמן או לקנות יותר, ייתכן שלא מסוגל לקבל בדיוק באותו גרסאות של החומרה. כי זה נופל מיושנת. אתה לא יכול לקנות את זה יותר. מחירים משתנים. אז ייתכן שיהיו שרתים שונים באשכול שלך, אם אפשר לומר כך. זה לגמרי בסדר. אבל החומרה של השנה הבאה עשוי להיות פי שניים יותר מהר, פעמים כמסוגלות כשינה של זה. אז אנחנו יכולים לזרוק כי לקטגורית העומס. לולאת המשוב הזה בין 1, 2, ו -3 איזון העומסים בהחלט יכול להגיד את זה, היי, אני בתפוסה של 50%. אבל דרך אגב, אני גם יש כפליים ליבות רבות. השתמש במידע זה. אפילו simpler-- וזה הולך להיות נושא במדעי המחשב. במקרה של ספק, או כאשר אתה רוצה פשוט פתרון שעובד היטב באופן כללי לאורך זמן, לא בוחר באותה השרת כל הזמן, אבל choose-- קהל: אחד אקראי? DAVID מלאן: --a שרת אקראי. כן, לבחור אחת או אחרת. אז אקראי הוא למעשה מרכיב חזק מאוד זה במדעי המחשב, ו בהנדסה יותר בדרך כלל, במיוחד כאשר אתה רוצה לקבל החלטה פשוטה במהירות בלי לסבך אותו עם כל של חכם מאוד אלה, אלא גם מאוד חכם, פתרונות הדורשים כל ההנדסה יותר, כל יותר מחשבה, כאשר באמת, למה לא אני פשוט סוג של יטיל מטבע, או שלוש צדדיים מטבעות במקרה זה, ולהחליט אם ללכת 1, 2, 3? זה יכול לגרום לתוצאה לא רצויה הסתברותי, אבל הרבה כמו הסיכויים של מרפרף ראשי שוב שוב ושוב ושוב ושוב ושוב הוא אפשרי סופר reality--, סופר סביר. אז לאורך זמן, רוב הסיכויים הם סתם שולחים משתמשים באופן אקראי עד 1, 2, ו -3 הולך יסתדר בסדר גמור. וזו טכניקה הידועה בשם רובין בסיבוב. או בעצם, זה לא רובין בסיבוב. זו תהיה הגישה האקראית. ואם אתה רוצה להיות אפילו קצת יותר פשוט, רובין בסיבוב יהיה, האדם הראשון הולך ל -1, האדם השני ל 2, בגוף שלישי עד 3, האדם הרביעי עד 1. וכאן טמון רובין בסיבוב. אתה פשוט סוג של ללכת סביב במחזור. עכשיו, אתה צריך להיות חכם על זה. אתה לא צריך בעיוורון לשלוח למשתמש מספר שרת אחד אם מה שקורה? אם זה בתפוקת המקסימום, או זה פשוט כבר לא מגיב. אז באופן אידיאלי אתה רוצה קצת חוקי מכניקת הקוואנטים. אחרת, אתה פשוט לשלוח את כל של המשתמשים שלך למבוי סתום. אבל זה יכול להילקח בחשבון גם. אז לא תחת להעריך את הערך של רק אקראי, וזה די קרובות פתרון מיני בעיות אלה. ואנחנו נרשום רובין בסיבוב. אז איך כמה חברות ליישם רובין או אקראי עגולים או כל אחת מן ההחלטות הללו? ובכן לצערי, הם לעשות דברים כאלה. תן לי להרים עוד מסך מהיר. למעשה, בוא נעשה את שני. אני לא יודע למה אנחנו מקבל את כל הכלים האלה. זה מוזר מאוד. בסדר, מה אני באמת רוצה הוא מסך. זה מוזר. בסדר, אז אני יכול לזייף את זה. אני לא יודע כמה רחוק אני רוצה לשמור על גלילה. אז מאוד נפוץ, אתה תמצא את עצמך בכתובת כמו www.2.acme.com, אולי www.3 או 4 או 5. לפקוח עין על זה. אתה לא רואה את זה, כי לעתים קרובות. אבל כאשר אתה עושה, זה סוג של נוטה להיות חברות גדולות, מבוגרים, stodgier כי מבחינה טכנולוגית לא באמת נראה לדעת מה הם עושים. ואתה רואה את זה על חברות טק לפעמים, המבוגרים. אז מה הם עושים? כיצד הם מיישמים איזון עומסים, האם זה נראה? אם אתה מוצא את עצמך בתור הקלדה המשתמש www.something.com, ופתאום אתה נמצא בבית www.2.something.com, מה יש עומס שלהם איזון כנראה לעשות? קהל: [לא ברור] DAVID מלאן: כן, כך איזון עומסים הוא כנראה קבלת החלטה המבוססת על אחד אלה החלטות processes-- לא ממש משנה איזה. אבל הרבה כמו שרטטתי את מספר על המנהלים כאן, השרתים הם לא רק קרא 1, 2, ו -3. הם בטח בשם www1, www2, www3. ומתברר כי החלק הפנימי של בקשת HTTP היא תכונה זו. ואני הולך לדמות זו כדלקמן. אני הולך לפתוח עוד באותו כרטיסיית רשת מפתח כמו קודם רק כדי שנוכל לראות מה קורה על מתחת למכסה המנוע. אני הולך לנקות את המסך. ואני הולך ללכת, בוא אומרים, http://harvard.edu. עכשיו מסיבה מסיבות עסקיות, הרווארד חליטה, כמו רבים, אתרי אינטרנט רבים אחרים, לתקנן שלה אתר על www.harvard.edu הוא טכני וסיבות שיווק. זה פשוט סוג של ב באופנה לקבל את www. אז השרת בהרווארד יש איכשהו להפנות את המשתמשים, כמו שאני אומר כל הזמן, מן כתובת אתר אחד אל השני. איך זה עובד? ובכן, תן לי ללכת קדימה והקש Enter. ושימו לב את כתובת האתר אכן במהירות שונה ל www.harvard.edu. תן לי לגלול אחורה זה ההיסטוריה ולחץ על באגים זה מידע אבחוני, אם תרצה. תן לי להסתכל לבקשה. אז הנה הבקשה עשיתי. ושימו לב שזה עולה בקנה אחד עם סוג של לבקש עשיתי של פייסבוק לפני. אבל לב התגובה. מה השתנה התגובה הפעם? קהל: [לא ברור] DAVID מלאן: כן, אז זה לא בסדר 200. זה לא 404 לא נמצא. זהו 301 הועבר לצמיתות, אשר סוג הוא על דרך מצחיקה לומר, הרווארד מעלה ועבר במקום אחר כדי www.harvard.edu. 301 מסמל מדובר הפניה. וכדי איפה כדאי המשתמש כנראה להיות מנותב? קיימת ידיעה נוספת של מידע פנימי המעטפה. ובכל שורות אלה יהיו עכשיו להתחיל לקרוא כותרת HTTP. הכותרת היא רק ערך מפתח pair-- משהו נקודתיים משהו. זוהי פיסת מידע. איפה כדאי החדש מיקום להיות כנראה? שים לב לקו האחרון בין כל כותרות אלה. קהל: [לא ברור] DAVID מלאן: כן, אז יש מידע נוסף. השורה הראשונה כי הדגשתי אומר 301 הועבר לצמיתות. טוב, אז לאן הוא עבר? Line-- האחרון והם לא צריך להיות בסדר הזה. זה יכול להיות אקראי. מעי גס מיקום אומר, היי הדפדפן, עבור אל כתובת האתר שלו. אז דפדפנים להבין HTTP מפנה. וזה מאוד, מאוד דרך נפוצה של הקפצה המשתמש ממקום אחד למשנהו. לדוגמא, אם ניסית פעם לבקר באתר כי אתה לא מחובר, ייתכן פתאום מוצא עצמך בכתובת אתר חדש לגמרי להיות שתתבקש להתחבר. איך זה עובד? השרת כנראה שולח 301. יש גם מספרים אחרים, כמו 302, שונים במקצת משמעות, ששולח לך אתר אחר. ואז השרת, פעם שהתחברת, אשלח לך בחזרה למקום שבו אתה בעצם התכוונת. אז מה, אם כן, הם גרועים אתרי מהונדסים עושים? כאשר אתה מבקר www.acme.com, והם פשוט יקרה יש שם השרתים שלהם www1, www2, www3, וכן הלאה, הם מאוד simply-- וזה הוגן, אבל מאוד מעין foolishly-- הפניית לך שרת ממש שונה בשם. וזה עובד בסדר גמור. זה נחמד וקל. ראינו איך זה יהיה נעשה מתחת למכסה המנוע במעטפה הווירטואלית. אבל למה הוא לטעון את זה החלטת הנדסה רעה? ולמה אני סוג של התנשאות לקראת הנדסה המסוימת הזה גִישָׁה? להתווכח למה זה רע. בן? קהל: [לא ברור] DAVID מלאן: כל שרת יצטרך יש עותק משוכפל של האתר. אני בסדר עם זה. ואכן, זה מה שאני נניח עבור כל הסיפור הזה, כיוון שאם אנו wanted-- היטב למעשה, למעט דן קודם לכן הצעה, שבו אם אתה צריך שונה שרתים עושים דברים שונים, אז אולי הם באמת יכולים להיות מבחינה תפקודית עושה דברים שונים. אבל גם אז, בשלב כלשהו, ​​שלך נתונים הולכים לקבל עמוס. שרת הנכסים סטטיים שלך הולך לחטוף עמוס. אז בשלב מסוים, אנחנו חזרה על הסיפור הזה, שבו אנחנו עליך להדפיס מספר עותקים של אותו הדבר. אז אני בסדר עם זה. קהל: [לא ברור] DAVID מלאן: אוקיי, אז כמה דפים יכול להיות פרופורציונלי פופולרי. וכך להתקבע על כתובת אחת זה לא הדבר הכי טוב בהכרח. [לא ברור]? קהל: [לא ברור] DAVID מלאן: מה אתה מתכוון לעשות את זה? קהל: [לא ברור] DAVID מלאן: כן, בדיוק. אז אתה לא רוצה בהכרח לכם-- אתה בהחלט לא רוצה שלמשתמשים שלך הקלדת www1 או www2 ידני. מנקודת מבט מיתוג, זה פשוט נראה קצת מגוחך. אם אתה רק רוצה מין ניסיון נקי, אלגנטי, שיש מעין אלה של אקראי כתובות ממוספרות ממש לא טובה. כי אז משתמשים בוודאי הם הולך להעתיק ולהדביק אותם לתוך מיילים או הודעות מיידיות. עכשיו הם ומתפשטים. עכשיו אתה סוג של מבלבל שלך פחות קהל טכני, שחושב כתובת האינטרנט שלך היא www2.something.com. אין סמנטיקה משכנעת לזה. זה פשוט קורה להיות שבבסיס פרט טכני, כי אתה כבר ממוספרים השרתים שלך בדרך זו. ובכל זאת גרוע, מה אם, למשל, אולי בסביבות חג המולד בתקופה שבה עסק ממש פורח, יש לך www1 דרך www99, אבל בחודשים ינואר ופברואר ו ואילך, תכבה מחצית מאלו אז אתה רק צריך www1 דרך www50? מה המשמעות עכשיו כי מאוד החלטה עסקית סבירה? קהל: [לא ברור] DAVID מלאן: אתה צריך לנהל את כל אלה עדיין. קהל: [לא ברור] DAVID מלאן: בדיוק. זה סוג של מלכוד שם. אם הלקוחות שלך הם נוהגים דברי סימניות, שליחתם בדוא"ל, רק להציל את כתובת האתר איפשהו, או אם זה רק ב אוטומטי שלהם להשלים בדפדפן שלהם ולכן הם לא ממש להקליד את זה בכוונה, זה פשוט קורה, הם עלולים, במשך 11 חודשים מתוך השנה ביעילות, יגיע למבוי סתום. ורק המחוכם ביותר משתמשים הולכים לממש, אולי אני צריך באופן ידני למחוק את המספר הזה. אני מתכוון, זה פשוט לא הולך לקרות עם משתמשים רבים, כך רעים לעסקים, הנדסת יישום רעה חכמה. אז תודה לאל, זה אפילו לא הכרחי. מתברר שמה מאזני עומסים יכולים לעשות במקום הוא אומר, כאשר עושה request-- היי A, ללכת 1. במילים אחרות, במקום לשלוח הפניה כי כך צעד אחד זו התהליך הוא תוך כדי תנועה כאן, הוא אמר אז ללכת למקום אחר. וכך שלב שלישי, הוא ילך למקום אחר. אתה יכול במקום להמשיך במסלול, כדי להמשיך להשתמש במונח זה, כל הנתונים של א דרך איזון עומסים, כך שהוא מעולם קשר 1, 2, או 3 ישירות. כל התנועה מקבל "מנותב" על ידי לטעון איזון עצמה. אז עכשיו אנחנו מעין בכוונה טשטוש הגבולות בין התקנים שונים אלה. איזון עומסים יכול נתוני מסלול. זה פשוט פונקציה כי יש לו. אז איזון עומסים, גם זה פיסת תוכנה, באמת. וגם נתב הוא פיסת תוכנה. ואתה יכול בהחלט להיות שתי פיסות תוכנה בתוך של מחשב פיזי אחד כך עומס איזון יכול לעשות מספר דברים אלה. אז יש עוד דרך אחת כדי לעשות זאת, אשר למעשה חוזר סוג של עקרונות הראשונים של DNS, אשר דיברנו על לפני ההפסקה. DNS היה מערכת שמות תחומים. זכור כי אתה יכול לשאול שרת DNS, מה כתובת ה- IP של google.com, facebook.com? ואנחנו באמת יכולים לעשות את זה. כלי שאנחנו לא השתמשנו קודם לכן הוא אחד זה נגישות באותה מידה, קרא nslookup, בחיפוש מידע על השרת שם. ואני רק הולך להקליד facebook.com. ואני רואה כי ה- IP של פייסבוק הכתובת היא כנראה זו. תן לי ללכת קדימה ולהעתיק כי, ללכת דפדפן, וללכת http: // וכי כתובת IP והקש Enter. ואכן, נראה לעבוד. עכשיו בהילוך חוזר, מה היה בתוך המעטפה הווירטואלית כי פייסבוק הגיבה כאשר ביקרתי כי כתובת IP באופן ישיר? בגלל ההודעה, איפה אני עכשיו? איפה אני עכשיו, את הכתובת? קהל: [לא ברור] DAVID מלאן: בשעה לגרסה המאובטחת, ובבית www.facebook.com. אז זה אפילו לא רק כתובת IP מאובטחת. פייסבוק לקח את זה על עצמה לומר, זה מגוחך. אנחנו לא הולכים כדי להשאיר אותך על זה URL הנראית מכוערת זה מספרי. אנחנו הולכים לשלוח לך HTTP להפנות בדרך של אותו בכותרת כי ראינו before-- מעי גס מיקום משהו. וכך זה פשוט אומר כי מתחת למכסה המנוע הוא עדיין כתובת IP זו. כל מחשב באינטרנט יש כתובת IP, זה היה נראה. אבל אתה לא בהכרח צריך לחשוף כי למשתמש. ובדומה חזרה היום, יש היה 1-800-לאסוף, 1-800-C-O-L-L-E-C-T, בארה"ב, היה איזו שהיא דרך לעשות גוביינא קורא באמצעות טלפון מאוד בקלות בלתי נשכח מספר, או 1-800-MATTRESS לקנות מיטה, ו זכרוניות דומה, כי אתה אפילו לראות בטלפון סוג של מעין עדיין, כי אותיות map למספרים. עכשיו, מדוע זה כך? ובכן, זה הרבה יותר קל לזכור 1-800-MATTRESS או 1-800-COLLECT במקום של 1-800 משהו משהו משהו משהו משהו משהו משהו, כאשר כל אחד מאלה הוא ספרות. באופן דומה, העולם למד מהר כי אנחנו לא צריכים יש אנשים לשנן כתובות IP. זה יהיה מטופש. אנחנו הולכים להשתמש בשמות במקום. ובגלל זה נולד DNS. בסדר, אז עם זה אמר, במונחים של איזון עומסים, בואו ננסה yahoo.com. ובכן, זה מעניין. יאהו נראה שהוא שב שלוש כתובות IP. אז להסיק מכך, אם אתה יכול, מה הוא דרך אחרת שנוכל ליישם הרעיון הזה של איזון עומסים אולי אפילו בלי להזדקק פיזית המכשיר, המכשיר הפיזי החדש הזה? במילים אחרות, האם אני יכול לקחת את מימון יש לך עבור איזון העומסים ולהגיד לך להשתמש בחלק קיים חתיכת חומרה ליישם הרעיון הזה של איזון עומסים? ואת ספוילר הוא, כן, אבל מה, או איך? מהו יאהו אולי עושה כאן? כרים? בסדר, כריס? קהל: [לא ברור] DAVID מלאן: כן, כל שלוש של עבודה אלה. אז אקראי, רובין בסיבוב, location-- אתה יכול פשוט למנף חתיכה קיימת של הפאזל כי דברנו קודם לכן של DNS מערכת ופשוט לומר, כאשר הראשון המשתמשים של היום מבקש yahoo.com, לתת להם את כתובת ה- IP הראשונה, כמו זה שהסתיים ב -45 שם למעלה. ובפעם הבאה בקשה של משתמש כתובת ה- IP של yahoo.com ממקום כלשהו בעולם, לתת להם את IP השני, אז ה- IP השלישי, אזי IP הראשון, אז השני. או להיות חכם על זה ולעשות את זה בצורה גרפית. או לעשות את זה באופן אקראי ולא רק לעשות זה סיבוב רובין בדרך זו. וגם במקרה הזה, אז אנחנו אפילו לא צריכים להציג שחור זה תיבה לתמונה שלנו. אנחנו לא צריכים מכשיר חדש. אנחנו פשוט אומרים מחשבים ללכת אל שרתי ישירות, ביעילות, אבל לא בדרך של שמם. הם אף פעם לא צריכים לדעת את שמו. הם פשוט אמרו לו yahoo.com מפות לכל באחת מכתובות ה- IP הללו. אז הוא שולח את הבקשה בדיוק. אבל על החלק החיצוני של את המעטפה, זה פשוט מעמיד את IP שזה נמסר. ובדרך זו גם יכול אנו לטעון לאזן את הבקשות רק על ידי שליחת את המעטפה אל שונה אחד השרתים עצמו של יאהו? ואם אנחנו ממשיכים לחפור, נראים כנראה חברות אחרות עם יותר. CNN יש שני גלויים לציבור. ובעצם אם אנחנו עושים את זה שוב ו again-- cnn.com-- אתה יכול לראות הם משני סדר, בעצם. אז מה המנגנון CNN משתמש, כנראה? קהל: אקראי. DAVID מלאן: ובכן, זה יכול להיות אקראי, אם כי נראה רכיבה על אופניים הלוך ושוב. אז זה כנראה סיבוב רובין שם הם פשוט החלפת ההסדר כך שאני כנראה אקח את הראשון. המחשב שלי ייקח הראשון בכל פעם. אז זה איזון עומסים. וזה מאפשר לנו, בסופו של דבר, למפות נתונים, או בקשות המפה, על פני מספר שרתים. אז אילו סוגים של בעיות עם חברה עדיין קיימות? זה מרגיש כאילו אנחנו פשוט באמת פתר בעיה טובה. הגענו משתמשים לשרתים שונים. But-- הו, וכריס, עשה יש לך שאלה לפני? קהל: [לא ברור] DAVID מלאן: לגמרי תלוי. אז מה קורה כאן? ואנחנו באמת יכולים לראות את זה. אז בואו ננסה יאהו. למעשה, בואו נלך אל פייסבוק. כי אנחנו יודעים שאחד מהם יפעל. אז אני הולך להעתיק כי כתובת ה- IP שוב. אני הולך לסגור את כל הלשוניות הללו. אני הולך ללכת פתוח כרטיסיית רשת מיוחדת כאן למטה. ואני הולך לבקר http רק: //. ועכשיו אני הולך על Enter. ובואו לראות מה קרה. אם אני מסתכל כי בקשה, הודעה שפייסבוק my-- הוא דוגמה רעה. כי יש להם טכניקה מפוארת סופר שמסתיר פרט זה מאיתנו. תן לי להשתמש יאהו instead-- http: // כי IP. בואו לפתוח את הרשת שלנו כרטיסייה, לשמר יומן. והנה אנחנו הולכים, Enter. זה מצחיק. אוקיי, אז כאן הוא המסר 404 המפורסם. מה שמצחיק כאן הוא שהם כנראה לעולם לא אחזור. כי יש כנראה לא משהו לא בסדר כשלעצמה. יש להם רק בכוונה החליטה לא לתמוך בצורה מספרית את כתובתם. אז מה אנחנו באמת רואים את כרטיסיית רשת, אם אני מושך את זה כאן, הוא, כפי שאמרתי, 404 המפורסם, שבו אם אני מסתכל על כותרות התגובה, זה מה שקיבלתי כאן-- 404 לא נמצא. אז בואו ננסה אחד אחר. בוא נראה אם ​​CNN משתפת פעולה איתנו. אני אחטוף באחת מכתובות ה- IP של CNN, לנקות זה, http, דה, דה, דה, דה. אז בתשובה כריס שאלה, כי אחד עבד. ובואו נלך כותרות תגובה. למעשה לא, בסדר, אני נאבק כדי למצוא למשל עבודה. אז CNN חליטה, אנחנו פשוט נשאיר אותך בכל מה כתובת אתה מבקר בפועל, בעיות מיתוג בצד. אבל מה לא היה קורה, אם יכולנו לראות את זה במקרה של פייסבוק, שנצליח לגרום לכך הועברו 301 לצמיתות, ככל הנראה, בתוך אחד מהם הוא מיקום: https: //www.facebook.com. ואת רוב הסיכויים הם www.facebook.com הוא כינוי עבור השרת בדיוק אנחנו פשוט הלך ל. אז זה מועיל קצת. אנחנו ממש אתה מבקר בשרת. השרת ואז אומר לנו, נעלם. מעבר לכתובת אחרת זה. אבל אנחנו פשוט כל כך קורים לך להיות חוזר לשרת אותו. אבל כנראה שאנחנו עכשיו להישאר על כי שרת ללא הלוך ושוב זו. כי עכשיו אנחנו משתמשים בשם גרסה של האתר, לא מספרי. שאלה טובה. אוקיי, אז אם אנחנו עכשיו assume-- אנחנו פתור איזון עומסים. עכשיו יש לנו מנגנון, בין אם זה באמצעות DNS, בין אם זה באמצעות הקופסה השחורה הזאת, אם זה באמצעות כל הטכניקות האלה. אנחנו יכולים לקחת בקשת המשתמש פנימה להבין לשרת אשר, 1, 2, או 3, לשלוח לו או לה. מה שמתחיל לשבור על האתר שלנו? במילים אחרות, יש לנו בנה עסק בעבר היה על שרת יחיד אחד. עכשיו העסק שבו פועל על פני מספר שרתים. אילו סוגים של הנחות, אילו סוגים של החלטות עיצוב, עכשיו יכול להיות שביר? זהו פחות ברורים. אבל בוא נראה אם ​​אנחנו לא יכולים לשים שלנו עם יד על חלק מהבעיה שאנחנו כבר שיצרנו לעצמנו. שוב, זה כמו סוג של מחזיק במורד הדליפה בצינור. ועכשיו קצת בעיה חדשה צץ כאן. קהל: [לא ברור] DAVID מלאן: אוקיי, אז אנחנו צריכים להמשיך לגדול שטח הדיסק הקשיח שלנו. אני בסדר עם זה עכשיו. כי אני חושב שאני יכול סולם אופקי. כמו אם אני נחלש, אני רק אביא בשרת הרביעי, אולי בשרת חמישי, ואז להגדיל את הקיבולת שלנו על ידי עוד 30% או 50% או מה שלא יהיה. אז אני בסדר עם זה, לפחות לעת עתה. קהל: [לא ברור] DAVID מלאן: אוקיי, אז זה נקודה טובה. אז תניח השרתים אינם זהים. שירות לקוחות או שווה ערך הדוא"ל הוא מקבל הודעה כמה ממשתמש אומר, זה לא עובד נכון. ייתכן מאוד, לפעמים, אולי כי שרת אחד או יותר הוא מתנהג קצת השתבש, אבל לא האחרים, אשר יכול בהחלט להקשות לרדוף אחרי הנושא. ייתכן צריך להסתכל במספר מקומות. כלומר ביטוי מסוג אחר של באג, וזה כי אתה כנראה צריך עצב מערכות תשתית כדי כל מה שהוא באמת זהה. אבל זה עושה לחשוף בעיה חדשה כי לא היה לנו קודם. מה עוד? קהל: [לא ברור] DAVID מלאן: כן, יש עוד מורכבות. יש פיזית יותר חוטים. יש עוד מכשיר. למעשה, אני כבר הצגתי יסוד קונספט בעיה בסיסית כאן המכונה נקודה אחת כישלון, אשר, אפילו אם אף פעם לא שמעתי את הביטוי, אתה יכול כנראה עכשיו לעבוד לאחור להבין את זה. מה זה אומר שיש לי אחת נקודת הכשל באדריכלות שלי? ועל ידי ארכיטקטורה, אני פשוט אומר את הטופולוגיה של זה. קהל: [לא ברור] DAVID מלאן: כן, מה אם שאיזון העומסים יורד? אני מוכנס איש באמצע זה שאת מטרה בחיים היא לפתור בעיה. אבל אני כבר הצגתי בעיה חדשה. דליפה חדשה צצה בצינור. כי עכשיו אם איזון העומסים מת או נשבר או misfunctions, עכשיו אאבד את הגישה כל שלושת השרתים שלי. ולפני, עשיתי לא יש מתווך זה. וכך מדובר בבעיה חדשה, שיש הטוענים. אנחנו נחזור כיצד נוכל לתקן את זה. קהל: [לא ברור] DAVID מלאן: זה יהיה גישה אחת. כן, אז זה הולך להיות די של חור-עכברים אנחנו מתחילים לרדת. אבל בואו לחזור כי בעוד רגע. איזה בעיות אחרות יצרנו? אז דן ציין באתר לפני. וגם אם אתה לא מוכר מדי מבחינה טכנית, מסד נתונים הוא רק לשרת שבו שינוי נתונים מאוחסנים בדרך כלל, אולי מישהו כדי הציב, פרופיל המשתמש שלך, את שמך, כתובת הדוא"ל שלך, דברים שעשויים להיות שהוזנו או השתנה לאורך זמן. בעבר, מסד הנתונים שלי היה על אותו שרת כמו שרת האינטרנט שלי. כי הייתי אחרי אחד חשבון אירוח אתרים. הכל היה כל באותו המקום. איפה אני צריך לשים באתר שלי עכשיו, בשרת 1, 2, או 3? קהל: 4. DAVID מלאן: 4, אישור, כל בסדר, אז בואו נלך לשם. אז אני הולך לשים שלי database-- ובואו להתחיל תיוג www אלה, www, www. ואני הולך להגיד, זהו מספר ארבע. ואני אגיד db עבור מסד הנתונים. בסדר, אני אוהב את זה. מה קו אני צריך ככל הנראה להיות ציור כאן? קהל: [לא ברור] DAVID מלאן: כן, אז את הקוד, כפי נדברנו מחר, ככל הנראה זהה על כל שלושת השרתים. אבל זה עכשיו צריך להתחבר לא אל מסד נתונים פועלים באופן מקומי אך במקום אחר. וזה בסדר. אנחנו יכולים רק לתת מסד נתונים שם, כמו שיש לנו, או מספר. ושכל עובד מצוין. אבל מה עשינו? שמינו מדורגים אופקיים על ידי בעל שלושה שרתים במקום אחד, אשר זה טוב. כי עכשיו אנחנו יכולים להתמודד עם פי שלושה עומס רב. וזה יותר טוב, אם אחד או שניים מאותם השרתים יורדים, העסק שלי יכול להמשיך לפעול. כי אני עדיין יש אחד, גם אם אני סוג של צולעת ביצועים חכמים. אבל מה בעיה חדשה יש לי הוצג על ידי הזזת המסד לשרת נפרד זה במקום ב -1, 2, ו -3? קהל: [לא ברור] DAVID מלאן: כן, אז עכשיו יש לי עוד נקודת כשל יחידה. אם מסד הנתונים שלי מת, או צריך ישודרג, או מה שלא יהיה, עכשיו בטוח, האתר שלי הוא מקוון. ואני יכול לשרת סטטי, תוכן משתנה. אבל אני לא יכול לאפשר למשתמשים להתחבר או שינוי משהו או משהו כדי, עדיין גרוע. כי אם 4 לא מחובר, אז 1, 2, ו -3 ממש לא יכול לדבר אליו על פי הגדרתו. אישור אז כן, ולכן זו הסיבה אני מהסס לצייר זה. אז בואו לחזור לזה. אני לא מתכוון להמשיך לדחוף אותך. אבל התמונה מאוד מהר הולך לקבל מלחיץ. מכיוון שאתה צריך כדי להתחיל שיש שתיים הכל. למעשה, אם אי פעם ראית את סרט לתקשר לפני כמה שנים עם ג'ודי Foster-- לא? אוקיי, אז עבור שתיים מבינינו ראיתי לתקשר, יש מערכת יחסים יש שם הם למעשה קנה שניים משהו במקום אחד, אם כי ב פעמיים את המחיר. אז זה היה סוג של שובבה להגיב בסרט. זה סוג של קשור לזה. אנחנו בהחלט יכולים לעשות את זה. ואתה רק עלות כסף אותנו כפליים. אבל נחזור לזה. אז שפתרנו זה. אז אתה יודע מה? זה כמו מדרון חלקלק. אני לא רוצה להתמודד עם צורך יש למסד נתונים כפול. זה יותר מדי כסף. אתה יודע מה? אני רוצה שיהיה לי באתר שלי בדיוק כמו בגרסה אחת שבו כל בעל שרת מסד נתונים מקומי משלה. אז אני פשוט הולך לצייר db על כל אחד מאלה. אז עכשיו כל שרת אינטרנט זהה עד כה שכן יש את אותו קוד, אותו נכסים סטטיים, תמונות וטקסט אותו וכן הלאה. ולכל אחד מהם יש מאגר משלה. תיקנתי את נקודה אחת של בעית הכישלון. עכשיו יש לי מסד נתונים. לא משנה איזה שניים או אחד מאלה דברים מתים, תמיד יש אחד שמאלה. אבל מה בעיה חדשה יש יצרתי שהפתרון של דן להימנע? קהל: [לא ברור] DAVID מלאן: כן, אני צריך לסנכרן אותם, נכון? כי גם אני צריך לסנכרן מי הולך where-- במילים אחרות, אם אליס מביקורי אתר, והיא קרתה כדי לקבל אקראי או עגול robined או כל דבר אחר, למספר שרת אחד, לאחר מכן אני חייב תמיד לשלוח אותה לשרת 1. למה? כי אם אני שולח לה לשרת 2, זה הולך להיראות כמו שהיא אינה קיימת שם. אני לא הולך להיות היסטוריית ההזמנות שלה. אני לא הולך להיות בעל פרופיל שם. וזה פשוט מרגיש כמו זה מזמין בעיות. וכאשר בוב מבקר, אני צריך לשלוח אותו תמיד לאותו שרת, 2, או לפי אחד, וצ'רלי על שליש, ובעקביות. זו אינה בלתי סבירה, אם כי. זה נקרא חלוקת מסד הנתונים שלך. ואכן זה היה מה פייסבוק עשה בשלב מוקדם. אם ביצעת את ההיסטוריה של פייסבוק, זה התחיל כאן בקמפוס כמו www.thefacebook.com. ואז זה התפתח פעם מארק התחיל הפצת לתוך קמפוסים אחרים להיות harvard.thefacebook.com ו mit.thefacebook.com, וכנראה bu.thefacebook.com, וכיוצא באלה. וזה היה מפני בשלב מוקדם, אני לא חושב אתה יכול להיות חברים ברחבי הקמפוסים. אבל זה בסדר. מכיוון שכל אחד מהרווארד נשלח לשרת זה. כל אחד מן BU נשלח לשרת זה. כל אחד מ- MIT נשלח כדי server-- זה בתיאוריה. אני לא ממש מכיר את כל פרטי יישום בסיסיים. אבל הוא כנראה למחיצות אנשים על ידי הקמפוס שלהם, שם הרשת שלהם הייתה. אז זה טוב עד לנקודה שבו אתה צריך שני שרתים עבור הרווארד, או שלושה שרתים עבור הרווארד. ואז כי פשטות סוג של נשברת. אבל זה גישה הגיונית. בואו תמיד לשלוח אליס לאותו מקום, תמיד לשלוח בוב לאותו מקום. אבל מה קורה אם אליס שרת הולך מחובר? בוב וצ'רלי עדיין יכול לקנות דברים להתחבר לאתר. אבל אליס לא יכולה. אז איבדת שליש של בסיס המשתמשים שלך. אולי זה טוב יותר מ -100%? אבל אולי זה יהיה נחמד אם יכולנו עדיין תומכים 100% מהמשתמשים שלנו גם כאשר שליש שלנו שרתי עובר למצב לא מקוון. כדי שנוכל לסנכרן מה? לא משתמש, כשלעצמה, אך מסד נתונים בכל השרתים האלה. אז עכשיו אנחנו די צריכים קצת סוג של קישוריות כאן כך השרתים עצמם יכול sync-- לא בלתי סביר. ואכן, הטכנולוגיה הזו קיימת. בעולם של מסדי נתונים, יש הרעיון של מסדי נתונים האדון והעבד, או עיקרי-תיכוני, שם בין התכונות לא רק הוא לאחסון נתונים ולהגיב עם נתונים, אבל גם רק כדי כל הזמן מסונכרנים אחד עם השני. אז כל פעם שאתה כותב או לשמור משהו מסד הנתונים הזה, הוא גם מיד נופל "משוכפל" כמו גם על מסדי נתונים אחרים. וכל פעם שאתה קורא ממנו, זה לא משנה היכן אתה נמצא. כי אם בתורת הם כבר כל מסונכרנים, הולך לקבל תצוגה זהה של נתונים. אז זה נשמע מושלם. יש חייב להיות איזשהו מלכוד. מה יכול להיות המלכוד? קהל: [לא ברור] DAVID מלאן: כן, כך שלוש פעמים כמו הרבה דברים יכולים להשתבש. זה למציאות. אולי הכול יהיה אותו ברוח. אבל מישהו צריך להגדיר את אלה. יש סבירות גבוהה כי משהו הולך להשתבש. רק combinatorially יש לך דברים נוטים יותר לטעויות. מה עוד הוא רע פוטנציאלי? קהל: [לא ברור] DAVID מלאן: כן, אז סינכרון יכול להיות רע. גם כפי שאתה אולי יודע מגיבויים וכאלה, אם אתה רק בעיוורון ביצוע גיבויים, מה אם משהו עושה להשתבש על מסד נתונים אחד? אתה מוחק משהו שאתה לא צריך. אתה כבר משוכפל מיד כי בעיה בכל מקום אחר. אז ויקטוריה היה גיבויים מדברים-- יהיה דבר טוב כאן. וכך נחזור לזה. וכדי להיות ברור, אנחנו מדברים לא על גיבויים כאן כשלעצמה. אנחנו מדברים על שכפול נכון או סנכרון בין שרתים. הם כולם חיים. הם לא אמורים לשמש גיבויים. קהל: [לא ברור] DAVID מלאן: מה זה? קהל: Higher-- DAVID מלאן: עלות גבוהה. שילשנו את העלות עבור בטוח, אם כי לפחות מבחינת של החומרה. מכיוון מסד נתונים הוא רק פיסת תוכנה. וגם שרת אינטרנט הוא פיסת תוכנה. זה כנראה בחינם ואם אנחנו משתמשים כל מספר של דברים קוד פתוח. אבל אם אנחנו משתמשים משהו כמו אורקל, אנחנו משלמים כסף אורקל יותר לכל רישיונות, או מיקרוסופט עבור גישה. יש חייב להיות איזשהו מלכוד אחר כאן. זה לא יכול להיות זה פשוט. אז לנקודה שלך, אני חושב שזה היה כרים, גיאוגרפיה earlier-- או לא, רומי, היה זה, עבור geography-- מניח שאנחנו להיות חכמים על זה, ואנחנו לשים אחד השרתים שלנו, וכפועל יוצא- מסדי הנתונים שלנו, בארצות הברית, ועוד באירופה, אחר דרום אמריקה, אחר באפריקה, עוד באסיה, בכל מקום שאנחנו אולי כדאי ברחבי העולם. אנחנו כבר יודעים מן העקבות שלנו מסלולים בנקודה A ונקודה B, אם הם רחוקים יותר זה מזה, הולכים לקחת יותר זמן. ואם כמה מכם השתמשו כלים, כמו פייסבוק או טוויטר או כל האתרים הללו בימים אלה, כי כל הזמן משתנים בגלל המשתמשים נתונים שנוצרו, לעתים אם פגע רענן או לפתוח את הדף אותו בדפדפן אחר, אתה רואה גרסאות שונות, כמעט. אתה עשוי לראות מה מצבו של הנמען לעדכן כאן אבל לא כאן, ואז אתה מחדש, ואז זה נראה, ואתה מחדש שוב, וזה נעלם. במילים אחרות, כדאי עין על זה, לפחות אם אתה השתמש חברתי רשתות במיוחד. שוב, רק בגלל נתונים משתנים כל כך מהר, לפעמים שרתים מקבלים מסונכרנים. ואולי זה חלון קטן סופר. אבל 200 אלפיות השנייה, אולי אפילו יותר ש-- זה הולך לקחת קצת לסכום שאינו אפס זמן עבור מסדי נתונים אלה לסנכרן. ואנחנו לא רק מדברים על בקשה אחת. אם לחברה יש אלפי משתמשים להשתמש בו בעת ובעונה אחת, הם עלולים חיץ. במילים אחרות, ייתכן להיות תור או קו המתנה לפני כל אלה בבסיס הנתונים יכול יסונכרנו שאילתות. אז אולי זה בעצם כמה שניות. ואכן זה נכון אני חושב אפילו עד עצם היום הזה עם פייסבוק, לפיה כשהם מסתנכרנים החוף המזרחי כדי החוף המערבי, יש לו לא טריוויאלית עיכוב התפשטות, אם אפשר לומר כך, כי אתה פשוט סוג של צריך לסבול. וכך זה לא כל כך הרבה באג כפי שהוא מציאות שמשתמש שלך עלול לא לראות את הנתונים הנכונים לפחות כמה שניות. אני רואה את זה בטוויטר הרבה למעשה שם לפעמים אני ציוץ בחלון אחד, לפתוח עוד אז לראות את זה כדי לוודא שהוא אכן עלה, וזה עדיין לא שם. ואני צריך סוג של רענן, רענן, reload-- הו, הנה זה בא. וזה לא כי זה לא נשמר. זה פשוט לא מופץ לשרתים אחרים. אז trade-off זה, מדי-- האם אתה באמת רוצה לחשוף את עצמך את הסיכון כי אם המשתמש הולך הסדר שלהם ההיסטוריה, זה לא ממש שם עדיין? אני רואה את זה על בנקים מסוימים. זה תמיד מרגיז אותי כאשר, גם, למשל, אתה יכול ללכת כמו שישה חודשים בלבד בחזרה בדוחות הבנק שלך בבנקים מסוימים, למרות בתיאוריה שייחלצו להיות מסוגל לקבל הכל באינטרנט. הם פשוט לקחת את הדברים לא מחובר לפעמים. לפעמים, יותר מדי-- מה באתר זה? יש one-- הו, זה GoDaddy, אני חושב. GoDaddy, בעת לבדוק קונה שם או משהו מושלם, הם לעתים קרובות ינתנו לך קישור לקבלה שלך. ואם תלחץ זה נכון הקישור משם, זה בדרך כלל לא עובד. זה פשוט אומר, מבוי סתום, שום דבר כאן. וזה גם בגלל אלה עיכובים התפשטות. בגלל מסיבה כלשהי, הם לוקחים קצת זמן למעשה ליצור את זה. אז זה סוג של כמו שאתה רוצה לשלוף את השיער בשלב כלשהו. בגלל כל מה שאתה מנסה לעשות הוא לפתור בעיה פשוטה. ואנחנו להמשיך לברוא חדש בעיות לעצמנו. אז בואו נראה אם ​​אנחנו סוג של יכול לפתוח את זה. מסתבר ששילוב מאגרי מידע על כל שרתי האינטרנט שלך לא באמת בפועל. באופן כללי, מה מהנדס אעשה, או ארכיטקט מערכות, יהיה לקבל שונה שכבות של שרתים. ובדיוק למען המרחב, אני יהיה לצייר את מסד הנתונים שלהם כאן. אנחנו אולי מסד נתונים מספר שרת ארבעה כאן כי אכן יש חיבורים כל השרתים האלה כאן. אז זה יכול להיות הכניסה שלנו בסופו של שכבות, כמו אנשים היו אומרים. וזה יהיה הנדבך העורפי שלנו. וזה רק אומר אלה להתמודד עם המשתמש. ומסדי הנתונים אינם ניצבת המשתמש. אף משתמש לא יכול ישירות לגשת אל מסד הנתונים. אז בואו עכשיו אולי לרדת מסלול ויקטוריה מוצעת. זוהי נקודת כשל יחידה. זה גורם לי אי נוחות. אז מה אולי הפתרון הברור ביותר? קהל: [לא ברור] DAVID מלאן: סליחה, להגיד את זה שוב. קהל: [לא ברור] DAVID מלאן: שרת-ייצור ללא. למה את מתכוונת? קהל: [לא ברור] DAVID מלאן: אה, אוקיי, אז גיבויים. אוקיי, אז נוכל לעשות את זה, בהחלט. ובעצם זה נעשה מאוד נפוץ. זה עשוי להיות מספר נכסים באתר חמש. אבל זה רק מחובר למספר ארבע. ואתם עשויים לקרוא לזה חילוף חם. מסדי נתונים אלה השני יכולים להיות מוגדרים פשוט כל הזמן לסנכרן אחד את השני. וכך, אם ההתקן הזה מת, עבור מה טיפש reason-- הכונן הקשיח מת, מישהו סיורים מעל כבל, כמה תוכנות פגומות ואת נתקע במכונה או crashes-- אתה יכול להיות אדם, פשוטו כמשמעו לנתק אותה מן הקיר ובמקום ותכניס את זה אחד. ואז בתוך, בואו נניח, דקות אחדות, אולי חצי שעה, שחזרת באינטרנט. זה לא נהדר, אבל זה גם לא נורא. ואתה לא צריך לדאוג ואודות בעיות סנכרון. כי הכל כבר נמצא שם. בגלל שיש לך מושלם גיבוי מוכן ללכת. אתה יכול להיות קצת להשתכלל על זה, כמו כמה אנשים עושים לעתים קרובות, שבו אתה אולי יש מספר נכסים באתר ארבעה כאן, מספר נכסים באתר חמש כאן, כי הם מדברים אחד עם השני. אבל יש לך גם זה סוג של arrangement-- וזה בכוונה נראה מבולגן, כי זה הוא-- שבו כל יכול שירת חזיתי לדבר עם כל השרתים העורפיים. וכך אם מסד נתונים זה לא להגיב, שרתי חזיתי אלה יש יש תכנות קוד בהם שאומר, אם אתה לא מקבל חיבור למסד הנתונים הזה, בפריימריז מיד מתחיל מדבר המשני. אבל זה עכשיו דוחף את מורכבות לקוד. ועכשיו המפתחים, התוכנה שלך מפתחים, צריכים לדעת על זה. ואתה מעין אתה קשירת הקוד אתה כותב כדי העורפי שלך בפועל פרטי יישום, אשר מקשה, במיוחד גדול חברה או אתר אינטרנט גדול, שבו אתה לא בהכרח רוצה את למתכנתים יש לדעת איך את מסד הנתונים מהנדסים עושים את עבודתם. אולי אתה רוצה לשמור על תפקידים אלו מעין מובחנת מבחינה תפקודית כך שיש שכבה זו של הפשטה בין השניים. אז איך נוכל לתקן את זה? ובכן, אנחנו סוג של פתרו זו בעיה אחת לפני. למה לא שמנו אחד אלה דברים כאן איפה הוא מדבר בתורו למספר ארבע חמש, כל שרתי האינטרנט חזה לדבר עם מתווך זה, ואת סרסור נתיבים בתורו הנתונים שלהם? למעשה, מה שיכול היה להיות שם טוב הדבר הזה? קהל: [לא ברור] DAVID מלאן: מניח את הדעת, מנהל מסד הנתונים. אבל מה עשוי להיות מונח כי נוכל לעשות שימוש חוזר עבור המכשיר הזה? אנחנו איזון. כן, אז באמת, אני לא להיות הוגן כאן. אז איזון עומסים ירמז כי אנחנו החלפה הלוך ושוב כאן, אשר לא צריך להיות ממש במקרה. אז יש כמה דרכים שנוכל לעשות זאת. אם זהו למעשה איזון עומסים, את הסיפור הוא בדיוק אותו הדבר כמו קודם. החלק מבקש ללכת 4. חלקם ללכת 5. וזה טוב. כי עכשיו אנחנו יכולים להתמודד עם תפוקה כפליים. אבל הקשר הזה כאן הוא סופר חשוב. הם צריכים להישאר כל הזמן מסונכרן ובתקווה הם לא גיאוגרפיים מדי רחוקים אחד מהשני כך שהסינכרון הוא במהותו מִיָדִי. אחרת שאולי יש לנו בעיה. אז זה לא רע. אבל שוב, יש לנו הציג בעיה חדשה. מה הבעיה שיש לי רק מחדש? נקודת כשל יחידה. אז מה הפתרון לזה? אז כמו ויקטוריה מחבבת להוציא כסף, אנחנו יכולים לקחת את הבחור הזה החוצה לעשות זאת. ואני בדיוק הולך להעביר כאן מספיק מקום. וזה הולך להיות קצת מבולגן. אני הולך לשמור על קווי ציור. נניח שכל שורות אלה להיכנס שניהם? שיטה נפוצה מאוד כאן תהיה להשתמש בטכניקה הנקראת דופק לפיו כל המכשירים האלה, מאזני עומסים על ימין ועל שמאל, או מה שאנחנו רוצים לקרוא אותם, אומר כל הזמן, אני חי, אני חי, אני חי, אני חי. אחד מהם כברירת מחדל מעשים כמו בפריימריז. אז כל התנועה מנותבת דרך אחד בצד שמאל, למשל, כברירת מחדל, באופן שרירותי. אבל ברגע הבחור מימין אינו שומע מבחור שמאל יותר, אחד מימין מתוכנת באופן אוטומטי, למשל, להשתלט על כתובת IP של אחד בצד שמאל, ולכן להיות יסודי, אולי לשלוח הודעת דואר אלקטרוני או הודעת טקסט לבני האדם לומר, היי, בפריימריז עזבו לא מחובר. אני אהפוך עיקרי לעת עתה. אז סגן נשיא הופך נשיא, אם אפשר לומר כך. ומישהו צריך ללכת להציל הנשיא, אם אתה רוצה. כי עכשיו יש לנו זמנים נקודת כשל יחידה. אז כפי מסובך או מלחיץ כמו זה אולי נראה להתחיל להיות, זה איך אתה לפתור את הבעיות הללו. אתה זורק כסף על זה. אתה זורק חומרה על זה. אבל לצערי אתה מוסיף מורכב עבורו. אבל התוצאה, בסופו של דבר, הוא כי יש לך הרבה יותר, בתיאוריה, אדריכלות חזקה. זה עדיין לא מושלם. כי גם כאשר אנו לכם-- נוכל יש לא נקודת כשל יחידה. עכשיו יש לנו נקודות כפולות של כישלון. אבל אם שני דברים להשתבש, אשר בהחלט יכול, אנחנו עדיין הולכים להיות מחוברים. וכך נפוץ מאוד תעשייה היא לתאר הזמן עד שלך במונחים של תשיעיות. וזה סוג של המטרה לשאוף הוא 99.999% זמן האתר שלך באינטרנט. או אפילו יותר טוב, להוסיף תשיעית עוד כמה לזה. למרבה הצער, אלה תשיעית הם יקרים מאוד. ובואו בעצם לעשות את זה. אז אם אני פותח מחשבון הגדול שלי שוב, 365 ימים בשנה, 24 שעות ביממה, 60 דקות בשעה, ו 60 שניות בעוד דקה, זה כמה שניות יש בעוד שנה אם עשיתי את זה בצורה נכונה. אז אם אנחנו פעמים זה על ידי 0.99999, זה כמה זמן אנחנו רוצים לשאוף. אז זה אומר שאנחנו צריכים להיות עד שניות רבות במהלך השנה. אז אם אני עכשיו להפחית את הערך המקורי, או ליתר דיוק ערך חדש זה מן הראשון-- 316 שניות, שכמובן הוא חמש דקות. אז אם האתר שלך או החברה שלך היא בטענה "חמש תשיעיות", לפיו אתה עד 99.99% מהזמן, זה אומר שאתה יותר טוב היה חכם מספיק ומהיר מספיק סומק מספיק עם משאבים כי השרתים הם רק מחוברים חמש דקות מתוך השנה. זהו יקרים קשה דבר שיש לשאוף אליו. אז זה סחר הנחה, מדי. 99.999% מהזמן הוא די קשה לתקן ויקר. חמש minutes-- אתה בקושי יכול לקבל לשרת להחליף פיזית משהו השתבש. ובגלל זה אנחנו מתחילים חיווט דברים ביחד יותר מסובכים Apriori כך מחשבים יכול מעין לתקן את עצמם. כֵּן. קהל: [לא ברור] DAVID מלאן: הבעיה יכולה להיות בכל מספר מקומות. ובכל fact-- קהל: [לא ברור] DAVID מלאן: בהחלט, בהחלט. וכמו התמונה מקבל יותר מסובך, זה יכול להיות שרתי אינטרנט. זה יכול להיות הכוח לבניין. זה יכול להיות משהו פיזי, כמו הכבלים יש בלוי או בעט החוצה. זה יכול להיות מסד נתונים אינו מגיב. זה יכול להיות שהם מעודכנים ההפעלה שלהם מערכת ומשהו תלויה. אז יש כל כך הרבה חלקים נעים אחרים. וכך הרבה של הנדסה כי צריך ללכת מאחורי זה באמת רק לסחור offs, כמו איך הרבה זמן, כמה כסף זה באמת שווה, ומה הם האיומים אתה באמת מודאג? למשל, ב קורסים אני מלמד בהרווארד, אנו משתמשים הרבה מחשוב ענן, אשר נתחיל לקחת מבט עכשיו, למעשה, שבו אנו משתמשים Amazon Web Services. רק בגלל זה אחד שהתחלנו איתו. אבל יש יותר ויותר בימים אלה מ- Google ו- Microsoft ועוד. ואנחנו בוחרים במודע לשים את כל של מכונות וירטואליות "הקורסים שלנו, כפי שהם קראו, בבית אני חושב זה מרכז הנתונים וירג'יניה המערבית. רוב התלמידים שלנו במקרה מארה"ב, אם כי יש בהחלט בינלאומית כלשהי. אבל המציאות היא שזה פשוט פשוט וזה זול עבורנו לשים את כל הביצים שלנו בסל וירג'יניה, למרות שאני יודע אם משהו משתבש בווירג'יניה, כפי יש happened-- מדי פעם כמו אם יש הוריקן או מזג אוויר אירוע כזה, אם יש איזה נושא לרשת חשמל או כל כמו-- הנתונים 'הקורסים שלנו עלולים לעבור למצב לא מקוון עבור מספר כמה דקות או שעות או אפילו יותר. אבל את הכמות מורכבת אשר יידרש, ואת סכום הכסף כי היה יידרש, כדי להפעיל את הכול במקביל באירופה או בקליפורניה פשוט לא עושה כל כך הרבה חוש. אז זהו סחר רציונלים מעל, אבל אם הוא מכאיב כאשר אתה בעצם שיש השבתה זה. ובכן, הרשו המעבר של עכשיו כדי כמה פתרונות מבוססי ענן לחלק את הבעיות הללו. כל מה שאנחנו כבר דן עד כה סוג של בעיות הוא שיש היה איתנו במשך זמן מה, אם אתה צריך משלך שירת בחברה שלך, אם אתה הולך למקום-שיתוף למקום כמו מרכז נתונים ולשתף שטח עם מישהו אחר, או בימינו בענן. ומה שיפה הענן הוא שכל הדברים האלה אני ציור לחפצים מוחשיים כעת ניתן נחשב מעין חפצים וירטואליים בענן כי הם מדומה עם תוכנה. במילים אחרות, היום מחשבים, שרתים היום, כמו בתמונה Dell הראיתי קודם, כל כך מהר, יש כל כך הרבה זיכרון RAM, כך כמה מעבד, כל כך הרבה דיסק מרחב, כי אנשים כתבו תוכנת מחיצה כמעט אחד שירת לתוך האשליה של זה שני שרתי להיות, או 200 שרתים, כך שכל אחד מאיתנו לקוחות יש את האשליה שיש פשוט לא חשבון על כמה אינטרנט לארח, אבל המכונה שלנו שאנחנו השכרה ממישהו אחר. אבל זה מכונה וירטואלית ב לכת על שרת אחד Dell, זה שוב יכול להיות למחיצות לתוך שתיים או 200 או יותר מכונות וירטואליות, שכולן לתת למישהו מינהלי גישה, אבל באופן שבו אף אחד מאיתנו יודע או יכול לגשת אחרות וירטואליות מכונה באותה החומרה. אז כדי לצייר תמונה שקופיות של היום, אני זה צולם כאן מאתר אינטרנט קרא דוקר. אז זה קצת יותר פרט ממה שאנחנו צריכים באמת. אבל אם אתה רואה בכך את שלך infrastructure-- אז רק את החומרה שלך, השרתים שלך, מתל, הנתונים מרכז, וכל ש-- שהיית בדרך כלל להפעיל מערכת הפעלה מארחת. אז משהו בהדגשה כמו זה יכול להיות Windows. זה לא יהיה Mac OS. כי זה לא באמת עסק בימים אלה. אז זה יהיה לינוקס או סולאריס או יוניקס או BSD או FreeBSD או כל מספר של מערכות הפעלה אחרות או כי הם בחינם או מסחריים. ואז אתה מפעיל תכנית, תכנית מיוחדת, הנקראת hypervisor, או צג מחשב וירטואלי, VMM. ואלה מוצרים, אם אתה מוכר, כמו VMware או VirtualBox או PC או אחרים וירטואליים. ומה התוכניות האלה עושים בדיוק התכונה שתיארתי קודם לכן. זה יוצר אשליה כי מכונה פיזית אחת יכול להיות מכונות וירטואליות מרובות. וכך קופסאות צבעוניות אלה למעלה הוא ציור תמונה של הבאה. hypervisor זה, זה פיסת תוכנה, קוראים לזה VMware, פועל על כמה אחרים מערכת ההפעלה, קוראים לזה לינוקס, יוצר את האשליה המחשב הפיזי הזה הוא למעשה אחת, שתיים, שלוש מחשבים וירטואליים. אז עכשיו אני כבר קניתי, כבעלים של חומרה זו, מחשב פיזי אחד. ועכשיו אני שוכר אותו שלושה לקוחות. ושלושה לקוחות אלה כולם חושבים יש להם מכונה וירטואלית ייעודית. וזה לא פיתיון מתג. זה יותר שגילוי אתה משתמש במכונה וירטואלית. אבל מבחינה טכנולוגית, כולנו יש שליטה מלאה מנהלית מעל כל אלה אורחים מערכות הפעלה, אשר יכול להיות מערכות כל מספר של הפעלה. אני יכול להתקין כל מה שאני רוצה. אני יכול לשדרג את זה כמו שאני רוצה. ואני אפילו לא צריך לדעת או אכפת הפעלה האחרת מערכות במחשב זה, מכונות וירטואליות אחרות, אלא אם הבעלים של כל האפור הזה דברים הוא להיות קצת חמדן והוא overselling המשאבים שלו או שלה. אז אם אתה לוקח אחד מכונה פיזית ומכירתו כדי לא 200 אבל 400 לקוחות, בשלב כלשהו אנחנו הולכים למעוד לתוך אלה באותו בעיות ביצועים כמו קודם. מכיוון שיש לך רק סופים כמות דיסק RAM וכן הלאה. וזה מכונה וירטואלית רק היא תוכנית זה מתיימר להיות מחשב לכל דבר מלא. אז אתה מקבל מה שאתה משלם עבור כאן. אז תמצא באינטרנט אתה עלול לשלם חברה מכובדת אולי 100 $ לחודש עבור מכונה וירטואלית משלך, או שרת וירטואלי פרטי משלך, שהוא מונח אחר זה. או שאתה עלול למצוא כמה זבוב על ידי בלילה שבו אתה משלם 5.99 $ לחודש עבור מכונה וירטואלית משלך. אבל רוב הסיכויים הם אין לך כמעט כמו הרבה ביצועים זמינים עבורך, כי הם כבר overselling זה כך, ממה שאתה עושה עם גבוה רובד של שירות או הספק הטוב יותר. אז מה זה בעצם אומר לנו? אז תן לי ללכת זה. אני הולך ללכת aws.amazon.com. רק כי יש להם תפריט של אפשרויות נחמד. אבל שיעורים אלה חלים על חבורה שלמה של ספקי ענן אחרים. למרבה הצער, זה בדרך כלל יותר שיווק לדבר מכל דבר אחר. וזה משתנה כל הזמן. אז אתה הולך אתר כזה. וזה באמת לא להגיד לך כמעט כלום. ואפילו אני, כשאני מסתכל על זה, לא באמת יודע מה כל הדברים האלה בהכרח לעשות עד שאני לצלול פנימה. אבל בואו נתחיל בצד השמאל, המחשוב. ואני הולך ללחוץ זה. ועכשיו אמזון יש בכנות מספר עצום של שירותים בימים אלה. אבל אמזון EC2 היא אולי הפשוטה ביותר. אמזון EC2 ייצור עבורנו בדיוק התמונה שראינו לפני רגע. זה איך הם עושים הרבה כספם בענן. נטפליקס ואחרים כנראה הם בענן איתם. זהו כל בדרך כלל מדברי שיווק מטרפה. אז מה שאני רוצה לעשות זה ללכת Pricing-- או ליתר דיוק בוא נלך מופעים ראשון רק כדי לצייר תמונה של זה. אז זה ישתנה לפי ספק. ואנחנו לא צריכים להגיע עמוק מדי לתוך העשבים כאן של אופן הפעולה של כל זה. אבל הדרך אמזון, למשל, שוכר לך מכונה וירטואלית או בשרת בענן הוא שיש להם אלה סוג של שמות מצחיקים, כמו t2.nano, כלומר קטן, או t2.large, כלומר גדול. כל אחד מהם נותן לך גם אחד או שניים מעבדים וירטואליים. למה זה מעבד וירטואלי? ובכן, המכשיר הפיזי אולי יש 64 או יותר מעבד בפועל. אבל שוב, דרך התוכנה, הם יוצרים את האשליה כי מכונה אחת יכולה להיות יחולק למספר משתמשים. אז אנחנו יכולים לחשוב על זה בתור שיש מעבד אחד אינטל או שתיים. זיכויי CPU לכל hour-- הייתי צריך לקרוא את האותיות הקטנות על מה זה בעצם אומר. זה אומר כמה של המכונה אתה יכול להשתמש לשעה לְעוּמַת לקוחות אחרים על החומרה. הנה כמה RAM או זיכרון אתה להתרגל-- או חצי ג'יגה או 500 מגה בייט, או 1 ג'יגה, או 2. ואז האחסון רק מתייחס איזה סוג של דיסקים שהם נותנים לך. יש אחסון שונה טכנולוגיות שהם מציעים. אבל יותר מעניין זה אז יכול להיות המחיר. אז אם אתה CTO או מהנדס ומי לא רוצה להריץ שרת ב שלך המשרד, מכל סיבה שהיא, וזה הרבה יותר מדי מסובך או יקר לקנות שרתים ושיתוף לאתרם לשלם את שכר הדירה בחלק מרחב בכלוב פיזי somewhere-- אתה רק רוצה לשבת ליד המחשב הנייד שלך מאוחר בלילה, להקליד את פרטי כרטיס האשראי שלך, ושרתים להשכרה cloud-- היטב, אנחנו יכולים לעשות את זה כאן. אני הולך לרדת עם-- לינוקס היא מערכת הפעלה פופולרית. ובואו רק לקבל תחושה של דברים. Whoops-- גדול מדי. אז בואו נסתכל על הזעירים שלהם מכונה וירטואלית, אשר נראה כי, לענייננו, מעבד אחד ו 500 מגה בייט של זיכרון RAM. זה די קטן. אבל בכנות, שרתי אינטרנט לא צריך לעשות כל כך הרבה. יש לך מפרט טוב יותר את המחשב הנייד. אבל אתה לא צריך אותם מפרט בימים אלה לדברים. אתם הולכים לשלם 0.0065 $ לשעה. אז בואו נראה. אם יש 24 שעות ביממה, אנחנו משלמים כל כך הרבה לשעה, זה יעלה לך 0.15 $ לשכור כי שרת מסוים בענן. וזה רק ליום אחד. אם נעשה את זה 365-- 57 $ ל לשכור כי שרת מסוים. אז זה נשמע סופר זול. זה גם ביצועים נמוכים במיוחד. אז אנחנו, לקורסים אני מלמד כאן, נוטים להשתמש אני חושב t2.smalls או t2.mediums. וזה אולי יהיה לנו כמה מאות משתמשים, כמה אלפי משתמשים, הכולל. זה די צנוע. אז בואו נראה מה זה יעלה. אז אם אני עושה את זה פעמים עלות 24 שעות כפולות 365, של זה אחד 225 $. ובשביל הקורסים אני מלמד, אנחנו בדרך כלל לרוץ שני פריטים מכל סוג, עבור יתירות וגם עבור ביצועים. אז אנחנו יכולים לבלות, ולכן, 500 $ עבור השרתים כי אולי נצטרך בשנה. עכשיו, אם אתה צריך יותר performance-- בואו נסתכל זיכרון. דיברנו על זיכרון לא מעט. ואם אתה צריך יותר memory-- ו -64 ג'יגה-בייט הוא מספר המשכתי mentioning-- זה כמעט 1 $ לשעה. ואתה די יכול במהירות לראות היכן זה goes-- כך 24 שעות כפול 365. אז עכשיו זה 8,000 $ בשנה עבור שרת די הגון. אז בשלב מסוים, יש נקודת פיתול זה שם החברה יכולנו לבלות 6,000 $ כנראה ולקנות מכונה כזאת ו amortize עלותו מעל אולי שניים, שלוש שנים, החיים המכונים. אבל מה עלול לדחוף אותך בעד או אי אהדה של שוכרים מכונית בענן כזה? שוב, ניתן להשוות זאת, כנראה, לאחד השרתים הללו Dell ראינו בתמונה לפני קצת. קהל: [לא ברור] DAVID מלאן: כן, זה הפוך ענק. כי אנחנו לא קונים את המכונה, אנחנו לא צריכים Unbox זה. אנחנו לא צריכים להרים אותו. אנחנו לא צריכים לחבר אותו אל המדף שלנו. אנחנו לא צריכים לחבר אותו. אנחנו לא צריכים לשלם הצעת חוק החשמל. אין לנו להפוך על מיזוג האוויר. כאשר כונן קשיח מת, אין לנו לנהוג באמצע הלילה לתקן את זה. אין לנו להקים ניטור. אין לנו עם-- והרשימה עוד ארוכה ועל כל הדברים הפיזיים אתה לא צריך לעשות בגלל "הענן". וכדי להיות ברור, מחשוב ענן הוא מונח יתר על מידה מאוד זה. זה באמת רק אומר לשלם למישהו אחר להפעיל שרתים בשבילך, או להשכיר שטח על שירת מישהו אחר. אז המונח "מחשוב ענן" הוא חדש. הרעיון הוא בן עשרות שנים. אז זה די משכנע. ומה עוד אתה מקבל? ובכן, אתה גם מקבל את היכולת לעשות הכל על מחשב נייד בבית. במילים אחרות, כל תמונות שאני פשוט drawing-- וזה לא היה כל כך מזמן שאפילו שזחלתי סביב בקומת שרת חיבור הכבלים עבור כל אחד המקווים שאתה רואה, ושדרוג ההפעלה מערכות וכונני שינוי סביב. יש הרבה פיזי לכל זה. אבל מה שיפה וירטואלי מכונות, כפי שהשם מרמז מין, עכשיו יש מבוססי אינטרנט ממשקים לפיה אם אתה רוצה את המקבילה של קו משרת זה למשנהו, פשוט הקלד, סוג, סוג, לחץ וגרור, ולחץ על שלח, וזהו, יש לך את זה לחווט אותו כמעט. כי הכול נעשה בתוכנה. והסיבה שזה נעשה בתוכנה היא שוב כי יש לנו כל כך הרבה זיכרון RAM וכן הלאה מעבד הרבה העומדים לרשותנו בימים אלה, למרות כל דברים שלוקחים זמן, הוא איטי יותר לנהל את העניינים בתוכנה מאשר בחומרה, בדיוק כמו שזה איטי להשתמש מכנים מכשיר כמו כונן קשיח יותר RAM, משהו טהור אלקטרוני. יש לנו משאבים רבים כל כך העומדים לרשותנו. אנחנו, בני האדם הם סוג של invariantly איטיים. אז עכשיו המכונות יכולות לעשות כל כך הרבה יותר ליחידת זמן. יש לנו את היכולות הללו לעשות דברים כמעט. ואני אגיד לקורסים אני מלמד, למשל, כאן, יש לנו כ אולי תריסר או כך סך של מכונות וירטואליות ככה פועל בכל רגע נתון זמן לעשות דברים חזיתיים, עושה בחזרה דברים סוף. יש לנו את כל האחסון שלנו. אז כל קטעי וידאו, דברים כולל ככה שאנחנו יורים, אנחנו בסופו של דבר לשים לתוך הענן. אמזון שירותים שנקראו Amazon S3, שירות האחסון פשוט שלהם, אשר רק הוא כמו שטח דיסק בענן. יש להם משהו CloudFront שנקרא, אשר הוא, תוכן שירות CDN שירות רשת משלוח, אשר אומר שהם לוקחים את כל הקבצים שלכם בשבילך automagically לשכפל אותו מסביב לעולם. אז הם לא עושים את זה מנע. אבל הפעם הראשונה שאחד בהודו מבקש את הקובץ, הם פוטנציאל יהיה לטמון אותו באופן מקומי. בפעם הראשונה בסין, בפעם הראשונה בברזיל זה יקר, הם יתחילו במטמון אותו באופן מקומי. ואתה לא צריך לעשות שום דבר כזה. וכך הוא כל כך נורא משכנע בימים אלה כדי להזיז דברים בתוך הענן. כי יש לך את היכולת הזו ממש כך שלא צריך אדם עושה כמעט באותה מידה עֲבוֹדָה. ואתה ממש לא צריך כמו רבים בני אדם עושים עבודות אלה anymore-- "אופ", או בתפקידים מבצעיים, יותר. אתה באמת צריך רק מפתחים ומהנדסים פחות מי יכול פשוט לעשות דברים כמעט. למעשה, רק כדי לתת לך תחושה של זה, תן לי ללכת לתמחור המוצר השני כאן. בוא נראה משהו כמו CDN S3. אז זה הוא במהותו קשה הכונן הווירטואלי בענן. ואם אנחנו לגלול למטה כדי pricing-- אז זה 0.007 $ לכל ג'יגה-בייט. ו זה-- איך עושים את זה? אני חושב שזה לחודש. אז אם זה לכל month-- או ליום? דן, הוא זה ליום? זהו לחודש, אישור. אז אם זה לכל month-- מצטער, זה 0.03 $ לחודש. יש 12 חודשים מתוך השנה. אז כמה נתונים שאולי אתה מאחסן בענן? לגיגה הוא לא ענק, אבל אני לא יודע, כמו 1 טרה, כך כמו 1,000 מאלה. זה לא כל כך הרבה. זה 368 $ לאחסן טרה נתונים בענן של אמזון. אז מה הם חלק פשרות, אז? זה לא כולם יכול להיות טוב. שום דבר שדיברנו עליו היום הוא מין ללא לתפוס או בעלות. אז מה רע על ההעברה הכל לתוך הענן? קהל: אבטחה. DAVID מלאן: בסדר, מה אתה מתכוון? קהל: [לא ברור] DAVID מלאן: כן, בטח. והאם אתה באמת רוצה כמה מהנדסים אקראיים ב אמזון כי אתה אף פעם לא תפגוש שיש גישה פיזית למחשבים אלה, ואם הם באמת רציתי, גישה וירטואלית? ואף על פי התיאוריה software-- היטב, הצפנה יכולה בהחלט להגן עליך מפני זה. אז אם מה שאתה אחסון בשרתים שלך הוא encrypted-- פחות דאגה. אבל ברגע אדם יש פיזית גישה למכונית, הצפנה הצידה, ההימורים כל הם סוג של הנחה. אתה אולי יודע מן האתמול כי מחשבים במיוחד, גם אם היה לך את הדברים האלה בשם "סיסמאות BIOS," היו כאשר שולחן העבודה שלך מאותחלת, היית שתתבקש עם סיסמה אין שום קשר עם Windows, אתה יכול בדרך כלל פשוט לפתוח את המארז של המכונה, למצוא סיכות קטנטנות, ולהשתמש משהו שנקרא סוודר ופשוט להתחבר שני אלה חוטים למשך כשני, ובכך השלים מעגל. וזה היה מונע את הסיסמה. לכן, כאשר יש לך גישה פיזית מכשיר, אתה יכול לעשות דברים כאלה. אתה יכול להסיר את הכונן הקשיח. אתה יכול לקבל גישה זה ככה. וכך זה לכן, ב במקרה של Dropbox, למשל, זה קצת מדאיג כי לא רק שהם יש את הנתונים, למרות שזה מוצפנים, יש להם גם את המפתח. דאגות אחרות? קהל: [לא ברור] DAVID מלאן: כן, זה מאוד true-- חברות כמו Google, התפוחים, Microsofts של העולם. ואכן, כמה זמן יש אכלת לארוחת iPhone שלך? כן, פחות או יותר. קהל: [לא ברור] DAVID מלאן: אני מצטער? אתה מבין מי יש iPhone, נכון? קהל: כן. DAVID מלאן: כמה זמן היה לך iPhone שלך? קהל: [לא ברור] DAVID מלאן: אוקיי, אז אפל ממש יודע איפה היית כל שעה של היום בחמש השנים האחרונות. קהל: [לא ברור] DAVID מלאן: איזו היא תכונה נפלאה. קהל: [לא ברור] DAVID מלאן: כן, אבל לסחור את בוודאות. קהל: [לא ברור] DAVID מלאן: כן, זה קל מאוד. קהל: [לא ברור] DAVID מלאן: חסרונות אחרים? קהל: [לא ברור] DAVID מלאן: Absolutely-- מבחינה טכנולוגית, כלכלית, זה די משכנע מעין לזכות לגודל הארגון ולעבור את הכל לתוך הענן כביכול. אבל כנראה שאתה רוצה ללכת עם כמה מן הגדולים דגים, האמזונות, את גוגל, את Microsofts-- Rackspace הוא די big-- ועוד כמה אנשים, ולא בהכרח לעוף על ידי אנשים בלילה שבשבילם זה קל מאוד לעשות סוג של טכניקה זו בימינו. וזה מי שאתה יכול לשלם 5.99 $ לחודש. אבל אתה בהחלט מקבל מה שאתה משלם עבור. כשאתה אומר [לא ברור], אז דברים כמו חמש תשיעיות אלה לבוא, לפיה גם אם מבחינה טכנולוגית אנחנו לא באמת יכולים להבטיח 99.999, אנחנו פשוט לבנות איזשהו של עונש לחוזה כך שאם זה יקר, לפחות יש איזה עלות לנו, הספק. וזה מה שהיית בדרך כלל לקבל אותם להסכים. קהל: [לא ברור] DAVID מלאן: ו סוג אחד של ברכה אפילו הוא שכשאנחנו נכבה, חברות למשל, או אפילו מסוימים, המציאות היא אמזון, יש למשל, כל כך הרבה לקוחות מעצבנים הזה, לקוחות ידועים, הפועל מתוך מרכזי נתונים מסוימים שכאשר משהו באמת משתבש, כמו כוח עליון ומזג האוויר וכאלה, אם יש כל סוג של רע בלי טוב, זה עד כדי כך אתה בחברה טובה מאוד. האתר שלך יכול להיות מחובר. אבל אז הוא חצי כמו של האינטרנט הפופולרי. וכך וזה לטעון קצת יותר טעים ללקוחות שלך אם זה יותר של אינטרנט דבר מאשר דבר acme.com. אבל זה קצת לרמות. אז מבחינת יתר להסתכל, רק כך אנחנו לא פוסלים אחרים, אם אתה רוצה ללכת ל- Microsoft Azure, שהם יש גם לינוקס וכאלה Windows זה דומה של אמזון. אם אתה הולך ב- Google Compute Engine, יש להם משהו דומה גם כן. ורק כדי להשלים את עד שמוצרי העננים הללו, אני אכין אזכור ולו דבר אחד אחר. זהו אתר פופולרי זה נציג של מעמד של טכנולוגיות. אלה רק דיברנו על, אמזון, יהיה IAAS, תשתית כשירות, שבו אתה מעין החומרה הפיזית כשירות. יש SAAS. למעשה, תן לי לרשום אלה. תשתיות IAAS-- כשירות, SaaS, ו PAAS, שהן ראשי תיבות מבלבל להפליא כי אל מתארים שלושה סוגים של דברים שונים. ואת ראשי התיבות עצמם לא ממש משנה. זהו כל הדברים ענן שמנו רק דיבר עליו, חומר ברמה נמוכה יותר, וירטואליזציה של החומרה והאחסון בענן כביכול, בין אם זה אמזון, מיקרוסופט, גוגל, או אחר. Software as a service-- כולנו סוג של משתמש זה. אם אתה משתמש ב- Google Apps ל- Gmail או לוח שנה, כל אחד מאלה מבוססי אינטרנט יישומים שרק לפני 10 שנים היינו יצטרך סמלי לחיצה כפולה על שולחן העבודה שלנו, תוכנה כשירות עכשיו באמת הוא יישום אינטרנט. פלטפורמה בתור שירות מעין תלוי. ודוגמא אחת אני אתן לך כאן בהקשר של ענן computing-- יש חברה אחת כי די בימים אלה פופולריים, Heroku. והם מספקים שירות, פלטפורמה, אם תרצה, שפועל על גבי התשתית של אמזון. והם פשוט לעשות את זה אפילו יותר קל עבור מפתחים ומהנדסים כדי לקבל יישומים מבוססי אינטרנט מקוון. זה כאב, בתחילה, להשתמש שירותי האינטרנט של אמזון ודברים אחרים. כי אתה באמת צריך לדעת ולהבין על בסיסי נתונים ושרתי אינטרנט מאזני עומסים וכל מיני דברים אני פשוט דברתי על. בגלל כל שאמזון עשה הוא לא הנסתרים הללו אתגרי תכנון. הם פשוט וירטואליזציה אותם ולהעביר אותם לתוך הדפדפן, לתוך תוכנה במקום חומרה. אבל חברות כמו Heroku ואחרים ספקי PAAS, פלטפורמה כשירות, הם משתמשים אלו יסודות בעגלה כי רק דיברנו על, והם לבנות קלים יותר להשתמש בתוכנה על גבי זה כך שאם אתה רוצה לקבל מבוססי אינטרנט יישום מקוון בימים אלה, אתה בהחלט צריך יודע איך לתכנת. אתה צריך לדעת Java או Python או PHP או רובה או חבורה של שפות אחרות. אבל אתה גם צריך מקום לשים אותו. ודיברנו קודם על מקבל חברת אירוח אתרים. זה סוג של אמצע שנות ה -2000 כמו גישה מקבל משהו באינטרנט. כיום אתה עלול במקום לשלם למישהו כמו Heroku כמה דולרים בחודש. בעיקרו של דבר, ברגע שיש לך נעשה כמה תצורה ראשונית, לעדכן את אתר האינטרנט שלך, אתה פשוט להקליד פקודה בחלון. ומה שלא הקוד שכתבת כאן במחשב הנייד מיד מקבל מופץ לכל מספר שרתים בענן. ו Heroku מטפלת כל המורכבות. הם מעריכים את כל מסד הנתונים דברים, כל איזון עומסים, כל כאבי הראש כי יש לנו רק כתוב על הלוח, ולהסתיר את כל זה בשבילך. ובתמורה, אתה פשוט לשלם להם קצת יותר. אז יש לך תשתיות אלה שירות, פלטפורמות כשירות, ואז התוכנה כשירות. זה, שוב, זה הפשטה או שכבות. כל שאלות על הענן או בניית תשתית של האדם עצמו? בסדר, זה היה הרבה. למה שלא נלך קדימה לקחת 15 דקות הפסקה שלנו כאן. נחזור עם כמה רעיונות חדשים וקצת על הידיים הזדמנות לפני שהערב נגמר.