Развертывание сайта в облачной инфраструктуре может изменить ваш подход к развертыванию мощностей. Он сильно зависит от того, как вы собираетесь организовать эффективное использование доступных мощностей. В рассмотренных примерах мы видели, как при принятии решений учитывались различные причины как технического, так и не технического плана. Ниже приведена краткая сводка таких причин.

Не технические причины:

• Юридические аспекты, связанные с конфиденциальностью, безопасностью и правами владения данных, хранящихся на серверах сторонней организации.
• Уверенность в доступности и достаточной производительности облачной инфраструктуры.
• Влияние соглашения об уровне обслуживания (или его отсутствия) в контексте фрагментов инфраструктуры.
• Комфортность взаимодействия с развивающейся технологической платформой.

Технические причины:

• Необходимость переработки приложения для эффективного использования облачных ресурсов. На практике обычно применяются архитектуры, которые стремятся свести к минимуму затраты на отправку/получение данных из облака, и развертывают вычислительные экземпляры только тогда, когда они необходимы.
• Недоступность информации о физическом местонахождении данных заставляет разработчиков рассматривать свое приложение (и операции управления приложением) на более высоком уровне. Потенциальная возможность приостановки, исчезновения или миграции вычислительных экземпляров требует реализации встроенной избыточности.

Независимо от того, как организация собирается использовать облачную инфраструктуру, сам факт такого использования оказывает значительное влияние на планирование мощностей. WordPress.com хранение данных обходится дороже, чем до перехода на облачный сервис, но их это устраивает. SmugMug.com платит за Amazon S3 меньше, чем пришлось бы платить за организацию собственного хранилища. В сфере облачных инфраструктур не существует единых рекомендаций «на все случаи жизни»; каждое решение зависит от приложения и организации (впрочем, это относится и ко многим другим технологиям).

Облачные вычисления могут сократить время развертывания и предоставить более детализированные средства контроля над использованием мощностей. Многие принципы управления мощностями, рассматривавшиеся ранее, в равной степени применимы к облачным инфраструктурам:

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

Область планирования роста за счет использования облачных инфраструктур продолжает развиваться. У облачного сервиса имеются свои ограничения, возможности, преимущества и недостатки по сравнению с запуском собственной инфраструктуры. Но если вам удастся построить качественный процесс планирования мощностей, вы сможете видоизменить свои методы планирования так, чтобы в них учитывались все эти обстоятельства.

SmugMug.com веб-сайт для размещения фотографий, в некоторых отношениях похожий на Flickr. Он поддерживает собственные вебсерверы и базы данных, но широко использует облачную инфраструктуру Amazon как для хранения данных (S3), так и для вычислений (ЕС2).

На момент написания статьи SmugMug.com использует свыше 600 Тбайт пространства в Amazon S3. Передача хранения данных в облако Amazon позволила сконцентрироваться на разработке новых функций. Сначала сервис S3 использовался в качестве резервного хранилища для сайта. Постепенно уверенность в производительности и надежности сервиса окрепла, и на S3 было переведено все первичное хранение данных, хотя у Amazon Web Services тогда еще не существовало соглашения об уровне обслуживания для этого сервиса (сейчас оно есть). Решение о перемещении хранения данных было принято легко, потому что руководство SmugMug увидело экономические преимущества и не хотело расширять персонал для организации внутреннего хранения данных.

Фотографии, отправленные в SmugMug, помещаются в очередь для отправки в ЕС2, где они преобразуются к нескольким размерам для использования на сайте и других операций по обработке. То же самое происходит с отправленными видеороликами. Обработанные материалы сохраняются непосредственно в S3. Конечно, описание получается чрезмерно упрощенным, но в процессе SmugMug использует достаточно интересную схему управления облаком.

Циклы обратной связи

SmugMug автоматизирует передачу и обработку видеороликов и фотографий в облако посредством организации очередей, что позволяет управлять частотой отправки заданий на обработку и количеством экземпляров, необходимых в каждый конкретный момент для обработки текущей нагрузки. Система SmugMug ежеминутно анализирует ряд метрик, чтобы принять решение о запуске или уничтожении вычислительных экземпляров по мере необходимости.

Некоторые из этих метрик:

• Текущее количество заданий, ожидающих обработки.
• Приоритеты заданий, ожидающих обработки.
• Типы заданий (фотографии, видеоролики и т. д.).
• Сложность заданий (HD-видео или фотография 1 мегапиксел)
• Критичность заданий, ожидающих обработки, по времени.
• Текущая нагрузка на экземпляры ЕС2.
• Среднее время выполнения задания.
• Исторические метрики нагрузки и производительности обработки заданий.
• Продолжительность запуска нового вычислительного экземпляра.

Учитывая все эти метрики, система SmugMug масштабируется с повышением или сокращением текущего количества используемых экземпляров ЕС2. Таким образом повышается эффективность обработки с использованием облачной инфраструктуры.

Сценарий SmugMug следует принципам, описанным ранее. Метрики прикладного и системного уровня объединяются с целью планирования мощностей, а собранные исторические данные используются для построения прогнозов. SmugMug хорошо знает свои потолки, отслеживает возможное приближение к ним и регулирует текущие мощности в пределах узкого, подвижного временного окна.

В случае SmugMug, принимая во внимание рассчитанную общую стоимость собственного вычислительного центра, желание фирмы избежать расширения штата и масштабов ее деятельности, применение облачной инфраструктуры для хранения данных и обработки было выгодно с экономической точки зрения.

Начинающая фирма решила использовать облачную инфраструктуру для размещения своей среды разработки, а также бета-версии своего сайта с ограниченным доступом. Сайт занимается индексированием хорошо известных источников новостей в Интернете. Далее компания обрабатывает полученные документы с применением алгоритмов естественных языков в поисках статей, представляющих интерес для ее пользователей. Для обхода источников новостей использовались вычислительные экземпляры, а для хранения как собранных, так и обработанных данных — облачные хранилища.

В ходе разработки сайта фирма заметила, что производительность приложения с его облачным хостингом изменяется без видимых закономерностей. Иногда при запуске новых экземпляров скорость работы заметно менялась от экземпляра к экземпляру, а обработка начинала необъяснимым образом «тормозить».

Кроме этого, так как вычисления были сопряжены с интенсивным использованием вычислительных мощностей, фирма запускала много малых экземпляров из меню поставщика услуг. По мере развития приложения, фирма начинала использовать все большее количество малых экземпляров, поэтому было решено перейти на более высокий уровень сервиса, чтобы получить доступ к большим вычислительным ресурсам. Но при всей привлекательности запуска меньшего количества «мощных» экземпляров для наращивания мощностей, действовавшие расценки делали его экономически неприемлемым. Таким образом, фирма была вынуждена продолжать использование множества маломощных экземпляров, сопряженное с пониженной производительностью работы с памятью и локальных подсистем ввода/ вывода. Ситуация была далеко не идеальной.

В меню предложений подходящего варианта не нашлось, и фирма сделала вывод, что она должна перейти на собственные системы, для чего приступила к изучению существующих возможностей. Тем временем поставщик облачного сервера внес изменения в свои расценки и предложил экземпляры «среднего» уровня, которые лучше соответствовали бюджету фирмы и ее потребностям в мощностях.

Этот пример наглядно показывает, что сервис облачных инфраструктур все еще развивается и продолжает приспосабливаться к потребностям клиентов в отношении конфигураций и средств управления.

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

WordPress.com обеспечивает хостинг свыше 2 миллионов блогов (на момент написания статьи) и получает свыше 30 миллионов просмотров страниц за день. Серверы компании установлены в трех вычислительных центрах, между которыми налажена репликация данных. Одно время это обстоятельство усложняло отправку мультимедийных материалов (видео аудио, фотографии) для пользователей, потому что у фирмы возникали проблемы с развертыванием нового дискового пространства. Фирма выбрала сервис Amazon Simple Storage Service (S3) для решения проблем резервного копирования/восстановления данных.

По мере накопления опыта использования сервиса в WordPress постепенно начали использовать S3 для основного хранения данных. Выбор в пользу облачною хранения объяснялся не экономическими причинами, на момент написания статьи затраты на S3 в 3-4 раза превышали затраты на приобретение собственной системы хранения данных и управление ею. В WordPress стремились к простоте развертывания и управления. Избавившись от проблем с использованием дискового пространства, они смогли сосредоточиться на других частях инфраструктуры и функциональности сайта. В сущности, WordPress планирует использовать S3 как «склад данных» почти бесконечной емкости.

Amazon Web Services (AWS) взимает плату за чтение и запись данных в своем облаке S3, поэтому WordPress кэширует контент, получаемый от S3, на своих собственных серверах.

Благодаря кэшированию часто запрашиваемых объектов (или объектов, которые оцениваются как «достаточно популярные» для кэширования) WordPress использует S3 с максимально возможной эффективностью. Кэширование помогает избежать лишних затрат на передачу данных, а также ускоряет предоставление контента с собственных серверов.

При подобной организации кэширование S3 превращается в почти бесконечный ресурс дискового пространства. WordPress не нужно беспокоиться об ограничениях и затратах, связанных с пошаговым наращиванием мощностей.

Означает ли это, что WordPress больше не занимается планированием мощностей? Вовсе нет. Остались системы кэширования (а также базы данных и веб-серверы), которые тоже должны масштабироваться, но это считается приемлемым, поскольку самым «больным местом» было хранение данных. WordPress с радостью переработала архитектуру хранения данных, чтобы больше не беспокоиться о ней.

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

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

В конечном итоге фирма решила создать собственную инфраструктуру. Решение было принято по нескольким причинам.

Отсутствие приемлемых соглашений об уровне обслуживания

В то время большинство проверенных поставщиков облачного сервиса предоставляло крайне ограниченные соглашения об уровне обслуживания (SLA). Фирма, не имевшая особого опыта работы в области Интернета, без энтузиазма отнеслась к тому, что надежность и качество работы с данными клиентов окажутся в руках третьей стороны (даже если это известный поставщик облачного сервиса). Отсутствие полноценного соглашения SLA сыграло значительную роль в их решении.

Юридические аспекты

Кто является фактическим владельцем пользовательских данных размещенных на серверах поставщика? Обладает поставщик облачного сервиса какими-либо правами на данные, которые физически хранятся на его серверах? Распространяются на хостинг какие-либо ограничения, действующие в отдельных странах или регионах? При рассмотрении юридической стороны пользовательских данных, конфиденциальности и надежности всегда анализируются всевозможные сценарии «что-если». В данном случае они тоже сыграли немаловажную роль в решении этой конкретной компании.

Затраты

Так как фирма была достаточно солидной, она располагала капиталом для самостоятельной организации хостинга данных. Экономика использования облачных услуг в данном случае отличалась от той, которая характерна для начинающего предприятия. Сопоставив оценку затрат на организацию собственного вычислительного центра с прогнозами популярности новых онлайновых возможностей продукта, фирма решила, что капиталовложения окупятся в долгосрочной перспективе. Решение базировалось как на расценках поставщиков облачного сервера на тот момент времени, так и на вычисленной общей стоимости владения (ТСО).

Другая серьезная причина для отказа от использования облачных мощностей имела нетехническую природу. Самостоятельная разработка позволяла хорошо изучить создаваемую систему. Фирма решила, что в случае сбоя она сможет решить проблему так, как того требует ситуация. Также фирме не хотелось перерабатывать архитектуру приложения для использования облачных услуг через соответствующие API. Наконец, было решено, что при необходимости фирма сможет перейти на облачный сервис в будущем, когда проявятся все закономерности использования онлайновых функций.

Стоит ли вам использовать сервис облачных вычислений для своего растущего веб-сайта? Короткий ответ: «Зависит». Длинный ответ: облачная инфраструктура, как и любая другая технология, имеет достоинства и недостатки. С одной стороны, вы избавляетесь от хлопот с развертыванием и обеспечением работоспособности — это может быть достаточно убедительным мотивом для перехода. С другой стороны, вы в некоторой степени лишаетесь полного контроля над происходящем, к которому вы возможно, привыкли.

Облачные вычисления все еще находятся на ранней стадии развития, и разнообразие предложений слишком велико, что не позволяет выработать конкретные эвристические решения и формальные рекомендации. Тем не менее истории и примеры помогут вам решить, попадаете ли вы в число потенциальных пользователей, и понять, какие факторы следует учитывать при принятии решения.

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

Эти примеры показывают, насколько разные потребности, проблемы и преимущества использования облачных инфраструктур встречаются в разных организациях.

Когда инфраструктура находится в вашем распоряжении, у вас имеется много вариантов для измерения текущих мощностей. Инструменты сбора метрических данных для создания истории использования и построения трендов, мониторинг событий изменения критических порогов и, конечно, средства ситуативной диагностики уровня ОС — обо всем этом было уже написано.

Так как облачная инфраструктура во многих отношениях представляет собой «черный ящик», а большинство поставщиков предлагает относительно ограниченное меню с выбором ресурсов, важность эффективного сбора метрик становится еще более очевидной. Даже при том, что облачный сервис способен значительно сократить время развертывания, вы все равно должны следить за остальными компонентами процесса планирования мощностей. Поиск потолков по-прежнему остается необходимостью, как и развертывание новых экземпляров в опережение роста.

В случае потребления дискового пространства прогнозирование можно возложить на вашего провайдера, опережать потребление — это его задача. Однако в случае вычислительных экземпляров объем фактической «работы», которая ими выполняется, в значительной мере зависит от размера/класса экземпляра, а также использования ресурсов приложением (которое тоже, разумеется, зависит от размера/класса экземпляра). Кроме обычных причин для сбора метрической информации по мощностям облака, существуют и другие причины для организации сбора метрик и оповещения о событиях:

• Производительность любого экземпляра и хранилища может изменяться по мере того, как поставщик облачного сервиса перераспределяет мощности с целью адаптации архитектуры к повышению нагрузки.
• Даже если поставщик предоставляет соглашения об уровне обслуживания (SLA), очень важно знать, когда на ваших экземплярах или в хранилищах происходят сбои. Полезное правило: верь, что инфраструктура доступна… но проверяй. Возможно, развертывание новых мощностей в облаке выполняется быстро, но не мгновенно. Время запуска нового экземпляра стоит измерить.
• Хотя облачные хранилища могут автоматически масштабироваться в соответствии с потреблением дискового пространства, скорость выборки данных из хранилища не гарантирована, Как и в случае с ограничениями базы данных по интенсивности дискового ввода/вывода, пропускная способность хранилища может стать фактором, влияющим на мощности, и ее также следует измерить, Это относится и к операциям ввода/вывода с любыми «локальными» хранилищами, выполняемыми вашими вычислительными узлами.

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

У снижения прозрачности есть и свои преимущества. Она позволяет поставщику свободно вносить изменения в свою архитектуру (которые могут сделать возможным быстрый запуск новых экземпляров), а клиент освобождается от низкоуровневых проблем, связанных с масштабированием мощностей. Но снижение прозрачности также означает, что вы можете не располагать всей подробной информацией по своему усмотрению, особенно если вы привыкли иметь все данные под рукой.

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

Большинство поставщиков различных категорий облачных вычислений предоставляет «меню» вычислительных экземпляров, от простейших платформ с маломощными процессорами и малым объемом памяти до крупномасштабных систем с многоядерными процессорами и гигантскими объемами памяти. Выбор системы не так гибок, как при сборке принадлежащего вам оборудования, поэтому при определении потребностей приходится подбирать наиболее подходящий вариант из предлагаемых. Решения с большим количеством маломощных экземпляров бывают предпочтительнее решений с меньшим количеством мощных экземпляров, хотя все зависит от приложения. Пример меню облачной инфраструктуры показан на рисунке.

Как упоминалось ранее, в традиционном контексте развертывания собственного оборудования на закупку и согласование в организации может потребоваться некоторое время, так как приобретение оборудования является капиталовложением. Но в облачных инфраструктурах, разделяющих эту концепцию на небольшие затраты там и сям, останется ли процесс согласования тем же самым? Возможно, ваш системный администратор не имеет полномочий для закупки 10 серверов без предварительного согласования с фирмой. А есть ли у него полномочия для запуска произвольного количества экземпляров использующих значительные облачные мощности, которые со временем обойдутся в такую же сумму?

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

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

С точки зрения планирования облачные хранилища и вычислительные экземпляры следует рассматривать как очередной ресурс. Как и в односерверной парадигме, при использовании облачной архитектуры в вашем распоряжении оказываются определенные объемы процессорного времени, оперативной памяти, дискового пространства (с возможностью долгосрочного хранения данных или без нее) и пропускной способности сети (входной и выходной).

Каждый облачный ресурс, по аналогии с ресурсами традиционных инфраструктур, обладает собственными потолками и стоимостью. Во многих отношениях процесс планирования мощностей совершенно не изменяется:

• Измерьте текущее состояние потребления (количество экземпляров, вычислительные мощности, дисковое пространство).
• Определите потолки (когда необходимо запустить/уничтожить новый экземпляр?).
• Составьте прогноз на основании истории использования.

Зачем составлять прогнозы, если время развертывания измеряется в минутах? Во-первых, задача прогнозирования не сводится к своевременной закупке и развертыванию.

Перспективность облачных вычислений заключается в том, что мощности могут легко (не обязательно автоматически!) наращиваться «по требованию». Так как каждый экземпляр фактически является покупкой, многие поставщики услуг облачных вычислений передают контроль за экземплярами в руки клиентов, а решение о запуске новых экземпляров (и их количестве) может сыграть исключительно важную роль в свете возможных выбросов трафика. Процесс использования облачных вычислений может автоматизироваться, но автоматизация должна быть очень аккуратной, чтобы она реагировала не только на поведение под нагрузкой веб-сайта, но и на поведение самого облака. Пример такой «оптимизации обратной связи» будет приведен чуть позднее.

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

Решетчатые вычисления, облачные вычисления и службы, управляемый и виртуальный хостинг, вспомогательные службы… Как и во многих развивающихся технологиях, терминология порой бывает весьма запутанной. Концепция облачных вычислений еще не получила четкого, недвусмысленного толкования. Фирмы-поставщики, маркетологи, консультанты, поставщики услуг распространяют этот термин на практически любые сценарии, в которых унифицированная масштабируемая инфраструктура предоставляется многим пользователям на условиях оплаты потребляемых ресурсов.

Даже маркетинговые службы компаний, специализирующихся на предоставлении услуг облачных вычислений признают существование некоторой путаницы. Далее перечислены самые общие категории облачных вычислений:

• Облачная инфраструктура. Службы типа Amazon Web Services или FlexiScale. Низкоуровневые элементы таких служб формируют некий аналог управляемой среды хостинга. Управление многими функциями, включая возможность повышения или снижения мощностей, осуществляется через специальный API. Сейчас в этой категории в основном предоставляются вычислительные ресурсы и пространство для хранения данных.
• Платформенные облака. Такие службы, как Google АрpEngine, позволяют клиентам создавать код, выполняемый (с соблюдением определенных ограничений) в специализированной среде, абстрагированной от базовой операционной системы и аппаратных ресурсов. Веб-приложениям предоставляется доступ к нереляционной базе данных, которая расширяется или сокращается по мере необходимости (в заранее оговоренных пределах).
• Прикладные облака. Браузерные приложения Salesforce.com, которые создаются фирмой-поставщиком для конкретных целей и предоставляют доступ к API-приложениям, построенным на их основе. Также известны под названием SaaS (Software as a Service, программное обеспечение как услуга).

Растущие веб-приложения в основном обращались к решениям первой категории для масштабирования своей back end инфраструктуры, но, как я уже сказал, эта технология все еще находится на стадии бурного развития. Уровни абстракции, среды разработки и ограничения развертывания по каждому типу облачных вычислений могут подходить для одних приложений и не соответствовать потребностям других.

В категории облачных инфраструктур встречается немало примеров успешного перевода критически важных операций на эту модель. Некоторые примеры будут представлены ниже.

Облачная инфраструктура во многих отношениях является следующим шагом на пути эволюции парадигмы использования компьютеров, которая началась с мейнфреймов. Как показано на рисунке провайдеры облачных услуг занимаются построением, управлением и обслуживанием всего физического оборудования, организованного в виде виртуализированного облака, причем их клиентами могут быть как физические лица, так и коммерческие организации.

По сути, архитектура облачных вычислений базируется на крупномасштабной виртуализации. Существуют разные типы облачных инфраструктур, но доминирующее положение среди них занимают вычислительные экземпляры и облачные хранилища.

Вычислительные экземпляры (compute instances) фактически представляют собой виртуальные ОС, в которых выполняется код вашего приложения. Такие экземпляры строятся, уничтожаются и восстанавливаются по требованию пользователя. Они могут располагать (или не располагать) средствами долгосрочного хранения данных, так что уничтожение экземпляра может привести к стиранию записанных в нем данных.

Облачное хранилище (cloud storage) предназначено прежде всего для хранения данных, а оплата осуществляется по установленным нормам потребления в виде абонентской платы за чтение и запись данных в хранилище.

Каждый уровень облачного сервиса обслуживается комплексом серверов, будь то «чистая» подсистема хранения данных (в случае распределенной файловой системы) или изменяемые кластеры вычислительных узлов, которые создаются для обеспечения работы гостевых экземпляров операционной системы клиента.