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

Регион, VPC и подсети

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

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

Амазонка S3

S3 — это служба хранения объектов в AWS, в которой представлена ​​концепция сегментов, в которых хранятся объекты.

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

Блокнот и модель Amazon Sagemaker

Sagemaker — это сервис на AWS, который содержит все ваши потребности в машинном обучении. Он имеет множество функций, начиная от моделей обучения и заканчивая развертыванием конечных точек.

Мы используем блокнот Sagemaker для передачи изображений в шлюз API, чтобы получить вывод. Модель Sagemaker (развернутая как изображение в Amazon ECR) аннотирует изображения и возвращает их в Lambda.

Шлюз API Amazon

Шлюз API позволяет создавать API и управлять ими. Шлюз API расположен между приложениями, использующими API, и сервисами, реализующими функциональность API.

В нашем случае шлюз API реализует метод POST REST API. Блокнот Sagemaker вызывает метод POST с изображением и запускает Lambda, и после успешного вывода метод возвращает тело, содержащее аннотированное изображение.

АВС Лямбда

Lambda — это сервис FaaS в AWS для запуска кода с использованием определенной среды выполнения.

Наш код Lambda (развернутый в виде образа на Amazon ECR) соединяет несколько компонентов со следующими функциями:

  • Запросы Sagemaker для предсказания
  • Запись аннотированного изображения в корзину s3
  • Запись метаданных и аннотированного изображения в RDS
  • Передача аннотированного изображения обратно в API Gateway

Amazon RDS

Реляционная база данных Amazon — это Amazon RDS.

Мы используем RDS для сохранения метаданных входных изображений и их выводов Sagemaker.

Инфраструктура как код (IaC), Что в имени?

Читатели, знакомые с AWS Cloudformation, возможно, слышали об IaC. Функциональность Terraform чем-то похожа на Cloudformation, но Cloudformation предназначена только для AWS. Terraform не зависит от облака и может использоваться для предоставления инфраструктуры на других основных облачных платформах.

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

resource "aws_sagemaker_notebook_instance" "notebook_instance" { name = "smart-mobility-notebook-instance-${terraform.workspace}" role_arn = var.iam_role_arn instance_type = "ml.t2.medium" subnet_id = var.subnet_ids[0] security_groups = var.security_group_ids }

(2) Пример кода Terraform для развертывания экземпляра ноутбука AWS Sagemaker.

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

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

Важно проверить, называется ли ключ раздела для таблицы DynamoDB LockID. Этот конкретный ключ раздела необходим Terraform для распознавания таблицы.

Точки внимания

Мы заканчиваем эту запись в блоге некоторыми моментами, на которые следует обратить внимание при настройке подобной инфраструктуры.

  • Шлюз API

Для развертывания ресурса aws_api_gateway_integration uri Lambda должен быть в следующем формате:

"arn:aws:apigateway:${region}:lambda:path/2015-03-31/functions/${lambda_arn}/invocations/"

(3) Конкретный требуемый формат для привязки Lambda к шлюзу API

  • IAM-политики

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

  • Рабочие пространства Terraform

Рабочие области Terraform полезны при работе с несколькими средами (например, при разработке и производстве). Каждая рабочая область имеет собственный файл состояния, что позволяет развертывать одни и те же ресурсы для разных сред.

  • Действия Github и секреты Github

С помощью Github Actions можно создать рабочий процесс CI/CD, который проверяет изменения в коде Terraform и применяет эти изменения к AWS. Имейте в виду, что для этого Github нужны учетные данные AWS, но не размещайте свои учетные данные в репозитории. Секреты Github предлагают безопасный способ сохранить ваши учетные данные AWS, чтобы их можно было использовать в рабочих процессах CI/CD.

  • Консоль AWS

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

Заключение

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

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

Вам также может понравиться

Tokyo Drift: обнаружение дрейфа изображений с помощью NannyML и Whylogs — Варре Дрисен, Марсьяль Ван ден Брук

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

корни данных