AWS Kinesis Data Stream 내부구조

현재 회사 서비스에 발생하는 데이터 스트림을 구축하고 있다. aws 에서 제공하는 aws kinesis data stream 를 사용할 일이 있어 내부구조 파악하고 있다.

---

 

아키텍처

kinesis data stream 은 "분산 큐" "스트림 스토리지" 라는 개념으로 설명할 수 있다.

즉, 아래 세가지 특성을 갖는다.

1. queue

2. distributed

3. storage

 

stream 별로 샤드수를 지정해야 하는데, 샤드는 인입되는 데이터가 저장되는 큐의 갯수라고 할 수 있다. 1개 샤드당 capacity, maximum total data read rate, maximum total records for writes, maximum total record rate 등 상한수치가 정해져있다. 따라서 인입되는 데이터의 속도와 양에 따라 샤드수를 조절해 주어야 한다.

 

AWS에서 제공하는 문서를 참고하면, 아래와 같다. 

write: up to 1MB or 1000 records per seconds

read: 5transactions per second(5번의 API 요청을 의미), up to 10MB per second, 10000 records per call

 

데이터가 인입될때 데이터에 포함되어 있는 Partition Key(필수)에 Hash function(MD5 사용하여 16바이트 정수로 변환)을 적용하여 어떤 샤드에 저장될지 결정된다.

 

샤드에 레코드가 차례로 쌓인 후 각각의 컨슈머 혹은 컨슈머 그룹에 의해 데이터가 처리되는데, 이때 데이터가 처리되는 방식은 kafka와 비슷하다. 샤드마다 컨슈머 마다의 개별 포인터가 처리해야할 데이터를 가리키는 방식이다(next consumer offset). 따라서 이미 컨슈머가 데이터를 이미 소비 하였더라도, 다른 컨슈머에 의해 데이터를 반복적으로 읽을 수 있게된다.

 

리텐션기간이 지난 데이터는 자동으로 삭제된다(24 hour) 또한 이러한 특성 때문에 stream stroage 라고 불린다.

 

카프카와 구조가 비슷하다보니, 개념상 카프카와 주의할 점도 비슷하다. 하나의 큐(샤드)에서 하나의 컨슈머(혹은그룹)이 데이터를 읽고 처리할땐 순서대로 읽지만, 샤드가 여러개일 경우엔 하나의 큐에서의 처리순서만 보장된다. 즉, 샤드가 여러개라면 데이터의 인입순서와 상관없이 처리순서가 정해질 수 있다는 것이다(여러 샤드간에는 처리순서가 다를 수 있으니)

 

운영상 필요지식

정해야할 것

stream 수, 샤드 수

 

모니터링 해야할 것

아래와 같은 상황들이 발생하는지 모니터링이 필요하다

1. Write Throughput 초과가 발생하는지(샤드의 인입 한계속도는 정해져있는데, 이걸 초과해서 데이터 인입발생 시도가 있는지) -> WriteProvisionedThroughputExceeded

2. Read Throughput 초과가 발생하는지(샤드의 read 한계속도 초과) -> ReadProvisionedThroughputExceeded

3. 데이터의 소비속도가 인입속도보다 느릴경우, 당연스럽게도 처리되지 못한 데이터가 점점 많아지게되는 양상을 띄게 된다. 즉, "샤드 내 record들이 얼마나 오랫동안 처리되지 못하고 대기하고 있는지" -> GetRecords.IteratorAgeMilliseconds

 

 

 

 

참고

Kinesis Data Stream 과 MSK 의 내부구조에 대해 설명한 영상: https://www.youtube.com/watch?v=7ppCJy2pF7U

Kinesis Data Stream document: https://docs.aws.amazon.com/streams/latest/dev/key-concepts.html