카프카 커넥터의 태스크에 Priority를 부여할 수 없을까?

관련 지라 : KAFKA-5741

https://issues.apache.org/jira/browse/KAFKA-5741

[KAFKA-5741] Prioritize threads in Connect distributed worker process - ASF JIRA

Connect's distributed worker process uses the DistributedHerder to perform all administrative operations, including: starting, stopping, pausing, resuming, reconfiguring connectors; rebalancing; etc. The DistributedHerder uses a single threaded executor service to do all this work and to do it sequentially. If this thread gets preempted for any reason (e.g., connector tasks are bogging down the process, DoS, etc.), then the herder's membership in the group may be dropped, causing a rebalance. This herder thread should be run at a much higher priority than all of the other threads in the system.

프로세스 내부에 스레드로 동작하는 태스크는 상황에 따라 언제든지 리밸런스가 필요할 수 있습니다. 일부 파티션에 데이터가 몰리는 혀상들이 발생할 가능성이 있기 때문입니다. 이를 해소하고자 KAFKA-5741에서는 task에 priority를 주고자 하는 제안을 하였습니다. 제안자는 Randall Hauch로, 현재 Confluent 직원입니다.

 

이에 Ewen(Confluent 직원)은 다음과 같이 답했습니다.

It would be good to have clear indications this is actually a problem in practice and that other threads starving the herder thread caused it to rebalance. First, heartbeating actually happens in a background thread, so you'd have to starve that thread as well for the session timeout. And the actual processing done in the thread is very minimal, so you'd have to completely starve that thread for a long time – it's much more likely that things like waiting for other threads to flush data during a rebalance is what causes it to fall out of the group. I'm also skeptical of the prioritization because to me, if this really occurred for this reason, it would suggest that the hardware is just underprovisioned for the workload. Prioritizing the DistributedHerder thread would probably just end up starving other threads if there really is that much resource contention, and so the connectors won't even really be functioning correctly anyway...

결과적으로 스레드에 데이터를 처리하지 못하고 지연되는 현상은 스레드 그 자체의 원인을 찾아야 한다고 언급했습니다. 뿐만아니라 priority를 적용한다고 한들, 결국 다른 스레드들로 인해서 리소스가 부족하여 처리량이 줄어드는(starving) 현상이 발생할 것이라고 판단했습니다. 그렇기 때문에 차라리 이런 현상이 나타나면 하드웨어의 리소스가 부족(underprovisioned)하다고 판단하는 것이 낫다고 합니다. 결과적으로 이렇게 스레드(태스크)의 데이터 처리량이 부족/불균등 나타날 경우에는 리소스를 확충하는 것이 최종적인 방법이 되겠습니다.