Наверх ▲

Как мы строили Jelastic — облачную платформу (PaaS) нового поколения

Дмитрий Лазаренко Дмитрий Лазаренко Технический директор Российского подразделения Jelastic.

Дмитрий Лазаренко: Всем привет! Меня зовут Дмитрий Лазаренко.

Я технический директор компании Hivext Technologies. Мы занимаемся тем, что строим новую "облачную" платформу Jelastic. До этого я очень много лет занимался проектированием и разработкой enterprise-приложений. Это были различные приложения: BPM, SOA, порталы и даже ERP. Теперь мы делаем "облачную" платформу.

Наверное, не все знают, что такое Jelastic, поэтому постараюсь с помощью нескольких слайдов рассказать о ней.

Jelastic – это новая PaaS-платформа для хостинга приложений, написанных на JAVA. Сейчас у нас есть не только JAVA, но мейнстрим – это JAVA-приложения.

Что мы делаем?

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

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

В чем отличие Jelastic от остальных платформ?

Не знаю, может быть, кто-то пользовался PaaS или IaaS. Сейчас попробую рассказать.

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

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

Особенность JVM в том, что если JVM забирает память у операционной системы, обратно она ее обычно не отдает. Вам, чтобы уменьшить память, придется ее перезапустить. Это не самый приятный процесс. Наша платформа позволяет JVM (фактически, вашему приложению) отдавать память в операционную систему. Вы платите только за фактическое использование памяти. Это очень удобно.

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

Следующая особенность очень важна. Мы даем только стандартные настройки технологий. Вам не нужно переписывать свое приложение, не нужно подстраиваться под чей-то API, под какие-то экзотические базы данных. Мы даем стандартные технологии: JAVA, Tomcat, Jetty, GlassFish (GlassFish у нас в компании просто ругательное слово). Мы предлагаем стандартные базы данных: MySQL, PostgreSQL, MongoDB, и так далее.

Соответственно, у нас нет никакой привязки типа "Vendor Lock-In". Вы можете взять и перенести свое приложение от нас к нашим конкурентам, это будет беспроблемно.

Что еще немаловажно? Мы стремимся к тому, чтобы конечный пользователь не тратил время на изучение документации по настройке системы и работе с ней. Мы также заботимся о том, чтобы он не тратил время на работу в командной консоли, чтобы что-то развернуть. Всегда есть вероятность что-то забыть. Человеческая природа такова, что любой человек что-то забывает. Поэтому мы разработали специальный одностраничный OneClick-интерфейс. Я вам дальше его покажу – это очень удобно.

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

Маркетинговые преимущества

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

На этом маркетинговая часть, наверное, закончится, и начнутся технические вещи.

Начнем с истории

Проект Jelastic стартовал в начале 2011-го года. До него был проект Hivext.

Что он представлял из себя? Это была "облачная" платформа для разработки приложений, похожая на Google OpenDjinn. В ней был онлайн-редактор IDE с  возможностью создания модели данных, с возможностью разработки приложений на JAVA, PHP и серверном JavaScript.

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

В Hivext было много хорошего. Была сервисная шина. Наши разработчики сделали ряд важных сервисов. Был сервис авторизации, прав доступа, сервис доступа к файлам, расписания, сценарии – вещи, которые были очень востребованы. Мы перенесли эти идеи в платформу Jelastic. Сейчас на базе Hivext построен ряд внутренних приложений. Например, сайт jelastic.com, блог Jelastic, Wiki. Панели мониторинга пользователей – это фактически приложения на платформе Hivext. Мы свою же работу используем внутри компании.

Теперь начинается строго техническая часть.

Что представляет собой системная архитектура?

Как я уже говорил, мы перенесли часть сервисов из Hivext в Jelastic. Сервис управления приложениями, сервис прав доступа, управление учетными записями, расписания. Эти сервисы активно используются. Например, когда пользователь появляется на сайте, он проходит через сервис Identity Manager. Также распределение прав доступа к окружениям тоже происходит через внутренние сервисы.

Следующая немаловажная вещь – виртуализация. Как и любая "облачная платформа", мы используем виртуализационный слой. Но в данный момент мы не используем никаких IaaS-прослоек типа CloudStack или OpenStack – когда платформа разрабатывалась, они были еще очень "сырыми". Мы используем работу с гипервизором напрямую. Есть собственная система обеспечения (англ. provisioning), собственная система, которая коллекционирует статистику и проверяет шаблоны виртуальных машин – это отдельные сервисы. Вся архитектура построена на поняти сервиса – это такое соприложение.

Еще у нас есть сервис биллинга, сервис DNS-разрешения и проксирования. Это то, что используется внутри.

Пользователю мы предоставляем сервисы по управлению окружениями. Разрабатывая приложение и размещая его исходный код на GitHub, вы можете компилировать его прямо в "облаке" и развертывать новые версии прямо в "облако". Это наши пользовательские сервисы.

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

Это был краткий обзор архитектуры. В дальнейшем я остановлюсь на важных сервисах, которые как-то интересно работают.

Следующий столп, на котором стоит вся работа Jelastic, – это контейнеры. Контейнеры – это, фактически, аналог виртуальных машин. Мы применяем виртуализацию везде: как для инфраструктурных вещей (так называемые инфраструктурные контейнеры), так для пользовательских контейнеров, с которыми работают конкретные пользователи. А также вводим специальное понятие "Runtime Execution Container" (REC).

Сейчас фактически каждый элемент окружения, например, Tomcat или MySQL – это отдельный виртуальный контейнер. Это обеспечивает нам гибкость в масштабировании. Мы можем гибко распределять эти контейнеры по физическим машинам и очень хорошо масштабировать приложения.

Что еще немаловажно? На одну физическую машину (32 гигабайта RAM и 12 ядер) у нас приходится 500 контейнеров, при этом они работают очень быстро, без "тормозов". Нам хочется предоставить удобный сервис, поэтому количество контейнеров именно такое. В принципе, 256 контейнеров будут идеально работать.

Все контейнеры типизированы. Как я уже говорил, каждый вид ПО, который установлен – это отдельный тип контейнера. Для него есть специальные управляющие скрипты, которые находятся внутри этого контейнера. Ядро управляет этими скриптами по SSH. При этом, естественно, обеспечена безопасность – авторизация по ключам. Для каждого контейнера генерируются свои уникальные ключи, и ядро их "понимает".

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

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

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

Окружения оптимально настроены. Все компоненты окружения "знают" друг о друге все. Если вы создаете окружение с балансировщиком нагрузки, балансировщик "знает" обо всех нодах, на которых ему надо балансировать нагрузку.

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

Еще одна особенность нашей платформы: если на окружение долго не поступают запросы, окружение "засыпает" и "просыпается", если на него поступают новые запросы. У нас есть модуль "awaker", который позволяет пользователю не платить за неиспользуемое приложение, и экономит наши ресурсы.

Как все выглядит со стороны пользователя?

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

Что значит "высокая доступность"?

То, что данные HTTP-сессии будут реплицироваться по разным серверам. Таким образом, если у вас один из них "упадет" (закончилась память по какой-то причине), другой "подхватит" работу, и все данные будут сохранены.

Также у нас есть слой баз данных. В данный момент мы предлагаем около 5 баз данных, и собираемся расширять этот стек.

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

Наша тарификация

Еще один момент – тарификация. Мы ввели специальное понятие "клаудлет". Клаудлет – это единица масштабирования, за которую платит пользователь и которой он манипулирует при выставлении пределов масштабирования своего приложения. Клаудлет эквивалентен 128-ми мегабайтам оперативной памяти и двумстам мегагерцам процессора.

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

Мы дошли до очень интересной вещи. В принципе, все нужные понятия я уже ввел.

Архитектура развертывания

Приложения, сама платформа разворачивается на разных физических машинах. Какие-то части виртуализированы, какие-то нет – это настраивается нашими администраторами. Есть отдельные серверы, на которых установлены пользовательские контейнеры.

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

Запросы разделены: есть запросы на управление самой инфраструктурой, идущие через панель мониторинга пользователя, и есть запросы собственно к приложениям. Эти запросы "раскидываются" специальным компонентом "Resolver". Фактически это бинд с двумя зонами (внешней и внутренней) и nginx, который делает проксирование. Запросы на управление окружениями поступают на внутренний балансировщик ядра и дальше "раскидываются" по экземплярам ядра.

Ядро тоже кластеризовано. Глобальный Resolver также кластеризован. Там есть режим "active/passive keep alive" для обеспечения высокой доступности. Если что-то "упадет", то любой компонент восстанавливается.

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

Дальше начинаются уже интересные вещи. Как мы выбирали систему виртуализации?

Мы около двух месяцев думали, что выбирать. Решений, на самом деле, много, но часть из них коммерческие, часть не очень быстрые, часть с плохим сообществом. Фактически, мы выстроили ряд критериев: скорость, настраиваемость параметров, гибкое управление размером оперативной памяти, процессором и "живая" миграция. Что я имею в виду? То, что вы можете перенести одну виртуальную машину на другой физический сервер, при этом приложение этого "не заметит".

В результате мы выбрали Parallels Virtuozzo Containers. На самом деле, выбрали мы его случайно, но потом поняли все приемущества этого решения. Как известно, основатель "Parallels" – это один из наших инвесторов, поэтому в какой-то степени это был и маркетинговый ход. Но, на самом деле, это решение реально оказалось лучшим для задач JAVA-хостинга.

Почему Virtuozzo?

Потому что у Virtuozzo очень низкие расходы на виртуализацию (например, накладные расходы от 1 % до 3 %) за счет того, что есть одно ядро, и оно очень эффективно управляет всеми виртуальными машинами, при этом эффективно изолируя их друг от друга. По производительности это лучше, чем паравиртуализация. В те времена с паравиртуализацией были проблемы, но даже сейчас наше решение работает лучше.

Чем еще хорошо решение Virtuozzo?

Оно предоставляет хорошие возможности в плане вертикального масштабирования. Память распределяется между виртуальными машинами динамически. В один момент ее больше, в другой момент меньше. Это "больше – меньше" называется "перераспределением памяти по виртуальным машинам" (англ. memory overselling).

Это очень удобно. С помощью такой технологии мы можем запускать на 32-х гигабайтной машине 500-700 контейнеров. При этом они не будут соревноваться в использовании памяти.

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

Одна из важных вещей – оптимальная утилизация дискового пространства. В Virtuozzo (в отличие от OpenVirtuozzo) есть виртуальные файловые системы с защитой дубликации файлов. Фактически все файлы уникальны, и если конкретной операционной системе нужен какой-то файл, используется символическая ссылка. Это очень хорошо экономит дисковое пространство. Плюс, в отличие, например, от аппаратной виртуализации, где либо используются образы, либо VMWare ставится напрямую на LVM-раздел, и образ занимает определенное место. Его очень сложно уменьшить.

Virtuozzo позволяет обходить эту проблему, потому что фактически у вас файлы – одна файловая система, один LVM-раздел или просто раздел. Это файлы – их либо больше, либо меньше. Их можно удалить и выполнять "shring" автоматически.

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

Следующий обещанный раздел – инсталляция и обновления. Предыстория такова. У нас сейчас есть порядка четырех площадок, на каждой из которых размещено порядка 20-ти серверов. Это продакшн-площадки. Есть еще две площадки для разработчиков. Там серверов поменьше, но очень много виртуальных машин. Есть еще эталонная стабилизационная площадка, на которой какие-то важные вещи "обкатываются" перед установкой на продакшн-площадки.

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

Установка занимала несколько дней. Мы могли потратить неделю на установку новой площадки, обновление занимало весь день и всю ночь. Это была головная боль всей команды и особенно администраторов.

Потом мы случайно открыли для себя такую вещь, как Puppet. Расскажу, как мы ее используем.

Как я говорил, есть несколько DEV-площадок, несколько продакшн-площадок и одна тестовая площадка, на которой скрипты и обновления проверяются перед "заливкой" на продакшн. Администраторы, делая какой-то новый функционал на девелоперской площадке (на одной из девелоперских площадок) как-то ее стабилизируют,  потом комитят эту фичу в SVN в формате Puppet.

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

Такой непрерывный процесс, может быть, похож на Continuous Integration, только для администраторов. Каждую ночь с нуля создается площадка Stage, на которой разворачивается актуальная версия из специальной ветки SVN – стабильные скрипты. Далее на этой площадке запускаются автоматические тесты, нагрузочные тесты (реже, чем автоматические) и тесты – стабильности (англ. high variability).

Мы эмулируем ситуации с "выпадением" отдельных нод. Если тесты проходят успешно, происходит обновление продакшн-площадки вручную.

Почему мы предпочитаем обновлять все вручную?

Во-первых, не всем можно давать доступ к продакшн-площадкам. У нас к ним имеют доступ только специальные супер-администраторы – начальники отделов. Человек сознает, что обновляет продакшн-площадку.

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

Есть ряд скриптов, которые создают виртуальные машины с нужными именами (хостнеймами). Далее уже работает Puppet-сервер. Клиенты Puppet на этих виртуальных машинах автоматически соединяются с Puppet-сервером, и уже он ставит туда все, что нужно. Под каждый инфраструктурный контейнер устанавливается нужное ПО, нужные скрипты – он догоняется до нужной конфигурации. Это очень удобно. Теперь мы можем запускать систему новых хостинг-партнеров, не тратя особых усилий.

Следующий секрет – вертикальное масштабирование

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

Чего это нам стоило?

Порядка шести месяцев шли исследования, как правильно это сделать. Были разные решения – например, анализировать текущее потребление памяти. Если оно начинает уменьшается, то как-то сигнализировать наружу JVM… Можно было сигнализировать операционной системе, чтобы она забирала память. Но это было плохое решение.

После создания порядка десяти тестов и общения с Гослингом и с компанией "Oracle" мы нашли решение, которое позволяет отдавать память в операционную систему, по крайней мере, при "сборщике мусора" Serial GC. Но Serial GC старый, медленный и плохо работает на большом объеме памяти.

Потом, когда вышел G1, оказалось, что это решение работает и в нем, правда, есть некоторые ограничения. Мы нашли утечку памяти. В наших тестах память отдавалась, но при этом происходила утечка. Мы вовремя сообщили об этом в "Oracle", и они исправили это, правда, уже в JVM 1.7. В JAVA 1.6 это до сих пор не исправлено – не знаю, будет оно исправлено или нет.

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

Какие хитрые алгоритмы мы используем?

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

Что включает в себя комплексный показатель нагрузки?

Есть такой показатель, как "load average". Он демонстрирует, насколько процессор опережает дисковую подсистему. Есть еще понятия доступной оперативной памяти, используемой оперативной памяти и свободного места на жестких дисках.

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

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

Есть еще очень интересный алгоритм "умной" "живой" миграции окружений. Когда он применяется? Тогда, когда на одном физическом сервере находится, к примеру, 200 виртуальных контейнеров. При этом 10 из них сильно тратят ресурсы процессора, дают высокий показатель "load average". Работает алгоритм, который перемещает на другие физические машины либо активно использующие ресурсы контейнеры, либо наоборот, те контейнеры, которые мало используют ресурсы. Это необходимо, чтобы загрузка стала равномерной. 

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

О наших проблемах

Прежде всего, это высокие нагрузки. Сейчас ядро обрабатывает порядка 15-ти тысяч запросов в секунду. Это достаточно много, по крайней мере, для нас. Мы стараемся, во-первых, кластеризовать все компоненты и избавляться от единых точек отказа. При этом есть схемы "active-active", есть "active-passive", и они работают.

Была еще проблема обработки большого числа статистических данных. В данный момент у нас порядка 12 тысяч клиентов, пользователей, и у каждого пользователя как минимум три виртуальные машины в контейнерах. Получается 36 или 40 тысяч контейнеров – не помню конкретные цифры.

Статистические данные собирались каждые 20 секунд. В начале, когда мы выбирали систему для хранения этих данных, мы использовали MongoDB – это модная технология. Мы "складывали" в MongoDB показатели за каждые 20 секунд. За пару месяцев база в MongoDB выросла до 40 гигабайт, и стали "тормозить" выборки, которые агрегируют статистику и отдают ее под систему биллинга.

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

Следующая проблема - это утечка в JVM. Я уже говорил, что Oracle подправил ошибку, которую мы нашли.

Еще одна проблема связана с виртуальным масштабированием JAVA и JVM в целом. В принципе, сейчас JAVA находится в начальном этапе правильного вертикального масштабирования. Есть компания, которая делает Azul JVM. Если раньше они рекламировали сокращение задержки для JVM, то сейчас они рекламируют виртуальную машину, которая умеет "вверх" и "вниз" масштабироваться. В принципе, только эта компания дает решение "из коробки", но оно, естественно, платное.

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

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

Следующая проблема (я уже упоминал о ней) – это особенности репликации сети для обеспечения высокой доступности. Мы сделали решение, которое работает на всех контейнерах и на всех серверах приложений, доступных JAVA. Есть общее решение, и на него было потрачено очень-очень много времени.

Что мы используем?

Мы взяли стандартный стек технологий. Сама система написана на JAVA, активно используется Spring, Hibernate. У нас есть партнерство с компаниями NGINX и Parallels. Последний логотип – это Hivext. Нашу прошлую платформу мы используем внутри ядра. Также очень активно используем Bash-скриптинг и Perl-скриптинг. Наши администраторы практически гуру – они могут написать на Bash все, что угодно.

О команде

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

В команде сейчас 35 человек: 12 разработчиков, 5 админов (их количество как раз увеличивается), 3 маркетолога. Все работают по Scrum – команда сидит в одном офисе и использует Scrum, у нас четырехнедельные спринты. В принципе, Scrum оправдал свое применение. Раньше была стихийная разработка, сейчас уже три месяца применяем Scrum и видим движение вперед.

Статьи на Хабре у нас пишет очень симпатичная девушка. Мы были очень удивлены, что она пишет статьи и одновременно умеет разбираться в технических деталях: сама разворачивает приложение, настраивает – это круто.

Что мы будем делать дальше, и каковы направления нашего развития?

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

Мы будем расширять стек технологий. Что это означает? Во-первых, мы собираемся поддерживать разные языки. Сейчас есть бета-версия с PHP, будет версия с .NET, Python – уже по порядку и по потребностям пользователей. А также будем расширять предлагаемые технологии. Для той же JAVA, по крайней мере, будут средства распределенного кеширования, будут новые базы данных, возможно, будет Memcached и новые виды контейнеров (g-bios от IBM, возможно, Open GDK или IBM GDK).

Следующее и, наверное, самое важное направление – создание решения для частных "облаков", для крупных enterprise-клиентов, для российского и зарубежного госсекторов. Это основное направление, которым занимается российский офис разработки, - создание решения для частных "облаков" на основе текущей платформы.

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

Вопросы и ответы

Реплика из зала: В самом начале вы сказали, что у вас GlassFish в компании – это слово ругательное. Можно узнать, почему?

Дмитрий Лазаренко: Потому что GlassFish оказался очень тяжелым продуктом и одновременно очень важным. Мы потратили очень много времени, чтобы правильно научиться с ним работать и правильно применять его к платформе. 

Реплика из зала: Если "упадет" приложение или еще что-нибудь, это как-то мониторится?

Дмитрий Лазаренко: В следующей версии будет мониториться, да. Мы будем предоставлять средства мониторинга и оповещения.

Реплика из зала: Масштабирование по горизонтали – это задача клиента, а потом это будет предоставляться?

Дмитрий Лазаренко: Да, да, да. Будет еще автоматическое масштабирование горизонтальное. Сейчас оно фиксировано. Потом оно будет масштабироваться по мере поступления, по мере возрастания нагрузки.

Реплика из зала: Спасибо за доклад. Очень впечатляет, как вы упаковали JVM в ограниченный объем памяти. В связи с этим возникает вопрос, что с SLA? Насколько вы готовы поручиться, что приложение получит, по крайней мере, свою долю ресурсов?

Дмитрий Лазаренко: Я говорил уже, что у нас есть алгоритм миграции: миграции окружений, миграции контейнеров. Есть специальный сервис мониторинга, который отслеживает текущую загрузку и делает так, чтобы приложение гарантированно получало свою долю. Он же переносит контейнеры, которые активно используют память и начинают расти…

Реплика из зала: Хорошо. Тогда каким максимальное время отклика приложения будет? Это миллисекунды, секунды, минуты?

Дмитрий Лазаренко: Сложный вопрос. Мы еще не определились с этим. Это еще зависит все-таки и от "железа". Я говорил, что мы не делаем хостинг. Разные хостеры дают разное "железо" (разные жесткие диски, разное количество оперативной памяти и процессоры), соответственно, тут еще много факторов. 

Реплика из зала: Это действительно сложный вопрос. Спасибо.

Реплика из зала: Здравствуйте. Спасибо за доклад. Какую версию JAVA вы используете?

Дмитрий Лазаренко: 1.6.28 и 1.7 для клиентских приложений.

Реплика из зала: Позволяет ли ваша платформа проводить "горячую" замену кода?

Дмитрий Лазаренко: "Горячую" замену... У нас есть партнерский проект с "JRebel", если вы про это говорите.

Реплика из зала: Да. Кстати, он эстонский. Правильно?

Дмитрий Лазаренко: Да. Мы планируем как раз внедрять его, чтобы можно было осуществлять "горячую" замену. Сейчас вы можете делать несколько версий приложений и менять код динамически, переключаться между старой и новой версией. У вас может быть две версии, вы переключаете домен на другое окружение, и они меняются местами. У вас одновременно могут существовать и старая, и новая версии.

Реплика из зала: Когда вы проводили исследование, рассматривали ли вы технологию OSGi?

Дмитрий Лазаренко: Нет, не рассматривали. Была такая идея, наши советники предлагали OSGi, но пока нет, не применяем.

Реплика из зала: Еще вы упомянули, что используете Scrum. Меня интересует, вы как-то по книжкам это все делаете, или вы тренинги какие-то проходили?

Дмитрий Лазаренко: Scrum – это, в принципе, классическая идеология. Это ежедневные встречи, это какие-то задачи на конкретный этап, период и оценка, понимание того, что сделано, в конце этого периода. У нас классический Scrum без всяких ухищрений пока что.

Реплика из зала: То есть тренингов не было?

Дмитрий Лазаренко: Нет-нет-нет.

Реплика из зала: Отлично! Спасибо.

Дмитрий Лазаренко: Тренинги – это тоже плохое слово?

Реплика из зала: Какие возможности для масштабирования баз данных предоставляет ваша платформа? Есть схема "ведущий-ведомый" (англ. master-slave) для MySQL, может быть, шардинг для MongoDB?

Дмитрий Лазаренко: Мы в следующей версии собираемся это сделать – масштабирование для MySQL, для PostgreSQL.

Реплика из зала: Просто база данных – это очень узкое место.

Дмитрий Лазаренко: Еще у нас есть отдельный проект по масштабированию MySQL, точнее, MariDB, которая сделана на основе MySQL. Есть отдельная команда, которая "распиливает" MySQL под надзором автора MySQL, руководствуясь его рекомендациями. Это будет отдельное решение, которое будет встраиваться в платформу.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Александр Лямин

Александр Лямин

С 2008 года является руководителем Qrator Labs (ранее Highload Lab). Принимал участие в запуске целого ряда российских интернет-провайдеров (Comstar, Teleport TP, Cityline), работал над первой в России мультисервисной ATM-сетью МГУ им. Ломоносова.

Александр Лямин (HighLoad Lab) продолжает раскрывать тему защиты от DDоS-атак доступными средствами.

Александр Титов

Александр Титов

Руководитель отдела системного администрирования в компании Skype.

Доклад специалистов "Skype" об использовании решений Chef и Knife.

Дмитрий Башакин

Дмитрий Башакин

Эксперт, тренер и консультант по управлению проектами, командообразованию, коммуникациям и личной эффективности. Менеджер проектов, продуктов и проектных программ с 12-летним стажем. Эксперт в области продуктовой, заказной и внутренней разработки ПО с 27-летним опытом. С 2003 г.

Говорим о мотивации ярко и жизненно – так, чтобы вы поулыбались, или, может быть, даже посмеялись.