Partly cloudy Построение отказоустойчивых систем в AWS минимальными средствами
Partly cloudy
Построение отказоустойчивых систем в AWS минимальными
средствами
Евгений Потапов
10 лет опыта веб-разработки
3 года опыта использования облачных технологий
генеральный директор компании «Сумма АйТи»
Поддержка высоконагруженных веб-сайтов
90 миллионов уникальных посетителей в сутки
113 инстансов на поддержке в Amazon AWS
Использовали AWS, Softlayer Cloudlayer, Rackspace Cloud, Scalaxy
Amazon Web Services с точки зрения эксплуатации
Переход работающих проектов
Использование особенностей облака минимальными средствами
Построение отказоустойчивых систем в AWS минимальными средствами
Реальную сущность облаков
Не думаем о стоимости внедрения
Верим в чудо
Мы забываем
Владельцы хотят
Высокой надежности
Простой масштабируемости
Платить за используемые ресурсы
новостей за сутки
13
Показывают яндекс.новости по запросу «Облачные вычисления»
Ложные причины перехода в AWS
Искажение реальности
Потеря доверия к текущей хостинг-площадке
Полный переход в AWS
Решение станет дорожеОтказоустойчивости по умолчанию нетПоявляются новые проблемы
Процессор: Quad Core Xeon 3450 2.66GHz w/HTОперативная память: 8GB DDR3 Registered 1333Дисковая подсистема: 4x500GB SATA HDD, RAID 10 Траффик: 5000 гигабайтПропускная способность: 1 гигабит
Процессор: High-CPU Extra Large Instance (8 virtual cores)Оперативная память: 7 GB of memoryДисковая подсистема: EBS 1000GBТраффик: 1000 гигабайтПропускная способность: не контролируется
$399
$5011yr upfront: $2000, Instance: $0.16 per hour($2000 / 12) + ($0.16*24*30) = $166.6+$115.2EBS: 1000GB = 1000 * $0.01 = $100Траффик – 1000GB = $0.12*1000 = $120$166+$115+$100+$120 = $501
Но может быть AWS надёжнее?
Даунтайм: 53 часа (21 апреля 2011 года)
Причина: нарушение маршрутизацииЗона: US EastНачало аварии: 12:47 29.04.2011Конец аварии: 18:15 23.04.2011
21 апреля 2011 года
Мы понимаем то значение, которое оказало это событие на наших клиентов, Мы хотим извиниться, и хотим сказать что мы сделаем выводы из этого происшествия.
http://aws.amazon.com/message/65648/
Даунтайм: 36 часов (7 августа 2011 года)
Причина: отказ подстанцииЗона: EU WestНачало аварии: 10:41 07.08.2011Конец аварии: 20:25 08.08.2011
7 августа 2011 года
Мы понимаем то значение, которое оказало это событие на наших клиентов, Мы хотим извиниться, и хотим сказать что мы сделаем выводы из этого происшествия.
http://aws.amazon.com/message/2329B7/
Даунтайм: 7 часов (29 июня 2012 года)
Причина: отказ подстанцииЗона: US EastНачало аварии: 19:24 29.06.2012Конец аварии: 02:45 30.06.2012
29 июня 2012 года
Мы извиняемся за те неудобства, которое оказало это событие на наших клиентов… Мы проведем много часов делая выводы из этого происшествия.
http://aws.amazon.com/message/2329B7/
Uptime 100%
Во всех случаях авария затронула несколько Availability зон в пределах одной географической
локации
Специфика виртуализации
EBS тормозит
Специфика виртуализации
Производительность EBS нестабильнаhttp://blog.scalyr.com/2012/10/16/a-systematic-look-at-ec2-io/
Специфика виртуализации
Пропускная способность непропорциональна типу инстанса
Но, хорошие решения существуют
1 Гибридный бэкап
Текущий хостинг в основном устраивает
Допустим «откат» в данных на период последнего бэкапа
Бюджет минимален
(показания к применению)
1 Гибридный бэкап
Сайт находится на физическом хостинге все время, кроме аварийных ситуаций
В AWS находятся только образы подсистем проекта и регулярные бэкапы, которые поднимаются только в случае аварии
(особенности решения)
1 Гибрный бэкап(нормальный режим)
1 Гибридное облако(авария на физической площадке)
1 Гибридный бэкап
Время простоя – время между реакцией на падение физического хостинга и окончательным запуском всех сервисов в AWS
Данные актуальны на дату последнего бэкапа
Необходимо поддерживать две разные площадки
(минусы решения)
1 Гибридный бэкап
Необходимо поддерживать актуальное состоние AMI и EBS Snapshot-ов
Код проекта должен быть абстрагирован от текущего хостинга
Стоит запланировать регулярные процедуры перехода в «резервное» облако
(рекоммендации)
2 Бюджетное облако
Текущий хостинг в основном устраивает
При failover в резервную платформу данные должны быть актуальны
Бюджет чуть менее минимален
(показания к приминению)
2 Бюджетное облако
Проект находится на физическом хостинге, но реплицируется на минимально возможную конфигурацию в Amazon
Минимальная конфигурация масштабируется до необходимой в случае аварии
Стоимость резервирования равна стоимости минимально выдерживающего процесс репликации инстанса
(особенности решения)
2(нормальный режим)
Бюджетное облако
2(авария на физической площадке)
Бюджетное облако
2 Бюджетное облако
Время простоя – время между реакцией на падение физического хостинга и окончанием масштабирования инстанса
(минусы решения)
2 Бюджетное облако(рекоммендации)
«Минимальная конфигурация» должна быть способна выдержать входящий поток репликации
За самим процессом репликации следует следить
Переход ради масштабирования
«Взять слабый инстанс и автоматически масштабировать его при росте нагрузок в пиковые часы»
Переход ради масштабирования
Вертикальное масштабирование:Апгрейд инстанса – 4-10 минут
Горизонтальное масштабирование: Создание инстанса – 5-10 минут
3 Горизонтальное масштабирование v.1
Текущий хостинг всем устраивает, но нагрузка возрастает в сезонные периоды (т.е. праздники, выходные и т.д.)При появлении пиковой нагрузки можно некоторое время «потормозить»
Бюджет сравним с «гибридным бэкапом»
(применение)
3 Горизонтальное масштабирование v.1
Вариация «Бюджетного клауда».
Проект находится на физическом хостинге, реплика хранится в AWS
При необходимости масштабирования необходимое количество инстансов запускается в AWS и синхронизируется с «минимального» инстанса.
(особенности решения)
3 Горизонтальное масштабирование v.1
(нормальный режим)
3 Горизонтальное масштабирование v.1
(рост нагрузки, синхронизация)
3 Горизонтальное масштабирование v.1
(итоговое состояние)
3 Горизонтальное масштабирование v.1
До запуска в AWS конфигурации способной выдержать текущую нагрузку скорость актуальность данных будет ограничиваться пингом между площадками
Если до этого горизонтальное масштабирование не использовалось - большие усилия направленные на изменения архитектуры проекта
(минусы решения)
3 Горизонтальное масштабирование v.1
При использовании решений не поддерживающих multi-master архитектуры необходимо учитывать наличие только одной (двух) мастер-машин (либо использовать циркулярную репликацию)Очень легко масштабировать чтение, очень сложно масштабировать запись (синхронизация данных при удалении инстанса)
(рекомендации)
4 Горизонтальное масштабирование v.2
Текущий хостинг всем устраивает, но нагрузка возрастает в короткий промежуток времени (часы)При появлении пиковой нагрузки нет времени на синхронизацию данных – данные должны быть актуальны
(применение)
4 Горизонтальное масштабирование v.2
Проект целиком находится в AWS, классический облачный хостинг Минимальный пинг между отдельными компонентами системы
Для резервной конфигурации расходы остаются небольшими
(плюсы решения)
4 Горизонтальное масштабирование v.1
(нормальный режим)
4 Горизонтальное масштабирование v.2
(рост нагрузки)
Специальные сервисы
EC2 Spot Instances
Amazon Route 53
Amazon ELB
Amazon Glacier
Специальные сервисы
Spot Instances: Amazon позиционирует spot instances как инструмент для cloud computing
Действительно, можно взять EC2-инстанс высокой конфигурации за небольшие деньги.
Этот инстанс будет остановлен как только кто-то предложит большую ставку при дефиците инстансов.
Специальные сервисыRoute 53: сервис работает хорошо, но amazon.com использует другие NS
amazon.comamazon.com nameserver = ns4.p31.dynect.net.amazon.com nameserver = pdns1.ultradns.net.amazon.com nameserver = pdns2.ultradns.net.amazon.com nameserver = pdns3.ultradns.org.amazon.com nameserver = pdns4.ultradns.org.amazon.com nameserver = pdns5.ultradns.info.amazon.com nameserver = pdns6.ultradns.co.uk.amazon.com nameserver = ns1.p31.dynect.net.
Специальные сервисы
ELB: последнее падение затронуло ELBПроекты которые полагались только на ELB в пределах одного региона оказались недоступны на весь период времени
Специальные сервисы
Glacier: высокая стоимость восстановления данных
Дешевизна и надежность архивирования компенсируется стоимостью и скоростью выгрузки данных:
«Стоимость выгрузки 3 терабайт данных может дойти до $22082» http://news.ycombinator.com/item?id=4412886
Точка зрения
Реально оценивайте пользу от облаков
Эффективные решения находятся в области комбинирования подходов
Всегда читайте, что написано мелким шрифтом
Евгений Потапов
http://[email protected]://twitter.com/eapotapov
Построение отказоустойчивых систем в AWS минимальными средствами