Привет, %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, т.к. активно живу и работаю в нем. Это самое полезное, что я вынес с данного мероприятия! И именно ради такого я рекомендую всем посещать конференции – ради возможности задать свои вопросы напрямую людям, продуктами которых ты пользуешься.

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