Kinesis Stream vs Kafka

최근에 Cloud service를 활발하게 사용하는 곳이 많아졌다. Big Data 영역에서도 기존 On-Premise에서 Cloud 환경으로 대체되는 경우가 많아지고 있다.

그래서 On-Premise에서 쓰던 Application들이 Cloud 환경에서 무엇으로 대체되는지 검토를 해볼 필요가 있었다.

Kafka를 사용하는 입장에서 Cloud의 1위 업체인 Amazon에서는 어떤 대체 서비스가 있는지 찾는게 첫번째 검토사항이었다.

Kafka에 대한 설명에 대해서는 필자의 Kafka 내용을 추가하는 것으로 대체하도록 하고,

이 글에서는 Kafka와 비교가 가능한 Amazon Kinesis Stream을 설명하고자 한다.

Kinesis Data Stream이란 무엇인가?

Amazon 사이트의 설명을 참조하면 "고도로 확장 가능하고 내구력 있는 실시간 데이터 스트리밍 서비스입니다"라고 한다.

Amazon 개발자 안내서의 아키텍처 그림을 보면 Kinesis Data Stream (이하 KDS)의 구조를 이해할 수 있다.

Producer, Consumer 사이에 KDS가 위치한 것을 볼 수 있다. 어디서 많이 본 익숙한 구조였다.

Kafka와 같이 Streaming 데이터의 중계 및 저장소 역할을 한다.

Kafka 역시 여러 Producer에 의해서 Streaming 데이터를 Broker에 적재하고 Broker에 Partition 단위로 순서를 유지하면서 여러 Consumer가 데이터를 처리하는 구조였다.

KDS는 Kinesis의 구성요소 중에서 Kafka의 Broker와 비슷한 역할을 한다.

그러면 무엇이 다른가?

Kafka와 KDS의 차이점을 표로 정리해 보자. (표는 다른 블로그 글에서 참고했다)

Concepts	Apache Kafka	AWS Kinesis Data Streams
Data Storage	Partitions	Shards
Data Ordering	In partition level	In shard level
Data Retention	No maximum (configurable)	1 to 7 days (default is 24 hours)
Data Size Per Blob	Default 1MB (but can be configured)	Maximum 1 MB
Partition/Shard Modification	Increase only and does not repartition existing data	Re-shard by merging or splitting shards
Partition/Shard Limitation	No limit. Optimal partitions depend on the use case	500 shards in US East (N. Virginia), US West (Oregon), and EU (Ireland) regions. 200 shards in all other regions.
Data Replication/DR	Cluster mirroring	Automatically across 3 Availability Zones
Message Delivery Semantics	Kafka guarantees at-least-once delivery by default. Kafka supports exactly-once delivery in Kafka Streams	Kinesis Data Streams has at least once semantics
Security	Either SSL or SASL and authentication of connections to Kafka Brokers from clients; authentication of connections from brokers to ZooKeeper; data encryption with SSL/TLS	Data can be secured at-rest by using server-side encryption and AWS KMS master keys on sensitive data within KDS. Access data privately via your Amazon Virtual Private Cloud (VPC)
Monitoring	Yammer Metrics for metrics reporting in the server	AWS CloudWatch and CloudTrail
Dependency	ZooKeeper	DynamoDB
Cost	Requires a lot of human support on installation, set up, configuration and clusters management. Setup in weeks	Pay and use. Setup in a couple Of hours

표에서 인상 깊은 차이점만 골라서 따로 부연 설명 하고자 한다.

Partition vs Shard

Kafka에서의 Partiton은 분산의 기준으로서 중요하다. 각 Partiton의 리더들을 통해 데이터가 처리되고, 팔로워들이 리더에 접근해 데이터를 복제한다.

일단 KDS에서는 복제에 대한 자세한 설명을 찾지 못했다. 다만 차이점은 Shard가 데이터 처리 속도의 기준이 되고 자유롭게 증가/ 감소를 할 수 있다는 부분이다.

참고로 Kafka의 Partition은 한번 늘어나면 줄이지 못한다. 각 Partition으로 분산된 데이터들을 줄어든 숫자로 다시 재배치가 어렵기 때문이다. Partitoin을 늘릴 때는 입수되는 데이터를 추가 분산하면 되지만 줄일 때는 방법이 없다. KDS에서는 Shard를 늘릴수도 줄일수도 있다. Cloud는 사용한만큼 금액을 부여하기 때문에 데이터가 많아져서 Shard를 늘였는데 줄일 수 없다면 계속 많은 금액을 내야 하기에 꼭 Shard 숫자를 줄일 수 있어야 한다고 생각한 듯 하다.

Data Size

Kafka에서는 설정에 의해 들어오는 데이터의 크기를 조절할 수 있다. Default 값이 1MB 이기는 하나 입수되는 데이터 크기에 따라 조절할 수 있다. 그런데 KDS에서는 안된다.

만약 실시간 처리하려는 데이터의 크기가 1MB를 넘는 경우라면 KDS를 사용할 수 없다.

Partition/Shard Limitation

Shard의 숫자는 region에 따라 다르지만 최대 500개까지 사용이 가능하다. 경험상 Kafka Partition과 비교할 수 있는 Shard 숫자를 500개까지 늘려야 하는 가능성은 없지만 제한이 있다는건 차이점이다. Shard의 숫자에 따라 속도도 제한하니 Kinesis는 일단 최대 성능을 유추할 수 있을 듯 하다. 반면에 Kafka는 Partition 숫자의 제한은 없다.

완전 관리형 서비스로서 Streaming 서비스를 위해 Kinesis는 선택 가능한 옵션 중 하나다. 다만 운영/성능/가격 측면에서 장단점은 무엇인지 비교하고 적용해야 한다.