За время работы с объектными хранилищами я встречал немало «подводных рифов» на пути к быстрому и эффективному хранению.
В этой статье я покажу, где чаще всего проседает производительность при работе с S3-совместимым хранилищем, — на примерах из реальных кейсов технической поддержки.
Меня зовут Оля, я разработчик в Yandex Infrastructure и я делаю веб‑плеер — библиотеку для воспроизведения видео на разных сервисах Яндекса (например, на Кинопоиске, Диске, Практикуме и Погоде).
Эта история о том, как мы отказались от опенсорс‑решения для воспроизведения потокового видео и написали свой велосипед. Я расскажу об архитектуре нашего решения и о том, с чем мы столкнулись, когда воплощали его в жизнь. Также покажу, какие эксперименты мы проводили и на какие метрики ориентировались.
В 2021 году мы запустили Greenplum в нашем облаке. И очень скоро столкнулись с тем, что эластичность систем расчёта и хранения — это must have в облачных аналитических БД. А Greenplum — совсем не такой.
Чтобы поменять ситуацию, мы научились отгружать часть данных в S3 и назвали получившееся решение Hybrid Storage. В этой статье расскажу о нём подробнее.
Привет! Меня зовут Паша Сушин. Уже больше десяти лет я занимаюсь в Яндексе развитием платформы YTsaurus — нашего внутреннего инструмента, который в марте 2023 года вышел в опенсорс и теперь доступен всем на GitHub по лицензии Apache 2.0.
Сегодня мой рассказ будет о том, какие ограничения архитектуры мы преодолели, чтобы масштабировать наши кластеры больше чем в сотню раз.
Привет, меня зовут Руслан Савченко, я руководитель службы разработки динамических таблиц в Yandex Infrastructure и преподаватель в Школе анализа данных. Сегодня я поделюсь актуальными инсайтами о том, как ломаются большие системы и как их траблшутить. Думаю, это будет полезно разработчикам и студентам, которые интересуются Site Reliability Engineering. Вообще, мало где сейчас обучают SRE, хотя в индустрии такие задачи очень востребованы.
В основе статьи — материалы SRE Week, открытого интенсива ШАДа по работе с большими нагруженными системами.
В начале апреля мы запустили первую программу сертификации специалистов по облачным технологиям — до этого не было экзаменов по работе с российскими облачными платформами, которые созданы в соответствии с отечественными и международными стандартами тестирования. За 3 месяца с момента запуска состоялось 12 экзаменов, в них участвовали 88 специалистов разного профиля. Большинство участников — инженеры DevOps.
Мы спросили первых обладателей сертификата про их опыт: как сертификация помогает достичь профессиональных целей, как лучше подготовиться и чего стоит ждать тем, кто только собирается сдавать экзамен. Дадим слово четырём участникам с разной облачной специализацией.
Работа в Яндексе ставит огромное количество технических вызовов, которые интересно решать. И один из них — это производительность основной очереди сообщений YDB Topics. Посмотрим, может ли опенсорсный продукт от Яндекса конкурировать с Apache Kafka по производительности.
Меня зовут Зевайкин Александр. Я уже практически 20 лет в IT. Начинал с преподавания в вузе, запускал множество стартапов, руководил командами разработки. В текущий момент я работаю в Яндексе в отделе, занимающимся одной из высоконагруженных систем. Это разработка распределённой базы YDB, в частности, функциональности YDB Topic.
4 июня состоялась infra.conf 2024 — конференция про создание инфраструктуры и эксплуатацию высоконагруженных систем от команды Yandex Infrastructure. На мероприятии мы попросили поделиться своими инфраструктурными историями инженеров не только Яндекса, но и Ozon.Tech, T1, MTS Web Services, Т‑Банка, SberDevices, Альфа‑банка, «Лаборатории Касперского», Selectel, Postgres Pro, СберМаркета и Авито. В результате, по отзывам участников, «хардкор‑концентрат железа и DevOps зашкаливал и летал прямо в воздухе».
В этой статье мы собрали самые интересные моменты по тем докладам, которые вызвали наибольшую реакцию и восторг от полезности в кулуарах и чатах, — чтобы вам было проще сориентироваться, что стоит пересмотреть.
В среду 29 мая мы провели ML2Business — первую конференцию от Yandex Cloud, посвящённую кейсам применения GenAI, NLP, CV и других технологий ML в бизнесе.
Реальный опыт внедрения машинного обучения был представлен в двух треках: GenAI&NLP и GenAI&CV. Их программа была полностью посвящена историям использования ML в разных компаниях. В этой статье мы собрали инсайты спикеров из компаний «Инфосистемы Джет», «ВкусВилл» и Банки.ру, которые могут быть интересны техническим специалистам.
Вот есть у вас сотня коммутаторов или маршрутизаторов. Это много или мало?
Ну вроде как мало. А если надо на всех разом нового сотрудника добавить? А потом удалить уволившегося? А потом поротировать скомпрометированные пароли и ключи?
И тут приходит служба безопасности, которая, во-первых, хочет централизованно контролировать, у кого какие доступы, во-вторых, актуальны ли они на железках, в-третьих, ещё и смотреть, кто что когда запускал, да ещё и разрешать или запрещать это делать («Просто продолжай, не останавливайся» © СИБ).
Ну вот совсем уже и не мало. Чувствуете, чем это пахнет? Даааа, TACACS-ом.
Сегодня мы разберём, как сделать аутентификацию и авторизацию на сетевом оборудовании на основе TACACS, сделать работу сервиса отказоустойчивой, обеспечить себе запасной ход на случай глобальных проблем и осчастливить безопасников.
Технологии MPLS более двадцати лет. Всё это время она широко использовалась операторами связи, а также в больших корпоративных сетях. Казалось бы, стоит ли искать «лучшее вместо хорошего»? Так, да не так.
В завершающей части нашего цикла про Traffic Engineering обсудим подробнее тему Segment Routing, к которой мы подошли в прошлый раз. И для этого нам будет нужно разобраться, что же не хватало в MPLS.
Всем привет. На связи Артём Гойлик @ArtoLord и Владислав Волох @Chillintano из команды DataSphere в Yandex Cloud. Мы создаём инфраструктуру для ML-разработчиков. И сегодня расскажем про одну задачу, которая, как и многие другие, начиналась с болей наших пользователей.
10 лет назад сотни серверов Яндекса работали на Apache Kafka®, но в этом продукте нам нравилось далеко не всё. Наши задачи требовали единой шины для передачи всех видов данных: от биллинговых до журналов приложений. Сегодня объёмы достигли уже десятков тысяч именованных наборов сообщений.
При таком количестве данных в Apache Kafka® становилось сложно управлять правами доступа, организовывать распределённую работу нескольких команд и многое другое. Проблемы роста и отсутствие подходящего решения в открытом доступе привели к тому, что мы разработали своё решение YDB Topics и выложили его в опенсорс в составе платформы данных YDB. В этом посте расскажу о предпосылках создания продукта, нашей архитектуре передачи данных, возникающих задачах и возможностях, которые появились вместе с YDB Topics.
Меня зовут Алексей Афонин, я старший дизайнер продукта в Yandex Cloud. В прошлом году нам понадобилось полностью изменить внешний вид нашего сервиса для бизнес‑аналитики DataLens перед его выходом в опенсорс. Разработчики и дизайнеры интерфейсов часто сталкиваются с подобными задачами: есть уже работающий сервис, но его нужно стилизовать, например, в случае ребрендинга или при необходимости учесть специфический пользовательский опыт.
В наших продуктах мы пользуемся дизайн‑системой и библиотекой компонентов Gravity UI — это проект Yandex Cloud, который не так давно тоже вышел в опенсорс. В этой статье я поделюсь опытом, как мы решили задачу «перекрашивания DataLens» с её помощью. Но даже если вы не используете DataLens и ещё не знакомы с Gravity UI, наши наработки могут пригодиться командам разработчиков и дизайнеров, которые хотят стилизовать свои продукты быстрее и удобнее.
Yandex Query Language (YQL) — универсальный декларативный язык запросов к системам хранения и обработки данных, разработанный в Яндексе. А ещё это один из самых нагруженных сервисов: YQL ежедневно обрабатывает около 800 петабайт данных и 600 000 SQL-запросов, и эти показатели постоянно растут.
Изначально YQL основывался на операциях MapReduce, которые эффективны для больших данных. Но для средних объёмов данных (до 50 Гб, которые составляют около 60% запросов) этот подход оказался неоптимальным, потому что нужно было обмениваться данными между операциями через диск. Поэтому разработчики создали новый более гибкий стриминговый движок, который значительно ускоряет обработку данных за счёт выполнения всех вычислений в памяти.
В этой статье я хочу рассказать о подходах и технологиях в разработке систем для обработки данных на примере YQL. Основное внимание я уделил переходу от MapReduce к стриминговому движку, который обеспечивает более эффективную обработку данных, вмещающихся в память, и который доступен в опенсорсе.
Меня зовут Александр, я руковожу направлением больших данных в Битрикс24. Клиенты нашего сервиса хранят миллиарды файлов: от документов до фотографий, — а моя команда предоставляет возможность строить бизнес-аналитику на основе этого множества данных. И нам важно позаботиться об их сохранности.
Более 10 лет назад мы продумали необходимую нам схему репликации объектного хранилища в облаке. Затем файлы клиентов потребовалось перенести в другое облако, и нам очень хотелось также перенести все наши наработки в режиме «Ctrl+C, Сtrl+V».
В статье расскажу, как мы организовали резервирование данных в парадигме слабого связывания и как перенесли эту схему в Yandex Cloud без потери важных нам деталей.
Traffic Engineering помогает нам решать проблемы оценки и оптимизации производительности IP‑сетей, но при этом требует недюжинного понимания сетевых технологий и протоколов, которые используются в больших сетях. В прошлый раз мы остановились на магии работы PCE-контроллера и затронули Stateless и Stateful PCE. Как здесь не вспомнить комикс от Go Chronicles, посвящённый Stateful.
Конечно, на самом деле PCE-контроллер общается не так, а с использованием PCEP — Path Computation Element Communication Protocol, который описан в RFC 5440. Так что самое время начать с него вторую часть нашей истории про Traffic Engineering.
В Yandex Cloud с сегодняшнего дня открыт доступ к тестированию API YandexART — нейросети для генерации изображений и анимаций, которая лежит в основе приложения Шедеврум. Протестировать API можно в сервисе Foundation Models, в котором доступно несколько моделей машинного обучения, включая YandexGPT для генерации текстов и эмбеддинги для задач семантического поиска.
Задумывались ли вы о том, как изменить конфигурацию сразу на нескольких сетевых устройствах? Что, если нужно сделать это на всей сети с сотнями и тысячами единиц оборудования? А что, если приходится делать это каждый месяц на железе от пяти разных производителей? Очевидное решение для подобных задач — автоматизация. Но реализовать её можно не одним способом, а в процессе наткнуться не на одни грабли.
Меня зовут Вадим Воловик, и я руковожу проектами разработки в Yandex Infrastructure. Наша команда NOCDEV отвечает за автоматизацию сетей всего Яндекса. Давно хотелось рассказать о задачах такого масштаба, но по ходу написания материала стало понятно, что тема тянет на целый цикл. Так что мы с коллегами расскажем о самых интересных примерах автоматизации в отдельных постах.
В этой статье проведём небольшую экскурсию по нашему сетевому «хозяйству» в десятки тысяч устройств и остановимся подробнее на том, как при таком объёме мы автоматически обновляем конфигурации.
Привет, я Паша, разработчик в Yandex Infrastructure, и я катаю гусей. С 2019 года я развиваю S3-хранилище как для внутренних пользователей Яндекса, так и для клиентов Yandex Cloud. А «гусём» называется наш бэкенд S3 API: он написан на Go, а из словосочетания Go + S3 получился goose. Возможно, вы также слышали про GeeseFS — это наш высокопроизводительный FUSE-клиент для S3. C его помощью вы можете на своём ноутбуке или виртуалке подмонтировать папку, которая будет работать с бакетом S3.
Для чего нам «гуси» и прочая орнитология? Яндексовая инсталляция хранилища S3 хранит миллиарды файлов. Это огромные объёмы данных, а также метаданных. Для хранения метаданных мы научились использовать умное шардирование, и теперь сами управляем распределением занятого места и нагрузкой между шардами баз.
Так что сегодня я расскажу, как сделать так, чтобы ни один клиент, даже с самым неудобным паттерном нагрузки, не положил сервис.