Масштабирование облачной инфраструктуры

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

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

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

Планирование мощностей

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

В этой главе мы рассмотрим основные вопросы, относящиеся к масштабированию в облачной среде.

± Изучение статистики использования, меняющейся в зависимости от времени суток, дней недели, праздничных дней и сезонных колебаний в вашем бизнесе.

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

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

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

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

Ожидаемые потребности

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

± спланировать инфраструктуру, которая будет поддерживать ожидаемые нагрузки;

± определить, когда фактическая нагрузка начинает значительно отличаться от ожидаемой;

± понять, как изменяющиеся потребности вашего приложения влияют на вашу инфраструктуру.

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

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

Рассмотрим, к примеру, сценарий, при котором вам необходимо создать такую инфраструктуру, которая обеспечивает поддержку 10 миллионов транзакций в секунду, и вы ожидаете, что при пиковых нагрузках вам необходимо будет поддерживать увеличение нагрузки в диапазоне от 1 до 5 миллионов транзакций в секунду по сравнению с этим средним значением. Если вы правильно оцените нагрузку, вы сможете определять, является ли внезапный выброс ожидаемым (и в этом случае беспокоиться не о чем) или неожиданным (в таком случае за ним нужно понаблюдать и принять меры, чтобы избежать потенциальных проблем с производительностью). Без надлежащей оценки ожидаемой нагрузки вы не сможете понять, что следует делать в случае резких колебаний нагрузки.

Определение ожидаемых потребностей

На рис. 7.1 и 7.2 представлены графики, отражающие ожидаемый трафик сайта системы электронной коммерции в течение типичного рабочего дня и предполагаемые пиковые нагрузки на ближайшие 12 месяцев.

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

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

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

Рис. 7.1. Предполагаемое распределение дневной нагрузки на сайт системы электронной коммерции

Рис. 7.2. Ожидаемое распределение нагрузки на сайт системы электронной коммерции на ближайшие 12 месяцев

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

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

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

Анализ неожиданностей

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

Влияние нагрузки

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

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

± Полоса пропускания канала связи к балансировщику нагрузки.

± Ресурсы CPU и RAM на балансировщике нагрузки.

± Способность балансировщика  нагрузки правильно распределять нагрузку по серверам приложений.

± Полоса пропускания каналов связи, связывающих балансировщик нагрузки и серверы приложений.

± Ресурсы CPU и RAM на сервере приложений.

± Производительность дисковой подсистемы для операций чтения на сервере приложений.

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

± Ширина полосы пропускания канала связи между сервером приложений и сетевыми устройствами хранения данных (например такими, как эластичные блочные устройства Amazon (Amazon EBS).

± Ширина полосы пропускания канала связи между сервером приложений и сервером базы данных.

± Производительность дисковой подсистемы для операций записи не сервере базы данных.

± Производительность дисковой подсистемы для операций записи на сервере главной базы данных.

± Свободное дисковое пространство для поддержания потребностей в хранении данных.

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

К вопросу об архитектуре приложений и баз данных

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

± используйте как можно более скоростные устройства хранения данных для ускорения доступа к базе данных;

± избегайте хранения транзакционных данных на уровне сервера приложений;

± создайте несколько копий сервера приложений, работающих с одной и той же базой данных, причем эти серверы приложений не должны взаимодействовать друг с другом;

± правильно индексируйте свою базу данных;

± по возможности используйте архитектуру "главный/подчиненный" и перенаправляйте операции чтения на подчиненные серверы;

± работая в Amazon EC2, планируйте избыточность таким образом, чтобы минимизировать трафик, пересекающий границы зон доступности.

Шкалы масштабирования

В зависимости от вашего приложения наиболее вероятными участками напряженности окажутся следующие три компонента:

± CPU на сервере приложений;

± объем RAM на сервере приложений;

± дисковая подсистема (ввод/вывод) на сервере базы данных.

Каждое приложение имеет свои "узкие места". Если бы это было не так, то любое приложение могло бы работать на старом компьютере Intel 386 под неограниченно высокой нагрузкой. Например, для приложения Valtira (Web-приложение, написанное на Java, которое я проектировал для одноименной компании) первым "узким местом" всегда является CPU на сервере приложений. Поскольку приложение масштабируется горизонтально, CPU перестает быть слишком серьезным фактором, но (в зависимости от информационного наполнения, с которым работает Valtira) мы сталкиваемся с еще одним "узким местом" — это будет либо полоса пропускания сети, либо производительность подсистемы дискового ввода/вывода. В облачной среде этим "узким местом" обычно становится производительность дискового ввода/вывода.

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

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

1 Чтобы иметь возможность отделить операции чтения от операций записей, вам необходимо обеспечить в вашем приложении защиту от "грязной записи", о чем подробнее рассказывалось в главе 4. О феномене "грязной записи" (dirty writes) подробнее см. здесь: http://www.rsdn.ru/article/db/deadlocks.xml.

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

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

Источник: Риз Дж., Облачные вычисления: Пер. с англ. — СПб.: БХВ-Петербург, 2011. — 288 с.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете промотать до конца и оставить ответ. Pinging в настоящее время не допускается.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100