Архитектура WhatsApp, которую Facebook купил за $19 миллиардов

в 8:25, , рубрики: Erlang/OTP, Facebook, freebsd, WhatsApp, Анализ и проектирование систем, Разработка систем связи

В очередной раз хочу предложить свой перевод статьи, на этот раз автор Тодд Хофф, и его статья посвященна архитектуре WhatsApp на момент его покупки Facebook.

Ремарка: в начале статьи содержится рассуждение автора оригинала о том, зачем Facebook купил WhatsApp за баснословные 19 миллиардов. Если это вам не интересно — просто пролистайте, описание архитектуры будет ниже.

Рик Рид в его предстоящем мартовском докладе, озаглавленном "Миллиард с большой 'М': Следующий уровень масштабирования в WhatsApp" раскрывает сногсшибательную статистику WhatsApp:

Что имеет сотни узлов, тысячи ядер, сотни терабайт RAM и надеется обслужить миллиарды смартфонов, которые вскоре станут реальностью по всему миру? Основанная на Erlang и FreeBSD архитектура WhatsApp. Мы столкнулись со многими трудностями при удовлетворении постоянно растущего спроса на наш сервис обмена сообщениями, но мы продолжаем расширять нашу систему с точки зрения размера (> 8000 ядер) и с точки зрения скорости (>70М сообщений Erlang в секунду).

Но поскольку у нас ещё нет этого доклада, давайте посмотрим на доклад, который Рик Рид сделал два года назад: "Масштабирование до миллионов одновременных соединений".

Имея опыт разработки высокопроизводительной шины сообщений на C++ в Yahoo, Рик Рид не новичок в мире масштабируемых архитектур. Основатели WhatsApp это также бывшие сотрудники Yahoo с немаленьким опытом в масштабировании систем. Так что WhatsApp работает за счет их навыков масштабирования. А поскольку их Большая Дерзкая цель в том, чтобы быть на каждом смартфоне в мире, которых в течение нескольких лет будет около 5 миллиардов, им потребуется весь этот опыт.

Прежде чем мы перейдём к фактам, давайте отвлечёмся на эту поразительную загадку: как WhatsApp вообще мог быть оценён Facebook в $19 миллиардов?

Если вы спросите меня как программиста, стоит ли WhatsApp таких денег, то я отвечу, что, разумеется, нет! Это просто отправка данных по сети! Ну в самом деле. Правда, я из тех, кто считает, что блог-платформы не нужны, потому что нет ничего сложного в том, чтобы удалённо подключиться к серверу, открыть index.html с помощью vi и написать ваш пост в HTML. Мне потребовалось время, чтобы понять, что разработка — это не написание тупого кода, это способ сделать так, чтобы все те пользователи полюбили ваш продукт, что самое сложное. Любовь не купишь.

Так что же делает WhatsApp таким ценным? Технология? Не обращайте внимания на тех, кто говорит, что за неделю сможет написать WhatsApp на PHP. Это просто неправда. Как мы увидим, это весьма крутые технологии. Но, разумеется, у Facebook достаточно ресурсов, чтобы разработать WhatsApp, если бы они захотели.

Давайте посмотрим на особенности. Мы все знаем, что WhatsApp это продукт без уловок (нет рекламы, игр, уловок) с преданными пользователями по всему миру. Он предлагает бесплатные сообщения в суровом мире, где счета за SMS могут быть ужасными. Как приезжего американца, меня очень удивило то, как много настоящих людей используют WhatsApp чтобы действительно оставаться на связи со своей семьёй и друзьями. Так что когда вы берете WhatsApp, то вероятнее всего, что люди, которых вы знаете, уже там, так как у всех есть телефон, который устраняет проблему пустой социальной сети. Он агрессивно-кросс-платформенный, так что все, кого вы знаете, может использовать его и он просто будет работать. Фраза он "просто работает" часто используется. Он имеет все возможности (можно поделиться местоположением, звуком, видео, картинки, push-to-talk, голосовые сообщения и фото, оповещение о доставке, групповые чаты, отправка сообщений через WiFi, и всё это может быть сделано независимо от того, в сети адресат или нет). Он также поддерживает отображение национальных систем письменности. А использование номера мобильного телефона как идентификатора и контактов как социального графа дьявольски просто. Нет подтверждения по электронной почте, имени пользователя и пароля, номер кредитной карты не требуется. Он просто работает.

Это всё круто, но оно не стоит $19 миллиардов. Другие продукты могут посоревноваться с ним в плане возможностей.

Возможная причина в том, что Google хотел купить его. Это угроза. Это 99 центов за пользователя. Facebook просто в отчаянии. Это за вашу телефонную книгу. За метаданные (даже учитывая то, что WhatsApp их не хранит).

Это за 450 миллионов активных пользователей с ростом на миллион каждый день и потенциалом в миллиард пользователей. Facebook'у нужен WhatsApp для получения следующего миллиарда пользователей. Но если это и так, то это только часть. И цена в примерно $40 за пользователя не выглядит неадекватной, особенно при оплате акциями. Facebook купил Instagram по цене $30 за пользователя. Пользователь Twitter стоит $110.

Бенедикт Эванс заявляет, что рынок мобильной связи составляет более триллиона долларов, а WhatsApp подрывает часть этой индустрии, относящуюся к SMS, которая приносит доход в $100 миллиардов, отправляя 18 миллиардов сообщений в день, в то время как глобально отправляется только 20 миллиардов SMS. С фундаментальным переходом от персональных компьютеров к почти универсальным смартфонам, размер возможностей равен значительно большему целевому рынку, чем тот, который привычен Facebook.

Но Facebook обещал, что не будет ни рекламы, ни объединения сервисов, так в чем выгода?

Имеет место интересное развитие бизнеса через использование мобильных технологий. WhatsApp используется для создания групповых обсуждений командами проектов, а инвесторы обсуждают ход сделок через WhatsApp.

Instagram используется в Кувейте для торговли овцами.

WeChat, конкурент WhatsApp, в январе запустил сервис найма такси, за первый месяц был нанят 21 миллион машин.

С будущим электронной коммерции, направляемой мобильными приложениями для отправки сообщений, стоит ли сыграть на этом поле?

Не только бизнес пользуется WhatsApp для задачи, которые когда-то решались настольными или веб-приложениями. Полиция Испании использует WhatsApp для поимки преступников, итальянцы организуют баскетбольные команды с его помощью.

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

Таким образом, мгновенные сообщения это угроза для Google и Facebook. Настольные компьютеры мертвы. Веб умирает. Мгновенные сообщения + мобильные технологии это экосистема, способная их заменить. Мгновенные сообщения стали центром взаимодействия в мобильных технологиях, а не поиск, изменяя то, поиск и природу того, какие приложения завоюют будущее. Мы не просто предваряем PageRank, мы предваряем веб.

Facebook должен попасть на этот рынок, или станет бесполезным.

С переходом в мобайл, мы видеим депортализаию Facebook. Его настольный интерфейс это портал, предоставляющий доступ ко всем возможностям бекенда. Он большой, запутанный и скрипучий. Да кому вообще нравится интерфейс Facebook?

Когда Facebook пришел на мобильные устройства, они попробовали портальный подход и он не сработал. Так что они перешли к стратегии маленьких, более сфокусированных приложений для одной задачи. Mobile first! На маленьком экране можно сделать не так много. На мобильнике проще найти отдельное приложение, чем меню, закопанное глубоко в недра запутанного портального приложения.

Но Facebook идёт на шаг впереди. Они не только разрабатывают отдельные приложения для конкретных задач, они предоставляют несколько конкурирующих приложений, предоставляющих схожую функциональность, и эти приложения не обязательно имеют общий бекенд. Мы видим это на примере WhatsApp и Messenger, а Instagram конкурирует с фотографиями на Facebook. Paper это альтернативный интерфейс Facebook, который предоставляет ограниченную функциональность, но то, что он делает, он делает хорошо.

Здесь может быть применим закон Конвея. Идея в том, что "организации, проектирующие системы… обычно порождают архитектуру, копирующую коммуникационную структуру этих организаций". С монолитной инфраструктурой бекенда мы получим портальный дизайн, похожий на Борга. Переход к мобильным технологиям освобождает организации от такого мышления. Если могут быть разработаны приложения, использующие только часть инфраструктуры Facebook, тогда могут быть разработаны приложения, совсем не использующие инфраструктуру Facebook. А если они не используют инфраструктуру Facebook, то они могут быть разработаны не в Facebook. Что же тогда Facebook?

CEO Facebook Марк Цукерберг имеет свою точку зрения, озвученную на конференции Mobile World Congress, заключающуюся в том, что поглощение WhatsApp тесно связано с Internet.org:

Идея в том, чтобы разработать набор базовых бесплатных интернет сервисов — "911 интернета". Это может быть социальная сеть, как Facebook, мессенджер, может быть поиск, и другие вещи, вроде погоды. Набор этих бесплатных сервисов будет работать как своего рода наркотик — пользователи, которые могут себе позволить услуги передачи данных и телефоны просто не видят смысла в том, чтобы платить за эти сервисы. Это даст им некоторый контекст, который покажет им, почему сервисы важны и это подтолкнет их к оплате других подобных сервисов — есть такая надежда.

Это долгая игра, но она содержит достаточно ценностей, чтобы имело смысл в неё играть.

Пришли ли мы согласию? Не думаю. Это поразительное количество долларов, краткосрочная выгода от которых неочевидна, так что объяснение как долгосрочная игра имеет некоторый смысл. Мы по-прежнему на заре мобильных технологий. Никто не знает, как будет выглядеть будущее, так что лучше не пытаться заставить будущее выглядеть как прошлое. Похоже, что Facebook поступает именно так.

Но хватит этого. Как бы вы обслуживали 450 миллионов активных пользователей силами всего 32 инженеров? Давайте посмотрим...

Источники

Предупреждение: мы знаем не так много об архитектуре WhatsApp в целом. Просто фрагменты и обрывки, собранные из разных источников. Доклад Рика Рида посвящён оптимизации, позволившей обрабатывать 2 миллиона соединений на одном сервере используя Erlang, а не обзору всей архитектуры.

Статистика

Эта статистика, в основном, для текущей системы, а не для системы, доклад о которой у нас есть. Доклад о текущей системе будет включать больше информации о хаках для хранения данных, обмена сообщениями, мета-кластеризации, и больше о патчах для BEAM/OTP.

  • 450 миллионов активных пользователей, достигли этой цифры быстрее, чем любая другая компания в мире.
  • 32 инженера, один разработчик приходится на 14 миллионов активных пользователей.
  • 50 миллиардов сообщений каждый день на семи платформах (входящие и исходящие).
  • Больше миллиона новый пользователей регистрируются каждый день.
  • $0 потрачено на рекламу.
  • $60 миллионов инвестиций от Sequoia Capital; $3.4 миллиарда Sequoia заработает.
  • Facebook потратил 35% наличных денег на сделку.
  • Сотни узлов.
  • Более 8000 процессорных ядер.
  • Сотни терабайт RAM.
  • Более 70 миллионов сообщений Erlang в секунду.
  • В 2011 WhatsApp достиг миллиона активных TCP соединений на одном сервере при наличии свободной памяти и ресурсов CPU. В 2012 достигли 2х миллионов соединений. В 2013 они твитнули: "31 декабря мы установили новый рекорд: 7 миллиардов входящих сообщений, 11 миллиардов исходящих сообщений = 18 миллиардов сообщений обработано за один день! С Новым, 2013м!"

Платформа

Бекенд

  • Erlang
  • FreeBSD
  • Yaws, lighttpd
  • PHP
  • Свои патчи для BEAM (BEAM этот как JVM для Java, но для Erlang)
  • Свой XMPP
  • Хостинг, возможно, от Softlayer

    Фронтенд

  • Семь клиентских платформ: iPhone, Android, Blackberry, Nokia Symbian S60, Nokia S40, Windows Phone, ?
  • SQLite

    Аппаратное обеспечение

  • Стандартный сервер, работающий с пользователями:
    • Два 6-ядерных процессора архитектуры Westmere (24 логических процессора);
    • 100GB RAM, SSD;
    • Два сетевых интерфейса (публичный интерфейс для связи с пользователями, внутренний для бекенда)

Продукт

  • Фокус на обмене сообщениями. Соединение людей по всему миру, независимо от того, где они находятся, без необходимости платить много денег. Основатель Ян Кум помнит, как сложно было в 1992 связаться с семьей по всему миру.
  • Приватность. Сформировано воспоминаниями Яна Кума от взросления в Украине, где не было ничего частного. Сообщения не хранятся на серверах; история чатов не хранится; цель — знать о пользователь как можно меньше; ваше имя и пол неизвестны, история чата хранится только на вашем телефоне.

Общее

  • Сервер WhatsApp практически полностью написан на Erlang.
    • Серверные системы, осуществляющие маршрутизацию сообщений написаны на Erlang.
    • Большим достижением является то, что такое большое количество пользователей обслуживается небольшим количеством серверов. Команда сходится во мнении, что, во многом, это благодаря Erlang.
    • Стоит отметить, что Facebook Chat был написан в 2009 на Erlang, но впоследствии от этого языка отказались, так как было сложно найти квалифицированных программистов.
  • Сервер WhatsApp вырос из ejabberd
    • Ejabberd это знаменитый сервер Jabber, с открытым исходным кодом, написанный на Erlang.
    • Первоначально он был выбран так как он открытый, имеет отличные отзывы разработчиков, с ним легко начать работу и есть гарантия того, что Erlang подходит для больших коммуникационных систем в долгосрочной перспективе.
    • Следующие несколько лет были потрачены на переписывание и модифицирование небольшого числа частей ejabberd, включая переход с XMPP на свой протокол, реструктуризацию кодовой базы, перепроектирование нескольких ключевых компонентов и внесения множества важных изменений в виртуальную машину Erlang для оптимизации производительности.
  • Чтобы обработать 50 миллиардов сообщений в день, нужно сфокусироваться на построении надёжной системы, которая работает. О монетизации следует думать позже, она сильно впереди по пути.
  • Основной индикатор "здоровья" системы это длина очереди сообщений. Длина очереди сообщений всех процессов на одном узле постоянно отслеживается и оповещение рассылается, когда она становится длиннее допустимого значения. Если один или несколько процессов отстает от других, и для него было отправлено предупреждение, то это признак очередного узкого места.
  • При отправке мультимедиа сообщения, изображение, аудио или видео отправляются на HTTPS сервер, а затем адресату отправляется ссылка на содержимое, вместе с закодированной в Base64 миниатюрой.
  • Некоторое количество кода выкладывается каждый день. Обычно, это происходит несколько раз в день, но выкладка не происходит во время обычных пиковых нагрузок. Erlang позволяет агрессивно подходить к выкладке исправлений или новых возможностей на продакшен. Горячая замена кода означает, что обновления выкладываются без перезагрузок или перенаправления трафика. Ошибки обычно могут быть исправлены очень быстро, также с помощью горячей замены. Такие системы имеют тенденцию быть слабосвязаными, что облегчает инкрементальную выкладку изменений.
  • Какой протокол используется в приложении WhatsApp? SSL сокет разделяется между пулом серверов. Все сообщения организуются в очередь на сервере до тех пор, пока клиент не подключится для их получения. Уведомление об успешном получении сообщения отправляется северу WhatsApp, который перенаправляет его исходному отправителю (который увидит его в виде "галочки" около сообщения). Сообщения удаляются из памяти сервера, как только клиент его принял.
  • Как процесс регистрации реализован внутри WhatsApp? WhatsApp использовал IMEI телефона для создания имени и пароля пользователя. Недавно это изменили. Теперь WhatsApp использует обычный запрос от приложения, чтобы отправить уникальный 5-и символьный PIN. WhatsApp затем отправляет SMS с этим кодом на указанный номер телефона (это значит, что клиент WhatsApp больше не должен быть запущен на этом же телефоне). На основе PIN-кода приложение запрашивает уникальный ключ у WhatsApp. Этот ключ используется как пароль для последующих вызовов (этот "постоянный" ключ хранится на устройстве). Это также означает, что регистрация нового устройства делает ключ на старом устройстве недействительным.
  • На Android используется сервис push-нотификаций Google.
  • Пользователей Android больше. Работа с Andoid доставляет больше удовольствия. Разработчики могут сделать прототип и мгновенно разослать сотням миллионов пользователей, если есть какая-то проблема, она может быть быстро исправлена. С iOS все не так просто.

Задача о 2+ миллионах соединений на сервер

  • Они столкнулись с большим притоком пользователей, что является положительной проблемой, но также означает необходимость тратить деньги на покупку дополнительного аппаратного обеспечения и увеличившуюся сложность управления всем этими машинами.
  • Необходимо планировать всплески трафика. Примерами могут служить футбольные матчи и землятресения в Испании и Мексике. Это происходит при практически пиковых нагрузках, так что должно быть достаточно свободной ёмкости чтобы справиться с пиками и всплесками. Недавний футбольный матч привел к скачку на 35% количества исходящих сообщений, ровно во время дневного пика.

Средства и технологии, используемые для повышения масштабируемости

  • Разработали средство отслеживания состояния системы (wsar):
    • Записывает характеристики всей системы, включая характеристики ОС, железа, BEAM. Она была разработана такой, что к ней легко подключать метрики от других систем, таких как замеры виртуальной памяти. Система отслеживает потребление CPU, общую загруженность, user time, system time, время обработки прерываний (interrupt time), переключения контекста, исключения, принятые/отправленные пакеты, общее количество сообщений в очередях процессов, события с занятыми портами, трафик, переданные/принятые байты, статистика планировщика, статистика сборщика мусора и так далее.
    • Первоначально сбор информации запускался раз в минуту. С ростом загруженности системы потребовалось сократить период опроса до одной секунды, так как события, произошедшие в течение одной минуты были невидимы. Это действительно хорошо детализованная статистика, позволяющая увидеть, как все работает.
  • Аппаратные счетчики производительности CPU (pmcstat):
    • Смотрят загруженность процессора во времени. Это позволяет узнать, сколько времени тратится на выполнение виртуальной машини. В их случае это 16%, что означает, что только 16% времени уходит на выполнение кода для виртуальной машины, так что даже если бы они смогли убрать все время, в течение которого исполняется Erlang код, то это сэкономило бы только 16% от всего времени работы системы. Это подразумевает, что следует сфокусироваться на других областях, чтобы увеличить эффективность системы.
  • dtrace, kernel lock-counting, fprof
    • Dtrace использовался в первую очередь для отладки, а не для контроля производительности.
    • Они пропатчили BEAM под FreeBSD, чтобы получить CPU time stamp.
    • Написали скрипты, чтобы получить агреггированный обзор со всех процессов, чтобы понять, на что тратится время.
    • Наибольшим достижением была компиляция эмулятора со включенным счетчиком блокировок.
  • Некоторые проблемы
    • Раньше было замечено, что много времени уходит на процедуры сборки мусора, это было исправлено.
    • Заметили некоторые проблемы с сетевым стеком, но решили их настройкой.
    • Большинство проблем были вызваны состоянием гонки за блокировки, что серьезно отражается на выводе от счетчика блокировок.
  • Измерения:
    • Синтетические нагрузки, то есть генерация трафика вашими скриптами, имеют мало смысла для настройки работающих с пользователями систем огромного размера.
    • Работало неплохо для простых интерфейсов, таких как таблица пользователей, генерируя вставки и чтения так быстро, как только возможно.
    • Если сервер может обработать миллион соединений, то потребуется 30 хостов, чтобы открыть нужное количество IP-портов, чтобы сгенерировать достаточно соединений для сервера. Для сервера, держащего два миллиона соединений, потребуется 60 хостов. Сложно создать такой масштаб.
    • Сложно сгенерировать трафик, как при реальном использовании. Можно предположить нормальную нагрузку, но в реальности обнаружатся сетевые события, всемирные события, а по причине мульти-платформенности, обнаружатся отличия в поведении клиентов и отличия по странам.
    • Объединенная нагрузка:
      • Возьмите обычный трафик от продакшена и направьте его на отдельную систему.
      • Это очень удобно для систем, где сайд-эффекты могут быть ограничены. Вы не хотите перенаправить трафик и делать то, что может повлиять на постоянное состояние пользователей или привести к нескольким копиям сообщения, отправленным пользователям.
      • Erlang поддерживает горячую замену кода, так что можно находясь под полной нагрузкой что-то придумать, скомпилировать, загрузить изменение, пока программа работает, и мгновенной увидеть, лучше стало или хуже.
      • Они добавили переключатели, чтобы динамически изменять нагрузку от продакшена и видеть, как это скажется на производительности. Они будут читать вывод от sar, смотря на загрузку CPU, потребление памяти, отслеживать переполнения очередей, а затем переключат переключатели, чтобы увидеть, как система отреагирует.
    • Реальные нагрузки
      • Абсолютный тест. Выполнение задач как ввода так и вывода.
      • Внесите сервер в DNS пару раз, так что он будет получать вдвое или втрое больше трафика, чем обычно. Это создает проблемы с TTL, так как клиенты игнорируют TTL от DNS, что создает задержку, и нельзя быстро отреагировать на получение большего объёма трафика, который нужно обработать.
      • IPFW. Перенаправляйте трафик от одного сервера к другому, чтобы получить требуемое количество клиентских соединений. Есть баг, вызывающий kernel panic, так что это не очень хорошо работает.
  • Результаты:
    • Начали с 200 тыс. одновременных соединений на сервер.
    • Первое узкое место обнаружилось на 425 тысячах. Система вошла в состояние гонок. Работа остановилась. Обратились к планировщику, чтобы измерить, сколько полезной работы выполняется, сколько процессов ожидает, сколько в блокировках. Под нагрузкой возросли ожидающие, так что использовалось 35-45% CPU, 95% из которых потребляли планировщики.
    • Первый этап исправлений позволил достичь миллиона соединений.
      • Потребление памяти составило 76%, процессор был загружен на 73%. BEAM потреблял 45% ресурсов, что близко к значением потребления ресурсов из пространства пользователя, это хорошо, так как BEAM работает от имени пользователя.
      • Обычно, потребление CPU это не самая удачная метрика, так как планировщик тоже потребляет CPU.
    • Спустя месяц, после исправления бутылочных горлышек, достигли двух миллионов соединений.
      • BEAM потребляет 80% памяти, близко к показателю, когда FreeBSD начинает выгружать страницы из памяти. Потребление CPU примерно такое же, но с двукратным приростом количества соединений. Планировщик сталкивается с блокировками, но работает довольно неплохо.
    • Выглядело как хороший момент, чтобы остановиться, поэтому начали профилировать код на Erlang.
      • Первоначально было два процесса на каждое соединение. Сократили до одного.
      • Небольшие изменения работы с таймерами.
    • Достигли пика на 2.8 миллиона соединений на сервер
      • 571 тысяча пакетов в секунду, больше 200 тыс сообщений в секунду.
      • Сделали несколько оптимизаций работы с памятью. и её потребление сократилось до 70%.
    • Пробовали 3 миллиона соединений, но не получилось.
      • Когда система под нагрузкой, очереди сообщений вырастают. Либо одна очередь, либо несколько сразу.
      • Они добавили в BEAM механизм по отслеживанию очередей сообщений для каждого процесса в отдельности. Отслеживают, как много сообщений принято и отправлено, насколько быстро.
      • Замеры производятся каждые 10 секунд, можно увидеть, что если у процесса в очереди 600 тысяч сообщений, с задержкой 15 секунд и извлечением из очереди 40 тысяч сообщений, то ожидаемое время очистки очереди составит 41 секунду.
  • Выводы:
    • Erlang + BEAM + их патчи — прекрасное масштабирование на SMP. Почти линейное масштабирование. Поразительно. Можно запустить систему, потребляющую 85% CPU и она будет продолжать работать под реальными нагрузками. Она может работать так хоть весь день.
      • Привет программной модели Erlang.
      • Чем больше сервер работает, тем больше долгоживущих соединений он соберёт, эти соединения большую часть времени находятся в состоянии ожидания, так что сервер может обработать ещё больше соединений, так как эти соединения не так загружены, как другие.
    • Блокировки — главная проблема
      • Внесли в свой код исправления, чтобы уменьшить проблемы от блокировок BEAM.
      • Пропатчили BEAM.
      • Распределение задач таким образом, что задачи не перемещаются между процессорами лишний раз.
      • Каждый раз, когда сообщение получена от порта, обновляется блокировка, единая для всех планировщиков, то есть все процессоры обращаются к одной блокировке.
      • Оптимизировали использование таймеров. Убрали таймеры на встроенных функциях (BIF, build-in-function).
      • Добавили такую функцию записи в файл, которая принимает уже открытый порт, для того, чтобы снизить конкуренцию за порты ввод-вывода.
      • Аллокатор mseg — единая точка конкуренции для всех аллокаторов. Сделали его отдельным для каждого планировщика.
      • При получении соединения выполняется много транзакций с портами. Внесли изменения, чтобы уменьшить количество дорогих операций взаимодействия с портами.
      • Когда очередь сообщений становится большой, сборка мусора может дестабилизировать систему. Так что сборка мусора приостанавливается до тех пор, пока очередь не сократиться.
    • Избегание некоторых дорогих вещей.
      • Бекпортировали TSE таймер с FreeBSD 9 на 8. Этот таймер читать дешевле. Можно быстрее получить время, и это не так дорого, как обращение к аппаратному чипу.
      • Увеличили количество сокетов и файлов.
      • Pmcstat показала, что много времени уходило на поиcк PCB в сетевом стеке. Увеличили размер хеш-таблицы, чтобы сделать поиск быстрее.
    • Патчи BEAM
      • Уже упомянутые диагностические патчи. Пропатчили планировщик, чтобы получить информацию о потреблении ресурсов, статистику очередей сообщений, количество "спящих" процессов, количество отправленных сообщений, счетчики сообщений, и так далее. Может быть получено и из Erlang, c помощью procinfo, но при миллионе соединений это очень медленно.
      • Сбор статистики очень эффективен, поэтому его можно запускать и в продакшене.
      • Статистика собирается через три увеличивающихся интервала: 1, 10 и 100 секунд. Позволяет отслеживать проблемы с течением времени.
      • Сделали подсчет блокировок для большего числа асинхронных потоков.
      • Добавили механизмы для отладки счетчиков блокировок.
    • Настройка
      • Установили границу пробуждения планировщика ниже, потому что планировщик может уйти в состояние "сна" и не проснуться.
      • Предпочти mseg, а не malloc.
      • Увеличили размер буферов FreeBSD, и дали им возможность увеличиваться ещё сильнее. Это заставляет FreeBSD использовать супер-страницы. Сокращает замусоривание TLB и увеличивает пропускную способность CPU.
      • Свой аллокатор для каждого экземпляра планировщика.
      • Запустили BEAM с real-time приоритетом, так что другие задачи, такие как cron не прерывают планировщик. Предотвращает заминки при обработке трафика пользователей.
      • Специальный патч, чтобы уменьшить работу планировщка вхолостую.
    • Mnesia
      • Предпочитают использовать os:timestamp, а не erlang:now.
      • Транзакции не используются, но применяется удалённая репликация. Параллелизованная репликация для каждой таблицы, чтобы увеличить пропускную способность.
    • На самом деле сделано намного больше изменений.

Уроки

  • Оптимизация это тёмная отвратительная работа, подходящая только для троллей и инженеров. Если просмотреть все изменения, которые Рик внес, чтобы достичь двух миллионов соединений на сервер, то это сведет вас с ума. Вдумайтесь в этот огромный объём работы, который вылился в написание инструментов, выполнение тестов, бекпортирование кода, добавление огромного числа метрик в практически все уровни стека, настройка системы, просмотр трассировок, изучение деталей на самом низком уровне, и попытки понять все. Вот что значит, устранение узких мест для того, чтобы увеличить производительность и масштабируемость до экстремальных значений.
  • Получайте данные, которые вам нужны. Пишите инструменты. Исправляйте инструменты. Добавляйте выключатели. Кен без устали расширял систему, чтобы получать данные, которые им требовались, постоянно разрабатывая инструменты и скрипты для обработки этих данных, чтобы управлять системой и оптимизировать её. Делайте все, что угодно.
  • Измеряйте. Устраняйте узкие места. Тестируйте. Повторяйте. Вот, как это делается.
  • Erlang rocks! Erlang продолжает доказывать свои способности как гибкой, надежной, высокопроизводительной системы. Хотя, все настройки и исправления вызывают у меня некоторые сомнения относительно этого утверждения.
  • Взломайте код виральности и прибыльности. Виральность это спорное качество, но если вы сможете разобраться в этом, то оно принесет вам много денег.
  • Ценность и количество сотрудников теперь официально не имеют ничего общего. Всем сейчас доступно то, что сделает их сильнее. Продвинутая телекоммуникационная инфраструктура делает приложения вроде WhatsApp возможными. Если бы WhatsApp должен был создать свою сеть, свой телефон или что-то в этом роде, они бы не появились. Доступность мощного дешевого оборудования и программного обеспечения с открытым исходным кодом также усиливает успех. Равно как и появление в нужном месте в нужное время с правильным продуктом рядом с правильным покупателем.
  • В этой жесткой сосредоточенности на пользователях что-то есть. WhatsApp сосредоточен на том, чтобы быть простым приложением по обмену сообщениями, а не игровой сетью, не рекламной сетью и не сетью с исчезающими картинками. Для них это сработало. Это привело их к принципу отказа от рекламы, способности сохранять приложение простым, добавляя новые возможности и бесхитростной философии о том, что оно просто работает на любом телефоне.
  • Ограничения во имя простоты — это хорошо. Ваша личность привязана к номеру вашего телефона, так что если вы его смените, ваша личность будет потеряна. Это не по-компьютерному. Но это делает всю систему значительно проще.
  • Возраст это не главное. Если Брайана Эктона, сооснователя WhatsApp, не взяли в Twitter и Facebook в 2009м из-за возрастной дискриминации, то это позор, позор, позор.
  • Начните с простого, затем улучшайте. Когда проект был запущен, бекенд был основан на ejabberd. Он был полностью переписан с тех пор, но это был первый шаг в направлении Erlang. Расширяемость, надежность и работоспособность Erlang в этом исходном сценарии привели ко все более широкому его использованию.
  • Сохраняйте количество серверов небольшим. Постоянно работайте над тем, чтобы количество серверов было максимально небольшим, оставляя запас на случай событий, вызывающих краткосрочный всплеск нагрузки. Анализируйте и оптимизируйте пока уменьшение количества оборудования оправдывает затраченные усилия, а потом добавьте еще железа.
  • Держите избыточное количество оборудования. Это гарантирует, что в пользователей есть непрерывающийся сервис во время праздников, а сотрудники могут отдохнуть на выходных, без необходимости провести все время решая проблемы, вызванные увеличением нагрузки.
  • Рост останавливается, когда вы просите денег. Рост был нереально большим, когда WhatsApp был бесплатным, 10000 загрузок в первые дни. Когда они переключились на платную модель, рост сократился до 1000 в день. В конце года, когда добавили обмен картинками, они перешли к однократному платежу при установке, позже превратившемуся в ежегодные платежи.
  • Вдохновение приходит из самых странных источников. Постоянные забытые пароли и имена пользователей от Skype, привели к стремлению сделать приложение, которое просто работает.

Связанные работы

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

Автор: IvaYan

Источник

* - обязательные к заполнению поля

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js