AWS Kinesis - (1) Kinesis Data Stream Introduce

Understanding Kinesis Data Stream
김주혁's avatar
Sep 09, 2024
AWS Kinesis - (1) Kinesis Data Stream Introduce
 
 
AWS Kinesis는 실시간 데이터 스트림을 수집, 처리 및 분석해주는 도구입니다.
 
 
Kinesis는 데이터 스트림 처리를 위해서 4가지 플랫폼을 제공합니다.
  • Kinesis Data Stream
  • Kinesis Date Firehose
  • Kinesis Video Stream
  • Kinesis Data Analytics
 
Kinesis 도입 목표가 실시간 로그 처리였기 때문에, 이 글에선 이 중 실시간 로그 처리를 위한 사례로 적합한 Data Stream과 Firehose만을 다루겠습니다.
 

Kinesis Data Stream


 
Kinesis Data Stream Application이라고 하는 데이터 처리 Application을 만들 수 있습니다. 이 Application을 통해 대용량 스트림을 수집하고 처리할 수 있습니다. Kinesis Data Streams 애플리케이션은 데이터 스트림 에서 데이터 레코드로 데이터를 읽습니다.
 
다음 아키텍처는 Kinesis Data Streams의 상위 수준 아키텍처를 보여줍니다. 생산자는 Kinesis Data Streams에 지속적으로 데이터를 푸시하고 소비자는 실시간으로 데이터를 처리합니다. 소비자(Application 또는 Amazon Data Firehose 전달 스트림)는 Amazon DynamoDB, Amazon Redshift 또는 Amazon S3와 같은 AWS 서비스를 사용하여 결과를 저장할 수 있습니다.
 
notion image
 

Kinesis Data Stream Started

 

Producer

 
프로듀서는 Amazon Kinesis Data Streams에 레코드를 넣습니다. 예를 들어, 스트림에 로그 데이터를 보내는 웹 서버는 Producer입니다.
 

Consumer

 
소비자는 Amazon Kinesis Data Streams에서 레코드를 가져와 처리합니다. 일반적으로 Amazon Kinesis Data Streams Application 입니다.
 
  • fan-out consumers(기본)
    • Shard Read Throughput: Shard당 2 MB/sec 고정되어 있으며, 다수의 consumers가 동일한 shard에서 가져갈시(read) 모두 동일한 데이터를 가져가지만, 초당 2MB 을 넘어가면 안됨
    • Message Propagation Delay: 하나의 consumer당 200ms 가 걸리고, 5개의 consumers가 존재시 1000ms 까지 느려질수 있음
    • Cost: 없음
  • enhanced fan-out consumers
    • 기존 fan-out consumers의 제약을 넘어서기 위해서 나온 consumer
    • Shard Read Throughput: enhanced fan-out consumers는 모두 독립적인 read throughput을 갖으며 각각 2 MB/Sec 를 갖는다
    • Message Propagation Delay: 하나의 consumer가 있는 5개가 있든 상관없이 평균 70ms 가 걸림
    • Cost: 데이터를 retrival 그리고 consumer-shard hour cost 존재
    •  

Kinesis Data Stream은 샤드 세트입니다.

 
Kinesis 데이터 스트림 은 샤드 세트입니다. 핵심적으로 Kinesis Data Streams는 여러 개의 샤드로 구성되어 있으며, 각각에 1에서 N까지 고유한 번호가 지정됩니다. 샤드의 수는 스트림의 데이터 수집 및 소비 용량에 직접적인 영향을 미칩니다.
 
  • Shard?
    •  
      샤드  스트림에서 고유하게 식별된 데이터 레코드 시퀀스입니다. 스트림은 하나 이상의 샤드로 구성되며, 각각은 고정된 용량 단위를 제공합니다.
       
    • 각 샤드는 읽기의 경우
      • 초당 최대 5개의 트랜잭션
      • 초당 최대 2MB의 총 데이터 읽기 속도
    • 쓰기의 경우
      • 초당 최대 1,000개의 레코드
      • 초당 최대 1MB의 총 데이터 쓰기 속도(파티션 키 포함)를 지원할 수 있습니다.
       
      Kinesis Data Stream이 수용할 수 있는 데이터 용량은 지정한 샤드 수에 따라 달라집니다. 즉, 스트림의 총 용량은 샤드의 용량 합계 입니다. 데이터 읽기/쓰기가 증가한다면 Stream에 할당된 샤드 수를 늘리거나 줄임으로서 확장성을 가져갈 수 있습니다. 자세한 것은 스트림 재샤딩을 통해 확인할 수 있습니다.
       

Data Record

 
데이터 레코드는 Kinesis Data Stream에 저장된 데이터 단위입니다. 데이터 레코드는 시퀀스 번호 , 파티션 키 및 불변 바이트 시퀀스인 데이터 블롭으로 구성됩니다. Partition Key는 데이터를 그룹화 하는데 사용되며 그룹화된 데이터의 식별자가 Sequence Number입니다.
 
  • Sequence Number
    •  
      각 데이터 레코드는 샤드 내의 파티션 키마다 고유한 시퀀스 번호를 가지고 있습니다. 즉, 각 데이터 레코드에 대한 고유 값을 가지고 있다는 의미입니다.
    • Kinesis Data Streams는 스트림에 데이터를 쓸 때 시퀀스 번호를 할당합니다.
    • 동일한 파티션 키에 대한 시퀀스 번호는 일반적으로 시간이 지남에 따라 증가합니다.
    • 쓰기 요청 간의 시간이 길어질수록 시퀀스 번호는 더 커집니다.
 
  • Partition Key
    •  
      파티션 키는 스트림 내에서 샤드로 데이터를 그룹화하는 데 사용됩니다. Kinesis Data Streams는 스트림에 속하는 데이터 레코드를 여러 샤드로 분리합니다. 각 데이터 레코드와 연관된 파티션 키를 사용하여 주어진 데이터 레코드가 속하는 샤드를 확인합니다. 애플리케이션이 데이터를 스트림에 넣을 때 파티션 키를 지정해야 합니다.
       
    • 파티션 키는 유니코드 문자열이며 각 키의 최대 길이는 256자입니다.
    • MD5 해시 함수는 파티션 키를 128비트 정수 값에 매핑하고 샤드의 해시 키 범위를 사용하여 연관된 데이터 레코드를 샤드에 매핑하는 데 사용됩니다.
 
  • Data Blob
    •  
    • 블롭의 데이터를 어떤 식으로든 검사, 해석 또는 변경하지 않습니다.
    • 데이터 블롭은 최대 1MB가 될 수 있습니다.
 

Capacity Mode

 
AWS Kinesis Data Stream은 온디맨드와 프로비저닝 모드로 나뉩니다.
 
  • 온디맨드는 사용자의 요청할 때 마다 자동으로 관리되기 때문에, 따로 사용자의 디테일한 설정이 없이도 변동적인 트래픽에 대응할 수 있다는 장점이 있고 사용이 편리하다는 장점이 있습니다.
  • 프로비져닝 모드는 Data Stream 생성시 샤드를 직접 할당하며 리소스를 관리해야 한다는 단점이 있습니다. 변동적인 트래픽으로 인해 데이터 스트림 자체에 대한 병목 현상이나 다운 타임이 발생할 수 있습니다.
 
그렇다면 이처럼 편한 온디맨드를 사용하지 않고 프로비져닝 모드를 사용해야 하는 이유는 무엇일까요?
 
그 이유는 바로 “비용”에 있습니다.
 
온디맨드 요금의 비용 항목은 다음과 같습니다.(아래 3개 항목은 제외하겠습니다.)
  • 스트림당, 시간당 0.049 USD
  • GB당 수집된 데이터(24시간 보존 포함) 0.099 USD
  • GB당 데이터 검색 0.049 USD
  • GB당 향상된 팬아웃 데이터 검색 0.062 USD
  • GB당 월별 데이터 저장(24시간 초과, 최대 7일) 0.114 USD
  • GB당 월별 데이터 저장(7일 이상) 0.025 USD
    •  
프로비저닝 요금의 비용 항목은 다음과 같습니다.
  • 샤드 시간(초당 1MB 수신, 초당 2MB 송신) 0.0185 USD
  • PUT 페이로드 단위, 1백만 유닛당 0.0204 USD
  • 데이터 보존 기간 연장(최대 7일), 샤드 시간당 0.0247 USD
  • 장기 데이터 보존(7일 이상 보존된 데이터), GB-월 기준 0.025 USD
  • 장기 데이터 검색(7일 이상 보존된 데이터), GB 기준 0.0258 USD
  • GB당 향상된 팬아웃 데이터 검색 0.016 USD
  • 소비자 샤드 시간당 향상된 팬아웃 0.0185 USD
 
조건은 두 선택지 모두 똑같습니다.
 
💡
데이터를 시간당 1GB를 처리하며, 데이터 수집만을 고려하고 향상된 옵션을 선택하지 않으며 24시간 이내에 데이터가 처리되는 Data Stream
 
위 비용 항목과 조건들을 토대로 온디맨드의 월 비용은
  • (0.049 USD(스트림당, 시간당) + 0.099 USD(GB 당 수집된 데이터) ) = 0.148 USD
  • 0.148 * 24 * 30 = 106.56 usd로 한화 약 142,814.39원입니다.
 
그렇다면 프로비저닝 요금은 어떨까요? 위 조건에 샤드를 1개만 사용한다고 했을 때 월 비용은
  • 초당 1MB 수신, 초당 2MB 송신이므로, 총 처리량은 1MB + 2MB = 3MB입니다. 1GB는 1024MB이므로, 1GB를 처리하기 위해서는 1024MB / 3MB = 약 341.33초가 필요합니다.
  • 1시간은 3600초이므로, 1GB를 처리하는 데 필요한 시간은 341.33초 / 3600초 = 0.0947시간, 샤드 시간당 비용은 0.0185 USD입니다.
  • 1GB를 처리하는 데 드는 비용은 0.0947시간 × 0.0185 USD/시간 = 0.00175 USD 입니다.
  • 한 달 동안의 총 비용은 720GB × 0.00175 USD/GB = 1.26 USD 입니다.
 
월 최소치의 수집 비용만을 고려했을 때 비교가 되지 않게 프로비저닝으로 사용하는 것이 저렴하기 때문에 일반적으로 변동성이 너무 크지 않고 확장성을 크게 고려해야 하는 상황이 아니라면 프로비저닝 모드를 사용하는 것이 권장됩니다.
 

Data Stream Quotas and limits(할당량과 제한)

 

Quotas and limits

 
온디맨드 모드
프로비저닝 모드
데이터 스트림 수
기본적으로 온디맨드 용량 모드로 최대 50개의 데이터 스트림을 만들 수 있습니다.
계정 내 프로비저닝 모드에서 스트림 수에 대한 상한 할당량은 없습니다.
샤드의 수
상한은 없습니다. 샤드 수는 수집된 데이터 양과 필요한 처리량 수준에 따라 달라집니다.
- 다음 AWS 리전 (US East, US West, Europe)의 경우 기본 500개 할당됩니다. - 그 외 리전의 경우 기본 샤드 할당량은 AWS 계정 당 200개 입니다.
데이터 스트림 처리량
기본적으로 온디맨드로 생성된 새 데이터 스트림은 - 쓰기 처리량이 4MB/s이고 - 읽기 처리량이 8MB/s입니다. 트래픽이 증가함에 따라 온디맨드 모드의 데이터 스트림은 - 쓰기 처리량이 200MB/s이고 - 읽기 처리량이 400MB/s까지 확장됩니다.
- 각 샤드는 최대 1MB/초 또는 1,000개 레코드/초 쓰기 처리량 또는 - 최대 2MB/초 또는 2,000개 레코드/초 읽기 처리량을 지원할 수 있습니다.
데이터 페이로드 크기
이전 레코드의 데이터 페이로드의 최대 크기 base64-encoding는 1MB입니다.
온디맨드와 같음
GetRecords transaction size
- GetRecords는 단일 샤드에서 호출당 최대 10MB의 데이터와 - 호출당 최대 10,000개의 레코드를 검색할 수 있습니다. - 각 호출은 GetRecords하나의 읽기 트랜잭션으로 계산됩니다. - 각 샤드는 초당 최대 5개의 읽기 트랜잭션을 지원할 수 있습니다. - 각 읽기 트랜잭션은 트랜잭션당 최대 10MB의 할당량으로 최대 10,000개의 레코드를 제공할 수 있습니다.
온디맨드와 같음
샤드당 데이터 읽기 속도
각 샤드는 GetRecords를 통해 초당 최대 2MB의 총 데이터 읽기 속도를 지원할 수 있습니다 . 호출이 GetRecords10MB를 반환하면 다음 5초 내에 수행되는 후속 호출은 예외를 throw합니다.
온디맨드와 같음
데이터 스트림당 등록된 소비자 수
각 데이터 스트림에 대해 최대 20개의 등록된 Consumer를 만들 수 있습니다(향상된 팬아웃 제한).
온디맨드와 같음
프로비저닝 모드와 주문형 모드 간 전환
AWS 계정의 각 데이터 스트림에 대해 24시간 내에 온디맨드 및 프로비저닝 용량 모드를 두 번 전환할 수 있습니다.
온디맨드와 같음
 

API Limits

 
Kinesis Data Streams API 작업은 속도 제한이 있습니다. 지역별 AWS 계정당 적용됩니다.
 

KDS 제어 평면 API 제한

 
하단 참조.
 
 

KDS 데이터 플레인 API 제한

 
API
API 호출 제한
탑재량 제한
추가 세부 사항
GetRecords
5TPS
- 기능 호출 당 최대 레코드 반환 수 10,000개 - 반환할 수 있는 최대 데이터 크기 10MB
- 호출 후 5초 안에 재 호출 시  ProvisionedThroughputExceededException. - 프로비저닝 된 처리량이 충분하지 않다면 다음 1초 이내 호출 시 ProvisionedThroughputExceededException.
GetShardIterator
5TPS
- 요청이 반환된 후 5분 이내에 만료 - 너무 자주 호출 하면 ProvisionedThroughputExceededException 발생
PutRecord
1000TPS
- 초당 최대 1,000개 쓰기 작업 - 초당 최대 1MB 쓰기 작업
PutRecords
- 각 PutRecords 요청은 최대 500개의 레코드를 지원할 수 있습니다. - 요청의 각 레코드는 최대 1MB까지 가능하며, 파티션 키를 포함하여 전체 요청에 대해 최대 5MB까지 가능합니다. - 각 샤드는 초당 최대 1,000개의 레코드를 쓸 수 있으며, 최대 데이터 쓰기 총량은 초당 1MB입니다.
SubscribeToShard
샤드당 등록된 소비자당 1초에 한 번씩 SubscribeToShard를 호출할 수 있습니다.
성공적인 호출 후 5초 이내에 동일한 ConsumerARN과 ShardId로 SubscribeToShard를 다시 호출하면 ResourceInUseException이 발생합니다.
 

Increasing Quota(할당량 증가)

 
리전 혹은 계정별 할당된 Data Stream 기본 할당량에 조정이 필요하면 Supports를 통해 할당량을 증가하거나 조정할 수 있습니다.
 

개발 환경

 
Java 1.7(Java SE 7 JDK) 이상
 

보안

 
  • Enable server-side encryption(서버측 암호화 옵션)
    •  
    • 서버 측 암호화를 사용하면 Kinesis 스트림 제작자와 소비자가 마스터 키나 암호화 작업을 관리할 필요가 없습니다. 데이터는 Kinesis Data Streams 서비스에 들어오고 나갈 때 자동으로 암호화되므로 저장 중인 데이터가 암호화됩니다. AWS KMS는 서버 측 암호화 기능에서 사용하는 모든 마스터 키를 제공합니다. AWS KMS를 사용하면 AWS에서 관리하는 Kinesis용 CMK, 사용자가 지정한 AWS KMS CMK 또는 AWS KMS 서비스로 가져온 마스터 키를 쉽게 사용할 수 있습니다.
    • 데이터 스트림을 암호화하고 다른 주체에게 액세스를 공유할 때 AWS KMS 키에 대한 키 정책과 외부 계정의 IAM 정책 모두에서 권한을 부여해야 합니다.
    •  
  • 비용
    • WS에서 관리하는 Kinesis용 CMK(별칭 = aws/kinesis)는 무료입니다.
    • 사용자가 생성한 KMS 키에는 KMS 키 비용이 적용됩니다.
 
  • VPC와 통합
    •  
      VPC 엔드포인트를 사용하면 Amazon VPC와 Kinesis Data Streams 간의 트래픽이 Amazon VPC network 격리 수준을 벗어나지 못하도록 만들 수 있습니다. 시작하기 위해 스트림, Producer 또는 Consumer에 대한 설정을 변경할 필요가 없습니다. Amazon VPC 리소스에서 Kinesis Data Streams 트래픽이 인터페이스 VPC 엔드포인트를 통하도록 인터페이스 VPC 엔드포인트를 만들기만 하면 됩니다.
       
Share article
RSSPowered by inblog