System-NS изнутри

После публикации прошлой статьи, в которой была информация о том, как и почему мы придумали System-NS и что этот сервис из себя представляет, нам начали сыпаться вопросы по поводу нашей “внутренней кухни”.

Сразу хочу сказать, что мы не являемся конкурентом Cloudflare ни в каком виде, поэтому не вижу смысла рассказывать, чем мы лучше. На сегодняшний день наш сервис направлен только на управление доменами. А в отличии от PDD Yandex, мы предоставляем услуги Secondary и Dynamic DNS.

Перед нами стояла задача: “использовать максимальное количество внешних модулей” (дабы писать меньше своего кода). Мы потратили много времени на поиск подходящих модулей (с необходимым функционалом и без багов). В процессе этого поиска несколько наших молодых сотрудников перестали быть свято уверены в “безупречности” opensource проектов. После криков и мордобоя остановились на связке: ZF2 — Doctrine ODM — BjyAuthorize — ZfcUser.

Немного подробнее о составляющих.
Frontend:

• Zend Framework (ZF) 2. Так как раньше для некоторых проектов мы использовали ZF, при старте работы над System-NS мы были безгранично рады выходу ZF2, он оказался удобнее и производительнее своего предшественника.
• Doctrine ODM. Модуль, позволяющий преобразовывать документы mongoDB в объекты php. На самом деле данный модуль был выбран нами с целью “посмотреть”, какие преимущества он может дать при работе с mongoDB (обычно работаем через свой класс/враппер). Модуль оказался избыточным и далеко не всегда удобным в работе.
• MongoDB. Отличная документо-ориентированная база данных, используем ее практически для всех своих проектов (единственный минус БД — отсутствие транзакций, но при должном упорстве можно реализовать и их).
• BjyAuthorize. Механизм для ограничения доступа к определенным частям сайта, основан на “ролях” пользователя.
• ZfcUser. Модуль для управления пользователями, содержит готовые (настраиваемые) механизмы регистрации и авторизации. Отлично совместим с Doctrine ODM и BjyAuthorize.
• Twitter Bootstrap. Очень приятный набор CSS шаблонов, сильно облегчает задачу с responsive design и версткой в целом.

Backend:

• Самописный DNS сервер(C++) — это вообще отдельная история. Сильно распространяться не могу, так как проект закрыт NDA. Причина его написания только одна — производительность. В нашей реализации одно ядро на 2 GHz (способное обслужить до 3-3.5 млн запросов в секунду), что соответствует приблизительно 1.4 Gb траффика dns (average). Эта же технология, с разрешения собственника, была использована в паблик сервисе, но в немного урезанном виде. Имеет собственный управляемый кеш, но в целом зависит от внешнего хранилища данных.
• Memcached — используется как хранилище бинарной структуры записей зон доменов, вместо выделения памяти в демоне dns — с единственной целью (см следующий пункт), хотя и были длительные дискуссии на тему того, что tcmalloc в самом dns был бы быстрее, но решили вообще не нагружать dns лишним функционалом
• Самописный демон для репликации данных по серверам и сохранения на диск снепшотов (C++)

Физически сервис находится на пяти серверах. На трех из них (Франция, Украина, Россия) находится frontend. Остальные два сервера (Норвегия, Чехия) предназначены для репликации. Для балансировки трафика использован отказоустойчивый балансировщик от компании Clustertech AS (Норвегия) — который расположен на anycast сегменте.

Так как сервис бесплатный — мы пока не видим необходимости запускать для него свой anycast сегмент (хотя и имеем возможность), это уже из разряда дорогого удовольствия “для себя”, но не исключено, что при наличии большого количества желающих, мы его таки запустим.

Спасибо за внимание и интерес к нашему сервису.