Это гостевой пост, написанный совместно с руководством Iambic Therapeutics.
Ямбическая терапия — это стартап по разработке лекарств, целью которого является создание инновационных технологий на основе искусственного интеллекта, позволяющих быстрее предоставлять более качественные лекарства больным раком.
Наши передовые инструменты генеративного и прогнозирующего искусственного интеллекта (ИИ) позволяют нам быстрее и эффективнее искать в огромном пространстве возможных молекул лекарств. Наши технологии универсальны и применимы в различных терапевтических областях, классах белков и механизмах действия. Помимо создания дифференцированных инструментов искусственного интеллекта, мы создали интегрированную платформу, которая объединяет программное обеспечение искусственного интеллекта, облачные данные, масштабируемую вычислительную инфраструктуру и высокопроизводительные возможности химии и биологии. Платформа не только обеспечивает работу нашего ИИ, предоставляя данные для уточнения наших моделей, но и активизирует его, извлекая выгоду из возможностей автоматического принятия решений и обработки данных.
Мы измеряем успех нашей способностью создавать превосходных клинических кандидатов для удовлетворения неотложных потребностей пациентов с беспрецедентной скоростью: мы прошли путь от запуска программы до клинических кандидатов всего за 24 месяца, что значительно быстрее, чем наши конкуренты.
В этом посте мы сосредоточимся на том, как мы использовали Карпентер on Амазон Эластик Кубернетес Сервис (Amazon EKS) для масштабирования обучения и вывода ИИ, которые являются основными элементами платформы открытий Iambic.
Необходимость масштабируемого обучения и вывода ИИ
Каждую неделю Iambic выполняет выводы искусственного интеллекта на десятках моделей и миллионах молекул, обслуживая два основных варианта использования:
- Медицинские химики и другие ученые используют наше веб-приложение Insight для исследования химического пространства, доступа и интерпретации экспериментальных данных, а также прогнозирования свойств вновь созданных молекул. Вся эта работа выполняется в интерактивном режиме в режиме реального времени, что создает необходимость в логическом выводе с низкой задержкой и средней пропускной способностью.
- В то же время наши генеративные модели искусственного интеллекта автоматически разрабатывают молекулы, направленные на улучшение многочисленных свойств, поиск миллионов кандидатов и требующие огромной пропускной способности и средней задержки.
Под руководством технологий искусственного интеллекта и опытных охотников за наркотиками наша экспериментальная платформа каждую неделю генерирует тысячи уникальных молекул, каждая из которых подвергается множеству биологических анализов. Сгенерированные данные автоматически обрабатываются и используются для точной настройки наших моделей ИИ каждую неделю. Первоначально точная настройка нашей модели занимала несколько часов процессорного времени, поэтому необходима была среда для точной настройки масштабируемой модели на графических процессорах.
Наши модели глубокого обучения предъявляют нетривиальные требования: они имеют размер в гигабайтах, многочисленны и неоднородны, а также требуют графических процессоров для быстрого вывода и точной настройки. Что касается облачной инфраструктуры, нам нужна была система, которая позволяла бы нам получать доступ к графическим процессорам, быстро масштабироваться вверх и вниз для обработки резких, неоднородных рабочих нагрузок и запускать большие образы Docker.
Мы хотели создать масштабируемую систему для поддержки обучения и вывода ИИ. Мы используем Amazon EKS и искали лучшее решение для автоматического масштабирования наших рабочих узлов. Мы выбрали Karpenter для автоматического масштабирования узла Kubernetes по ряду причин:
- Простота интеграции с Kubernetes, использование семантики Kubernetes для определения требований к узлам и характеристик модулей для масштабирования.
- Масштабирование узлов с малой задержкой
- Простота интеграции с нашей инфраструктурой в качестве инструмента кода (Terraform).
Поставщики узлов поддерживают легкую интеграцию с Amazon EKS и другими ресурсами AWS, такими как Эластичное вычислительное облако Amazon (Amazon EC2) и Магазин эластичных блоков Amazon объемы. Семантика Kubernetes, используемая поставщиками, поддерживает направленное планирование с использованием конструкций Kubernetes, таких как ограничения или допуски, а также спецификации сходства или антисходства; они также облегчают контроль над количеством и типами экземпляров графического процессора, которые могут быть запланированы Karpenter.
Обзор решения
В этом разделе мы представляем общую архитектуру, аналогичную той, которую мы используем для наших собственных рабочих нагрузок, которая позволяет гибко развертывать модели с использованием эффективного автоматического масштабирования на основе пользовательских метрик.
Следующая диаграмма иллюстрирует архитектуру решения.
В архитектуре используется простой сервис в модуле Kubernetes внутри Кластер ЭКС. Это может быть вывод модели, моделирование данных или любой другой контейнерный сервис, доступный по HTTP-запросу. Служба предоставляется за обратным прокси-сервером с использованием Траефик. Обратный прокси-сервер собирает метрики о вызовах службы и предоставляет их через стандартный API метрик для Прометей. Автомасштабирование Kubernetes, управляемое событиями (КЕДА) настроен на автоматическое масштабирование количества сервисных модулей на основе пользовательских метрик, доступных в Prometheus. Здесь мы используем количество запросов в секунду в качестве пользовательской метрики. Тот же архитектурный подход применяется, если вы выбираете другую метрику для своей рабочей нагрузки.
Карпентер отслеживает все ожидающие модули, которые не могут быть запущены из-за отсутствия достаточных ресурсов в кластере. Если такие модули обнаружены, Карпентер добавляет в кластер дополнительные узлы, чтобы предоставить необходимые ресурсы. И наоборот, если в кластере больше узлов, чем необходимо запланированным подам, Карпентер удаляет некоторые рабочие узлы, и поды перепланируются, объединяя их в меньшем количестве экземпляров. Количество HTTP-запросов в секунду и количество узлов можно визуализировать с помощью графана панель приборов. Чтобы продемонстрировать автоматическое масштабирование, мы запускаем один или несколько простые модули, генерирующие нагрузку, которые отправляют HTTP-запросы в службу, используя виться.
Развертывание решения
В пошаговое руководство, мы используем Облако AWS9 как среду для развертывания архитектуры. Это позволяет выполнять все шаги из веб-браузера. Вы также можете развернуть решение с локального компьютера или экземпляра EC2.
Чтобы упростить развертывание и улучшить воспроизводимость, мы следуем принципам do-framework и структура шаблон зависимости от докера. Мы клонируем оу-до-экс проект и, используя Docker, мы создаем образ контейнера, оснащенный необходимыми инструментами и скриптами. Внутри контейнера мы проходим все этапы комплексного руководства: от создания кластера EKS с помощью Karpenter до масштабирования. Экземпляры EC2.
Для примера в этом посте мы используем следующее Манифест кластера EKS:
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: do-eks-yaml-karpenter
version: '1.28'
region: us-west-2
tags:
karpenter.sh/discovery: do-eks-yaml-karpenter
iam:
withOIDC: true
addons:
- name: aws-ebs-csi-driver
version: v1.26.0-eksbuild.1
wellKnownPolicies:
ebsCSIController: true
managedNodeGroups:
- name: c5-xl-do-eks-karpenter-ng
instanceType: c5.xlarge
instancePrefix: c5-xl
privateNetworking: true
minSize: 0
desiredCapacity: 2
maxSize: 10
volumeSize: 300
iam:
withAddonPolicies:
cloudWatch: true
ebs: true
Этот манифест определяет кластер с именем do-eks-yaml-karpenter
с драйвером EBS CSI, установленным в качестве дополнения. Группа управляемых узлов с двумя c5.xlarge
nodes включен для запуска системных модулей, необходимых кластеру. Рабочие узлы размещаются в частных подсетях, а конечная точка API кластера по умолчанию является общедоступной.
Вы также можете использовать существующий кластер EKS вместо его создания. Мы развертываем Karpenter, следуя инструкциям инструкции в документации Karpenter или выполнив следующую команду скрипт, который автоматизирует инструкции по развертыванию.
Следующий код показывает конфигурацию Karpenter, которую мы используем в этом примере:
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
name: default
spec:
template:
metadata: null
labels:
cluster-name: do-eks-yaml-karpenter
annotations:
purpose: karpenter-example
spec:
nodeClassRef:
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
name: default
requirements:
- key: karpenter.sh/capacity-type
operator: In
values:
- spot
- on-demand
- key: karpenter.k8s.aws/instance-category
operator: In
values:
- c
- m
- r
- g
- p
- key: karpenter.k8s.aws/instance-generation
operator: Gt
values:
- '2'
disruption:
consolidationPolicy: WhenUnderutilized
#consolidationPolicy: WhenEmpty
#consolidateAfter: 30s
expireAfter: 720h
---
apiVersion: karpenter.k8s.aws/v1beta1
kind: EC2NodeClass
metadata:
name: default
spec:
amiFamily: AL2
subnetSelectorTerms:
- tags:
karpenter.sh/discovery: "do-eks-yaml-karpenter"
securityGroupSelectorTerms:
- tags:
karpenter.sh/discovery: "do-eks-yaml-karpenter"
role: "KarpenterNodeRole-do-eks-yaml-karpenter"
tags:
app: autoscaling-test
blockDeviceMappings:
- deviceName: /dev/xvda
ebs:
volumeSize: 80Gi
volumeType: gp3
iops: 10000
deleteOnTermination: true
throughput: 125
detailedMonitoring: true
Мы определяем Karpenter NodePool по умолчанию со следующими требованиями:
- Карпентер может запускать экземпляры из обоих
spot
иon-demand
пулы емкости - Экземпляры должны быть из раздела «
c
(оптимизировано для вычислений), «m
" (общее назначение), "r
(оптимизировано для памяти) или «g
(Основной ключ) иp
Семейства вычислительных систем (с графическим ускорением) - Генерация экземпляра должна быть больше 2; например,
g3
приемлемо, ноg2
Не
NodePool по умолчанию также определяет политики сбоев. Недостаточно используемые узлы будут удалены, чтобы модули можно было объединить для работы на меньшем или меньшем количестве узлов. Альтернативно мы можем настроить удаление пустых узлов по истечении указанного периода времени. expireAfter
Параметр определяет максимальный срок службы любого узла, прежде чем он будет остановлен и заменен при необходимости. Это помогает уменьшить уязвимости безопасности, а также избежать проблем, типичных для узлов с длительным временем безотказной работы, таких как фрагментация файлов или утечки памяти.
По умолчанию Karpenter выделяет узлы с небольшим корневым томом, которого может быть недостаточно для выполнения рабочих нагрузок искусственного интеллекта или машинного обучения (ML). Размер некоторых образов контейнеров глубокого обучения может достигать десятков ГБ, и нам необходимо убедиться, что на узлах достаточно места для хранения модулей, использующих эти образы. Для этого определим EC2NodeClass
blockDeviceMappings
, как показано в предыдущем коде.
Карпентер отвечает за автоматическое масштабирование на уровне кластера. Чтобы настроить автоматическое масштабирование на уровне модуля, мы используем KEDA для определения пользовательского ресурса под названием ScaledObject
, как показано в следующем коде:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: keda-prometheus-hpa
namespace: hpa-example
spec:
scaleTargetRef:
name: php-apache
minReplicaCount: 1
cooldownPeriod: 30
triggers:
- type: prometheus
metadata:
serverAddress: http://prometheus- server.prometheus.svc.cluster.local:80
metricName: http_requests_total
threshold: '1'
query: rate(traefik_service_requests_total{service="hpa-example-php-apache-80@kubernetes",code="200"}[2m])
Предыдущий манифест определяет ScaledObject
названный keda-prometheus-hpa
, который отвечает за масштабирование развертывания php-apache и всегда поддерживает работу хотя бы одной реплики. Он масштабирует модули этого развертывания на основе метрики http_requests_total
доступный в Prometheus, полученный по указанному запросу, и предназначен для масштабирования модулей, чтобы каждый модуль обслуживал не более одного запроса в секунду. Он уменьшает масштаб реплик после того, как загрузка запроса была ниже порогового значения в течение более 30 секунд.
Ассоциация спецификация развертывания для нашего примера сервис содержит следующее запросы и лимиты ресурсов:
resources:
limits:
cpu: 500m
nvidia.com/gpu: 1
requests:
cpu: 200m
nvidia.com/gpu: 1
В этой конфигурации каждый из сервисных модулей будет использовать ровно один графический процессор NVIDIA. При создании новых модулей они будут находиться в состоянии ожидания, пока не станет доступен графический процессор. Карпентер добавляет узлы графического процессора в кластер по мере необходимости для размещения ожидающих модулей.
A капсула, генерирующая нагрузку отправляет HTTP-запросы к сервису с заранее установленной частотой. Увеличиваем количество запросов за счет увеличения количества реплик в развертывание генератора нагрузки.
Полный цикл масштабирования с консолидацией узлов на основе использования визуализируется на информационной панели Grafana. На следующей информационной панели показано количество узлов в кластере по типам экземпляров (вверху), количество запросов в секунду (внизу слева) и количество модулей (внизу справа).
Мы начнем с двух экземпляров ЦП c5.xlarge, с которыми был создан кластер. Затем мы развертываем один экземпляр службы, для которого требуется один графический процессор. Карпентер добавляет экземпляр g4dn.xlarge для удовлетворения этой потребности. Затем мы развертываем генератор нагрузки, в результате чего KEDA добавляет больше сервисных модулей, а Карпентер — больше экземпляров графического процессора. После оптимизации состояние фиксируется на одном экземпляре p3.8xlarge с 8 графическими процессорами и одном экземпляре g5.12xlarge с 4 графическими процессорами.
Когда мы масштабируем развертывание, генерирующее нагрузку, до 40 реплик, KEDA создает дополнительные сервисные модули для поддержания необходимой нагрузки запросов на каждый модуль. Карпентер добавляет в кластер узлы g4dn.metal и g4dn.12xlarge, чтобы обеспечить необходимые графические процессоры для дополнительных модулей. В масштабированном состоянии кластер содержит 16 узлов GPU и обслуживает около 300 запросов в секунду. Когда мы уменьшаем генератор нагрузки до 1 реплики, происходит обратный процесс. После периода восстановления KEDA уменьшает количество сервисных модулей. Затем, когда запускается меньше модулей, Карпентер удаляет из кластера недостаточно используемые узлы, и сервисные модули объединяются для работы на меньшем количестве узлов. При удалении модуля генератора нагрузки один сервисный модуль на одном экземпляре g4dn.xlarge с 1 графическим процессором продолжает работать. Когда мы также удаляем сервисный модуль, кластер остается в исходном состоянии только с двумя узлами ЦП.
Мы можем наблюдать такое поведение, когда NodePool
имеет настройку consolidationPolicy: WhenUnderutilized
.
С помощью этого параметра Карпентер динамически настраивает кластер с как можно меньшим количеством узлов, обеспечивая при этом достаточные ресурсы для работы всех модулей, а также минимизируя затраты.
Поведение масштабирования, показанное на следующей информационной панели, наблюдается, когда NodePool
политика консолидации установлена на WhenEmpty
, вместе с consolidateAfter: 30s
.
В этом сценарии узлы останавливаются только в том случае, если после периода охлаждения на них не работают ни один модуль. Кривая масштабирования выглядит плавной по сравнению с политикой консолидации на основе использования; однако видно, что в масштабированном состоянии используется больше узлов (22 против 16).
В целом, сочетание автоматического масштабирования модулей и кластера обеспечивает динамическое масштабирование кластера в соответствии с рабочей нагрузкой, выделение ресурсов при необходимости и удаление их, когда они не используются, тем самым максимизируя использование и минимизируя затраты.
Результаты
Компания Iambic использовала эту архитектуру, чтобы обеспечить эффективное использование графических процессоров на AWS и перенести рабочие нагрузки с процессора на графический процессор. Используя экземпляры EC2 с графическим процессором, Amazon EKS и Karpenter, мы смогли обеспечить более быстрый вывод для наших моделей, основанных на физике, и сократить время итерации экспериментов для ученых-прикладников, которые полагаются на обучение как услугу.
В следующей таблице приведены некоторые временные показатели этой миграции.
Сложность задачи | процессоры | Графические процессоры |
Вывод с использованием моделей диффузии для моделей машинного обучения на основе физики | 3,600 секунд |
100 секунд (из-за свойственной пакетной обработки графических процессоров) |
Обучение модели ML как услуга | 180 минут | 4 минут |
В следующей таблице приведены некоторые из наших показателей времени и затрат.
Сложность задачи | Производительность/стоимость | |
процессоры | Графические процессоры | |
Обучение модели машинного обучения |
240 минут в среднем 0.70 доллара США за тренировочное задание |
20 минут в среднем 0.38 доллара США за тренировочное задание |
Обзор
В этом посте мы продемонстрировали, как компания Iambic использовала Karpenter и KEDA для масштабирования нашей инфраструктуры Amazon EKS, чтобы удовлетворить требования к задержке наших рабочих нагрузок вывода искусственного интеллекта и обучения. Karpenter и KEDA — это мощные инструменты с открытым исходным кодом, которые помогают автоматически масштабировать кластеры EKS и выполняемые на них рабочие нагрузки. Это помогает оптимизировать затраты на вычисления и одновременно удовлетворить требования к производительности. Вы можете проверить код и развернуть ту же архитектуру в своей среде, следуя полному пошаговому руководству в этом руководстве. Репо GitHub.
Об авторах
Мэтью Велборн — директор отдела машинного обучения в Iambic Therapeutics. Он и его команда используют искусственный интеллект для ускорения выявления и разработки новых терапевтических средств, быстрее доставляя пациентам жизненно важные лекарства.
Пол Уиттемор является главным инженером в Iambic Therapeutics. Он поддерживает создание инфраструктуры для платформы разработки лекарств на основе искусственного интеллекта Iambic.
Алекс Янкульский — главный архитектор решений в компании ML/AI Frameworks, которая помогает клиентам организовывать свои рабочие нагрузки ИИ с помощью контейнеров и инфраструктуры ускоренных вычислений на AWS.
- SEO-контент и PR-распределение. Получите усиление сегодня.
- PlatoData.Network Вертикальный генеративный ИИ. Расширьте возможности себя. Доступ здесь.
- ПлатонАйСтрим. Интеллект Web3. Расширение знаний. Доступ здесь.
- ПлатонЭСГ. Углерод, чистые технологии, Энергия, Окружающая среда, Солнечная, Управление отходами. Доступ здесь.
- ПлатонЗдоровье. Биотехнологии и клинические исследования. Доступ здесь.
- Источник: https://aws.amazon.com/blogs/machine-learning/scale-ai-training-and-inference-for-drug-discovery-through-amazon-eks-and-karpenter/
- :имеет
- :является
- :нет
- ][п
- $UP
- 1
- 10
- 100
- 125
- 16
- 200
- 200m
- 22
- 24
- 26%
- 28
- 30
- 300
- 40
- 600
- 7
- 70
- 8
- 80
- a
- способность
- в состоянии
- О нас
- ускорять
- ускоренный
- приемлемый
- доступ
- доступной
- вмещать
- через
- Действие
- Добавить
- Дополнительный
- дополнительный
- адрес
- Добавляет
- продвинутый
- сродство
- После
- AI
- AI модели
- AI обучение
- Все
- позволяет
- вдоль
- причислены
- всегда
- Amazon
- Amazon EC2
- Amazon Web Services
- an
- и
- любой
- API
- приложение
- появляется
- отношение
- Применение
- прикладной
- применяется
- подхода
- архитектурный
- архитектура
- МЫ
- области
- искусственный
- искусственный интеллект
- Искусственный интеллект (AI)
- AS
- At
- автоматический
- Автоматизированный
- автоматы
- автоматически
- доступен
- избежать
- AWS
- основанный
- дозирующий
- BE
- было
- до
- поведение
- за
- ниже
- ЛУЧШЕЕ
- Лучшая
- Beyond
- биология
- Заблокировать
- изоферменты печени
- Дно
- приносить
- Приведение
- браузер
- строить
- но
- by
- под названием
- Объявления
- CAN
- рак
- кандидатов
- возможности
- Пропускная способность
- капитализация
- случаев
- Причины
- проверка
- химический
- химия
- Выберите
- выбрал
- классов
- Клинический
- облако
- облачная инфраструктура
- Кластер
- код
- улавливается
- комбинируя
- сравненный
- конкурентов
- полный
- Заполненная
- вычисление
- Вычисление
- компьютер
- вычисление
- Конфигурация
- настроить
- консолидации
- консолидация
- конструкции
- Container
- Контейнеры
- содержит
- контроль
- наоборот
- расхолаживание
- Основные
- Цена
- Расходы
- может
- Создайте
- создали
- создает
- Создающий
- CSI
- кривая
- изготовленный на заказ
- Клиенты
- цикл
- приборная панель
- данным
- точки данных
- обработка данных
- Принятие решений
- глубоко
- глубокое обучение
- По умолчанию
- определять
- Определяет
- поставка
- демонстрировать
- развертывание
- развертывание
- развертывает
- Проект
- предназначенный
- обнаруженный
- Развитие
- диаграмма
- различный
- дифференцированный
- Вещание
- направленный
- директор
- открытие
- Нарушение
- do
- Docker
- документации
- сделанный
- вниз
- множество
- управляемый
- водитель
- наркотик
- два
- динамично
- каждый
- фактически
- эффективный
- легкий
- элементы
- включить
- включен
- позволяет
- впритык
- Конечная точка
- инженер
- огромный
- достаточно
- Окружающая среда
- оборудованный
- установленный
- События
- Каждая
- точно,
- пример
- существующий
- эксперимент
- экспериментальный
- эксперту
- Больше
- подвергаться
- содействовал
- БЫСТРО
- быстрее
- несколько
- меньше
- Файл
- Фокус
- фокусируется
- следовать
- после
- Что касается
- фрагментация
- Рамки
- каркасы
- частота
- от
- полный
- Общие
- генерируется
- генерирует
- поколение
- генеративный
- Генеративный ИИ
- генератор
- получить
- GPU / ГРАФИЧЕСКИЙ ПРОЦЕССОР
- Графические процессоры
- большой
- группы
- GUEST
- Guest Post
- обрабатывать
- Есть
- he
- помощь
- помощь
- помогает
- здесь
- его
- состоялся
- ЧАСЫ
- Как
- Однако
- HTTP
- HTTPS
- Идентификация
- if
- иллюстрирует
- изображение
- изображений
- императив
- улучшать
- улучшение
- in
- включены
- Увеличение
- повышение
- Инфраструктура
- свойственный
- начальный
- первоначально
- инновационный
- понимание
- установлен
- пример
- вместо
- инструкции
- интегрированный
- интеграции.
- Интеллекта
- интерпретировать
- вопросы
- IT
- итерация
- JPG
- всего
- держит
- Основные
- Вид
- Этикетки
- Отсутствие
- большой
- Задержка
- запуск
- Наша команда
- Утечки
- изучение
- наименее
- оставил
- уровень
- Кредитное плечо
- продолжительность жизни
- рамки
- загрузка
- локальным
- Длинное
- дольше
- искать
- Низкий
- машина
- обучение с помощью машины
- поддерживать
- сделать
- ДЕЛАЕТ
- управляемого
- максимизации
- максимальный
- Май..
- проводить измерение
- механизмы
- средний
- Встречайте
- заседания
- Память
- слияния
- Метаданные
- металл
- метрический
- Метрика
- мигрировать
- миграция
- миллионы
- минимизация
- Наша миссия
- ML
- модель
- Модели
- Мониторы
- месяцев
- БОЛЕЕ
- с разными
- должен
- имя
- Названный
- необходимо
- Необходимость
- необходимый
- Новые
- вновь
- нет
- узел
- узлы
- роман
- номер
- многочисленный
- Nvidia
- наблюдать
- полученный
- of
- on
- On-Demand
- ONE
- только
- открытый
- с открытым исходным кодом
- оператор
- Возможности
- оптимизация
- Оптимизировать
- оптимизированный
- or
- Другое
- наши
- внешний
- за
- собственный
- пациент
- пациентов
- в ожидании
- для
- производительность
- выполняет
- период
- Часть
- Платформа
- Платон
- Платон Интеллектуальные данные
- ПлатонДанные
- пунктов
- сборах
- политика
- возможное
- После
- Питание
- мощный
- предшествующий
- предсказывать
- представить
- первичный
- Основной
- Принципы
- частная
- процесс
- Обработанный
- обработка
- производит
- FitPartner™
- Проект
- свойства
- Белкове продукты
- обеспечивать
- обеспечение
- полномочие
- что такое варган?
- цель
- запрос
- быстро
- R
- реальные
- реального времени
- причины
- уменьшить
- снижает
- совершенствовать
- область
- полагаться
- остатки
- удаление
- удален
- удаляет
- удаление
- заменить
- ответ
- запросить
- Запросы
- требовать
- обязательный
- Требования
- требуется
- ресурс
- Полезные ресурсы
- ответственный
- обратный
- правую
- Роли
- корень
- Run
- Бег
- то же
- масштабируемые
- Шкала
- масштаб ай
- масштабируется
- Весы
- масштабирование
- сценарий
- считаться
- планирование
- Ученые
- скрипты
- Поиск
- поиск
- Во-вторых
- секунды
- Раздел
- безопасность
- видел
- семантика
- Отправить
- посылает
- сервер
- служит
- обслуживание
- Услуги
- выступающей
- набор
- установка
- оседает
- продемонстрированы
- показанный
- Шоу
- существенно
- аналогичный
- упростить
- моделирование
- одинарной
- Размер
- небольшой
- меньше
- сгладить
- So
- Software
- Решение
- Решения
- некоторые
- Источник
- Space
- спецификации
- указанный
- функции
- скорость
- Спотовая торговля
- стандарт
- Начало
- ввод в эксплуатацию
- Область
- Шаги
- остановившийся
- диск
- Структура
- подсеть
- успех
- такие
- достаточный
- топ
- поставки
- поддержка
- Поддержка
- Убедитесь
- SVC
- система
- ТАБЛИЦЫ
- принимает
- направлены
- направлена против
- команда
- технологии
- шаблон
- десятки
- Terraform
- чем
- который
- Ассоциация
- Государство
- их
- Их
- тогда
- терапевтика
- Там.
- тем самым
- Эти
- они
- этой
- тысячи
- порог
- Через
- пропускная способность
- время
- раз
- в
- приняли
- инструменты
- топ
- Обучение
- правда
- два
- напишите
- Типы
- типичный
- созданного
- беспрецедентный
- до
- время безотказной работы
- срочный
- us
- использование
- используемый
- через
- v1
- Наши ценности
- Огромная
- разносторонний
- версия
- с помощью
- объем
- тома
- vs
- Уязвимости
- прохождение
- стремятся
- законопроект
- we
- Web
- веб приложение
- веб-браузер
- веб-сервисы
- неделя
- ЧТО Ж
- были
- Что
- Что такое
- когда
- который
- в то время как
- КТО
- будете
- в
- Работа
- работник
- YAML
- Ты
- ВАШЕ
- зефирнет