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

ГЛАВА 3

В более широком плане разработку математических приложений в облачных средах поощряли и государственные органы: так, проект MSO4SC, финансируемый ЕС, включал HPC.

3.6.7. Медицинские науки

Есть множество примеров внедрения облачных и бессерверных вычислений в области медицинских наук. Сегодня FDA использует облачные технологии для совершенствования обработки огромных массивов письменных отчетов о воздействии препаратов, которые Управление получает каждый год. Кроме того, CDC использует эту технологию для получения и обмена информацией об эволюции болезней. Если рассматривать более частные случаи использования HPCaaS, то Институт медицинских исследований Уолтера и Элизы Холл прибегает к облачным вычислениям для анализа данных микроскопических исследований с высоким разрешением. Кроме того, Фонд Майкла Дж. Фокса разработал программу исследований, в ходе которой пациенты постоянно передают данные с переносных устройств в облако. Полученную от разных пациентов информацию анализируют одновременно, что является огромным прогрессом по сравнению с плановыми ежемесячными медицинскими осмотрами и, как следствие, полезно для изучения симптоматики и лекарственных средств. Еще два примера — Исследовательский институт больницы Оттавы, использующий облачные ресурсы в рамках программы, направленной на изучение вопроса, почему люди неохотно соглашаются на прививки, и Университет Западной Капской провинции, предоставляющий в рамках своего исследования веб-платформу для изучения устойчивости к препаратам от ВИЧ. Не меньшую важность имеет распараллеливание рабочих процессов: так, Смитсоновский институт использует их при аннотировании геномов. Стэндфордский университет прибегает к облачным вычислениям для совершенствования рабочих процессов при исследованиях в области нейровизуализации. Кроме того, данная технология позволяет укрепить компьютерную безопасность и упрочить соблюдение строгих правил в отношении медицинской информации.

Упомянем здесь также использование бессерверных вычислений. Так, примеры применения AWS Lambda включают GenePool от Station X — платформу, которую можно использовать для анализа генетических данных, и Benchling — компанию, разрабатывающую и продающую ПО для генной инженерии.

51

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

3.6.8. Физика

Пожалуй, одним из самых ярких примеров использования облачных технологий в физике является управление огромным массивом данных, получаемых ЦЕРН в ходе экспериментов на Большом адронном коллайдере. GCP применяется для анализа данных эксперимента Atlas, а OpenFOAM, популярное бесплатное ПО в области вычислительной гидродинамики, можно запустить непосредственно на AWS.

3.6.9. Общественные науки

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

3.6.10 Космические исследования

ЕКА, NASA и ее лаборатория JPL, а также Университет Аляски используют облачные вычисления для обработки и распространения огромного количества спутниковых снимков. В случае с JPL их променяли для систем наведения роботов и обеспечения масштабируемой потоковой передачи видеомиссии Mars Curiosity. Кроме того, для обработки полученных из космоса изображений применялись бессерверные вычисления61.

61Malawski M., Gajek A., Zima A., Balis B., Figiela K. (2019) Serverless execution of scientific workflows: experiments with HyperFlow, AWS Lambda and Google Cloud Functions. Future Gener Comput Syst. https://doi.org/10.1016/j.future.2017.10.029

Г Л А В А 4

Покажите деньги

4.1. Средства на исследования с использованием облачных вычислений

В последние годы несколько вендоров (поставщиков оборудования и ПО), задавшись целью содействовать использованию облачных вычислений, создали программы предоставления грантов или кредитов исследователям, проверяющим применимость данной технологии в своей работе. Такой подход был и остается беспроигрышным, так как научное сообщество получает доступ к огромным объемам ресурсов для HPC или датамайнинга; вендоры же, заранее узнавая о проблемах и потребностях будущих клиентов, решают их загодя, а значит, разрабатывают более надежный и комплексный продукт. Такой подход сам по себе является отличной маркетинговой кампанией: вендоры инвестируют в проекты на благо общества.

Некоторые из подобных программ выполняются или выполнялись в прошлом в течение ограниченного промежутка времени; другие действуют дольше или открыты постоянно. В качестве примера можно привести Azure for Research и AWS Research Credits; некоторые программы ориентированы на более узкие темы, например Microsoft Climate Data Initiative или Amazon Sustainability Data Initiative. В других случаях можно связаться с вендорами

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

идругие варианты. Чаще всего ответы можно найти, просто изучив сайты вендоров.

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

53

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

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

4.2. Распределение расходов

Мы уже рассматривали случай, когда Сашина лаборатория участвует в исследованиях, где не обойтись без HPCaaS. Лаборатория производит обширные объемы данных, которые нужно где-то хранить, и ей наверняка придется приложить усилия, чтобы получить хранилище требуемого объема и подключение к Интернету, позволяющее обмениваться данными и результатами исследований с коллегами. С этим могут возникнуть проблемы, если Сашины исследования обретут известность или если в результате изысканий будут получен набор данных, которым захочет пользоваться исследовательское сообщество. Более того, в подобных случаях облачные сервисы могут стать отличным инструментом для распространения результатов. Если Сашины коллеги пожелают скачать себе данные или получить результаты

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

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

Эта схема представляет собой огромный шаг вперед по сравнению с традиционной, при которой Сашина лаборатория может потребовать от коллег

54

ГЛАВА 4

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

4.3. Продажа исследований

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

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

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

55

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

4.4. А если я не заплачу?

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

4.5. А если мой поставщик не предоставит услугу?

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

Однако это не единственная из возможных трудностей. Уровень надежности поставщиков облачных решений чрезвычайно высок. Так, в ходе своего главного ежегодного мероприятия в сфере облачных вычислений — Google Cloud Next — в 2019 г. Google заявили, что являются номером один по степени надежности среди поставщиков облачных услуг, подкрепив это следующими сведениями: в 2018 г. их сервис был недоступен всего в течение примерно 200 минут. Ближайшим конкурентом стали AWS с показателем порядка 300 минут. Развернулись споры о том, насколько точны эти данные

56

ГЛАВА 4

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

4.6. Оценка перехода

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

4.6.1. Выбор поставщика

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

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

Вэтом разделе мы не предлагаем никакой новой стратегии выбора поставщика и даже не определяем, какой подход вам выбрать; у большинства поставщиков есть собственные руководства, где указаны методы оценки

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

Хотя представленная нами оценка абсолютно нейтральна, у каждого поставщика есть своя уникальная стратегия и целевая группа клиентов. Таким

62Misra S.C., Mondal A. (2011) Identification of a company’s suitability for the adoption of cloud computing and modelling its corresponding return on investment. Math Comput Model 53(3– 4):504–521. https://doi.org/10.1016/j.mcm.2010.03.037

57

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

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

4.6.2 Определение проблемы

Первый шаг — определение проблемы, которую необходимо решить, и ее составляющих на высоком уровне. Чем конкретнее удастся определить требования, тем легче будет найти оптимальное решение (и поставщика). Так, в рассмотренном нами примере Саша пытается запустить моделирование климата, чтобы рассчитать, допустим, облачность: узнать, насколько облачно в разных уголках Земли в определенный день.

4.6.3 Сбор требований

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

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

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

63Bildosola I., Río-Belver R., Cilleruelo E., Garechana G. (2015) Design and implementation of a cloud computing adoption decision tool: generating a cloud road. PLoS ONE10(7): e0134563. https://doi.org/10.1371/journal.pone.0134563;

Etsy (2018) Selecting a cloud provider (code as craft post). https://codeascraft.com/2018/01/04/ selecting-a-cloud-provider/. По состоянию на 10 июня 2019 г.

64Repschläger J., Wind S., Zarnekow R., Turowski K. (2011) Developing a cloud provider selection model. Paper presented at the enterprise modelling and information systems architectures: proceedings of the 4th international workshop on enterprise modelling and information systems, EMISA 2011, Hamburg, September 22–23, 2011.

58

ГЛАВА 4

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

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

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

Саше следует ранжировать эти аспекты по важности и присвоить каждому значение от 0 до 1, где 0 — наименее, а 1 — наиболее значимый аспект.

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

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

•Приложению требуется мощный процессор, а большой объем памяти — нет.

•Данные поступают из публичного API, доступного в интернете.

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

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

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

59

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

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

4.6.4. Получение данных

После определения всех граней задачи данные о поставщиках заносятся в самый удобный для нас формат, например в таблицу. Учитывая все требования, мы присваиваем каждому из поставщиков баллы и оцениваем их с точки зрения способности удовлетворить наши потребности. Так, для решения задачи, рассмотренной в предыдущих разделах, мы присваиваем поставщикам от 1 до 10 баллов по каждому критерию. В табл. 4.2 показан пример оценки поставщиков, который позволит Саше выбрать наиболее соответствующего его потребностям.

60