Темы тринадцатого выпуска: что не так с электронной почтой, использование Haskell в продакшене и новый фреймворк rest, какая связь между моноидами и Summingbird, что такое Lambda Architecture, и причем тут Samza, Storm или Kafka, тонкости работы с ZooKeeper, как правильно решается проблема service discovery и из какого места должна бить радуга, если очень быстро едешь на велосипеде. Предыдущие выпуски: двенадцатый , одиннадцатый , десятый , девятый .
Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/13/
Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/13/file/podfm_eaxcast__eaxcast_206.mp3
Шоу нотес:
- Пост про замену электронной почты , о котором шла речь;
- Выпуск 037 Parellel Universe With Ron Pressler подкаста Mostly Erlang;
- Подкаст , который нашел по ссылкам Сережа;
- Сайт, посвященный Lambda Architecture — lambda-architecture.net ;
- Книга Big Data за авторством Nathan Marz и James Warren;
- Статья Nathan Marz об LA под названием How to beat the CAP theorem ;
- Статья Jay Kreps Questioning the Lambda Architecture ;
- Упомянутые софтины — ZooKeeper , Kafka , Samza , Storm , Consul , etcd ;
- Фреймворк под названием rest , написанный на Haskell;
- Скандальная история взлома Code Spaces ;
- Картофельный салат набрал на KickStarter уже более 60 000$ ;
Голоса выпуска: Никита @nikitonsky Прокопов, Валерий @sum3rman Мелешкин, Сергей @kpy3 Елин, Александр @afiskon Алексеев
Фоновая музыка: The Panets — Winter Beats (Big Power Mix)
Александр: Вы слушаете вторую часть интервью с nikitonsky… или tonsky, в разных соцсетях по-разному. Приятного прослушивания!
Сергей: Интересно, когда-нибудь появится Java, которой ничего не нужно будет? Такие уже были попытки, насколько я помню. Даже был процессор, который умел исполнять инструкции байт-кода, только он как-то не «взлетел». Это еще где-то в 90-х было, помнится. Было бы интересно посмотреть на некую вычислительную станцию, которая работает исключительно на скомпилированном байт-коде.
А: Это все устарелая мысль. Я сегодня слушал замечательный подкаст, который Mostly Erlang, и там ребята обсуждают, что современные процессоры и вообще компьютеры, они настолько сложны, что ты писать эффективный код, который будет одинаково эффективно работать на Ivy Bridge и на чем-то другом, ты как программист физически не можешь. У тебя просто это в голове все не уместится, настолько все сложно. Поэтому тебе нужен некий уровень абстракции от железа. По-моему, это 0037 выпуск, подкаст называется Mostly Erlang.
С: Надо послушать.
А: Он вообще замечательный, там много интересного конкретно в этом выпуске.
С: Я только не понял, они, таким образом, пытаются оправдать отсутствие JIT в Erlang-е?
А: У меня другой вопрос, к нам, что, sum3rman подрубился?
Валерий: Да, я тут, извините ребята, я тут сломался по дороге, так получилось.
А: Ну, ты успел на последние три минуты буквально.
С: Ты как раз успеешь сказать «пока» всем.
А: Валера, если кто не знает, добирается до работы на велосипеде. Ему в +30 не влом.
С: Ну, он специально сидел на работе пока не остыло, я так понимаю.
А: Я вот не понимаю, у меня тоже когда-то был длинный хаер. Как можно с таким длинным хаером еще по жаре ездить на велосипеде? Я бы там просто умер.
С: Я тебе могу рассказать, как. У меня доча на велике гоняет с длинным хаером. Каждый раз, когда она резко передо мной тормозит, она говорит: «Папа, папа, ты, правда, видел радугу?». Она считает, что из хаера должна бить радуга, когда быстро едешь на велосипеде.
В: Она слишком много смотрела поняш?
С: Ага, она фанат поняш.
А: Так, пока мы совсем не ушли…
С: Вот, так мы и перешли к поняшам!
А: Пока мы совсем не ушли в послешоу, Валер, может быть, у тебя есть какой-нибудь последний вопрос?
В: Понимаешь, я очень опасаюсь, что вы его уже спросили.
А: А ты спроси что-нибудь необычное.
В: Что-нибудь необычное? Не знаю, я сейчас прям весь еще, буквально, в мыле пришел, и мне стало интересно, и я присоединился. Не знаю, что я могу такого спросить.
С: Вот и спроси про мыло.
В: Про мыло?
С: Чтобы это не значило.
В: Вот, Никита, у тебя когда-то был концепт заменителя e-mail-a, расскажи нам про него.
Никита: Да, был когда-то такой концепт, смысл в том, чтобы на самом деле, e-mail перенести на какой-то центральный сервер, на котором все были, в одно и то же место, по сути, «втыкали». А не такой, что, вот как сейчас, какие-то разные сервера общаются между собой и пересылают почту туда-сюда. Основная у меня претензия к e-mail, что юзабилити очень неприятный. Трудно подключить человека к дискуссии, трудно подключиться к дискуссии и тд.
Вообще, трудно создавать дискуссии, трудно следить за какими-то тредами, трудно создавать алиасы, нужен какой-то админ, чтобы создавать алиасы. Ну, такого плана. У нас, например… короче в Echo у нас официальным мессенджером был Skype, причем мы два или три раза пытались перейти на Jabber. Что-то скайп, короче, всех задолбал и мы пытались перейти на Jabber. Не смогли, потому что народа там 20 человек, кто-то недоперейдет и в итоге через два-три дня все опять сидят в скайпе.
А в Machine Zone официальный чатик — это Jabber, как раз, но когда сотрудники Echo перешли в Machine Zone, они форсят туда Erlang и более того, они еще и перетаскивают тех, кто сейчас в Machine Zone работает, форсят скайп, и перетаскивают тех, кто там сейчас работает тоже на скайп. По очень простой причине, потому что в Jabber-е, чтобы создать комнату на несколько человек, нужен сисадмин, а в скайпе не нужен. В скайпе ты просто говоришь «Этот, этот, этот человек, давайте заведем дискуссию», и общаешься. И, вот эта легкость, она, в принципе, решает.
Соответственно, в e-mail тоже такого хотелось бы, примерно, такого уровня, плюс там, исправлять письма, если ты опечатался. Почему бы тебе там что-то не исправить? Но, плюс, на самом деле, легковесности хочется. Меня, к примеру, бесит все аттачменты в письме… Не аттачменты, а цитаты из предыдущих писем. Каждое письмо накапливает, как ком, всех предыдущих комментаторов, которые в него писали. Эта штука очень легко ломается. У меня она постоянно ломается, потому что у разных людей разные клиенты и разные стили реплая, поэтому это обычно каша такая из стрелочек, каких-то линий, отступов и тд. Там трудно разобраться, кто, что писал когда, они еще вложены друг в друга. Короче — ад.
Вот, хочется линейную дискуссию вести. Что-нибудь типа Facebook Messages. Короче, центральный сервер, на котором идет общение, все смотрят вот так в тоже место «втыкают», можно там подписываться на дискуссии, и тд. У гугла был проект Wave, который достаточно близко к этому подошел, но они его, на самом деле, немножко зафакапили переусложнением и, в общем-то, тем, что он over e-mail ничего особо не предлагал. Центральный интерфейс, конечно, предлагал.
У меня еще была концепция потоков. Потоки — это что-то вроде места, на которое можно подписаться, в которое могут люди писать. Люди пишут не на какой-то адрес, а в какой-то поток. Допустим, если тебе интересна какая-то тема, то ты подписываешься на поток и получаешь оттуда письма. Если тебе она не интересна, ты оттуда отписываешься, но письма туда все равно идут. И через эту концепцию можно все, что угодно сделать. Можно сделать персональные чатики, ну, свести к этому, можно сделать письма с подтверждением регистрации, паролями, служебными какими-то… Ты купил товар на Amazon-е, тебе там, порядка 50 писем приходит о том, как его переложили из места A в место B, как его запаковали, как его отправили в почту. Такие штуки тоже, в принципе, делаются. Служебная почта в это все дело вписывается и получается такая изящная стройная система, вроде бы, если научить людей ею пользоваться.
В: Но ведь есть, во-первых, очень много всяких развитий от чатиков, вроде Slack , вроде kato.im , в какой-то степени — HipChat , но он беднее гораздо, и то, что ты предлагаешь, уже во многом перекрывается существующими штуками, ну кроме скайпа. А, во-вторых, не возникнет ли проблем с выведением данных?
А: Перед тем, как ты ответишь, у меня есть предложение. Мы можем либо сейчас завершить выпуск на этой радостной ноте, либо записать два выпуска, разбив его на две части.
С: Я, все-таки, за «завершить», потому что у меня несобранный чемодан, простите ребята.
А: Ты можешь, кстати, нас покинуть, мы останемся втроем.
С: Нет, я хочу послушать. Я просто разрываюсь, сижу.
А: Валер, ты как?
В: Я? Я не знаю. Я в шоке.
А: Никит?
Н: Ну, мне все равно. А там ограничение по времени?
А: Да, у нас есть копирайтеры, которые делают текстовую расшифровку и им очень тяжко, когда выпуски длинные.
Н: Ну, смотрите. Я не знаю, я могу еще час говорить.
А: Я лично за двойной выпуск раз вы так разговорились про почту.
С: Да, а я тут…
А: Ты послушаешь потом, когда мы опубликуем, Сереж.
С: Я послушаю потом, да. Я просто хотел сказать, что я тут случайно по ссылочкам… Я не воспроизведу это, но я, кажется, нашел еще один интересный подкаст. И тут должен выйти подкаст, как раз с Ричи Хики, что-то он будет рассказывать. Сейчас скину в чатик.
А: Да, ну так мы тебя, Никит, перебили. Или кто говорил?
В: Ну я давал слово Никите. Я спросил два вопроса у Никиты.
Н: Вопрос был про чатики? Чатики, в принципе, да, и это похоже, опять же… Короче, одна из концепций еще была в том, чтобы попытаться объединить возможность писать длинные письма и короткие. Сейчас ты можешь в почте написать письмо, состоящее из слова «Да», но это противоестественно как-то выглядит. Или ты можешь, в принципе, в чатик написать 20-30 строк текста, но опять же, это тоже выглядит противоестественно. И у меня была идея, что при правильном подходе, это теоретически можно объединить в один интерфейс, но это не совсем проработано, это гипотеза пока.
Потому что есть такая интересная штука с людьми, что люди очень хорошо по размеру сообщений научились разделять сервисы. Отличие Twitter, от Facebook и ЖЖ, на самом деле, в размере сообщения. Есть средне ожидаемый размер сообщения, неограниченный платформой, ну кроме Twitter-а, и эти платформы для публикации, они очень четко по нему разграничены. И вот эта штука, ну я не знаю ее глубинные мотивы, почему так есть, но оно, вроде бы, так есть. Может быть, очень опасно пытаться объединить почту и чатики, но, по крайне мере, пока мне не известны примеры, где бы это успешно получилось. Но хочется, потому что концептуально отличий почты от чата, в принципе, нет. Только в размере сообщений.
А: Я буду честен, у нас кончились вопросы к гостю, которые были заготовлены. Поэтому мы можем перейти к каким-нибудь дежурным темам, их тут довольно много. Вот, например, мне будет интересно у тебя, Никита, спросить. В мире Haskell недавно вышел такой фреймворк, называется rest. Там идея в том, что ты описываешь на… не совсем DSL , в общем, некоторыми структурами ты описываешь свой ресурс в REST. Какие у него есть поля, какие значения. И у тебя этот фреймворк автоматически генерирует документацию, автоматически генерирует клиент на JavaScript, на Рубях, на Haskell-е. Пока больше ничего не поддерживает. Некоторые люди уверяли меня, что в мире Java все это давно есть, но названий конкретных фреймворков я выпытать так и не смог. Тебе, во-первых, ничего ли об этом неизвестно, и во-вторых, может быть тебе известно что-то об этом за пределами мира Java?
Н: Ну, название я, наверное, тоже не назову, но мне не кажется, что это, на самом деле, какое-то большое достижение. У меня есть такое мнение, что прелесть REST API … ну, концепция REST API состоит в том, что тебе не нужны клиентские библиотеки никакие, на самом деле, чтобы тебе поработать… Ну, вот я, как бы, писал проект, который работает с API соцсетей, у нас был Twitter, Facebook, YouTube, RSS был. Прелесть была в том, что мы не используем клиентские библиотеки для доступа к ним. Потому что REST API — это универсальная клиентская библиотека.
Тебе нужен HTTP клиент и все. Как бы, больше ничего и не нужно. Он является универсальной клиентской библиотекой к любому ресурсу. В этом смысле генерация клиентов для меня выглядит странным преимуществом. А что касается документации, опять же, у меня такое мнение, что документация должна писаться отдельно от кода и руками, осмысленно. Сгенерированная документация, я вижу в ней мало смысла, потому что это просто повторение информации, это, по сути — перекладывание информации из одного места, из кода, в другое место. Я считаю, что каждый артефакт должен нести какую-то добавленную ценность, не повторять ценность, которая уже в другом месте лежит, а какую-то дополнительную нести ценность. В этом смысле документация — огромный простор для подобных вещей.
Документация состоит не только в том, что ресурс — user, метод — update, апдейтит юзера. Это самые очевидные вещи. Нет, документация должна описывать, как раз, неочевидные вещи. Ну, как бы, реестр методов тоже нужен, но главная ценность — описывать какие-то неочевидные вещи и описывать общую картину. Документацией конкретного метода нельзя описать общую картину, как в целом API устроено, какие используются абстракции там, например, или еще что-то. Ну, и плюс, какие-то там гайды, как начать этим пользоваться, какие самые важные вещи, какие менее важные. То есть, структурирование не такое формальное, просто реестр алфавитный, а структурирование по смыслу. Это все приносит дополнительный смысл в то, что документация существует и она полезней, чем просто сгенерированная. Сгенерированная, на мой взгляд, достаточно бесполезна.
А: Понятно. Вопрос от одного из наших слушателей. Я к сожалению, сейчас не вспомню от кого именно, потому что это просто записано в Google Docs. Вопрос звучит следующим образом. Было бы очень интересно послушать на тему проектирования в функциональном стиле, шаблоны и пр. Вот, как ты считаешь, есть всякие там замыкания, лямбды и тд, это аналоги шаблонов проектирования из ООП или, вообще, не аналоги ни разу? Вопрос, в первую очередь, к Никите, а потом к Валере.
Н: Ну, замыкания и функции высшего порядка — это не шаблоны, а конструкции языка скорее, но, вообще, функциональный стиль он существует, но это именно стиль и да, можно считать это шаблонами, но опять же… Короче говоря, ФП меняет немножко стиль написания кода и меня, вот, например, критиковали, что я на Питоне начал писать по функциональному. Ну а что? Удобно, я по-другому уже не могу никак. Очень простой стиль, функции возвращают объекты, а не меняют какие-то объекты inline. Основное, чего избегает ФП — это inline изменение объектов. За счет этого между функциями очень четкие зависимости, кто что возвращает. Проще так следить за потоком кода. Вот основное, что для меня функциональный стиль приносит.
А: Валера?
В: Шаблоны, с моей точки зрения, — это такая вещь, которая… К примеру, есть идиоматика, но она ближе к языку какому-то конкретному, а есть шаблоны — какие-то идиомы, которые воспроизводятся во всех языках одной парадигмы. И, если в ООП есть какие-то одни шаблоны, которые, как правило, связаны с тем, что некоторые довольно композиционно сложные вещи, их иногда бывает тяжеловато выразить. Соответственно, в функциональном стиле появляются другие шаблоны, которые про другие ситуации, которые часто можно выразить и они примерно одинаково выражаются во всех функциональных языках. Ну, например, какие-нибудь итераты , вот, типичный функциональный паттерн. Некоторые шаблоны, они существуют и там и там. Если мы возьмем абстрактно написанный фасад, то он встретится в любом языке программирования, потому что это настолько общая штука, что она, наверное, везде есть. Так что, я не знаю, я не вижу большого смысла говорить о каких-то специальных функциональных шаблонах, потому что…
А: Ну, я тебя понял. Сереж, ты еще с нами или уже все?
С: Я уже все.
А: Ну, тогда пока.
С: Да, всем счастливо. Никита, спасибо, что приходил. Было очень интересно с тобой поговорить. Ну, ладно, все, отключаюсь.
Н: Пока.
А: А от себя я хотел сказать, что, действительно, вся эта боязнь монад , функторов и тд, оно, в первую очередь, от непонимания людей, что это не имеет ничего общего с шаблонами ООП — там всякими фабриками, билдерами и подобными вещами. Это просто то же самое, что переменные и циклы. Когда ты перестанешь заморачиваться на тему, что это какой-то местный паттерн и его там надо заботать, а это сложно, тогда приходит понимание и там, в принципе, нет ничего сложного. Вот, Валера, ты же протащил Haskell в продакшн, да?
В: Ой, такой уж прям продакшн. Это же не крутится в продакшене, это джоба которая по крону крутится на тестовой площадке.
А: Мы с Сережей не могли же не собезьянничать, и мы тоже протащили Haskell в продакшн , и, вот, я его писал, и там сплошные функторы, и моноиды, и монады. Ты с этим вполне естественно и спокойно работаешь, и нет тут никаких паттернов. То же самое, что переменные и циклы.
В: Моноид — это вообще такая штука, это паттерн из матана, точнее из алгебры. Если мы возьмем, какой-нибудь Summingbird Twitter-вский и всю ту обвязку, которую они до этого написали, в полнее себе ООП-м подходе берется и… Там очень хорошая смесь ООП и функциональщины. Там, где нужно, используется ООП, а там, где нужно, используется функциональщина. Ребята написали довольно красиво вплетающийся во весь этот стиль фреймворк для написания кастомных моноидов в Scala или Java.
И для чего это нужно? Для того, что данные, которые представляют собой моноид, очень хорошо ложатся на их вычислительную модель. И вот, они там автоматом могут что-то считать MapReduce’ом, что-то в Storm’е, и автоматом мержить результат. Казалось бы, тут не важно на чем это может быть написано. К чему я веду? То, что тот фреймворк, который написали, он мог быть написан на Scala, на Java, на Python, на чем угодно. Сама идея моноида от этого никуда не денется. Точно так же, я тут упомянул итераты, да, они, как бы, зародились в Haskell-е, но сейчас они постепенно появляются в ООП-х языках, просто потому что концепт-то удобный, на самом деле.
А: Вот, раз ты заговорил про Storm и подобные вещи… Никит, тебе о чем-то говорит название Lambda Architecture?
Н: Да, мы Storm использовали. Потом выкинули, правда. Lambda Architecture — это развитие тех же чуваков вроде как, концепция.
В: Ну, собственно, Summingbird — это по сути Lambda Architecture. Слушай, а ты можешь рассказать, почему выкинули? Я помню, ты писал пост, но, во-первых, я сам пост уже забыл, а, во-вторых, ты, может, сейчас что-нибудь такое расскажешь, чего в посте не рассказывал.
Н: Да, там очень просто все, он нам не слишком удачно подошел. Storm создает статическую сеть вот этих болтов и спаутов, это pipeline по обработке данных. Ты его создаешь на старте и потом гоняешь через него данные. А процессора по апдейту этого pipeline у них нет. Нельзя добавить новый болт где-то сбоку. А нам такая штука была нужна. У нас состояние приложения интерактивное, мы можем в реальном времени добавить какого-то юзера Twitter и нам нужно создать поток, который следит за этим юзером. Поэтому мы не смогли использовать Storm для этих целей.
Плюс там были всякие проблемы типа того, что у него был баг с редиплоем, типа ты обновляешь, а он в каких-то случаях умудрялся словить рейс кондишн на аплоаде jar’ки. Эта штука меня до сих пор шокирует. Где они там смогли словить рейс кондишн? Но они смогли. Плюс это такой фреймворк, он дает тебе все, и ты вписываешь свой код в маленькое, специально предназначенное место, а все остальное он за тебя решает, в том числе, версию Clojure, версию библиотек. Мы, в основном, запоролись на том, что мы не могли проапгрейдить Clojure, не могли проапгрейдить ZooKeeper и не могли какую-то еще библиотеку проапгрейдить, потому что Storm свои ставит библиотеки, в своем составе, а твое приложение к ним догружает, поэтому там нельзя было поменять. И с логированием там какая-то задница была. Логирование нужно делать… Точнее оно сделано уже в Storm, ты можешь только вписать свои классы в их log config, соответственно там гибкости никакой.
А: У меня пояснение и вопрос. Пояснение для наших слушателей, для тех, кто не понимает, что такое Lambda Architecture и о чем идет речь. Это архитектура, которую пытаются популяризировать товарищ Nathan Marz , если я правильно читаю, чувак из Twitter-а, который автор Storm. Идея заключается в том, что… Блин, проще дать ссылку на статью, потому что это займет у вас пять минут прочитать. Идея в том, что у вас все события в системе, они записываются в log, например, этот log хранится в HDFS, в Hadoop’е, где у тебя в этот log только дозаписываются события, что что-то произошло.
У тебя от этого benefit, потому что данные немутабельны, потому что они там круто реплицируются и все такое. И, имея вот этот log, ты из него всегда можешь получить… Как бы, это у тебя сырые данные, ты из них всегда можешь получить любую вьюху. Например, из событий, что я кого-то зафрендил, зафрендил, потом кого-то анзафрендил, я могу всегда получить количество друзей, кто у меня сейчас в друзьях и тд. По log-у я получаю какой-то интересный view. И Lambda Architecture — это о том, как такие log-и хранить, обрабатывать, как это сделать эффективно, с одной стороны, чтобы у тебя… Да, и не только эффективно, но и, как сделать это устойчивым к ошибкам, в том числе ошибкам со стороны программиста. Если ты сделал ошибку, программируя вьюху, как тебе потом все это по log-ам можно пересчитать.
В: Прости, Саш, но ты гонишь. Ты не про Lambda Architecture рассказываешь.
А: Тогда расскажи, как ты это видишь.
В: То, что ты рассказываешь — какие-то детали реализации. Основная идея Lambda Architecture в том, что, вот у нас есть MapReduce, который прекрасно справляется с batch processing. И у нас есть всякие Storm и тому подобные вещи, которые прекрасно справляются с real time stream processing. Зачастую, почти все задачи современные, многие современные задачи анализа данных, они требуют, и возможность в real time что-то запросить по-быстрому, и сделать какое-то историческое ретроспективное видение.
Как правило, у нас есть какой-то вид. Мы запрашиваем какую-то вьюху и мы в ней хотим видеть как исторические данные, так и данные, которые, буквально, полсекунды назад прилетели. Проблема с Hadoop в том, что они не очень хорошо подходят, сама парадигма, не очень хорошо подходит для того, чтобы быстренько досчитать эти данные, которые долетели в последние полсекунды. А всякие Storm и тому подобные, они не очень хорошо подходят для того, чтобы обрабатывать кучу исторических данных. Можно сделать какую-нибудь универсальную вычислительную модель, есть такие попытки и даже довольно неплохие.
А есть Lambda Architecture, когда мы просто говорим, что у нас есть одна штука и другая штука, давайте мы построим над ними еще один слой запросов и будем данные такие делать, собственно, например, моноид, как в Summingbird, и это нам позволит вести обработку и там, и там. Запрос будет прозрачно добирать, оттуда, откуда эти данные уже есть. Предпочтительней выбирать из batch обработанных данных, но если там данных еще нет, мы сходим значит в наш с real time stream processing систему и выберем из нее данные. Вот это основная идея Lambda Architecture. Собственно, можно послушать доклады про Summingbird, можно пойти на сайт lambda-architecture.net.
А: Я рассказывал в интерпретации, которую я получил. Я сейчас читаю книжку, которая называется Big Data, того же автора, который Nathan Marz, как он там объясняет. Может быть, я не до конца дочитал, может быть, что-то не так понял…
В: Я сейчас открыл сайт lambda-architecture.net, чтобы не соврать…
А: Сайт lambda-architecture.net — это просто каталог статей.
В: Но там есть большая картинка с объяснением архитектуры очень высокоуровневым и то, что ты говоришь, это уже очень глубокие детали, а основная идея — в том, что у нас есть batch processing, и есть real time stream processing, и у нас есть какой-то слой, который позволяет и оттуда, и оттуда выгребать по мере возможности.
А: Ну да. А еще есть такой интересный товарищ Jay Kreps , если я правильно читаю, чувак из LinkedIn и автор Kafka.
В: А также Samza.
А: Который написал интересную статью о том, что чувак из Twitter-а не очень прав и я, чувак из LinkedIn, считаю, что все можно делать Кафкой и Самзой, и не нужен вам Hadoop. Тоже интересная статья, ознакомьтесь, там, в принципе, здравые мысли.
Н: Я, как раз, сегодня ее открыл ее на прочитать.
В: Кстати, про ZooKeeper. Никит, у вас большой опыт использования ZooKeeper, как я понимаю, потому что вы и Storm использовали, и я так понимаю, что он у вас где-то еще используется. Я про него почитал много страшилок, в частности, что он не умеет реконфигурироваться на лету, про то, что у него какие-то безумные гарантии консистентности, потому что чтение всегда стейл и непонятно, с кого читаешь. Я стараюсь обходить ZooKeeper как можно дальше стороной. Что ты можешь по поводу моей боязни сказать?
А: Сори, что я влез. До твоего прихода как раз Никита рассказывал о том, как у них классно был ZooKeeper в продакшене, и вот, да, я тоже хотел это спросить.
Н: Ну, я не рассказывал, что он был классный, я говорил, что он был :). Да, у нас был ZooKeeper, но он странный. У него там прям есть странности, если про него почитать. Например, мы хранили где-то в нем 8 Мб данных всего, и он при этом умудрялся, какими-то 2-х гигабайтными файлами ворочить на диске. Мы выделили ему раздел в 2 Гб, и он за него стабильно выходил, хотя подчищение логов и все такое, там было. Такие вот странности.
Ну, там есть еще странности типа того, что чуваки используют его для конфигурирования 100 серверов и жалуются, что он не выдерживает нагрузки, если 100 серверов одновременно загружаются. Ну, в таком духе. Короче, не очень понятно, в чем с ним проблема, но что-то есть. В нем, на самом деле, есть еще концептуальная проблема, сам ZooKeeper внутри надежный, но, если ты используешь его для strong consistency, тебе нужно чтобы клиент был правильно написан. У них клиент очень примитивный, он не рассчитан даже на просто отключение от сервера, грубо говоря. Обработку ошибок нужно самому делать. Если хочется strong consistency, там, вообще говоря, очень нетривиально написать хорошего клиента.
У нас была очень простая задача, мы хотели, чтобы кусочек стейта, вот эти 8 Мб, был равномерно реплицирован на все ноды in memory. Чтобы in memory состояние этого стейта на всех нодах было одинаковое в узлах, ну, не ZooKeeper, а нашего приложения. Мы складывали стейт ZooKeeper, ну, и наивно вычитывали его оттуда. Получалось очень сложно и там куча мест, например, для рейс кондишенов такого плана, что у него древовидная структура, и ты не можешь взять и считать кусок дерева консистентный. Ты можешь считать вершину и список детей, потом по очереди начать читать детей. Естественно, пока ты читаешь детей, состав этих детей может измениться, какие-то ноды могут удалиться. Короче, очень tricky сделать клиента так, чтобы получить консистентное состояние, которое, в принципе, внутри ZooKeeper существует. Сам он внутри это все видит консистентно. Чтобы это состояние консистентно считать на клиента.
У меня как-то была идея написать такого клиента, чтобы он это умел делать, но, что-то я не дописал и, в итоге у меня появилась гипотеза, что нужно ZooKeeper чем-то заменить типа Raft’а . Ну, короче, единственное понимание, которое я из всего этого вынес, что в распределенной системе клиенты являются точно такой же полноценной частью распределенной системы. Подход сделать тупого, плоского клиента, он не работает.
Есть такая штука, как, например, etcd — это реализация Raft алгоритма, который тоже strong consistency, strong consensus, на Go , по-моему. Они сделали довольно… они ее реализовали и я даже уверен, что реализовали хорошо, но они, опять же, зафейлили эту ситуацию. Они сделали клиентом обычный curl. По HTTP ты туда ходишь и что-то там качаешь, естественно, ты очень легко можешь пропустить любые изменения в состоянии, если ты недостаточно часто там полишь или мониторишь это состояние. У них там лонг полинг, в общем, все очень печально. И в итоге, такое понимание я вынес, но потом еще появилось чуть позже другое понимание, что, на самом деле, strong consistency не так уж и нужен. Например, для вещей типа service discovery лучше подходит AP solutions, когда у тебя availability вместо consistency, потому что, на самом деле, скорее нужно AP, чем CP.
Если тебе нужно узнать, какие сервисы существуют, лучше… ну, это снимает ту проблему, когда там ZooKeeper ложится под… как бы, ZooKeeper становится single point of failure, если ты его зафлудил запросами, у тебя вся система лежит, потому что никто не может получить список сервисов. Лучше, если часть клиентов увидит стейл какой-то, список сервисов на 5-10 секунд белее стейл, но зато они его стабильно будут видеть без вот таких вот проблем. Это скорее то, что чаще нужно в реальных ситуациях. Плюс, как бы strong consistency для service discovery нереально сделать, потому что реакция на пропадание сервиса не мгновенная, а опять же с каким-то heartbit или еще чем-то. Там все равно не мгновенная реакция, поэтому разница между CP и AP непринципиальна. Есть ситуации, где это нужно, типа distributed locks, где реально нужно, чтобы только один процесс захватил lock. Там да, ZooKeeper подойдет, но опять же, его нужно правильно готовить.
В: Я совершенно согласен про service discovery. Есть такая штука — Serf, ее автор сейчас делает Consul . Кстати, ты не смотрел на Consul, etcd, всякие такие штуки?
Н: Ну, про etcd я рассказал уже.
В: Я просто отключался.
Н: Да, да. Нет, Consul… Ну, я, как бы, да, в курсе примерно, там Serf, etcd, CoreOS, так, очень поверхностно.
В: Вот, собственно, судя по тому, как внутри сделан Consul, service discovery таки действительно гораздо проще делать на AP. И у меня тоже есть похожий опыт и я согласен с точкой зрения, что для discovery гораздо лучше AP. В этом смысле я с тобой полностью согласен, тут даже обсуждать ничего особо не хочется.
А: У нас выпуск, на самом деле, плавненько-плавненько подходит к концу. Может быть, Никит, ты хочешь что-нибудь пожелать нашим слушателям? Может, что-то попиарить из своих проектов?
Н: Ну, у меня есть блог tonsky.me ….
А: Ну, это понятно, это все будет в show notes, это можешь даже не перечислять.
Н: Там есть интересные концепции на тему, ну, DataScript, на тему интерфейса Git . Как можно переделать Git, чтобы им было приятно пользоваться. С картинками.
В: С анимированными картинками!
Н: Да.
В: Тебе, на самом деле, нужно было сделать пост про Git в таком же гипно стиле, как ты в свое время рекламировал курс по Clojure.
Н: Да, можно было. Но это не самый эффективный способ донесения информации, но веселый.
В: Понимаешь, тот же салат с картошкой собрал 7 тысяч долларов на Kickstarter. Может быть, твой новый классный интерфейс к Git хорошо поданный собрал бы больше на Kickstarter, и ты смог бы заняться этим в full time, например.
Н: У меня, на самом деле, есть идея попробовать это сделать. Серьезно, как бы.
А: Для тех, кто в танке, что там про салат с картошкой на Kickstarter?
В: Человек собрался сделать салат с картошкой и попросил «хочу 30 баксов, я с вами поделюсь салатом с картошкой». Ему в итоге столько начали донатить, что они в итоге уже делают пикник. Они хотят снять какое-то больше помещение и накормить салатом с картошкой всех, кто задонатил им около 7 тысяч долларов на Kickstarter. Как-то так. Можно в шоу нотес ссылку прилепить.
А: Да, если ты ее найдешь, то кидай в чатик. А слышали эту эпичную историю про закрытие Code Spaces? Что их хакнули и удалили все ноды в Amazon или где там они хостились, по-моему, в Amazon. И то, что чувакам пришлось уйти из бизнеса, потому что их хакнули.
Н: Да, весело было.
А: Ну, я думаю, что чувакам из Code Spaces и их пользователям было не так весело. Вообще, да, вот забавная история. Это все к поинту о том, почему, может быть, не стоит все держать в облаках ?
Н: Ну, я вот в какой-то момент подписался на несколько новых, стильных, модных стартапов типа чатиков, Slack, еще чего-то, какой-то там менеджер задач. И мне, вот, сейчас время от времени приходят письма «ну, мы закрываемся», потом другой сервис — «ну, мы закрываемся», в таком духе.
А: Про стартапы ведь известно, что там типа 90% не удается, а 10% более-менее живут. Так что, в этом смысле нормально.
В: Просто сейчас стало модно, потихонечку, слава Богу, входят в моду всякие проекты… Вот, мы в прошлом выпуске обсуждали refuge.io и в последнее время становится модно облачным сервисам, которые обслуживают особенно B2B сектор, сами данные отдавать, по крайне мере, их реплику, хозяину данных. Полной потери данных может не быть в такой ситуации.
Н: Нет, там же эта проблема, она же не связана с тем, что облака это или не облака. Насколько я понимаю, проблема с тем, что они пароль профакапили и бэкапов у них не было. То есть, они были, но их то ли их стер чувак, то ли что. Какая-то такая проблема была.
А: Я так понял, что у них все в Amazon-е, поэтому он все стер и с S3, где были бэкапы, и вообще.
Н: Да, типа того.
А: Ладно, я вижу, говорить уже особо не о чем, так что, да, я потихоньку завершу выпуск.
Подписывайтесь, лайкайте, если вы нашли этот выпуск через Twitter, то ретвитьте, если нашли через Google+, то нажмите кнопочку share this. Не путайте с кнопочкой +1, потому что +1 — это не то же самое, что share this.
В: Интуитивный Google!
А: Да. Я думаю, что у этого выпуска или двух выпусков, я не знаю, мы их разобьем, наверное, будет новая обложка. Обязательно напишите, понравилась она вам или не понравилась. Вот нам, например, пишут, что она украдена у Cisco. Ну, действительно, что-то общее есть.
Не стесняйтесь предлагать вопросы для выпусков, вот, общие, как мы обсудили, например, или вопросы для конкретных ведущих. Я анонсирую в Twitter по совету Валеры. Валер, ты был прав, да. Анонсирую, кто у нас будет в гостях и можно там, в ответ на твит задавать вопросы гостям.
Не стесняйтесь, предлагайте себя в качестве гостя, так тоже можно. Притом, необязательно быть каким-то супер крутым функциональщиком. Мне, например, будет интересно поговорить с кем-нибудь, кто на .NET фигачит, вот, лично мне. Я узнал, что у чуваков там есть, как он там, ну короче есть JIT-компиляция, а есть наоборот, AOT-компиляция. У чуваков под .NET есть прям совсем не JIT.
В: Это в основном используется для того, чтобы это работало на всяких анально огороженных платформах, вроде iOS, потому что там JIT запрещен и, в общем-то, поделом. И, чтобы оно там работало, оно компилируется, как может.
А: Поинт в том, что я очень мало чего знаю про .NET и мне было бы интересно. Намного важнее иметь правильную гарнитуру и говорить нормально, не заикаясь, без слов-паразитов. Как-то так. И, наверно, у нас все. Спасибо, что слушали, и до следующего выпуска. Пока.
В: Пока.
Н: Пока.
Дополнение: EaxCast S02E07 — интервью с Максимом Сохацким об Erlang, проекте Erlang on Xen и веб-фреймворке N2O