DAVID Маланки: Добре, ласкаво просимо назад. Перш ніж зануритися в хмарних обчислень, Я думав, що на хвилину зупинитися якщо є будь-які невирішені питання, або теми, які прийшли під час обіду що, можливо, в даний час становить інтерес. ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: OK. О, добре. ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Ні, звичайно. Добре, добре, сподіваюся, всі ваші проблеми виникають в найближчі години а завтра особливо. Але давайте подивимося, а потім, при якому Останнє обговорення цього питання про створення веб-сайт призводить, в більш загальному плані коли справа доходить до хмарних обчислень, створення серверної архітектури, види рішень що інженери і розробники і менеджери потрібно зробити, коли мова йде робити більше, ніж просто підписавшись на $ 10 в місяць веб-хостингу коли ви насправді хочете, щоб будувати з ваша власна інфраструктура. І ми будемо намагатися, щоб зв'язати цю спину, наприклад, до Dropbox і інші як вони. 

Отже, давайте почнемо розглядати які проблеми виникають у бізнесі отримує хороші і виникають хороші проблеми. Таким чином, в самому простому випадку наявності якась компанія, яка має веб-сервер, Ви могли б мати, скажімо, сервер, ми просто малювати, що виглядає в такий спосіб. І в ці дні, більшість servers-- і давайте фактично поставив картину на це просто так що це трохи менше туманні. 

Так Dell стійки server-- назад в той же день, там були мейнфрейми що взяв цілі кімнати. У ці дні, якщо ви були щоб отримати сервер, його може виглядати трохи щось на зразок цього. Сервери вимірюються в якому називаються стоєчних одиниць, або БПРМ. І один RU становить 1,5 дюйма, який є промисловим стандартом. Так що це виглядає як сервер два RU. Так що 3 дюйма у висоту. І вони, як правило 19 дюймів в ширину, що означає все такого роду речі стандартизований. 

Так що, якщо ви подивитеся в center-- даних а не тільки на одному сервері, але давайте подивіться на Google, центрів обробки даних і подивитися, якщо ми побачити красиву картинку в Google Images. Це набагато краще, ніж ви освітлено як правило, знайти, і багато сексуальніше дивлячись, як результат. але це те, що виглядає як пара сто серверів все про те ж розмірі, насправді, в стійку після стійки після того, як стійки після стійки в центрі обробки даних. 

Щось на зразок this-- це цілком може бути компанії Google, так як я гуглі Google. Але це може бути представник в більш загальному плані центр обробки даних, в якому багато компанії, як правило, розташовані спільно. І суміщених в загальному випадку означає що ви йдете в такому місці, як Equinix або інших виробників, які мають великі склади, які мають багато енергії, багато охолодження, ми сподіваємося, багато безпеки, і окремі вольєри огороджувальних стійки сервери, і ви або орендувати стійки або ви приносите стійки в. 

А окремі компанії, стартапів особливо, матиме якийсь біометрії щоб потрапити в їх клітці, або клавіші, або ключ-карта. Ви відкриваєте двері. А всередині є тільки квадрат кадри слід що ви платите за, всередині які ви можете покласти все, що ви хочете. 

І ви, як правило, платять за владу. І ви платите за відбитками. А потім ви платите самостійно для серверів що ви чого в цей простір. А що ви тоді мати можливість зробити це платити комусь для підключення до Інтернет-послуг. Ви можете оплатити будь-яку кількість постачальників, кожен з яких як правило, потрапляють в цей центр обробки даних. 

Але реальний цікаве питання, що насправді йде в цих стійках? Вони можуть все дуже добре виглядати так, як ми тільки що бачили. Але вони виконують різні функції і, можливо, доведеться робити різні речі. І давайте насправді мотивувати це обговорення з питанням про те, які проблеми починає виникати, якщо ви успішні? 

Так що у вас є веб-сайт що ви побудували. А може бути, він продає віджети або щось в цьому роді. І ви робите дуже добре з продажами віджетів в Інтернеті. І ви починаєте відчувати деякі симптоми, ваш веб-сайт. Що може бути деякі з технічні симптоми що користувачі повідомляють, як бізнес росте і процвітає і ваш сайт вигоду від цього? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, точно. Таким чином, ви могли б мати уповільнення вашого веб-сайту. І чому це могло статися? Ну, якщо ми припустимо, для заради обговорення прямо зараз, що ви перебуваєте на одному з цих комерційних веб-хости що ми говорили про перед обідом, що ви платите кілька доларів в місяць, і ви вже заплатили для річної вартості вашого домену ім'я, що веб-хостингу, ймовірно, переоцінювати свої ресурси певною мірою. Так що ви можете мати ім'я користувача і пароль на своєму сервері. Але так може кілька інших, або кілька десятка інших, або, можливо, навіть кілька сотні інших, користувачів. 

І сайти живуть фізично на тому ж сервері. Чому це можливо? Ну в ці дні, сервери як це зазвичай є кілька жорстких дисків, може бути, цілих шість або більше жорстких дисків, кожен з яких може бути стільки, як 4 терабайт в ці дні. Таким чином, ви могли б мати 24 терабайт простору всього за один маленький сервер, як це. 

І навіть якщо ви вкрасти частину цього простору для резервування, для цілей резервного копіювання, це все ще досить багато місця. І, звичайно ж, типовий веб-сайт не потрібно багато місця. Просто реєстрації користувачів і зберігання журналів замовлень не брати все, що багато місця. Таким чином, ви можете розділити його досить трохи і дати кожному користувачеві тільки трохи шматочок цього. 

У той же час, комп'ютер як це в ці дні як правило, має кілька CPUs-- не тільки один, може бути, два, може бути чотири, може бути, 16, або навіть більше. І кожен з цих процесорів є те, що називається ядро, яке ніби як мозок всередині мозку. Так що насправді більшість всіх присутніх тут з сучасні ноутбуки, ймовірно, двоядерний або чотирьохядерним CPU-- і, ймовірно, тільки один процесор всередині ноутбука в ці дні. Але настільні комп'ютери і стійку комп'ютери, такі як це може мати чимало чим більше процесорів, і в свою чергу сердечників. 

І, чесно кажучи, навіть в наших комп'ютерах Mac і ПК сьогодні, ви насправді не потрібні двоядерний або чотириядерних ядра, щоб перевірити свою електронну пошту. Якщо є вузьке місце, коли мова йде про використання комп'ютера, Ти людина, ймовірно, найповільніша річ про цей комп'ютер. І ви не збираєтеся бути в змозі перевірте свою електронну пошту швидше, якщо ви мають в чотири рази більше процесорів або ядер. 

Але той же самий добрий істинного сервера. Один єдиний веб-сайт не може обов'язково потрібно більше, ніж один Процесор або одне ядро, один маленький мозок всередині робить все мислення і обробки. Так виробники аналогічно почав нарізати ці ресурси так що, можливо, ваш сайт отримує один ядро, ваш сайт отримує одне ядро, або, може бути, ми поділяємо одну таку серцевину. Ми також обмін дискового простору. І ми також обмін оперативної пам'яті, або пам'яті довільного доступу від раніше, з яких є також кінцеве кількість. 

І це ключ. Незалежно від того, наскільки дорого комп'ютер був, є ще кінцеве обсяг ресурсів в ньому. І тому все більше і більше вас спробуйте споживати ті ресурси, тим повільніше речі могли б стати. Але чому? Чому б речі уповільнити як симптом перевантаження сервера? Що відбувається? 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Так, точно. Я запропонував, що раніше Оперативна пам'ять є тип пам'яті. Це летюча, причому це де додатки і дані зберігаються, коли вони використовуються. І ось тому є лише кінцеве число речей, які ви можете зробити, мабуть, відразу ж. І це також швидше, який є хорошою річчю. Але це також дорожче, який є поганою річчю. І це також, отже, присутня в нижній кількостях, ніж на диску, жорсткий диск простір, яке, як правило, дешевше. 

Іншими словами, ви може мати 4 терабайт дискового простору на вашому комп'ютері. Але ви можете мати 4 гігабайти, або 64 гігабайти, по порядку величини, фактор 1000 менше, оперативної пам'яті в вашому комп'ютері. Отже, що ж комп'ютер робити? Ну, припустимо, що ви дійсно є 64 гігабайт оперативної пам'яті в сервері, як це, що буде досить поширеним явищем, якби не низька ці дні. Але припустимо, що у вас є так багато користувачі роблять так багато речей що ви начебто свого роду буде потрібно 65 гігабайт пам'яті обробляти всі, що одночасне використання? 

Ну, ви могли б просто сказати, На жаль, певна кількість користувачів просто не може отримати доступ до сайту. І це є міра в крайньому випадку, звичайно ж. Або, в якості операційної системи, як Windows, Mac або OS або Linux або Solaris або будь ряд інших операційних систем на цьому сервері, може просто вирішити, ви знаєте, що? У мене є тільки 64 гігабайт оперативної пам'яті. Я як би потрібно 65. Таким чином, ви знаєте, що? Я збираюся взяти 1 гігабайт варто даних в оперативній пам'яті який був найменш недавно зверталися і просто перемістити його на диск тимчасово, буквально скопіювати його з поста пам'ять з повільнішою пам'яттю так що я можу впоратися з цим, то 65-е необхідно гігабайтний для пам'яті, зробити деякі обчислення на ньому. Потім, коли я зробив це робити, Я буду просто рухатися, що на диск, перемістити цю іншу оперативну пам'ять я тимчасово покласти на диску назад в реальному обладнанні так що я частково багатозадачності. 

Так що я свого роду наведення тимчасово перебувають в цьому просторі повільніше, тому я створюю ілюзію обробки всіх. Але є уповільнення. Чому? Ну, всередині них важко диски в ці дні є що? Швидше за все, що робить жорсткий диск відрізняється від RAM як краще тепер ви знаєте? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Добре, правда. ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так дуже вірно. І це побічний ефект або функцію той факт, що пам'ять дійсно швидше. І тому ви хочете використовувати його для поточного використання. І диск повільніше. Але це постійне, або енергонезалежним. Таким чином, ви використовуєте його для тривалого зберігання. Але з точки зору реалізація, якщо я дивлюся вгору що називається модуль DIMM, дворядним пам'яті Модуль, це те, що частина оперативної пам'яті зазвичай може виглядати наступним чином. 

Так що всередині нашого Mac--, що це помилка. Усередині наших Маков і ПК, наші настільні комп'ютери матимуть палиці пам'яті, як ви могли б назвати їх, або модулі DIMM або SIMMs назад в той же день, пам'яті що виглядати наступним чином. Наші ноутбуки, ймовірно, є речі, які є третім розміром або половину розміру. Вони трохи менше, але той же самий маленький idea-- шматочки зеленого кремнію вафельні або пластику, має маленькі чорні фішки на них з великим проводів взаємного з'єднання все. Ви можете мати цілу купу вони всередині вашого комп'ютера. Але винос тут це повністю електронна. Там просто електрони протікає на цьому пристрої. На противагу цьому, якщо ми подивимося на всередині жорсткого диска і потягнути вгору картину тут, ви б замість того, щоб побачити щось на зразок цього, який робить електрику пройшовши через нього, в кінцевому рахунку. Але що ж вискакує у вас про цю річ? ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Так, є мабуть, рухомих частин. Це ніби як старого запису гравець або гравець фонограф. І це в значній мірі це. Це трохи вправнішим, ніж that-- в той час як фонограф використовуваного програвача канавками в запису, це насправді використовує крихітні магнітні частинки що ми не можемо бачити зовсім. Але якщо трохи магнітної частинки виглядає наступним чином, це вважається 1. І якщо це виглядає так, з півночі на південь, а не на південно-північ, це може бути 0. І ми побачимо завтра, як ми можемо побудувати від більш цікавих речей. 

Але все це повинен фізично перемістити , Безумовно, буде йти повільніше, ніж швидкість світла, яка в теорії є те, що електрон може протікати в, хоча реально не зовсім. Так що механічне devices-- набагато повільніше. Але вони дешевше. І ви можете пристосовувати так багато більше даних всередині них. Тому той факт, що існує в світі щось називається віртуальної пам'яті, при використанні жорсткого диска, як це як ніби це було RAM прозорим для користувача, просто шляхом переміщення даних з оперативної пам'яті на жорсткий диск, потім перемістити його назад, коли вам потрібно він знову створює уповільнення. Тому що ви в буквальному сенсі доведеться скопіювати його з одного місця в інше. І справа ви копіюєте його, а від фактично повільніше, ніж ОЗУ де ви хочете бути. 

Альтернативне рішення here-- якщо вам не подобається, що сповільнить, і ваша віртуальна пам'ять свого роду бути перевантажена, що інше рішення цієї проблеми? 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Ну, збільшення віртуальної пам'яті дозволить нам зробити це на ще більший масштаб. Ми могли б впоратися з 66 гігабайтами варто потреб в пам'яті, або 67 гігабайт. Але припустимо, що мені не подобається це уповільнення, насправді Я хочу, щоб відключити віртуальний пам'ять, якщо це взагалі можливо, що ще я міг кинути на цю проблему вирішити, де я хочу, щоб обробляти більшу кількість користувачів і більше вимоги до пам'яті ніж я фізично є на даний момент? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: На жаль, немає. Таким чином, процесор і ядра вони в це кінцевий ресурс. І немає ніякого аналогового в цьому контексті. Хороше запитання, хоча. Так просто бути ясно, теж, якщо всередині цього комп'ютера, скажімо, палиця пам'яті, яка виглядає як this-- і так ми будемо називати цю пам'ять. І тут це жорсткий диск. І я просто зробити це зображально як маленький коло. Є 0 і 1. В обох these-- дані, ми узагальнимо його як. 

І по суті справи, якщо користувач запуск програми, як, скажімо, веб-сайт, який вимагає це обсяг оперативної пам'яті для кожного користувача, що я пропоную, шляхом цієї речі називається віртуальної пам'яті, це просто тимчасово перемістити що тут, так що тепер я може перемістити пам'ять когось іншого Вимоги там. І тоді, коли це буде зроблено, Я можу скопіювати це назад на і це йде тут, тим самим переміщаючи що я хотів там де-небудь ще в цілому. 

Таким чином, є просто багато Switcheroo, є винесення тут. Так що, якщо вам не подобається це, і ви цього не зробите хочу поставити що-небудь на жорсткому диску, щось очевидне Рішення бізнес людини до проблеми, або інженера рішення, якщо на те пішло, теж? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, я маю на увазі в буквальному сенсі кидати гроші на цю проблему. І насправді, це ідеальний безпосередньо перейти до деяких з більш високого рівня обговорення хмарних обчислень. Тому що багато чого з цього мотивується фінансовими рішеннями, навіть не обов'язково технологічні. Якщо 64 гігабайтами оперативної пам'яті занадто мало, ну, чому б не отримати 128 гігабайт оперативної пам'яті? Чому б не отримати 256 гігабайт оперативної пам'яті? Ну, чому б і ні? 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Ну, варто більше грошей, звичайно. А якщо у вас вже є запасний простору на жорсткому диску, ефективно, або, що еквівалентно, простір на жорсткому диску так набагато дешевше, ви можете також використовувати його. Отже, ще раз, є такий компроміс, що ми побачили ще раніше цього ранку, де є насправді не обов'язково правильну відповідь, там просто краще або гірше відповідь засновані на тому, що ви насправді хвилює. 

Таким чином, є також технологічні реалії. Я не можу купити комп'ютер, Наскільки мені відомо, з трильйон гігабайт ОЗУ прямо зараз. Він просто фізично не існує. Так що є деяка верхня межа. Але якщо ви коли-небудь навіть робив покупки для споживачів Mac або PC, теж, як правило, є ця крива особливостей де може бути хорошим, краще, а кращий комп'ютер. 

І маргінальні повертається на ваш долар покупки кращий комп'ютер в порівнянні з тим краще комп'ютер не може бути настільки ж високим а витрачати трохи більше грошей і отримати кращий комп'ютер за хороший комп'ютер. Іншими словами, ви платите премії, щоб отримати верхній частині лінії. 

І те, що ми побачимо в обговорення хмарних обчислень це те, що дуже часто ці днів, а також те, що такі компанії, як Google рано популяризував, не звертала для і будівництво дійсно фантазії, дорого новоспеченим до комп'ютерів з багато і багато всього, а купувати або будувати досить скромні комп'ютери, але багато хто з них, і використовуючи те, що це в цілому називається горизонтальне масштабування замість вертикального масштабування. 

Таким чином, вертикальне масштабування означало б отримати більше RAM, більше дискового, найбільше, і як би інвестувати вертикально в вашому обладнанні так що ви просто отримання кращі з кращих з кращих, але ви платите за це. Горизонтальне масштабування вид отримати нижній ярус речі, хороша модель, або навіть гірше, модель, але отримати їх багато. Але як тільки ви отримаєте багато them--, наприклад, в даному випадку, веб-сервери, якщо цей сервер або один веб-хостингу є недостатнім, то просто інтуїтивно, то Вирішення цієї проблеми навантаження або перевантаження на серверах або отримати більший сервер або, що я пропоную тут замість того, щоб масштабування по вертикалі, так би мовити, буде, ви знаєте, що? Просто отримати другий один з них. Або, може бути, навіть отримати третій. Але тепер ми створили інженерна проблема за своєю природою цього бізнесу або фінансове рішення. Що інженерна проблема зараз? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, як ви підключаєте їх і-- шкода? 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: справа, тому що я до сих пір have-- якщо я знову ввести мене в цю картину, якщо це мій ноутбук десь в Інтернеті, який зараз знаходиться між я і компанія, ми говоримо про те, Тепер я повинен з'ясувати, до якого сервер я можу відправити цей учасників форуму? І якщо є інші користувачі, як це, і потім цей один тут, і, можливо, це користувач А, це є користувач В, це користувач С, і це сервер 1, 2, і в даний час 3-- інтуїтивний відповідь може бути тільки тут, ми будемо посилати користувачеві A 1 і В2 і С 3. І ми можемо обробляти 3 рази більше користувачів. 

Але це спрощенням. Як ви вирішуєте, кого послати де? Так давайте спробуємо міркувати через це. Так припустимо, що комп'ютери А, В, і С є клієнти, і сервери 1, 2 і 3 є горизонтально масштабується серверів. Так вони начебто ідентичні. Вони всі використовують те саме програмне забезпечення. І всі вони можуть зробити те ж саме. Але причина у нас є три з них так що ми можемо впоратися з трьома раз більше людей відразу. 

Отже, ми знаємо з нашого обговорення до обіду що є апаратна між ноутбуки і сервери. Але ми просто свого роду узагальнення що в даний час в Інтернеті або в хмарі. Але ми знаємо, що в моєму будинку, Тобто, ймовірно, домашній маршрутизатор. Поруч з серверами, там, напевно, маршрутизатор, DNS-сервер, DHCP. Там може бути що завгодно ми хочемо, щоб в цій історії. 

Так як же ми починаємо вирішувати, коли користувач А переходить в something.com, яке сервер для маршрутизації користувачеві? Як ми могли б почати розповідати цю історію? ГЛЯДАЧІ: балансування навантаження? DAVID Маланки: балансування навантаження. Що ти маєш на увазі? 

ГЛЯДАЧІ: Повернення де найбільш використання є і який з них має більшість наявних ресурсів. DAVID Маланки: Добре, так що дозвольте мені ввести новий тип апаратного забезпечення що ми ще не обговорювали, що це саме те, балансування навантаження. Це теж може бути просто сервером. Це може виглядати так само, як той, який ми бачили хвилину назад. Балансування навантаження насправді просто шматок програмного забезпечення що ви запускаєте на частини апаратних засобів. 

Або ж ви можете заплатити постачальнику, як Citrix або інші, Cisco або інші. Ви можете заплатити за їх власних апаратних засобах, який є компенсатором навантаження устаткування. Але це просто означає, що вони попередньо встановленої балансування навантаження програмне забезпечення на своїх апаратних і продав його до вас все разом. Так що ми просто зробити це як прямокутник для наших цілей. 

Як же тепер мені реалізувати балансування навантаження? Іншими словами, коли користувач А хоче відвідати мій сайт, їх запит якось або інший, ймовірно, шляхом тих, Маршрутизатор про які ми говорили раніше, збирається в кінці кінців досягне це компенсатор навантаження, який потім необхідно зробити маршрутизації типу рішення. Але це для маршрутизації роду більш високої мети в даний час. Це не тільки про отримання від точки А до точки B. Йдеться про рішення, яке Точка B є найкращим серед them-- 1, 2, або 3, в даному випадку. 

Так як же я вирішити, чи слід щоб перейти до 1, 2, 3? Що може цей чорний ящик, так кажуть, робити на внутрішній? Це також є ще одним прикладом у інформатика абстракції. Я буквально намалювали балансування навантаження як чорний ящик чорним чорнилом, всередині з яких деякі цікаві Логіка, або магія, навіть, з яких повинен прийти decision-- 1, 2, або 3. І вхід тільки А. 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Я шкодую? ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Добре, як ми могли б класифікувати види операцій тут? 

ГЛЯДАЧІ: Перегляд веб-сторінки в порівнянні з запитами до бази даних. DAVID Маланки: Добре, це добре. Так може бути, цей користувач А хоче переглядати веб-сторінки. А може бути, це навіть статичний контент, то, що змінюється рідко, якщо коли-небудь. І це здається досить проста операція. Так що, може бути, ми просто довільно, але розумно, скажімо, сервер 1, його мета в житті просто обслуговувати до статичного контенту, файли, які рідко, якщо коли-небудь, змінити. Може бути, це зображення на сторінці. Може бути, це текст на сторінці або іншого такого роду нецікавих речей, нічого не транзакционной, нічого динамічного. 

На відміну від цього, якщо користувач А перевіряє з його або її кошику, що потрібно база даних, десь зберігати і пам'ятайте, що угоди, а можливо, що запит повинні перейти до сервера 2. Так що це добре. Таким чином, ми можемо завантажити на основі балансу від типу запитів. Як ще ми могли б це зробити? що other-- 

ГЛЯДАЧІ: На основі сервера використання і потужності. DAVID Маланки: справа, ОК. Таким чином, ви згадали, що раніше, Kareem. Так що, якщо ми забезпечуємо деякий внесок на [нерозбірливо] серед серверів 1, 2, і 3 до цієї балансування навантаження таким чином, що вони просто постійно інформуючи вирівнювач навантаження який їхній статус? Як, агов, балансування навантаження, Я на 50% утилізації. Іншими словами, у мене є вдвічі менше, багато користувачів як я можу насправді обробляти прямо зараз. Гей, компенсатор навантаження, я при 100% утилізації. Гей, компенсатор навантаження, 0% використання. Балансування навантаження, якщо це сконструйовані таким чином, що може прийняти в цих коментарях в якості вхідних даних, він може вирішити, ох, номер 2 на 100%. Дозвольте мені надіслати не майбутні запити до нього крім користувачів вже підключені. Цей хлопець на 0%. Давайте пошлемо багато трафіку до нього. Цей хлопець сказав, що він на 50%. Давайте пошлемо деякий рух до нього. 

Таким чином, це було б одним з компонентів, який ми могли б взяти до уваги навантаження. І це буде змінюватися з плином часу. Таким чином, рішення будуть змінюватися. Так що це дійсно хороша техніка, той, який зазвичай використовується. Що ще ми можемо зробити? І давайте насправді просто підсумовувати тут. Таким чином, рішення тут може бути за типом трафіку, я буду називати його. Він може бути в залежності від навантаження. Давайте подивимося, якщо ми не можемо придумати кілька інших. 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Місцезнаходження. Так що це хороший. Так як місце расположенія-- ви могли б використовувати цю інформацію? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: О, це добре. І про те, скільки мілісекунд б вона зменшиться на на основі того, що ми побачили в цьому ранок б ви сказали? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Ну, на основі на слідових маршрутів ми бачили раніше, що це просто груба міра чогось, по крайней мере, скільки часу потрібно для даних, щоб отримати від А до Б відчуває, як що-небудь місцевим було, що, як 74 мілісекунд, давати або приймати? А потім що-небудь 100 плюс, 200 плюс був, ймовірно, за кордоном. І ось на основі цього поодинці, представляється розумним припустити, що для користувача в США щоб отримати доступ до Європейського сервера може зайняти два або три рази до тих пір, навіть в мілісекундах, ніж він міг би прийняти, якщо це Сервер були розташовані тут географічно, або навпаки. Тому, коли я запропонував раніше, що особливо Як тільки ви перетинаєте, що 200 мілісекунди Поріг, давати або приймати, люди дійсно починають помічати. І маршрут траси просто припускаючи, сирі, нецікаві дані. Якщо у вас є веб-сайт, ви повинні отримати користувач при завантаженні зображень або кіно файли, багато тексту, наступні запити. Ми бачили, коли ми відвідали, що було це, Facebook або Amazon раніше, є цілий багато речей який повинен бути завантажений. Так що збирається скласти. Так мульти-секунд може НЕ нерозумно. Так добре, географії є ​​одним з компонентів. Так що насправді таких компаній, як Akamai, якщо ви чули про них, або інші вже давно прийняті географія до уваги. І виходить, що за своєю природою IP-адреса, IP-адреса мого ноутбука, ви можете зробити висновок, з певною ймовірністю, де ви знаходитесь у світі. І справді є послуги третіх сторін, може оплатити які підтримують бази даних по IP-адрес і географічних регіонів що з високою впевненістю буде правда, коли його запитали, де в світі це IP-адреса? 

І так, що насправді інші компанії використовують це? Якщо у вас є Hulu або Netflix якщо Ви коли-небудь подорожував за кордоном, і ви намагаєтеся щось дивитися на Hulu, і ви не в США, ви можете побачити повідомлення кажучи, не в США. На жаль, ви не можете побачити це. 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: О, насправді? Але так, так що насправді це ідеальне додаток чогось дуже технічний актуальній проблемі. Якщо ви повинні були VPN від Європі чи Азії або де-небудь в світі до корпоративної Штаб-квартира в Нью-Йорку або там, де ви знаходитесь, ви збирається створити видимість на зовнішні веб-сайти, ви насправді в Нью-Йорку, навіть якщо ви фізично досить далеко. 

Тепер ви користувач збираєтеся знаю, що ви, очевидно, далеко. Але ви також будете почувати себе, тому що з цих додаткових мілісекунд. Це додаткове відстань і шифрування, що відбувається в VPN збирається уповільнити хід подій. Таким чином, він може або не може великий досвід. Але Hulu і Netflix збираються, щоб побачити Ви, як сидячи десь у Нью-Йорку, як ви чітко підбирала. Що ідеальне рішення для цього. 

Добре, так що географія одне рішення. Що ще ми могли б використовувати, щоб вирішити, як для маршрутизації трафіку з A, B, і C 1, 2 і 3, знову ж таки, поклавши інженерний капелюх на? Все це звучить дуже складно. Е-е, я навіть не знаю, де приступити до виконання тих. Дайте мені що-небудь простіше. Що це найпростіший спосіб щоб прийняти це рішення? 

ГЛЯДАЧІ: Чи є сервер доступний? 

DAVID Маланки: Чи є сервер доступний? Так що не погано. Добре. Це свого роду нюансування навантаження. Так що давайте тримати, що в категорії навантаження. Якщо ви доступні, я просто збирається відправити дані там. Але це може призвести до зворотних швидко. Тому що, якщо я використовую цю логіку, і якщо я завжди запитують 1, ким ви, ким ви, ким ви, якщо відповідь завжди так, Я збираюся відправити 100% трафіку до нього, 0% для всіх інших. І в якийсь момент, ми збираємося вдарити що уповільнення або сайт недоступний. Так що трохи краще, ніж що, але все ще досить просто і не майже настільки ж розумна, як приймати всі ці додаткові дані до уваги? 

ГЛЯДАЧІ: Вартість кожного сервера. DAVID Маланки: Вартість на сервері. ОК, так що дозвольте мені кинути, що в категорії навантаження теж. Тому що ви знайдете в компанія, too--, що якщо ви оновити сервери з плином часу або купити більше, Ви не могли б бути в змозі отримати точно однакові версії апаратного забезпечення. Тому що вона випадає з дати. Ви не можете купити його більше. Ціни змінюються. 

Таким чином, ви можете мати різнорідні сервери в кластері, так би мовити. Це абсолютно нормально. Але апаратне забезпечення в наступному році може бути в два рази швидше, в два рази здатні, як в цьому році. Таким чином, ми можемо кинути, що в категорію навантаження. Ця петля зворотного зв'язку між 1, 2 і 3 в балансування навантаження безумовно, може сказати йому, агов, я на 50% потужності. Але, до речі, я теж мають в два рази більше ядер. Використовуйте цю інформацію. Навіть simpler-- і це відбувається щоб бути темою в інформатиці. Якщо є сумніви, чи коли ви хочете простий рішення, яке в цілому працює добре протягом довгого часу, не вибирають той же сервер весь час, але виберіте-- 

ГЛЯДАЧІ: випадковий один? 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. Тепер для будь-якої бізнес-причини, Harvard вирішив, як і багато інших, багато інших веб-сайти, стандартизувати його веб-сайт по www.harvard.edu для технічних і маркетингових міркувань. Це просто вид в Моді мати WWW. 

Таким чином, сервер має в Гарварді щоб якось переспрямувати користувача, як я продовжую говорити, від один URL на інший. Як це працює? Що ж, дозвольте мені йти вперед і натисніть клавішу Enter. І зверніть увагу на URL дійсно швидко змінено на www.harvard.edu. Дозвольте мені прокрутити назад в цьому історія і натисніть на цю налагоджувати діагностична інформація, якщо ви будете. Дозвольте мені поглянути на моє прохання. 

Так ось запит, який я зробив. І зауважте, що це узгоджується з видом запиту я зробив Facebook раніше. Але зверніть увагу на реакцію. Що змінилося в відповідь на цей раз? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, так що це не 200 OK. Це не 404 Not Found. Це 301 Moved Постійно, який це свого роду кумедний спосіб сказати, Harvard підвищив і переїхав в іншому місці www.harvard.edu. 301 означає, що це редирект. І де якщо користувач мабуть, бути перенаправлені? Там в додатковий ласий шматочок інформація всередині цього конверта. І кожна з цих ліній тепер буде почати називати заголовок HTTP. Тема просто ключове значення pair-- щось щось двокрапка. Це частина інформації. Де слід новий Звідки, мабуть бути? Зверніть увагу на останній рядок серед всіх цих заголовків. 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, так що є Додаткова інформація. Перший рядок, що я виділив говорить 301 Moved постійно. Ну, де він переїхав? Останнє line-- і вони цього не роблять повинні бути в такому порядку. Це може бути випадковим. Розташування товстої кишки означає, агов браузер, перейдіть на цей URL замість. 

Так браузери розуміють HTTP перенаправляє. І це дуже, дуже поширений спосіб підстрибуючи користувач з одного місця в інше. Наприклад, якщо ви коли-небудь пробували відвідати веб-сайт, який ви не увійшов в, ви можете несподівано знайти себе на новому URL взагалі бути буде запропоновано увійти в систему. 

Як це працює? Сервер, ймовірно, відправляючи 301. Там також інші номери, як 302, дещо відрізняється за змістом, що відправити вас на інший URL. А потім сервер, як тільки ви увійшли в систему, відправить вас туди, де ви насправді призначені. 

Так що, то, погано сконструйовані сайти робити? Коли ви відвідуєте www.acme.com, і вони просто трапляється, назвали своїх серверів www1, www2, www3, і так далі, вони дуже simply-- яка є справедливою, але дуже свого роду foolishly-- перенаправляти вас насправді по-іншому з ім'ям сервера. І це працює прекрасно. Це приємно і легко. 

Ми бачили, як це було б зроблено під капотом в віртуальному конверті. Але чому це можливо, є погане інженерне рішення? І чому я на кшталт поблажливого до цієї конкретної техніки підходить? Стверджують, чому це погано. Бен? ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Кожен сервер повинен буде є дублікат сайту. Я в порядку з цим. І справді, це те, що я припустимо, для всієї цієї історії, так як якщо ми wanted-- добре насправді, для Дана раніше, за винятком Пропозиція, де якщо у вас є різні сервери робити різні речі, то може бути, вони могли б бути насправді функціонально робити різні речі. 

Але навіть тоді, в якийсь момент, ваш бази даних збирається отримати перевантажені. Сервер статичні активи збирається отримати перевантажені. Так що в якийсь момент, ми назад в цій історії, де ми необхідно мати кілька копій одного і того ж. Так що зі мною все гаразд з цим. ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: ОК, так що деякі сторінки може бути непропорційно популярним. І так що закріплює на одну адресу не обов'язково найкраще. [Нерозбірливо]? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Що ви маєте на увазі під цим? ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, точно. Таким чином, ви не хочете обов'язково have-- вас, звичайно, не хочете, щоб ваші користувачі вручну вводити в www1 або www2. З точки зору брендінгу, його просто виглядає трохи смішно. Якщо ви просто хочете свого роду чистий, елегантний досвід, маючи ці роду випадковим чином пронумеровані URL-адреси насправді не дуже добре. Тому що тоді користувачі, безумовно, збирається копіювати і вставляти їх в повідомлення електронної пошти або миттєві повідомлення. 

Тепер вони розповсюджується. Тепер ви свого роду заплутаним СВІЙ Проте технічно аудиторії, хто думає Ваш веб-адреса www2.something.com. Там немає переконливих семантики цього. Це як раз трапляється бути основною технічна деталь, що ви маєте пронумеровані сервери таким чином. 

І ще гірше, що, якщо, наприклад, може бути, під час різдвяних свят коли це бізнес дійсно процвітає, ви отримали www1 через www99, але в січні і лютому і вперед, ви виключаєте половину тих, тому у вас є тільки www1 через www50? Що мається на увазі тепер, що дуже розумне рішення бізнес? ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Вам потрібно управляти всіма тими, до сих пір. ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Абсолютно вірно. Це свого роду улову там. Якщо ваші клієнти знаходяться в звичку закладок речі, відправки по електронній пошті їх, просто збереження URL де-небудь, або якщо це тільки в їх авто завершити в свій браузер таким чином, вони насправді не навмисно вводити його, це просто відбувається, вони могли б, за 11 місяців в році ефективно, досягають в глухий кут. І тільки найбільш проникливі з користувачі збирається реалізувати, Можливо, я повинен вручну видалити цей номер. Я маю на увазі, це просто не відбудеться з великою кількістю користувачів, так що погано для бізнесу, погана інженерна реалізація мудрим. 

Так, на щастя, це не потрібно. Виявляється, що балансири навантаження може зробити це замість того, щоб говорити, коли А робить request-- агов, перейти до 1. Іншими словами, замість того, щоб відправки які перенаправляють таким чином, що перший крок в цьому Процес є йди сюди, він тоді сказав, щоб піти в іншому місці. І так крок три це, він йде в іншому місці. 

Замість цього ви можете продовжувати маршрут, щоб продовжувати використовувати цей термін, всі дані А в через балансування навантаження таким чином, щоб він ніколи не контакти 1, 2, або 3 безпосередньо. Весь трафік дійсно отримує "розгромили" балансування навантаження на себе. І ось тепер ми начебто навмисно розмиває лінії серед цих різних пристроїв. Балансувальник навантаження може даних маршруту. Це просто функція, яку вона має. 

Таким чином, балансування навантаження, також, це частина програмного забезпечення, насправді. І маршрутизатор є частиною програмного забезпечення. І ви можете абсолютно мати дві частини програмного забезпечення всередині одного фізичного комп'ютера тому навантаження балансир може зробити ці кілька речей. 

Таким чином, є ще один спосіб щоб зробити це, який насправді сходить до свого роду перше принципів в DNS, про який ми говорили до розриву. DNS була система доменних імен. Пам'ятайте, що ви можете запитує сервер DNS, що IP-адреса google.com, facebook.com? 

І ми дійсно можемо зробити це. Інструмент ми не використовували раніше, той, який так само, як доступний, називається Nslookup, для сервера імен пошуку. І я просто хочу, щоб ввести facebook.com. І я бачу, що IP Facebook, адреса, мабуть це. Дозвольте мені йти вперед і скопіювати що, перейти в браузер, і перейти до HTTP: // і що IP-адресу та натисніть клавішу Enter. І дійсно, це, здається, працює. 

Зараз працює в зворотному напрямку, що було всередині віртуального конверта що Facebook відповів, коли Я відвідав, що IP-адреса безпосередньо? Тому що повідомлення, де я зараз? Де я зараз, адреса? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: В безпечної версії, і на www.facebook.com. Так що це навіть не просто захищений IP-адреса. Facebook прийняла на себе сказати, що це смішно. Ми не будемо тримати вас в цьому некрасиво дивлячись URL це числовий. Ми збираємося відправити вам HTTP перенаправлення за допомогою того ж заголовка що ми побачили before-- Звідкись товстого кишечника. 

А так це просто означає, що під капот і раніше цей IP-адреса. Кожен комп'ютер в мережі Інтернет має IP-адресу, він, здавалося б. Але ви не обов'язково повинні виставити що користувачеві. І так само, як ще в той день, там був 1-800-Collect, 1-800-С-О-Л-Л-Е-З-Т, в США, був спосіб зробити Collect дзвінки через дуже легко запам'ятовується телефон номер, або 1-800-MATTRESS купити ліжко, і подібні Мнемоніки, що ви навіть бачите по телефону вид роду до сих пір, що листи карта з номерами. 

Тепер, чому це? Ну, це набагато легше запам'ятати 1-800-MATTRESS або 1-800-Collect замість 1-800-то что-то что-то що-то что-то что-то щось, де кожен з них є цифрою. Точно так же, як світ дізнався швидко, що ми не повинні є люди, запам'ятовувати IP-адреси. Це було б нерозумно. Ми будемо використовувати імена замість. І саме тому DNS був народжений. 

Добре, так і з тим, що, з точки зору балансування навантаження, давайте спробуємо yahoo.com. Ну, це цікаво. Yahoo, схоже, повертаються три IP-адреси. Так що з цього висновок, якщо ви могли б, що таке ще один спосіб, який ми могли б реалізувати це поняття балансування навантаження може бути, навіть не використовуючи фізичний пристрій, це нове фізичне пристрій? 

Іншими словами, я можу забрати фінансування у вас є для балансування навантаження і сказати вам, щоб використовувати деякі існуючі частина апаратних засобів для реалізації це поняття балансування навантаження? А спойлер, да, але що, чи як? Що таке Yahoo, можливо, тут робить? Kareem? Добре, Кріс? ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Так, все Три з цих робіт. Так що випадковістю, Кругова система, місце расположенія-- ви можете просто використовувати існуючий шматок головоломки що ми говорили раніше про DNS системи і просто сказати, коли перший Користувач дня просить yahoo.com, дати їм перший IP-адреса, як один, який закінчується в 45 там. І наступного разу, коли користувач запитує IP-адреса yahoo.com звідкись в світі, дати їм другий IP, потім третій IP, то перший IP, потім другий. Або бути розумним про це і зробити це графічно. Або це випадково і не просто робити це коловою системою в цій моді. 

І в цьому випадку, то ми навіть не потрібно щоб ввести цей чорний коробка в нашу картину. Нам не потрібно новий пристрій. Ми просто кажучи комп'ютери щоб перейти до серверів безпосередньо, ефективно, але не шляхом їх імені. Вони ніколи не повинні знати ім'я. Вони просто кажуть, що yahoo.com карти до будь-якого з цих IP-адрес. 

Таким чином, він посилає точно такий же запит. Але на зовнішній стороні конверт, він просто поміщає IP, що він був проінформований про. І таким чином, теж могли б ми балансувати навантаження запити просто посилати конверт до відрізняється одним з власних серверів Yahoo ,? 

І якщо ми будемо рити, ми побачимо, можливо, інші компанії з більш. CNN має два публічно піддаються. Хоча насправді, якщо ми робимо це знову і again-- cnn.com-- ви можете побачити вони змінюють порядок, насправді. Так що механізм CNN, використовуючи, мабуть? 

ГЛЯДАЧІ: Random. DAVID Маланки: Ну, може бути випадковим, хоча здається, їзда на велосипеді назад і вперед. Так що це, ймовірно, де Кругова система вони просто перемикаючи замовлення так, що я, ймовірно, займе перше. Мій комп'ютер буде приймати перший кожен раз. Так що це балансування навантаження. І це дозволяє нам, в кінцевому рахунку, для відображення даних, або запити до карти, на декількох серверах. Так що ж види проблеми в даний час все ще існують? Таке відчуття, що ми насправді просто вирішити хорошу проблему. Ми отримали користувачів на різних серверах. Но-- ой, і Кріс, зробив у вас є питання, перш ніж? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Повністю залежить від багатьох чинників. Так що ж тут відбувається? І ми дійсно можемо побачити це. Так давайте спробуємо Yahoo. Насправді, давайте перейдемо до Facebook. Тому що ми знаємо, що один працює. Так що я збираюся скопіювати що IP-адреса знову. Я збираюся закрити всі ці вкладки. Я збираюся піти відкритим, що спеціальна вкладка мережу тут. І я збираюся відвідати тільки HTTP: //. А тепер я вдарю Enter. І давайте подивимося, що сталося. 

Якщо я дивлюся на це прохання, повідомлення що my-- Facebook є поганим прикладом. Тому що у них є супер фантазії техніка яка приховує цю деталь від нас. Дозвольте мені використовувати Yahoo instead-- HTTP: // цей IP. Давайте відкриємо нашу мережу Вкладка, зберегти журнал. І тут ми йдемо, Enter. Забавно. Добре, так ось прославлений 404 повідомлення. Що смішного в тому, що вони ймовірно, ніколи не повернеться. Тому що там, напевно, не те, що само по собі неправильно. Вони просто навмисно вирішили не підтримувати числовій формі їх адреси. 

Так що ми насправді бачимо в Вкладка Мережа, якщо я тягну це тут, це, як я кажу, прославлений 404, де якщо я дивлюся на заголовки відповіді, це те, що я отримав here-- 404 Not Found. Так давайте спробуємо один одного. Давайте подивимося, якщо CNN співпрацює з нами. Я захопити один з IP-адрес на CNN, очистити це, HTTP, ля-ля-ля-ля. Таким чином, у відповідь на Кріса питання, що один працював. 

І давайте перейдемо до заголовків відповіді. Взагалі-то немає, все в порядку, я щосили, щоб знайти робочий приклад. Так CNN вирішив, що ми просто залишити вас на будь-яку адресу, ви насправді відвідати, питання брендингу в сторону. Але те, що не відбувалося б, якщо ми могли бачити його в разі Facebook, це ми отримали б 301 Moved Постійно, швидше за все, всередині якого знаходиться Місцезнаходження: 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. І я збираюся сказати, це номер чотири. І я скажу БД для бази даних. Добре, мені це подобається. Яку лінію я повинен імовірно малюнок тут? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, так що код, як ми обговоримо завтра, імовірно такий же, на всіх трьох серверах. Але тепер необхідно підключити не до бази даних на локальному комп'ютері, але в іншому місці. І це прекрасно. Ми можемо просто дати до бази даних, ім'я, як у нас, або номер. І це все працює відмінно. Але що ж ми зробили? Ми горизонтально масштабується при наявності три сервера замість одного, який це добре. Тому що тепер ми можемо обробляти в три рази більше навантаження. 

А ще краще, якщо один або два з цих серверів виходить з ладу, мій бізнес може продовжувати працювати. Тому що я до сих пір один, навіть якщо я вид накульгуючи з точки зору продуктивності. Але те, що нова проблема є я введені шляхом переміщення бази даних для цього окремий сервер а не на 1, 2 і 3? 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Так, так що тепер у мене є інша єдина точка відмови. Якщо моя база даних вмирає, або потрібно бути підвищений, або незалежно від того, тепер впевнений, мій веб-сайт в Інтернеті. І я можу служити статичним, незмінне зміст. Але я не можу дозволити користувачам увійти в систему або змінити нічого або замовити що-небудь, що ще гірше. Тому що якщо 4 відсутня, потім 1, 2, і 3 насправді не може говорити з нею по визначенню. 

ОК, так що так, і ось чому Я не наважуючись зробити це. Так що давайте повернемося до цього. Я не маю на увазі, щоб штовхати вас. Але картина дуже швидко збирається отримати стрес. Тому що вам потрібно, щоб почати маючи два всього. Насправді, якщо ви коли-небудь бачив кіно Зв'язок кілька років тому з Джоді Foster-- немає? 

ОК, так що для двох нас, хто бачив контакт, є відносини там, де вони по суті, купив два чогось а не один, хоча і в два рази дорожче. Так що це був свого роду грайлива коментарі у фільмі. Це свого роду пов'язані з цим. Ми могли б зробити це абсолютно. І ви тільки вартість нас в два рази більше грошей. Але ми повернемося до цього. 

Отже, ми вирішили цю проблему. Таким чином, ви знаєте, що? Це схоже на слизькому схилі. Я не хочу мати справу з наявністю мати дублікат бази даних. Це занадто багато грошей. Знаєш, що? Я хочу мати свою базу даних так само, як в першій версії де кожен сервер має свою власну локальну базу даних. Так що я просто збираюся малювати дБ на кожному з них. 

Так що тепер кожен веб-сервер ідентичний в тій мірі, так як вона має один і той же код, те ж саме статичні активи, ті ж малюнки і текст і так далі. І кожен з них має свою власну базу даних. Я встановив одну точку проблеми відмови. Тепер у мене є база даних. Незалежно від того, який два або один з них речі, вмирають, завжди є один зліва. Але те, що нова проблема є я створив що рішення Дана уникнути? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, я повинні синхронізувати їх, чи не так? Так як мені потрібно синхронізувати хто збирається where-- іншими словами, якщо Аліса відвідують мій сайт, і вона випадково щоб отримати випадковим чином або круглий robined або незалежно від того, на сервер номер один, Після цього я повинен завжди відправити її на сервер 1. Чому? Тому що, якщо я посилаю її на сервер 2, це буде щоб подивитися, як вона там не існує. 

Я не буду мати її історію замовлень. Я не буду мати її профіль там. І це просто відчуває, як він запрошує проблеми. І коли Боб відвідує, я повинні послати його завжди до того ж сервера, 2, або в залежності від того один, і Чарлі до третього, і послідовно. Це не позбавлене сенсу, хоча. це називається секціонування бази даних. І насправді це було те, що Facebook зробив на ранніх стадіях. 

Якщо ви слідували історію Facebook, це почалося тут в кампусі як www.thefacebook.com. Потім вона перетворилася одного разу Марк почав поширення в інші кампуси щоб бути harvard.thefacebook.com і mit.thefacebook.com, і, ймовірно, bu.thefacebook.com, тощо. І це тому, що на ранній стадії, я не думаю, ви могли б мати друзів по кампусів. Але це нормально. Тому що будь-який з Гарварда був відправлений на цей сервер. Будь-який з БО отримав надсилатися на цю сервер. Будь-який з MIT отримав відправлено до цього server-- в теорії. Я не зовсім знаю, все лежать в основі деталей реалізації. Але він, ймовірно, розподіляли людей, їх університетського містечка, де їх мережа була. 

Так що це добре до точки де вам потрібно два сервера для Гарварду, або три сервера для Гарварду. А потім, що простота вид ламається. Але це розумний підхід. Давайте завжди посилає Алісі до того ж місця, завжди посилають Боба на те саме місце. Але що станеться, якщо Еліс сервер переходить в автономний режим? Боб і Чарлі все ще можна купити речі і увійти на сайт. Але Аліса не може. Таким чином, ви втратили третину вашої користувальницької бази. Може бути, це краще, ніж на 100%? Але, можливо, було б добре, якби ми могли до сих пір підтримують 100% наших користувачів навіть якщо третина наших серверів переходить в автономний режим. 

Таким чином, ми могли б синхронізувати що? Чи не користувачі, самі по собі, але бази даних у всіх цих серверах. Так що тепер ми начебто потрібні деякі вид з'єднання ось так, що самі сервери може sync-- не є необгрунтованим. І справді, ця технологія існує. У світі баз даних, є поняття провідний-ведений баз даних, або первинного і вторинного, де серед особливостей не тільки для зберігання даних і реагувати з даними, але і просто постійно синхронізуються один з одним. Так що в будь-який час ви пишете або зберегти щось в цю базу даних, він одразу ж отримує "реплицировать" для інших баз даних, а також. 

І в будь-який час читати з нього, це не має значення, де ви знаходитесь. Тому що якщо в теорії вони все синхронізуються, ви збирається отримати той же вид даних. Так що це звучить ідеально. Там повинен бути підступ. Що може бути підступ? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, так що в три рази так багато речей може піти не так. Це реальність. Все це могло б бути таким же духом. Але хтось повинен налаштувати їх. Там дуже висока ймовірність того, що щось піде не так. Просто комбинаторно у вас є більше матеріалу схильні до помилок. Що ще погано потенційно? ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, так Синхронізація може бути поганим. Навіть, як ви могли б знати з резервних копій і такі, якщо ви просто сліпо робити резервне копіювання, то, що якщо щось піти не так, на одній базі даних? Ви видаліть щось ви не повинні. Ви негайно дублювалися ця проблема всюди. Так що Вікторія була talking-- резервне копіювання було б добре тут. І тому ми повернемося до цього. І було ясно, що ми говоримо нема про резервних копій тут самі по собі. Ми говоримо про справжню реплікації або синхронізації між серверами. Вони всі живуть. Вони не призначені для використовуватися для резервного копіювання. 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Що це? ГЛЯДАЧІ: Higher-- DAVID Маланки: Більш висока вартість. Ми потроїли витрати на Звичайно, хоча принаймні, з точки зору апаратних засобів. Оскільки база даних є просто шматок програмного забезпечення. І веб-сервер є частиною програмного забезпечення. Це, ймовірно, безкоштовно, якщо ми використовуємо будь-яку кількість речей з відкритим вихідним кодом. Але якщо ми використовуємо щось на кшталт Oracle, ми платимо Oracle більше грошей в ліцензії або Microsoft для доступу. Там повинен бути якийсь інший улов тут. Це не може бути це просто. 

Так що до точки, я думаю, що це було Каріма, для географії earlier-- чи ні, Роман, це був, для geography-- припустимо що ми бути розумним про це, і ми поміщаємо один з наших серверів, і в свою чергу, наші бази даних, в США, а інший в Європі, інший в Південній Америці, інший в Африці, інший в Азії, в будь-якому місці ми могли б хотіти в усьому світі. Ми вже знаємо з нашого сліду маршрути, що точка А і точка B, якщо вони далі один від одного, збираються зайняти більше часу. 

І якщо деякі з вас використовували інструменти, такі як Facebook або Twitter або будь-які з цих сайтів, що в ці дні постійно змінюються через користувача створені дані, іноді, якщо ви вдарив перезавантажити або відкрити ту ж сторінку в іншому браузері, ви бачите різні версії, майже. Ви можете побачити чийсь статус оновити тут, але не тут, а потім перезавантажити, а потім його Виявляється, і ви знову перезавантажити, і вона зникає. Іншими словами, тримати очей за це, принаймні, якщо ви використовуєте соціальні мереж зокрема. 

Знову ж таки, тільки тому, що даних змінюється так швидко, іноді сервери рассінхронізіроваться. А може бути, це супер маленьке вікно. Але 200 мілісекунд, може бути, навіть більше, ніж це that-- збирається зайняти деякий нульове кількість часу для цих баз даних для синхронізації. І ми не тільки говорити про одне запиті. Якщо у компанії є тисячі користувачі використовувати його одночасно, вони можуть буфер. Іншими словами, може бути черги або очікування лінії перш, ніж всі ті бази даних запити можуть синхронізуватися. Так що, може бути, насправді це кілька секунд. 

І справді, це правда, я думаю, що навіть донині з Facebook, в результаті чого при синхронізації з Східне узбережжя на Західне узбережжя, вона має нетривіальне затримка поширення, так би мовити, що ви тільки частково повинні терпіти. І тому це не так багато помилка, як це реальність які не могли б бачити користувачі правильні дані, по крайней мере, кілька секунд. 

Я бачу це на Twitter багато насправді, де я іноді буду чірікать в одному вікні, відкрийте інше потім побачити його, щоб підтвердити, що це дійсно пішли вгору, і це ще не там. І я повинен начебто перезавантаження, перезавантажити, reload-- ой, там. І це не тому, що він не був врятований. Він просто не поширюється на інші сервери. 

Так що це компроміс, too-- ви насправді хочуть наражатися на ризик що якщо користувач переходить до їх порядку історія, це не насправді там ще? Я бачу це на деяких банках. Це завжди дратує мене, коли, ну, наприклад, ви можете йти тільки як шість місяців тому в виписках в деяких банках, навіть якщо в теорії вони повинні бути в змозі мати все в Інтернеті. Вони просто взяти речі в автономному режимі іноді. Іноді too-- який веб-сайт це? Там в одно-- про, це GoDaddy, я думаю. GoDaddy, коли ви закінчували купити доменне ім'я або щось, вони часто дають вам посилання на квитанції. А якщо натиснути на це посилання право геть, це часто не працює. Він просто говорить, тупик, нічого тут. 

І це теж через ці затримки поширення. Тому що з якої-небудь причини, вони займають небагато часу насправді генерувати це. Так що це ніби як ви хочете витягнути своє волосся в якийсь момент. Тому що все, що ви намагаєтеся зробити, це вирішити просту проблему. І ми продовжуємо створення нових проблеми для себе. Отже, давайте подивимося, якщо ми може частково скасувати. 

Виявляється, що об'єднання бази даних на всіх ваших веб-серверів це насправді не найкраща практика. Взагалі, те, що інженер робитиме, або системний архітектор, матиме різні яруси серверів. І тільки заради простору, я буду черпають базу даних тут. 

Ми могли б мати базу даних і Сервер номер чотири тут що має підключення до кожен з цих машин тут. Так що це може бути наш фронт кінець ярус, так як люди сказали б. І це буде наш задній кінець рівня. І це просто означає, що вони стикаються з користувачем. А бази даних не звернена до користувача. Ні користувач може безпосередньо доступ до бази даних. 

Так давайте тепер, може бути йти вниз Пропонований маршрут Вікторія. Це єдина точка відмови. Це робить мене незручним. Так що, можливо, Найбільш очевидне рішення? ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: На жаль, сказати, що знову. ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: невиробнича сервер. Що ви маєте на увазі? 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: О, добре, так що резервне копіювання. ОК, так що ми могли б зробити це, звичайно ж. І насправді це дуже часто робиться. Це може бути база даних номер п'ять. Але це тільки з'єднаний з номером чотири. І ви могли б назвати його гарячим резервом. Ці дві бази даних може бути налаштований просто постійно синхронізувати один одного. І тому, якщо ця машина вмирає, для все, що нерозумно reason-- жорсткий диск вмирає, хтось поїздок по шнур, деяке програмне забезпечення є некоректною і машина зависає або crashes-- ви могли б мати людину в буквальному сенсі вимкніть цей від стіни і замість того, щоб підключити цей ст. А потім всередині, давайте скажемо, кілька хвилин, може бути, через півгодини, ви повернулися в Інтернеті. 

Це не здорово, але це також не потрапило. І вам не доведеться турбуватися про будь-які проблеми синхронізації. Тому що все вже є. Тому що у вас було ідеальним резервного копіювання готовий до роботи. 

Ви могли б бути трохи вправнішим про це, так як деякі люди часто роблять, де ви можуть мати бази даних номер чотири тут, база даних номер п'ять тут, які розмовляють один з одним. Але у вас також є це вид arrangement-- і свідомо виглядає брудним, тому що він is--, де все передні сервери можуть говорити з усіма серверними серверів. І тому, якщо ця база даних не реагувати, ці передні кінцеві сервери щоб мати програмування код в них, що говорить, якщо ви не отримаєте підключення до цієї бази даних, первинний негайно починає говорити з вторинним. 

Але це зараз штовхає складність в коді. А тепер ваші розробники, ваше програмне забезпечення розробники, повинні знати про це. І ви начебто зав'язування код, ви пишете до вашої фактичної задньої частини деталі реалізації, що робить його більш важким, особливо в більшому компанія або більше веб-сайт, де ви не обов'язково хочуть програмісти мати щоб знати, як база даних інженери виконують свою роботу. Ви можете зберегти ці ролі свого роду функціонально відрізняються так що є цей шар абстракція між ними. 

Отже, як ми могли б це виправити? Ну, ми якось вирішена ця проблема колись раніше. Чому б нам не поставити один з ці речі тут, де він говорить, в свою чергу номер чотири і п'ять, все веб-серверів зовнішнього інтерфейсу поговорити з цим посередником, а Посередник в свою чергу, маршрутах їх даних? Насправді, що може бути гарна назва для цієї речі? 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: OK, менеджер баз даних. Але що може бути термін, який ми могли б повторно використовувати для цього пристрою? Ми балансування. Так, так що насправді, я же не бути справедливим тут. Таким чином, балансування навантаження буде означати, що ми перемикаючи назад і вперед тут, які потребують насправді не так. Таким чином, є кілька способів, якими ми могли б зробити це. 

Якщо це насправді балансування навантаження, то історія точно така ж, як і раніше. Деякі із запитів йдуть 4. Деякі з них йдуть на 5. І це добре. Тому що тепер ми можемо обробляти в два рази більше пропускної здатності. Але цей зв'язок тут супер важливо. Вони повинні залишатися постійно синхронізованих і ми сподіваємося, географічно не дуже далеко один від одного, так що синхронізація по суті миттєво. В іншому випадку ми могли б мати проблеми. 

Так що це не погано. Але знову-таки, ми представила нову проблему. Яку проблему я просто відтворені? Вони не були одностайними відмови. Так що рішення з цього приводу? Так що, як Вікторії люблять витрачати гроші, ми можемо взяти цього хлопця і зробити це. І я тільки збираюся рухатися тут достатньо місця. І це збирається бути трохи неакуратно. Я буду тримати малювання ліній. Припустимо, що всі ці лінії йдуть в обох? 

Дуже поширений метод тут буде використовувати техніку, звану серцебиття причому кожне з цих пристроїв, лівий і правий балансування навантаження, або те, що ми хочемо, щоб називати їх, постійно говорять, що я живий, Я живий, я живий, я живий. Один з них за замовчуванням виступає в якості основного. Таким чином, весь трафік перенаправляється через один на лівій стороні, наприклад, за замовчуванням, довільно. 

Але як тільки хлопець на правому не чує від лівого хлопця більше, один на правому запрограмований автоматично, наприклад, взяти на себе IP-адреса з однієї зліва, і, отже, стати основним, і може бути, відправити електронною поштою або текстове повідомлення до людей, щоб сказати, агов, лівий первинний відсутня. Я став основним на даний момент. Так, віце-президент стає президент, так би мовити. І хтось повинен піти врятувати президент, якщо ви хочете. Тому що тепер у нас є тимчасовий єдина точка відмови. 

Так само складно або стрес, як це може здатися почати бути, це те, як вам вирішити ці проблеми. Ви робите кидати гроші на нього. Ви кидаєте апаратне забезпечення на нього. Але на жаль, ви додати складність для нього. Але результат, в кінцевому рахунку, є те, що у вас є набагато більше, в теорії, надійна архітектура. Це все ще не досконалі. Тому що навіть коли ми have-- ми могли б немає єдиної точки відмови. Тепер у нас є подвійні точки відмови. Але якщо дві речі йдуть не так, який абсолютно міг, ми як і раніше буде перебувати в автономному режимі. 

А так дуже поширені в промисловість, щоб описати Ваше Час з точки зору дев'яток. І начебто цілі прагнути до 99,999% часу ваш сайт в Інтернеті. Або ще краще, додати кілька дев'яток до цього. На жаль, ці дев'ятки стоять дуже дорого. І давайте насправді робити це. Так що, якщо я відкриваю мій великий калькулятор знову, 365 днів в році, 24 години на добу, 60 хвилин на годину, і 60 секунд в хвилину, ось скільки секунд є в рік, якщо я зробив це правильно. Так що якщо ми раз це, .99999, це скільки часу ми хочемо прагнути. Таким чином, це означає, що ми повинні бути вгору це багато секунд протягом року. Так що, якщо я тепер відняти початкове значення, або, вірніше, це нове значення з first-- 316 секунд, який, звичайно, через п'ять хвилин. 

Так що якщо ваш сайт або ваша компанія стверджуючи, що "п'ять дев'яток", в якому ви перебуваєте до 99,99% часу, це означає, що вам краще був досить розумний і швидко досить і досить врівень з ресурсами що ваші сервери тільки в автономному режимі п'ять хвилин з року. Це дорога і тверда річ, щоб прагнути. 

Так що це компроміс, теж. 99,999% часу досить штопати важко і дорого. П'ять minutes-- ви можете тільки отримати на сервер фізично замінити то, що пішло не так. І саме тому ми починаємо проводку всі разом складніші апріорно так, що комп'ютери може на кшталт виправити себе. Так. 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Проблема може бути в будь-якій кількості місць. І в fact-- 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Абсолютно, абсолютно. І, як картина стає все більш складним, це може бути веб-сервери. Це може бути сила до будівлі. Це може бути щось фізичне, як кабелі отримали поношений або виженуть. Це може бути база даних не відповідає. Це може бути, вони оновили свої операційні система і щось висить. Так що є так багато інших рухомих частин. І так багато інженерних що повинен йти за цим насправді просто компроміси, наприклад, як багато часу, скільки грошей він насправді варто, і які загрози ви дійсно стурбовані? Наприклад, в курси я вчу в Гарварді, ми використовуємо багато хмарних обчислень, яка ми почнемо поглянути на зараз, Справді, де ми використовуємо Amazon Web Services. Просто тому, що це яку ми почали. Але є ще більш в ці дні від Google і Microsoft та інші. І ми свідомо вирішили поставити все віртуальних машин наших курсів », як вони називають, в я думаю, це Західна Вірджинія центру обробки даних. Більшість наших студентів трапляється, з США, хоча є, звичайно, деякі на міжнародному рівні. 

Але реальність така, що це просто простіше і це дешевше для нас покласти всі яйця в кошику Вірджинії, хоча я знаю, якщо щось піде не так в Вірджинії, так само як і час від часу, як happened-- якщо є ураган або деякі погоди подія, як, що, якщо є якась випуск енергосистема або like-- все з даних наших курсів "може піти на форумі протягом певної кількості хвилин або годин або навіть довше. 

Але кількість складності які будуть потрібні, і кількість грошей, які б потрібно, щоб працювати все паралельно в Європі або в Каліфорнії просто не має так багато сенсу. Так що раціональне торгівля геть, але болючим коли ви насправді маючи, що час простою. 

Що ж, давайте перехід прямо зараз деякі з хмарних рішень в деяких з цих проблем. Все, що ми були обговорення досі це свого роду проблем, які мають був з нами протягом деякого часу, чи є у вас свій власний серверів у вашій компанії, Чи ви піти на спільне розміщення місце як центр обробки даних і частка простір з кимось ще, або в даний час в хмарі. 

І що приємно про хмара, що все з цих речей, які я малюнок як фізичні об'єкти Тепер можна розглядати як свого роду віртуальних об'єктів в хмарі, які змодельовані за допомогою програмного забезпечення. Іншими словами, комп'ютери сьогодні, сервери сьогодні, як на картинці Dell Я показав раніше, настільки швидко, є так багато оперативної пам'яті, стільки процесор, стільки диск простір, що люди писали Програмне забезпечення практично розділу один сервер вгору в ілюзію його бути два сервера, або 200 серверів, так що кожен з нас клієнти має ілюзію наявності не тільки рахунок на деяких веб господар, але нашу власну машину, ми здача в оренду від кого-то другого. 

Але це віртуальна машина до сих пір, як на одному сервері Dell, він знову може бути розділена вгору в два або 200 або більше віртуальних машин, всі з яких дають комусь адміністративний доступ, але в шляху, де ніхто з нас знає або може отримати доступ до інших віртуальним машини на тому ж обладнанні. Таким чином, щоб намалювати картину в сьогоднішніх слайдів, Я цей постріл тут з веб-сайту називається Докер. 

Так що це трохи більше детально, ніж ми насправді потрібно. Але якщо ви розглядати це як ваш infrastructure-- так що просто апаратні засоби самостійно, сервери, стелажі, дані центр, і все that-- ви б як правило, працюють під управлінням операційної системи хоста. Так щось like-- це може бути Windows. Це не було б Mac OS. Тому що це насправді не підприємство в ці дні. Так що це буде Linux або Solaris або Unix або BSD або FreeBSD або будь-яку кількість інших операційних систем які є або безкоштовно, або комерційний. 

А потім ви запускаєте програма, спеціальна програма, називається гипервизор, або монітор віртуальної машини, VMM. І ці продукти, якщо ви знайомі, як VMware або VirtualBox або Virtual PC або інші. І те, що ці програми роблять саме те, що особливість, яку я описав раніше. Це створює ілюзію що однією фізичної машині може бути кілька віртуальних машин. 

І ось ці барвисті коробки до верху намалювати картину в такий спосіб. Цей гипервизор, це частина програмного забезпечення, викличте його VMware, що працюють на якийсь інший операційна система, назвемо його Linux, створює ілюзію того, що це фізичний комп'ютер, насправді один, два, три віртуальних комп'ютерів. Так що я в даний час купив, як власник це обладнання, один фізичний комп'ютер. А тепер я оренди це три клієнта. 

І ці три клієнти все думають вони мають спеціальну віртуальну машину. І це не наживки і перемикач. Це більше розкриття, що ви використовуєте віртуальну машину. Але технологічно, ми все мають повний адміністративний контроль над кожним з цих гостя операційних систем, які могли б бути будь-яку кількість операційних систем. 

Я можу встановити все, що захочу. Я можу оновити його, як я хочу. І я навіть не потрібно знати або піклуватися про інших операційних системи на цьому комп'ютері, інші віртуальні машини, якщо не власник всього цього сірого мотлох будучи трохи жадібний і переоцінювати свої ресурси. 

Так що, якщо ви приймаєте один фізична машина і продавати його щоб не 200, а 400 клієнти, в якийсь момент ми збираємося поїздка в ті Ті ж проблеми з продуктивністю, як раніше. Оскільки у вас є тільки кінцеве обсяг диска і оперативної пам'яті і так далі. І віртуальна машина це просто програма, це вдаючи, що повноцінний комп'ютер. Таким чином, ви отримаєте те, що ви платите за тут. 

Таким чином, ви знайдете на сайті ви можете заплатити Шановна компанія може бути $ 100 в місяць для вашої власної віртуальної машині, або свій власний віртуальний виділений сервер, який є інший термін для цього. Або ви могли б знайти якийсь пролітають ніч, де ви платите $ 5,99 на місяць для вашої власної віртуальної машині. Але шанси у вас немає майже як багато продуктивності доступні для вас, тому що вони були перепроданості його так, ніж ви б з вищою рівня обслуговування або краще постачальника. 

Отже, що ж це насправді означає для нас? Отже, дозвольте мені перейти до цього. Я збираюся поїхати в aws.amazon.com. Просто тому, що у них є гарне меню опцій. Але ці ж уроки можна застосувати до ціла купа інших постачальників хмарних. На жаль, це часто більш маркетинг говорити, ніж що-небудь. І це постійно змінюється. Таким чином, ви йдете на сайт, як це. І це дійсно не має сказати вам багато всього. 

І навіть я, як я дивлюся на це, не насправді знати, що будь-який з цих речей обов'язково робити, поки я не пірнати. Але давайте почнемо з лівого боку, Compute. І я збираюся натиснути це. А тепер Amazon має відверто Переважна кількість послуг ці дні. Але Amazon EC2, мабуть, найпростіший. 

Amazon EC2 створить для нас точно картина ми бачили хвилину назад. Це, як вони роблять багато їхні гроші в хмарі. Мабуть, Netflix і інші знаходяться в хмарі з ними. Це все, як правило, пухнасті маркетингу говорять. Так що я хочу зробити, це піти в Pricing-- або, вірніше, підемо до екземплярів спочатку просто намалювати картину цього. 

Так що це буде варіюватися в залежності від постачальника. І нам не потрібно, щоб отримати занадто глибоко в бур'яни тут, як це все працює. Але шлях Amazon, наприклад, орендує вам віртуальну машину або сервер в хмарі у них є це свого роду кумедними назвами, як t2.nano, що означає маленький, або t2.large, що означає великий. Кожен з них дає вам або один або два віртуальних процесорів. 

Чому це віртуальний процесор? Ну, фізична машина може мають 64 або більше реальних процесорів. Але знову-таки, за допомогою програмного забезпечення, вони створюють ілюзію що, що одна машина може бути divvied до декількох користувачів. Таким чином, ми можемо думати про це як маючи один процесор Intel або два. кредитів CPU на hour-- я б повинні читати дрібний шрифт щодо того, що це насправді означає. Це означає, що, як велика частина машини ви можете використовувати в годину візаві інші клієнти на цьому апаратним забезпеченням. 

Ось скільки оперативної пам'яті або пам'яті у вас get-- або половину гігабайти, або 500 мегабайта, або 1 гігабайт, або 2. І тоді зберігання просто відноситься до якого роду дисків вони дають вам. Там в різні способи зберігання технології, які вони пропонують. Але більш цікаво, ніж це то може бути ціноутворення. 

Так що якщо ви технічний директор або інженер, який не чинить хочете запустити сервер в офіс, з якої причини, і це дуже складний або дорогий придбати сервери і спільно знайти їх і платити орендну плату в якомусь фізичному просторі клітці somewhere-- ви просто хочете, щоб сидіти на вашому ноутбуці пізно вночі, введіть дані вашої кредитної карти, і взяти в оренду сервери в cloud-- добре, ми можемо зробити це тут. Я збираюся піти вниз Linux, метою яких є найпопулярнішою операційною системою. І давайте просто отримати сенс речей. Whoops-- занадто великий. 

Так що давайте подивимося на їх найменшої віртуальна машина, яка, здається, є, для наших цілей, один процесор і 500 мегабайт оперативної пам'яті. Це досить маленький. Але, відверто кажучи, веб-сервери не потрібно зробити все, що багато. У вас є кращі функції в вашому ноутбуці. Але вам не потрібні ті, дані в ці дні для речей. Ви збираєтеся заплатити $ 0,0065 на годину. 

Отже, давайте подивимося. Якщо є 24 години на добу, і ми платимо стільки на годину, це буде коштувати вам $ 0,15 в оренду, що певний сервер в хмарі. І це тільки на один день. Якщо ми робимо це 365-- $ 57 до орендувати цей конкретний сервер. Так це звучить супер дешево. 

Це також дуже низька продуктивність. Таким чином, ми, на курси я викладаю тут, як правило, використовувати я думаю t2.smalls або t2.mediums. І ми могли б мати кілька сотень користувачі, кілька тисяч користувачів, заг. Це досить скромний. Отже, давайте подивимося, що це буде коштувати. Так що, якщо я роблю це витрати раз 24 годин 365 раз, на цей раз в $ 225. І на курси Я вчу, ми в цілому запустити два усього, для надмірності, а також для підвищення продуктивності. Таким чином, ми могли б витратити, тому, $ 500 для серверів що ми, можливо, буде потрібно в рік. 

Тепер, якщо вам потрібно більше performance-- давайте поглянемо на пам'ять. Ми говорили про пам'ять зовсім небагато. І якщо вам потрібно більше memory-- і 64 гігабайти це число, яке я тримав mentioning-- це майже $ 1 на годину. І ви можете досить швидко побачити, де це goes-- так 24 години 365 раз. Так що тепер це $ 8000 в рік для досить пристойний сервер. 

Так що в якийсь момент, є ця точка перегину де зараз ми могли б витратити $ 6000. ймовірно, і купити машину, як це і амортизувати його вартість більш може бути, два, три роки, термін служби машини. Але що може підштовхнути вас в сприяти або не сприяли оренди машина в хмарі, як це? Знову ж таки, це можна порівняти, мабуть, до одного з цих серверів Dell ми бачили на фото трохи назад. 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, це величезний потенціал зростання. Тому що ми не купуєте машина, ми не повинні розпаковувати його. Ми не повинні його підняти. Ми не повинні підключити його до нашої стійці. Ми не повинні його підключити. Ми не повинні платити електричний законопроект. 

Ми не повинні повернути кондиціювання повітря на. Коли жорсткий диск вмирає, ми не маємо забивати в середині ночі щоб виправити це. Ми не повинні встановити контроль. У нас немає, метою яких список продовжується і на всіх фізичних речей Вам не потрібно робити через "хмарі". 

І ясно, хмарні обчислення це дуже зловживають терміном. Це дійсно просто означає, що платити комусь ще для запуску серверів для вас, або оренди приміщень на сервери когось іншого. Таким чином, термін "хмарні обчислення" є новим. Ідея полягає в тому десятиліть. Так що це досить переконливим. 

А що ще ви отримуєте? Ну, ви також отримуєте можливість робити все, на ноутбуці у себе вдома. Іншими словами, все фотографії я просто drawing-- і це було не так давно, що навіть Я повзав на підлозі сервера підключити кабелі протягом кожна з ліній, які ви бачите, і оновлення операційної системи, а також зміна дисків навколо. Там дуже багато тілесність до всього цього. 

Але те, що красиво про віртуальну машини, оскільки назва роду припускає, Тепер є веб- інтерфейси за допомогою чого якщо ви хочете еквівалент лінії з цього сервера до іншого, просто тип, тип, тип, натисніть і перетягніть, натисніть кнопку Відправити, і вуаля, у вас є це провідні вгору практично. Тому що все це робиться в програмному забезпеченні. І причина, це робиться в програмне забезпечення знову тому що у нас так багато оперативної пам'яті і так багато CPU доступні для нас в ці дні, хоча все що матеріал займає багато часу, це повільніше вести справи в програмному забезпеченні, ніж апаратні засоби, так само, як це повільніше, щоб використовувати механічний Пристрій, як жорсткий диск, ніж RAM, щось чисто електронні. У нас так багато ресурсів доступні для нас. Ми, люди, є свого роду інваріантної повільно. І ось тепер машини можуть зробити так що набагато більше за одиницю часу. У нас є ці здібності робити щось віртуально. 

І я буду говорити на курси Я вчу, наприклад, тут, ми маємо про, може бути, десяток тому загальна кількість віртуальних машин як це працює в будь-який даний момент час, роблячи передній кінець речі, робити задній кінець речі. У нас є всі наші сховища. Таким чином, будь-яке відео, в тому числі речі як це, що ми знімаємо, ми в кінцевому підсумку покласти в хмару. Amazon має послуги під назвою Amazon S3, їх простий сервіс зберігання, який точно так само як обсяг дискового простору в хмарі. У них є щось називається CloudFront, який це послуга CDN, Content Служба доставки мережі, яка означає, що вони приймають всі ваші файли і для вас автомагіческі повторити його навколо світу. 

Таким чином, вони не роблять це превентивно. Але в перший раз хтось в Індії запитує файл, вони потенційно кешувати його локально. У перший раз в Китаї, перший раз в Бразилії, що відбувається, вони почнуть кешування його локально. І ви не повинні робити нічого з цього. І так це неймовірно змушуючи ці дні, щоб перемістити речі в хмару. Тому що у вас є ця можливість в буквальному сенсі щоб не мати людей роблять майже стільки ж робота. І ви в буквальному сенсі не потрібно так багато люди роблять ці робочі місця anymore-- "OPS", або функціональні ролі, більше. Ви насправді просто потрібно Розробники і менше інженерів хто може просто зробити щось віртуально. Насправді, просто щоб дати ви почуття цього, дозвольте мені перейти до ціноутворення на один інший продукт тут. Давайте подивимося, щось на зразок CDN S3. Таким чином, це по суті віртуальний жорсткий диск в хмарі. І якщо ми перейдіть до pricing-- так що $ 0,007 за гігабайт. І that's--, як ми це робимо? Я думаю, що в місяць. 

Так що, якщо це за month-- або в день? Ден, це за день? Це в місяць, OK. Так що, якщо це за month-- На жаль, це $ 0,03 на місяць. Там в 12 місяців в році. Так скільки даних може зберігати в хмарі? Гігабайт не настільки велика, але я не знаю, як 1 терабайт, так як 1000 з них. Це ще не все, що багато. Це $ 368 для зберігання терабайт даних в хмарі Amazon. Так що деякі з компроміси, то? Вона не може бути все добре. Нічого ми говорили сьогодні немає свого роду без улову або вартості. Так що погано про переїзд все в хмарі? АУДИТОРІЯ: Безпека. DAVID Маланки: Добре, що ви маєте на увазі? ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Так, вірно. І чи дійсно ви хочете деякі випадкові інженери на Амазонки, що ви ніколи не зустрінете маючи фізичний доступ до цих комп'ютерів, і якщо вони насправді хотів, віртуальний доступ? І хоча в теорія software-- добре, Шифрування може абсолютно захистити вас від цього. Так що, якщо те, що ви зберігання на серверах є encrypted-- менше занепокоєння. 

Але як тільки людина має фізичний доступ до машини, шифрування в сторону, всі ставки є свого роду гру. Можливо, ви знаєте з минулих років що ПК особливо, навіть якщо у вас ці речі звані "паролі BIOS," були, коли ваш робочий стіл завантажився, ви б запит з паролем, який не має нічого спільного з Вікна, як правило, ви можете просто відкрити шасі машина, знайти крихітні шпильки, і використовувати те, що називається стрибун і просто підключити ці два дроти приблизно на одну секунду, таким чином завершуючи схему. І це усуне пароль. 

Тому, коли у вас є фізичний доступ до пристрій, ви можете зробити щось подібне. Ви можете видалити жорсткий диск. Ви можете отримати доступ до нього таким чином. І ось чому, в випадок Dropbox, наприклад, це трохи викликає занепокоєння, що не тільки вони є дані, навіть якщо це зашифроване, у них також є ключ. Інші турботи? 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Так, це дуже true-- в Googles, яблука, в Microsofts світу. І справді, як довго у Вас був свій iPhone для? Так, давати чи приймати. ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Я шкодую? Ви серед тих, хто має iPhone, чи не так? ГЛЯДАЧІ: Так. DAVID Маланки: Як довго Ви мали свій iPhone? ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: ОК, так що Apple, в буквальному сенсі знає де ви були щогодини на наступний день протягом останніх п'яти років. 

ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Що чудова особливість. ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Так, але компроміс напевно. ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: Так, це дуже легко. ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Інші негативні сторони? ГЛЯДАЧІ: [нерозбірливо] DAVID Маланки: Absolutely-- технологічно, економічно, це досить змушує свого роду отримати ці економії від масштабу і перемістити всі в так зване хмара. Але ви, ймовірно, хочете йдуть з деякими з найбільших риба, амазонки, то Googles, то Microsofts-- Rackspace досить big-- і кілька інших, а не обов'язково літати вночі люди для яких це дуже легко зробити цей вид техніки в наші дні. І ось, кого ви можете платити $ 5,99 на місяць. Але ви, звичайно, отримати те, що ви платите. 

Коли ви говорите [нерозбірливо], що, коли такі речі, як ці п'ять дев'яток придумали, причому навіть якщо технологічно ми не можемо гарантувати 99.999, ми просто побудувати в деякому роді пені за договором так що, якщо це станеться, принаймні, є деяка вартість до нас, продавець. І це те, що ви, як правило, отримувати їх погодитися. 

ГЛЯДАЧІ: [нерозбірливо] 

DAVID Маланки: І один вид благословення в тому, що навіть коли ми йдемо вниз, для наприклад, або навіть деякі компанії, реальність така, Amazon, наприклад, має так багато штопати клієнтів, добре відомі клієнти, працюючи з певних центрів обробки даних що колись дійсно йде не так, як стихійні лиха і погодних умов і таких, якщо є будь-якої срібні накладки, це те, що ви перебуваєте в дуже хорошій компанії. Ваш сайт може перебувати в автономному режимі. Але так як половина популярний інтернет. І таким чином це, можливо, трохи більш прийнятним для ваших клієнтів якщо це більше з Інтернету річ, ніж acme.com річ. Але це ніби обману. 

Так що з точки зору інших речей, щоб дивитися на, просто так, що ми не виключаємо інших, якщо ви йдете в Microsoft Azure, вони мають як Linux і Windows, речі що можна порівняти з Amazon. Якщо ви йдете в Google Compute Engine, у них є щось подібне, а також. І просто закруглити ці хмарні пропозиції, Я славимо ще одну річ. Це популярний веб-сайт це представник класу технологій. Ті, кого ми тільки що говорили о, Amazon, буде МААН, Інфраструктура як сервіс, де ви свого роду фізичне обладнання в якості служби. Там в SAAS. Насправді, дозвольте мені коротко ці вниз. 

IAAS-- інфраструктура Як служба, SAAS, і PAAS, які є дивно заплутані акроніми які описують три різні типи речей. І самі абревіатури насправді не має значення. Це все речі хмар ми тільки що говорили про те, матеріал нижчий рівень, віртуалізації апаратних засобів і зберігання в так званому хмарі, будь то Amazon, Microsoft, Google, або інший. 

Програмне забезпечення як service-- все з нас свого роду використовувати цю функцію. При використанні Служб Google для Gmail або календарями, будь-який з цих веб додатки, які 10 років тому ми буде двічі натиснув на іконки наш настільний комп'ютер, програмне забезпечення як послуга Зараз дійсно веб-додаток. І як платформа Сервіс вид залежить від багатьох чинників. 

І один приклад я дам вам тут в контексті хмарних computing-- є одна компанія, яка досить популярні в ці дні, Heroku. І вони це послуга, платформа, якщо ви будете, який працює на вершині Інфраструктура Амазонки. І вони просто роблять його ще простіше для розробників та інженерів щоб отримати веб-додатків в Інтернеті. 

Це біль, спочатку, використовувати Amazon Web Services і інші речі. Тому що ви насправді є знати і розуміти про бази даних і веб-серверів і балансування навантаження і всі речі Я тільки що говорив о. Тому що все Amazon зробив це не приховані ці конструктивні проблеми. Вони тільки віртуалізувати їх і перемістити їх в браузері, в програмне забезпечення, а не апаратного забезпечення. 

Але такі компанії, як Heroku і інших провайдери PaaS, платформа як сервіс, вони використовують ці основи Barebone що ми тільки що говорили про те, і вони будують легше використовувати програмне забезпечення на ньому так що якщо ви хочете, щоб отримати веб- додатків онлайн в ці дні, Ви, звичайно, повинні вміти програмувати. Ви повинні знати, Java або Python або PHP або Рубі або купа інших мов. 

Але вам також потрібно місце, щоб помістити його. І ми говорили раніше про отримання веб-хостингу компанії. Це свого роду, як в середині 2000-х підхід до отримати щось в Інтернеті. В даний час ви могли б замість того, щоб платити комусь як Heroku кілька доларів в місяць. І по суті справи, як тільки ви зробив деяку початкову конфігурацію, оновити свій веб-сайт, ви просто введіть команду у вікні. І незалежно від того коду ви написали тут на вашому ноутбуці негайно отримує розподіляється на будь-яке число серверів в хмарі. 

І Heroku піклується про всі складності. Вони вважають, що всі бази даних матеріал, все балансування навантаження, всі головні болі, які ми просто написано на дошці, і приховати всі, що для вас. І в свою чергу, ви просто платити їм трохи більше. Таким чином, у вас є такий інфраструктури, як сервіс, платформи як сервіс, а потім програмне забезпечення як послуга. Це, знову ж таки, це абстракція або нашарування. 

Будь-які питання на хмарі або будівництво власної інфраструктури? Добре, що було багато. Чому б нам не піти далі і прийняти нашу 15-хвилинну перерву тут. Ми повернемося з декількома новими концепціями і трохи практичної можливості до того, як вечір закінчився.