Insight IT

Вакансии: разработчики облачной IaaS платформы в Крок

Иван Блинков — Thu, 19 Sep 2013 19:40:00 +0400

Вакансии более не актуальны

Ведущая российская ИТ-компания ищет талантливых, креативных и энергичных инженеров и разработчиков для развития коммерческой облачной платформы КРОК, предоставляющей услугу типа «Инфраструктура как сервис» (IaaS). В современном высокотехнологичном офисе Вас ждет дружная сплоченная команда профессионалов, занимающаяся разработкой передовой «облачной» платформы, у которой всегда найдется для Вас множество интересных, сложных и разнообразных задач, способных удовлетворить даже самые заоблачные амбиции!

Разработчик на платформе Linux

Обязанности

Проектирование архитектуры компонентов «облачного» решения;
Разработка и интеграция модулей облачной платформы;
Исследования в области распределенных высоконагруженных систем.

Требования

Опыт в области shell-программирования;
Уверенное знание Python, приветствуется знание С++ или Java;
Владение средствами разработки (autotools, git, svn и др.);
Опыт администрирования ОС Linux от 1 года (преимущественно RHEL, CentOS, Debian или SLES);
Опыт работы с технологиями виртуализации (Qemu/KVM, XEN, Hyper-V или VMware);
Знание «облачных» технологий особенно приветствуется.

Инженер по облачным решениям

Обязанности

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

Требования

Навыки администрирования современных ОС GNU/Linux и Windows;
Понимание принципов виртуализации вычислительных ресурсов;
Приветствуется опыт написания сценариев на языках shell и Python;
Личные качества: коммуникабельность, общительность, активная жизненная позиция.

Условия

Конкурентная заработная плата по результатам собеседования;
Возможность профессионального и карьерного роста;
Компания оплачивает обучение и сертификацию;
Социальный пакет (медицинская страховка, бесплатное питание в офисе, спортивные программы и компенсация фитнеса, английский язык);
Компания оказывает помощь при переезде в Москву (оплата стоимости проезда для прохождения собеседований, «подъемные» при выходе на работу).

Куда отправлять резюме?

Вакансии более не актуальны

Архитектура Вконтакте

Иван Блинков — Thu, 28 Oct 2010 21:12:00 +0400

Самая популярная социальная сеть в рунете пролила немного света на то, как же она работает. Представители проекта в лице Павла Дурова и Олега Илларионова на конференции HighLoad++ ответили на шквал вопросов по совершенно разным аспектам работы Вконтакте, в том числе и техническим. Спешу поделиться своим взглядом на архитектуру проекта по результатам данного выступления.

Платформа

Debian Linux - основная операционная система
nginx - балансировка нагрузки
PHP + XCache
Apache + mod_php
memcached
MySQL
Собственная СУБД на C, созданная "лучшими умами" России
node.js - прослойка для реализации XMPP, живет за HAProxy
Изображения отдаются просто с файловой системы xfs
ffmpeg - конвертирование видео

Статистика

95 миллионов учетных записей
40 миллионов активных пользователей во всем мире (сопоставимо с аудиторией интернета в России)
11 миллиардов запросов в день
200 миллионов личных сообщений в день
Видеопоток достигает 160Гбит/с
Более 10 тысяч серверов, из которых только 32 - фронтенды на nginx (количество серверов с Apache неизвестно)
30-40 разработчиков, 2 дизайнера, 5 системных администраторов, много людей в датацентрах
Каждый день выходит из строя около 10 жестких дисков

Архитектура

Общие принципы

Cервера многофункциональны и используются одновременно в нескольких ролях:
- Перебрасывание полуавтоматическое
- Требуется перезапускать daemon'ы
Генерация страниц с новостями (микроблоги) происходит очень похожим образом с Facebook (см. Архитектура Facebook), основное отличие - использование собственной СУБД вместо MySQL
При балансировке нагрузки используются:
- Взвешенный round robin внутри системы
- Разные сервера для разных типов запросов
- Балансировка на уровне ДНС на 32 IP-адреса
Большая часть внутреннего софта написано самостоятельно, в том числе:
- Собственная СУБД (см. ниже)
- Мониторинг с уведомлением по СМС (Павел сам помогал верстать интерфейс :) )
- Автоматическая система тестирования кода
- Анализаторы статистики и логов
Мощные сервера:
- 8-ядерные процессоры Intel (по два на сервер, видимо)
- 64Гб оперативной памяти
- 8 жестких дисков (соответственно скорее всего корпуса 2-3U)
- RAID не используется
- Не брендированные
Вычислительные мощности серверов используются менее, чем на 20%
Сейчас проект расположен в 4 датацентрах в Санкт-Петербурге и Москве, причем:
- Вся основная база данных располагается в одном датацентре в Санкт-Петербурге
- В Московских датацентрах только аудио и видео
- В планах сделать репликацию базы данных в другой датацентр в ленинградской области
CDN на данный момент не используется, но в планах есть
Резервное копирование данных происходит ежедневно и инкрементально

Волшебная база данных на C

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

Разработана "лучшими умами" России, победителями олимпиад и конкурсов топкодер; озвучили даже имена этих "героев" Вконтакте (писал на слух и возможно не всех успел, так что извиняйте):
- Андрей Лопатин
- Николай Дуров
- Арсений Смирнов
- Алексей Левин
Используется в огромном количестве сервисов:
- Личные сообщения
- Сообщения на стенах
- Статусы
- Поиск
- Приватность
- Списки друзей
Нереляционная модель данных
Большинство операций осуществляется в оперативной памяти
Интерфейс доступа представляет собой расширенный протокол memcached, специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса)
Хотели бы сделать из данной системы универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой степени интеграции с остальными сервисами
Кластеризация осуществляется легко
Есть репликация
Если честно, я так и не понял зачем им MySQL с такой штукой - возможно просто как legacy живет со старых времен

Аудио и видео

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

1000-1500 серверов используется для перекодирования видео, на них же оно и хранится.

XMPP

Как известно, некоторое время назад появилась возможность общаться на Вконтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций.

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

Реализован на node.js (выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, а также хороший набор инструментов для реализации задачи)
Работа с большими контакт-листами - у многих пользователей количество друзей на Вконтакте измеряется сотнями и тысячами
Высокая активность смены статусов - люди появляются и исчезают из онлайна чаще, чем в других аналогичных ситуациях
Аватарки передаются в base64
Тесная интеграция с внутренней системой обмена личными сообщениями Вконтакте
60-80 тысяч человек онлайн, в пике - 150 тысяч
HAProxy обрабатывает входящие соединения и используется для балансировки нагрузки и развертывания новых версий
Данные хранятся в MySQL (думали о MongoDB, но передумали)
Сервис работает на 5 серверах разной конфигурации, на каждом из них работает код наnode.js (по 4 процесса на сервер), а на трех самых мощных - еще и MySQL
В node.js большие проблемы с использованием OpenSSL, а также течет память
Группы друзей в XMPP не связаны с группами друзей на сайте - сделано по просьбе пользователей, которые не хотели чтобы их друзья из-за плеча видели в какой группе они находятся

Интеграция со внешними ресурсами

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

Максимальная кроссбраузерность для виджетов на основе библиотек easyXDM и fastXDM
Кросс-постинг статусов в Twitter, реализованный с помощью очередей запросов
Кнопка "поделиться с друзьями", поддерживающая openGraph теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега <title> и атрибутов alt у изображений, чуть ли не побуквенно)
Возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и.т.д.), открыты к интеграции с другими

Интересные факты не по теме

Процесс разработки близок к Agile, с недельными итерациями
Ядро операционной системы модифицированно (на предмет работы с памятью), есть своя пакетная база для Debian
Фотографии загружаются на два жестких диска одного сервера одновременно, после чего создается резервная копия на другом сервере
Есть много доработок над memcached, в.т.ч. для более стабильного и длительного размещения объектов в памяти; есть даже persistent версия
Фотографии не удаляются для минимизации фрагментации
Решения о развитии проекта принимают Павел Дуров и Андрей Рогозов, ответственность за сервисы - на них и на реализовавшем его разработчике
Павел Дуров откладывал деньги на хостинг с 1 курса :)

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

В целом Вконтакте развивается в сторону увеличения скорости распространения информацию внутри сети. Приоритеты поменялись в этом направлении достаточно недавно, этим обусловлено, например, перенос выхода почтового сервиса Вконтакте, о котором очень активно говорили когда появилась возможность забивать себе текстовые URL вроде vkontakte.ru/ivan.blinkov. Сейчас этот подпроект имеет низкий приоритет и ждет своего часа, когда они смогут предложить что-то более удобное и быстрое, чем Gmail.

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

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

Если хотите быть в курсе новых веяний в сфере масштабируемости высоконагруженных интернет-проектов - по традиции рекомендую подписаться на RSS.

Amazon Web Services

Иван Блинков — Mon, 28 Jul 2008 20:35:00 +0400

Если Вы уже успели прочитать статью про архитектуру Amazon, то Вы уже знаете, что этот проект активно использует сервис-ориентированную архитектуру для максимально эффективной организации взаимодействия между всеми подпроектами. Этот подход используется практически во всех начинаниях Amazon и во многом благодаря ему они выпустили в свет групу сервисов под общим названием Amazon Web Services. Идея их достаточно проста: они предоставляют практически все необходимое для запуска веб-проектов абсолютно произвольной направленности и практически неограниченных масштабов. Причем они старались учесть все возможные потребности потребителей и именно по-этому сервисов в эту группу входит четыре:

Elastic Cloud 2: "Практически любой высоконагруженный сервис требует внушительных вычислительных мощностей" - вполне закономерное высказывание, именно проблемы с ним связанные и призван решить данный сервис. Сервис предоставляет в распоряжение пользователей виртуальные машины сопоставимые по производительности с "железными" серверами в считанные минуты, причем имеется возможность настраивать изначальный набор программного обеспечения и конфигурацию виртуального оборудования. Размещаемые на таких виртуальных машинах сервисы могут наращивать вычислительные мощности существенно быстрее по сравнению с использованием dedicated или colocation хостинга.
Simple Storage Service: Этот сервис по сути представляет собой "бездонное" хранилище для произвольных файлов. Функционал достаточно прост: положить, забрать, удалить. Доступ возможен с использованием нескольких предоставляемых интерфейсов, а доступ к файлам может быть ограничен. Казалось бы ничего особенного, но во многих интернет-проектах такая возможность может оказаться полезной.
SimpleDB: Позиционируется как сервис для предоставления доступа к структурированным данным. С точки зрения разработчика проще охарактеризовать его как нереляционную базу данных. Схема данных генерируется в процессе эксплуатирования сервиса - заранее ее указывать не нужно, а запросы в какой-то степени напоминают сильно ограниченный SQL с возможностью только самых примитивных операций: сравнение, объединение, пересечение и т.п. У этой системы есть несколько аналогов, среди них Apache HBase и Hypertable.
Simple Queue Service: Более экзотический сервис - предоставляет возможность создания распределенных очередей сообщений для обеспечения взаимодействия других компонентов системы, которые предполагается, что будут размещены в Amazon EC2. Далеко не всем веб-проектам такая функциональность нужна, но если она все же понадобится - этот сервис здорово упростит жизнь разработчикам.

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

Знакомство было не долгим - всего пару недель, да и поиграться удалось по большей части лишь с Amazon EC2 и совсем чуть-чуть с S3. Первое впечатление произвел их Getting Started Guide - все просто и лаконично, еще даже до получения доступа к сервису у меня сложилось четкое представление о том, как он работает - несомненный плюс. После получения всех необходимых ключей от аккаунта (их было несколько, запутаться достаточно легко, но документация всегда спасала) можно сразу же приступать к работе с сервисом, скачав набор консольных утилит. Первым делом стоит взглянуть на ассортимент предоставляемых операционных систем для установки на будущие виртуальные машины - на первый взгляд представлены все популярные дистрибутивы Linux, что в общем-то более, чем достаточно (но при более детальном рассмотрении это оказалось далеко не так: различается в них только набор программного обеспечения, а ядро везде одно и то же - от Fedora 8). Так что выбор предстоит хоть и непростой, но скорее его стоит основывать его на личном предпочтении и удобстве, а не на каких-то других соображениях - разница в итоге будет невелика. Я лично остановил свой выбор на Debian Etch - не знаю по каким соображениям, да и не важно это вовсе, как впоследствии оказалось. Сделав свой выбор и подождав буквально несколько секунд можно узнать по какому URL располагается свежесозданная виртуальная машина (хочется отметить, что у утилиты их создания есть параметр "количество", то есть создавать их можно целыми пачками).

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

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

На закуску я оставил ложку дегтя - их ценовую политику. За пару недель достаточно неактивного, "ознакомительного" использования счет легко достиг отметки в пятьсот долларов. EC2 тарифицируется по часам - от 10 до 80 центов в час за виртуальную машину плюс трафик (более детально можно посмотреть на все том же официальном сайте). Там же и указаны гарантируемые вычислительные мощности и объем дискового пространства и оперативной памяти. На практике же все остальные параметры системы (пропускная способность сетевых интерфейсов, скорость чтения/записи на диски и так далее) делятся между всеми виртуальными машинами, располагаемыми на одной физической и по большей части это происходит по принципу "как повезет", хотя наблюдаются и некоторые закономерности: узлам за 40-80 центов/час дается явный приоритет при доступе к дискам (что, впрочем, упоминается в их Developer Guide), но, как оказалось, приоритет этот настолько высок, что скорость записи отличается между ними более чем на порядок - в 15-20 раз, такое вот несколько удивительное наблюдение. Интернет-канал же тоже делится - ограничения сверху достичь не удалось, но есть предположение, что в сумме "на всех" он равен гигабиту на физическую машину.

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

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

Архитектура LiveJournal

Иван Блинков — Thu, 10 Apr 2008 00:24:00 +0400

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

Источники информации

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

Основным источником информации послужила презентация Brad Fitzpatrick в Токио.

Платформа

Linux (Debian Sarge)
Perl
Apache
MySQL 4.0/4.1 в основном с InnoDB
Perlbal, веб-сервер и балансировщик нагрузки
memcached для распределенного кэширования
MogileFS, распределенная файловая система
Gearman
TheShwartz
djabberd

Статистика

на данный момент 15320315 учетных записей; (10.04.08)
из них активно используется 551589;
наиболее активно сервис используется в США и Российской федерации, а 2/3 пользователей - девушки и женщины;
более 15 миллионов новых записей в блогах за месяц;
более 50 миллионов просмотров страниц в день, при пиковой нагрузке - несколько тысяч в секунду (сильно устаревшие цифры, 2004 год);
связь с внешним миром осуществляется через два BIG-IP (активный + в режиме ожидания) с автоматическим восстановлением работоспособности в случае сбоя в работе одного из них, защитой от DDoS, L7 набором правил, включая TCL;
более сотни серверов, насчет конфигурации известен только тот факт, что практически на каждом сервере установлены огромные объемы оперативной памяти (более 12 GB) для эффективного кэширования.

История

Все началось с одного обычного сервера. Он выполнял роль как веб-сервера так и базы данных. Единственный плюс такого подхода к организации работы оборудования - достаточно дешево. Само собой достаточно скоро этот сервер перестал справляться с нагрузкой.
Следующим шагом было разнесение веб-сервера и базы данных на разные серверы, всего их получилось два. По прежнему имелось два узла, сбой в которых означал недоступность сервиса. По прежнему вычислительная мощность такой системы оставалась более чем скромной.
Первым из тех двух серверов, как ни странно, перестал справляться с нагрузкой веб-сервер - докупили еще два. Веб-сервера три, внешний IP - один, теперь приходится как-то распределять нагрузку! А как добавить еще одну базу данных?
Новый сервер баз данных был подключен в роли slave к исходному, данные в нем обновлялись с помощью репликации, а обрабатывал он только операции чтения, оставив все операции записи первому серверу.
Есть предположения о том, к чему привело дальнейшее добавление новых серверов? Правильно - к полнейшему хаосу! Со временем стала возникать проблема масштабируемости баз данных. Операции чтения производились на каком-то одном сервере, но когда приходил запрос на запись данных, так или иначе данные приходилось производить обновление на каждом из slave серверов. В итоге выполнение синхронизации данных стало занимать подавляющее большинство процессорного времени slave серверов, что привело к отсутствию возможности продолжать масштабирование просто добавлением дополнительных серверов.
Пришло время задуматься над архитектурой системы и распределением операций записи. Основной целью стало избавиться от такой серьезной избыточности данных, так как это было практически пустой тратой времени копировать одни и те же данные на десяток машин, да еще и с RAID на каждой из них.

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

Применительно к LiveJournal эту схему лучше всего демонстрирует один из слайдов презентации, указанной в источниках информации:

При работе такой системы не используется auto_increment в MySQL, а также используется составной primary key из номера пользователя и номера записи. Таким образом пространство имен объектов разбито на группы, соответствующие конкретному пользователю.

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

Программное обеспечение

В ситуации, когда не удавалось найти готового программного решения для какой-то конкретной задачи, они не боялись взяться за написание его самостоятельно, это стало одним из основных компонентов успеха проекта. Существенная часть программной платформы LiveJournal написана специально для этого проекта и выпущено под свободной лицензией с открытым исходным кодом, доступным в официальном SVN репозитории.

memcached

Залогом быстрой загрузки любой страницы крупного интернет-проекта является кэширование. Но как всегда возникает вопрос: а на каком уровне обработки данных его стоит выполнять? Для динамических страниц недопустимо кэширование на уровне готовых страниц. Можно кэшировать на уровне mod_perl, но по сути это пустая трата оперативной памяти, так как создастся отдельный кэш для каждого потока Apache, и количество промахов мимо кэша будет огромно. Кэширование запросов MySQL или HEAP таблицы также не дали бы требуемого результата ввиду чрезвычайной распределенности базы данных.

Выходом из сложившейся ситуации стало написание собственной распределенной системы кэширования объектов, получившей название memcached. Она позволяет:

использовать для кэширования свободную оперативную память практически любого компьютера, задействованного в системе;
кэшировать объекты практически любого языка программирования в сериализованном виде: Perl, PHP, Java, C++ и так далее;
использовать для передачи кэшируемых данных простой протокол, не требующий избыточности данных;
избегать даже теоретической возможности полного сбоя работы кэшируещей системы в связи с полной равнозначностью серверов;
достигать превосходной производительности при формировании HTML-кода страниц;
в разы снизить нагрузку на базы данных в проекте любого масштаба.

Этот продукт на практике оказался более чем эффективен, о чем свидетельствует его более чем успешное использование во многих крупнейших веб-проектах.

Perlbal

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

быстрый;
небольшой размер;
"сообразительный";
обработка "мертвых" узлов;
может выступать как в роли reverse proxy, так и балансировщика нагрузки;
базовый функционал классического веб-сервера;
реализация внутреннего перенаправления данных;
поддержка некоторых менее существенных трюков, реализованных обычно в виде plug-in'ов.

Perlbal не так активно используется вне LiveJournal, по сравнению с memcached, но для решения конкретной задачи он подошел как нельзя лучше.

MogileFS

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

Как и все файловые системы этого класса, MogileFS работает на уровне пользовательских приложений и использует достаточно тривиальные протокол передачи данных и общую архитектуру: клиенты, управляющие серверы, абстрактные базы данных, сервера для хранения самих данных - в этом плане ничего нового придумано не было. Доступ к файлам осуществляется с помощью HTTP-запросов PUT/GET либо через виртуальный NFS-раздел. Единственной особенностью можно назвать уклон в построение собой абстрактной прослойки между приложением и собственно кластером базы данных (в случае LiveJournal - сегмента), используемой в роли альтернативы более тривиальной master/slave схемы.

Gearman

Gearman по сути прост до безобразия, но это не мешает ему быть чрезвычайно эффективным. Возможно Вы уже догадались в чем суть этого еще одного продукта, написанного специально для LJ, если уже навели курсор на акроним в начале этого абзаца, если же нет - поясню: он управляет общей работой системы средствами клиент-серверной архитектуры и высокопроизводительного бинарного протокола. С их помощью он способен удаленно вызывать практически любые процедуры на удаленных серверах с минимальными задержками во времени. Казалось бы ничего особенного он сам по себе не делает, но на самом деле он выполняет очень важную функцию: увеличивает степень параллельности выполнения операций, необходимых для полноценного функционирования проекта. Единственное но в работе этого механизма заключается в том, что он не предоставляет никаких гарантий успешности выполнения работ.

В рамках LiveJournal Gearman применяется в основном для:

обработка изображений средствами Image::Magick вне perl-приложений;
создание pool'а DBI соединений (DBD::Gofer + Gearman);
уменьшением нагрузки, создаваемой отдельными компонентами системы;
улучшения субъективного впечатления пользователей о быстродействии сервиса, благодаря выполнению части работ параллельно в фоновом режиме;
выполнение блокирующего ресурсы кода отдельно от обработчиков различных событий.

TheShwartz

В качестве альтернативы gearman'у для работ, для выполнения которых необходимы некоторые гарантии успешности, а также некоторая стабильность, была разработана эта библиотека. Общая схема работы осталась та же: клиент-серверная, но за стабильность приходится платить - производительность существенно ниже, возможно возникновение задержек.

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

Основными сферами применения TheShwartz в LJ являются:

отправка электронной почты (SMTP клиент);
LJ Notifications: каждое событие может вызывать за собой цепочку из тысяч уведомлений по электронной почте, SMS, XMPP и так далее;
отправка RPC сообщений внешним сервисам;
внедрение Atom потоков;

djabberd

Как всегда следуя принципу "чем проще - тем лучше", разработки LJ написали этот крошечный daemon, лежащий в основе их Jabber/LJTalk. Он способен спокойно работать с более чем 300 тысячами соединений, используя очень скромное количество оперативной памяти для поддержания каждого соединения.

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

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

Если перед Вами появилась нетривиальная задача - не бойтесь написать программное обеспечение для ее решения самостоятельно! Пускай, возможно, это потребует некторых дополнительных усилий, но масса преимуществ, связанных с полным соответствием требованиям конкретного проекта, превосходит все издержки дополнительной разработки.
Невозможно масштабировать проект просто постоянно добавляя новые сервера, рано или поздно все же прийдется задуматься об его архитектуре;
Распределение нагрузок и параллельное операций порой заслуживают того, чтобы разработчики обратили на них внимание;
"Мы ненавидим изобретать колесо! Но тем не менее, если колесо не существует или оно квадратное, то мы не боимся изобретать круглое колесо." (с)