`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

Фастов + Идея + FreeBSD + Erlang = 19 миллиардов

+1212
голосов

На фоне непрекращающихся и нарастающих успехов нашей экономики $19 миллиардов, щедро «отсыпанные» за Whatsapp, кажутся форменным издевательством и полным крахом «обнадёживающих» картин «национального спасения за счёт доходов от крупной приватизации», с которыми у нас принято носитися дурнями з писаною торбою (я не ошибся, не «як дурнi», а именно как написано).

Особенно же издевательски цифра выглядит в сочетании с организационной и исторической спецификой Whatsapp – в компании чуть больше полусотни человек персонала (львиная доля – сервис-инженеры), а основатель компании Ян Кум – наш соотечественник и многим из нас практически земляк, родившийся в Киеве и выросший в Фастове, в трудном подростковом шестнадцатилетнем возрасте в не менее трудное время популярности «кравчучек» (1992 год) перевезенный родителями в США. «Американская мечта» как она есть. Впрочем, не будем о грустном, и без него невесело.

Бизнес-версий о сделке я строить не буду, это сделали без меня, да и совершенно бессмысленны сейчас любые попытки догадок как Facebook утилизирует приобретение, как и с какими целями интегрирует обе масштабные системы. По-моему, это вообще гадание на кофейной гуще, потому что и в самой Facebook могут пока точно не знать, что же «такого» сделать с Whatsapp, чтобы в итоге получилось «нечто». Достаточно того, что все желавшие приобрести Whatsapp очевидно понимали – это «нечто» непременно может получиться в итоге. И не стоит удивляться если на пути к этому «нечто» будут многочисленные пробы и ошибки, и даже не надо удивляться, если «нечто» вообще не получится. Такие игры потому что, и они без всяких гарантий.

Не буду увлекаться и реверансами Яну Куму за гениальность ключевой идеи Whatsapp. Просто скажу – она безукоризненно гениальна. Что в с своей простоте – ну как никто до него не видел возможности заменить унылый ввод имени пользователя и пароля (ещё и с предупреждениями о надёжности последнего) тем, что всегда есть в любом телефоне (даже не обязательно смартфоне) – номером телефона и IMEI, что в естественной интеграции разных до неё миров (сугубо «телефонного» и сугубо «messengers») – ведь номера телефонов в записной книжке пользователя – это готовая нужная ему контактная база. Великолепная и гениальная идея. И эту гениальность оценили пользователи. Точка.

И не буду пытаться строить ненужные конспиративные теории относительно модели безопасности приватности пользовательских данных в Whatsapp и возможных «расширенных» использований её для всяких потенциальных big data «вкусностей». Просто констатирую её – в Whatsapp история сообщений и сами сообщения не хранятся нигде кроме телефонов пользователей, о которых сервису ничего не известно (пол, возраст, реальные имена, адреса etc), каналы телефон-сервис дополнительно защищённые (SSL, инкапсулированный в собственную «защиту» GSM или всяких там *G). Поговаривают, что необходимость в такой модели Ян Кум впитал на исторической родине, возможно, это городская легенда, но в таком варианте я лично не сильно сомневаюсь.

(В дальнейшем тексте не буду приводить ссылок, их нужно так много, что в них вообще нет нужды, а на легко находящееся с помощью любой поисковой машины и вовсе нет смысла ссылаться явно)

Я хочу о другом поговорить. Об инфраструктуре Whatsapp, о «железе», программных системах и ухищрениях инженеров, которые в сумме реализуют сервис. Потому как это и есть материальная составляющая Whatsapp, её «заводы, мосты и пароходы».

Насколько можно восстановить по разрозненным данным, аппаратная основа Whatsapp – порядка 350-400 (или даже 600-700, в зависимости от того, что понимается под «core» в упомянутых самим Кумом «8000 cores») нод единой для Whatsapp конфигурации – двухпроцессорные машины c CPU от Intel (семейства Wetrmere, шестиядерные), 100 GB оперативной памяти, SSD-накопитель, две сетевые карты – одна «смотрит портом» в публичную сеть, вторая – в приватную, в бэкенд сервиса.

Ну, вполне логичная хорошая «машина как машина» для своих задач, ничего удивительного для 2013-2014 годов. И ещё послужит прилично. Разве что забавно одно – механические накопители (HDD) в описании конфигурации вообще не упоминаются. В сочетании с приличным объёмом оперативной памяти каждой ноды и с realtime-характером сервиса в целом, факт неупоминания HDD позволяет утверждать, что реализации всех программных систем Whatsapp основаны на «in memory» модели. А вот это уже интересно. Стало быть, в 2013-2014 году действительно большая «in memory» система может работать весьма надёжно, Whatsapp никогда не отличался особыми «взбрыками» в работе и на фоне прочих больших сервисов всегда выглядел достойно. И это уже нечто полезное, например, для системных архитекторов – при правильном проектировании можно не бояться 24/7/365 in-memory архитектур, они работают.

Теперь взглянем на системное ПО, обеспечивающее работу Whatsapp. Вот здесь начинается интересное.

Во-первых, выбор ОС. Он как бы не нов для тех, кто всерьёз интересуется построением высокодоступных и надёжных систем, но может несколько удивить всех прочих – несмотря на все достоинства всех ОС семейства Linux, несмотря на постоянные заявления всяких альтернативно одарённых о «перманентном умирании» *BSD систем – Whatsapp реализован на основе ОС FreeBSD (даже известна версия – 8.3). И не просто «реализован». Сама история Whatsapp – целая отдельная замечательная история раскрытия реальных возможностей этой ОС.

Во-вторых, - выбор единой технологической основы (или платформы) для реализации сервиса. Он тоже известен – платформа Erlang.
Пока остановимся, и взглянем на цепочку эволюции реальных возможностей этой явно удачной технологической пары (я собрал их твиттера и блогов Whatsapp):

Загрузка сервиса на начальном этапе довольно непростого завоевания популярности:
200 одновременных TCP сессий на одну ноду

23 сентября 2011 года, одна нода сервиса:
1016313 (больше миллиона одновременных TCP сессий)

6 января 2012 года, одна нода сервиса:
2277845 (больше двух миллионов одновременных сессий)

31 декабря 2012 года, суммарная оценка предновогодней нагрузки:
18 миллиардов обработанных сообщений за день

Достойные показатели, и сказать нечего, и оспаривать нет смысла. И они реально нужны для решения двух задач – минимизации расходов на масштабирование системы (эту задачу в Whatsapp очевидно решали – сверхэффективная монетизация не была главной целью сервиса, и всесторонним изучением поведения с тонкими настройками ОС и программных подсистем нужно было «вытягивать максимально возможное») и обеспечения бесперебойного и качественного обслуживания 450+ миллионов пользователей сервиса при росте пользовательской базы со скоростью миллион человек в день.

Теперь вернёмся к подробностям.

Стек Whatsapp – FreeBSD 8.3 + Erlang OTP R14B03 + Yaws (реализованный на Erlang HTTP-сервер для динамического контента) + Lighttpd (HTTP-сервер для статического контента). По аналогии с общеупотребительной аббревиатурой LAMP (Linux + Apache + MySQL + PHP/Perl/Python), получаем FEYL, который хоть и похож по звучанию на «fail», но вот всем бы хорошим людям – да такие «фейлы».

Совершенно «нестандартный» стек. Причём о нечто подобное в своё время «сломали зубы» в… Facebook. Именно с поддержкой Erlang-реализации протокола своего чата в Facebook в своё время не справились из-за невозможности отыскать достаточное количество квалифицированных разработчиков. В Whatsapp начали с открытой Erlang-реализации протокола XMPP и сервера Ejabberd, но довольно быстро были вынуждены полностью переделать что сервер, что и вовсе сам протокол – он довольно давно у них собственный. После чего ещё и серьёзно модифицировали виртуальную машину Erlang для достижения требуемых показателей. Вот деталька с отказом от XMPP и переходом на собственный протокол – она ещё одна заметочка в копилку знаний смелых и умных системных архитекторов – оказывается, протоколы и прочие «условно стандартные» нюансы всего лишь инструменты, и если задачи требуют радикального изменения инструментов, совершенно незачем цепляться за «стандартность» до последнего (об очевидной ответственности за уровень и качество проектных решений молчу). Иначе за $19 миллиардов точно не купит никто.

Следует заметить, что от традиционного LAMP в технологическом стеке Whatsapp кое-что осталось. Как это ни странно для специфического и «неправильного» FEYL, последняя буква P в LAMP. И за ней стоит… многострадальный PHP, неиссякаемый источник язвительных шуток «шибко вумных программистов». В общем, доподлинно известно, что где-то там в Whatsapp PHP используется, где его рационально использовать, но точно уж не в realtime-части сервиса. Это не основная часть стека, посему места для него в аббревиатуре FEYL я и не предусмотрел. Но всё правильно – если инструмент позволяет решить задачу, то незачем его не использовать по каким-то другим причинам.

Теперь несколько слов о методике «тюнинга» FreeBSD, принятой в Whatsapp. Она строится на циклическом принципе – «пробуй-измеряй-меняй настройки». И качество измерений в ней – один из ключевых моментов. Реализованная в FreeBSD подсистема мониторинга ядра ОС, изначально разработанная в Sun, dtrace, для задач мониторинга и изучения поведения используется только в цикле разработки и отладки кода. На «боевых» нодах сервиса она не используется. Для мониторинга «боевых» нод применяется собственная подсистема (wsar), причём с одним очень забавным нюансом характера использования – на начальных этапах развития сервиса период между «измерениями характеристик» нод был равен одной минуте, но по мере роста нагрузки и уровня утилизации имеющихся вычислительных мощностей его уменьшали и довели до одной секунды – большее временное разрешение просто неинформативно для оценки состояния системы такого масштаба. На основе оценок поведения системы методом проб и ошибок подбирались и настройки, причём по словам самих инженеров Whatsapp, «экстремальная оптимизация настроек – это тёмная магия, доступная только гномам и инженерам». 

Вот такая примерно картинка получается.

Откланиваюсь

+1212
голосов

Напечатать Отправить другу

Читайте также

Объясните для неспециалиста чем отличается FreeBSD от Линукса?

Добрый день.
Ответ на Ваш вопрос - http://www.freebsd.org/doc/en/articles/explaining-bsd/comparing-bsd-and-...
Это точка зрения FreeBSD, но думаю ключевые моменты будут полезны

Большое спасибо! Когда нибудь почитаю, но памятую как вы мне заумно объясняли что epub (в итоги оказалось что это просто zip-архив) рискну предположить что существует намного более простое объяснение ;)

Простите, но Вы вероятно меня с кем-то путаете.
Я никогда не кому не объяснял вопросы, связанные с epub.
Тем более, тут уже разложили все по косточкам.
Если говорить о практике - то мне лично не хватает в FreeBSD одного - родной JVM. Без нее представить себе решение очень широкого круга серверных задач (в приемлемое время) очень сложно.

1) Извините и правда спутал :(
2) Про jvm поподробней пожалуйста. jvm от Оракла тормозит на FreeBSD? Или что с ней не так?

Не так в том смысле, что ее просто НЕТ для платформы.
Т.е. оф. платформы Java:

Linux
Mac OS X
Solaris
Windows

Да, я могу запустить во FreeBSD через эмуляцию бинарной совместимости с Linux.
И больше того - оно даже будет работать.
Пусть даже не вылезут артефакты по линии этой прослойки, но что делать с ПО, которое работает поверх JVM ?

Жить это будет до первой проблемы, которая потребует обращения в support.
Меня знаете куда пошлет support того-же WebLogic'а, если базовая ОС будет выходит за круг рекомендуемых ?

И так по всему ПО.
Та же Cassandra. И так ней, как с невестой, обходиться приходиться, а добавить на свою голову еще цикл проблем...

За что Лэри Элисон так не взлюбил FreeBSD? А во времена Sun была jvm для FreeBSD или нет?
ЗЫ. Насколько я знаю Mac OS X на FreeBSD основана. В чем тогда принципиальная проблема?

Это просто совершенно разное, основанное на, если хотите, "модели" оригинальной Unix и спецификациях POSIX.

Первое ключевое отличие - в процессе разработки.
Он очень разный.
Для Linux - "базар", для FreeBSD - "собор" (подробнее вы сами найдёте, мне стыдно писать то, что написано до меня миллион раз).

Второе - в архитектурных понятиях.
Linux - это ядро ОС. На основе него строятся семейства дистрибутивов системы.
FreeBSD - это ОС. Ядро FreeBSD - всего лишь часть ОС. За пределами этой ОС ядро FreeBSD фактически не существует.

Третье и т.д. - уже находятся на уровне реализации, потому их неперечислимое множество.

Как-то так.

Большое спасибо! Из того что вы написали есть вопросы.
1) Хоть у них разные исходники но разработаны они на одинаковых принципах "модели" оригинальной Unix и спецификациях POSIX. Правильно?
2) Дистрибутивы Линукса собирает любой желающий, а он один FreeBSD по каким-то причинам (Почему? Лицензионное соглашение запрещает?)
3) Прикладной уровень у них одинаковый - LAMP и иже с ним есть и там и там. Правильно?

1. Абсолютно разные реализации. В составе FreeBSD были какое-то время системообразующие компоненты, распространяющиеся на основе лицензий, отличных от BSD, но их количество сокращается до практически нуля.

2. Лицензионное соглашение BSD является одним из самых либеральных - оно требует от использующего код фактически только упоминания автора. Почему так? А почему мы можем разрабатывать какой-то редуктор, например, пользуясь законами Ньютона, и Ньютон нам не завещает открыть детали и нюансы проекта нашего редуктора всему миру? Это классическая модель распространения знаний в академической науке. В сообществе BSD считают, что код - это знания, в сообществе GNU - что чертежи инструмента. Я лично не против ни первого, ни второго. Мир большой, в нём всему есть место.

3. LAMP - всего лишь аббревиатура для набора программ. Без Linux от LAMP останется AMP (апач + мискль + похапе или что там на "п"). AMP вы можете использовать в любой ОС. Хоть в Windows 95, никто не запрещает.

Все POSIX-совместимые программы работают после перекомпиляции в любой POSIX-совместимой ОС, в этом смысл POSIX. Если программа Linux-зависима, FreeBSD даёт возможность её собирать и запускать с помощью Linux-эмулятора.

Примерно так.

Чем объясняется ваше особое отношение к FreeBSD? Ностальгией? Или у нее действительно есть принципиальные преимущества перед Линукс?

Я не знаю что вы имеете в виду под моим "особым отношением к FreeBSD"
но мне льстит, конечно, что вы подозреваете меня в выборе платформы для сервиса, который куплен за $19 миллиардов.
это приятно.
спасибо.
даже хоть бы я и не имел к этому ни малейшего отношения.

Не прибедняйтесь ;)
1) Везде где хоть что-то связано с Линуксом в ВСЕГДА возникает упоминание FreeBSD. Мне по-этому и стало интересно узнать чем же они отличаются. Из того что услышал - ничем.
2) Второй мозоль MIPS.
Вот такие вот пироги.

Я не прибеднялся, а чётко отвечал на ваши вопросы.

По сути ответов у вас есть претензии?

Чтобы вы не напрягались с формулировками (почему мозоли MIPS, почему то-сё), попытаюсь объяснить, несколько расширяя ваш вопрос, и кратко:

1. выбор всегда лучше чем его отсутствие,
2. мир большой,
3. в большом мире всегда есть место для всего,
4. место чему-то в мире определяется не тем, что указал великий кормчий, и даже не возможностями чего-то, а сугубо творческими возможностями и знаниями того, кто это что-то использует
5. я пытаюсь сделать людям интересно, и интересно - это не соседний ларёк, а мир в его разнообразии

если вам ещё что-то не совсем понятно в перечисленном, спрашивайте, не стесняйтесь.

только прошу, уберегите меня от ваших домыслов и спрашивайте по существу.

В моем случае то что bsd не отличается от линукса это даже лучше. Не будет страха что это что-то неизведанное-непонятное.
Я вплотную столкнулся с Линуксом достаточно недавно, когда купил Raspberry Pi. Это был праздник какой-то. Просто у них на сайте вначале был достаточно узкий круг дистрибутивов, а так как меня интересовал mono, то выбора вообще не было. Только soft-float Debian. Возможно сейчас уже есть и bsd.
Кстати у вас насколько я помню были большие планы по embeded. Или вы уже перегорели?

P.S. Со всем остальным полностью согласен.

Спасибо, что мы поняли друг друга.

Embedded непременно продлится, непременно.
Было очень нервное время, были проблемы и "не до того".
Все успокоятся, я успокоюсь, всё будет.
Оно никуда не делось, мне просто лень фотографировать мой рабочий стол, поверьте.
Всему своё время.

зы

я тоже пользователь распберри :)
если что.

я тоже пользователь распберри :)

Я чувствовал это ;)

я бы вот что хотел заметить из своих наблюдений (в прошлом админ с 15-летним стажем, сейчас ушел в руководящие органы). Это все мое личное мнение. Linux очень сильно раскручен благодаря интернету: школьники, молодеж и прочие начинающие IT специалисты выбирают его де-факто, тк он у всех на слуху. Ненадо забывать, что развитие Linux сосредоточено в руках крупнейших коммерческих организаций, в то время как FreeBSD - Opensource проект, за которым такой поддержки не наблюдается. Это наиболее важное отличие. С технической стороны, тем не менее, проекты сложно выделить друг перед другом, тк что Линукс что BSD - это платформы для запуска остального ПО, которое везде одинаково. По мелочем - у всех систем свой набор проблем. Вот что хотелось бы отметить мне, как человеку прособеседовывшему более тысячи админов. FreeBSD специалисты в большинстве своем оказались намного более компетентны (может такая картина, потому что их приходило 1:20). Они глубже знают как это все работает - начиная от сборки и портирования ПО (работа с портами не проходит даром) и заканчивая внутренней архитектурой ядра. В то время как Linux-админы которые приходили, ни основ autotools ни cmake ни dtrace-подобные вещи и трассировщики просто не знали. Более того, многие компании решают свои проблемы на Линукс просто переходом с одного дистрибутива на другой. И этот уровень подкованности Linux-спецов лежит в том что система более доступная. Да, на Линуксе немало специалистов но когда я смотрю свою статистику по людям - разница колоссальная. Поэтому, не смотря на то что у нас сейчас работает все на Linux, я с большим удовольствием звал на собеседование опытного FreeBSD-шника: FreeBSD заставляет или рыть глубоко, или не использовать ее.

PS: автору статьи на заметку. WhatsApp не в меньшей мере использовали pmc на FreeBSD, о чем они очень хорошо расписали
в своем докладе в 2008 году. Dtrace играл не главную роль.

1:20. Вы сами ответили на свой вопрос. Если я завтра начну ковыряться в BSD, то я НЕ стану автоматом спецом. Я просто стану слабым BSD-шником + слабым линуксоидом (каким сейчас и являюсь).

Дело не в "завтра", а в том, насколько глубоко вы можете отдаваться делу. Многие бросают BSD из-за того что в ней чуть более сложно что-то сделать и ее обслуживание выходит чуть дороже - понять можно. Но и побочный эффект от сложности может быть положительный. Если планируете быть слабым Linux/BSD-шником и этим зарабатываете на жизнь, лучше поискать альтернативу. Linux спецы с глубокими знаниями разумеется имеются, но в моем случае то, что знали приходящие FreeBSD админы, в случае с "Linux"-oriented человеком, эти же знания наблюдались обычно у тех кто приходил на разработчика, а не админа.

По-этому я и написал 1:20. Их мало, но они энтузиасты, а среди линуксоидов есть даже школьники - http://www.youtube.com/channel/UCIPbcTTXxYrCHjWaqkXLCOg

Совершенно необязательно.
Я - админ с 10-летним стажем. Приходилось работать и с виндой, и с FreeBSD, и с Linux.
Знаете что я вам скажу из личного отпыта:
Винду я могу мехом внутрь вывернуть. Сделать из неё могучий роутер тоже можно (но не нужно), можно и корпоративную инфраструктуру поднять, можно и MSSQL отказоустойчивый сделать, так чтоб он не падал с каждым чихом.
С Linux приходиться работать, во всех его ипостасях. И как Jabber сервер, и LAMP, и астериск, и KVM, и много чего другого. Но меня от него тошнит иногда (почти всегда).
Но когда передо мной FreeBSD - эта система открыта как голая-застенчивая девушка. Делай что хочешь. Мне просто приятно с ней работать. Она мне просто понятна, я её люблю.

как голая-застенчивая девушка
Только по взаимному согласию пожалуйста ;)

я читал доклад, спасибо, но слишком в дебри заводить людей, далёких от, не хотелось.
dtrace же упомянул, потому что это знаковая подсистема, и мы все многим обязаны Sun, о которой уже никто и не вспоминает :(
Хотелось отдать дань, так сказать.
Это же не техническая статья, всё-таки.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT