Хабрахабр

Kafka в Wargaming: блицопрос

Почему Kafka? Каковы общие впечатления? Каков состав кластеров? Под катом — дюжина коротких вопросов для Левона Авакяна, отвечающего в Wargaming за надежность, архитектуру приложений, инфраструктуру и продакшн.

Что использовали до этого?
— Как выбрали именно Kafka? Какие альтернативы рассматривали?

Apache Kafka уже использовалась в компании для нужд нашего Data Warehouse, и изначально была задача интеграции, а уж потом мы увидели, что можно использовать Kafka для разных задач. Не очень корректный вопрос по отношению к танковой разработке.

— Сколько событий генерируется вашим игровым кластером?

Все кластеры генерируют в среднем 12 тысяч сообщений, в пиках около 30 тысяч сообщений в секунду. Танковый кластер — это кластер кластеров, система распределенная и генерирует события в разные Kafka.

— А сколько всего у вас кластеров и каков их состав?

Более мелкие кластеры, которые обслуживают только танковые периферии, — это примерно по три узла плюс виртуалки. Самый крупный центральный кластер состоит из пяти железных узлов. Локальных кластеров для региона СНГ у нас четыре.

Каковы рейты на чтение/запись? — Сколько у вас продюсеров и консьюмеров?

Для локальных периферийных Кafka продюссер один – танковый кластер, а консьюмеров десятки. Хороший вопрос. По рейтам: на центральном кластере пишется до 75 тысяч сообщений в секунду, в среднем 12 тысяч, на локальных до семи тысяч и в среднем три тысячи.

Есть ли ограничения по времени доставки? — Насколько большие события вы пишете в Кafka?

Ограничения по времени доставки для некоторых консьюмеров есть, для некоторых нет. Ограничение 1 МБ — больше никто не просил. Некоторые читают раз в неделю.

— Сталкивались ли с какими-либо интересными особенностями и багами при шардировании или репликации?

Были разрешены грязные перевыборы и был выбран некорректный ISR. Сталкивались с потерями данных при перевыборах из-за настроек топиков.

— А случалось ли упираться в диск или сеть?

В диск тоже не упирались. В сеть не упирались, у нас сетевые интерфейсы 10 Гбит. Стабильность пришла после обновления с  java-1. Упирались в закончившиеся файловые дескрипторы. 0-openjdk-1. 7. 0. 7. 4. 55-2. 1.el6_5.x86_64 на jdk1. 7. 0_66-1. 8. 0_66-fcs.x86_64. 8.

Требуется ли особая настройка gc? — Какие накладные расходы приносит JVM в случае с Kafka? Сколько памяти расходует один инстанс в вашем случае?

12 ГБ памяти выделено, всё остальное стандартное.

Log Compaction?
Использовали Log Compaction для некоторых топиков, но не для проекта World of Tanks. — Приходилось ли использовать какие-то особые фичи Кafka? Еще увеличивали offsets.retention.minutes до семи дней, чтобы консьюемеры, которые вычитывают один раз неделю, продолжали читать с того места, где остановились. Включили на конкретные топики, но результат не ясен, никто не дал фидбэка.

Что понравилось? — Какие библиотеки Python использовали для работы с Kafka?

В нашем активе Kafka-python, confluent-kafka-python, aiokafka. Как раз один из моих докладов на Moscow Python Conf++ будет об опыте использования различных Python-библиотек для Kafka в WoT. У каждой из этих библиотек есть свои плюсы и минусы.

Для каких типов задач мог бы порекомендовать одно или другое? — Что бы ты рассказал про преимущества и недостатки file-based хранилищ в сравнении с in-memory?

На файловой системе надежней, но медленнее. Тут принцип простой. Плюс важное ограничение по объему: в файловой системе можно хранить терабайты, а в памяти мы пока оперируем гигабайтами. В памяти быстрее, но и надежность ниже. Отсюда можно много фантазировать, отталкиваясь от конкретной реализации.

Исходя из вышеописанного: если надо быстро, объем небольшой и не важна сохранность, то in-memory, иначе смотрим на file-based.

Если бы ты делал эту же задачу сейчас, оставил бы Kafka или посмотрел бы в сторону других решений? — Общие впечатления от Kafka?

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

Надеюсь, многим он покажется интересным и полезным. Опять же, если интересны детали нашего опыта работы с Kafka, приходите на мой доклад на Moscow Python Conf++.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть