Это такие же сервера в дата-центрах AWS, то есть там тот же уровень безопасности, та же виртуализация и тд. Единственное отличие, что они могут быть выключены не по вашей инициативе. Ну и цена:)
ага, понял) просто статья и так большая получилась, так что решили в отдельной статье более подробно про Lambda рассказать в разрезе аналитических систем.
А что такое удаленная перегрузка инстансов из мобильного приложения?
Не могу сказать, мы не жили вне облака:) квалификация для управления всем этим нужна, безусловно, но кажется, что ручной работы всё же сильно меньше, а значит вероятность ошибиться. Плюс за нас делаются бэкапы, обновления, менеджится безопасность частично.
И самый большой плюс — это интеграция с другими сервисами внутри AWS. Нужно отправить пуши — есть SNS, для писем SES, для devops и аналитики Lambda + Kinesis, S3 очень удобный, CloudWatch тоже активно используем и много других сервисов. И на всё можно повесить триггеры, связать друг с другом, это очень удобно.
ECS используем очень давно, а с k8s опыта мало. EKS вообще не использовали, в Яндекс Облаке разворачивали кластер на Managed Kubernetes, всё работает, но всё равно как-то не хватает уверенности, что мы его достаточно хорошо понимаем, чтобы в случае проблем быстро понять, что не так.
У нас много сервисов (апи для сдк, апи для дашборда, кеш, асинхронные таски, pgbouncer, внутренние аналитики и др) и несколько окружений. Стабильно работает порядка 30 машин, почти на всех 2 vCPU и 2-4 GiB оперативки. На пиках может быть +10 машин, так как масштабируются не все сервисы.
У нас вообще нет выделенных devops, просто несколько разработчиков за этим следят фоново. В целом всё автономно работает, настроены уведомления по важным показателям, чтобы понимать, если вдруг что-то не по плану идёт, и надо посмотреть.
Про Terraform отдельно напишем, но эта статья рассчитана на первый уровень погружения, поэтому всё было через интерфейс. И в процессе написания статьи действительно всё создали через интерфейс, чтобы убедиться, что это работает:)
Спасибо, будем продолжать!
Нет, новый инстанс подняться за 2 минуты не успеет, там не успевают так быстро отработать все проверки и развёртывание нового. Но если у вас есть свободное место на машинах, то контейнер обычно поднимается быстрее, чем за 2 минуты. Это зависит от контейнера, конечно, но на нашей практике не было дольше 1 минуты.
Чтобы всегда держать какое-то количество свободных инстансов, надо указать Target capacity % меньше 100%. Об этом есть в статье, актуально как для масштабирования, так и для случаев, когда нода умирает.
Но вообще кейс, что инстанс умирает, по нашему опыту, довольно редкий. Не скажу точный процент, но на сотни запущенных инстансов, у нас было меньше 10 таких случаев. Возможно, это связано с тем, что на ECS из-за постоянных деплоев и скейлов инстансы органически постоянно обновляются. То есть когда количество тасков увеличивается, а потом уменьшается, то свободные инстансы удаляются по нашему желанию. Из-за этого время жизни инстанса не очень большое, так что реже случаются кейсы удаления со стороны владельца. При этом у нас есть сервис, где нет масштабирования, и количество машин при деплое не меняется, и вот там спотовые инстансы почти 3 месяца уже живут, то есть всё это время их не убивали. Но их там всего 2, так что не очень репрезентативно.
У нас вебпак собирает файлы именно так, как вы описали, с версиями в названии (хотя больше это нужно для инвалидации кэша). И заливаются по порядку, так что ничего не сломается.
Более того, на AWS у нас перед S3 бакетом со статикой стоит CloudFront, который кэширует всё, и только после обновления всех файлов в бакете запускается инвалидация кэша. Так что там в принципе невозможен вариант, когда что-то битое появится. В Я.О такого нет (надеюсь, что пока)
Локально фронт поднимается просто npm (yarn) скриптом, какой-то сложности в этом нет.
мы не писали, что мы переезжаем в Я.О, если что) потому что пока там нет большого количества сервисов, которые мы постоянно юзаем в AWS, да и инструментов для разработки тоже. Речь в статье про конкретный сервис с описанной инфраструктурой.
1. По факту решение, которое рассматривается в статье, нормально переносится на облако, да, больше работы ручной (балансировщик и оркестратор), но в целом это не сложные вещи. По поводу будущих сервисов — есть роадмэп, так что это не голословное утверждение.
2. Разве это не плюс?
3. Завязка уж точно не такая прямая, как если ты платишь счёт в валюте. Если ты используешь один и тот же класс машин и сервисов, то с очень большой вероятностью у тебя не будет меняться цена вообще. Понятно, что при закупке оборудования курс имеет значение, но в облаках это не главная статья расходов, а остальное в России (обслуживание, энергия и пр.) в рублях.
4. Таким, что в Яндекс не пойдут хостить сервера те, кого масштабно блочит РКН (практика показывает, что они не хотят что-либо делать на территории РФ), поэтому тебя за компанию с ними не закроют. Другой вопрос, что в свете последних новостей из госдумы, могут закрыть тебя от всего остального мира:)
5. Ну тут же не говорится, что кроме Яндекса нет других решений. При этом если смотреть именно на облака, а не на дц, то есть только Яндекс и Мэил. Хранить данные в РФ тоже можно.
Ну и по поводу альфа — да, мы говорим, что сейчас этого нет, поэтому в расчётах под балансировщик и оркестраторы выделены отдельные машины. Для AWS в случае балансировщика приведена цена за ELB, оркестратор не биллится, т.к. ECS, никакого обмана.
Тот же самый слипбокс в Центре Дизайна ARTPLAY обойдётся вам в 500р за сутки. Метро Курская, что тоже не очень-то далеко от центра.
Правда, это уже не формат отеля, но функции свои он полностью выполняет.
Ну не сказал бы, что прям ужасен. Просто ничего другого в сети не нашёл, а сам озвучку не практикую. Для тех, кто не понимает английский, будет смысл ролика понятен, хотя бы. Так что не вижу ничего страшного в этом:)
Недавно обратил внимание на возможность запоминания языка клавиатуры для каждой программы (в Chrome запоминает для каждой вкладке) — очень удобная вещь!
Включить здесь: Системные настройки — Язык и текст — Источники ввода — Параметры источника ввода
А что такое удаленная перегрузка инстансов из мобильного приложения?
И самый большой плюс — это интеграция с другими сервисами внутри AWS. Нужно отправить пуши — есть SNS, для писем SES, для devops и аналитики Lambda + Kinesis, S3 очень удобный, CloudWatch тоже активно используем и много других сервисов. И на всё можно повесить триггеры, связать друг с другом, это очень удобно.
У нас вообще нет выделенных devops, просто несколько разработчиков за этим следят фоново. В целом всё автономно работает, настроены уведомления по важным показателям, чтобы понимать, если вдруг что-то не по плану идёт, и надо посмотреть.
Нет, новый инстанс подняться за 2 минуты не успеет, там не успевают так быстро отработать все проверки и развёртывание нового. Но если у вас есть свободное место на машинах, то контейнер обычно поднимается быстрее, чем за 2 минуты. Это зависит от контейнера, конечно, но на нашей практике не было дольше 1 минуты.
Чтобы всегда держать какое-то количество свободных инстансов, надо указать Target capacity % меньше 100%. Об этом есть в статье, актуально как для масштабирования, так и для случаев, когда нода умирает.
Но вообще кейс, что инстанс умирает, по нашему опыту, довольно редкий. Не скажу точный процент, но на сотни запущенных инстансов, у нас было меньше 10 таких случаев. Возможно, это связано с тем, что на ECS из-за постоянных деплоев и скейлов инстансы органически постоянно обновляются. То есть когда количество тасков увеличивается, а потом уменьшается, то свободные инстансы удаляются по нашему желанию. Из-за этого время жизни инстанса не очень большое, так что реже случаются кейсы удаления со стороны владельца. При этом у нас есть сервис, где нет масштабирования, и количество машин при деплое не меняется, и вот там спотовые инстансы почти 3 месяца уже живут, то есть всё это время их не убивали. Но их там всего 2, так что не очень репрезентативно.
Более того, на AWS у нас перед S3 бакетом со статикой стоит CloudFront, который кэширует всё, и только после обновления всех файлов в бакете запускается инвалидация кэша. Так что там в принципе невозможен вариант, когда что-то битое появится. В Я.О такого нет (надеюсь, что пока)
Локально фронт поднимается просто npm (yarn) скриптом, какой-то сложности в этом нет.
По docker swarm — согласен:)
мы не писали, что мы переезжаем в Я.О, если что) потому что пока там нет большого количества сервисов, которые мы постоянно юзаем в AWS, да и инструментов для разработки тоже. Речь в статье про конкретный сервис с описанной инфраструктурой.
1. По факту решение, которое рассматривается в статье, нормально переносится на облако, да, больше работы ручной (балансировщик и оркестратор), но в целом это не сложные вещи. По поводу будущих сервисов — есть роадмэп, так что это не голословное утверждение.
2. Разве это не плюс?
3. Завязка уж точно не такая прямая, как если ты платишь счёт в валюте. Если ты используешь один и тот же класс машин и сервисов, то с очень большой вероятностью у тебя не будет меняться цена вообще. Понятно, что при закупке оборудования курс имеет значение, но в облаках это не главная статья расходов, а остальное в России (обслуживание, энергия и пр.) в рублях.
4. Таким, что в Яндекс не пойдут хостить сервера те, кого масштабно блочит РКН (практика показывает, что они не хотят что-либо делать на территории РФ), поэтому тебя за компанию с ними не закроют. Другой вопрос, что в свете последних новостей из госдумы, могут закрыть тебя от всего остального мира:)
5. Ну тут же не говорится, что кроме Яндекса нет других решений. При этом если смотреть именно на облака, а не на дц, то есть только Яндекс и Мэил. Хранить данные в РФ тоже можно.
Ну и по поводу альфа — да, мы говорим, что сейчас этого нет, поэтому в расчётах под балансировщик и оркестраторы выделены отдельные машины. Для AWS в случае балансировщика приведена цена за ELB, оркестратор не биллится, т.к. ECS, никакого обмана.
Правда, это уже не формат отеля, но функции свои он полностью выполняет.
Включить здесь: Системные настройки — Язык и текст — Источники ввода — Параметры источника ввода