LinkedIn 의 brooklin 활용
최근에 흥미로웠던 LinkedIn 에서 Brooklin 을 활용한 Mirror Maker 를 소개하고자 한다.
현재 Kafka Cluster 간 Message 를 Mirroring 하는 방법은 다양하다. 대표적으로 Mirror Maker 라는 오픈소스가 있고(이건 v2 가 release 되었다), Kafka Connector 나 오늘 소개할 Brooklin, 그리고 직접 Consumer 와 Producer 를 구현해서 만들수도 있다.
필자가 Kafka Mirroring 과 관련된 모든 오픈소스를 확인해본건 아니지만, 적어도 위에서 언급한 방법들에 대해서만 한정하자면 모두 공통적으로 Source Cluster 에서 message 를 Consuming 하고, 이를 Target Cluster 로 Publish 하는 방식을 기본으로 한다.
그래서 사실 어떤 오픈 소스를 쓰거나 혹은 직접 구현하는게 크게 특별한 차이가 존재하지 않을거라 생각했는데 Linkedin 의 Brooklin 활용 방식을 보고 내 생각이 짧았음을 느끼게 되었다.
LinkedIn 의 Brooklin 활용 방식을 통해 인상깊게 느꼈던 부분은 다음과 같다.
1. Kafka 에서 제공하는 Metric 을 자동화 시스템을 위한 지표로 활용한 점.
Kafka 에서 제공하는 JMX metric 중에는 Topic 의 Partition 단위로 traffic 이 얼마나 되는지 볼 수 있는 metric 이 있는데 LinkedIn 에서는 이 metric 을 활용하여 Mirroring 노드가 받을 트래픽을 계산하고 이를 기반으로 노드별 트래픽이 분산되도록 자동화 시스템을 구축했다.
필자는 이 Metric 을 단순히 Kafka 가 받고 있는 Traffic 이 어느정도인지 모니터링 하는 용도로 사용할 생각만 했지 이를 자동화 시스템을 구현하기 위한 지표로 활용할 생각은 전혀 못했다.
2. 자신들의 목표를 위해 Kafka 가 제공해주는 기능을 활용하지 않은 점.
Kafka 가 제공해주는 기능중에 Consumer 의 Partition Ownership 을 각 Consumer 에 적절히 분산시켜주는 기능이 있는데 LinkedIn 은 이를 사용하지 않았다.
그 이유는 Kafka 가 Consumer 의 Partition Ownership 을 분배하는 방식은 단순히 Partition 갯수를 기반으로 균등하게 분배하는 방식이기 때문에 파티션별 트래픽이 달라질 경우 이를 컨트롤 할 수 없다. 즉, 경우에 따라 특정 노드는 열심히 일하고 특정 노드는 놀게되는 현상이 발생하게 된다.
그래서 LinkedIn 에서는 Brooklin 에서 Mirroring 을 위한 Datastream(흔히들 얘기하는 Job 과 비슷한 개념으로 생각하면 된다.) 을 정의할 때 Consumer 가 특정한 partition 만 assign 하도록 설정한다. 즉, Kafka 가 자동으로 Partition 을 지정해주는게 아닌 LinkedIn 에서 직접 자신들이 원하는 Partition 에 assign 하도록 로직을 구현한 것이다.
Kafka 의 Partition Ownership 분배가 얼마나 강력한 기능인지는 Kafka 를 사용해본 사람이라면 누구나 알것이다. 그런데 LinkedIn 은 자신들이 목표한 Mirroring 기능을 위해 이 기능을 포기하고 본인들이 직접 Control 하도록 변경한것이다.
당연하게 사용해야될 기능인줄 알았는데 이렇게 변화를 줄 수도 있다는 사실이 필자에겐 꽤나 충격적이고 신선했다.
3. 이런 구현이 가능하도록 Brooklin 을 설계했다.
Brooklin 을 만든 목적이 이 글에서 소개한 자동화된 mirroring 을 구현하기 위한건지, 아니면 만들다보니 이렇게 활용할 수 있게 된건지는 정확하게 모르겠지만 한가지 분명한건 LinkedIn 에서 활용한 방식을 비슷하게 해볼려면 필자가 알고있는 방법중에는 Brooklin 을 쓰는게 가장 적절해 보인다는 점이다. 현재 필자가 업무를 하고 있는 팀에서도 Mirroring 을 구현할 방안으로 Brooklin 을 활용할지 검토중이다.
이밖에 OLAP 데이터 저장소로 Apache Pinot 과 Samza 를 통한 스트리밍 처리도 흥미로운 주제이지만 이 내용은 다음에 기회가 되면 정리해볼까 한다.(Samza 대신 Kafka Streams 를 써도 되지 않았을까 하는 생각이 든다)
# Reference