Как жить в облаке без админов?

Александр Демидовруководитель направления арендных решений

«1С-Битрикс»

Никак…

До 2012 года…

Два основных продукта:

Единственное, что требовало того или иного обслуживания – наш собственный сайт.

В настоящее время…

CRM CDN

бэкапфайлысканер безопасности

??

видеозвонки push

Облачные сервисы

Битрикс24 – SaaS «Корпоративный портал»

Более 7000 наиболее активных порталов

Ускорение сайта – интеграция с CDN

Около 9000 сайтов

Облачный бэкап

Более 7500 сайтов

Анонс новых сервисов осенью 2013

Примерно 2 стойки 42U – если без виртуализации

Два человека – у которых админство не является основной деятельностью

Разные классы сайтов и веб-сервисов:

Домашние странички, личные блоги и т.п.«Продающие» сайты (интернет-магазины)Имиджевые сайты (в том числе и корпоративные)«Business critical application» - веб-сервисы, использующиеся в работе (CRM, учет, таск-менеджмент, почта и т.п.)

Разные стадии проекта:Инвестиции, развитиеВыход на операционную прибыль

Что ожидаем от проекта?

Облако!

Быстро, качественно (надежно), дешево!

Marketing bullshitВыберите любые два пункта…

Не дешевле?

В прямом сравнении железа и аналогичного по конфигурации облака – облако почти всегда проигрывает

Почти всегда отдельно рассчитывается стоимость траффика

Сложность расчетов при оплате «по потреблению»

При оплате «по потреблению» при резком росте нагрузки (DDoS, «хабраэффект», ошибки в разработке) возможны значительные расходы (в разы больше запланированных)

Как минимум – не надежнее…

Надежность?

Виртуальные машины ребутятся чаще физического «железа».

Amazon AWS – как минимум:

апрель 2011, август 2011, июнь 2012, декабрь 2012…

«Лежали» Foursquare, Instagram, Netflix, Pinterest…

Масштабирование в облаке?

Без готовности приложения к масштабированию – не имеет практического смысла

Есть выделенные ресурсы – RAM, CPU, HDD: попросил-выделил-заплатил

Есть разделяемые ресурсы – кэш процессора, IOPS... Почти ни у одного облака нельзя попросить обеспечить N IOPS в течение K минут. Можно только понадеяться.

Инфраструктура: «Железо» vs. «Облако»

- Медленные диски

- Нельзя гарантированно получить некоторые ресурсы

- Ложное ощущение гарантий безопасности и отказоустойчивости

+ CPU и RAM – по требованию

+ Возможность построить масштабируемую инфраструктуру

+ Возможность построить отказоустойчивую инфраструктуру

Инфраструктура: «Железо» vs. «Облако»

- Затраты (время) на обучение сотрудников специфике конкретного сервиса

- Ограничения инфраструктуры (аппаратная часть, специфичное ПО)

- Сложность расчетов «по потреблению»

+ Экономия за счет возможности планирования ресурсов

+ Экономия и отсутствие рисков, связанные с вложениями в инфраструктуру

+ Моментальное вертикальное и горизонтальное масштабирование

+ Удобство администрирования

+ Экономия времени

+ Дополнительные сервисы

Правильное облако

Правильное облако

Несколько территориально распределенных ДЦ (с возможностью их выбора)

Гибкое управление дисками

Облачные базы данных, кэш, NoSQL, балансировщики, DNS, мониторинг, сервисы очередей, файловые хранилища, CDN и т.д.

API и готовые SDK для управления всеми сервисами

Модульность приложения

И его готовность к масштабированию

Админы пока еще не нужны…

Нужен аналитик…

Админы пока еще не нужны…

…и архитектор.

Elastic Load Balancing

Web 1

Elastic Load Balancing

DynamicHTTPS

*.com/*.de

Web N

…CloudWatch + AutoScaling

Web 1 Web 2 Web N

…CloudWatch + AutoScaling

Резервируй это!

S3

management, monitoring,

backup

StaticHTTPS

*.com/*.de

CDN (Amazon CloudFront)

js, css

DynamicHTTPS

*.ru

StaticHTTPS

*.ru

CDN (CDNvideo)

js, css

imag

es (c

lient

s)

imag

es (c

lient

s)

local cache (APC)

local cache (APC)

local cache (APC)

local cache (APC)

local cache (APC)

control cache: memcached

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

master-master replication

master-master replication

master-master replicationmysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

mysqld

control cache: memcached

control cache: memcached

control cache: memcached

control cache: memcached

control cache: memcached

Web 2

local cache (APC)

Real Time мониторинг – как узнавать о проблемах?

Можно – так…

Real Time мониторинг – как узнавать о проблемах?

Или – так…

Организация системы мониторинга

Лучше – стандартные решения (Nagios, Zabbix и т.п.), а не самописные.

Дежурная смена и/или мгновенные уведомления.

Мониторить – всё.

Но – аккуратно. Тысячи уведомлений будут бесполезны.

Мониторить систему мониторинга.

Автоматизация типовых реакций.

Автоматизация типовых реакций

Рост / падение LA – автоматическое масштабирование вверх / вниз

Автоматический рестарт «сбойных» сервисов

Автоматическое «удаление» проблемных машин

Автоматическое восстановление репликации

Автоматическое переключение траффика в случае аварии на уровне целого ДЦ

Мониторинг веб-приложения

Лог работы скрипта (>) – обновился за N часов

Лог ошибок работы скрипта (2>) – должен быть пуст

Мониторинг нетипичных характеристик

Наличие бэкапов

Срок делегирования доменов

Срок действия SSL сертификатов

Баланс у провайдера смс-уведомлений

Аналитика

Видим, что было

Предвидим, что будет

Улавливаем тренды

Планируем мощности железа

Сравниваем настройки софта

Веб-система перестает быть черным ящиком, видно ее

развитие с течением времени

Аналитика

Аналитика – со стороны пользователя

Гистограммы распределения времени хитов, памяти, кодам ответа и т.п. – из логов (awk-скрипт), pinba или других инструментов

Мало знать «среднюю температуру по больнице» и мониторить только главную страницу сайта

Поиск узких мест

Pinba, XDebug, XHProf

Приложение всегда работаетв условиях ограниченных ресурсов

Постоянный feedback разработчикам – в автоматическом и полуавтоматическом режиме

Резюме

Систему в облаке можно поддерживать, обходясь минимумом человеческих ресурсов

• Выбирайте правильное облако – с максимально широким набором сервисов, API и т.п.

• Ваше приложение должно быть готово к горизонтальному масштабированию

• Резервируйте все

• Обязательно используйте системы мониторинга

• Автоматизируйте все типовые действия

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

Спасибо за внимание! Вопросы?

Александр Демидов

demidov@1c-bitrix.ru

+7-926-521-3700

@demidov

http://www.1c-bitrix.ru