Использование возможностей облачных функций для создания распределенных систем нового поколения
Что, если бы каждый разработчик имел доступ к самому большому суперкомпьютеру в мире?
Бессерверное путешествие так далеко
Запуск AWS Lambda 13 ноября 2014 г. позволил создать новый способ написания приложений в облаке. Сегодня разработчики во всем мире во всех мыслимых типах и размерах организаций пользуются меньшими затратами и более быстрым выводом на рынок бессерверных приложений.
Путь от первоначального выпуска к сегодняшнему дню - это не только рост внедрения и масштабирования: это также история о постоянно увеличивающемся «целевом пространстве» для бессерверных приложений.
То, что начиналось как способ реагирования на объекты, хранящиеся в Amazon S3, превратилось в обработку событий во всех портфелях всех крупных поставщиков облачных услуг. С годами были добавлены новые возможности, которые позволили использовать бессерверные архитектуры для создания мобильных и веб-серверов, обработки потоковых данных, замены заданий cron и многого другого.
Поставщики облачных услуг нашли способы сделать все больше и больше своих возможностей безсерверными: не только очевидные, такие как хранилища объектов и службы публикации / подписки, но и базы данных SQL, запросы аналитики данных, Интернет вещей и многое другое.
Это нововведение далеко не закончено - недавние достижения, такие как возможность Amazon API Gateway автоматически кадрировать трафик веб-сокетов и превращать его в вызовы функций Lambda, также известные как архитектуры кефали, позволяют создать совершенно новый класс возможности, которые раньше требовали тяжелых серверов и методологий развертывания.
Эти инновации проявляются во многих формах: новые шаблоны и структуры, новые сервисы (например, AWS AppSync и Google Cloud Run) и постоянно растущий набор функций среди существующих бессерверных предложений поставщиков облачных услуг.
Простота Serverless в сочетании с быстрыми темпами инноваций помогли ему добиться огромного успеха - преимущества отсутствия необходимости владеть, масштабировать, управлять или защищать инфраструктуру позволяют разработчикам сосредоточиться на своем бизнесе, а не на обслуживании и питании серверов или контейнеров.
Эти преимущества носят не только технический характер - компании, внедряющие бессерверные архитектуры, также обычно снижают свои счета за облачные вычисления до 90% и более благодаря тому, что бессерверные функции обеспечивают 100% -ное использование по сравнению с типичным корпоративным использованием серверов на 10–15%.
Но какими бы значительными ни были эти достижения, даже позволяющие некоторым компаниям полностью отказаться от серверов, их недостаточно. Обработка крупномасштабных данных, параллельные алгоритмы, потоковый контент, распределенное управление заданиями и множество других задач по-прежнему в основном решаются с использованием тех же многоуровневых серверных архитектур, которые мы развертывали в 1990-х годах.
Можно ли применить бессерверные методы к большим данным, моделированию машинного обучения, универсальным алгоритмам, перекодированию видео и другим ресурсам, требующим больших вычислительных ресурсов, и получить те же виды затрат и улучшений времени выхода на рынок, которые он предлагает сегодня для Интернета, мобильных устройств и других приложений. событийные приложения?
Можем ли мы получить те же преимущества для приложений высокопроизводительных вычислений (HPC), которые Serverless принесли с обработкой событий, веб- и мобильными серверными модулями?
Расцвет бессерверного суперкомпьютера
Сложность никогда не является достоинством. Обещание, лежащее в основе бессерверных подходов, состоит в том, что сопоставление кода с серверами (или контейнерами) и обеспечение безопасной масштабной работы этих серверов должны быть ответственностью поставщиков облачных услуг.
Выяснение того, где запускать код и как поддерживать работоспособность инфраструктуры, представляет собой ненужное отвлечение для каждого разработчика приложений, независимо от того, каким может быть их приложение.
Это никогда не было более справедливым, чем в мире больших данных и больших вычислений, где проблемы разделения, развертывания и управления серверами могут стать непреодолимой проблемой для разработчиков. Это еще более верно, если учесть, что разработчик таких приложений может быть исследователем-биологом, статистиком, астрономом или другим профессионалом, которому нужно вычислять числа, но не обязательно желанием или навыками масштабировать серверы и присматривать за ними.
Между тем, бессерверные функции теперь обладают огромным парком, совокупная вычислительная мощность которых превышает все вычислительные возможности общедоступного облака всего несколько лет назад. При таком масштабе вычислительной мощности бессерверные функции в облаке теперь конкурируют со специализированными суперкомпьютерами по общему количеству используемых в них кремний.
Вопрос уже не в том, будут ли они масштабироваться как услуга, а в том, сможем ли мы найти способы использовать всю эту мощь в реальных приложениях для высокопроизводительных вычислений.
Есть несколько заманчивых предположений, что это возможно. Самый быстрый в мире алгоритм перекодирования видео, известный сегодня, ExCamera, не работает на графических процессорах или другом специализированном оборудовании - он был создан с использованием AWS Lambda.
Бессерверные алгоритмы для высокопараллельной линейной алгебры уже находятся в пределах 33% от традиционных подходов, демонстрируя при этом на 240% лучшую вычислительную эффективность.
Fannie Mae перенесла массивные модели Монте-Карло для кредитных портфелей с мэйнфреймов на AWS Lambda, что привело к сокращению времени выполнения, снижению затрат и более гибкому масштабированию. Другие исследователи нашли способы перенести рабочие места, обычно выполняемые на ноутбуках и настольных компьютерах, в облако, что сокращает время распределенной сборки и вычислений.
Решение существующих проблем в таком масштабе увлекательно, но это еще не все. Также весьма вероятно, что парадокс Джевона применим. Например, если мы сможем найти способы распараллеливания перекодирования видео, чтобы редактирование могло происходить в реальном времени, больше людей будут редактировать больше видео.
Это говорит о том, что «бессерверные супервычисления» - это далеко не ограниченная сфера деятельности исследователей и нескольких хардкорных вычислителей чисел, они фактически открывают новые приложения и активируют новые мощные функции в приложениях, которые мы используем сегодня.
Нижняя строка? Чем проще и дешевле становится применение огромных вычислительных мощностей для быстрого поиска ответов на сложные проблемы, тем больше вероятность того, что мы зададим такие вопросы.
В бессерверных суперкомпьютерах по-прежнему отсутствуют некоторые детали
Приведенные выше примеры интересны - они показывают, что возможно с бессерверным подходом и что он может произвести революцию в этих приложениях - точно так же, как он изменил то, как мы пишем обработчики событий и бэкенды на основе API.
Но вот и плохая новость: каждой команде, создающей одно из перечисленных выше приложений, приходилось вручную создавать множество строительных лесов, чтобы выполнять свою работу. Ни одно из этих приложений не было простыми «из коробки», и создание этой базовой структуры для распределенных алгоритмов поверх бессерверных предложений поставщика было нетривиальным в каждом случае.
Хорошие новости? Он также был довольно похож - и мы можем прочитать список того, что требовалось в качестве формы спецификации продукта для создания платформы бессерверных суперкомпьютеров будущего.
Прежде чем перейти к конкретным деталям, стоит задать более широкий вопрос: почему бессерверные алгоритмы и архитектуры будут отличаться от того, что было раньше? Ответ прост: на протяжении большей части истории мы думали о теории и практике распределенных систем как о неограниченном времени в ограниченном пространстве.
Постановка проблемы практически в каждой статье исследования распределенных систем или в высокопараллельном алгоритме заключалась в том, чтобы использовать ограниченный набор машин (серверов), которые живут вечно, для выполнения вычислений, которые не могут уместиться только на одном из них.
Serverless переворачивает это фундаментальное предположение с ног на голову: его вычислительная модель ограниченное время на неограниченном пространстве. Этот сдвиг заставляет нас переосмыслить все, что касается нашего подхода к распределенным алгоритмам, и создает разрушительный потенциал для совершенно новых инноваций, которые могут принести недоступные ранее вычислительные мощности в массы!
Бессерверная версия меняет нашу модель распределенных вычислений.
Что нужно для работы бессерверного суперкомпьютера?
Создание этой возможности требует сочетания устранения пробелов в обычных («серверных») вычислениях, таких как сети, а также создания новых сервисов, которые устраняют несоответствие импеданса между вычислениями (облачные функции, такие как AWS Lambda) и технологиями хранения на основе серверов, такими как redis.
Для этого требуются принципиально новые алгоритмы сортировки и поиска, которые могут использовать способность Serverless жестко ограничивать затраты, при этом хорошо играя в рамках своих временных ограничений.
И для этого требуются новые структуры, в том числе возможность быстро распределять и управлять работой десятков тысяч функций, работающих параллельно.
Давайте посмотрим на некоторые конкретные «недостающие части» и роли, которые они будут играть в бессерверной архитектуре суперкомпьютера:
# 1 Распределенная сеть
Все распределенные алгоритмы зависят от способности соединять вычислительные узлы друг с другом и, во многих случаях, от способности динамически устанавливать и изменять топологию этих каналов связи.
Сегодняшние облачные функции не поддерживают эту возможность напрямую, и фактически большинство из них отключает входящий TCP / IP. Чтобы сделать бессерверные суперкомпьютеры возможными, нам необходимо устранить этот фундаментальный пробел.
# 2 Детализированная хореография с малой задержкой
Хотя существующие сервисы управляемых рабочих процессов хорошо справляются с моделированием бизнес-процессов, они, как правило, на несколько порядков слишком медленны (и слишком дороги) для управления. жизненный цикл из десятков тысяч времени жизни функций, не говоря уже о координации переходов между вызовами функций.
Бессерверному суперкомпьютеру также потребуются настраиваемые функциональные возможности рабочего процесса, такие как управление отставанием, которое отражает его уникальную семантику и проблемы.
№3 высокоскоростных хранилищ ключей и значений
Вероятно, наиболее очевидным недостающим элементом в управляемых портфелях сегодняшних поставщиков облачных услуг является высокоскоростное хранилище ключей и значений (на основе DRAM). Хранилища облачных объектов, такие как Amazon S3, предлагают низкую полосу пропускания и высокую пропускную способность, но за счет высокой задержки.
Базы данных NoSQL, такие как Amazon DynamoDB, предлагают более высокую производительность, но при слишком высоких затратах, чтобы эффективно служить в качестве системы общей памяти для переходного состояния. В этом нет ничего удивительного; DynamoDB разработан для того, чтобы делать записи постоянными и долговечными… ни то, ни другое обычно не требуется для сохранения текущего состояния алгоритма, который можно было бы просто перезапустить.
Развертывания серверной инфраструктуры, такие как Redis (или их эквиваленты от облачных поставщиков), страдают от серьезного несоответствия импеданса бессерверным функциям, что возвращает нас в мир индивидуального управления и масштабирования серверов. К счастью, недавняя работа в академических кругах показывает многообещающие перспективы лучшего согласования срока службы хранилища с бессерверными алгоритмами и разработки экономически эффективного масштабируемого хранилища.
# 4 Неизменяемые входы и выходы, связанные с вызовами функций
Системы, которые преуспели в использовании мощности бессерверного режима в огромных вычислительных масштабах, должны были найти способ создания привязок входных и выходных данных по порядку. для выполнения крупномасштабных потоков данных.
В отличие от привязок на основе событий, которые существуют сегодня в некоторых бессерверных архитектурах, эти объекты обычно эфемерны вне выполнения алгоритма и происходят в массовом масштабе.
К счастью, неизменяемые структуры управления объектами оказались пригодными для надстройки над существующими облачными услугами поставщиков; их просто нужно извлечь из академических исследований и сделать доступными для разработчиков в целом.
# 5 Возможность масштабной настройки кода и данных
Бессерверные функции, такие как AWS Lambda, имеют «плоскости управления» (API-интерфейсы для создания, обновления и удаления функций), которые были разработаны для масштабирования человеческого взаимодействия. Но эти плоскости управления плохо подходят для ситуации, когда для 10000 вызовов параллельных функций требуется немного другой код для выполнения скоординированного алгоритма, а затем они исчезают навсегда.
Точно так же вызов облачной функции предназначен для передачи аргументов (таких как полезные данные события) только один раз, когда функция вызывается, а затем возвращает единственный результат, когда он завершается. Распределенным алгоритмам может потребоваться доставка больших объемов данных на протяжении времени существования функции, при этом частичные результаты передаются до выхода из функции.
# 6 Выполнение потоков данных
Благодаря поддержке предыдущих элементов можно создавать и выполнять графы потоков данных, которые представляют сложные многоузловые распределенные алгоритмы в массовом масштабе. Эти потоки данных будут представлять новый уровень абстракции для бессерверных вычислений, поскольку они описывают все вычисления, а не только то, как запускать или вызывать отдельную функцию.
# 7 Алгоритмы общего назначения и специфические для предметной области, адаптированные к «размеру и форме» бессерверных функций
Наконец, разработчикам нужна поддержка как для общих целей (сортировка, поиск, группировка и т. д.) и доменно-ориентированные (перекодирование видео, генетика) библиотеки, настроенные на бессерверную платформу. Имея это на месте, они могут сосредоточиться на конкретных потребностях своих алгоритмов и не изобретать колесо, чтобы добиться цели.
Путешествие впереди
Как говорится, будущее уже наступило - просто оно еще не распределено равномерно. Создание любого нового технологического стека требует времени и усилий, поэтому ожидайте постепенного появления бессерверных суперкомпьютеров в течение следующих нескольких лет.
Университетские исследователи уже усердно работают, а такие компании, как ServerlessTech, уже решают проблему распределенных сетей для облачных функций.
К счастью, это не предложение по принципу «все или ничего»: каждый дополнительный шаг открывает новые домены приложений для использования преимуществ бессерверных подходов.
Например, простое добавление поддержки сети делает возможным предварительное нагревание, одноранговый обмен файлами, распространение контента в реальном времени и обмен дополнительными аргументами и результатами с помощью облачной функции.
У поставщиков облачных услуг также есть критически важные роли, с которыми могут справиться только они: улучшение пропускной способности сети и джиттера, дополнительная память и хранилище файловой системы, более высокие (и более простые в управлении) ограничения на параллелизм и множество деталей функций из управляемой настройки NAT. для получения дополнительной контекстной информации внутри функций.
Еще многое предстоит сделать, но сейчас самое время быть разработчиком или новатором в этой сфере - самый мощный и самый простой в использовании суперкомпьютер в мире проектируется и строится прямо сейчас!
В эту статью включены материалы из моей презентации ServerlessConf NYC ’19 (слайды здесь).
