Yandex Scale 2024

2024-10-19 10:17 · 5 мин чтения · jtprogru

Привет, %username%! Я побывал на конференции Yandex.Scale , которая прошла 2024-09-25. Посетил несколько докладов, послушал про запуск нового продукта, а так же довольно интересно и полезно провел время. Сейчас попробую рассказать о том, как это было.

Общее впечатление#

Общее впечатление однозначно положительное. Однако стоит заметить некоторые особенности:

Было душновато – я это списываю на особенности самой площадки, где это проходило (в этом случае был МХАТ);
Хромало питание – причем к качеству питания никаких претензий, а вот к организации прям есть, потому что неоднократно оказывался в ситуации, когда стоя в очереди, как и все, тебе ничего не достается;
Очереди – в самом начале мероприятия были длинные очереди, однако к моменту когда я прибыл на площадку все рассосалось, но фотки были прям страшные (шпион с места действия передавал);
(Не)удобство навигации – к самой локации было довольно просто добраться (мне), однако непосредственно внутри – было крайне сложно сориентироваться, а площадку на 4 этаже я вообще посетил один раз (просто из любопытства), т.к. ползать туда по лестнице (мне) крайне лень.

Доклады#

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

Презентация Yandex BareMetal#

Ребята презентовали новый продукт, который позволит арендовать “железные сервера”. Немного тезисов из данной презентации:

Cloud Compute это классическая виртуализация, которая имеет ряд преимуществ вроде надежности, отказоустойчивости, эластичного масштабирования, быстрого и кастомизируемого выбора ресурсов;
Yandex BareMetal позволяет арендовать выделенные физические сервера со всем вытекающими плюсами и минусами, так что если тебе крайне необходимы “железные сервера”, то можно воспользоваться. Предоставляется полноценная L2-связность;
Новый сервис будет являться отличным выбором для приложений, которые не готовы к облакам, либо имеют достаточно высокие требования к производительности/железу;
Плюсы, по сравнению с использованием своего железа достаточно очевидны: большие капексные расходы, сроки и трудности поставки, сложности масштабирования, сложности в размещении в ЦОД/Co-Location, потребность в дополнительной экспертизе;
На этапе запуска сервис Yandex BareMetal будет предоставлять следующие условия: готовые типовые конфигурации, физическая сеть на 1 Гб/с или 10 Гб/с, приватные сети L2- и L3-связности, заказ N-серверов с поддержкой Terraform, интеграция в ресурсную модель Yandex IAM, ну и iKVM консоль для управления сервером;
Разделение зон ответственности выглядит так: Yandex.Cloud отвечает за весь физический мир, а все что устанавливается на сервере это полностью ответственность клиента;
Сервера заказанные через Yandex BareMetal будут доступны для подключения в Yandex Managed Kubernetes в качестве worker-нод, а так же их можно будет добавить в Yandex Cloud Backup;

Сломать, чтобы починить: Парадокс хаос-инжиниринга в действии#

Это доклад от ребят из компании Mindbox про их опыт построения такой интересной темы, как Chaos Engineering. Они выбирали инструмент, так же набили разные шишки, вот краткие тезисы из доклада:

Цель chaos engineering в том, чтобы выявить узкие места до того, как они проявят себя при промышленной эксплуатации на реальных пользователях;
Рассматривались несколько инструментов, но выбирали между двумя: Chaos Mesh и Litmus . Последний умеет смотреть в Prometheus и Kubernetes API помимо классического HTTP, а так же имеет полноценный GitOps. Однако Chaos Mesh умеет работать с виртуальными машинами, а так же визуальное отображение пайплайнов экспериментов;
Описания экспериментов для Chaos Mesh хранятся рядом с кодом сервисов, которые подвергаются этим экспериментам;
Эксперименты запускаются в неконкурентном режиме – пока эксперимент не завершится, он не будет запущен повторно;
Эксперименты пишутся с учетом проверки всех возможных точек отказа и одной из точек отказа может быть misconfiguration, которая так же проверяется;
Для каждого эксперимента должны быть готовы run books по восстановлению, т.к. всегда может что-то пойти не так;
Эксперимент пишется максимально близким к реальности – не допустимы кейсы вида “прилетели марсиане” или “прибежал Годзилла”;
Всегда есть шанс поломать не только свои сервисы, но и саму хаус-платформу, поэтому ран-буки по ее восстановлению необходимо держать при себе;
Кроме экспериментов на отказ стоит описывать эксперименты на деградацию, что позволит оценивать систему в целом и ее отдельные участки в частности. Так же важно выполнять эксперименты chaos engineering’а часто, что позволит быть ближе к реальности как результатам, так и самим тестам;
Оптимальное временное окно для запуска тестов это середина нагрузки, т.к. в пике может быть страшно, а в минимуме будет довольно скучно. И да, эксперименты проводятся на контуре промышленной эксплуатации, где всегда есть живые пользователи;
Полезно делать аннотации на дашбордах Grafana с началом/завершением экспериментов. Это позволит быстрее реагировать в случае, если что-то пошло не так, а так же более точно оценивать производительность системы и сервисов;
Алерты от системы мониторинга не стоит отключать до того, как убедились, что эксперименты работоспособны и корректны. Желательно 3-5 раз запустить с включенными алертами, а далее уже по ситуации;
Chaos Engineering позволяет повысить надежность и отказоустойчивость системы, приблизить к SLO, улучшить взаимодействие и навыки команды, а так же сократить MTTR.

Как подключаться к S3 из VPC без доступа к интернет#

Сам по себе S3 реализован изначально AWS для решения своих проблем и удовлетворения потребностей. Но ребята из Yandex.Cloud реализовали полностью совместимый сервис. Из интересного, что появилось:

Функционал Security Token Service (STS) полностью совместим с AWS STS API, поэтому можно смело использовать;
Изначально доступ к S3-бакету был равносилен походу в публичную сеть Интернет, однако сейчас можно организовать доступ к S3-бакету не выходя в публичную сеть Интернет;
Для тех, кто использует GeeseFS, может быть полезным тот факт, что реализована поддержка метода PATCH;

Стратегия продукта безопасности в Yandex Cloud#

Не возможно обойти стороной тему безопасности при разговоре про публичные облака. Немного о том, поэтому Yandex Cloud подсветили следующее:

Запуск в облаке снижает и Time To Market и трудозатраты, что однозначно является хорошим плюсом для бизнеса;
Решение внутренних задач по ИБ крайне проблематично отдавать на аутсорс, поэтому компания должна взращивать свои компетенции в сфере ИБ;
Помимо соблюдения кучи требований со стороны Yandex Cloud по теме ИБ от различных регуляторов, появилась сертификация по ИБ (экзамен), которая позволяет проверить своих специалистов на соответствие;
Активно практикуется “догфудинг” – все продукты/сервисы/стандарты активно используются самой компанией;

Итоги#

Очень много времени провел беседуя с архитектором Yandex Cloud – выпытывал устройство Yandex Cloud, т.к. активно живу и работаю в нем. Это самое полезное, что я вынес с данного мероприятия! И именно ради такого я рекомендую всем посещать конференции – ради возможности задать свои вопросы напрямую людям, продуктами которых ты пользуешься.

Если у тебя есть вопросы, комментарии и/или замечания – заходи в чат , а так же подписывайся на канал .

О способах отблагодарить автора можно почитать на странице “Донаты ”.