Правильная подготовка и сдача экзамена SAP-C01 дала мне ответы… Но какие вопросы?… Задача архитектора - убедиться, что все, что он создает, выдерживает возложенный на него вес. Такое совершенство недостижимо, не задав правильные вопросы.

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

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

1 | Итак, какие вопросы?

Хороший дизайн уровней инфраструктуры и программного обеспечения должен отвечать множеству проблем:

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

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

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

2 | Какие тогда ответы?

Чтобы ответить на эти вызовы, я решил:

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

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

Одним из основных столпов этой конструкции является EKS (Elastic Kubernetes Service), который представляет собой управляемый сервис AWS. Давайте посмотрим, как этот дизайн решает каждую из перечисленных проблем.

2.1 | Высокая доступность

AWS гарантирует высокую доступность своих управляемых сервисов. Вот почему я часто использую управляемые сервисы AWS: Route53, Cluster Autoscaler, NAT Gateway, FSx for lustre, Route53 и другие.

Чтобы гарантировать высокую доступность для всего проекта, необходимы как минимум две зоны доступности (AZ). Эти зоны доступности имеют одинаковую форму с немного разными типами ресурсов.

2.2 | Масштабируемый дизайн

Группы автомасштабирования (ASG) - хороший кандидат для решения этой проблемы. ПГС используются в двух местах:

  • Группа автомасштабирования для хостов-бастионов: поскольку это единственный способ доступа к платформе, я бы посоветовал иметь ASG с минимальной емкостью в два экземпляра. Некоторые люди предпочитают иметь только один экземпляр в качестве минимальной емкости для ASG, чтобы минимизировать затраты, потому что они считают, что хосты-бастионы используются для целей администрирования, и поэтому простой в несколько минут не имеет большого значения. Но при минимальной емкости в один инстанс мы гарантируем только непрерывность бизнеса, а не высокую доступность.
  • Cluster Autoscaler для кластера EKS: это отличная функция от AWS. Autoscaler «автоматически регулирует количество узлов в вашем кластере, когда модули не запускаются из-за нехватки ресурсов или когда узлы в кластере недостаточно загружены, и их модули могут быть перенесены на другие узлы в кластере» ¹ .

2.3 | Планирование мощности

Настоятельно рекомендуется иметь как минимум два кластера EKS. Я видел, как компании (например, Babylon Health ²) запускают намного больше кластеров EKS, каждый из которых содержит один тип EC2: это упрощает адаптацию использования платформы к конкретному варианту использования.

Одним из примеров использования этих двух кластеров является использование одного кластера для тяжелых работ, таких как обучение моделей машинного обучения (здесь используются экземпляры EC2 типа P3), а другой кластер для фазы вывода моделей (с Инстансы EC2 типа P2, которые дешевле).

2.4 | Устойчивость данных

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

В этой архитектуре я использовал FSx для Lustre, следуя рекомендациям Amazon для этого типа платформ: файловая система FSx For Lustre хорошо интегрируется с S3 и обеспечивает очень высокую производительность для доступа к данным, а платформам машинного обучения действительно нужна такая высокая производительность. Например, на этапе обучения модели данные обучения можно скопировать из S3 в FSx только один раз.

Поскольку файловая система FSx совместно используется различными рабочими узлами в кластере EKS, эти рабочие узлы могут очень эффективно получать доступ к данным из этой файловой системы, вместо того, чтобы полностью обращаться к S3.

2,5 | Безопасность платформы

Это самая интересная часть. Это подтолкнуло меня к глубокому исследованию EKS, чтобы найти ответы:

  • Для более высокого уровня безопасности я попытался скрыть ресурсы насколько это возможно. Итак, все рабочие узлы для кластеров EKS находятся в частных подсетях. Очевидно, что NAT-шлюз в общедоступной подсети является обязательным в каждой зоне доступности, поскольку иногда требуется доступ к Интернету для загрузки исправлений или доступа к реестру контейнеров, например ECR или DockerHub.
    Развертывание кластера EKS с частными и Согласно AWS, рекомендуется использовать общедоступные подсети.
  • Я выбрал частный доступ к API для Kubernetes: при использовании весь трафик между узлами Kubernetes остается внутри VPC, а API недоступен извне этого VPC.
    «Когда вы Включите частный доступ к конечным точкам для вашего кластера, Amazon EKS создает частную зону хостинга Route 53 от вашего имени и связывает ее с VPC вашего кластера. Этой частной зоной хостинга управляет Amazon EKS, и она не отображается в ресурсах Route 53 вашего аккаунта. Чтобы частная размещенная зона могла правильно направлять трафик на ваш сервер API, ваш VPC должен иметь enableDnsHostnames и enableDnsSupport значение true, а параметры DHCP, установленные для вашего VPC, должны включать _4 _ в своем списке серверов доменных имен ». ³
    Тогда доступ к Kubernetes API будет доступен только хостам-бастионам, которые должны быть созданы внутри того же VPC.
    Для обеспечения возможности подключения необходимо рассмотреть некоторые специальные конфигурации для хостов-бастионов:
    - Разрешить входящий трафик, поступающий с хостов-бастионов на порт 443 в группе безопасности плоскости управления Amazon EKS.
    - Доступ на основе ролей control (RBAC) для Kubernetes должен знать пользователя или роль IAM, используемую этими хостами-бастионами.

3 | Но как я получил эти ответы?

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

При развертывании кластера EKS с частными и общедоступными подсетями и включении частного доступа через API структура кластера будет следующей:

  • EKS Control Plane: главная часть кластера. Это узлы EC2, на которых запущена интеллектуальная сторона EKS для обеспечения согласованного состояния кластера Kubernetes. Они запускают хранилище ключей и значений etcd, которое используется в качестве резервного хранилища Kubernetes для всех данных кластера, kube-api-server и kube-scheduler. Подробнее здесь.
    Эти узлы работают в отдельном VPC, управляемом AWS.
  • Рабочие узлы с их автоматическим масштабированием кластера в частной подсети.
  • Шлюз NAT в общедоступной подсети для обеспечения исходящего трафика рабочих узлов.
  • Частная размещенная зона: « частная размещенная зона - это контейнер, содержащий информацию о том, как Amazon Route 53 должен отвечать на запросы DNS для домена и его субдомены в одном или нескольких VPC, которые вы создаете с помощью сервиса Amazon VPC ». ⁴.
    Создается EKS, когда включен API частного доступа. Для связи рабочие узлы и плоскость управления EKS используют записи частной размещенной зоны.
  • Эластичный сетевой интерфейс (ENI) предоставляется в дополнение к частной размещенной зоне. Этот ENI представляет собой сетевое соединение между плоскостью управления и рабочими узлами. Он поддерживает такие потоки, как выполнение kubectl, журналы и потоки данных прокси.

4 | Прости! Но мне нужно узнать подробности ...

На следующей диаграмме представлены более подробные сведения о компонентах внутри плоскости управления EKS и рабочих узлов.

Мы можем увидеть, как AWS развертывает плоскость управления EKS в нескольких зонах доступности для обеспечения высокой доступности.
Кроме того, мы можем наблюдать точный путь, по которому следует запрос, исходящий от рабочего узла при взаимодействии с сервером API.
Обратите внимание на внутри рабочего узла: компоненты Kubernetes, такие как Kubelet и Kube-proxy, развертываются на каждом рабочем узле.

5 | Советы

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

Лучше использовать утилиту командной строки ekctl⁶. Это определенно самый простой способ развернуть EKS. Он позаботится обо всех этапах создания тегов и ролей IAM, что действительно здорово и экономит много времени.

Заключение

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

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

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

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

Если у вас есть вопросы, напишите мне в LinkedIn.

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

[1] https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html

[2] https://www.youtube.com/watch?v=ULlqukKVKBo

[3] https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html

[4] https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html

[5] https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html

[6] https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html