Дарудар — облако в дар от Microsoft
Дарудар — известный на просторах Рунета проект, ставший связующим звеном между людьми, желающими что-то подарить, но не знающими кому, и теми, кто может этого захотеть. На сайте можно найти все, что угодно — от бытовых и не очень вещей до самых настоящих котов в мешках. О том, как работает сервис, где уже подарили более 2 миллионов даров, рассказывает один из основателей сервиса, Антон brutto Каракулов.
Дарудар — самый настоящий высоконагруженный проект. Размещенный в облаке и использующий полностью Linux-стек, в сутки он выдерживает ~2.5 тыс даров и ~1.5 тыс благодарностей, ~20 тыс. комментариев, ~40 тыс. уведомлений и ~4.5 тыс. файлов. Подробности под катом.
Современного человека уже не нужно убеждать в преимуществах облачных платформ, использующихся в качестве основной инфраструктуры создания веб-сервиса, мобильного приложения, наконец — «обыкновенного» веб-сайта. Для фиксации фактов не лишним будет еще раз повторить основные преимущества облачных услуг хостинга:
— Широкий выбор операционных систем, ЯП, фреймворков, инструментов, БД и устройств.
— Широкие возможности интеграции: Linux-контейнеры в Docker; наравне с
созданием JavaScript, Python, .NET, PHP, Java и Node.JS приложений
— И, конечно, бэкэнд для приложений под iOS, Android и Windows
Отсутствие необходимости осваивать новые технологии или решения/инструменты, вкупе с биллингом в реальном времени и масштабируемой «по запросу» железной инфраструктурой — вот краеугольный камень, на котором стоят все современные облака, и Microsoft Azure здесь, конечно же, не исключение.
Пожалуй, еще одно немаловажное преимущество облачных платформ в целом и Microsoft Azure в частности — это возможность переноса существующего проекта и получения всех уже упомянутых преимуществ. Собственно, сейчас «перевезти» собственный бэк-энд из дата-центра, в котором вы, возможно, арендуете отдельные стойки, в облако не представляет никакого труда: гибридные базы данных, хранилища, безопасные способы подключения — всё это есть из коробки. А в случае Microsoft есть еще и Azure Stack, позволяющий принести модель разработки и выкатки (деплоя) приложений Azure в любой ЦОД или дата-центр.
Наконец, платить только за то, что вы используете, а не за «факт наличия», стало уже настолько неотъемлемой ценностью для разработчиков и владельцев виртуальных продуктов, что обратную модель никто даже не готов рассматривать всерьёз.
Про «почему?»
Мы, как и многие другие, получили грант от компании Microsoft по программе поддержки стартапов. На наш взгляд, это жирный плюс, особенно для начинающих проектов или проектов, которые хотели бы лишь испробовать облако. Хотя, конечно, нам повезло узнать о преимуществах Azure в один из самых трудных моментов (наша предыдущая площадка-хостер резко прекратила свою деятельность, и мы «спасали» собственную инфраструктуру). Наши предыдущие хостеры славно потрудились в своё время, и я не могу сказать о них ничего плохого, но из-за постоянной нехватки полноценного системного администратора (на зарплату которому у нас нет средств) — облако заметно упростило моменты, связанные именно с администрированием инфраструктуры.
Про архитектуру и технологии
У Дарудара вполне классический nix-стек: nginx, php, mysql, memcached, sphinx.
Встречает всё nginx, дальше запрос идёт на php-бекенд, который уже взаимодействует со всеми остальными как внутренними, так и внешними сервисами проекта.
В настоящий момент на Azure используется Cloud Services и виртуальныемашины Ubuntu внутри одной сети. Для каждого внутреннего сервиса создан образ, который может быть использован для аварийного
восстановления/замены и планируется использовать также для возможности дальнейшего горизонтального масштабирования сервисов проекта не без помощи удобных инструментов платформы Azure Available Sets и Load Balancing set.
В планах стоит переезд медиа-хранилища на Azure Blob Storage, а также использование Azure Queue (проводим тестирование).
Про стереотипы
«Azure — это MS, а MS — это Windows» — у меня в голове тоже срабатывала такая связка. И это было первым, что я проверил, когда получил доступ к контрольной панели Azure.
Всё оказалось не так. Azure оказался лоялен к Nix-системам, и мы используем именно их.
Win-серверами мы на Дарударе никогда не пользовались и не пользуемся вообще. С виндовой технологией виртуализации знаком только понаслышке —в основном на винде для этого использую VMware какой-нибудь. В Azure есть, насколько мне известно, возможность разворачивать вин-сервер и подключаться к нему удалённо, вроде «удалённый рабочий стол», но сам лично с этим не работал и не пробовал даже (прим.ред: действительно, к Windows Server«у можно подключаться с помощью визуального интерфейса).
Если говорить отдельно о виртуализации nix-машин, то о самой технологии ничего сказать не могу — так глубоко не копал, но есть ряд «специфических» платформенных особенностей.
Минусы:
— При ресайзе (изменении конфигурации) VM (виртуальной машины) она полностью перезагружается.
— Системный диск VM крайне медленный и использовать его поэтому нужно осторожно или не использовать вовсе.
— Есть большой дополнительный диск, который присутствует у каждой машины и с хорошей скоростью, но он считается «временным» и при перезагрузке может обнуляться, поэтому использовать его под чувствительные данные крайне не рекомендуется (кстати, теперь Azure стал об этом писать везде, а не только в документации!).
— Неочевидная с первого раза для понимания структура Cloud Services.
Плюсы:
— Можно создавать, а затем использовать собственные образы (удобно для кластеризации и масштабирования).
— Любые диски можно добавить самостоятельно, можно даже образ сделать с нужным количеством дисков, которые будут затем «подниматься» и «цепляться» самостоятельно.
— Наличие консольной утилиты для управления инфраструктурой (удобно для автоматизации работ по включению/выключению, добавлению/удалению).
— Возможность создать VPN.
— Наличие инструментов для управления трафиком/нагрузкой (Azure Available Sets, Load Balancing Sets, DNS Traffic Manager).
Возможно, определённые вещи уже давно есть и у Амазона или Гугла, но я за ними пока перестал следить, а у Azure мы всем этим пользуемся и остаёмся с хорошими впечатлениями.
Про стоимость
Azure обходится нам сейчас в \~140 тыс. рублей в месяц. Этого нам хватает на 90%, так как для пиковых нагрузок всё же этого мало.
Думаю, конечная стоимость для полноценного обслуживания текущего положения дел будет порядка 160–180 тыс. Про нагрузку на «Дарударе» отвечу так:
~2.5 тыс даров и ~1.5 тыс благодарностей в сутки
~20 тыс. комментариев в сутки
~40 тыс. уведомлений в сутки
~4.5 тыс. файлов (изображений) в сутки
Что касается выбора для компаний, то для начала надо определиться с целями и масштабами.
Пробовать потому, что это модно и «все сейчас в облаках», не стоит. Для нас (Дарудар) ключевым при выборе переходить в облако или оставаться на collocation стало отсутствие в штате сисадмина, и поэтому, фактически, для нас стоимость облачного хостинга — это стоимость инфраструктуры + базовый администратор.
О том, стоит или нет вообще, можно рассуждать много, например, так:
— Хорошо для проектов прям только-только случившихся и которые только отрабатывают свою модель;
— Хорошо для проектов, которые рассчитывают жить только на инвестиции (имеется в виду, что при отсутствии инвестиций проект закрывается);
— Хорошо для проектов, которые могут зарабатывать самостоятельно и им интересен рост и развитие.
Про планы
Всё, что нам интересно и может планироваться к внедрению, так или иначе приводит к vendor lock«у, требуя, соответственно, аккуратного внедрения в проект.
1. Например, очень нужны очереди. Думаем над внедрением.
2. Надо решить вопрос с медиа-хранилищем. В итоге нужно будет перейти на полноценное облачное решение (а это 100% vendor lock).
3. Очень интересная штука, которая тоже нами запланирована и о которой говорил выше — управление траффиком/нагрузкой (Azure Available Sets, Load Balancing Sets, DNS Traffic Manager).
Про best practices
Проблема в очень медленном системном диске для Linux-инстансов, так что или не используем его вовсе или лишь для некоторого рода задач, где это не критично.
Локальный диск хоть и выглядит привлекательно с точки зрения размера и скорости, и даже, не смотря на предупреждение о том, что данные с него могут потеряться, может сохранять данные при перезагрузке инстансов (!), но хранить там критически важные данные всё же ошибка. Например при вертикальном масштабировании инстанса он по любому обнулится.
Случается, что VM может повиснуть так, что ему уже ничего не поможет, кроме перезагрузки. А иногда даже она может не помочь. Поэтому выделение каждого внутреннего сервиса в отдельный инстанс или группу на порядок облегчает управление инфраструктурой. В связи с этим даже мысли стали «облачными»: лучше перезагрузить, чем исправить. Если после перезагрузки не исправилось, лучше пересоздать.
Резюмируя
После боли и страданий при освоении платформы (были и такие моменты) теперь испытываю спокойствие за будущее инфраструктуры проекта. Появилась предсказуемость, которая позволяет полноценно заниматься планированием и развитием проекта. И что ещё очень ценно: появилась возможность управлять инфраструктурой, не обладая глубокими знаниями в области администрирования, и подключать к обслуживанию инфраструктуры дополнительных людей.
