Hackconf 2016 - Да пишем код за хиляди сървъри
Download as PPTX, PDF0 likes641 views
Много често, когато искаме да станем по-добри backend програмисти се опитваме да научим различни езици за програмиране и съответните библиотеки. Проблема е че в Rails, Express.js, Django или Zend Framework има горе долу едни и същи концепции. Ако искаме да се научим как да пишем код за големи системи, които скалират добре и се справят сами с различни грешки и неочаквани ситуации, трябва да овладеем един друг дял от човешкото познание, който се нарича разпределени системи. В моята презентация ще видим защо трябва да задълбаем в тях и какви са основните принципи като консистентност(consistency), достъпност(availability) и издръжливост на разделения(partition tolerance). Също, ще разгледаме стъпки, които всеки може да направи за да научи повече по темата и да получава нови и актуални знания.
Hackconf 2016 - Да пишем код за хиляди сървъри
- 1. Да пишем код за хиляди сървъри @stoitsev
- 6. MVC Структура ORM Библиотека за тестове Миграции за СУБД Библиотека за шаблони Библиотека за кеширане Превод и локализация Scaffolding Logging Сигурност Валидация на форми
- 10. Вертикално
- 14. Разпределена система “Разпределена система е група от самостоятелни сървъри, които работят заедно и отвън изглеждат като една цялостна система”
- 16. 120 сървъра = 1 сървър на месец
- 17. 1200 сървъра = 1 сървър на 15 дни
- 18. 12000 сървъра = 1 сървър на 7.5 часа
- 22. Децентрализирани алгоритми 1. Никоя машина няма информация за състоянитето на цялата система. 2. Всяка машина решава спряло локалната си информация. 3. Повреда е една машина не разваля целия алгоритъм. 4. Не се предполага че съществъва глобален часовник.
- 27. 1. Няма централизирано знание 2. Всеки сам има списък 3. Ако една машина се повреди, алгоритъма си работи 4. Няма глобален часовник
- 30. Репликация
- 31. Репликация
- 32. Разделяне на мрежата Partition tolerance
- 33. 100 лв.
- 34. 100 лв. 100 лв.
- 35. CAP Теорема
- 36. Доказателство Seth Gilbert and Nancy Lynch. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services.
- 41. “A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.”
- 43. Въпроси?
Editor's Notes
- #2: Здравейте на всички. Аз съм Ники и съм тук днес да ви разкажа за това как да пишем код за хиляди сървъри…
- #3: Първо няколко думи за мен. Аз съм софтуерен инженер в Убер, която е една голяма платформа, където се занимавам с разпределени системи извършващи плащания и различни други аспекти при работата с пари. Вчера по време на първата лекция Aлекс Тодоров повдигна въпроса дали правим mutation testing. Отговора е да, правим за Java и за JavaScript понеже голяма част от най-важните ни системи са на javascript върху node.js и искаме те да са изключително добре изстествани. За Java имаме библиотека, която може да намерите в github организацията ни.
- #4: И аз също съм част от ФМИ мафията, уча там и от няколко години водя упражнения
- #5: Та очевидно днес ще си говорим за бекенд. Да пятам - коло хора се определят като фронтенд девелъпъри, колко от вас са писали някакви backend неща , колко от вас са рънвали бекенд с повече от 100 сървъра, колко са ставали в 3 през нощта понеже бекенда им се е счупил Моята презентация е доста по-различна от тези които видяхте до сега на тази конференция. Тя е доста технически, с термини и теореми. Но нещо което всички ви казаха е че няма значение какъв език за програмиране или какъв framework ще си изберете, стига да разбирате нещата в осново. Днес точно това ще направим. Ще видим някакви принципи на backend нещата.
- #6: Та когато си избираме технология имаме доста голям избор и повечето пъти го правим спрямо езика за програмиране, който знаем. Тук виждаме няколко примера. Да направим едно малко състезание. Колко хора пишат на рейлс? Някой пише ли на django? Някой zend, php? А spring?
- #7: Без значение кой модерен фреймуърк ще си изберем, те горе долу имат едни и същи фийчъри...
- #9: Първото нещо което искаме да постигнем е мащабируемост - scalability Мащабируемост е възможноста на една система да увеличава количеството работа което извършва или да увеличи размера или капацитета си за да се справи с това увеличаване.
- #10: Ако имаме приложение, което работи на един сървър и искаме да го скалираме, може да го направим по 2 начина.
- #11: Първия е вертикално. При него си копуваме по-добър хардуер и започваме да използваме него. Това е по-евтино в началото и е много по-лесно
- #12: Но има 3 проблема с вертикалното скалиране… първия е закона на муур(транзисторите в един процесор се удвояват всеки 18 месеца)… втория е че данните в мрежата се удвояват всеки 12 месеца… третия е че човешкото знание също се удвоява всеки 12 месеца
- #13: Затова ще разгледаме втория начин, хоризонтално - при него нашата система увеличава капацитета си като добавя допълнителни сървъри
- #14: Този начин за скалиране е добър може може да се прави доста динамично - просто добавяш още машини, може да става през някакъв уеб портал. Другата е че прави системата по-надеждна, понеже дори и един от сървърите да се счупи другите може да продължат работа.
- #15: Така получаваме разпределена система...
- #16: Разпределената система е много много по-трудна за управление поради няколко причини. Първата е че нещата се чупят доста. Да предположим че един компютър се счупва веднъж на 10 години… тоест шанса е 1 на 120
- #20: Също така съм и мрежата се чупи the network will go down for annoying reasons: power failures, broken hardware, someone tripping a cord, vortex to other dimensions engulfing mission-critical components, headcrabs infestation, copper theft, etc И скороста на самата мрежа е непредвидима Study of Univeristy of Toronto and Microsoft - average failure rate of 5.2 devices per day and 40.8 links per day, with a median time to repair of approximately five minutes (and a maximum of one week), packet loss of 59,000 packets per failure. First year for a new Google cluster involves: • Five racks going wonky (40-80 machines seeing 50 percent packet loss). • Eight network maintenance events (four of which might cause ~30-minute random connectivity losses). • Three router failures (resulting in the need to pull traffic immediately for an hour).
- #21: Дори и цял дейтацентър може да се счупи. Виждал съм го да се случва не веднъж. Например, един инженер прави неправилна настройка на мрежата и цялата мрежа спира да работи. Може да намерите доста примери от най-различни компании като amazon и google. Когато проектираме нашаща разпределена система е добре да помислим как да се справяме с такива ситуации. Имаме реален случай, един рак се запалва, става пожар, изгасва централно тока…(един рак изгаря суича отгоре, започва да дими, включва пожарната аларма и тока спира) В друг дайта център в индия, хората решили да отваорят прозорците
- #22: Проблем е че може да си пейстнеш active record заявката в stackoverflow и да питаш защо не работи… няма как да питаш защо системата е толкова бавна в определена операция… може да питаш някакви малко архитектурни неща… няма кой да седи и да ни проектира системата в stackoverflow така че да реши точно нашия проблем с нашите инструменти
- #24: Един много просто пример на този протокол е ако има трима асистенти в един университет и те трябва да проверят едни домашни.
- #25: Ако имаме хиляди сървъри и искаме те да работят заедно, можем да имплементираме алгоритъм при които всеки знае, с колко и кои други сървъри работи. Проблема е как да разберем когато някой хост е добавен или кога е развален и повече не може да го достъпваме.
- #29: Освен тези принципи има и някои основни концепции Всички знаят едно и също In the previous example, consistency would be having the ability to have the system, whether there are 2 or 1000 nodes that can answer queries, to see exactly the same amount of money in the account at a given time.
- #31: Тhe key solution to high availability is redundancy.
- #32: По-евтино е да не я записваме навсякъде
- #33: The whole point of partition tolerance is that the system can work with messages possibly being lost between components. Примера
- #41: In the real world, we can have various things like quorum systems where we turn this 'yes/no' question into a dial we can turn to choose how much consistency we want. By changing making the M value of required nodes up to N (the total number of nodes), you can have a fully consistent system. By giving M the value 1, you have a fully AP system, with no consistency guarantees.
- #42: Лесли Лампорт, носител за наградата Тюринг за 2013