Планируя разработку облачных сервисов, многие разработчики задаются вопросом – что нового им предстоит и чем облачный сервис отличается от «обычного».
Довольно часто при описании облаков и облачных решений говорят об эластичности. Amazon даже назвала свое облако Elastic Compute Cloud (EC2). Помимо того, что «эластичность» – используемое в маркетинге облаков красивое слово, у него есть и вполне определенный смысл. Речь о возможности арендовать вычислительные ресурсы с оплатой по фактическому использованию, начиная и прекращая аренду в произвольный момент.
Это очень удобно для сервисов с непостоянной нагрузкой – при изменении нагрузки они могут масштабироваться, увеличивая или уменьшая число узлов, обеспечивая пользователям приемлемое время обработки запросов, а владельцам – снижение затрат.
Так в теории. На практике перейти от красивого слова к делу не всегда просто.
Все хорошо, пока речь идет о показе простого сервиса «Здравствуй, мир» на очередной конференции. «Вот мы загрузили пакет с сервисом в облако, нужно немного подождать, пока он запустится, а я тем временем расскажу о других полезностях, блаблабла… вооот, смотрите, сервис работает».
Теперь добро пожаловать в реальный мир. В реальном мире вам может быть недостаточно держать в облаке сервис «Здравствуй, мир». Вы можете захотеть сделать что-то более сложное, например, как наш сервис Cloud OCR SDK. Сам по себе наш сервис несложный, но он, видите ли, выполняет оптическое распознавание, а для этого он таскает с собой почти полный дистрибутив FineReader Engine (минус справка и инсталлятор) размером около 750 мегабайт. В реальном мире так бывает – чтобы сделать что-то полезное, приходится использовать что-то громоздкое.
Поскольку мы используем PaaS модель Windows Azure, каждый узел сервиса должен при запуске откуда-то взять этот дистрибутив FRE, развернуть и настроить его. Логичное решение – положить дистрибутив в Blob Storage. Процесс копирования должен быть максимально надежным, поэтому хорошо бы уменьшить число файлов и обойтись без развесистой структуры каталогов. Первое, что приходит в голову, – старый добрый ZIP.
Хитрый план выглядит так:
— скачать архив
— распаковать архив
— развернуть и настроить FRE
— ???
— ШТАТНО РАБОТАТЬ
Одна проблема – развертывание FRE идет довольно долго несмотря на все облачные датацентры. Так происходит, потому что виртуальная машина не одна на физической машине, ресурсами нужно делиться, поэтому ей специально ограничивают пропускную способность диска. Из-за этого распаковка занимает довольно много времени (читаем-пишем-читаем-пишем-повторить-нужное-число-раз).
Воспитанный в безоблачных старых традициях читатель уже готовится пойти в комментарии и «объяснить», что время запуска узла не так уж и важно, ведь запуск происходит редко. Не стоит торопиться.
Здесь и кроется важное отличие «обычного» сервиса от облачного.
У «обычного» сервиса запуск и штатная работа – две разные фазы жизни. Сначала запустился, потом работает. У облачного сервиса запуск дополнительных узлов является частью обычной работы. Пользователей стало больше – сервис масштабируется, запуская дополнительные узлы. Пользователей стало заметно меньше – часть узлов останавливается и возвращается облаку.
Как бы вы ни прогнозировали нагрузку, обычно вы ее не контролируете. В какой-то момент возможен непредсказуемый всплеск, и нужно будет запустить дополнительные узлы. Как можно быстрее. Облако эластичное, помните?
Каждые лишние 10 секунд, потраченные на запуск, – это бесполезный простой вновь запущенного узла. Эти 10 секунд узел мог бы делать что-то полезное. Более того, очень часто в это самое время нагрузка на сервис значительно увеличена, и этот узел мог бы обрабатывать нагрузку, но он еще не готов, потому что занят чем-то «действительно важным» вроде распаковки архива.
Это не все. При всплеске нагрузки может понадобиться запустить не один новый узел, а много. Тогда 10 секунд из предыдущего параграфа будут бесполезно работать все вновь запущенные узлы. Вроде все заняты, а пользы нет.
Каждая секунда, потраченная на что-то «действительно важное», непроизводительно расходуется как раз в то самое время, когда полезная работа узла востребована больше всего.
В нашем случае – очевидно, нужно по возможности ускорить действия по развертыванию FRE. Один из способов – использовать виртуальный жесткий диск. Если при создании диска отформатировать его под NTFS и включить встроенное сжатие данных, образ диска получается около 600 мегабайт. Образ можно положить в Blob Storage, узел сервиса при запуске скачает его и просто смонтирует. Так можно уменьшить время развертывания в несколько раз.
Чтобы сервис мог полностью использовать эластичность облака, необходимы дополнительные усилия при разработке сервиса, позволяющие запускать новые узлы как можно быстрее. Иначе эластичность так и останется красивым словом.
Дмитрий Мещеряков,
департамент продуктов для разработчиков
Автор: DmitryMe
