Amazon Kinesis

클릭 스트림과 센서 데이터가 초 단위로 계속 들어오는데, 배치 적재나 일반 큐만으로 처리하려 하면 순서와 실시간성이 쉽게 깨집니다. 흐르는 데이터를 끊김 없이 받아둘 계층이 없으면 downstream 처리가 금방 따라오지 못합니다.

예전에는 로그를 파일로 모아 수 시간 단위로 배치 처리하는 경우가 많았습니다. 그러면 이상 징후를 발견해도 이미 몇 시간이 지난 데이터를 보게 되고, 실시간 대응은 처음부터 불가능했습니다. 사고 감지가 늦어지고 비즈니스 지표도 다음 날 아침에야 확인할 수 있는 구조였습니다. 데이터가 들어오는 즉시 흘려보내고 처리해야 한다는 요구가 커지면서, 이를 뒷받침하는 스트림 수집 계층이 필요해졌습니다.

프로듀서(서버, 앱, IoT 기기)가 데이터를 스트림에 올리면, 스트림은 샤드(Shard)라는 병렬 처리 단위로 데이터를 분산해 저장합니다. 각 컨슈머는 담당 샤드에서 독립적으로 읽어가기 때문에, 샤드 수를 늘리면 수집·처리 처리량이 그에 비례해 늘어납니다. S3나 Redshift로 데이터를 바로 내보내야 할 때는 Firehose가 중간에서 자동 전달을 맡고, Lambda와 연결하면 스트림에 올라온 데이터를 실시간으로 변환하거나 알림을 붙일 수 있습니다.

Kinesis와 SQS는 둘 다 비동기 데이터 흐름에 쓰이지만 모델이 다릅니다. Kinesis는 시간 순서가 중요한 연속 스트림을 여러 소비자가 처리하는 데 강하고, SQS는 개별 작업 메시지를 안전하게 소비하는 큐에 가깝습니다. 이벤트 흐름 전체를 실시간으로 읽고 가공해야 하면 Kinesis를 보고, 작업 단위를 안정적으로 넘기고 재시도해야 하면 SQS를 보면 됩니다.

클릭스트림, IoT 이벤트, 로그 수집, 실시간 분석 파이프라인, 스트림 후처리에 적합합니다. 순서 보장 없이 작업을 대기열에 쌓고 소비하는 단순 큐잉에는 과합니다.