이번글은 Kafka Connect를 distributed mode로 사용할 때 필자가 실수했던 내용을 공유하는 목적이다.
Kafka Connect는 Standalone, Distributed 2가지의 mode가 있다.
테스트나 로컬에서 데이터를 이동할 때는 Standalone을 사용하지만 대부분의 운영 상황에서는 Distributed mode를 사용하게 된다.
필자의 실수에 대한 내용을 간략히 기술하면 다음과 같다.
-
Custom한 Connector를 개발한 이후, Connect에 plugin을 배포하고 실행했다.
-
REST API로 하나의 Job을 실행했다. 정상적으로 동작했다.
-
여러개의 Job의 동작 유무를 확인하기 위해 추가로 Job을 실행했다.
-
에러가 발생
에러의 내용은 다음과 같다.
org.apache.kafka.connect.runtime.rest.errors.ConnectRestException: Cannot complete request because of a conflicting operation (e.g worker rebalance)
새로운 Job 실행 요청에 대해 충돌이 발생해서 완료되지 않았고 충돌의 예로 리밸런스가 있단다.
그래서 필자가 만든 Connector이 각 파티션의 설정을 사용하는 로직이 있는데 거기서 버그가 있나 의심했다.
그런데 다시 생각해보니 리밸런스는 여러 Connect들에서 워커를 조정하면서 발생할 텐데 새로 만든 Connector가 파티션을 할당 받기 전에 발생한 문제 같았다.
Connect의 설정의 문제가 있나 의심하기 시작했고, 구글링으로 multi Job을 돌렸을 때 발생하는 케이스가 있는지 찾아봤다.
평소에 가끔 들어가보던 블로그에서 Connect 관련 내용이 있었다. 해당 블로그는 Confluent에 소속된 개발자이다.
블로그에서 주요하게 설명하는 설정은 rest.advertised.host.name 이었다.
Distributed mode로 동작하면 여러 Connect들이 서로 통신하며 Job을 분배한다.
그때 다른 Connect가 접근을 할 수 있도록 hostname이 설정되어 있어야 한다.
필자가 경험한 문제는 Job 실행 이후 다른 Connect가 실행한 Job에 대해 정보를 가져가지 못하면서 발생한 것으로 추측됐다.
그래서 rest.advertised.host.name, rest.advertised.host.port 2개 정보를 각 Connect에 모두 추가했다.
그 이후에 multi Job을 실행했을 때 정상적으로 동작했다.
필자는 기존에 Connect의 plugin 만드는 부분에 대해서만 검토를 했었는데, Distributed mode에서 Connect들이 서로 어떤 통신을 무엇을 위해 하는지 더 찾아봐야 겠다고 생각했다.
추후 해당 내용에 대해서 공부를 더 하면 정리하는 글을 써보도록 하겠다.
참고 문서
'Big Data > Kafka' 카테고리의 다른 글
[Kafka] Connector-level producer/consumer configuration overrides (0) | 2020.07.21 |
---|---|
[Kafka] 카프카 클러스터에 적당한 토픽/ 파티션 개수는? (0) | 2020.07.20 |
[Kafka] Producer config 정리 (0) | 2020.06.16 |
[Kafka] 관리자 Tip - 사용하지 않은 topic 목록 찾기 (0) | 2020.04.28 |
[Kafka] Kerberos 인증 #2 (2) | 2020.02.05 |