Инстанс что это: Что такое инстанс (экземпляр) приложения? — Хабр Q&A

Что такое инстанс? — Часто задаваемые вопросы

Инстанс — это виртуальная машина, которая запускается и работает в облаке.

Примеры использования

В бизнесе

Инстансы позволяют использовать программы без установки на каждый компьютер пользователя. Часто так устанавливают 1C, внутренние инструменты (административные панели), программное обеспечение для демонстрации заказчикам, срок действия которого ограничен. Также возможна разработка и тестирование на виртуальных машинах с разными операционными системами. Кроме того, серверы можно использовать для хостинга сайтов.

Дома

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

Основные понятия

Ключевая пара — используется для первого входа на виртуальную машину по протоколу ssh. Все пароли в сервисе Cloud Servers удалены, а логины отличаются от классического root в целях безопасности. Ключевую пару можно создать в момент запуска инстанса или импортировать уже существующую. Без ключевой пары зайти на виртуальную машину не получится.

Подробнее — в статье «Ключевая пара».

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

Подробнее — в статье «Диски».

Группа безопасности — это наборы правил IP-фильтрации, которые регулируют права сетевого доступа (вход по определенному протоколу, по конкретному IP-адресу или через конкретны порт). Группу безопасности можно назначить по умолчанию для всех инстансов или создать для каждого инстанса свой набор правил. 

Подробнее — в статье «Группы безопасности».

Образ — образ виртуальной машины. Это файл, в котором содержится виртуальный загрузочный диск с установленной на нем операционной системой. Образы используются для создания инстансов в облаке. В сервисе Cloud Servers есть набор доступных образов, однако можно импортировать собственный. Файл должен быть в формате RAW. Другие форматы пока не поддерживаются.

Подробнее — в статье «Образы».

instance — Викисловарь

instance (существительное)[править]

Морфологические и синтаксические свойства[править]

instance

Существительное.

Корень: —.

Произношение[править]

• МФА (США): ед. ч. [ˈɪnstəns]  мн. ч. []

Семантические свойства[править]

Значение[править]

1. пример, случай, образец ◆ Отсутствует пример употребления (см. рекомендации).
2. комп. экземпляр (класса, объекта, записи) ◆ NS2 simulator: From the interpreted hierarchy, we can also retrieve the simulator instance by invoking instproc instance{} of class Simulator. This instproc executes the OTcl built-in command «info» with an option «instances». This execution returns all the instances of a certain class. Since there is only one Simulator instance, the statement «Simulator info instances» returns the Simulator object as required (From: T.Issariyakul, E.Hossain, Introduction to Network Simulator NS2, (c) Springer Science+Business Media, LLC 2009)
3. требование, настояние; запрос, просьба ◆ Отсутствует пример употребления (см. рекомендации).
4. этап, ступень ◆ Отсутствует пример употребления (см. рекомендации).
5. инстанция ◆ Отсутствует пример употребления (см. рекомендации).

Синонимы[править]

Антонимы[править]

Гиперонимы[править]

Гипонимы[править]

Родственные слова[править]

Ближайшее родство

Этимология[править]

Происходит от лат. instantia «настоящий момент, непосредственная близость», от гл. instare «стоять, быть поблизости», далее из in- «в» + stāre «стоять», далее из праиндоевр. *sta- «стоять». Англ. instance впервые около 1380 г., заимтсв. через ст.-франц. Использованы материалы Online Etymology Dictionary Дугласа Харпера. См. Список литературы.

Фразеологизмы и устойчивые сочетания[править]

Морфологические и синтаксические свойства[править]

instance

Глагол.

Корень: —.

Произношение[править]

• МФА (США): [ˈɪnstəns] 

Семантические свойства[править]

Значение[править]

1. приводить пример; ссылаться ◆ Отсутствует пример употребления (см. рекомендации).
2. служить, быть примером ◆ Отсутствует пример употребления (см. рекомендации).

Синонимы[править]

Антонимы[править]

Гиперонимы[править]

Гипонимы[править]

Родственные слова[править]

Ближайшее родство

Этимология[править]

От ??

Фразеологизмы и устойчивые сочетания[править]

Морфологические и синтаксические свойства[править]

instance

Существительное, женский род.

Корень: —.

Произношение[править]

Семантические свойства[править]

Значение[править]

1. требование, настояние; запрос, (настоятельная) просьба ◆ Отсутствует пример употребления (см. рекомендации).
2. судебное производство; рассмотрение дела ◆ Отсутствует пример употребления (см. рекомендации).
3. инстанция, орган ◆ Отсутствует пример употребления (см. рекомендации).
4. комп. экземпляр (класса, объекта, записи) ◆ Отсутствует пример употребления (см. рекомендации).
5. компоненты структуры личности (во фрейдистской психологии) ◆ Отсутствует пример употребления (см. рекомендации).

Синонимы[править]

Антонимы[править]

Гиперонимы[править]

Гипонимы[править]

Родственные слова[править]

Ближайшее родство

Этимология[править]

Происходит от лат. instantia «настоящий момент, непосредственная близость», от гл. instare «стоять, быть поблизости», далее из in- «в» + stāre «стоять», далее из праиндоевр. *sta- «стоять».

Фразеологизмы и устойчивые сочетания[править]

Значение слова ИНСТАНС. Что такое ИНСТАНС?

• Инстанс (англ. instance — экземпляр, случай, этап)
  Инстанс — экземпляр класса в объектно-ориентированном программировании.

  Инстанс — подземелье в ролевых многопользовательских играх.

Источник: Википедия

Делаем Карту слов лучше вместе

Привет! Меня зовут Лампобот, я компьютерная программа, которая помогает делать Карту слов. Я отлично умею считать, но пока плохо понимаю, как устроен ваш мир. Помоги мне разобраться!

Спасибо! Я обязательно научусь отличать широко распространённые слова от узкоспециальных.

Насколько понятно значение слова велеречивый (прилагательное):

Кристально
понятно

Понятно
в общих чертах

Могу только
догадываться

Понятия не имею,
что это

Другое
Пропустить

инстанс — Викисловарь

В Википедии есть страница «инстанс».

Содержание

• 1 Русский
  • 1.1 Морфологические и синтаксические свойства
  • 1.2 Произношение
  • 1.3 Семантические свойства
    • 1.3.1 Значение
    • 1.3.2 Синонимы
    • 1.3.3 Антонимы
    • 1.3.4 Гиперонимы
    • 1.3.5 Гипонимы
  • 1.4 Родственные слова
  • 1.5 Этимология
  • 1.6 Фразеологизмы и устойчивые сочетания
  • 1.7 Перевод
  • 1.8 Библиография

В Викиданных есть лексема инстанс (L113159).

Морфологические и синтаксические свойства[править]

падеж	ед. ч.	мн. ч.
Им.	и́нстанс	и́нстансы
Р.	и́нстанса	и́нстансов
Д.	и́нстансу	и́нстансам
В.	и́нстанс	и́нстансы
Тв.	и́нстансом	и́нстансами
Пр.	и́нстансе	и́нстансах

и́н-станс

Существительное, неодушевлённое, мужской род, 2-е склонение (тип склонения 1a по классификации А. А. Зализняка).

Корень: -инстанс-.

Произношение[править]

• МФА: [ˈinstəns]

Семантические свойства[править]

Значение[править]

1. неол. спец. отдельный экземпляр, образец чего-либо ◆ Отсутствует пример употребления (см. рекомендации).

Синонимы[править]

1. частич.: объект

Антонимы[править]

Гиперонимы[править]

1. экземпляр

Гипонимы[править]

Родственные слова[править]

Ближайшее родство
существительные: инстанция, инстанцирование глаголы: инстанцировать

Этимология[править]

Происходит от англ. instance.

Фразеологизмы и устойчивые сочетания[править]

Перевод[править]

Список переводов

Библиография[править]

Для улучшения этой статьи желательно: Добавить пример словоупотребления для значения с помощью {{пример}} Добавить все семантические связи (отсутствие можно указать прочерком, а неизвестность — символом вопроса) Добавить хотя бы один перевод в секцию «Перевод»

Создание масштабируемого API на спотовых инстансах AWS / Хабр

Всем привет! Меня зовут Кирилл, я CTO в Adapty. Большая часть нашей архитектуры находится на AWS, и сегодня я расскажу о том, как мы сократили расходы на сервера в 3 раза за счёт использования спотовых инстансов на продакшн окружении, а также о том, как настроить их автомасштабирование. Сначала будет обзор того, как это работает, а потом подробная инструкция для запуска.

Что такое спотовые инстансы?

Спотовые инстансы — это сервера других пользователей AWS, которые в данный момент простаивают, и они продают их с большой скидкой (Amazon пишет до 90%, по нашему опыту ~3x, варьируется в зависимости от региона, AZ и типа инстанса). Основное их отличие от обычных в том, что они могут выключиться в любой момент. Поэтому мы долгое время считали, что их нормально использовать для дев окружений, либо для задач по расчёту чего-то, с сохранением промежуточных результатов на S3 или в базу, но не для прода. Существуют сторонние решения, которые позволяют использовать споты на проде, но там для нашего кейса много костылей, поэтому мы не внедряли их. Подход, описанный в статье, работает полностью в рамках стандартного функционала AWS, без дополнительных скриптов, кронов и тд.

Далее приведу несколько скриншотов, которые показывают историю цен на спотовые инстансы.

m5.large в регионе eu-west-1 (Ireland). Цена преимущественно стабильна на протяжении 3 месяцев, в настоящий момент экономия 2.9x.

m5.large в регионе us-east-1 (N. Virginia). Цена постоянно меняется на протяжении 3 месяцев, в настоящий момент экономия от 2.3x до 2.8x в зависимости от зоны доступности.

t3.small в регионе us-east-1 (N. Virginia). Цена стабильна на протяжении 3 месяцев, в настоящий момент экономия 3.4x.

Архитектура сервиса

Базовая архитектура сервиса, о котором мы будем говорить в рамках данной статьи, изображена на диаграмме ниже.

Application Load Balancer → EC2 Target Group → Elastic Container Service

В качестве балансировщика используется Application Load Balancer (ALB), который отправляет запросы в EC2 Target Group (TG). TG отвечает за то, чтобы открыть на инстансах порты для ALB и связать их с портами контейнеров Elastic Container Service (ECS). ECS — это аналог Kubernetes в AWS, который занимается менеджментом Docker контейнеров.

На одном инстансе может быть несколько работающих контейнеров с одинаковыми портами, поэтому мы не можем задать их фиксировано. ECS сообщает TG, что он запускает новый таск (в терминологии Kubernetes это называется под), она делает проверку свободных портов на инстансе и назначает один из них для запускаемого таска. Также TG регулярно проверяет, работает ли инстанс и апи на нём с помощью health check, и если видит какие-то проблемы, то перестаёт передавать туда запросы.

EC2 Auto Scaling Groups + ECS Capacity Providers

В приведённой выше диаграмме не показан сервис EC2 Auto Scaling Groups (ASG). Из названия можно понять, что он отвечает за масштабирование инстансов. При этом до недавнего времени в AWS не было встроенной возможности управлять количеством запущенных машин из ECS. ECS позволял масштабировать количество тасков, например, по использованию CPU, RAM или количеству запросов. Но если таски занимали все свободные инстансы, то новые машины автоматически не поднимались.

Это изменилось с появлением ECS Capacity Providers (ECS CP). Теперь каждый сервис в ECS можно связать с ASG, и если таски не умещаются на работающих инстансах, то поднимутся новые (но в рамках установленных лимитов ASG). Это работает и в обратную сторону, если ECS CP видит простаивающие инстансы без тасков, то он даст команду ASG, чтобы она их выключила. У ECS CP есть возможность указать целевой процент загрузки инстансов, так, чтобы некоторое количество машин было всегда свободно для быстрого масштабирования тасков, расскажу об этом чуть позже.

EC2 Launch Templates

Последний сервис, о котором я расскажу, прежде чем перейти к подробному описанию создания данной инфраструктуры, — EC2 Launch Templates. Он позволяет создать шаблон, по которому будут запускаться все машины, чтобы не повторять это каждый раз с нуля. Тут можно выбрать тип запускаемой машины, группу безопасности, образ диска и много других параметров. Также можно указать пользовательские данные, которые будут залиты на все запускаемые инстансы. В пользовательских данных можно запускать скрипты, например, можно отредактировать содержимое файла конфигурации ECS агента.

Один из наиболее важных в рамках данной статьи параметром конфигурации — ECS_ENABLE_SPOT_INSTANCE_DRAINING=true. Если этот параметр включен, то как только ECS получает сигнал о том, что спотовый инстанс забирают, он переводит все таски, которые работают на нём в статус Draining. Никакие новые таски на этот инстанс назначаться не будут, если есть таски, которые прямо сейчас хотят выкатится на него, они отменяются. Запросы с балансировщика тоже перестают приходить. Уведомление об удалении инстанса приходит за 2 минуты до фактического события. Поэтому если ваш сервис не выполняет задач дольше 2 минут и не сохраняет ничего на диск, то вы можете использовать спотовые инстансы без потери данных.

По поводу диска — AWS недавно сделал возможным использование Elastic File System (EFS) вместе с ECS, с этой схемой даже диск не является преградой, но мы это не пробовали, так как в принципе нам диск не нужен для хранения состояния. По умолчанию после получения SIGINT (отправляется в момент перевода таска в статус Draining) все работающие задачи будут остановлены через 30 секунд, даже если они не успели выполниться, изменить это время можно с помощью параметра ECS_CONTAINER_STOP_TIMEOUT. Главное не выставлять его больше 2 минут для спотовых машин.

Создание сервиса

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

EC2 Launch Template

В данном сервисе создаётся конфигурация машин, которые будут использоваться. Управление шаблонами происходит в разделе EC2 -> Instances -> Launch templates.

Amazon machine image (AMI) — указываем образ диска, с которым будут запускаться все инстансы. Для ECS в большинстве случаев стоит использовать оптимизированный образ от Amazon. Он регулярно обновляется и содержит всё необходимое для работы ECS. Чтобы узнать актуальный ID образа, заходим на страницу Amazon ECS-optimized AMIs, выбираем используемый регион и копируем AMI ID для него. Например, для региона us-east-1 актуальный на момент написания статьи ID — ami-00c7c1cf5bdc913ed. Этот ID нужно вставить в пункт Specify a custom value.

Instance type — указываем тип инстанса. Выбираете тот, который лучше всего подходит для вашей задачи.

Key pair (login) — указываем сертификат, с помощью которого можно будет подключиться с инстансу по SSH, если это нужно.

Network settings — указываем параметры сети. Networking platform в большинстве случаев должна быть Virtual Private Cloud (VPC). Security groups — группы безопасности для ваших инстансов. Так как мы будем использовать балансировщик перед инстансами, то рекомендую указывать здесь группу, которая разрешает входящие соединения только с балансировщика. То есть у вас будет 2 группы безопасности, одна для балансировщика, которая разрешает входящие (inbound) соединения отовсюду по портам 80 (http) и 443 (https), а вторая для машин, которая разрешает входящие соединения по любым портам от группы балансировщика. Исходящие (outbound) соединения в обеих группах нужно открыть по TCP протоколу на все порты на все адреса. Можно ограничить порты и адреса для исходящих соединений, но тогда нужно постоянно мониторить, что вы не пытаетесь обратиться куда-то по закрытому порту.

Storage (volumes) — указываем параметры дисков для машин. Объём диска не может быть меньше того, что задан в AMI, для ECS Optimized — 30 GiB.

Advanced details — указываем дополнительные параметры.

Purchasing option — хотим ли мы покупать спотовые инстансы. Мы хотим, но здесь эту галочку отмечать не будем, настроим это в Auto Scaling Group, там больше опций.

IAM instance profile — указываем роль, с которой будут запускать инстансы. Для того, чтобы инстансы работали в ECS, им нужны права, которые обычно лежат в роли ecsInstanceRole. В некоторых случаях она может быть создана, если нет, то здесь инструкция о том, как это сделать. После создания указываем её в шаблоне.
Дальше идёт много параметров, в основном везде можно оставлять дефолтные значения, но у каждого из них понятное описание. Я всегда включаю параметры EBS-optimized instance и T2/T3 Unlimited, если используются burstable инстансы.

User data — указываем пользовательские данные. Мы будем редактировать файл /etc/ecs/ecs.config, в котором лежит конфигурация агента ECS.
Пример того, как может выглядеть user data:

#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={\"registry.gitlab.com\":{\"username\":\"username\",\"password\":\"password\"}}" >> /etc/ecs/ecs.config

ECS_CLUSTER=DemoApiClusterProd — параметр указывает, что инстанс принадлежит кластеру с заданным именем, то есть этот кластер сможет размещать на этом сервере свои таски. Мы пока не создали кластер, но при создании будем использовать это имя.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — параметр указывает, что при получении сигнала о выключении спотового инстанса, все таски на нём должны переводиться в статус Draining.

ECS_CONTAINER_STOP_TIMEOUT=1m — параметр указывает, что после получения сигнала SIGINT, у всех задач есть 1 минуты, прежде чем их убьют.

ECS_ENGINE_AUTH_TYPE=docker — параметр указывает, что в качестве механизма авторизации используется docker-схема

ECS_ENGINE_AUTH_DATA=... — параметры подключения к приватному container registry, где хранятся ваши Docker образы. Если он публичный, то ничего указывать не нужно.

В рамках данной статьи я буду использовать публичный образ из Docker Hub, поэтому указывать параметры ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA не нужно.

Полезно знать: рекомендуется регулярно обновлять AMI, потому что в новых версиях обновляются версии Docker, Linux, ECS агента и др. Чтобы не забывать об этом, можно настроить уведомления о выходе новых версий. Вы можете получать уведомления на email и обновлять руками, а можете написать Lambda-функцию, которая будет автоматически создавать новую версию Launch Template с обновлённым AMI.

EC2 Auto Scaling Group

Auto Scaling Group отвечает за запуск и масштабирование инстансов. Управление группами происходит в разделе EC2 -> Auto Scaling -> Auto Scaling Groups.

Launch template — выбираем созданный на предыдущем шаге шаблон. Версию оставляем дефолтную.

Purchase options and instance types — указываем типы инстансов для кластера. Adhere to launch template использует тип инстанса из Launch Template. Combine purchase options and instance types позволяет гибко настраивать типы инстансов. Мы будем использовать его.

Optional On-Demand base — количество обычных, не спотовых инстансов, которые всегда будут работать.

On-Demand percentage above base — процентное соотношение обычных и спотовых инстансов, 50-50 будет распределять поровну, 20-80 на каждый обычный инстанс будет подниматься 4 спотовых. В рамках данного примера я укажу 50-50, но в реальности мы чаще всего делаем 20-80, в некоторых случаях 0-100.

Instance types — тут можно указать дополнительные типы инстансов, которые будут использоваться в кластере. Мы никогда не использовали, потому что я не очень понимаю смысл этой истории. Возможно дело в лимитах на конкретные типы инстансов, но они увеличиваются через поддержку легко. Если вы знаете применение, буду рад прочитать в комментариях)

Network — настройки сети, выбираете VPC и подсети для машин, в большинстве случаев стоит выбрать все доступные подсети.

Load balancing — настройки балансировщика, но мы это сделаем отдельно, здесь ничего не трогаем. Health checks также будут настроены позже.

Group size — указываем лимиты на количество машин в кластере и желаемое количество машин на старте. Количество машин в кластере никогда не станет меньше минимально указанного и больше максимального, даже если по метрикам должно произойти масштабирование.

Scaling policies — параметры масштабирование, но мы будем масштабировать, отталкиваясь от запущенных ECS тасков, поэтому настроим масштабирование позже.

Instance scale-in protection — защита инстансов от удаления при масштабировании вниз. Включаем, чтобы ASG не удалила машину, на которой есть работающие таски. Отключать защиту для инстансов, на которых нет тасков, будет ECS Capacity Provider.

Add tags — можно указать теги для инстансов (для этого должна стоять галочка Tag new instances). Рекомендую указать тег Name, тогда все инстансы, которые запускаются в рамках группы, будут одинаково называться, их удобно смотреть в консоли.

После создания группы откройте её и зайдите в раздел Advanced configurations, почему на этапе создания в консоли видны не все опции.

Termination policies — правила, которые учитываются при удалении инстансов. Они применяются по порядку. Мы обычно используем такие, как на картинке ниже. Сначала удаляются инстансы с наиболее старым Launch Template (например, если мы обновили AMI, у нас создалась новая версия, но все инстансы успели на неё перейти). Потом выбираются инстансы, которые ближе всего к следующему расчётному часу по биллингу. И дальше выбираются самые старые по дате запуска.

Полезно знать: для обновления всех машин в кластере, удобно использовать Instance Refresh. Если совместить это с Lambda-функцией из предыдущего шага, то у вас будет полностью автоматизированная система апдейта инстансов. Перед обновлением всех машин необходимо отключить instance scale-in protection для всех инстансов в группе. Не настройку в группе, а именно защиту с самих машин, это делается на вкладке Instance management.

Application Load Balancer и EC2 Target Group

Балансировщик создаётся в разделе EC2 → Load Balancing → Load Balancers. Мы будем использовать Application Load Balancer, сравнение разных типов балансировщиков можно прочитать на странице сервиса.

Listeners — имеет смысл сделать 80 и 443 порты и сделать редирект с 80 на 443 с позже помощью правил балансировщика.

Availability Zones — в большинстве случаем выбираем всем зоны доступности.

Configure Security Settings — здесь указывается SSL-сертификат для балансировщика, самый удобный вариант — сделать сертификат в ACM. Про различия Security Policy можно почитать в документации, можно оставлять выбранный по умолчанию ELBSecurityPolicy-2016-08. После создания балансировщика, вы увидите его DNS name, на который необходимо настроить CNAME для вашего домена. Например, так это выглядит в Cloudflare.

Security Group — создаём или выбираем группу безопасности для балансировщика, подробнее об этом писал чуть выше в разделе EC2 Launch Template → Network settings.

Target group — создаём группу, которая отвечает за роутинг запросов с балансировщика на машины и проверяет их доступность, чтобы заменить в случае проблем. Target type должен быть Instance, Protocol и Port любые, если вы используете HTTPS для общения между балансировщиком и инстансами, то на них надо загрузить сертификат. В рамках данного примера мы это делать не будем, просто оставим 80 порт.

Health checks — параметры проверки работоспособности сервиса. В настоящем сервисе это должен быть отдельный запрос, который реализует важные части бизнес-логики, в рамках данного примера я оставлю настройки по-умолчанию. Далее можно выбрать интервал запросов, таймаут, коды успешных ответов и др. В нашем примере укажем Success codes 200-399, потому что Docker образ, который будет использоваться, возвращает 304 код.

Register Targets — здесь выбираются машины для группы, но в нашем случае этим будет заниматься ECS, поэтому просто пропускаем этот шаг.

Полезно знать: на уровне балансировщика можно включить логи, которые будут сохраняться в S3 в определённом формате. Оттуда их можно экспортировать в сторонние сервисы для аналитики, а можно делать SQL-запросы прямо по данным в S3 с помощью Athena. Это удобно и работает без какого-то дополнительного кода. Также рекомендую настроить удаление логов из бакета S3 по истечение заданного периода времени.

ECS Task Definition

На предыдущих шагах мы создали всё, что связано с инфраструктурой сервиса, теперь переходим к описанию контейнеров, которые мы будем запускать. Это делается в разделе ECS → Task Definitions.

Launch type compatibility — выбираем EC2.

Task execution IAM role — выбириаем ecsTaskExecutionRole. С помощью неё пишутся логи, даётся доступ к секретным переменным и др.

В разделе Container Definitions нажимаем Add Container.

Image — ссылка на образ с кодом проекта, в рамках данного примера я буду использовать публичный образ с Docker Hub bitnami/node-example:0.0.1.

Memory Limits — лимиты по памяти для контейнера. Hard Limit — жёсткий лимит, если контейнер выйдет за указанное значение, то выполнится команда docker kill, контейнер сразу же умрёт. Soft Limit — мягкий лимит, контейнер может выйти за указанное значение, но при этом при размещение тасков на машины будет учитываться этот параметр. Например, если на машине 4 GiB оперативной памяти, а soft limit контейнера — 2048 MiB, то на этой машине может быть максимум 2 запущенных таска с этим контейнером. В реальности 4 GiB оперативной памяти — это чуть меньше, чем 4096 MiB, это можно посмотреть на вкладке ECS Instances в кластере. Soft limit не может быть больше hard limit. Важно понимать, что если в одном таске есть несколько контейнеров, то их лимиты суммируются.

Port mappings — в Host port указываем 0, это значит, что порт будет назначаться динамически, его будет отслеживать Target Group. Container Port — порт, на котором работает ваше приложение, часто задаётся в команде для исполнения, либо назначается в коде вашего приложения, Dockerfile и тд. Для нашего примера используем 3000, потому что он указан в Dockerfile используемого образа.

Health check — параметры проверки работоспособности контейнера, не путать с тем, который настроен в Target Group.

Environment — настройки окружения. CPU units — похоже на Memory limits, только про процессор. Каждое ядро процессора — 1024 юнитов, так что если на сервере двухъядерный процессор, и у контейнера стоит значение 512, то на одном сервере может быть запущено 4 таска с этим контейнером. CPU units всегда соответствуют количеству ядер, их не может быть чуть меньше как в случае с памятью.

Command — команда для запуска сервиса внутри контейнера, все параметры указываются через запятую. Это может быть gunicorn, npm и тд. Если не указано, то будет использовано значение директивы CMD из Dockerfile. Указываем npm,start.

Environment variables — переменные окружения контейнера. Это могут быть как просто текстовые данные, так и секретные переменные из Secrets Manager или Parameter Store.

Storage and Logging — здесь настроим логирование в CloudWatch Logs (сервис для логов от AWS). Для этого достаточно включить галочку Auto-configure CloudWatch Logs. После создания Task Definition автоматически создастся группа логов в CloudWatch. По умолчанию логи в ней хранятся бесконечно, рекомендую изменить Retention period с Never Expire на требуемый срок. Это делается в CloudWatch Log groups, надо кликнуть на текущий период и выбрать новый.

ECS Cluster и ECS Capacity Provider

Переходим в раздел ECS → Clusters, чтобы создать кластер. В качестве шаблона выбираем EC2 Linux + Networking.

Cluster name — очень важно, делаем здесь такое же имя, как указано в Launch Template в параметре ECS_CLUSTER, в нашем случае — DemoApiClusterProd. Отмечаем галочку Create an empty cluster. Опционально можно включить Container Insights, чтобы смотреть метрики по сервисам в CloudWatch. Если вы всё сделали правильно, то в разделе ECS Instances вы увидите машины, которые были созданы в Auto Scaling group.

Переходим на вкладку Capacity Providers и создаём новый. Напомню, что он нужен для того, чтобы управлять созданием и выключением машин в зависимости от количества работающих ECS тасков. Важно отметить, что провайдер может быть привязан только к одной группе.

Auto Scaling group — выбираем созданную ранее группу.

Managed scaling — включаем, чтобы провайдер мог масштабировать сервис.

Target capacity % — какой процент загрузки машин тасками нам нужен. Если указать 100%, то все машины всегда будет заняты работающими тасками. Если указать 50%, то половина машин всегда будут свободными. В таком случае, если случится резкий скачок в нагрузке, новые такси сразу попадут на свободные машины, без необходимости ждать развёртывания инстансов.

Managed termination protection — включаем, этот параметр разрешает провайдеру убирать защиту инстансов от удаления. Это происходит, когда на машине нет активных тасков и позволяет Target capacity %.

ECS Service и настройка масштабирования

Последний шаг:) Чтобы создать сервис, надо зайти в созданный ранее кластер на вкладку Services.

Launch type — надо кликнуть на Switch to capacity provider strategy и выбрать созданные ранее провайдер.

Task Definition — выбираем созданный раннее Task Definition и его ревизию.

Service name — чтобы не путаться, мы всегда указываем такой же, как Task Definition.

Service type — всегда Replica.

Number of tasks — желаемое количество активных тасков в сервисе. Этот параметр управляется масштабированием, но всё равно его надо указать.

Minimum healthy percent и Maximum percent — определяют поведение тасков при деплое. Значения по умолчанию 100 и 200, говорят о том, что в момент деплоя количество тасков увеличится в 2 раза, а потом вернётся к желаемому. Если у вас работает 1 таск, min=0, а max=100, то тогда при деплое он будет убиваться, и после этого подниматься новый, то есть будет простой. Если работает 1 таск, min=50, max=150, то деплой вообще не случится, потому что он 1 таск нельзя разделить пополам или увеличить в полтора раза.

Deployment type — оставляем Rolling update.

Placement Templates — правила размещения тасков на машинах. По умолчанию стоит AZ Balanced Spread — это значит, кто каждый новый таск будет помещаться на новый инстанс до тех пор, пока не поднимутся машины во всех зонах доступности. Мы обычно делаем BinPack — CPU и Spread — AZ, при такой политике таски помещаются максимально плотно по на одну машину по CPU. При необходимости создания новой машины, она создаётся в новой зоне доступности.

Load balancer type — выбираем Application Load Balancer.

Service IAM role — выбираем ecsServiceRole.

Load balancer name — выбираем созданный ранее балансировщик.

Health check grace period — пауза перед выполнением проверок работоспособности после выкатки нового таска, мы обычно ставим 60 секунд.

Container to load balance — в пункте Target group name выбираем созданную ранее группу, и всё автоматически заполнится.

Service Auto Scaling — параметры масштабирования сервиса. Выбираем Configure Service Auto Scaling to adjust your service’s desired count. Задаём минимальное и максимально количество тасков при масштабировании.

IAM role for Service Auto Scaling — выбираем AWSServiceRoleForApplicationAutoScaling_ECSService.

Automatic task scaling policies — правила для масштабирования. Есть 2 типа:

1. Target tracking — отслеживание целевой метрики (использование CPU/RAM или количество запросов на каждый таск). Например, мы хотим среднюю загрузку процессора была 85%, когда она станет выше, то новые таски будут добавляться до тех пор, пока она не придёт к целевому значению. Если загрузка ниже, то таски наоборот будут убираться, если не включена защита от масштабирования вниз (Disable scale-in).
2. Step scaling — реакция на произвольное событие. Тут можно настроить реакцию на любое событие (CloudWatch Alarm), когда она будет происходить, можно добавить или убрать указанное количество тасков, либо же указать точное количество тасков.

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

Заключение

Если вы следовали инструкции и использовали тот же Docker образ, ваш сервис должен возвращать такую страницу.

1. Мы создали шаблон, по которому запускаются все машины в сервисе. Мы также научились обновлять машины при изменении шаблона.
2. Мы настроили обработку сигнала остановки спотового инстанса, поэтому в течение минуты после его получения все работающие таски убираются с машины, таким образом ничего не теряется и не прерывается.
3. Мы подняли балансировщик, чтобы равномерно распределять нагрузку по машинам.
4. Мы создали сервис, который работает на спотовых инстансах, за счёт этого сокращаются расходы на машины примерно в 3 раза.
5. Мы настроили автомасштабирование в обе стороны, чтобы обрабатывать увеличение нагрузок, но в то же время не платить за простой.
6. Мы используем Capacity Provider, чтобы приложение управляло инфраструктурой (машинами), а не наоборот.
7. Мы молодцы.

Если у вас есть предсказуемые всплески нагрузки, например, вы рекламируетесь в большой email-рассылке, вы можете настроить масштабирование по расписанию.

Ещё можно делать масштабирование на основе данных из разных частей вашей системы. Например, у нас есть функционал рассылки индивидуальных промо-предложений пользователям мобильного приложения. Иногда кампания рассылается на 1М+ человек. После такой рассылки всегда наблюдается большой рост запросов к API, так как много пользователей одновременно заходят в приложение. Так что если мы видим, что в очереди на отправку промо-пушей их стало значительно больше стандартных показателей, мы сразу можем запустить несколько дополнительных машин и тасков, чтобы быть готовым к нагрузке.

Буду рад, если в комментариях расскажете интересные кейсы использования спотовых инстансов и ECS или же что-то по масштабированию.

Скоро будут статьи про то, как мы обрабатываем тысячи аналитических эвентов в секунду на преимущественно serverless стэке (с деньгами) и как устроен деплой сервисов с помощью GitLab CI и Terraform Cloud.

Подписывайтесь на нас, будет интересно!

перевод, произношение, транскрипция, примеры использования

На этом этапе я предпочитаю не сообщать своего имени. ☰

Сошлёмся лишь на одного автора — Уолтона. ☰

Возможно, это единичный такой случай в истории человечества. ☰

Она привела первую главу как доказательство его умения описывать место действия. ☰

They came across many instances of discrimination. 

Они столкнулись со многими случаями дискриминации. ☰

In most instances the disease can be controlled by medication. 

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

We need to rethink the way we consume energy. Take, for instance, our approach to transport. 

Нужно переосмыслить то, как мы потребляем энергию. Возьмём, например, наш подход к транспорту. ☰

They have decided not to oppose the decision in this instance. 

В данном случае они решили не противиться решению. ☰

The single appearance of the word in Domesday Book is the earliest instance. 

Единственное употребление этого слова в Книге Судного дня является самым ранним примером. ☰

These delays are just another instance of bureaucratic inefficiency. 

Эти задержки — просто ещё один пример бюрократической неэффективности. ☰

Anyone wishing to join the society should apply in the first instance to the secretary. 

Всем желающим вступить в общество следует для начала обратиться к секретарю. ☰

In this instance, the lawyer’s job is to make the jury doubt the witness’s credibility. 

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

He instanced one particular incident as an illustration of their penchant for practical jokes. 

В качестве иллюстрации их склонности к розыгрышам он привёл один конкретный пример. ☰

Enquiries should be made in the first instance to the Human Resources Director. 

В первую очередь запросы нужно направлять в адрес директора по управлению персоналом. ☰

Martin is not illiterate but I think close to it. I never saw him read a newspaper, for instance. 

Мартин не то чтобы безграмотный, но, по-моему, где-то рядом. Я никогда не видел, чтобы он читал, например, газету. ☰

Эффективное использование spot-инстансов AWS / Хабр

Spot-инстансы — это по сути продажа свободных в данный момент ресурсов со отличной скидкой. При этом инстанс могут в любой момент выключить и забрать обратно. В статье я расскажу о особенностях и практике работы с этим предложением от AWS.

Стоимость использования spot-инстанса может меняться время от времени. Во время заказа вы делаете ставку(bid) — указываете максимальную цену, которую готовы платить за использование. Именно баланс ставок и свободных ресурсов формирует итоговую стоимость, которая при этом отличается в разных регионах и даже в availability zones региона.

В определенный момент взвешенная цена может превысить цену обычного on-demand инстанса. Именно поэтому не стоит делать избыточные ставки — вам действительно могут продать инстанс по 1000$ за час. Не знаете, какую ставку сделать — указывайте цену on-demand инстанса (именно она используется по-умолчанию).

Жизненный цикл spot-инстанса

Итак, мы формируем запрос, а AWS выделяет нам инстансы. Как только Амазону понадобились выданные инстансы или цена превысила указанный нами лимит, запрос закрывается. Это значит, что наши инстансы будут terminated/hibernated.

Также запрос может быть закрыть из-за ошибки в запросе. И тут надо быть аккуратнее. Например, вы создали запрос и получили инстансы. А потом удалили ассоциированную IAM-роль. Ваш запрос закроется со статусом “error”. При этом инстансы будут остановлены.

И конечно же вы в любой момент можете отменить запрос, что так же приведет к остановке инстансов.

Сам запрос может быть:

• Одноразовым — как только у нас забрали инстансы, запрос закрывается
• Постоянным — инстансы нам возвращают после повторного включения.
• С гарантированным обслуживанием на 1-6 часов.

В итоге у нас есть две основные задачи для сервиса с желаемым 100% аптаймом:

• Формировать оптимальные spot-requests
• Обрабатывать события отключения инстанса

Средства

Одним из самых мощных средств работы со spot-запросами является spot fleet. Он позволяет динамически формировать запросы таким образом, чтобы удовлетворить заданные условия. Например, если инстансы подорожали в одной AvailabilityZone, то можно быстренько запустить такие же в другой. Также появляется такой замечательный фактор, как “вес” инстанса. Например, для выполнения задачи нам требуется 100 одноядерных ноды. Или 50 двухядерных. И это значит, на примере инстансов T2-типа, что мы можем использовать 100 small или 50 large или 25 xlarge. Именно оптимальное распределение и перераспределение минимизирует и стоимость, и вероятность того, что запрос будет неудовлетворен. Новсе же сохраняется вероятность того, что во всех AvailabilityZones не найдется нужного количества инстансов с нашими параметрами.

К счастью, AWS оставляет нам 2 мин между принятием решения об остановке и самим выключением. Именно а этот момент по ссылке начнет возвращаться таймер отключения:

http://169.254.169.254/latest/meta-data/spot/termination-time

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

#!/usr/bin/env bash
while true
    do
        if [ -z $(curl -Is http://169.254.169.254/latest/meta-data/spot/termination-time | head -1 | grep 404 | cut -d \  -f 2) ]
            then
                echo “Instanсe is going to be terminated soon”
                # Execute pre-shutdown stuff
                break
            else
                # Spot instance is fine.
                sleep 5
        fi
    done

Немного усложним задачу — наши инстансы подключены к Elastic Load Balancer (ELB). Можно воспользоваться демоном из сниппета выше и через API сообщать балансеру статус. Но есть более элегантный способ — проект SeeSpot. Вкратце, демон смотрит одновременно и в /spot/termination-time и, опционально, в healthcheck url вашего сервиса. Как только AWS соберется изъять инстанс, он отмечается как OutOfService в ELB и может опционально выполнить финальный CleanUP task.

Итак, мы разобрались, как правильно обрабатывать отключение. Осталось только научиться сохранять требуемую производительность системы, если у нас вдруг решили забрать инстансы. Здесь нам поможет проект autospotting. Идея следующая: мы создаем обычную autoscaling-группу, содержащую on-demand инстансы. Скрипт autospotting находит эти инстансы и по-одному подменяет их полностью соответствующими spot-инстансами(поиск происходит по тэгу). У autoscaling групп есть собственны Healthcheck’и. Как только один из ee членов не проходит проверку, группа пытается вернуть свой объем и создает “здоровый” инстанс исходного типа(а это был on-demand). Таким образом мы сможем переждать, например, скачек цены. Как только spot-requests снова начнут удовлетворяться, autospotting начнет постепенную замену. От себя добавлю, что проект сделан достаточно качественно, и имеет, в том числе, подходы для конфигурации с помощью terraform или cloudformation.

В заключении хотел бы порекомендовать по-возможности использовать spot-инстансы для stateless сервисов. Или же применять S3/EFS. Для конфигураций ECS необходимо подумать про tasks re-balancing.

Что такое инстанс? — Определение с сайта WhatIs.com

WhatIs.com Ищите тысячи технических определений Просмотреть определения :

• А
• Б
• С
• D
• E
• Ф
• г
• H
• я
• Дж
• К
• л
• кв.м
• N
• О
• -П
• квартал
• R
• S
• т
• U
• В
• Вт
• Х
• Я
• Z
• #

Авторизоваться регистр

• Сеть Techtarget
• Расширения файлов

RSS

• Что.ком
• Просмотреть определения Персональные вычисления Потребительские технологии Просмотреть все
  • Настольные и портативные компьютеры
  • Оборудование для конечных пользователей
  • Аббревиатуры и жаргон
  в Интернете
  • Интернет-технологии
  • Мультимедиа и графика
  • Принтеры
  • Беспроводная и мобильная
  AppDev Просмотреть все
  • Гибкая, Скрам, XP
  • Яблоко
  • DevOps
  • Интернет-приложения
  • Java
  • Linux
  • Microsoft
  • Открытый исходный код
  • Операционные системы

.Определение

в кембриджском словаре английского языка

ЭКЗАМЕН | Определение в кембриджском словаре английского языка Обычно я не поддерживаю руководство, но в данном случае я согласен с тем, что они говорят. Тезаурус: синонимы и родственные слова ,

c # — Что означает «_instance = this;» значит?

Переполнение стека

1. Товары
2. Клиенты
3. Случаи использования

1. Переполнение стека Общественные вопросы и ответы
2. Команды Частные вопросы и ответы для вашей команды
3. предприятие Частные вопросы и ответы для вашего предприятия
4. работы Программирование и связанные с ним возможности технической карьеры
5. Талант Нанять технических талантов

.

oop — В чем разница между экземпляром и объектом?

Переполнение стека

1. Товары
2. Клиенты
3. Случаи использования

1. Переполнение стека Общественные вопросы и ответы
2. Команды Частные вопросы и ответы для вашей команды
3. предприятие Частные вопросы и ответы для вашего предприятия
4. работы Программирование и связанные с ним возможности технической карьеры
5. Талант Нанять технических талантов

.