[AWS] Kinesis Data Streams 1분 요약 (개념, 예시, 그 외 비슷한 서비스 종류)

최근 면접 볼 일이 많았는데, 그중 프리랜서 면접 본 곳에서 AWS Kinesis를 통해 데이터 스트림 처리 관련 업무를 맡게 되는 곳이 있었다..

(Kinesis라는 용어조차 처음 들었더니 발음을 잘 모르겠어서 AWS에 데이터 스트림 서비스라고 검색해 본 건 안 비밀...)

 

그만큼 모르는 분야였어서 이번 기회에 간략하게 정리해 보았다..

나와 비슷한 경험이 있는 사람들이 빠르게 아는 척하기에 딱 훑기 좋은 글이 되길 바라면서..😝

 

📝 AWS Kinesis 개념

- 실시간 비디오 및 데이터 스트림을 수집, 처리 및 분석할 수 있는 완전관리형 AWS 서비스이다.

 

 

데이터 스트림을 일상생활에 비유를 해보자.

내가 카페에 앉아 있고 주변에서 일어나는 모든 대화를 실시간으로 듣고 있다고 가정하면,

여기서 일어나는 각 대화들은 데이터 스트림으로 볼 수 있고, 내 뇌는 이 데이터를 실시간으로 처리하고, 중요한 정보를 분류하고 반응한다.

뇌와 비슷한 역할을 하는 서비스가 AWS Kinesis라고 볼 수 있다.

 

 

Kinesis Data Streams High-Level Architecture (출처: AWS 공식홈)

Kinesis Data Streams 용어

 

*데이터 레코드(Data record)

 Kinesis 데이터 스트림에 저장되는 단위

데이터 레코드는 시퀀스 번호, 파티션 키 및 변경할 수 없는 바이트 시퀀스인 데이터 blob(최대 1MB)으로 구성됨

 

*용량모드(Capacity mode)

데이터 스트림 용량 모드는 용량이 관리되는 방식과 데이터 스트림 사용에 대한 요금이 청구되는 방식으로 결정됨

온디맨드 모드, 프로비저닝 모드 중에서 선택 가능

온디맨드 모드 - 필요한 처리량을 제공하기 위해 샤드를 자동으로 관리 (사용한 실제 처리량에 대해서만 요금이 부과됨)

프로비저닝 모드 - 데이터 스트림의 샤드 수를 지정해야 함, 데이터 스트림의 총용량은 해당 샤드 용량의 합계(샤드 수에 대해 시간당 요금 부과)

 

*보존 기간(Retention period)

데이터 레코드를 스트림에 추가한 후 데이터 레코드에 엑세스할 수 있는 기간

기본: 24시간

최대 8760시간(365일) 가능(IncreaseStreamRetentionPeriod)

최소 24시간(DecreaseStreamRetentionPeriod)

 

*생산자(Producer)

레코드를 AWS Kinesis Data Streams에 저장하는 것

예를 들어, 스트림에 로그 데이터를 보내는 웹서버가 생산자

 

*소비자(Consumer)

AWS Kinesis Data Streams의 레코드를 가져와서 처리하는데, 이 소비자를 AWS Kinesis Data Streams 애플리케이션이라고 한다.

 

*AWS Kinesis Data Streams Applications

EC2 인스턴스의 플릿에서 공통적으로 실행되는 스트림의 소비자

Kinesis Data Streams 애플리케이션의 출력은 다른 스트림의 입력이 될 수 있으며 실시간으로 데이터를 처리하는 복잡한 토폴로지를 생성할 수 있도록 해줌

또한, 애플리케이션은 다양한 다른 AWS 서비스에 데이터를 보낼 수 있음

스트림 하나에 여러 애플리케이션이 있을 수 있으며 각 애플리케이션이 동시에 독집적으로 스트림의 데이터를 소비할 수 있다.

 

*샤드(Shard):

스트림의 기본 데이터 처리 유닛

데이터 스트림으로부터 데이터 수집, 저장 처리하는 데 사용.

스트림의 처리량(Capacity)과 병철 처리 능력은 스트림에 포함된 샤드의 수에 결정된다.

필요한 처리량에 따라 적절한 수의 샤드를 구성하여 스트림을 최적화할 수 있다.

읽기의 경우 초당 최대 5개의 트랜잭션, 초당 최대 2MB의 총 데이터 읽기 속도

쓰기의 경우 초당 최대 1,000개의 레코드, 초당 최대 1MB의 총 데이터 쓰기 속도를 지원할 수 있음

스트림의 데이터 용량은 스트림에 지정하는 샤드 수의 함수

스트림의 총용량은 해당 샤드의 용량의 합계

 

*파티션 키(Partition Key)

스트림 내의 샤드에서 데이터를 그룹화하는 데 사용됨

최대 길이 제한 256자인 유니코드 문자열

파티션 키를 128비트 정수 값에 매핑하고, 샤드의 해시 키 범위를 사용하여 연결된 데이터 레코드를 샤드에 매핑하기 위해 MD5 해시 함수 사용

 

*시퀀스 번호(Sequence Number)

각 데이터 레코드에는 샤드 내 파티션 키별로 고유한 시퀀스 번호가 있음

같은 파트션 키의 시퀀스 번호는 일반적으로 시간이 지나면서 증가, 쓰기 요청 간의 기간이 길수록 시퀀스 번호 커짐

 

📝 작동 방식 요약

1. 데이터 수집 (Input -> AWS Kinesis)

- 여러 출처로부터 데이터가 Kinesis로 흘러들어오는데,

이 데이터들은 웹사이트 클릭, 센서 데이터, 금융 거래, 로그 파일 등 다양한 연속적인 데이터 스트림일 수 있다.

(내가 면접 본 곳은 IoT 관련된 곳이었다 ㅎㅎ)

 

2. 데이터 처리 및 분석 (AWS Kinesis)

- 흘러들어온 데이터는 Kinesis 시스템 내에서 처리되는데, 특정 조건을 충족하는 데이터를 필터링하거나, 데이터 조각(개별 레코드 또는 이벤트 등) 들을 합쳐서 더 큰 의미를 찾으며 분석한다.

- 예를 들어, 데이터 스트림에서 직접 적용할 수 있는 간단한 데이터 변환, 집계 작업도 포함 가능(시간대별로 데이터를 집계하여 평균값을 계산한다는 등의 작업)

 

3. 데이터 저장 및 사용(AWS Kinesis -> AWS s3, ElasticSearch, RedShift 등 서비스 -> Output)

- 처리된 데이터는 분석을 위해 AWS의 다른 저장 서비스로 전송될 수 있다. 또한, 이 데이터를 사용하여 대시보드를 업데이트하거나, 알림을 보내는 등의 액션을 취할 수 있다.

- 예를 들어, AWS S3에 저장된 데이터를 기반으로 Amazone Athena를 사용하여 SQL 쿼리를 실행하거나, Amazon QuickSight를 사용하여 대시보드를 생성하여 데이터를 시각화를 수행할 수 있음

 

*AWS RedShift: petaByte 규모의 데이터 웨어하우스 완전관리형 AWS 서비스, 복잡한 쿼리와 대량의 데이터 분석 작업을 빠르게 처리할 수 있음 (구조화된 데이터에 대한 분석 지원)

*AWS ElasticSearch: 오픈 소스 검색 및 분석 엔진을 기반으로 하는 완전 관리형 AWS 서비스, 대규모 데이터셋에 대해 빠른 검색, 실시간 분석, 복잡한 쿼리, 로그 분석, 데이터 시각화 기능 제공(비구조화된 데이터인 텍스트, 로그 등의 검색과 분석을 위해 JSON형식의 쿼리를 사용)

 

📝 왜  AWS Kinesis를 사용하는가?

1) 다양한 데이터 소스와 유형 처리

- Kinesis는 GA 같은 분석 시스템과 다르게 더 넓은 범위의 데이터 소스와 유형을 처리할 수 있다. IoT장비 데이터, 서버 로그, 소셜 미디어 피드 등 다양한 형태의 실시간 데이터를 처리하는데 적합하다.

 

2) 고성능 실시간 처리

- 대량의 데이터를 실시간으로 처리하고 분석해야 하는 경우, Kinesis는 높은 처리량과 낮은 지연 시간을 제공한다.

 

3) 맞춤형 데이터 처리

- Kinesis를 사용하면 데이터 스트림 맞춤 설정하며, 특정 비즈니스 요구 사항이나 로직에 맞게 데이터를 처리하고 분석할 수 있다.

 

 

📝 AWS Kinesis와 비슷한 다른 서비스들

1) Apache Kafka

- Apache Kafka는 고성능, 고신뢰성을 가진 분산 스트리밍 플랫폼이다. 대량의 데이터 스트림을 실시간으로 처리하고, 데이터를 저장하며, 여러 시스템과 데이터를 통합할 수 있다.

- 높은 처리량, 빌트인 파티셔닝, 복제, 서버 간 밸런스 조정 등을 지원하고, 대규모 메시지 처리가 필요한 애플리케이션에 사용됨

 

Kinesis와 차이점:

1. Kinesis는 완전 관리형 서비스지만, Kafka는 오픈 소스 플랫폼으로 사용자가 직접 설치, 설정, 운영 등 커스터마이징 필요

2. Kinesis는 데이터 처리량, 샤드의 수, 저장 데이터의 양에 따라 비용이 결정되지만, Kafka는 소프트웨어 자체는 무료, 자체 서버 관련 인프라 비용이 발생함

3. Kinesis는 당연하게도 AWS 생태계 적극 활용 가능하여 다른 AWS 서비스와의 연동이 용이함, Kafka는 브로커(개별서버) 시스템을 통한 확장이 용이하여, 다양한 플러그인, 커뮤니티 지원을 통해 거의 모든 데이터 소스와 시스템에 연결할 수 있다고 한다.

 

결론은 Kinesis 서비스는 AWS 환경에서 빠르고 쉽게 스트림 처리 기능 구현하고 싶으면 사용하고, Kafka는 좀 섬세한 커스터마이징이 필요하고, 복잡한 스트림 처리 로직을 구현해야 하는 대규모 프로젝트에 적합할 수 있을 것 같다.

 

* 빌트인 파티셔닝: 큰 데이터 스트림을 관리 가능한 작은 부분으로 세분화하는 작업

* 복제: 데이터의 안전을 위해 백업해 주는 것

* 서버 간 밸런스 조정(Load Balancing): 시스템의 부하를 고르게 분배하는 부하 분산 작업

 

2) Apache Flink

- 복잡한 데이터 스트림 처리를 위한 분산 처리 엔진, 실시간 스트리밍 데이터 처리뿐만 아니라, 배치 데이터 처리도 지원

- 고성능, 정확한 시간 관리, 고장 내성 등을 제공

- 스트림 처리의 정확성과 실시간 처리 능력이 핵심

 

3) Google Cloud Pub/Sub

- Google Cloud에서 제공하는 실시간 메시징 서비스

- 데이터 스트림을 쉽게 수집, 분석, 분산시키고 다양한 Google Cloud 서비스와 통합할 수 있다.

- 글로벌 분산, 높은 가용성, 대규모 이벤트 스트림의 신속한 처리를 지원하고, 서버리스 아키텍처를 사용하여 관리가 용이함

 

4) Microsoft Azure Event Hubs

- Azure Event Hubs는 Microsoft Azure에서 제공하는 대규모 이벤트 스트림 데이터 수집 서비스

- 높은 처리량의 이벤트나 데이터를 처리할 수 있음

- 수백만 개의 이벤트를 초당 처리할 수 있는 능력, 데이터 분석과 저장을 위한 실시간 스트림 처리 기능 제공

 

5) Apache Pulsar

- Apache Pulsar는 분산 메시지 및 스트리밍 플랫폼

- Kafka와 비교 시 멀티 테넌시, 지연 시간이 짧은 메시징, 서버리스 클라우드 네이티브 스트리밍, 분산된 영속성이 장점이라고 한다.

 

*멀티 테넌시(Multi-tenancy): 단일 인스턴스의 소프트웨어 애플리케이션이나 서비스가 여러 사용자 또는 고객(테넌트)에게 서비스를 제공할 수 있는 아키텍처를 말함. 리소스 공유, 데이터 격리, 유연한 스케일링, 중앙에서의 효율적인 관리와 업데이트 가능

*메시지: 시스템, 서비스, 애플리케이션 간에 데이터를 실시간으로 교환하는 모든 형태의 메시징을 포함

---

오호,, 간략하게 요약해 봤는데, 굉장히 재미있는 내용이었던 걸 새삼 깨달았다..!

역시나 이런 플랫폼을 경험해보지 못한 게 너무 아쉽다.. 꼭 앞으로는 경험해서 블로그에 실제 후기 작성하는 날이 오기를...💪🏻