Policy as Code в Apache Kafka: опыт внедрения Open Policy Agent

Статья рассматривает внедрение Open Policy Agent (OPA) для управления авторизацией в кластерах Apache Kafka на bare metal‑серверах. В рамках статьи проанализированы ограничения стандартных ACL и предложено решение на основе Open Policy Agent (OPA), обеспечивающее декларативное управление доступом через Policy as Code (PaaC). Особое внимание уделено обновлению OPA Kafka Plugin: создан pull request, в котором устранены уязвимости превносимые в OPA библиотекой Guava и реализован переход на более производительную библиотеку Caffeine. Описан процесс интеграции OPA с Kafka, включая автоматизацию доставки политик через Bundle API и S3-хранилище.

https://habr.com/ru/companies/t2/articles/901488/

Настройка Apache Kafka для высоконагруженных систем

Apache Kafka является одной из самых популярных платформ для обработки потоков данных, обеспечивая высокую пропускную способность и низкие задержки при передаче сообщений. В высоконагруженных системах, где необходимо обрабатывать миллионы сообщений в секунду, важность правильной настройки Kafka трудно переоценить. Без оптимизации её параметров можно столкнуться с серьёзными проблемами, такими как рост задержек, потеря сообщений и переполнение очередей. Эффективная настройка Kafka критична для обеспечения бесперебойной работы в условиях высокой нагрузки и стабильной обработки данных в реальном времени. Цель этой статьи — рассмотреть основные аспекты настройки Apache Kafka, которые влияют на производительность системы. Мы сосредоточимся на оптимизации параметров брокеров и продюсеров для достижения максимальной пропускной способности, минимальных задержек и надежности. Также рассмотрим важность мониторинга и тестирования системы для своевременного выявления и устранения узких мест.

https://habr.com/ru/articles/901200/

ОС против Kafka: битва за map-области: история одного неочевидного лимита

Добрый день! Меня зовут Богдан, я тимлид в одном из отечественных финтехов. Сегодня я хочу поделиться нашей историей: как нам удалось, ненарочно, зашедулить падение всех нод одного из наших кластеров Kafka. В один из холодных февральских дней пришло сообщение от мониторинга с виртуальных машин кластера Kafka: «Свободное дисковое пространство достигло значения < 15%» . Было решено исследовать, нужно ли добавлять дискового пространства или же можно потюнить настройки ретеншена данных. Тут стоит немного вспомнить теорию. Как известно, в Kafka сообщения распределяются по партициям, а каждая партиция на брокере представлена набором сегментов. Число сегментов у партиций может быть разным — оно варьируется в зависимости от интенсивности записи и настроек размера сегмента. Сегмент (если упростить) — это лог-файл, в который просто пишутся данные в конец. По достижении временного предела либо его размера он ротируется: создается новый сегмент, и запись идет уже в него. Держа вышесказанное в голове, мы отправились смотреть настройки хранения сегментов в нашем кластере Kafka..

https://habr.com/ru/articles/900094/

12 событий апреля, которые нельзя пропустить

Мы собрали для вас серию открытых уроков, которые пройдут в апреле и помогут не просто разобраться в сложных темах, а применить знания на практике. Будущее AI агентов на основе LLM, Prometheus для мониторинга, как избежать хаоса в IT-проектах и как обучить модель понимать языки — на эти и не только темы поговорим с экспертами в IT. Рассмотрим реальные кейсы, обсудим опыт и получим понимание того, как внедрять эти технологии в проекты.

https://habr.com/ru/companies/otus/articles/899644/

Apache Kafka и EDA

Архитектура, управляемая событиями (Event Driven Architecture, EDA) получила широкое распространение при разработке программного обеспечения, способного легко масштабироваться и обрабатывать большие объемы данных в режиме реального времени. В этой статье мы подробно рассмотрим EDA и продемонстрируем, как распределенная потоковая платформа Apache Kafka, может быть использована для создания масштабируемых систем.

https://habr.com/ru/companies/otus/articles/895766/

работа с Kafka в Go: практическое применение

Автор статьи Якушков Федор. Apache Kafka — это мощная распределённая платформа для обработки потоков данных, которая завоевала популярность благодаря своей способности эффективно управлять большими объёмами информации в реальном времени. В этой статье мы подробно разберём, как использовать Kafka в языке программирования Go с помощью библиотеки kafka-go. Мы рассмотрим все ключевые аспекты: от event-driven архитектуры до топиков и партиций, от создания продюсеров и консьюмеров до управления оффсетами и обработки ошибок. Разберем гарантии доставки, а также обсудим, где и как применять Kafka в проектах.

https://habr.com/ru/articles/894056/

Offset Explorer: разбираемся в базе

Всем привет! Меня зовут Макс. Я Lead Backend в компании ИдаПроджект и автор YouTube-канала PyLounge . Любой крупный проект так или иначе используют брокеры сообщений — и чаще всего это Apache Kafka. Так что уметь взаимодействовать с Kafka (хотя бы на базовом уровне) будет полезно как разработчику, так и тестировщику или аналитику. Я в своей работе практически ежедневно взаимодействую с кафкой, поэтому решил поделиться опытом. В команде мы используем графический интерфейс Offset Explorer (далее OE), о котором сегодня и пойдет речь. Погнали!

https://habr.com/ru/companies/idaproject/articles/889600/

Kafka Streams ч5: настройка окон, работа с задержанными событиями и suppression

Это моя финальная часть(ну пока что ;)) серии статей про Kafka Streams, прошлые статьи тут [ ноль , один , два , три ] Теперь давайте разработаем приложение, которое считывает: cобытия о пульсе из топика pulse-events .

https://habr.com/ru/articles/870784/

Про auto.offset.reset в Spring Kafka

Так исторически сложилось, что Apache Kafka использует для своих сообщений смещения (или же offset). В зависимости от нужд для настроек консьюмера можно выставить в параметр auto.offset.reset три значения: earliest, latest, none. По умолчанию, если данный параметр не задан, используется значение latest.

https://habr.com/ru/articles/851902/

Шины данных для очень больших инсталляций, или Почему большим компаниям сложно с опенсорсом

Как технический менеджер в Яндексе я отвечаю за эксплуатацию больших кластеров, через которые мы передаём данные, — для этого мы используем YDB Topics, собственный аналог Apache Kafka, о котором я уже рассказывал . Но если посмотреть не только на нас, но и на примеры других крупных систем, то становится понятно, почему энтерпрайзу сложно брать готовые опенсорс‑решения. Стоит лишь представить, что бывает, если команда с большими масштабами начинает использовать Apache Kafka. В этой статье я покажу собирательный образ такой крупной системы из нашего опыта общения с большими распределёнными командами, и мы увидим разницу в TCO Apache Kafka и YDB Topics на конкретных цифрах.

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/850758/

Скажем нет «Превращению», или анализ Kafka

Бывало ли вам интересно, какие баги может таить исходный код проектов, которыми пользуются большие компании по всему миру? Не упустите шанс познакомиться с интересными ошибками, которые нашёл статический анализатор PVS-Studio в исходном коде Open Source проекта Apache Kafka.

https://habr.com/ru/companies/pvs-studio/articles/851066/

Мой опыт использования Plumber: UI-инструмент для тестирования Kafka

Привет, Хабр! Меня зовут Марина, я QA-инженер в Купере. Как специалисту по тестированию, мне часто приходится сталкиваться с задачами, связанными с тестированием микросервисов, использующих асинхронное общение через Apache Kafka. Уверена, многие QA-инженеры, да и разработчики знакомы с подобными вызовами. На одном из проектов, где я работаю, у меня возникла проблема: используемые инструменты для тестирования Kafka были недостаточно удобными: Консольная утилита Protokaf не имеет интерфейса и полученные данные для лучшей читаемости нужно отформатировать в json структуру (а это еще одно доп приложение). UI-приложение Kowl удобно только для мониторинга состояния топиков, и только недавно в нём стала доступна возможность чтения сообщений без сложного флоу для расшифровки, но всё так же нет возможность отправки сообщений в топик. В поисках более удобного решения коллега посоветовал Plumber — графическое приложение, с возможностью коньюмера и продюсера сообщения. В этой статье я не буду объяснять, что такое Kafka и как работают брокеры — на эти темы уже есть множество отличных материалов, например, вот . Хочу поделиться своим опытом использования этого инструмента. Я не ставлю цель сравнивать его с другими существующими решениями, а просто расскажу, как Plumber помог мне упростить процесс ручного тестирования Kafka на стейджах.

https://habr.com/ru/companies/kuper/articles/845970/

Apache Kafka – Producer и Consumer. Простой пример Nodejs приложения

Привет! В продолжение темы изучения микросервисов решил разобраться с взаимодействием этих самых «сервисов», и написать простой пример взаимодействия двух сервисов между собой. Перед чтением данной статьи, настоятельно рекомендую ознакомиться с данной статьей, по теме kafka (Kafka за 20 минут. Ментальная модель и как с ней работать) Пример реализации можно найти тут...

https://habr.com/ru/articles/845118/

[Перевод] Интеграция REST и MQ брокеров сообщений через шлюз OpenIG

В статье рассмотрены варианты конвертации сообщений из REST в брокер сообщений и обратно, а так же возможные варианты использования такого подхода.

https://habr.com/ru/articles/828832/

[Перевод] Оптимизация настроек Kafka кластера. Часть 3. Сравнительное тестирование, мониторинг и тонкая настройка Kafka кластера

Привет, Хабр! Представляю вам третью (заключительную) часть серии статей, посвященных оптимизации развертывания Kafka кластера (ссылка на первую и вторую части). Это перевод руководства от Confluent. Сегодняшняя статья посвящена сравнительному тестированию настроек и мониторингу Kafka кластера.

https://habr.com/ru/articles/819677/

[Перевод] Оптимизация настроек Kafka кластера. Часть 2. Механизмы управления задержкой, надежностью и доступностью

Привет, Хабр! Представляю вам вторую часть из серии статей, посвященных оптимизации развертывания Kafka кластера ( ссылка на первую часть ). Это перевод руководства от Confluent. Сегодняшняя статья посвящена тому, как уменьшить задержку и повысить надежность и доступность. Заключительная третья часть будет посвящена мониторингу и бенчмаркингу.

https://habr.com/ru/articles/819243/

[Перевод] Оптимизация настроек Kafka кластера. Часть 1. Механизмы управления пропускной способностью

Привет, Хабр! Представляю вам перевод технического документа от Confluent, который посвящен тому, как определить, что именно нужно оптимизировать (пропускная способность, задержка, надежность или доступность), как настроить развертывание Kafka в соответствии с этими целями и убедиться в их достижении с помощью мониторинга. Сегодня я выкладываю первую часть, в которой обсуждается, как определить цели оптимизации и улучшить пропускную способность Kafka. Последующие статьи будут посвящены задержке, надежности, доступности, мониторингу и бенчмаркингу.

https://habr.com/ru/articles/818007/

Типы совместимости в Schema Registry для Apache Kafka

В прошлой статье я писал о том, что такое Schema Registry и как используется в Apache Kafka . Сегодня я хочу углубиться в тему и описать поведение системы при различных типах совместимости . Правильное понимание и применение этих типов совместимости поможет обеспечить стабильность и гибкость системы при изменениях структуры данных. Детали типов совместимости

https://habr.com/ru/articles/817121/

Как Яндекс создал свою шину данных, чтобы передавать сотни гигабайт в секунду

10 лет назад сотни серверов Яндекса работали на Apache Kafka®, но в этом продукте нам нравилось далеко не всё. Наши задачи требовали единой шины для передачи всех видов данных: от биллинговых до журналов приложений. Сегодня объёмы достигли уже десятков тысяч именованных наборов сообщений. При таком количестве данных в Apache Kafka® становилось сложно управлять правами доступа, организовывать распределённую работу нескольких команд и многое другое. Проблемы роста и отсутствие подходящего решения в открытом доступе привели к тому, что мы разработали своё решение YDB Topics и выложили его в опенсорс в составе платформы данных YDB . В этом посте расскажу о предпосылках создания продукта, нашей архитектуре передачи данных, возникающих задачах и возможностях, которые появились вместе с YDB Topics.

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/810907/

Управление схемами в Kafka с использованием Schema Registry

Apache Kafka является мощным инструментом для обработки и передачи потоковых данных в реальном времени, который находит широкое применение в различных индустриях для обработки огромных объемов данных с низкой задержкой. В центре этой платформы лежит способность эффективно распределять данные между множеством производителей (producers) и потребителей (consumers), при этом поддерживая высокую пропускную способность и масштабируемость. Однако, с увеличением количества и разнообразия данных, возникает необходимость в управлении структурами этих данных, что обеспечивает Schema Registry. Этот компонент является критически важным для поддержания согласованности данных в Kafka, поскольку он управляет схемами сообщений и обеспечивает совместимость между различными версиями схем, что позволяет системам бесперебойно обмениваться данными даже при изменении структуры сообщений.

https://habr.com/ru/articles/811283/