kafka vs kinesis + (msk)

Viva의 놀이터·2022년 2월 4일

kafka

목록 보기

1/5

배경

프로젝트에서 데이터 스트리밍이 필요하여 기술적 검토가 필요하여 kafka와 kinesis를 비교하여 기존의 kinesis를 계속해서 사용하는 것이 유리한지 kafka로 전환하는게 유리한지 분석하려 합니다.

kafka

kafka의 구성요소

Event
Event는 kafka에서 데이터를 주고 받는 단위입니다.
Producer
producer는 event를 kafka에 등록(post)하는 클라이언트 어플리케이션을 의미합니다.
Consumer
consumer는 event를 kafka(topic)에서 읽는(get)하는 클라이언트 어플리케이션을 의미합니다.
Topic
event를 분류하는 기준이고 Producer에서는 Topic에 event를 post하고 Consumer는 Topic에서 event를 get하여 처리합니다.
Topic으로 분류된 event는 필요한 만큼 다시 읽는 것이 가능합니다. event를 topic으로 구분하여 관리합니다!
ex) topic은 카테고리, event는 아이템
Partition
partition은 Topic으로 묶긴 event를 분산하여 저장하는 저장소입니다.

kafka의 특징

producer과 consumer의 관계

kafka의 특징은 producer과 consumer가 분리되어 있다는 점입니다. producer는 consumer를 고려하지 않고 event를 topic에 저장하기만 하면되고, 마찬가지로 consumer는 producer를 신경쓰지 않고 원하는 topic을 구독하여 topic안의 event를 받아서 처리하면 됩니다. 기존의 message queue와 차이점은 broker가 직접 consumer에게 메시지를 전달하는 것이 아닌 consumer가 필요하면 broker에서 메시지를 가져와서 사용합니다. 이처럼 producer와 consumer의 분리는 kafka의 높은 확장성을 제공합니다. 두 객체는 본인의 역할만 신경쓰면 되기 때문입니다.

Topic의 event 저장

event는 topic으로 분류되고 topic은 여러개의 partition에 나눠서 event를 저장합니다.
장점: producer에서 event를 발생시면 topic으로 분류하고 저장하는데 동시에 여러개의 topic을 저장하고 실시간 성으로 데이터를 처리하기 위해서는 속도가 빨라야 합니다. 분산해서 저장하면 event의 처리를 병렬로 처리하여 빠른 처리가 가능합니다.
단점: topic이 분산되어 저장되기 때문에 event가 발생한 순서대로 저장되지 않기 때문에 소비도 순차적으로 되지 않습니다. 또한 한번 늘린 파티션은 줄일수없기 때문에 파티션을 늘릴때는 신중하게 늘려야합니다.

+) producer에서 topic에 key를 설정해주면 특정 메시지를 분류해서 특정 파티션에만 저장이 가능하다 -> 순차적인 저장 가능 = 순차적인 소비 가능

consumer group

kafka에서는 consumer group 이라는 개념이 존재하고 이는 consumer의 묶음을 의미합니다. topic을 분산하여 저장한 partition을 소비하는 consumer는 하나의 group으로 묶깁니다.
consumer가 partition을 소비할 때는 한가지 규칙이 존재합니다. partition은 consumer과 1:N로 매핑이 되는 규칙입니다.

ex)

1개의 partition , 2개의 consumer (1개의 consumer는 대기 상태)
2개의 partition , 1개의 consumer (1개의 consumer가 2개의 partition을 소비)
2개의 partition , 2개의 consumer (각각의 객체는 1:1 매칭)

1개의 파티선을 증식 시킬 때는 consumer의 수를 고려해야합니다. 그렇지 않으면 여러개의 파티션을 한개의 consumer에서 소비해야 하는 경우가 발생하는데 이 경우 consumer에 부하가 커서 죽거나 성능이 저하될 수 있습니다.

kafka의 fail-over 대응

consumer group에서 언급한 것 처럼 topic은 한개의 consumer group이 담당을 하고 있습니다. partition과 consumer간의 커넥션이 끊기는 경우(consumer가 down되는 경우)를 rebalance된 상황이라 하고 다른 컨슈머가 down된 컨슈머를 대신해 partition을 소비합니다. 이때 partition이 어디까지 소비했는지를 알기 위해서 offset을 사용합니다. consumer group내의 consumer끼리 offset을 공유하기 때문에 빠르게 이전에 소비한 위치부터 살아있는 consumer로 대처가 가능합니다.

zookeeper

클러스터 최신 설정 정보 관리, 동기화, 리더 채택 등의 클러스터의 서버들이 공유하는 데이터를 관리하기 위해 사용합니다. 즉 broker에 분산 처리된 메시지 큐의 정보를 관리하는데 사용되고 kafka를 가동하기 위해서는 zookeeper 먼저 가동 되어있어야 합니다.

kafka vs kinesis

kinesis는 이미 사용하기 있기에 설명을 생략하겠습니다.

이제 이 둘 중 앞으로 진행할 프로젝트에 더 적합한 기술이 무엇인지 비교하겠습니다.

성능

kafka, kinesis 이 둘의 차이점 중에 유의미한 부분을 비교해보자면 데이터를 처리해서 저장하는 kafka의 partition은 유입되는 데이터의 양에 따라 auto-scaling이 힘듭니다. 또한 한번 늘린 partition은 다시 줄일수 없습니다. 반면 kinesis의 shard는 유입되는 데이터의 양에 따라 auto-scaling이 가능합니다. 즉 shard의 증설 및 감축이 자유롭습니다.
또한 partition의 숫자에는 제한이 없지만 shard의 수는 최대 500개로 제한이 있습니다. 만약 프로젝트의 크기가 커지고, 스트리밍 데이터가 많다면 성능적인 측면에서 kafka가 유리 할 수 있습니다.

데이터의 크기

kafka의 경우 데이터의 크기를 조절할 수 있습니다. default값이 1mb지만 유입되는 데이터의 크기에 따라 조절이 가능하지만 kinesis는 데이터의 크기가 1mb를 넘어서는 안됩니다.

데이터의 보존기간

2017년 이전에는 kinesis의 데이터 보존 기간이 최대 7일이기 때문에 kafka vs kinesis에서 중요한 요소였지만 오늘날 최대 365일로 확장되어 1년 이후까지 데이터를 보관할 경우에만 고려할 사항이 되었습니다.

모니터링

kafka의 경우 kafka에서 제공하는 api를 통해서 kafka의 모니터링이 가능하고, kinesis의 경우 aws의 모니터링 서비스를 통해서 모니터링이 가능합니다. 결과적으로 kafka의 경우 추가적인 모니터링 관리가 필요하지만 kinesis의 경우 aws 서비스의 모니터링과 같은 곳에서 관리가 가능하기 때문에 생산성이 높다고 판단됩니다. 저희 회사의 경우 aws에 많은 서비스가 엮여있고 cloudwatch를 통해서 모니터링 한다고 하였을 때 유지 보수 측면에서 kinesis가 좀더 유리하다고 할 수 있습니다.

요금

kafka는 오픈 소스이기 때문에 초기 비용이 없습니다. 반면 kinesis의 경우 aws의 서비스로 비용이 발생합니다. kinesis의 성능을 담당하는 shard 1개 당 하루 0.36$ 비용이 발생하고 한달에 10.8$의 비용이 발생합니다.

운영 난이도 측면

kafka는 처음부터 모든 설정을 사용자가 직접 관리해주고 설정해야 합니다. 또한 kafka를 관리하는 zookeeper의 관리 또한 사용자가 직접 해야합니다. 반면 kinesis의 경우 많은 부분을 aws에서 관리해주고 설정이 비교적 간편하다고 합니다. kafka를 설정하고 관리 및 지원하는데 자원이 많이 들기에 인력이 부족할 경우 aws의 kinesis를 사용하는게 유리 할 수 있습니다.

MSK

앞서 kafka와 kinesis를 비교하면서 aws 관리가 있어 kinesis가 더 편리하다고 언급하였는데 aws에도 kafka가 존재하고 이를 고려사항에 추가하고자 합니다. aws의 서비스인 만큼 사용하는데 비용이 발생하겠지만 사용했을 때 기본 kafka와 어떤 차이점이 있는지 분석하려 합니다.

kafka와 kinesis를 비교했을 때 kafka의 관리가 어렵고 어렵게 하는 원인중 kafka를 관리하는 zookeeper의 관리가 어렵다고 언급하였는데 MSK는 zookeeper를 관리해주기 때문에 운영 효율성을 높을 수 있습니다. 또한 모니터링을 위한 별도의 작업 없이 기존의 aws의 cloudwatch를 통해서 모니터링이 가능하고 많은 설정을 aws 콘솔에서 설정이 가능하기에 러닝커브를 낮출수있습니다. 이외에도 자동 복구 및 패치 기능을 통해서 클러스터 상태를 지속적으로 모니터링하여 중단되는 일을 사전에 방지하여 안정성이 높습니다.

다만 kinesis와 마찬가지로 확장성에 제한이 있습니다. 기존의 kafka는 partition 생성에 제한이 없지만 MSK는 클러스터당 최대 30개의 브로커만 생성이 가능하고 계정당 90개까지 브로커를 생성 할 수 있습니다. 또한 사용할 수 있는 인스턴스가 지정되어 있습니다. 서비스의 크기에 비해서 큰 인스턴스를 사용할 가능성이 있습니다.

이를 종합하면 MSK는 kafka와 kinesis를 비교할 때 발생하는 단점들을 커버 할 수 있지만, 기초 비용이 비쌉니다. 따라서 규모가 크지 않다면 MSK에서 제공하는 편의성보단 비용적인 측면이 부담이 될것입니다.

"kafka를 관리할 인력이 있다면 kafka를 사용하는것이 좋고, 인력이 부족하다면 완전 관리형인 MSK를 사용하는게 좋지만 비용이 발생한다."