Повышаем устойчивость приложений Apache Kafka через обработку исключений

разработка Kafka-приложений, обучение Kafka, курсы Kafka, Apache Kafka для инженеров и разработчиков, администрирование кластера Kafka, конфигурации брокера топика продсера и потребителя Kafka настройки, обучение дата-инженеров, обучение большим данным, Школа Больших Данных Учебный Центр Коммерсант

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

Исключения и транзакции в Apache Kafka

В ИТ под исключением понимается исключительная ситуация, когда программа аварийно завершается по причине ошибки алгоритма из-за невозможности обработки данных. Чтобы понимать, как исправить ошибку, надо знать, почему она возникла. В распределенных Kafka-приложениях исключения можно разделить на 2 категории:

  • исправимые – те, которые можно восстановить автоматически или вручную. Например, каталог журналов на брокере Kafka может быть отключен из-за исключения ошибки ввода-вывода IOException, вызванного отказом оборудования.
  • неисправимые – вызванные ошибкой данных, когда даже несколько повторных попыток все равно ведут к сбою. Записи не могут быть успешно обработаны, поэтому их нужно поместить в очередь недоставленных сообщений, и пропустить некорректную запись, чтобы она не блокировала обработку всего потока сообщений. Например, исключения NullPointerExceptions, IllegalStateExceptions, DataValidation.

При этом стоит вспомнить про механизм транзакций в Apache Kafka, который позволяет избежать дублирования событий в системе, гарантируя строго идемпотентную доставку сообщений (exactly once). В случае сбоя вся транзакция может быть повторена без каких-либо отрицательных побочных эффектов, т.е. без дублей и без пропусков данных. Возвращаясь к ошибкам, отметим, что для исправимых исключений транзакции Kafka следует повторить. Для неисправимых исключений повтор транзакций не имеет смысла. Далее рассмотрим несколько наиболее часто возникающих исключений в Kafka-приложениях.

Примеры исправимых и неисправимых

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

  • ProducerFenced Exception – фатальное исключение, указывающее на запуск другого продюсера с тем же транзакционным идентификатором — id. Это параметр конфигурации для транзакционной доставки. Он обеспечивает семантику надежности, которая охватывает несколько сеансов производителей, позволяя клиенту гарантировать, что транзакции с одним и тем же идентификатором завершены до начала новых. Если transactional.id не указан, то производитель ограничен идемпотентной доставкой. В любой момент времени можно иметь только один экземпляр продюсера с transactional.id, а запускаемый последний экземпляр «изолирует» предыдущие экземпляры, чтобы они больше не могли выполнять транзакционные запросы. При возникновении этого исключения необходимо закрыть экземпляр продюсера и перезапустить приложение.
  • InvalidPidMapping Exception, связанный с параметром конфигурации id. expiration.ms – максимальное время в мс, в течение которого координатор транзакций будет ждать, прежде чем упреждающе истечет срок действия идентификатора транзакции производителя без получения от него каких-либо обновлений статуса транзакции. Значение по умолчанию для этой конфигурации равно 7 дней. Это означает, что при отсутствии транзакции от продюсера в течение недели, потому вдруг от него поступит попытка зафиксировать транзакцию, возникает исключение InvalidPidMapping. При возникновении этого исключения необходимо закрыть экземпляр продюсера и перезапустить приложение.
  • CommitTimeoutException – исключение Kafka, связанное с параметром конфигурации имеет interval.ms — частота, с которой следует сохранять позицию процессора обработки, т.е. семантики доставки сообщений. В частности, для параметра конфигурации processing.guarantee задана строго однократная доставка (exactly once), то значение по умолчанию равно 100, иначе – 30000, чтобы транзакции могли выполниться в течение более длительного периода времени. В зависимости от рабочего процесса необходимо увеличить время ожидания фиксации или нужно проверить, есть ли какие-то шаги в транзакции, которые занимают больше времени и нуждаются в оптимизации. Иногда повторные попытки транзакции могут стать успешными в случае исключений по истечении времени ожидания.
  • Сетевые исключения (Network exceptions), которые характерны не только для Apache Kafka, а вообще очень часто встречаются в любых распределенных системах, где из-за задержки сети или потери соединение всего на несколько миллисекунд может возникнуть сбой транзакции. На практике чаще всего повторная попытка транзакции через какое-то время бывает успешной.
  • Пользовательские ошибки повтора (Custom retry errors), когда Kafka-приложению необходимо выполнить определенные условия перед успешной обработкой события. В этом случае событие может быть отправлено на повторную попытку топика, и его необходимо повторить позже, или продолжать попытки до тех пор, пока условия не будут выполнены.

Неисправимые исключения в Apache Kafka чаще всего связаны с проблемами в данных и их повторная обработка без изменения самих данных не приведет к успеху. Например, NullPointerException – исключение, которое возникает из-за отсутствия какого-либо поля или значения. Такое некорректное сообщение следует пропустить, зарегистрировав в специальном топике, чтобы вернуться к нему отдельно и обработать с учетом ошибки. Сюда же можно отнести другие исключения сериализации и десериализации, которые случаются когда запись не соответствует заданной схеме данных и не может быть обработана алгоритмом, например, ArithmeticException, ClassCastException, IndexOutOfBoundsException, IllegalStateException.

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

Освойте все тонкости администрирования и эксплуатации Apache Kafka для потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков больших данных в Москве:

Источники

  1. https://deeptimittalblogger.medium.com/kafka-exceptions-building-resilience-into-the-system-47ac39404aff
  2. https://kafka.apache.org/documentation/
Поиск по сайту