KStream, KTable 코파티셔닝 질문이 있습니다.

안녕하세요

말씀대로 데이터 발생양이 증가하여 파티션 개수를 늘려야하는 상황이라면 코파티셔닝이 깨져서 스트림즈 애플리케이션에 오류가 발생할 수 있습니다. 이 경우에는 다음과 같은 방법으로 해결할 수 있겠습니다.

방법1) 파티션 개수를 늘려야하는 상황이 오지 않도록 파티션 개수 지정

KStream, KTable 조인을 사용하는 것은 두 토픽간 강결합을 일으킵니다. 그렇기 때문에 말씀하신대로 파티션 개수를 늘리는 것은 오류를 발생시킬 수 있기 때문에 이러한 상황에 왔다는 자체가 개발 리소스 추가로 이어질 수 있습니다. 그렇기 때문에 태초부터 KStream, KTable 조인을 할 때는 파티션 개수를 매우 넉넉하게(평소 데이터 처리량의 x10 이상)으로 잡고 운영하는 것이 좋겠습니다.

방법3) 2개의 토픽으로 전송하는 프로듀서에 Custom Partitioner 로직 적용

KStream, KTable 조인 스트림즈 애플리케이션은 특정 파티션으로 들어온 데이터의 메시지 키가 동일하다면 무조건 조인을 시킵니다. 그렇기 때문에 파티션 개수가 달라지는 시점에 조인이 되어야 하는 메시지 키가 동일한 파티션 번호에 있어야지만 정상적인 데이터가 추출될 수 있는 것이죠. 그렇기 때문에 해당 토픽으로 레코드를 전송하는 프로듀서에서 CustomPartitioner를 적용하여 기존 사용하던 메시지 키의 경우 파티션 개수를 늘리기 전과 동일한 파티션 번호로 데이터를 전송하도록 로직을 개발하는 것도 방법입니다. 이 방법을 사용하면 파티션 개수가 달라지더라도 이전에 전송하는 메시지 키는 동일한 번호의 파티션으로 보내는 것을 보장할 수 있기 때문에 스트림즈 애플리케이션은 안정적으로 데이터를 처리할 수 있습니다.

방법2) 2개의 토픽의 파티션 개수를 적절한 시점에 수정

만약 비즈니스 로직 적으로 데이터가 일부 유실/중복 되거나 조인되지 않더라도 큰 이슈가 없을 경우 이 방법을 사용할 수 있습니다. 일시적으로 TopologyException이 발생할 수 있고, 조인이 되지 않을 수 도 있습니다. 하지만 파티션 개수가 두 토픽 모두 변경된 이후에는 다시 조인되어 처리될 수 있습니다.

안녕하세요, 인프런 AI 인턴입니다.

KStream과 KTable을 사용할 때, 파티션 개수를 늘리는 상황에 대한 질문을 주셨군요.

파티션 개수를 변경하려면, 가급적 두 토픽 모두 동일하게 파티션 개수를 조정해야 합니다. Kafka Streams에서는 KStream과 KTable 또는 두 KStream 간에 Join을 사용할 때, 해당 토픽들의 파티션이 코파티셔닝되어야 한다는 요구사항이 있습니다. 코파티셔닝이란 단순히 파티션 개수가 같다는 것 뿐만 아니라 해당 파티션들이 같은 키를 기반으로 메시지를 받는다는 것을 의미합니다.

리파티셔닝은 기존의 토픽 구조를 재조정함으로써 데이터를 다시 파티셔닝 하는 과정입니다. 이 작업을 수행할 때는 아래와 같은 고려사항이 있습니다.

1. 리파티셔닝을 실행하기 전에는 운영 중인 스트림즈 애플리케이션을 멈추어야 합니다. 이 과정에서 다운타임이 발생할 수 있고, 이를 최소화하기 위한 전략이 필요합니다.
   
2. 파티션 개수 변경 후, 파티셔닝 전략에 따라 메시지 키가 이전과 다른 파티션으로 할당될 가능성이 있으므로, 이 부분에 대해 염두해야 합니다.
   
3. 토픽의 파티션을 확장하는 과정은 Kafka 토픽의 설정을 변경하는 것을 포함하며, 이는 Kafka 클러스터에 직접적으로 소프트웨어적 작업을 수반합니다.
   

리파티셔닝 작업을 하면서 스트림즈의 다운타임이 발생하게 되므로, 이를 스케줄링하고 최소화할 수 있는 방법들을 검토해야 합니다. 예를 들어, 대안적인 스트림즈 인스턴스를 이용하거나, 재처리가 가능한 방식으로 데이터를 보존하는 등의 조치가 필요할 수 있습니다.

이와 관련된 자세한 내용이나 추가적인 문의사항이 있다면 Spring for Apache Kafka에 나와 있는 문서를 참고하시기 바랍니다.