Photon что это

Обзор: ОС VMware Photon отлично подходит для контейнеров Docker

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

Photon OS — это компактный хост-контейнер Linux, предназначенный для работы на виртуальных машинах и настроенный для гипервизоров VMware. VMware, безусловно, широко поддержала движение Docker, и не только в VMware. Вы можете запустить Photon OS на других гипервизорах, включая Google Compute Engine и Amazon EC2. Однако вы не можете установить Photon OS на физический сервер.

Photon OS не делает предположений о наборе инструментов контейнера, хотя Docker установлен по умолчанию. Администраторы могут располагать инструменты управления контейнерами по своему выбору над базовой ОС с помощью диспетчера пакетов Photon.

Системное администрирование Photon OS

В ОС Photon управление пакетами осуществляется с помощью TDNF (Tiny Dandified Yum), созданного VMware с открытым исходным кодом, который предлагает управление пакетами, совместимое с DNF, без использования большого объема Python в Yum.

VMware предоставляет свои собственные Yum-совместимые репозитории для управления пакетами и подписывает пакеты подписями GPG (GNU Privacy Guard). Это помогает сделать систему безопасной по умолчанию. Проверка подписи происходит автоматически, поэтому никаких дополнительных действий со стороны системных администраторов или скриптов не требуется. Репозитории Photon OS «курируются», поэтому не ожидайте найти все доступные для загрузки пакеты.

Поскольку в Photon OS 1.0 Revision 2 включена более старая версия Docker, первое, что я хотел сделать, это попробовать обновление. Все прошло безупречно, и в считанные минуты все мои контейнеры работали на последней версии Docker.

Photon OS использует систему инициализации Systemd, поэтому администраторам придется изучить этот вид управления системой, если они еще этого не сделали. Безопасность находится в центре внимания, и система включает SE Linux для повышения изоляции контейнеров. Брандмауэр (iptables) включен по умолчанию, и пакеты от внешних интерфейсов (кроме трафика SSH) отбрасываются, поэтому администраторам потребуется добавить правила, разрешающие трафик из внешнего мира.

В основном эта безопасность по умолчанию не мешала, за исключением случаев обязательного изменения пароля root из чистой установки. Любая ошибка выкидывает пользователя из оболочки и возвращает обратно приглашение для входа в систему. Эта часть могла бы быть немного более удобной для пользователя.

Установка и настройка Photon OS

Я установил Photon OS с помощью загружаемой виртуальной машины. Как и следовало ожидать, с моей установкой VMware Workstation Pro это было безболезненно. Система обнаружила загрузку, спросила, хочу ли я принять параметры оборудования, и сразу загрузилась. Photon OS также доступна в виде ISO и образов для облаков Amazon и Google. После входа в систему как root и настройки входа без пароля я отключился и работал.

Минимальная установка, как и другие хосты контейнеров Linux, почти ничего не содержит, даже sudo несмотря на то, что она включает SSH. Администраторы, развертывающие виртуальные машины Photon OS, захотят написать сценарий установки, и для этого Photon OS использует Cloud-Init, набор скриптов и утилит Python, чтобы упростить развертывание и настройку облака.

Даже для ОС для контейнеров Docker настройка Photon OS была настолько простой, насколько это возможно. Кажется, запуск Nginx в контейнере — это «привет, мир» для Docker. Вот он на Photon OS:

# systemctl start docker

# systemctl enable docker

# docker run –d –p 80:80 vmwarecna/nginx

Хранение и сеть Photon OS

Благодаря работе в виртуализированной аппаратной среде устройства хранения выглядят как обычное оборудование, а стандартные операции с файловой системой доступны в Photon OS. Вы можете добавить к машине новый (виртуальный) диск и смонтировать его там, где это необходимо, как и любой другой диск. Файловая система Photon OS включает Btrfs и Ext4. Корневая файловая система по умолчанию — Ext4. Примеров Btrfs немного, и, похоже, преобладает Ext4.

Удаленное хранилище обрабатывается утилитами Photon NFS. Ни один из других контейнерно-ориентированных Linux, которые я использовал (Alpine, RancherOS, CoreOS и Atomic Host), не содержал инструкций для NFS, поэтому я был рад увидеть, что VMware задокументировала эту практику. NFS все еще жива и работает в корпоративных средах, и я ожидаю, что установка дисков NFS будет обычным вариантом использования для пользователей Photon OS.

Единственный необычный вариант хранения в Photon OS — это выбор файловой системы только для чтения или чтения-записи, но это действительно зависит от варианта использования, и я был рад, что у меня есть выбор.

Сеть в Photon OS использует IPRoute2 утилиты, хотя традиционные ipconfig и netstat команды включены. Установки Photon OS по умолчанию не включают конфигурацию сети контейнеров, но многие популярные конфигурации задокументированы: Docker, Rocket, DCOS и т. Д. С точки зрения сети Photon OS ничем не отличается от любой другой разновидности Linux, и здесь не было никаких сюрпризов.

Обновления ОС Photon и более ранние версии

Как и Red Hat Atomic Host, Photon OS использует rpm-ostree в качестве гибридной системы управления образами / пакетами со своим собственным сервером OSTree. Понимание наборов команд rpm-ostree, терминологии и передовых методов займет у администраторов некоторое время. Помимо изучения нового набора команд, администраторы должны знать о каталогах только для чтения и следить за тем, чтобы приложения не записывали в них файлы. Например, каталог / usr доступен только для чтения при использовании rpm-ostree. Профиль rpm-ostree — это параметр во время установки, поэтому пользователи могут выбрать TDNF или rpm-ostree для управления пакетами. Документация по этой теме хороша.

При разработке Photon OS VMware смогла удалить все виды устаревших модулей из ядра Linux. Поскольку VMware контролирует все оборудование и стек ОС, она также может настраивать буферы, учет времени и флаги компиляции, чтобы устранить избыточность между средой выполнения контейнера и гипервизором. Для организаций, инвестирующих в виртуализацию VMware, проект Photon должен быть в верхней части списка для изучения.

Photon — OSINT инструмент

Photon — это относительно быстрый сканер, разработанный для автоматизации OSINT (Open Source Intelligence) с простым интерфейсом и множеством параметров настройки. Он разработан S0md3v и написан на одном из моих самых любимых языков, Python. По сути, Photon выступает в роли веб-сканера, который может извлекать URL-адреса с параметрами, а также может скрывать их секретные ключи AUTH и многое другое.

Установка Photon

Для начала нужно клонировать инструмент с официального репозитория. Сделать это можно с помощью следующей команды:

Установка необходимых зависимостей

Установка зависимостей в Python довольно проста, большинство разработчиков предоставляют requirements .txt файл вместе с пакетом, который имеет список всех зависимостей с конкретной версией, используемой в скрипте. Итак, время CD в клонированный репозиторий и установить зависимости.

Здесь мы вызываем двоичный файл python3 и запускаем модуль pip, который является менеджером пакетов для Python через командную строку. Позже мы передаем флаг -r в PIP для передачи списка требований. PIP будет проходить строку за строкой и устанавливать все необходимые пакеты.

Завершение установки пакетов из requirements.txt
@ llamasec.tk

Запуск и использование Photon

После успешной установки инструмента и всех необходимых пакетов для корректной работы инструмента самое время запустить и проверить на что же способен Photon. Сделать это можно с помощью следующей команды:

Вывод после запуска Photon @ llamasec.tk

Как вы можете видеть, Photon предлагает множество интересных функций. Вы можете:

• сканировать один веб-сайт;
• клонировать веб-сайт;
• устанавливать глубину ссылок; указывать пользовательские агенты и многое другое.

Краулинг сайта с помощью Photon

Для проведение сканирования веб-сайта необходимо воспользоваться следующей командой:

Например, можно просканировать наш сайт с помощью следующей команды:

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

В данной строке кода указывается количество потоков сканирования –l 1 -t 10, а также имя выходного файла Nelus с отображением DNS.

S0md3v также добавил визуальный DNSmap, что является довольно сложным процессом, однако очень полезно и крайне эффективно при сканировании сайта.

Подводим итоги

Photon является отличным инструментом для сканирования и анализа любого веб-сайта. Стоит отметить немаловажный плюс — крайне быстрое сканирование.

Пересаживаем высоконагруженный игровой проект с Photon на кастомные решения

Photon хорош, но со всем приходит время расставаться.

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

Но, как это часто бывает, с развитием продукта универсальные решения требуют обработки напильником. А ведь War Robots существует уже почти восемь лет — инфраструктура серверов за это время менялась неоднократно по мере масштабирования проекта, который сейчас уже перешагнул через порог 200 млн установок.

В нашем случае такая обработка вылилась в собственные реализации тех или иных компонентов. Матчмейкинг и социальные фичи перекочевали в отдельные сервисы, новые игровые механики реализовывались на сервере для лучшей согласованности. В итоге от Photon остался транспорт, прослойка PUN на стороне клиента и некоторые сопутствующие расходы в виде лицензии, привязки к Windows и .Net Framework и чрезмерных аллокаций на клиенте.

Стало понятно, что затраты на фреймворк превышают его ценность, и надо тiкать.

Итак, что мы имели по структуре серверов на проекте. У нас был Master Server, который занимался балансировкой, и Game Server, который, помимо того, что обрабатывал бои, также позволял делать API-запросы в микросервисы через специальную «ангарную» комнату. С тех пор эта комната переместилась в отдельный сервис, но не перестала выглядеть чем-то инородным.

Схема работы была примерно такой:

Обратите внимание на две балансировки: Master Server распределяет клиентов по API серверам, а выбор Game Server лежит на Matchmaking Server. На диаграмме специально не отображен процесс подключения к специальным комнатам в Master и API Server, иначе она была бы ещё больше.

Тут следует сделать небольшое отступление. Насколько бы ни была хорошо изолирована бизнес-логика, перевод такого проекта, как War Robots, на новый транспорт — это довольно долгий процесс. Помимо самого рефакторинга, необходимо:

• провести тестирование,
• поменять процесс развертывания,
• подготовить тестовые окружения,
• закупить или перенастроить новые сервера,
• обновить документацию,
• настроить дэшборды в системе мониторинга и т. д. и т. п.

Такой объем не поместится ни в один спринт, а ценность подобного рефакторинга для бизнеса, прямо скажем, неочевидная. Но если разбить переход на этапы так, чтобы в конце каждого был ощутимый результат, протолкнуть идею будет проще, ведь между этапами можно будет заниматься монетизируемыми фичами, а рефакторинг не будет лежать подолгу в отдельной ветке, в которую нужно постоянно подливать master.

Принимая во внимание вышесказанное, первым делом было решено избавляться от Photon в API Server.

Его перевели на TCP и protobuf. До этого, как и на игровых серверах, там были RUDP и сериализация Photon. Это позволило не переписывать Master Server, а просто удалить его и перейти на балансировку с помощью HAProxy.

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

Для этого на сервере добавилось абстракций, и он разделился на две реализации: работающую с Photon и новую. Таким образом, после окончательного перехода оставалось только удалить ненужный проект из солюшена, а не заниматься точечным вычищением кода.

Код, отвечающий за взаимодействие с Photon, не изменился ни на сервере, ни на клиенте, поэтому можно было не опасаться, что что-то внезапно пойдет не так.

В переходный период Profile Server на запрос списка Master Server отдавал либо адреса Photon-овских мастеров, либо HAProxy — в зависимости от настройки. И после окончательного перехода схема стала выглядеть так:

Следующим шагом стал отказ от Photon на гейме. Алгоритм действий — такой же, как и в случае с API Server:

• написали бенчмарк для сравнения двух библиотек, реализующих RUDP,
• выбрали наиболее производительную библиотеку,
• провели рефакторинг,
• разделили сервер на два сервиса, работающих с разными транспортами,
• добавили переключатель,
• отдали в отдел QA.

Спустя несколько итераций тестирования и полировки мы были готовы обновлять боевые сервера.

На проекте War Robots есть практика проведения так называемого внешнего тестирования — это когда игроки могут скачать отдельную версию игры и посмотреть контент, который ещё находится в разработке, а мы можем собрать фидбек и метрики, не боясь сломать что-то на продакшене.

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

На внешнем тестировании нас ждал сюрприз. Всё было очень плохо: роботы телепортировались, урон не наносился, игроков выкидывало из комнаты. Понятно, что дело было в нагрузке, ведь в процессе внутренних тестов подобных симптомов не наблюдалось. Но что же произошло — бенчмарк же показал, что всё хорошо?

А корень зла был в самом бенчмарке. Дело в том, что помимо смены транспорта планировалась переделка протокола. Не вдаваясь в подробности, скажу, что сообщений должно было стать меньше, они должны были быть больше, но не превышать MTU. Конечно, согласно методологии, переход на новый протокол должен был состояться в следующей итерации, но бенчмарк проектировался с учетом нового протокола, а не текущего. В текущем же было много мелких сообщений, а выбранная библиотека не поддерживала их склейку в один UDP-пакет, преследуя цель как можно быстрее отправить данные. Слишком частые вызовы отправки влияли на пропускную способность, что и приводило к проблемам.

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

Оставалось упаковать всё в образы для Docker. Тут тоже был прикол. Сервисы использовали ServerGC, но в .net был баг, из-за которого в контейнерах сборщик мусора вообще не вызывался, что приводило к перезагрузке. Впервые мы столкнулись с этим когда завернули в образ один из вспомогательных сервисов и запустили его в k8s. Конечно, мы были не первые, кто столкнулся с этой проблемой. В этой статье есть подробности.

Для вспомогательного сервиса мы просто перешли на WorkstationGC. Он крутится на отдельной машине, в принципе потребляет немного ресурсов и никак не влияет на игроков. Но с Game Server всё сложнее: там лишние вызовы сборщика могли сказаться на пользовательском опыте.

Нам повезло: к тому моменту, когда мы были готовы развернуть новые сервисы на проде, вышла стабильная версия .net 6, в которой баг был пофикшен. Поэтому мы просто переделали базовые образы, провели несколько плейтестов и стали ждать релиз.

Вкратце: всё прошло гладко. Первое время мы включали новый транспорт на время рабочего дня и переводили на старые рельсы на ночь, чтобы иметь возможность оперативно отреагировать в случае «пожара». И уже спустя пару недель можно было подвести итоги и сравнить текущие графики с историческими.

Google Photon. Обработка данных со скоростью света*

Photon – масштабируемая, отказоустойчивая и географически распределенная система обработки потоковых данных в режиме реального времени. Система является внутренним продуктом Google и используется в Google Advertising System. Research paper [5], описывающие базовые принципы и архитектуру Photon, был представлен на научной конференции ACM SIGMOD в 2013 году.

В paper [5] заявлено, что пиковая нагрузка на систему может составлять миллионы событий в минуту со средней end-to-end задержкой менее 10 секунд.
* ‘Скорость света’ в заголовке — наглая ложь гипербола.

Photon решает вполне конкретную задачу: необходимо соединить (выполнить операцию join) два непрерывных потока данных в режиме реального времени. Так в упоминаемой уже Google Advertising System один из этих потоков – поток поисковых запросов, другой – поток переходов по рекламным объявлениям.

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

Используемые сервисы: Google File System, PaxosDB, TrueTime.

Базовые принципы

В [5] объяснение принципов работы Photon идет в следующем контексте: пользователь ввел поисковый запрос (query) в момент времени t1 и перешел по рекламному объявлению (click) в момент времени t2. В этом же контексте, если не задано иного, в этой статье будут объяснены принципы работы Photon.

Принцип объединения потоков (join) взят из мира РСУБД: поток query имеет уникальный идентификатор query_id (условно Primary Key), поток click имеет уникальный идентификатор click_id и включает в себя некоторый query_id (условно Foreign Key). Объединение потоков происходит по query_id.

Следующий важный момент: ситуация, когда один click event посчитан дважды, либо, наоборот, не посчитан, будет вести, соответственно, либо к судебным искам со стороны рекламодателей, либо к упущенным выгодам со стороны Google. Отсюда, крайне важно обеспечить at-most-once семантику обработки событий.

Другое требование – обеспечить near-exact семантику, т.е. чтобы большая часть событий была посчитана в режиме близкому real-time. События, не посчитанные в real-time, все равно должны быть посчитаны — exactly-once семантика.

Кроме того, для экземпляров Photon, работающих в разных дата-центрах, необходимо синхронизированное состояние (точнее только critical state, так как между ДЦ весь state слишком «дорого» реплицировать). Таким синхронизируемым critical state выбрали event_id (по сути, click_id). Critical state храниться в структуре IdRegistry – in-memory key-value хранилище, построенное на основе PaxosDB.

Последний – PaxosDB – реализует алгоритм Paxos для поддержки отказоустойчивости и согласованности данных.

Взаимодействие с клиентами

Worker-узлы взаимодействуют с IdRegistry по клиент-серверной модели. Архитектурно взаимодействие Worker-узлов с IdRegistry – это сетевое взаимодействие с очередью асинхронных сообщений.

Так клиенты – Worker-узлы — отправляют к IdRegistry только 1) запрос на поиск event_id (если event_id найден, значит он уже был обработан) и 2) запрос на вставку event_id (для случая, если на шаге 1 event_id не был найден). На стороне сервера запросы принимают RPC-обработчики, целью которых поставить запрос в очередь. Из очереди запросы забирает специальный процесс Registry Thread (синглтон), который и выполнит запись в PaxosDB и инициализирует обратный вызов (callback) клиенту.

Источник иллюстрации [5, Figure 3]

Масштабируемость

Т.к. реплика IdRegistry происходит между географическим регионами, сетевые задержки между которыми могут достигать 100 мс [5], то это автоматически ограничивает пропускную способность IdRegistry до десяти последовательных транзакций (event_id commits) в секунду, в то время как требование к IdRegistry было равно 10K транзакций в секунду. Но и отказаться от геораспределенности и/или от синхронно репликации critical state с поддержкой решений конфликтов в кворуме также нельзя.

• пакетная отправка запросов (batching) – «полезная» информация по event_id занимает менее 100 байт; запросы отправляются пакетами на IdRegistry Client. Там они попадают in-memory в очередь, которую разбирает процесс Registry Thread, в обязанности которого входит решение конфликтов, связанные с тем, что в очереди может быть более одного элемента с одинаковым event_id.
• timestamp-based sharding (+ динамический resharding) – все event_id делятся по диапазонам; транзакции по каждому из диапазонов отправляются на определенный IdRegistry.

Компоненты

• EventStore – обеспечивает эффективный поиск по queries (поток поисковых запросов в поисковой системе);
• Dispatcher – чтение потока кликов по рекламным объявлениям (clicks) и передача (feed) прочитанного Joiner;
• Joiner – stateless RPC-сервер, принимающий запросы от Dispatcher, обрабатывающий их и соединяющий (join) потоки queries и clicks.

Взаимодействие между ДЦ:

Источник иллюстрации [5, Figure 6]

Алгоритм добавления записи в Joined Click Logs опустим, отметив, что в работы систем с частым сетевым взаимодействием применение retry-политик и асинхронных вызовов является крайне эффективным способом увеличения надежности и масштабируемости системы, соответственно, без усложнения общего алгоритма работы.

Этими же приемами – retry-политик и асинхронных вызов – и воспользовались создатели Photon.

Как уже ранее упоминалось, ситуация, когда click_id поступил на обработку, а ассоциированный с ним query_id нет – не исключение. Все из-за того, что не обязательно поток поисковых запросов обработается к тому моменту, кода начнет обрабатываться поток кликов по контекстной рекламе.

Для надежного обеспечения at-least-once семантики обработки всех click_id была введена логика, по которой для случая, описанного выше, применяется логика повторения. Для избегания троллинга (throttling) системы самой собой время между неудачными запросами увеличивается по экспоненте – exponential backoff algorithm. После некоторого количества неудачных запросов или по прошествии определенного времени click помечается как «unjoinable».

Dispatcher

Dispatcher – процесс, ответственный за чтение логов кликов — clicks. Эти логи хранятся в GFS и растут во времени непрерывно.

Для того, чтобы эффективно их читать, Dispatcher периодически сканирует директорию с логами и идентифицирует новые файлы и/или измененные, сохраняет состояние каждого файла в локальной GFS-ячейке. Это состояние содержит список файлов и сдвиг от начала файла для данных, которые уже были обработаны. Таким образом при изменении файла, последний вычитывается не с начала, а с того момента, на котором обработка закончилась в прошлое чтение.

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

Joiner

Joiner – реализация stateless RPC-сервера, принимающего запросы от Dispatcher. Приняв запрос от Dispatcher, Joiner извлекает из него click_id и query_id. После чего по query_id пытается получить информацию из EventStore.

В случае успеха, EventStore возвращает поисковый запрос соответствующий обрабатываемому click.

Далее Joiner удаляет дубликаты (с помощью IdRegistry) и генерирует выходной лог, содержащий объединенные (joined) значения – Joined Click Logs.

Если Dispatcher для обработки отказов использовал retry-логику, то в Joiner инженеры Google добавили еще один прием. Прием работает в случаях, когда Joiner отправил запрос к IdRegistry; последний успешно зарегистрировал click_id, но из-за сетевых проблем, либо по таймауту Joiner так и не получил ответ об успехе от IdRegistry.

Для этого с каждым «commit click_id»-запросом, который Joiner отправляет на IdRegistry, ассоциируется специальный токен. Токен сохраняется в IdRegistry. В случае, если ответ от IdRegistry не был получен, Joiner повторяет запрос с тем же токеном, что и в прошлом запросе, и IdRegistry без труда «понимает», что пришедший запрос уже обрабатывался.

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

Ясно, что гарантированная уникальность для event_id крайне важное требование для работы Photon. В то же время, алгоритм генерации уникального в рамках нескольких ДЦ значения может занять крайне значительное время и количество CPU-ресурсов.

Инженеры Google нашли элегантное решение: event_id можно уникально идентифицировать используя IP узла (ServerIP), Id процесса (ProcessId) и временную метку (Timestamp) узла, на котором данное событие было сгенерировано.

Как и в случае со Spanner, для минимизации несогласованности временных меток на различных узлах, используется TrueTime API.

EventStore

EventStore – это сервис, принимающий на вход query_id и возвращающий соответствующий query (информацию о поисковом запросе).

1. CacheEventStore – распределенное [sharding по hash(query_id)] in-memory хранилище, к котором хранится полная информация по query. Таким образом, для ответа на запрос не требуется чтение с диска.
2. LogsEventStore — key-value хранилище, где key – query_id, а value – имя log-файла, в котором хранится информацию по соответствующему query, и смещение (byte offset) в этом файле.

В researching paper [5] приводится статистика, что только 10% запросов «проходят мимо» in-memory кэша и, соответственно, обрабатываются LogsEventStore.

Результаты

Конфигурация

На момент публикации [5], т.е. в 2013 году, реплики IdRegistry развернуты в 5-ти датацентрах в 3-ех географических регионах (восточное, западное побережье и Mid-West Северной Америки), причем сетевые задержки между регионами превышают 100 мс. Другие компоненты Photon – Dispatchers, Joiners, etc. – развернуты в 2-ух географических регионах на западном и восточном побережье США.

В каждом из ДЦ количество IdRegistry-шардов превышает сотню, а количество экземпляров процессов Dispatcher и Joiner превышает тысячи.

Производительность

Photon обрабатывает миллиарды joined-событий в день, в том числе, в периоды пиковых нагрузок миллионы событий в минуту. Объем clicks-логов, обрабатываемых за 24 часа, превышает терабайт, а объем суточных query-логов исчисляется десятками терабайт.

90% всех событий обрабатываются (join’ятся в один stream) в первые 7 секунд, после их появления.

Источник иллюстрации [5, Figure 7]. Больше графиков со статистикой (слайды 24-30).

Простые принципы сложных систем

В разделе «Базовые принципы» я уже упоминал, что Photon является системой с поддержкой exactly-once (at-least-once и at-most-once) и near-exact семантики, т.е. гарантирует, что любое событие, зафиксированное в логах, будет обработано один и только один раз, причем с большой вероятностью в режиме близком к реальному времени.

• Масштабируемость:
  • Обязательный sharding для нереляционных хранилищ;
  • Все worker-узлы является stateless.
  • RPC-коммуникации везде, где это возможно;
  • Перенос (transfer) данных в RAM везде, где это возможно.

  В заключении

  В заключении research paper [5], инженеры Google поделились хорошими практиками и своим планами на будущее.

  • Используйте RPC-коммуникации вместо записи на диск. Запросы, выходящие за физические границы узла, должны выполняться асинхронно, а клиент всегда должен рассчитывать, что не получит ответ по таймауту или из-за сетевых проблем.
  • Минимизируйте критическое состояние (critical state) системы, т.к. его, в общем случае, приходится синхронно реплицировать. В идеале в критическое critical state системы должен включать в себя только метаданные системы.
  • Sharding – друг масштабируемости 🙂 Но и эту идею инженеры Google улучшили, сделав time-based sharding.

  Пожелаем создателям Photon удачи в реализации их планов! И ждем новых research paper!

  Список источников**

  [5] Rajagopal Ananthanarayanan, Venkatesh Basker, Sumit Das, Ashish Gupta, Haifeng Jiang, Tianhao Qiu, et al. Photon: Fault-tolerant and Scalable Joining of Continuous Data Streams, 2013.
  ** Полный список источников, используемый для подготовки цикла.

  Offtopic

  

  Всех с наступающим Новым Годом! Удачи и упорства!

  Дмитрий Петухов,
  MCP, PhD Student, IT-зомби,
  человек с кофеином вместо эритроцитов.