NGINX изнутри: рожден для производительности и масштабирования
NGINX вполне заслуженно является одним из лучших по производительности серверов, и всё это благодаря его внутреннему устройству. В то время, как многие веб-серверы и серверы приложений используют простую многопоточную модель, NGINX выделяется из общей массы своей нетривиальной событийной архитектурой, которая позволяет ему с легкостью масштабироваться до сотен тысяч параллельных соединений.
Инфографика Inside NGINX сверху вниз проведет вас по азам устройства процессов к иллюстрации того, как NGINX обрабатывает множество соединений в одном процессе. Данная статья рассмотрит всё это чуть более детально.
Подготавливаем сцену: модель NGINX процессов
Чтобы лучше представлять устройство, сперва необходимо понять как NGINX запускается. У NGINX есть один мастер-процесс (который от имени суперпользователя выполняет такие операции, как чтение конфигурации и открытие портов), а также некоторое количество рабочих и вспомогательных процессов.
На 4-х ядерном сервере мастер-процесс NGINX создает 4 рабочих процесса и пару вспомогательных кэш-процессов, которые управляют содержимым кэша на жестком диске.
Почему архитектура всё же важна?
Одна из фундаментальных основ любого Unix-приложения — это процесс или поток (с точки зрения ядра Linux процессы и потоки практически одно и то же — вся разница в разделении адресного пространства). Процесс или поток — это самодостаточный набор инструкций, который операционная система может запланировать для выполнения на ядре процессора. Большинство сложных приложений параллельно запускают множество процессов или потоков по двум причинам:
Наиболее типичный подход к построению сетевого приложения — это выделять для каждого соединения отдельный процесс или поток. Такая архитектура проста для понимания и легка в реализации, но при этом плохо масштабируется когда приложению приходится работать с тысячами соединений одновременно.
Как же работает NGINX?
NGINX использует модель с фиксированным числом процессов, которая наиболее эффективно задействует доступные ресурсы системы:
Когда NGINX находится под нагрузкой, то в основном заняты рабочие процессы. Каждый из них обрабатывает множество соединений в неблокирующемся режиме, минимизируя количество переключений контекста.
Каждый рабочий процесс однопоточен и работает независимо, принимая новые соединения и обрабатывая их. Процессы взаимодействуют друг с другом используя разделяемую память для данных кэша, сессий и других общих ресурсов.
Внутри рабочего процесса
Каждый рабочий процесс NGINX инициализируется с заданной конфигурацией и набором слушающих сокетов, унаследованных от мастер-процесса.
Рабочие процессы начинают с ожидания событий на слушающих сокетах (см. также accept_mutex и разделяемые сокеты). События извещают о новых соединениях. Эти соединения попадают в конечный автомат — наиболее часто используемый предназначен для обработки HTTP, но NGINX также содержит конечные автоматы для обработки потоков TCP трафика (модуль stream) и целого ряда протоколов электронной почты (SMTP, IMAP и POP3).
Конечный автомат в NGINX по своей сути является набором инструкций для обработки запроса. Большинство веб-серверов выполняют такую же функцию, но разница кроется в реализации.
Устройство конечного автомата
Конечный автомат можно представить себе в виде правил для игры в шахматы. Каждая HTTP транзакция — это шахматная партия. С одной стороны шахматной доски веб-сервер — гроссмейстер, который принимает решения очень быстро. На другой стороне — удаленный клиент, браузер, который запрашивает сайт или приложение по относительно медленной сети.
Как бы то ни было, правила игры могут быть очень сложными. Например, веб-серверу может потребоваться взаимодействовать с другими ресурсами (проксировать запросы на бэкенд) или обращаться к серверу аутентификации. Сторонние модули способны ещё сильнее усложнить обработку.
Блокирующийся конечный автомат
Вспомните наше определение процесса или потока, как самодостаточного набора инструкций, выполнение которых операционная система может назначать на конкретное ядро процессора. Большинство веб-серверов и веб-приложений используют модель, в которой для «игры в шахматы» приходится по одному процессу или потоку на соединение. Каждый процесс или поток содержит инструкции, чтобы сыграть одну партию до конца. Все это время процесс, выполняясь на сервере, проводит большую часть времени заблокированным в ожидании следующего хода от клиента.
NGINX, как настоящий Гроссмейстер
Вероятно вы слышали о сеансах одновременной игры, когда один гроссмейстер играет на множестве шахматных полей сразу с десятками противников?
Кирил Георгиев на турнире в Болгарии сыграл параллельно 360 партий. Его итоговый результат составил: 284 победы, 70 вничью и 6 поражений.
Таким же образом рабочий процесс NGINX «играет в шахматы». Каждый рабочий процесс (помните — обычно всего один на вычислительное ядро) является гроссмейстером, способным играть сотни (а на самом деле сотни тысяч) партий одновременно.
Почему так получается быстрее, чем блокирующаяся многопоточная архитектура?
Каждое новое соединение создает файловый дескриптор и потребляет небольшой объем памяти в рабочем процессе. Это очень малые накладные расходы на соединение. Процессы NGINX могут оставаться привязанными к конкретным ядрам процессора. Переключения контекста происходят достаточно редко и в основном когда не осталось больше работы.
В блокирующемся подходе, с отдельным процессом на каждое соединение, требуется сравнительно большой объем дополнительных ресурсов, и переключения контекста с одного процесса на другой происходят гораздо чаще.
Дополнительную информацию по теме можно также узнать из статьи об архитектуре NGINX от Андрея Алексеева, вице-президента по развитию и сооснователя компании NGINX, Inc.
С адекватной настройкой системы, NGINX прекрасно масштабируется до многих сотен тысяч параллельных HTTP cоединений на каждый рабочий процесс и уверенно поглощает всплески трафика (толпы новых игроков).
Обновление конфигурации и исполняемого кода
Архитектура NGINX с малым количеством рабочих процессов позволяет достаточно эффективно обновлять конфигурацию и даже его собственный исполняемый код на лету.
Обновление конфигурации NGINX — очень простая, легковесная и надежная процедура. Она заключается в простой отправке мастер-процессу сигнала SIGHUP.
Обновление исполняемого кода NGINX — это Святой Грааль высокой доступности сервисов. Вы можете обновлять сервер на лету, без потери соединений, простоя ресурсов и каких-либо перерывов в обслуживании клиентов.
Процесс обновления исполняемого кода использует схожий с перезагрузкой конфигурации подход. Новый мастер-процесс NGINX запускается параллельно со старым и получает от него дескрипторы слушающих сокетов. Оба процесса загружены и их рабочие процессы обрабатывают трафик. Затем вы можете отдать команду старому мастер-процессу на плавное завершение.
Вся процедура подробно описана в документации.
Подведем итоги
Мы дали поверхностный обзор того, как функционирует NGINX. Под этими простыми описаниями скрывается более чем десятилетний опыт разработки и оптимизации, который позволяет NGINX демонстрировать выдающуюся производительность на широком спектре оборудования и реальных задачах, оставаясь надежным и безопасным, как того требуют современные веб-приложения.
Если вы хотите узнать больше по данной теме, то рекомендуем для ознакомления:
Национальная библиотека им. Н. Э. Баумана Bauman National Library
Персональные инструменты
nginx
nginx
64px
Создатели:
Игорь Сысоев
Разработчики:
NGINX, Inc и Игорь Сысоев
Выпущена:
4 October 2004 года ; 17 years ago ( 2004-10-04 )
Постоянный выпуск:
1.11.0 / 24 May 2016 года ; 5 years ago ( 2016-05-24 )
Состояние разработки:
активное
Написана на:
C
Операционная система:
Unix-подобные операционные системы,
nginx (engine x) — HTTP-сервер и почтовый прокси-сервер, поддерживаемый UNIX-подобными операционными системами. Игорь Сысоев начал разрабатывать nginx с 2002 года. Изначально проект предназначался для серверов компании Rambler, впоследствии стал использоваться на других серверах. Релиз вышел в 2004 году, и он был в открытом доступе. В настоящее время nginx используется на 6,75% всех существующих доменов по рейтингу Netcraft.
Содержание
Архитектура и масштабируемость сервера nginx
Рабочие процессы в Nginx одновременно обслуживают множество соединений, обеспечивая их вызовами ОС (операционной системы) epoll (Linux), select и kqueue (FreeBSD). Данные, полученные от клиента, разбираются посредством конечного автомата. Обработку разобранного запроса осуществляет цепочка модулей, задаваемая конфигурацией. Формирование ответа клиенту происходит в буферах, которые могут указывать на отрезок файла или хранить данные в памяти. Последовательность передачи данных клиенту определяется цепочками, в которые группируются буферы. В структурном отношении HTTP-сервер Nginx разделён на виртуальные серверы, которые в свою очередь делятся на location. Виртуальному серверу или директиве можно задать порты и адреса для приёма соединений. Для location можно задать точный URI, часть URI, или регулярное выражение.Для оперативного управления памятью служат пулы, являющиеся последовательностью заранее выбранных блоков памяти. Один блок, выделяемый изначально под пул, имеет длину от 1 до 16 килобайт. Он разделён на области – занятую и незанятую. По мере заполнения последней выделение нового объекта обеспечивается образованием нового блока.
Преимущества nginx
nginx считается очень быстрым HTTP сервером. Вместо Apache или совместно с ним Nginx используют, чтобы ускорить обработку запросов и уменьшить нагрузку на сервер. Дело в том, что огромные возможности, заложенные модульной архитектурой Apache, большинству пользователей не требуются. Платить же за эту невостребованную функциональность приходится значительным расходом системных ресурсов. Для обычных сайтов, как правило, характерно явное «засилье» статичных файлов (изображений, файлов стилей, JavaScript), а не скриптов. Никакого специального функционала для передачи этих файлов посетителю ресурса не требуется, так как задача весьма проста. А, значит, и веб-сервер для обработки таких запросов должен быть простым и легковесным, как Nginx. Географическая классификация клиентов по их IP-адресу производится в nginx посредством специального модуля. Система Radix tree позволяет оперативно работать с IP-адресами, занимая минимум памяти.
Функции nginx
Nginx получил большую известность за счет своей высокой производительности, простой конфигурации, надежности и стабильности, а также достаточного набора функций.
nginx в качестве HTTP-сервера
nginx в качестве почтового прокси-сервера
Установка nginx
Установка nginx в СentOS
Из-под привилегированного пользователя мы отдаем команду
После установки вводим команду для запуска
Можно включить дополнительный сервис в автозагрузку
Установка nginx в Ubuntu
Из-под привилегированного пользователя мы отдаем команду
Включаем сервис, когда он установится в систему
Установка nginx в FreeBSD
Устанавливаем из портов
Установка nginx в Windows
Если nginx не запустился, нужно смотреть причины в error_log. Если же error_log не создался, то об этом сообщается в Event Log. В настоящее время данное ПО не работает в Windows как сервис.
Способы применения nginx
На отдельному порту/IP
Если ресурс насыщен изображениями или файлами для скачивания nginx можно настроить на отдельном порту или же IP и раздавать через него статичный контент. Чтобы это реализовать, нужно поменять некоторые ссылки на сайте. При большом количестве запросов к статичным файлам целесообразно создать отдельный сервер и установить на нем nginx.
Акселерированное проксирование
При акселерированном проксировании все посетительские запросы поступают к nginx. Запросы на получение статичных файлов (например, картинки, простого HTML, JavaScript или CSS-файла) Nginx обрабатывает самостоятельно. В случае обращения пользователя к тому или иному скрипту он переадресует запрос в ведомство Apache. Код сайта при этом остается неизменным.
Ошибки nginx и их устранение
502 Bad Gateway
Ошибка означает, что NGINX не может получить ответ от одного из сервисов на сервере. Часто она появляется, когда NGINX работает в связке с Apache, Varnish, Memcached или иным сервисом, а также обрабатывает запросы PHP-FPM. Как правило, проблема возникает из-за отключенного сервиса (в этом случае нужно проверить состояние напарника и при необходимости перезапустить его) либо, если они находятся на разныхn серверах, проверить пинг между ними, так как, возможно, отсутствует связь между ними. Также, для PHP-FPM нужно проверить права доступа к сокету. Для этого убедитесь, что в
прописаны правильные права
504 Gateway Time-out
Ошибка означает, что nginx долгое время не может получить ответ от какого-то сервиса. Такое происходит, если сервис, с которым nginx работает в связке, отдаёт ответ слишком медленно. Проблему можно устранить с помощью увеличения времени таймаута. При работе в связке NGINX+Apache в конфигурационный файл можно внести изменения
413 Request Entity Too Large
и заменить значение на нужное. Например, мы увеличим размер загружаемых файлов до 100 Мб.
nginx (англ. engine x) (по-русски произносится как э́нджин-и́кс [4] [5] ) — веб-сервер и почтовый прокси-сервер, работающий на Unix-подобных операционных системах (тестировалась сборка и работа на FreeBSD, OpenBSD, Linux, Solaris, Mac OS X, AIX и HP-UX). Начиная с версии 0.7.52 появилась бинарная сборка под Microsoft Windows.
Содержание
Основные функции
nginx — простой, быстрый и надёжный сервер, не перегруженный функциями. Применение nginx целесообразно прежде всего для статических веб-сайтов и как прокси-сервера перед динамическими сайтами. [источник не указан 151 день]
HTTP-сервер
SMTP/IMAP/POP3-прокси сервер
Архитектура
В nginx рабочие процессы обслуживают одновременно множество соединений, мультиплексируя их вызовами операционной системы select, epoll (Linux) и kqueue (FreeBSD). Рабочие процессы выполняют цикл обработки событий от дескрипторов (см. Событийно-ориентированное программирование). Полученные от клиента данные разбираются с помощью конечного автомата. Разобранный запрос последовательно обрабатывается цепочкой модулей, задаваемой конфигурацией. Ответ клиенту формируется в буферах, которые хранят данные либо в памяти, либо указывают на отрезок файла. Буферы объединяются в цепочки, определяющие последовательность, в которой данные будут переданы клиенту. Если операционная система поддерживает эффективные операции ввода-вывода, такие как writev и sendfile, то nginx применяет их по возможности.
Конфигурация HTTP-сервера nginx разделяется на виртуальные серверы (директива server). Виртуальные серверы разделяются на location’ы (location). Для виртуального сервера возможно задать адреса и порты, на которых будут приниматься соединения, а также имена, которые могут включать * для обозначения произвольной последовательности в первой и последней части, либо задаваться регулярным выражением.
location’ы могут задаваться точным URI, частью URI, либо регулярным выражением. location’ы могут быть сконфигурированы для обслуживания запросов из статического файла, проксирования на fastcgi/memcached сервер.
Для эффективного управления памятью nginx использует пулы. Пул — это последовательность предварительно выделенных блоков динамической памяти. Длина блока варьируется от 1 до 16 килобайт. Изначально под пул выделяется только один блок. Блок разделяется на занятую область и незанятую. Выделение мелких объектов выполняется путём продвижения указателя на незанятую область с учётом выравнивания. Если незанятой области во всех блоках не хватает для выделения нового объекта, то выделяется новый блок. Если размер выделяемого объекта превышает значение константы NGX_MAX_ALLOC_FROM_POOL, либо длину блока, то он полностью выделяется из кучи.
Таким образом, мелкие объекты выделяются очень быстро и имеют накладные расходы только на выравнивание.
nginx содержит модуль географической классификации клиентов по IP-адресу. В его основу входит база данных соответствия IP-адресов географическому региону, представленная в виде Radix tree (сжатое префиксное дерево или сжатый бор) в оперативной памяти. nginx предварительно распределяет первые несколько уровней дерева, таким образом, чтобы они занимали ровно 1 страницу памяти. Это гарантирует, что при поиске IP-адреса для первых нескольких узлов при трансляции адреса всегда найдётся запись в TLB.
Игорь Сысоев, разработчик веб-сервера nginx, член большой семьи HighLoad++, не просто стоял у истоков нашей конференции. Я воспринимаю Игоря как своего профессионального учителя, мастера, который научил меня работать и понимать высоконагруженные системы, что на десятилетие определило мой профессиональный путь.
Естественно, я не мог пройти мимо оглушительного успеха команды NGINX… И взял интервью, но не у Игоря (он по-прежнему интроверт-программист), а у инвесторов из фонда Runa Capital, которые десять лет назад разглядели nginx, построили вокруг него бизнес-инфраструктуру, а сейчас вели сделку, беспрецедентную по размеру для российского рынка.
Цель статьи под катом — ещё раз подтвердить — возможно все! Пробуй!
Руководитель Программного комитета HighLoad++ Олег Бунин: Поздравляю с удачной сделкой! Насколько я могу судить, у вас получилось сохранить и поддержать стремление Игоря продолжать работать программистом и при этом выстроить вокруг него всю бизнесовую инфраструктуру — это прямо мечта любого разработчика. Так ведь?
Мой собеседник управляющий партнер Runa Capital Дмитрий Чихачев: Это так. В этом большая заслуга самого Игоря и его кофаундеров Максима и Андрея (Максим Коновалов и Андрей Алексеев), потому что они изначально были готовы к тому, чтобы эта инфраструктура выстраивалась вокруг них. Не все стартаперы настолько адекватно оценивают свои собственные силы и возможности. Многие хотят лидировать или руководить всем процессом.
— То есть команда NGINX по большому счету сама отстранилась от бизнес-части, или как?
Дмитрий: Нет, они не отстранились от бизнес-части, почему же? Максим руководил операционной частью как операционный директор. Андрей занимался BizDev’ом, Игорь продолжал заниматься разработкой — тем, что ему нравится. Каждый занимался тем, в чем его сильная сторона и что ему нравится.
Более 15 лет назад был дан старт проекту nginx, 8 лет прошло с момента основания компании.
Я видел всю историю со стороны инвестора, моё описание событий может быть слегка упрощенным, выхватывать только несколько поворотных моментов.
Но основа всего — годы упорной работы команды и фаундеров, участвующих в поиске и выборе CEO, открытию американского офиса, формированию бизнес-модели и главное — в постоянном развитии продукта.
За что мы не устаём говорить им большое человеческое спасибо! Благодаря им nginx развивается и добивается успехов.
Но все они понимали, что для построения многомиллионного бизнеса в США необходим человек другого калибра, с другим бэкграундом. Поэтому еще в первом раунде переговоров был договор с инвесторами о том, что такой человек будет найден. Им стал Гас Робертсон, он подходит по всем этим критериям.
Нельзя переоценить значение nginx для HighLoad-сообщества. Спасибо, что здорово облегчаете нам жизнь!
— Получается, изначально планировалось выходить на американский рынок?
Дмитрий: NGINX — это b2b-бизнес. Причем не особо широко известный пользователям, поскольку работает на инфраструктурном уровне, можно сказать middleware Основным рынком b2b являются США — там сосредоточено 40% мирового рынка.
Успех на американском рынке предопределяет успех любого стартапа.
Поэтому логичный план: идти в США, сразу нанять человека, который возглавит американскую компанию, будет развивать бизнес и привлекать американских инвесторов. Если ты хочешь продавать в США инфраструктурное ПО, то важно, чтобы у тебя за спиной были в том числе и американские инвесторы.
— Кто к кому пришел: вы к nginx, nginx к вам?
Дмитрий: У нас было много разных точек контакта. Наверное, мы проявляли большую инициативу, потому что уже тогда nginx был заметен. Хотя он еще не был компанией, и доля рынка была относительно небольшой (6%), инвесторский интерес уже был большой. Сделка была конкурентной, поэтому мы, конечно, проявляли активность.
— В каком состоянии был продукт? Компании не было, но были ли наброски коммерческой enterprise-версии?
Дмитрий: Был web-сервер nginx с открытым кодом. У него были пользователи — 6% глобального рынка. На самом деле это миллионы, даже десятки миллионов web-сайтов. Но, тем не менее, компании не было, никакой бизнес-модели не было. А поскольку не было компании, не было команды: был Игорь Сысоев — разработчик nginx и небольшое community вокруг.
Это очень интересная история. Игорь начал писать nginx довольно давно — в 2002 году, а выпустил в 2004. Реально интерес к нему появился только в 2008, в 2011 году он привлек деньги. Немногие люди задумываются, почему прошло так много времени. На самом деле есть логичное техническое объяснение этому.
В 2002 году Игорь работал в Rambler, и была одна проблема, которую он как системный администратор решал — так называемая проблема C10k, то есть обеспечение сервером более десяти тысяч одновременных запросов в пиковой нагрузке. Тогда эта проблема только появилась, потому что большие нагрузки в интернете только входили в обиход. С ним сталкивались только единичные сайты — такие, как Rambler, Яндекс, Mail.ru. Большинству веб-сайтов это было неактуально. Когда в день по 100-200 запросов, никакой nginx не нужен, прекрасно справится Apache.
По мере того, как интернет становился все более популярным, росло количество сайтов, которые сталкивались с проблемой C10k. Все большему и большему количеству сайтов стал требоваться более быстрый web-сервер для обработки запросов — такой, как nginx.
Легко представить, насколько сразу выросло число запросов на серверы. Во-первых, увеличилось время пользования интернетом, потому что кликать по ссылкам стало можно везде и всюду, а не только сидя за компьютером. Во-вторых, изменилось и само поведение пользователя — с touch screen переходы по ссылкам стали более хаотичными. Сюда же можно добавить социальные сети.
Это привело к тому, что пиковые нагрузки в интернете стали расти экспоненциально. Общая нагрузка росла более-менее равномерно, но пики стали все более и более ощутимыми. Оказалось, что та самая проблема C10k стала повсеместной. В этот момент nginx и полетел.
— Расскажи, как развивались события после встречи с Игорем и его командой? Когда началась проработка инфраструктуры, бизнес-идей?
Дмитрий: Сначала формировалась сделка. Я уже говорил, что сделка была конкурентная, и в конце концов образовался синдикат инвесторов. Мы стали частью этого синдиката вместе с BV Capital (сейчас e.ventures) и Майклом Деллом. Сначала закрыли сделку, а после этого стали думать над вопросом поиска американского CEO.
А как вы закрыли сделку? Ведь получается, что вы даже не знали, какая бизнес-модель и когда это окупится? Просто в команду, в классный продукт инвестировали?
Дмитрий: Да, это была в чистом виде посевная сделка. Мы не думали в тот момент над бизнес-моделью.
Наш инвестиционный тезис был основан на том, что NGINX — уникальный продукт со значительно растущей аудиторией.
Он решал для этой аудитории достаточно серьезную проблему. У меня есть любимый тест, лакмусовая бумажка для любой инвестиции — решает ли продукт массовую и болезненную проблему. NGINX этот краш-тест проходил на ура: проблема была массовая, нагрузки росли, сайты лежали. И она была болезненна, потому что наступала эпоха, когда веб-сайт становился, что называется mission critical.
В 90-е люди рассуждали так: лежит сайт — сейчас позвоню сисадмину, через час поднимут — нормально. В конце 2000-х годов для многих компаний 5-минутный down-time стал равен реально потерянным деньгам, репутации и т.д. То что, проблема была болезненна — это одна сторона.
Вторая сторона, на которую мы как инвесторы смотрим — это качество команды. Здесь мы были впечатлены Игорем и его кофаундерами. Это был взаимодополняемый опыт и уникальный продукт, который был разработан одним человеком.
— Понятно, свою роль сыграла и команда с каким-то количеством компетенций, дополняющих друг друга.
Дмитрий: Мне кажется правильным, что Игорь один разработал продукт, но когда подошел момент создания бизнеса, не один туда бросился, а с партнерами. Глядя на 10-летний инвесторский опыт, могу сказать, что наличие двух соучредителей, безусловно, уменьшает риски. Оптимальное число кофаундеров — два или три. Один — это очень мало, а четыре — уже очень много.
— А что было дальше? Когда сделка уже состоялась, а проработанной бизнес-идеи еще не было.
Дмитрий: Заключается сделка, регистрируется компания, подписываются документы, переводятся деньги — все, побежали. Параллельно проработке бизнес-части, наняли команду разработчиков, которая начала работать над продуктом. Андрей Алексеев как BizDev выстраивал первые отношения с потенциальными клиентами, чтобы собрать обратную связь. Все вместе думали над бизнес-моделью, и все вместе искали топ-менеджера, который будет развивать американский бизнес и возглавит компанию по сути.
— И как же вы его нашли? Где? Я даже не представляю, как это сделать.
Дмитрий: Все инвесторы и совет директоров этим занимались. В итоге выбор пал на Гаса Робертсона. Гас работал в Red Hat, топ-менеджер которой был нашим инвестором. Мы обратились в Red Hat, поскольку это open source, сказали, что ищем человека, который способен возглавить бизнес и развить его в миллиардный. Они порекомендовали Гаса.
Сделку с NGINX закрыли в 2011, а в 2012 мы уже встретились с Гасом, и он нам сразу очень понравился. У него был бэкграунд в open source из Red Hat — на тот момент это была единственная компания с многомиллиардной капитализацией в open source. К тому же Гас занимался именно развитием бизнеса и продажами — то, что надо!
Помимо бэкграунда и опыта нам понравились его личные качества — он толковый проницательный человек с быстрым умом, и, что немаловажно, нам показалось, что у него хорошее культурное соответствие команде. Действительно, так и случилось. Когда они познакомились, оказалось, что все на одной волне, все в отличном взаимодействии.
Мы сделали Гасу предложение, и в конце 2012 года он приступил к работе. Гас также предложил инвестировать в NGINX свои собственные деньги. На всех инвесторов это произвело впечатление. Благодаря высокой вовлеченности Гаса, он влился в команду основателей и воспринимался всеми как сооснователь компании. В последующем он был одним из четырех. Есть знаменитая фотография, где все четверо в майках NGINX.
Фотография взята из заметки Дмитрия Чихачева об истории сотрудничества NGINX и Runa Capital.
— Сразу удалось нащупать бизнес-модель, или она потом менялась?
Дмитрий: Модель удалось нащупать сразу, но перед этим мы некоторое время дискутировали, как и что. Но основная дискуссия была вокруг того, продолжать ли поддерживать проект с открытым кодом, оставить ли nginx бесплатным, или постепенно заставить всех платить.
Мы решили, что будет правильно использовать силу сообщества, которое стоит за nginx, не разочаровывать его и не отказываться от поддержки проекта с открытым кодом.
Поэтому мы решили сохранить nginx в open source, но создать дополнительно специальный продукт, который получил название NGINX Plus. Это коммерческий продукт на базе nginx, который мы лицензируем enterprise-клиентам. Сейчас основной бизнес NGINX — это продажа лицензий NGINX Plus.
Основные различия открытой и платной версии это:
Дмитрий: Open source продукт продолжает развиваться параллельно с коммерческим. Какой-то функционал добавляется только в коммерческий продукт, что-то и туда, и туда. Но ядро системы, очевидно, одно и то же.
Важный момент, что nginx сам по себе очень небольшой продукт. По-моему, в нем всего около 200 тысяч строк кода. Задача была в том, чтобы разрабатывать дополнительные продукты. Но это уже произошло после следующего раунда инвестиций, когда были запущены несколько новых продуктов: NGINX Amplify (2014-2015), NGINX Controller (2016) и NGINX Unit (2017-2018). Продуктовая линейка для enterprise расширялась.
— Как быстро стало понятно, что вы угадали с моделью? Вышли на окупаемость, или стало понятно, что бизнес растет и будет приносить деньги?
Дмитрий: Первый год с выручкой был 2014, тогда мы заработали условный первый миллион долларов. В этот момент было понятно, что есть спрос, но еще не была до конца понятна экономика с точки зрения продаж, насколько модель позволит масштабироваться.
Два года спустя, в 2016-2017 годах мы уже понимали, что экономика хорошая: отток клиентов небольшой, есть up-sell, и клиенты, начав использовать NGINX, покупают его больше и больше. Тогда стало понятно, что это можно масштабировать дальше. Что в свою очередь привело к дополнительным раундам финансирования, которые уже пошли на масштабирование организации продаж, найм дополнительных людей в США и других странах. Сейчас у NGINX офисы продаж в Штатах, Европе, Азии — по всему миру.
— Большая сейчас компания NGINX?
Дмитрий: Уже около 200 человек.
— В основном, наверное, это продажи и support?
Дмитрий: Разработка по-прежнему довольно большая часть компании. Но продажи и маркетинг — значительная часть.
— Разработкой в основном занимаются российские ребята, которые в Москве сидят?
Дмитрий: Разработка сейчас уже ведется в трех центрах — это Москва, Калифорния, Ирландия. Но Игорь продолжает большую часть времени жить в Москве, ходить на работу, программировать.
Мы проследили весь путь: начало в 2002, в 2004 выпуск nginx, рост в 2008-2009, 2010 знакомство с инвесторами, в 2013 первые продажи, в 2014 первый миллион долларов. А что в 2019? Успех?
Дмитрий: В 2019 — хороший выход.
— Это нормальный цикл для стартапа по времени, или исключение из правил?
Дмитрий: Это совершенно нормальный цикл по времени — смотря от чего отсчитывать. Когда Игорь писал nginx — я не зря рассказал эту предысторию — nginx не был массовым продуктом. Потом, в 2008-2009 году изменился интернет, и nginx стал очень востребован.
Если отсчитывать как раз с 2009-2010 года, то цикл в 10 лет совершенно нормальный, если учесть, что по сути это момент, когда продукт только начал пользоваться спросом. Если считать от раунда 2011 года, то 8 лет с времени первых посевных инвестиций тоже нормальный срок.
— Что можно сейчас рассказать, завершая тему с NGINX, про F5, про их планы — что будет с NGINX?
Дмитрий: Я не знаю — это корпоративная тайна F5. Единственное, что я могу добавить это, что если сейчас загуглить «F5 NGINX», то первые десять ссылок будут новостью о том, что F5 приобрел NGINX. На такой же запрос две недели назад поиск сначала выдал бы десять ссылок о том, как мигрировать с F5 на NGINX.
— Не убили бы конкурента!
Дмитрий: Да нет, зачем? В пресс-релизе в общих чертах написано, что они собираются делать.
— В пресс-релизе все хорошо: мы никого не будем трогать, все будет расти, как и раньше.
Дмитрий: Думаю, что у этих компаний очень хорошее культурное совпадение. В этом смысле они обе все-таки в одном сегменте работают — networking и нагрузки. Поэтому всё будет хорошо.
— Последний вопрос: я — гениальный программист, что мне делать, чтобы повторить успех?
Дмитрий: Чтобы повторить успех Игоря Сысоева надо сначала придумать, какую проблему решить, потому что за код платят деньги только тогда, когда он решает массовую и болезненную проблему.
— А потом к вам? И дальше вы поможете.
Дмитрий: Да, с удовольствием.
Спасибо большое Дмитрию за интервью. С фондом Runa Capital мы вскоре снова увидимся на Saint HighLoad++. В месте, которое, теперь мы можем с полной уверенностью это утверждать, собирает лучших разработчиков не России, а всего мира. Кто знает, может через несколько лет мы все будем так же горячо обсуждать успех кого-то из вас. К тому же теперь понятно, с чего начинать — искать решение важной проблемы!
И быть готовыми, как и команда nginx, к многолетнему упорному труду.
NGINX вполне заслуженно является одним из лучших по производительности серверов, и всё это благодаря его внутреннему устройству. В то время, как многие веб-серверы и серверы приложений используют простую многопоточную модель, NGINX выделяется из общей массы своей нетривиальной событийной архитектурой, которая позволяет ему с легкостью масштабироваться до сотен тысяч параллельных соединений.
