Почему Kafka? Каковы общие впечатления? Каков состав кластеров? Под катом — дюжина коротких вопросов для Левона Авакяна, отвечающего в Wargaming за надежность, архитектуру приложений, инфраструктуру и продакшн.
— Как выбрали именно Kafka? Что использовали до этого? Какие альтернативы рассматривали?
Не очень корректный вопрос по отношению к танковой разработке. Apache Kafka уже использовалась в компании для нужд нашего Data Warehouse, и изначально была задача интеграции, а уж потом мы увидели, что можно использовать Kafka для разных задач.
— Сколько событий генерируется вашим игровым кластером?
Танковый кластер — это кластер кластеров, система распределенная и генерирует события в разные Kafka. Все кластеры генерируют в среднем 12 тысяч сообщений, в пиках около 30 тысяч сообщений в секунду.
— А сколько всего у вас кластеров и каков их состав?
Самый крупный центральный кластер состоит из пяти железных узлов. Более мелкие кластеры, которые обслуживают только танковые периферии, — это примерно по три узла плюс виртуалки. Локальных кластеров для региона СНГ у нас четыре.
— Сколько у вас продюсеров и консьюмеров? Каковы рейты на чтение/запись?
Хороший вопрос. Для локальных периферийных Кafka продюссер один – танковый кластер, а консьюмеров десятки. По рейтам: на центральном кластере пишется до 75 тысяч сообщений в секунду, в среднем 12 тысяч, на локальных до семи тысяч и в среднем три тысячи.
— Насколько большие события вы пишете в Кafka? Есть ли ограничения по времени доставки?
Ограничение 1 МБ — больше никто не просил. Ограничения по времени доставки для некоторых консьюмеров есть, для некоторых нет. Некоторые читают раз в неделю.
— Сталкивались ли с какими-либо интересными особенностями и багами при шардировании или репликации?
Сталкивались с потерями данных при перевыборах из-за настроек топиков. Были разрешены грязные перевыборы и был выбран некорректный ISR.
— А случалось ли упираться в диск или сеть?
В сеть не упирались, у нас сетевые интерфейсы 10 Гбит. В диск тоже не упирались. Упирались в закончившиеся файловые дескрипторы. Стабильность пришла после обновления с java-1.7.0-openjdk-1.7.0.55-2.4.7.1.el6_5.x86_64 на jdk1.8.0_66-1.8.0_66-fcs.x86_64.
— Какие накладные расходы приносит JVM в случае с Kafka? Требуется ли особая настройка gc? Сколько памяти расходует один инстанс в вашем случае?
12 ГБ памяти выделено, всё остальное стандартное.
— Приходилось ли использовать какие-то особые фичи Кafka? Log Compaction?
Использовали Log Compaction для некоторых топиков, но не для проекта World of Tanks. Включили на конкретные топики, но результат не ясен, никто не дал фидбэка. Еще увеличивали offsets.retention.minutes до семи дней, чтобы консьюемеры, которые вычитывают один раз неделю, продолжали читать с того места, где остановились.
— Какие библиотеки Python использовали для работы с Kafka? Что понравилось?
Как раз один из моих докладов на Moscow Python Conf++ будет об опыте использования различных Python-библиотек для Kafka в WoT. В нашем активе Kafka-python, confluent-kafka-python, aiokafka. У каждой из этих библиотек есть свои плюсы и минусы.
— Что бы ты рассказал про преимущества и недостатки file-based хранилищ в сравнении с in-memory? Для каких типов задач мог бы порекомендовать одно или другое?
Тут принцип простой. На файловой системе надежней, но медленнее. В памяти быстрее, но и надежность ниже. Плюс важное ограничение по объему: в файловой системе можно хранить терабайты, а в памяти мы пока оперируем гигабайтами. Отсюда можно много фантазировать, отталкиваясь от конкретной реализации.
Исходя из вышеописанного: если надо быстро, объем небольшой и не важна сохранность, то in-memory, иначе смотрим на file-based.
— Общие впечатления от Kafka? Если бы ты делал эту же задачу сейчас, оставил бы Kafka или посмотрел бы в сторону других решений?
Kafka — хороший и простой инструмент для обеспечения доступа снаружи к большим объемам данных, которые можно потом неспешно обрабатывать для разных целей, разными командами в разных местах. В WoT у нас много различных инструментов для решения наших задач, поэтому там, где уместно выбрать Kafka, мы выбираем Kafka, где нет — смотрим на другие инструменты.
Опять же, если интересны детали нашего опыта работы с Kafka, приходите на мой доклад на Moscow Python Conf++. Надеюсь, многим он покажется интересным и полезным.
— Как выбрали именно Kafka? Что использовали до этого? Какие альтернативы рассматривали?
Не очень корректный вопрос по отношению к танковой разработке. Apache Kafka уже использовалась в компании для нужд нашего Data Warehouse, и изначально была задача интеграции, а уж потом мы увидели, что можно использовать Kafka для разных задач.
— Сколько событий генерируется вашим игровым кластером?
Танковый кластер — это кластер кластеров, система распределенная и генерирует события в разные Kafka. Все кластеры генерируют в среднем 12 тысяч сообщений, в пиках около 30 тысяч сообщений в секунду.
— А сколько всего у вас кластеров и каков их состав?
Самый крупный центральный кластер состоит из пяти железных узлов. Более мелкие кластеры, которые обслуживают только танковые периферии, — это примерно по три узла плюс виртуалки. Локальных кластеров для региона СНГ у нас четыре.
— Сколько у вас продюсеров и консьюмеров? Каковы рейты на чтение/запись?
Хороший вопрос. Для локальных периферийных Кafka продюссер один – танковый кластер, а консьюмеров десятки. По рейтам: на центральном кластере пишется до 75 тысяч сообщений в секунду, в среднем 12 тысяч, на локальных до семи тысяч и в среднем три тысячи.
— Насколько большие события вы пишете в Кafka? Есть ли ограничения по времени доставки?
Ограничение 1 МБ — больше никто не просил. Ограничения по времени доставки для некоторых консьюмеров есть, для некоторых нет. Некоторые читают раз в неделю.
— Сталкивались ли с какими-либо интересными особенностями и багами при шардировании или репликации?
Сталкивались с потерями данных при перевыборах из-за настроек топиков. Были разрешены грязные перевыборы и был выбран некорректный ISR.
— А случалось ли упираться в диск или сеть?
В сеть не упирались, у нас сетевые интерфейсы 10 Гбит. В диск тоже не упирались. Упирались в закончившиеся файловые дескрипторы. Стабильность пришла после обновления с java-1.7.0-openjdk-1.7.0.55-2.4.7.1.el6_5.x86_64 на jdk1.8.0_66-1.8.0_66-fcs.x86_64.
— Какие накладные расходы приносит JVM в случае с Kafka? Требуется ли особая настройка gc? Сколько памяти расходует один инстанс в вашем случае?
12 ГБ памяти выделено, всё остальное стандартное.
— Приходилось ли использовать какие-то особые фичи Кafka? Log Compaction?
Использовали Log Compaction для некоторых топиков, но не для проекта World of Tanks. Включили на конкретные топики, но результат не ясен, никто не дал фидбэка. Еще увеличивали offsets.retention.minutes до семи дней, чтобы консьюемеры, которые вычитывают один раз неделю, продолжали читать с того места, где остановились.
— Какие библиотеки Python использовали для работы с Kafka? Что понравилось?
Как раз один из моих докладов на Moscow Python Conf++ будет об опыте использования различных Python-библиотек для Kafka в WoT. В нашем активе Kafka-python, confluent-kafka-python, aiokafka. У каждой из этих библиотек есть свои плюсы и минусы.
— Что бы ты рассказал про преимущества и недостатки file-based хранилищ в сравнении с in-memory? Для каких типов задач мог бы порекомендовать одно или другое?
Тут принцип простой. На файловой системе надежней, но медленнее. В памяти быстрее, но и надежность ниже. Плюс важное ограничение по объему: в файловой системе можно хранить терабайты, а в памяти мы пока оперируем гигабайтами. Отсюда можно много фантазировать, отталкиваясь от конкретной реализации.
Исходя из вышеописанного: если надо быстро, объем небольшой и не важна сохранность, то in-memory, иначе смотрим на file-based.
— Общие впечатления от Kafka? Если бы ты делал эту же задачу сейчас, оставил бы Kafka или посмотрел бы в сторону других решений?
Kafka — хороший и простой инструмент для обеспечения доступа снаружи к большим объемам данных, которые можно потом неспешно обрабатывать для разных целей, разными командами в разных местах. В WoT у нас много различных инструментов для решения наших задач, поэтому там, где уместно выбрать Kafka, мы выбираем Kafka, где нет — смотрим на другие инструменты.
Опять же, если интересны детали нашего опыта работы с Kafka, приходите на мой доклад на Moscow Python Conf++. Надеюсь, многим он покажется интересным и полезным.