Эта статья является первой из серии «Хотите перейти в облако?» серия статей, посвященная «большой тройке» поставщиков общедоступных облаков и раскрывающая новые факторы и перспективы, которые следует учитывать при включении общедоступного облака в вашу более широкую ИТ-архитектуру.

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

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

«Бессерверные» функции
В то время как массы продолжают изучать, внедрять или приспосабливаться к контейнеризации и оркестровке своих контейнеров, вы можете быстро поручить Google, Amazon или Microsoft управлять каждым аспектом этой оркестровки. через свои управляемые «бессерверные» функции. Идея проста: напишите код, решите, сколько вычислений выделить для этого кода для выполнения в облаке, а затем решить, как и когда ваша система должна вызывать эту функцию (читать: микросервисы) , оплачивая только время, необходимое для выполнения этой функции. Повторять до бесконечности.

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

* Примечание. ГБ-секунды - это количество секунд, в течение которых работает ваша функция, умноженное на количество потребляемой оперативной памяти. За перечисленные ниже функции обычно взимается плата как за время выполнения - по ставке за миллисекунды, так и за количество вызовов в месяц.

AWS Lambda:
0,000017 доллара США за 1 ГБ в секунду для времени выполнения кода
0,20 доллара США за миллион вызовов

Функции Azure:
0,000016 USD / ГБ-секунда для времени выполнения кода
0,20 USD за миллион вызовов

Облачные функции Google:
0,0000025 долл. США / ГБ-секунда на время выполнения кода
0,40 долл. США за миллион вызовов

Как видно из модели ценообразования, эти функции предназначены для массового использования. Каждая ненужная или неэффективная строка кода будет выполняться миллионы раз в месяц. Чтобы продемонстрировать возможные последствия, мы можем использовать AWS Lambda в качестве примера:

Если лямбда-функция с 256 МБ ОЗУ вызывается 25000000 раз в месяц, мои ежемесячные затраты на эту единственную функцию будут составлять 57,08 долларов США, если для ее выполнения требуется 500 миллисекунд. Увеличьте это до 750 миллисекунд, и ваши ежемесячные затраты на эту единственную функцию увеличатся на 45% до 83 долларов США. Умножьте это превышение на каждую бессерверную функцию в вашей архитектуре микросервисов, ориентированной прежде всего на облако, и штрафы за технический долг могут быстро возрасти.

Запросы к хранилищу данных
Архитектура приема и хранения ваших данных сама по себе заслуживает отдельного поста (в ближайшее время!), но стоит заранее подумать о том, как эти данные будут запрашиваться. . На данный момент мы предполагаем, что вы следовали лучшим методам создания многоуровневого хранилища, разрушили стены между разрозненными хранилищами данных в своей организации и можете легко управлять доступом ко всем своим данным в хранилище данных с хорошей архитектурой. Помимо проприетарных игроков, таких как Snowflake и Databricks, вот основные предложения хранилищ данных общедоступного облака - и способы расчета стоимости запросов для каждого из них:

Amazon Redshift
5 долларов США за ТБ обработанных данных (RedShift Spectrum, только для данных S3)
Или от 0,25 до 13,04 долларов США в час за узел Redshift

Azure Synapse Analytics
5 долларов за ТБ обработанных данных (бессерверный вариант, только для данных Azure Data Lake)
Или от 1,20 до 360 долларов в час за Единицы хранилища данных, , Которые представляют собой вычислительные узлы с ценой, основанной на ЦП, памяти и IOPS.

Google BigQuery
5 долларов за ТБ обработанных данных

BigQuery - единственное истинное бессерверное предложение среди этих поставщиков облачных услуг; однако у каждого поставщика есть вариант без сервера для прямого запроса ваших данных, если они хранятся в объектном хранилище; как правило, в виде больших файлов на основе схемы в форматах вроде CSV, Avro или Parquet.

Вот где приходит экономия средств. Аналитики, обученные использованию SQL, будут знакомы со следующим (почти универсальным) началом запроса:

›ВЫБРАТЬ * ИЗ таблицы….

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

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

Например, вы можете просто изменить свой SQL и исключить столбцы из запроса:

›SELECT * EXCEPT (column1, column3 column4) FROM table…

Кроме того, вы можете горизонтально разделить таблицу по дате или значению отметки времени при ее создании. Это позволит вам также ограничить количество строк, которые вы запрашиваете.

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

Amazon Redshift предлагает функцию План запроса, которая требует вручную вставлять команду EXPLAIN перед вашими запросами.

BigQuery от Google делает это по умолчанию и дает предварительный просмотр перед каждым запросом:

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

Кластеры Kubernetes
И, конечно же, ни один хороший разговор об облаке не обходится без хотя бы краткого упоминания Kubernetes. Код, выполняемый в ваших кластерах Kubernetes, в конечном итоге повлияет на размер ваших кластеров и затраты, которые вы за них платите. Позвольте мне объяснить, что я имею в виду.

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

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

Google Cloud: Google Kubernetes Engine (GKE), организует ваши группы управляемых экземпляров.

AWS: Elastic Kubernetes Service (EKS), оркестрирует ваши группы автоматического масштабирования.

Azure: Службы Azure Kubernetes (AKS), оркестрируют ваши масштабируемые наборы виртуальных машин.

Хотя Kubernetes всегда был идеальным решением для масштабирования количества модулей, работающих на одной виртуальной машине / узле, управляемые службы Kubernetes идут дальше и автоматически масштабируют количество виртуальных машин в вашем кластере. Это масштабирование обычно основано на загрузке ЦП.

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

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