SQS와 SNS는 메시지를 "처리하면 사라지는" 것으로 다룬다. 소비자가 가져가면 큐에서 지워지고, 발행되면 푸시되고 잊힌다. 그런데 어떤 데이터는 본질적으로 다르다. 사용자 클릭 스트림, IoT 센서 측정값, 애플리케이션 로그—이런 것들은 끊임없이 흐르고, 여러 시스템이 같은 데이터를 각자 다른 목적으로 동시에 읽고 싶어 하며, 어제 데이터를 오늘 새 알고리즘으로 다시 처리하고 싶기도 하다. Amazon Kinesis는 이런 스트리밍 데이터를 위해, 메시지를 소비 후 버리는 대신 로그에 추가만 하고 일정 기간 보존하는 전혀 다른 모델을 택했다.
DVA-C02에서 Kinesis는 "SQS·SNS와 무엇이 다른가"를 묻는 비교 시나리오로 가장 자주 나온다. 샤드 처리량 숫자, Data Streams와 Firehose의 역할 구분, Enhanced Fan-Out 같은 디테일도 출제된다. 이번 글은 Kinesis가 왜 "추가 전용 로그(append-only log)"라는 구조를 택했는지, 샤드와 파티션 키가 어떻게 순서와 확장을 동시에 푸는지, Data Streams와 Firehose가 갈라지는 이유, 그리고 Kinesis가 SQS와 근본적으로 다른 지점을 깊이 파고든다.
Kinesis Data Streams의 데이터 모델을 한 단어로 줄이면 로그(log) 다