«Облака были созданы, потому что все задолбались»: в чём отличие облачной инфраструктуры от своих серверов

Публичные облака появились как ответ на мучения компаний, которые поддерживали парк собственных серверов. Слишком много проблем возникало с заказом оборудования, его настройкой и поддержкой, поэтому облачные вычисления быстро стали востребованными — так считает Александр Волочнев, Developer Advocate в DataStax и автор видеокурса по AWS в «Слёрме». 

Боли сисадминов и бизнеса, а также возможности, которые принесли им облака, Александр Волочнев подробно описал на вебинаре «Создание эффективной инфраструктуры при помощи облачных решений». Запись вебинара есть на YouTube, здесь публикуем краткую выжимку.

Проблемы поддержки своей инфраструктуры

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

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

При поддержке своего парка серверов компании сталкивались и продолжают сталкиваться с несколькими крупными проблемами.

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

Высокая стоимость и низкая надёжность. Система либо хрупкая, либо очень дорогая. А часто и хрупкая, и дорогая.

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

Например, AWS работает регионами и зонами доступности. Регион — это несколько центров обработки данных, размещенных вместе. Зона доступности — это конкретный ЦОД, обязательно удалённый от соседей, имеющий независимое подключение к интернету и энергопитанию. Вот это настоящая распределённость и отказоустойчивость.

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


Режим экономии vs режим производительности: либо отказы в обслуживании на пике, либо переплата 

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


Идеальная ситуация: мощности и затраты на них меняются под задачи бизнеса

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

Так появился Amazon Web Services (AWS) и такой вид услуг, как облака.

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

Что такое облако

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

Теперь представим, что вместо этого руководство выбирает IaaS (Infrastructure as a Service, инфраструктура как услуга). В этом случае часть задач по организации инфраструктуры забирает облачный провайдер. ЦОД уже есть, он построен и отвечает самым высоким требованиям надёжности (по крайней мере, в случае с крупными провайдерами вроде AWS или Google Cloud). Хранилища, сети и виртуализацию тоже настраивает провайдер.

Таким образом компании остаётся только подготовка окружения для работы с данными и их администрирование. У инженеров освобождается время на развитие, улучшение, прокачку, оптимизацию. Они начинают больше участвовать в процессе разработки, появляется DevOps.


Распределение по обязанностям

Со временем облачные провайдеры развивали услуги и в дополнение к IaaS появились такие подходы, как Platform as a Service (платформа как сервис) и Software as a Service (приложение как сервис).

Для примера предположим, что в компании разработали приложение и хотят его запустить. В случае с IaaS, нужно войти в веб-интерфейс AWS, создать виртуальную машину. Операционная система уже будет установлена, но настраивать её придётся самостоятельно. Самим придётся устанавливать необходимый софт и разбираться в работе с данными.

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

И наконец, Software as a Service — приложение как сервис, когда вы просто используете какую-то услугу и не заботитесь ни о чём.


Дополнительные возможности

Особенности облака: «чёртова магия!»

Рассмотрим ключевые особенности облаков. В примерах часто упоминается Amazon Web Services (AWS), потому что с этой компании всё началось, и сейчас они лидеры на рынке облачных услуг.

On-Demand Self-Service — самообслуживание. Возможность по требованию, ни к кому не обращаясь, получить всё необходимое. Без телефонных звонков, без пересылки документов почтой, без ожидания в несколько месяцев — сразу.

Fast Flexibility (0 → 100 → 10) — «быстрая» гибкость. Сегодня компания не арендует ни одного сервера, завтра возьмёт сто машин, а послезавтра — десять. Очень быстро и гибко.

Resource Pooling — шаринг ресурсов. На одном железном сервере могут храниться данные разных компаний: профили нагрузки не совпадают, и они друг другу не мешают, зато оба платят меньше, чем за выделенный сервер — концепция многоквартирного дома. Однако не все любят многоквартирные дома. Тогда можно сказать: «хочу выделенный сервер», и вы это получите. Естественно, цена будет выше.

Elastic Scalability — гибкая масштабируемость. Сегодня нужно 10 серверов, завтра понадобится 100, послезавтра снова 10. С облаками не надо думать, где взять столько. Можно просто использовать и закрывать, когда необходимость отпадёт. 

Measured Service — измеряемый сервис. Потребление ресурсов измеряется до бита и микросекунды, чтобы пользователь действительно оплачивал только то, что было потреблено. AWS первыми ввели посекундную тарификацию серверов. 
     
Pay as you Go — оплата по мере потребления. Большинство облачных провайдеров берут оплату постфактум. Но если пользователь знает, что сервер будет нужен и завтра, и через год, он может платить и по-другому: сразу за весь период или по частям. За это предусмотрена скидка.

В AWS есть три способа получить сервер: on-demand — оплата по факту потребления; reserved — оплата за год вперёд, целиком или частями; spot instances — оплата по типу аукциона. В последнем случае пользователи устанавливают цену, которую готовы платить за Spot Instance, и сервер уходит к тому, кто заплатил больше. Система не самая надёжная, зато скидки могут достигать 90%. Spot Instance подходит для отложенного выполнения задач, когда скорость обработки не так важна, как стоимость.

Global Availability / Distribution — глобальная доступность. AWS имеет 22 региона и 77 центров обработки данных по всему миру, плюс около 200 точек присутствия. Похожая инфраструктура у Azure и Google Cloud. Благодаря этому клиенты облачных сервисов могут использовать свои приложения, управлять своими данными глобально. Если компания работает в одном регионе, а клиенты живут в другом, тогда можно настроить всё так, чтобы подключение от клиента шло сначала во внутреннюю сеть AWS и оттуда уже на высоких скоростях попадало в регион компании.

Programmable Access / Management — программный доступ и программное управление. Раньше для заказа серверов приходилось звонить поставщикам, объяснять свои задачи, ждать коммерческое предложение, опять звонить… Связаться с AWS по телефону может только очень крупный клиент. Время стоит дорого, поэтому всё делается через веб-интерфейс, интерфейс командной строки и программный менеджмент. 

Если нужно оптимизировать мощности серверов в зависимости от трафика, то достаточно один раз настроить AutoScaling Group — группу автоматического масштабирования для серверов, мониторинг и триггеры. После этого AWS будет сам создавать и удалять серверы в зависимости от нагрузки. Клиент получает масштабирование с минимальной переплатой и полностью автоматическим управлением. 

«Программный доступ, программирование вашей инфраструктуры — это реально чертова магия, я это просто обожаю!»

AWS предлагает около 250 служб для самых разных задач. Если говорить про инфраструктуру, то здесь есть и базы данных, и сетевые хранилища, и вообще всё. Нет такой отрасли, для которой они еще что-то не предложили. Посмотрите на скриншот, в левом нижнем углу есть вкладка «Satellite» — управление спутниками. То есть при желании в AWS можно работать со спутниками!

Услуги AWS

Фактически в AWS есть всё, что может потребоваться в разработке. Хотите организовать работу микросервисов — пожалуйста, на базе AWS существует целый фреймворк. В современных приложениях 99% кода — это повторение уже написанного. Чтобы не повторяться, можно прийти в AWS и пользоваться.

Облачные провайдеры

AWS, Microsoft Azure и Google Cloud — самые популярные облачные провайдеры. Но помимо них существует более десяти крупных поставщиков облачных услуг. 

Amazon высадились первыми, и они продолжают занимать около половины рынка. Microsoft Azure присоединились с большим опозданием, но сейчас каждый пятый клиент пользуется именно ими. Google Cloud Platform немножко от них отстают, но в принципе незначительно.
Распределение облачных провайдеров на рынке

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

Некоторые компании предпочитают использовать Hybrid Cloud и Multicloud. Multicloud подразумевает, что ресурсы рассредоточены по нескольким облакам. Его организуют, чтобы сэкономить и обеспечить отказоустойчивость. Если один тип обработки дешевле в Google Cloud, второй тип на Amazon, то распределять данные выгоднее, чем держать в одном сервисе. Хотя надо учитывать, что передача больших объемов данных между облаками может стоить дорого. 

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

Как попробовать

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

На курсе по администрированию облачных систем мы рассказываем о принципах работы в AWS и учим развёртывать системы с автоматическим масштабированием. Видеокурс вышел в январе 2021. Он будет полезен разработчикам, DevOps, сисадминам. Архитекторам и техническому руководству тоже пригодится: чтобы сэкономить время, можно пропустить практику, а сосредоточиться на теории и демонстрациях. Они помогут понять, как работает AWS и как его использовать в компании.