Amazon Kinesis Data Stream은 Real-time / Fully managed / Scalable를 자랑하는 서비스이다. 완전 관리형이라 인프라 관리를 안 해도 되기 때문에 신경 써야 할 부분이 상당히 적다.
기능은 간단하게 여러 Producer로부터 데이터를 받아 stream에 저장하고, 여러 Consumer에게 해당 데이터를 전달한다.
이때 전달되는 데이터는 kinesis에서 Record
단위로 처리한다. 스트림은 한 개 이상의 샤드로 구성되어 있는데 데이터는 PartitionKey
로 샤드를 특정 지어 그곳에 저장된다.
샤드는 Kinesis Stream의 용도에 맞게 랜덤 하게 분배하거나, 특정 샤드에 보내도록 PartitionKey를 신경 써야 한다.
이를 읽어가는 consumer는 KCL(Kinesis Client Library)를 이용하거나 Data Analytics, Data Firehose, Lambda 등의 aws에서 지원하는 서비스를 이용할 수 있다.
큰 그림은 이렇고, 실제 가장 핵심인 Record를 더 자세히 보면 이런 값을 포함한다.
- Sequence Number: 샤드 내에서 순서를 보장하기 위한 번호
- Partition Key: 최대 256Byte 문자열로 최종적으로 MD5 해시로 샤드에 매핑된다.
- Data BLOB (최대 1MB)
put record / get record
kinesis stream에 데이터를 넣을 때 필요한 파라미터는 다음과 같다. stream-name과 data, partition-key까지 필수로 요구된다.
$ aws kinesis put-record help
SYNOPSIS
put-record
--stream-name <value>
--data <value>
--partition-key <value>
[--explicit-hash-key <value>]
[--sequence-number-for-ordering <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]
데이터를 이렇게 추가하면 shardId와 sequenceNumber를 반환한다. shardId는 partition-key로 의해 연산된 샤드 값이다.
kiensis stream에서 데이터를 꺼내올 때는 shard iterator가 필요하다. shrad iterator로 어떤 데이터를 꺼내올지 정할 수 있다. 위에 데이터를 넣을 때 받았던 유니크한 데이터 값인 sequenceNumber를 기준으로 이어서 받을 수도 있고, 처음부터 받을 수도 있고, 가장 최근 것만 받을 수도 있다.
shard iterator를 받아오기 위해 필요한 파라미터를 보면 stream-name, shard-id와 함께 어떤 기준의 iterator를 받아올지 shard-iterator-type을 같이 넘긴다.
$ aws kinesis get-shard-iterator help
SYNOPSIS
get-shard-iterator
--stream-name <value>
--shard-id <value>
--shard-iterator-type <value>
[--starting-sequence-number <value>]
[--timestamp <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]
이렇게 해서 받은 shard-iterator를 사용해서 실제 데이터를 조회할 수 있다.
$ aws kinesis get-records help
SYNOPSIS
get-records
--shard-iterator <value>
[--limit <value>]
[--cli-input-json <value>]
[--generate-cli-skeleton <value>]
속도
- 쓰기: 1000 TPS, 1MB/초
- 읽기: 5 TPS, 2 MB/초
Producer, Consumer의 상태에 따라 샤드를 split/merge 하여 속도를 제어할 수 있다. 특정 샤드를 split 하면 해당 샤드는 상위 샤드가 되고, 하위 샤드가 추가된다.
결국 샤드 수를 늘릴수록 성능이 좋아지기 때문에 필요한 성능에 따라 샤드 수를 결정해야 한다. kinesis stream 생성 UI에서는 친절히 아래와 같은 식으로 계산하라고 나와있다.
number_of_shards = max(incoming_write_bandwidth_in_KiB/1024, outgoing_read_bandwidth_in_KiB/2048)
고가용성
Record는 PartitionKey에 의해 샤드에 저장되는데, 이 샤드는 세 곳의 Availability Zone에 저장되어 고가용성을 보장한다.
순서
Record가 저장되는 샤드에는 Record Sequence가 있어서 순서가 보장된다.
따라서 Producer에서 순서가 보장되어야 하는 데이터들은 동일한 샤드를 향하도록 PartitionKey를 정해야 한다.
순서를 보장해서 읽어야 하는 경우, 샤드 split으로 상위 - 하위 샤드가 있다면 상위 샤드를 먼저 꺼내야 한다. 그 후에 하위 샤드를 읽어야 생성된 데이터들의 순서가 보장되는데, 직접 구현할 필요 없이 이런 기능들이 구현되어 있는 KCL(Kinesis Client Library)를 사용하면 편리하다.
단, KCL을 사용하면 kinesis 외에도 상태 관리를 위한 DynanoDB, 지표 수집을 위한 CloudWatch 기능이 추가되어 해당 권한이 필요하다.
순서 보장이 필요하지 않은 단순한 버퍼 역할이라면 PartitionKey를 랜덤으로 설정해서 여러 샤드에 고루 분배되도록 설정한다.
보존 기간
기본 하루이고 최대 7일까지 설정할 수 있어 replay 할 수 있다.
'aws' 카테고리의 다른 글
AWS IAM 보안 정책 (0) | 2020.04.07 |
---|---|
DNS 과정과 route 53 사용법 (0) | 2020.04.04 |
Security Group vs Network ACL 정리 (0) | 2020.04.02 |
AWS storage type (0) | 2020.03.31 |
AWS VPC(Virtual Private Cloud) 구성 (0) | 2019.10.24 |
댓글