[Kafka] mirrorMaker v1 단점. v2는?

이 글은 Cloudera Blog의 다음글에서 대부분 가져왔으며 이해한 만큼 한글로 정리한 문서입니다.

개요

필자는 Kafka들의 성격에 맞게 cluster를 분리하여 사용할 경우가 있었다.

cluster를 분리하지만 일부 topic에 대해서는 분리된 cluster에 복제해서 데이터를 같이 사용해야 하는 요구사항이 있었다.

이럴 경우, MirrorMaker를 사용한다.

MirrorMaker의 이름에서 유추할 수 있듯이 Mirroring 데이터를 복사해주는 역할이다.

그런데 MirrorMaker에 단점이 많이 존재해서 복제 용도로 쓰기에 부족한 부분들이 많았다.

그 단점을 개선하려는 시도가 있고 MirrorMaker v2 (이하 MMv2)로 개발이 진행 중이다.

MMv2는 아직 release 되지 않았지만 MMv1에 어떤 단점이 있었고 어떻게 개선될지를 살펴보는건 중요하다.

필자의 경우 MMv1의 단점들로 인해 어려움을 겪고 Uber에서 개발한 uReplicator를 적용해서 사용한 적이 있다.

uReplicator, MMv2의 차이점은 다른 글로 적도록 하고 이 글에서는 Cloudra Blog에서 명시한 MMv1의 단점을 살펴보도록 하자.

MirrorMaker v1의 한계점

Static Whitelists and Blacklists

복제를 위한 topic을 선정할 때, whitelist와 blacklist를 MMv1 실행할 때 고정(정규식 가능)해야 한다. 복제를 위한 대상 topic이 변경될 때 MMv1을 재시작해야 한다.

No Syncing of Topic Properties

destination cluster의 topic properties에 의존을 한다. source topic의 partition이 10개 destination topic의 partition이 8개라고 할 때, destination properties에 의존하므로 source topic의 partition 순서가 달라질 수 있다. 또한 destination topic의 properties를 바꾸어도 동적으로 MMv1의 설정이 반영되지 않는다.

Manual Topic Naming to avoid Cycles

MMv1은 source topic의 이름과 동일한 이름으로 destination topic에 복제한다. 한 방향으로만 복제를 할 때는 문제가 없지만 양방향일 때는 무한 루프에 빠질 수 있다. 이를 방지하기 위해서는 topic 이름을 변경할 수 있도록 해야한다.

Scalability and Throughput Limitations due to Rebalances

MMv1은 내부적으로 high-level consumer를 사용한다. group coordinator에 의해 파티션을 담당하는 consumer를 결정하는 rebalance를 수행한다. rebalance는 topic 추가/삭제, 파티션 수 변경 등에 의해 일어난다. rebalance가 일어날 때의 문제는 복제 작업이 중단되는 점이다. 지속적으로 중단되면 destination에 의존하는 서비스에 영향을 미칠 수 밖에 없다.

Lack of Monitoring and Operational Support

MMv1는 최소한의 모니터링 관리 기능을 제공한다. 그래서 데이터 파이프라인의 모니터링을 위한 알람을 해줄 수 없다.

No Disaster Recovery Support

cluster에 장애 조치를 위해 재시작을 할 때 문제점이 발생할 수 있다. MMv1는 offset 관리의 근본적인 한계로 인해서 완벽한 스위칭을 하기 어렵다. source와 destination의 offset이 다르기 때문에 consumer의 offset을 통해서는 destination의 위치를 정확히 추적할 수 없다. 만약 destination이 변경되게 된다면 consumer가 마지막으로 commit한 offset을 활용할 수 없다. offset 불일치는 timestamp를 의존해서 처리해야 하지만 어려움이 많다.

Lack of Exactly Once Guarantees

MMv1은 exactly once를 지원하지 않으며 at least once를 지원한다. 그래서 destination topic에 중복된 값이 있을 수 있다. producer와 conumser offset commit이 한 트랜잭션으로 묶이지 않아서이다.

Too many MirrorMaker Clusters

MMv1은 destination cluster와 쌍을 이루어 구축해야 한다. 그래서 cluster가 늘어남에 따라 MMv1도 동일하게 늘어난다.

단점에서 필자가 단점 중에서 크게 문제라고 생각했던 부분은 2가지이다. 설정이 동적으로 변경되지 않는 다는 점과 rebalance 문제이다.

Topic 추가/삭제에 대해서 동적으로 바뀌지 않으니 MirrorMaker를 재시작 해줘야 하는 불편함이 있었다.

그리고 Rebalance가 간헐적으로 계속 반복되다 보니 평소에는 문제가 없지만 Broker에 이슈가 발생할 때마다 성능에 문제가 생기는 일이 빈번했다.

필자는 uReplicator로 변경을 했는데, MMv2가 나온다고 하니 개인적으로 기대를 하고 있다.

그리고 다른 글에서 설명을 하겠지만 MMv2의 도입으로 active/standby, active/active 구조의 multi cluster의 미래를 그리고 있는 듯 해서 궁금함도 있다.

관련 문서

• Kafka Replication: The case for MirrorMaker 2.0