Современные S3-хранилища давно перестали быть «черным ящиком»: от их архитектуры напрямую зависят отказоустойчивость, производительность и экономика сервисов, которые на них опираются. Но за внешне простым API скрывается интересная, сложная, промышленная система — от железа в стойках до многослойного распределенного  приложения.

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

Меня зовут Александр Гришин, я руковожу направлением хранения и обработки данных в Selectel. Отвечаю за развитие облачных баз данных, S3-хранилища, аппаратных СХД и сервисов для построения DLH. Материал будет полезен CTO, CIO и архитекторам, которые выбирают или проектируют собственное S3-совместимое хранилище. Или инженерам которые хотят просто лучше понимать, что же происходит у нашего сервиса под капотом.

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

Это явление давно известно в архитектуре вычислительных систем как разрыв между процессором и памятью (или Memory Wall). Сегодня он определяет производительность серверов, баз данных, платформ данных и AI/ML-платформ сильнее, чем выбор конкретной модели процессора или видеокарты. А в будущем определит то, какие продукты и решения индустрия будет использовать для решения задачи хранения данных.

Привет! Я Александр Гришин, руководитель по развитию продуктов хранения данных в Selectel. В этой статье я попробую подробно разобрать, что такое этот ваш разрыв между процессором и памятью, как он сформировался, как устроена иерархия памяти в сервере и почему эти ограничения подталкивают индустрию к новым архитектурам и решениям. Погнали!

Привет, Хабр! Меня зовут Александр Гришин, я руководитель по развитию продуктов хранения данных в Selectel. Сегодня я предлагаю продолжить разбираться с PostgreSQL и заглянуть еще глубже в эту кроличью нору. Посмотрим, что происходит под капотом СУБД во время записи строк, поверхностно разберем, как устроены страницы памяти, что такое tuple, tuple chain, fillfactor, VM и FSM. Эти знания помогут разработчикам не только понимать, как работает база данных, но и эффективно управлять ее производительностью в продакшене.

Если вы начинающий DBA, разработчик, инженер или архитектор облачной инфраструктуры, эта статья для вас. Погнали?

Недавно объявили лауреатов Нобелевской премии по экономике. Комитет по экономике наградил исследователей, которые объяснили, почему устойчивый рост невозможен без технологических инноваций и «креативного/творческого разрушения». Казалось бы, это чисто академическая история. Но на деле — очень точное описание того, что происходит с любым продуктом: от облачной платформы до SaaS-сервиса. И если копнуть глубже, в этих исследованиях можно найти ответы на вопросы, с которыми сталкивается любая IT-компания.

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

За более чем 10 лет работы в облачной индустрии я видел немало историй, когда команды вкладывали месяцы и даже годы в разработку продукта, но в итоге все упиралось не в технологии, а в цену. Продукт может быть удобным, быстрым, технологически безупречным. Но если компания не понимает, сколько и за что готов платить клиент, то даже самая инновационная идея рискует превратиться в игрушку для амбиций команды или продакта, так и не найдя своего места на рынке.

Привет, Хабр! С вами Александр Гришин, руководитель по развитию продуктов хранения данных Selectel: облачных баз данных и S3. Сегодня мы разберем пять ключевых принципов из книги Мадхавана Рамануджама и Георга Таке «Monetizing Innovation», но не ограничимся теорией. Каждый принцип я постараюсь показать на конкретных примерах из AWS, Google Cloud, MongoDB, Elastic/OpenSearch. Где это возможно, добавлю наблюдения из практики и цифры.

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

Kafka — распределенная стриминговая платформа, которая стала де-факто стандартом для обработки событий в реальном времени. Она обеспечивает надежную доставку сообщений, масштабируемость и низкую задержку. Однако чтобы кластер Kafka работал стабильно под высокой нагрузкой, мало просто «поднять брокеры» — критично правильно настроить параметры конфигурации. От них напрямую зависят пропускная способность, время отклика, устойчивость к сбоям и эффективность использования ресурсов.

На связи снова Александр Гришин, руководитель по развитию продуктов хранения данных Selectel. В этой статье я разберу доступные параметры конфигурации Kafka-кластеров в облачных базах данных: от настроек репликации и ретеншена до лимитов на продюсеров и потребителей. Мы посмотрим, как каждый параметр влияет на производительность и надежность, приведем практические рекомендации для разных сценариев — от высокочастотных событий до больших архивных потоков.

Материал будет полезен инженерам, которые проектируют архитектуру обмена данными, DevOps-специалистам, отвечающим за эксплуатацию, и разработчикам, которым важно предсказуемое поведение стриминга на продакшене. Погнали!

Катастрофоустойчивое хранение данных — одна из актуальных задач при построении IT-инфраструктуры. Но ее решение может завести в тупик. Как оптимальнее организовать хранение данных, исключив домены отказа? Как разместить определенные данные ближе к целевой нагрузке или части аудитории? Как организовать асинхронную репликацию данных между Москвой и Санкт-Петербургом?

Всем привет! Меня зовут Гришин Александр, я продакт-менеджер в Selectel и отвечаю за развитие объектного хранилища и облачных баз данных. Под катом я расскажу, как с помощью мультирегиональности взаимодействовать с разными регионами S3 через Python и библиотеку boto3. Это поможет хранить и обрабатывать данные в Москве и Санкт-Петербурге, используя единую авторизацию и простой интерфейс. К тому же — улучшить катастрофоустойчивость и доступность данных, а еще снизить задержки при работе с объектами, когда инфраструктура распределена между городами.

При развитии продуктов часто используют принципы на базе исследования потребностей, определения размеров рынка и гипотез достижения тех или иных стратегических целей. Меня зовут Гришин Александр, я менеджер продуктов и отвечаю за разработку и развитие VMmanager в ISPsystem. Сегодня я расскажу о том, как управлять развитием уже существующего продукта в контексте управления на основе инструмента математического моделирования и визуализации — «дерева метрик».

Представим, что перед нами стоит цель зарабатывать 1 млн долларов в месяц. Хорошая цель. И вот мы собрались с нашей командой — разработка, тестирование, дизайн, аналитик, маркетинг, продажи, техподдержка… Что будем делать, капитан? Куда плывем? Как достигнем цели?

Молодой, но опытный моряк сразу скажет: «Все просто! Нам нужен непрерывный цикл исследований, который мы будем проходить по кругу, раз за разом: гипотеза, действие, измерение, анализ».

Но с какой конкретно гипотезы начать? Что делать, если гипотез очень много? На чем нужно сконцентрировать усилия в первую очередь: маркетинг? Качество? Удовлетворенность? Может, новые фичи, о которых мечтает тимлид? И если так, то какая фича действительно важна, а какую положить в бэклог?

Давайте попробуем использовать дерево метрик для решения этой задачи.