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++.