Переход в облако. Практическое руководство по организации облачных вычислений для ученых и IT-специалистов

ГЛАВА 6

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

•Сколько ресурсов на самом деле требуется Саше? Этот вопрос крайне важен: хоть и некоторая степень неопределенности всегда допустима, Саша должен заранее знать, какие ресурсы ему потребуются. Вот основные вопросы, на которые ему предстоит ответить:

—Сколько требуется процессоров и памяти, в том числе — из расчета на один узел?

—Какой требуется объем хранилища? Должен ли он быть постоянным?

—Как долго будет работать приложение?

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

•Каков допустимый критический уровень для Сашиного ПО или экспериментов? Иными словами, каковы Сашины ожидания? Код или эксперименты можно выполнять по достаточно низкой цене, если у вас нет жестких временных ограничений: например, если вы не возражаете против того, что выполнение вашего кода займет больше времени.

•Каким бюджетом располагает Саша? Теперь, когда все предыдущие вопросы сняты, можно ответить на самый главный: сколько ресурсов вам доступно? Чем точнее вы можете ответить на предыдущие вопросы, тем корректнее будет ответ на этот, последний. Мы подробно рассматривали данный аспект в главе 4 этой книги.

71Andrikopoulos V., Binz T., Leymann F., et al (2013) How to adapt applications for the cloud environment. Computing 95:493. https://doi.org/10.1007/s00607–012–0248–2.

71

ПЕРЕХОД В ОБЛАКО

6.2.2.Интерфейсы прикладного программирования (API)

6.2.2.1.Что такое API?

API-интерфейсы, абстракции очень высокого уровня, обеспечивающие стандартный способ взаимодействия с ПО или инфраструктурой, широко распространены в информатике. API предоставляют системную точку входа или библиотечную функцию с четко определенным синтаксисом, доступным из прикладных программ или пользовательского кода для предоставления четко определенного функционала. API играют важную роль в облачных системах и могут иметь различные формы (например, API POSIX). Базовый рабочий процесс API показан на рис. 6.1.

Вывод / Ответ

Система, приложение и т. д.

Рис. 6.1 Базовый рабочий процесс API

Современные облачные системы как правило используют и обеспечивают передачу состояния представления (REST) при помощи CRUD-о- пераций («создание», «чтение», «обновление», «удаление») и/или API GraphQL72, инкапсулированных в HTTP. Вот несколько интересных примеров такого подхода:

•Примером API, построенного на основе REST, является NASA Earth API73, позволяющий исследовать доступные наборы данных, в том числе изображения.

•Также в открытом доступе есть несколько построенных таким же образом API от Google (например, поиск)74.

72Eizinger T. (2017) API design in distributed systems: a comparison between GraphQL and REST. Master Thesis, University of Applied Sciences Technikum Wien.

73NASA (2019) Earthdata Developer Portal. https://earthdata.nasa.gov/collaborate/open- dataservices-and-software/api. По состоянию на 5 ноября 2019 г.

74Google (2019) Google API explorer. https://developers.google.com/apis-explorer/. По состоянию на 20 мая 2019 г.

72

ГЛАВА 6

6.2.3. Облачное окружение и среда выполнения кода

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

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

6.2.3.1 Почему API так важны в облаке?

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

•Многие функции доступны только через API и должны быть реализованы программным путем.

•API предоставляют возможность создавать повторяющиеся или автоматизируемые шаблоны; пользовательский интерфейс или любые другие методы условно оптимальны и могут со временем быть изменены.

Основные поставщики общедоступных облачных сервисов располагают обширной и четко регламентированной документацией по своим API, включая примеры для различных языков программирования:

•Azure REST API75;

75Microsoft (2019) Azure REST API reference. https://docs.microsoft.com/en-us/rest/api/ azure/. По состоянию на 22 мая 2019 г.

73

ПЕРЕХОД В ОБЛАКО

•Руководства AWS и API76;

•Google Cloud API77.

6.2.3.2 Пример использования облачного API

В качестве примера рассмотрим, как AWS EC2 делает информацию об экземпляре доступной с помощью метаданных в формате JSON; т. е. экземпляр может получить информацию о себе через запрос в локальную службу, предоставляющую метаданные. Например, для получения списка доступных экземпляров в метаданных можно выполнить следующую команду:

$ curl http://169.254.169.254/latest/meta-data/

Исходя из этого списка, для получения общедоступного IPv4 инстанса вводим такую команду:

$ curl http://169.254.169.254/latest/meta-data/public-ipv4/ 193.146.46.94

Очевидно, этот процесс представляет собой один из низших уровней доступа. В этом случае к интерфейсу можно получить прямой доступ, чтобы сделать GET-запрос с помощью curl. Этот подход необходим лишь в определенных случаях; если возможно, рекомендуется применять SDK, обычно предоставляемый поставщиками облачных услуг или третьей стороной. Использование SDK предлагает более высокий уровень абстракции — например, взаимодействие с различными API для разных сервисов — и упрощает написание кода. Для основных поставщиков публичных облаков доступны следующие SDK:

•AWS SDK78;

•GCP SDK79;

•Azure SDK80.

76Amazon (2019) AWS documentation. https://docs.aws.amazon.com/#lang/en_us. По состоянию на 10 апреля 2019 г.

77Google (2019) Google cloud APIs. https://cloud.google.com/apis/docs/overview. По состоянию на 20 мая 2019 г.

78Amazon (2019) AWS SDK. https://aws.amazon.com/tools/#SDKs. По состоянию на 10 апреля 2019 г.

79Google (2019) Cloud SDK. https://cloud.google.com/sdk/. По состоянию на 20 мая 2019 г.

80Microsoft (2019) Azure tools. https://azure.microsoft.com/en-us/tools/. По состоянию на 22 мая 2019 г.

74

ГЛАВА 6

Дополнительную сложность привносит концепция Регионов, которой пользуются поставщики облачных услуг. Регион — это географическая точка, в которой фактически расположена инфраструктура и где управляются ресурсы. Регион — не только физическое понятие, но и указание на то, что имеющиеся ресурсы и даже их свойства могут отличаться. Так, на платформе GCP доступные типы процессоров отличаются в регионах asia-east1 и europe-north181.

Когда к предыдущему примеру добавляется проблема регионов, список запущенных экземпляров для проекта на GCP в Python потребует следующих действий:

•Установите Google Cloud SDK, как описано на официальной странице (этот шаг выполняется только один раз).

•Установите клиентскую библиотеку для Python (этот шаг также выполняется только один раз).

$pip install ––upgrade google–api–python–client

•Как только все зависимости будут соблюдены, этот несложный класс выдаст список работающих экземпляров:

“””

This code list the instances on a given project and zone.

Данный код выводит список экземпляров для заданного проекта и зоны

“””

import os

from pathlib import Path import googleapiclient. discovery

#Credentials can be generated at your:

#Вы можете получить исходные данные по адресу

#https://console. cloud.google.com/iam–admin/serviceaccounts

#Put your JSON credentials file on your $HOME/.google/credentials. json

#Поместите ваш файл данных JSON в свой каталог $HOME/.google/credentials. json

81Здесь следует отметить, что названия и регионы меняются, а значит, эти обозначения могут не соответствовать регионам Google Cloud, доступным в то время, когда вы читаете эту книгу.

75

ПЕРЕХОД В ОБЛАКО

os. environ [

“GOOGLE_APPLICATION_CREDENTIALS”] = “%s/.google/credentials.json”% Path.home()

class GCPCompute(object):

“””

This class contains the logic to return a list containing the instances for a zone (for a project).

Этот класс содержит код, возвращающий список экземпляров зоны (для проекта).

“””

def __init__ (self, project: str, zone: str):

self.compute = googleapiclient. discovery. build (’compute’, ’v1’) self. project = project

self.zone = zone

def list_instances (self) –> list:

“””

Return a list of items (instances). Возвращает список экземпляров.

“””

result = self.compute. instances (). list (

project =self. project, zone=self.zone). execute () return result. get (’items’, [])

if __name__ == “__main__”: PROJECT = “my–experiment” ZONE = “europe–west1-c”

GCPCOMPUTE = GCPCompute(project=PROJECT, zone=ZONE)

INSTANCES = GCPCOMPUTE.list_instances()

print(“>> Project:%s “% PROJECT)

# Just print instances names (if any):

#Просто выводит на печать имена экземпляров (при наличии)

76

ГЛАВА 6

if not INSTANCES:

print(“ \ nInstances (name) for zone%s:”% ZONE) for instance in INSTANCES:

print(“–>%s”% instance[’name’])

else :

print(“ \nNo instances found for zone%s”% ZONE)

•Результат выполнения этого кода выглядит следующим образом:

$ python list_instances.py

>> Project: my–experiment

Instances (name) for zone europe–west1-c –> Instance_1

–> Instance_2 –> Instance_3

6.2.4. Код в облаке: соображения

На этом этапе, с точки зрения и запуска, и написания облачного ПО, Саше предстоит решить, начинать ли с нуля, полностью приняв облачную парадигму, или выполнить реорганизацию кода для запуска в облаке, что подразумевает следующее:

•Запустить cloud native-проект: разработать системы и внедрить их с нуля, чтобы воспользоваться всеми ресурсами, такими как API, одновременно устраняя подводные камни облачной среды, например, низкую производительность в определенных ситуациях.

•Сделать ПО и системы пригодными для использования в облаке82: перенести в облако как можно больше ПО, чтобы воспользоваться всеми преимуществами; или, в более ограниченном числе случаев,

82Andrikopoulos V., Binz T., Leymann F., et al (2013) How to adapt applications for the cloud environment. Computing 95:493. https://doi.org/10.1007/s00607–012–0248–2.

77

ПЕРЕХОД В ОБЛАКО

преобразовать ПО таким образом, чтобы оно могло хотя бы работать в облаке.

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

6.2.4.1.Общие аспекты

•Оборудование в большинстве своем отличается высокой степенью абстрагированности: зачастую предоставляемая системой информация не отражает реальность: например, это можно сказать о вычислительных юнитах AWS EC2. Данная особенность может осложнить точную настройку, например, отдельные флаги компилятора.

•Некоторые системы совместно используют ресурсы: т. е. ресурсами ЦП или подсистемы IOPS могут пользоваться и другие клиенты облака, что способно привести к неожиданным результатам, например непрерывному использованию ЦП или недостаточной производительности дисков.

•Всегда используйте API по умолчанию и избегайте применения пользовательского интерфейса: некоторые ресурсы доступны только в таком виде.

•Воспользуйтесь преимуществами готовых систем и компонентов: такие технологии, как контейнеры (Docker или Kubernetes) и PaaS (например, Hadoop как услуга), могут значительно сэкономить время на настройке инфраструктуры.

6.2.4.2.Сеть

•Время задержки: сетевая задержка — это один из аспектов, оказывающий большое влияние на код, особенно научный, использующий такие технологии, как MPI и сети с низким значением задержки (например, InfiniBand). Большинство поставщиков, хоть некоторые из них и заявляют о сверхнизком значении задержки, по умолчанию предлагают сеть, предназначенную для общих целей, что может ощутимо снизить производительность научных приложений. Следовательно, главная рекомендация — рассматривать доступную оптимизацию (некоторые поставщики предлагают оптимизированные для HPC среды отдельно от стандартных опций) и провести первоначальную оценку, напри-

78

ГЛАВА 6

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

снизким значением задержки.

•Ограниченное устранение неполадок: в облачной среде этот процесс ограничен, что объясняется характером сетей и их абстракцией.

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

споставщиком: он может предложить индивидуальные решения, например, отдельные среды, по запросу.

•Частные сети: некоторые сети, которые должны быть доступны из Сашиных систем или сервисов, могут не быть доступны напрямую. Так, частное исследовательское учреждение может предоставить доступ к определенным данным, которые могут потребоваться для экспериментов, только по своим частным сетям. Возможным решением может стать VPN, однако поставщикам оно доступно далеко не везде и не всегда.

6.2.4.3. Хранилище данных

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

•Различные уровни хранения: в дополнение к предыдущему пункту абстракция может также предоставить доступ к различным уровням хранения — от быстрого и дорогого для частого использования до медленного и недорогого для резервного копирования или редкого использования.

79

ПЕРЕХОД В ОБЛАКО

6.3. Запуск эксперимента в облаке

На данном этапе Саша обладает достаточными знаниями для запуска эксперимента. Повторим несколько моментов, которые ему следует учесть.

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

•Контроль версий: для поддержки и совместного использования кода и документации Саше надо применять систему контроля версий, например Git.

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

6.3.1 Пример: эксперимент по классификации месяцев

Новый Сашин проект — простое ПО, которое классифицирует месяцы по свойственной им облачности. Саша планирует использовать имеющиеся средства для исследований на AWS. В первичном подходе источником данных будет API Earth data NASA84. Вот какие технологии и поставщик потребуются Саше.

•Поставщик облачных услуг: пусть в данном случае это AWS.

•Технологии:

—Язык программирования и библиотеки: Python 3 и NumPy.

—Инструментарий: интерфейс командной строки AWS.

—Сторонние API: API Earth data NASA.

—Облачные технологии/сервисы: AWS EC2 (вычисления) и S3 (хранение).

ПО будет названо classificator.py. Архитектура очень высокого уровня и рабочий процесс показаны на рис. 6.2.

83Vijayasarathy L., Butler C. (2016) Choice of software development methodologies: do organizational, project, and team characteristics matter? IEEE Softw 33(5):86–94. https://doi. org/10.1109/MS.2015.26

84NASA (2019) Earthdata Developer Portal. https://earthdata.nasa.gov/collaborate/open- dataservices-and-software/api. По состоянию на 5 ноября 2019 г.

80