Облака и эластичность

    Sooo elastic
    Планируя разработку облачных сервисов, многие разработчики задаются вопросом – что нового им предстоит и чем облачный сервис отличается от «обычного».

    Довольно часто при описании облаков и облачных решений говорят об эластичности. 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, узел сервиса при запуске скачает его и просто смонтирует. Так можно уменьшить время развертывания в несколько раз.

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

    Дмитрий Мещеряков,
    департамент продуктов для разработчиков
    ABBYY
    167,00
    Решения для интеллектуальной обработки информации
    Поделиться публикацией

    Комментарии 25

      0
      Я не использовал Azure, но неужели там нельзя установить на систему FRE, сделать из этого образ, и новые ноды поднимать, используя уже его?
        0
        нет, там идея в том, что у вас PaaS, а описанный вариант — это простая виртуалка, как EC2 в Амазоне.
        Ажур же настаивает на том, чтобы вы весь ваш продукт сделали в виде некоторого автоматического инсталлятора. И тогда ставить его на любую машину ажур будет самостоятельно.
          0
          Я отвечал на вопрос в пределах «без смены парадигмы PaaS на IaaS» ;)
          0
          Можно, это IaaS-модель использования (как в Amazon EC2). В этом случае при изменениях кода сервиса придется перезаливать этот образ. PaaS-модель в этом плане удобнее — в пакет складываются только часто изменяемые небольшие части сервиса, гораздо меньше заливать вручную. Плюс при использовании PaaS-модели гораздо удобнее масштабирование. Всегда какой-то компромисс.
            0
            Это проблема, если держать сервис вшитым в образ. Если использовать модель деплоя сервиса при старте, то, мне кажется, это решит проблему. Именно так делали мы:
            1. Собирали образ со всеми библиотеками, настройками, app-сервером
            2. При старте сервиса загружали архив с кодом и уже его разворачивали.

            Возможен другой вариант, когда деплой делается тем актором, который запускает инстанс.
              0
              Да, так тоже можно. По сути PaaS в Azure работает аналогично — берется «эталонный» образ, с него запускается виртуальная машина, потом на нее копируется пакет с кодом, код запускается в служебном процессе. Важное преимущество Azure в том, что Azure, например, умеет по очереди отключать виртуальные машины для обновления ОС, потом возвращать их.
                0
                Вы ниже писали, что проблемы при обновлении не покрываются SLA. Так что это не обязательно преимущество.

                Особо смысла нет в споре IaaS vs PaaS. Везде свои преимущества, главное выбирать наиболее подходящий вариант для конкретного проекта. Но в каждом из подходов надо правильно «готовить» образ, пакет и т.д.
          0
          Кстати, Дим, вопрос — а ты этот виртуальный диск в итоге попробовал? Какой реальный прирост в попугаях?

          Дело в том, что в теории это все выглядит ровно также как с архивом в блобе — кем-то скачивается полностью VHD и просто монтируется. Это ничем не отличается, если узкое место — канал скачивания или запись на диск. Выигрыш может быть если этот тормозящий участок (в виде скачивания) относится к хосту, т.е. не твой виртуальный контейнер качает у себя и монтирует, а параллельно с развертыванием твоей виртуалки хост скачивает диск и монтирует на момент поднятия.

          У нас была идея — делать архив с нулевой компрессией, т.е. просто контейнер. Ибо по логам и ощущениям — распаковка архива занимает больше времени чем скачивание. Проще скачать 1.5 гига flat, чем качать 500 метров но сжатых в zip и тратить время на распаковку…

          А еще стоит упомянуть про волшебные 15 минут: в процедуре апгрейда OS есть очень некомфортный note
          msdn.microsoft.com/en-us/library/windowsazure/hh543978.aspx

          Due to this behavior, if you have startup tasks or code in the OnStart method which takes longer than 15 minutes, you may have role instances from multiple upgrade domains offline at the same time, which may affect your service availability.


          (или тут blogs.msdn.com/b/avkashchauhan/archive/2011/10/02/does-windows-azure-startup-task-have-time-limit-what-to-do-with-heavy-processing-startup-task-in-windows-azure-role.aspx)
            0
            Узкое место как раз преобразование «упакованного чего-то» в дерево папок — множественные чтения-записи приводят к очень заметному замедлению. Одно из альтернативных решений — читать архив в память и распаковывать из памяти. И распаковка из памяти, и вариант с VHD работают примерно одинаково быстро. Ускорение составляет порядка двух минут.
              0
              Да, я понимаю, что дисковая подсистема не фонтанирует там. А -2 минуты это от какого стандартного времени «как было ранее»? В принципе 2 минуты это более чем много при верхнем лимите в 15, но все же.
                0
                Общее время было порядка от трех до пяти минут, оно части варьируется из-за неравномерной нагрузки от разных виртуальных машин на железный сервер, на котором они все размещены. Пост-то не про верхний предел, пост про масштабирование при штатной работе.

                Что касается верхнего предела. Перечитал SLA под более сильной лупой (интересное выделено жирным)…
                In addition to the SLA Exclusions noted in Section 1.c., the SLA and any applicable Service Levels related to the Monthly Role Instance Uptime does not include any performance or availability issues to perform regular platform upgrades and patches.

                Это похоже на полный произвол. Обращусь-ка я в поддержку.
            +1
            Если подразумевается распаковка образа тем более 750 mb не о какой быстрой эластичности, понятно, речи быть не может.
            С подключением виртуального диска хорошая идея. А есть ли мысли почему ядро FR весит 750 мегабайт? Я возможно тупой вопрос задаю. На входе картинка — алгоритм — спуск. FR написан вроде на с или с++, возможно ли занятся оптимизацией кода в сторону уменьшения дистрибутива? Я прекрасно понимаю что это все крайнесложные технические вещи которые один человек разработчик в одиночку не решит и за этим стоит целый этаж разработчиков, и поэтому глупо говорит о размере дистрибутива. Но нельзя отрицать что со временем програмные среды разработки из за конкуренции каждый раз компилируют exe все большим и большим размером. Если со стороны посмотреть. НУ не может алгоритм написанный с С или с++ занимать 750 mb. Вспомните первые версии FR. Да это он был жутко старый и там нет уже ничего от современного, но не настолько же мегобайт. Это же алгогритм какие то циклические операции с пикселями. Я про то, что в свое время писал создатель тотал коммандера. Его софт так и остается крайнешустрым и малым по размеру не зависимо от времени. Потому что он тратил адовые усилия и все писал в Delphi 2, так как понимал что новые версии компиляторов добаляют тормозов.
              0
              Помимо исполняемого кода есть словари для словарной поддержки и описания того, как выглядят символы. Поскольку сервис умеет распознавать иероглифические языки (например, китайский), описания для этих языков тоже приходится таскать с собой. В иероглифических языках довольно много разных символов с довольно сложным начертанием, поэтому описания довольно большие, их объем и составляет значительную долю в объеме дистрибутива FRE.
                0
                Если учесть самые частые языки распознования русский и английский, сильно снизится словарь?
                Просто гараздо эффективнее подготовить виртуальный жесткий диск для частых языков, чем засовывать из за англиского в дистрибутив все остальные. Поставить чекбоксы в вебинтерфейсе а потом уже грузить нужный образ.
                Мне кажется без работы с дистрибутивом что то ускорить в облаке врятли больше получится.
                  0
                  Если оставить только европейские языки, дистрибутив уменьшится в разы. Вы правы, эту проблему можно решить лучше, но всегда нужен компромисс между результатом и затратами. Кстати, скачивание и распаковка FRE была приведена только в качестве примера, а проблема с временем запуска узла — общая.
                    0
                    Ну если посчитать:
                    Часы на переработку дистрибутива под облака с выбором опций (чем точнее запрос от пользователя тем быстрее разворот)
                    Но как посчитать убыток? Как посчитать что пользователь ждал ждал ждал разворота диска и ушел нежождавшись… Ведь облака то у вас платные, купил — сиди уж жди. Триалка разве что даст понять по скорости. Чем быстрее работает, тем вероятность покупки подписки выше.
                      0
                      Чтобы клиент не ждал нужно делять некоторый overporvisioning. Несколько машин должны работать вхолостую. Да деньги на ветер, но не затратив ни копейки ничего не заработаешь.
              0
              Будь я на AMazon EC2 у меня такой проблемы вообще не возникло. Зачем вам нужно устанавливать ваш SDK на каждом хосте.
              Поднимайте не голый образ, а образ с уже всеми передустановлеными пререквизитами. Дальше Chef/Puppet/cfEngine клиент ломится за конфигурацией на главный узел и конфигурируется. На всё про всё несколько минут, большая часть из этого времени запуск ОС с образа.
              Из того что я пока нагуглил про Azure, для Windows OS такой образ поднять тоже можна, но нужно явно запускать syspep, но я думаю что это всё одно более быстрый способ чем установка msi.
                0
                Во-первых, главный узел. Как только с ним что-то случится, начинаются проблемы.

                Во-вторых, что делать с изменениями кода? Их нужно как-то развертывать, не правда ли?

                Вот из-за этого PaaS и удобнее. То, что вы нагуглили про образ, — это IaaS, который в Azure тоже есть и примерно такой же, как в EC2.
                  0
                  Изменения кода означают новый образ. У вас ведь не каждый день изменения выкатываются на production.
                  Главный узел для того puppet не проблема, клиент идёт через лоадбалансер, за ним два/три/сто инстанса puppet/cheff/whatever.

                  Если про вас напишет какое-то известное издание и вы получите slashdot/хабр-эфект виртуалки которім нужно будет только поднять ОС заработают быстрее чем те которые будут ещё что-то ставить.

                  Да кстати, как вы ставите FineReader SDK, вам достаточно xcopy или нужен полноценный инсталятор.

                  Так-как у вас полностью своё облако, то если переписать FineReader OCR SDK без всех регистраций/реэстра/ActiveX у вас может быть даже более простое решение держать FineReader OCR SDK на статическом read-only vhd-томе. Тогда даже запускать его можна с этого диска, главное чтобы он писал на writtable диск.
                    0
                    Почему не каждый день — хоть каждый час можно. В этом то и прелесть PaaS — с билда получили специальный pack, загрузили в интерфейс и сказали — развернуть. Все. А возиться вручную каждый раз с образом или даже на текущий образ заливать обновленный код — пробовали, не понравилось. Все эти puppet\chef автоматизируют именно эту рутину — обновление IaaS инстанса при изменение.
                    Идея PaaS уничтожает эту рутину как класс.
                    0
                    «Вот из-за этого PaaS и удобнее. То, что вы нагуглили про образ, — это IaaS, который в Azure тоже есть и примерно такой же, как в EC2. » — Что-то я не понял этого момента. Вы исспользуете Azure как раз как IaaS иначе зачем копировать ваш SDK. Задеплоили WCF/ASP.NET сервиса и Azure за вас думает сколька ему инстансов поднять надо. (Кстати у Amazon PaaS есть даже для .NET aws.amazon.com/elasticbeanstalk/).
                      0
                      Нет, мы используем Azure как PaaS — даем Azure пакет с основным кодом сервиса, Azure его сам разворачивает на выбранных им виртуальных машинах с обновленной операционной системой. FRE мы копируем потому, что в пакет его класть очень неудобно из-за большого размера.

                      Нет, Azure не думает за нас, сколько запускать экземпляров сервиса, — мы управляем этим сами.
                  0
                  ей специально ограничивают пропускную способность диска.

                  У них же есть provisioned iops диски
                    0
                    Разве они не только в Amazon?

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

                  Самое читаемое