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

ГЛАВА 7

Экземпляр EC2

Рис. 7.1. Высокоуровневая архитектура бессерверных вычислений и рабочего

процесса эксперимента по классификации месяцев по критерию облачности

Обратите внимание: данный код упрощен и не предназначен для практического применения. Кроме того, это так называемый синхронный запрос, используемый в качестве примера (а длительные синхронные HTTP-запросы обычно не рекомендуется применять). Данный код является вариацией представленного в разделе 6.3.1 кода, адаптированного для облачных функций Google. Вот в чем состоят его основные отличия:

•Все требования обрабатываются на стороне сервера, и о разрешении заботится Google (согласно файлу requirements.txt).

•Выходные данные и журналы, полученные облачной платформой, отображаются в пользовательском интерфейсе (в данном случае это Google Cloud Logs / Stackdriver).

•Аутентификация и память, характерные для AWS, заменены аналогами GCS.

Несмотря на эти различия, логика моделирования остается неизменной:

•В данном случае код запускается конечной точкой HTTP, созданной Google Cloud Functions для этого эксперимента.

91

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

•Далее следует получение оценки облачности за месяц (ежедневные значения) из API NASA.

•С учетом этих данных производится расчет: определяется средний показатель облачности за месяц и наиболее типичный день для этого месяца (ближайший к среднему значению).

•Результаты загружаются в объект облачного хранилища Google.

•Пользователю отправляется сообщение об успешном завершении задачи.

Для запуска этой программы требуются два файла: содержащий требования (requirements.txt, используемый для разрешения зависимостей) и собственно код моделирования (main.py).

Содержимое файла requirements.txt выглядит так:

numpy

google–cloud–storage

Содержимое файла main.py выглядит следующим образом:

import json import numpy import os import requests

from calendar import monthrange from datetime import datetime from google.cloud import storage

# Константы: ключи API и секретные ключи доступа

NASA_API_KEY = “NASA_API_KEY”

AWS_ACCESS_KEY_ID = ’XXX’

AWS_SECRET_ACCESS_KEY = ’YYY’

GCS_BUCKET = ’MY EXPERIMENT BUCKET’

# Константы: дата в формате ГГГГ–ММ

DATE = «2016–07»

# Константы: долгота и широта

LON = «–7.8987052»

92

ГЛАВА 7

LAT = “42.3384207”

class Month(object):

def __init__ (self, longitude, latitude, date, api_key): self. _longitude = longitude

self. _latitude = latitude self. _date = date

self ._api_key = api_key

self. _baseurl = “https://api. nasa.gov/ planetary / earth /imagery/” self ._req = requests

# Данные за месяц self ._monthdata = {}

def _getData(self):

year, month = self. _date. split (’–’)

mrange = monthrange(int(year), int (month))

print(“> Receiving data from API … “)

for day in range(1, mrange[1] + 1):

day_date = “{}–{}”.format(self. _date, day)

day_url = “{base}?lon={lon}&lat={lat}&date={date}& cloud_score=True&api_key={api_key}”

. format(base=self. _baseurl, lon=self. _longitude, lat =self. _latitude,

date=day_date, api_key=self ._api_key)

#Оптимизация может заключаться в том, чтобы делать меньше запросов к API (ближайший день от API).

#а также с целью использования многопроцессорного пула для

#параллельных запросов

day_data = self ._req. get (day_url)

day_data_json = day_data. json ()

93

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

response_date = datetime. strptime (

day_data_json[’ date ’], ’%Y–%m–%dT%H:%M:%S’) response_simple_date = “{}–{}–{}”.format(

response_date. year, response_date.month, response_date. day)

# Добавляем данные только если их еще нет if response_simple_date not in self ._monthdata:

self ._monthdata[response_simple_date] = day_data_json

def _getAverageDay(self):

self ._getAverageCloudScore() closest_average_day = ’ ’ average_distance = 1

for day in self ._monthdata: day_avg_distance = numpy.absolute(

self ._monthdata[day][’ cloud_score ’] — self. _average_cloud_score)

if (day_avg_distance < average_distance):

# Отмечаем текущий день как наиболее близкий к среднему average_distance = day_avg_distance

closest_average_day = day

self. _closest_average_day = closest_average_day

def _getAverageCloudScore(self): cloud_scores = []

for day in self ._monthdata:

cloud_scores.append(self ._monthdata[day][’ cloud_score ’]) self. _average_cloud_score = numpy.mean(cloud_scores)

def _writeResultFile (self, filename, file_content):

# Записываем файл результатов в бакет GCS client = storage. Client ()

bucket = client. get_bucket (GCS_BUCKET) blob = bucket.blob(filename)

94

ГЛАВА 7

blob. upload_from_string (str (file_content))

def _writeOutput(self):

# Эти данные будут записаны в журнал выполнения функции print(“ “)

print(“> Month Average Cloud Score for%s:%s”% (DATE, self. _average_cloud_score))

print(“> Average Day Date (YYYY–MM–DD):%s (avg.:%s)”% ( self._closest_average_day, self._monthdata[self. _closest_average_day][’ cloud_score ’]))

def process (self): self ._getData ()

self ._getAverageDay() self. _writeOutput ()

# Запись среднемесячного значения в хранилище

self. _writeResultFile (“%s_%s”% (DATE, “month_average”), self. _average_cloud_score)

# Запись наиболее типичных данных для дня (усредненных) в хранилище self. _writeResultFile (“%s_%s”% (DATE, “day_average”), self.

_closest_average_day)

def classifier (request):

month = Month(LON, LAT, DATE, NASA_API_KEY)

# Обработка данных за месяц month.process ()

return f”Computation completed! Results available on the GCS Bucket.”

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

$gcloud functions deploy start_simulation ––runtime python37 ––trigger

—http

95

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

Эта команда вернет информацию о нашей функции, например о ее конечной точке (httpsTrigger url), которая будет использоваться для запуска облачной функции. В нашем примере функция выглядит так: https://us- central1-OUR-EXPERIMENT.cloudfunctions.net/simulation. Команда для запуска моделирования выглядит следующим образом:

Рамка открывается

$ curl «https://us–central1–OUR–EXPERIMENT.cloudfunctions.net/

simulation»

Как только моделирование будет завершено, его можно удалить с помощью команды gcloud:

$ gcloud functions delete simulation

7.4. Пример: Бессерверный сбор данных с датчиков

После успешного запуска классификатора в облаке Google Сашина команда рассматривала возможность использовать новые знания для решения другой проблемы, которая беспокоит их уже продолжительное время: данные API NASA — это прекрасно, но все же не совсем то, что им требуется. Сашина команда больше заинтересована в данных по конкретному региону: для этого они развернули сеть высокочувствительных датчиков, с которых можно получать данные в режиме реального времени. И теперь исследователям нужен легкий способ сбора этих данных.

Поскольку команда уже знает, как запустить бессерверный код, Саша предлагает простую функцию, которая будет заносить данные с датчика в файл; а команда в свою очередь сможет считывать результаты непосредственно из своего бакета GCS. Вероятнее всего, Саша начнет с использования программы вроде Datastore. Рабочий процесс схематично показан на рис. 7.2.

Вот как это будет реализовано94:

94Обратите внимание: в данной разработке не затрагиваются вопросы безопасности или аутентификации; она служит лишь доказательством концепции: любой, у кого есть URL-а- дрес, может сделать GET-запрос и внести данные в GCS-бакет.

96

ГЛАВА 7

=

Облачное

хранилище

3: Сохранение данных датчика

Рис. 7.2. Высокоуровневая бессерверная архитектура и рабочий процесс для

сбора данных с датчиков

Содержимое файла requirements.txt:

google–cloud–storage

Содержимое файла main.py:

import time import json

from google.cloud import storage

# Константы

GCS_BUCKET = ’MY_EXPERIMENT_BUCKET’

def writeSensorData(sensor_id, sensor_value):

# Запись файла результата в бакет GCS timestamp = int (time. time ())

filename = “sensor_%s_%s”%(sensor_id, timestamp) client = storage. Client ()

bucket = client. get_bucket (GCS_BUCKET)

97

ГЛАВА 8

Г Л А В А 8

Этические и юридические аспекты облачных технологий

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

Этика в области ИТ не очень отличается от этики в остальных сферах жизни. Учитывая, что Саша, скорее всего, не разрабатывает большую часть своего программного и аппаратного обеспечения самостоятельно, ему следует учитывать, какое ПО он использует и как оно было разработано. Несколько десятилетий назад на этот факт обратил внимание Ричард Столлман, инициировавший Движение за свободное ПО. Это движение является частью деятельности таких организаций, как Фонд свободного ПО и Фонд электронных границ.

Популяризация интернета превратила вопрос защиты данных в новую острую проблему. В некотором смысле использование облачных вычислений сопряжено с теми же юридическими проблемами, что и работа с многими другими сервисами в интернете. Например, Саше нужно знать, работает ли выбранная им SaaS под лицензией типа Affero GPL (AGPL)95 и разработана ли она специально для облака. Это гарантировало бы, что запущенное в облаке ПО является бесплатным и Саша может получить доступ к исходному коду.

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

95GNU (2007) GNU Affero General Public License. https://www.gnu.org/licenses/agpl-3.0.html. По состоянию на 10 февраля 2019 г.

99

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

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

Около 10 лет назад была выдвинута инициатива по разработке «Манифеста облачных вычислений»: он должен был вытекать из сотрудничества, основанного на бесплатных инструментах с участием индустрии. Это был следующий шаг после «Билля о правах на облачные вычисления»; однако ключевые игроки в конечном итоге решили его все же не подписывать, и в 2012 г. идея провалилась. Проекты манифеста были сугубо техническими и ориентированными на разработку бизнес-модели облачных вычислений. Однако они также включали идею возможности взаимодействия «облаков». В недавней работе96 этические вопросы облачных вычислений классифицируются по четырем категориям: приватность и безопасность, соответствие требованиям, функциональная этика и воздействие на окружающую среду, что мы уже обсуждали в разделе 3.5. Первая категория касается типичного для нас беспокойства о конфиденциальности данных, вторая — правильного уровня стандартов. Функциональная этика относится к предоставлению услуг, обещанных по контракту. Фактически эти три проблемы связаны с общей «деловой этикой» и применимы независимо от того, используется облако или нет. Последствия использования облачных вычислений в этой области привели к появлению таких относительно недавних проектов, как SafeCloud97, финансируемый Европейским союзом.

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

96Faragardi H. (2017) Ethical considerations in cloud computing systems. Proceedings 1:166. https://doi.org/10.3390/IS4SI-2017–04016.

97EASA (2016) SafeClouds.eu Data-driven research addressing aviation safety intelligence. https:// ec.europa.eu/inea/en/horizon-2020/projects/h2020-transport/aviation/safeclouds.eu. По состоянию на 05 апреля 2019 г.

100