Andy Melnikov (nponeccop) wrote,
Andy Melnikov
nponeccop

Lightweight, portable, self-tuning, HA, streaming and caching mapreduce over WAN with backpressure

Делаю я тут хуёвину, но что-то задолбался на говне и палках, хочется переложить аппликейшен-независимую часть на миддлваре и заопенсорсить оное миддлваре, если такого ещё нет. По сути - мапредьюс с блекджеком и шлюхами, можно рассматривать как высокоуровневую message queue. Итак.

type WorkUnit = (WUID, [Request])
type WorkUnitResponse = (WUID, [Response])

Мне шлют ворк-юниты, я отсылаю обратно респонсы на них в произвольном порядке. Надо обеспечить, чтобы на все присланные юниты были максимально быстро отосланы ответы. WUID играет роль ключа в хадуповском смысле мапредьюса, т.е. я пишу маппер и группировщик по ключам.

Запросы а ля DNS - рекурсивные (из ответов на запросы собираются подзапросы) и с кешированием ответов на предыдущие подзапросы.

Система состоит из двух частей: условных датацентра и клауда.

В клауде сидят сервера, на серверах сидят воркеры, делающие из подзапросов ответы. В датацентре сидят резолвер, шедулер и дц-воркеры. Шедулер распихивает присылаемые ворк-юниты по дц-воркерам. Дц-воркеры сплитят ворк-юниты на запросы, отсылают запросы резолверу, получают ответы, джойнят их и отправляют обратно шедулеру. Все компоненты параллельные внутри.
Хочется максимально упростить части, связанные с распараллеливанием, обнаружением отказов и отказоустойчивостью. Т.е. чтобы надо было только последовательные части писать, а остальное брал на себя аппликейшен сервер. Если все пункты из заголовка убрать - то подойдёт хадуп, т.е. задача по идее должна быть уже решена.
Lightweight - must have
Если миддлваре на любом из узлов жрет более 100 метров ОЗУ без нагрузки - то его писали имбецилы, которым доверия нет и в других вещах. Т.е 50м пусть жрет + 50м gc slack.
Portable - must have
Должна быть возможность работы из трех языков и двух ОС без существенных тормозов. С++, Perl, Node.js, Haskell, Linux, Windows. Thrift, например, обеспечивает.
Self-tuning - желательно
Automatic control: sensors, controllers, actuators. Self-tuning - expectations, measurement, analysis, and actions. Вот это всё. Актуаторы регулируют степень паралеллизма и таймауты на разных уровнях (в т. ч. эластичностью), сенсоры репортят нагрузку, производительность и отказы, контроллеры подбирают параметры для оптмизации затрат и производительности. Полная автоматизация не нужна, скорее некий фреймворк для экспериментирования с параметрами и анализа зависимостей.
Highly available - must have
Возможность писать в стиле fail fast. Например, воркер может терять запросы. По таймату это обнаружится как отказ, потерявший запрос воркер будет перепущен, а запросы перешедулены.
Streaming - must have
В процессе работы над ворк-юнитами могут прийти новые, и их надо тут же пустить в работу, по возможности обеспечив fairness разным источникам ворк-юнитов, чтобы если кто-то насрал ворк-юнитов на неделю вперёд, вновь приходящие юниты не ждали неделю, а перемешивались.
Сaching - желательно
Cамонастраивающийся кеш был бы плюсом. Пример: кеши на дц-воркерах снижают нагрузку на кеш в резолвере, но при слишком большом кеше воркерам приходится снижать свой паралеллизм./dd>
Mapreduce - желательно
Реализовывать mapreduce поверх просто мессаджинга - утомительно.
Over WAN - must have
Два аспекта: а) не должно быть говнокоординаторов, торчащих голой жопой в инете. Слушающие порты только на клауд-воркерах. б) Не должно генерироваться много служебного трафика, везде должны быть очереди размером в bandwidth-latency product и т.п.
With backpressure - must have
Надо, чтобы автоматически выдерживался режим "у компонента Х должно быть всегда У запросов в асинхронной обработке", и сам компонент за этим не следил.
Subscribe

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 2 comments