Amazon Kinesis Data Streams FAQ

샤드에는 스트림에 일련의 데이터 레코드가 있습니다. Kinesis 데이터 스트림의 기본 처리량 단위 역할을 합니다. 샤드는 쓰기에 대해 1MB/초 및 초당 1,000개의 레코드를 지원하고 읽기의 경우 2MB/초를 지원합니다. 샤드 제한은 예측 가능한 성능을 보장하므로 매우 안정적인 데이터 스트리밍 워크플로우를 쉽게 설계하고 운영할 수 있습니다. 생산자는 데이터 레코드를 샤드에 넣고 소비자는 샤드에서 데이터 레코드를 가져옵니다. 소비자는 병렬 데이터 처리 및 저장된 정확한 순서로 데이터를 소비하기 위해 샤드를 사용합니다. 쓰기 및 읽기가 샤드 제한을 초과하면 생산자 및 소비자 애플리케이션에서 제한을 받게 되며 이는 재시도를 통해 처리할 수 있습니다.

레코드는 Amazon Kinesis 데이터 스트림에 저장되는 데이터의 단위입니다. 레코드는 시퀀스 번호, 파티션 키, 데이터 Blob으로 구성됩니다. 데이터 Blob은 사용자의 데이터 생산자가 데이터 스트림에 추가한 대상 데이터입니다. 데이터 Blob의 최대 크기(Base64로 인코딩하기 전 데이터 페이로드)는 1메가바이트(MB)입니다.

파티션 키는 레코드를 데이터 스트림의 다른 샤드에 격리하고 라우팅하는 데 사용됩니다. 파티션 키는 Kinesis 데이터 스트림에 데이터가 추가되는 동안 데이터 생산자가 지정합니다. 예를 들어, 샤드가 2개 있는 데이터 스트림이 있다고 가정해 보겠습니다(샤드 1과 샤드 2). 파티션 키 2개(키 A와 키 B)를 사용하도록 데이터 생산자를 구성하여 키 A가 있는 모든 레코드는 샤드 1에 추가하고 키 B가 있는 모든 레코드는 샤드 2에 추가할 수 있습니다.

시퀀스 번호는 각 레코드에 대한 고유 식별자입니다. Amazon Kinesis 데이터 스트림에 데이터를 추가하기 위해 데이터 생산자가 PutRecord 또는 PutRecords 작업을 호출할 때 Amazon Kinesis에서 시퀀스 번호를 할당합니다. 동일한 파티션 키의 시퀀스 번호는 일반적으로 시간이 지남에 따라 증가합니다. PutRecord 또는 PutRecords 요청 사이의 시간 간격이 길어질수록 시퀀스 번호도 커집니다.

Kinesis Data Streams의 용량 모드는 데이터 스트림에 대해 용량을 관리하고 사용량에 요금이 부과되는 방식을 결정합니다. 프로비저닝 모드와 온디맨드 모드 중에서 선택할 수 있습니다. 프로비저닝 모드에서는 데이터 스트림의 샤드 수를 지정합니다. 데이터 스트림의 총 용량은 샤드 용량의 합계입니다. 필요에 따라 데이터 스트림의 샤드 수를 늘리거나 줄일 수 있으며 샤드 수에 대해 시간당 요금을 지불하면 됩니다. 온디맨드 모드에서 AWS는 샤드를 관리하여 필요한 처리량을 제공합니다. 사용한 실제 처리량에 대해서만 비용을 지불하면 되며, Kinesis Data Streams는 워크로드 처리량 요구 사항이 증가하거나 감소함에 따라 자동으로 수용합니다. 모든 Kinesis Data Streams 쓰기 및 읽기 API는 확장 보존 및 향상된 팬아웃과 같은 옵션 기능과 함께 두 용량 모드에서 모두 지원됩니다.

온디맨드 모드는 예측할 수 없고 매우 가변적인 트래픽 패턴이 있는 워크로드에 가장 적합합니다. AWS에서 사용자를 대신하여 용량을 관리하거나 처리량당 지불 요금을 선호하는 경우 이 모드를 사용해야 합니다. 프로비저닝된 모드는 용량 요구 사항을 쉽게 예측할 수 있는 예측 가능한 트래픽에 가장 적합합니다. 데이터가 분할된 데이터베이스에 분산되는 방식을 세밀하게 제어하려면 프로비저닝된 모드 사용을 고려해야 합니다. 프로비저닝 모드는 사용하는 애플리케이션이 전체 처리 속도를 높이기 위해 더 많은 읽기 처리량을 가질 수 있도록 추가 샤드를 프로비저닝하려는 경우에도 적합합니다.

예. 온디맨드 모드와 프로비저닝 모드 간을 하루에 두 번 전환할 수 있습니다. 프로비저닝된 모드에서 온디맨드 모드로 전환할 때 데이터 스트림의 샤드 수는 동일하게 유지되며 그 반대의 경우도 마찬가지입니다. 프로비저닝된 용량 모드에서 온디맨드 용량 모드로 전환하면 데이터 스트림은 전환 전에 샤드 수를 그대로 유지합니다. 그러나 이 시점부터 Kinesis Data Streams는 데이터 트래픽을 모니터링하고 트래픽 증가 또는 감소에 따라 온디맨드 데이터 스트림의 샤드 수를 늘리거나 줄입니다.

PutRecord 및 PutRecords 작업, KPL 또는 Amazon Kinesis Agent를 통해 Kinesis 데이터 스트림에 데이터를 추가할 수 있습니다.

PutRecord 작업에서는 API 호출 시 단일 데이터 레코드를 사용할 수 있고 PutRecords 작업에서는 API 호출 시 여러 데이터 레코드를 사용할 수 있습니다. 자세한 내용은 PutRecord 및 PutRecords를 참조하세요.

KPL은 사용이 간편하고 쉽게 구성 가능한 라이브러리로, Amazon Kinesis 데이터 스트림에 데이터를 추가하는 데 도움이 됩니다. KPL은 간편한 비동기식의 안정적인 인터페이스를 제공하여 최소한의 고객 리소스로 높은 생산자 처리량을 신속하게 달성하는 데 도움이 됩니다.

Amazon Kinesis 에이전트는 사전 구축된 Java 애플리케이션으로서, 데이터를 수집하여 Amazon Kinesis 데이터 스트림으로 전송하는 간편한 방법을 제공합니다. 에이전트는 웹 서버, 로그 서버, 데이터베이스 서버 등과 같은 Linux 기반 서버 환경에 설치할 수 있습니다. 에이전트에서는 특정 파일을 모니터링하고 데이터를 데이터 스트림으로 지속적으로 전송합니다. 자세한 내용은 Writing with Agents를 참조하세요.

PutRecord 또는 PutRecords 직접 호출의 필수 파라미터는 데이터 Blob, 파티션 키 및 데이터 스트림 이름입니다. 데이터 Blob 크기(Base64 인코딩 전)와 파티션 키는 데이터 스트림 내 샤드 수에 의해 결정되는 Amazon Kinesis 데이터 스트림의 데이터 처리량으로 계산됩니다.

소비자는 Kinesis Data Streams의 모든 데이터를 처리하는 애플리케이션입니다. 공유 팬아웃 및 향상된 팬아웃 소비자 유형 중에서 선택하여 Kinesis 데이터 스트림에서 데이터를 읽을 수 있습니다. 공유 팬아웃 소비자는 모두 샤드의 2MB/초의 읽기 처리량과 초당 5개의 트랜잭션 제한을 공유하며 GetRecords API를 사용해야 합니다. 향상된 팬아웃 소비자는 2MB/초의 읽기 처리량을 할당하므로 여러 소비자가 다른 소비자와 읽기 처리량을 경합하지 않고도 동일한 스트림에서 병렬로 데이터를 읽을 수 있습니다. 향상된 팬아웃 소비자와 함께 SubscribetoShard API를 사용해야 합니다. 데이터 스트림에 둘 이상의 소비자를 추가하려는 경우 향상된 팬아웃 소비자를 사용하는 것이 좋습니다.

AWS Lambda, Amazon Managed Service for Apache Flink 및 AWS Glue와 같은 관리형 서비스를 사용하여 Kinesis Data Streams에 저장된 데이터를 처리할 수 있습니다. 이러한 관리형 서비스는 기본 인프라의 프로비저닝 및 관리를 관리하므로 사용자는 비즈니스 로직 작성에 집중할 수 있습니다. 또한 Kinesis Data Streams에 저장된 데이터를 Kinesis Data Firehose와의 사전 구축된 통합을 사용하여 Amazon S3, Amazon OpenSearch Service, Amazon Redshift 및 사용자 지정 HTTP 엔드포인트로 전송할 수 있습니다. 또한 Amazon Kinesis Client Library, 사전 구축된 라이브러리 또는 Amazon Kinesis Data Streams API를 사용하여 사용자 지정 애플리케이션을 구축할 수도 있습니다.

Java, Python, Ruby, Node.js 및 .NET용 KCL은 Amazon Kinesis 데이터 스트림의 데이터를 읽고 처리하는 Amazon Kinesis 애플리케이션을 손쉽게 구축할 수 있도록 지원하는 사전 구축 라이브러리입니다.

KCL은 데이터 스트림 볼륨 변화에 따른 조정, 스트리밍 데이터 로드 밸런싱, 분산 서비스 조직화 및 내결함성 있는 데이터 처리와 같은 복잡한 문제를 처리합니다. KCL을 사용하면 애플리케이션을 개발하는 동안 비즈니스 로직에 집중할 수 있습니다. KCL에 대한 자세한 내용은 여기의 Kinesis Data Streams 설명서를 참조하세요.

SubscribeToShard API는 클라이언트의 요청 주기 없이 영구 연결을 통해 샤드의 데이터를 소비자에게 푸시하는 고성능 스트리밍 API입니다. SubscribeToShard API는 일반적으로 70밀리초 이내에 새 데이터가 샤드에 도착할 때마다 등록된 소비자에게 데이터를 전달하기 위해 HTTP/2 프로토콜을 사용하여 GetRecords API에 비해 약 65% 더 빠른 전달을 제공합니다. 소비자는 다수의 등록된 소비자가 동일한 샤드에서 읽는 경우에도 고속 전송의 이점을 누릴 수 있습니다.

향상된 팬아웃은 Kinesis Data Streams 소비자의 선택적 기능으로, 소비자와 샤드 간에 논리적 2MB/초의 처리량 파이프를 제공합니다. 사용자는 이 기능을 사용하여 고성능을 유지하는 동시에 데이터 스트림을 병렬로 읽는 소비자 수를 확장할 수 있습니다.

단일 스트림에서 병렬로 데이터를 검색하는 소비자가 다수이거나 다수일 예정인 경우 또는 SubscribeToShard API를 사용하여 생산자와 소비자 간에 200밀리초 미만의 데이터 전송 속도를 제공해야 하는 소비자가 한 명 이상인 경우 향상된 팬아웃을 사용해야 합니다.

소비자는 SubscribeToShard API로 데이터를 검색하여 향상된 팬아웃을 사용합니다. 등록된 소비자의 이름이 SubscribeToShard API 내에서 사용되며 소비자는 이를 통해 등록된 소비자에게 제공된 향상된 팬아웃의 이점을 활용할 수 있습니다.

예. 다수의 사용자가 향상된 팬아웃을 사용하는 동안 다른 사용자는 향상된 팬아웃을 사용하지 않도록 설정할 수 있습니다. 향상된 팬아웃의 사용은 기존 GetRecords 사용량에 대한 샤드 제한에 영향을 미치지 않습니다.

예. SubscribeToShard를 사용하려면 소비자를 등록해야 하며 이를 통해 향상된 팬아웃이 활성화됩니다. 기본적으로 소비자는 SubscribeToShard를 통해 데이터를 검색할 때 자동으로 향상된 팬아웃을 사용하게 됩니다.

온디맨드 모드에서 생성된 새 데이터 스트림의 할당량은 초당 4MB이고 쓰기에 대해 초당 4,000개의 레코드가 있습니다. 기본적으로 이러한 스트림은 쓰기에 대해 초당 최대 200MB와 초당 200,000개의 레코드로 자동 확장됩니다.

온디맨드 모드의 데이터 스트림은 지난 30일 동안 관찰된 이전 최대 쓰기 처리량의 두 배까지 수용할 수 있습니다. 데이터 스트림의 쓰기 처리량이 새로운 피크에 도달하면 Kinesis Data Streams는 스트림의 용량을 자동으로 확장합니다. 예를 들어 데이터 스트림에 10MB/초에서 40MB/초 사이의 쓰기 처리량이 있는 경우 Kinesis Data Streams를 사용하면 최대 처리량인 80MB/초의 두 배로 쉽게 버스트할 수 있습니다. 따라서 동일한 데이터 스트림이 50MB/초의 새로운 피크 처리량을 유지하는 경우 데이터 스트림은 100MB/초의 쓰기 처리량을 수집하기에 충분한 용량이 있는지 확인합니다. 그러나 15분 내에 트래픽이 이전 피크의 두 배 이상 증가하면 “ProvisionedThroughputExceeded” 예외가 표시됩니다. 이러한 제한된 요청을 다시 시도해야 합니다.

온디맨드 모드의 총 읽기 용량은 쓰기 처리량에 비례하여 증가하여 사용하는 애플리케이션이 수신 데이터를 실시간으로 처리하기에 항상 적절한 읽기 처리량을 갖도록 합니다. GetRecords API를 사용하면 데이터를 읽을 수 있는 쓰기 처리량이 두 배 이상 증가합니다. 애플리케이션이 가동 중단 시간에서 복구해야 하는 시기를 따라 잡을 수 있는 충분한 공간을 확보할 수 있도록 GetRecord API와 함께 한 소비자를 사용하는 것이 좋습니다. 사용 중인 응용 프로그램을 두 개 이상 추가하려면 SubscribetoShard API를 사용하여 데이터 스트림에 최대 20명의 소비자를 추가할 수 있는 향상된 팬아웃을 사용해야 하며 각 소비자에는 전용 처리량이 있습니다.

프로비저닝된 모드에서 Kinesis 데이터 스트림의 처리량은 데이터 스트림 내의 샤드 수를 늘려 제한 없이 확장하도록 설계되었습니다.

SplitShard API를 사용하여 기존 샤드를 분할하여 프로비저닝된 모드에서 Kinesis 데이터 스트림 용량을 스케일 업할 수 있습니다. MergeShard API를 사용하여 두 샤드를 병합하면 용량을 스케일 다운할 수 있습니다. 또는 UpdateHardCount API를 사용하여 스트림 용량을 특정 샤드 수로 확장(또는 축소) 할 수 있습니다.

Kinesis 데이터 스트림의 처리량은 데이터 스트림 내의 샤드 수에 의해 결정됩니다. 프로비저닝된 모드에서 아래 단계를 따라 데이터 스트림에서 초기에 필요한 샤드 수를 추정해 보십시오. 리샤딩을 통해 데이터 스트림 내의 샤드 수를 동적으로 조정할 수 있습니다.

데이터 스트림에 작성된 레코드의 평균 크기는 킬로바이트(KB) 단위로 추정합니다(최대 1KB 단위로 반올림).(average_data_size_in_KB)

데이터 스트림에 작성된 초당 레코드 수(number_of_records_per_second)를 추정합니다.

해당 데이터 스트림의 데이터를 동시에 독립적으로 사용할 Amazon Kinesis 애플리케이션의 수를 결정합니다(number_of_consumers).

수신되는 쓰기 대역폭을 KB 단위로 계산합니다(incoming_write_bandwidth_in_KB). 이는 average_data_size_in_KB와 number_of_records_per_second를 곱한 값과 동일합니다.

발신되는 읽기 대역폭을 KB 단위로 계산합니다(outgoing_read_bandwidth_in_KB). 이는 incoming_write_bandwidth_in_KB와 number_of_consumers를 곱한 값과 동일합니다.

그런 다음 다음 공식을 사용하여 데이터 스트림에 필요한 초기 샤드 수(number_of_shards)를 계산할 수 있습니다. number_of_shards = 최대(incoming_write_bandwidth_in_KB/1000, outgoing_read_bandwidth_in_KB/2000)

Kinesis 데이터 스트림의 처리량은 제한 없이 확장할 수 있도록 설계되었습니다. 기본 샤드 할당량은 미국 동부(버지니아 북부), 미국 서부(오레곤), 유럽(아일랜드) AWS 리전에서 스트림당 샤드 500개입니다. 그 외에 다른 모든 리전의 기본 샤드 할당량은 스트림당 샤드 200개입니다. AWS Service Quotas 콘솔을 사용하여 샤드 할당량을 증가를 요청할 수 있습니다.

프로비저닝된 모드에서 Kinesis 데이터 스트림의 용량 제한은 데이터 스트림 내의 샤드 수에 의해 결정됩니다. 데이터 처리량 또는 PUT 레코드 수로 인해 용량 제한이 초과될 수 있습니다. 용량 제한이 초과된 경우 PUT 데이터 호출은 거부되며 ProvisionedThroughputExceeded 예외가 발생합니다. 데이터 스트림의 입력 데이터 속도가 일시적으로 증가하여 용량 제한이 초과된 경우, 데이터 생산자가 다시 시도하여 요청을 완료하게 됩니다. 데이터 스트림의 입력 데이터 속도가 지속적으로 증가하여 용량 제한이 초과된 경우, 데이터 스트림 내 샤드 수를 늘려 PUT 데이터 호출이 계속 이루어질 수 있도록 충분한 용량을 확보해야 합니다. 두 가지 경우 모두 Amazon CloudWatch 지표를 통해 데이터 스트림의 입력 데이터 속도 변경 사항 및 ProvisionedThroughputExceeded 예외 발생에 대해 알아볼 수 있습니다.

프로비저닝된 모드에서 Kinesis 데이터 스트림의 용량 제한은 데이터 스트림 내의 샤드 수에 의해 결정됩니다. 데이터 처리량 또는 읽기 데이터 호출 수로 인해 제한이 초과될 수 있습니다. 용량 제한이 초과된 경우 읽기 데이터 호출은 거부되며 ProvisionedThroughputExceeded 예외가 발생합니다. 데이터 스트림의 출력 데이터 속도가 일시적으로 증가하여 용량 제한이 초과된 경우, Amazon Kinesis 애플리케이션에서 다시 시도하여 결국 요청이 완료됩니다. 데이터 스트림의 출력 데이터 속도가 지속적으로 증가하여 용량 제한이 초과된 경우, 데이터 스트림 내의 샤드 수를 늘려 읽기 데이터 호출이 계속 이루어질 수 있도록 충분한 용량을 확보해야 합니다. 두 경우 모두 Amazon CloudWatch 지표를 통해 데이터 스트림의 출력 데이터 속도 변경 사항 및 ProvisionedThroughputExceeded 예외 발생을 확인할 수 있습니다.

기본 보존 기간인 24시간은 간헐적인 처리 지연으로 인해 실시간 데이터를 따라잡아야 하는 시나리오에 적용됩니다. 보존 기간이 7일이면 최대 7일 동안 데이터를 다시 처리해서 잠재적 다운스트림 데이터 손실을 해결할 수 있습니다. 7일 이상, 최대 365일 이내의 장기 데이터 보존을 사용하면 알고리즘 백 테스트, 데이터 스토어 백필, 감사 등의 사용 사례에 오래된 데이터를 다시 처리할 수 있습니다.

예. 동일한 getShardIterator, GetRecords, SubscribeToShard API를 사용하여 7일 이상 보존된 데이터를 읽을 수 있습니다. 소비자는 반복자를 스트림 내의 원하는 위치로 옮기고, (열려 있거나 닫힌) 샤드 맵을 검색하여 기록을 읽을 수 있습니다.

예. ListShards, GetRecords, SubscribeToShard API가 향상되었습니다. ListShards API에서 제공되는 TimeStamp 파라미터의 새로운 필터링 옵션을 사용하여 샤드 맵을 효율적으로 검색하고 오래된 데이터를 읽는 성능을 개선할 수 있습니다. TimeStamp 필터를 사용하는 애플리케이션은 데이터를 다시 처리하려는 시점에 샤드를 검색 및 나열하기 때문에 트림 면에서 시작할 필요가 없습니다. GetRecords 및 SubscribeToShards에는 새로운 필드인 ChildShards가 있어 애플리케이션이 샤드 맵을 다시 탐색할 필요 없이 닫힌 샤드에서 데이터 읽기를 마치면 하위 샤드를 빠르게 검색할 수 있습니다. 샤드를 빠르게 검색하기 때문에 데이터 보존 기간과 관계없이 모든 용량의 스트림에서 애플리케이션의 컴퓨팅 리소스를 효율적으로 사용할 수 있습니다.

데이터 보존 기간을 늘리거나 스트림 용량을 정기적으로 확장하고 싶다면 이러한 향상된 API 구성 요소를 사용하는 것이 좋습니다. 스트림 확장 작업은 기존 샤드를 닫고 새로운 하위 샤드를 엽니다. 모든 열린 샤드 및 닫힌 샤드의 데이터는 보존 기간이 끝날 때까지 보존됩니다. 그러므로 샤드의 총 개수는 보존 기간이 길어지고 확장 작업이 여러 개일 때 비례적으로 증가합니다. 샤드 맵에서 샤드 개수가 증가하기 때문에 ListShards의 TimeStamp 필드, GetRecords의 ChildShards 필드, SubscribeToShard API를 사용하여 데이터 검색 시 샤드를 효율적으로 검색해야 합니다. 이 기능을 사용하려면 표준 소비자의 경우 KCL을 최신 버전인 1.x로, 향상된 팬아웃 소비자의 경우 2.x으로 업그레이드해야 합니다.

예. Kinesis Data Streams의 클라이언트는 AWS Glue의 서버리스 기능인 AWS Glue Schema Registry를 KPL 및 KCL 또는 AWS Java SDK의 AWS Glue Schema Registry API를 통해 사용할 수 있습니다. 스키마 레지스트리는 추가 비용 없이 사용할 수 있습니다. 

스키마 레지스트리 사용 설명서를 참조하여 시작하고 자세히 알아보세요.

데이터 스트림 처리량을 변경하는 방법은 두 가지가 있습니다. UpdateShardCount API 또는 AWS 관리 콘솔을 사용하여 데이터 스트림의 샤드 수를 확장하거나, 데이터 스트림 내 샤드 수를 조정(리샤딩)하여 Amazon Kinesis 데이터 스트림의 처리량을 변경할 수 있습니다.

일반적인 확장 요청은 완료하는 데 몇 분 정도 소요됩니다. 큰 규모의 확장 요청은 적은 규모보다 시간이 좀 더 걸립니다.

예. UpdateShardCount 또는 리샤딩을 사용하여 데이터 스트림의 처리량을 변경하거나 Kinesis Data Streams가 온디맨드 모드에서 자동으로 변경할 때 Kinesis 데이터 스트림에 데이터를 계속 추가하고 읽을 수 있습니다.

Amazon Kinesis Data Streams 관리 콘솔은 Kinesis 데이터 스트림의 데이터 입력 및 출력 처리량과 같은 핵심 운영 및 성능 지표를 표시합니다. 또한, Kinesis Data Streams는 Amazon CloudWatch와 통합되므로 데이터 스트림과 해당 데이터 스트림 내 샤드에 대한 CloudWatch 지표를 수집, 확인 및 분석할 수 있습니다. Kinesis Data Streams 지표에 대한 자세한 내용은 Monitoring Amazon Kinesis Data Streams with Amazon CloudWatch를 참조하세요.

모든 스트림 수준의 지표는 무료로 제공됩니다. 모든 활성화된 샤드 수준의 지표는 Amazon CloudWatch 요금에 따라 비용이 부과됩니다.

Kinesis Data Streams는 AWS 서비스 및 리소스에 대한 사용자 액세스를 안전하게 제어하는 데 도움이 되는 서비스인 AWS Identity and Access Management(IAM)와 통합됩니다. 예를 들어 특정 사용자 또는 그룹만 데이터 스트림에 데이터를 추가할 수 있도록 허용하는 정책을 생성할 수 있습니다. 또한 리소스 기반 정책을 데이터 스트림 또는 등록된 소비자에 연결하여 리소스 수준에서 액세스를 제어할 수 있습니다. 데이터 스트림의 액세스 관리 및 제어에 대한 자세한 내용은 Controlling Access to Amazon Kinesis Data Streams Resources using IAM을 참조하세요.

IAM 수임 역할 또는 리소스 기반 정책을 사용하여 다른 계정과 액세스를 공유할 수 있습니다. 크로스 계정 AWS Lambda 함수와 액세스를 공유하려면 리소스 기반 정책을 데이터 스트림 또는 소비자에 연결하여 Lambda 함수의 실행 역할에 대한 액세스 권한을 부여하세요. 자세한 내용은 Amazon Kinesis에서 AWS Lambda 사용을 참조하세요.

Kinesis Data Streams는 계정의 AWS API 직접 호출을 기록하고 로그 파일을 전달하는 서비스인 Amazon CloudTrail과 통합됩니다. API 직접 호출 로깅 및 지원되는 Amazon Kinesis API 작업 목록에 대한 자세한 내용은 Logging Amazon Kinesis API calls Using Amazon CloudTrail을 참조하세요.

Kinesis Data Streams를 사용하면 더 쉬운 리소스 및 비용 관리를 위해 Kinesis 데이터 스트림에 태그를 지정할 수 있습니다. 태그는 키-값 페어로 표현되는 사용자 정의 레이블로, AWS 리소스를 정리하는 데 도움이 됩니다. 예를 들어 비용 센터별로 스트림에 태그를 지정하면, Kinesis Data Streams 비용을 비용 센터별로 분류하여 추적할 수 있습니다. Amazon Kinesis Data Streams 태깅에 대한 자세한 내용은 Tagging Your Amazon Kinesis Data Streams를 참조하세요.

기본적으로 Amazon Kinesis는 안전합니다. 계정 및 데이터 스트림 소유자만 자신이 생성한 Kinesis 리소스에 액세스할 수 있습니다. Kinesis는 데이터에 대한 액세스를 제어하기 위해 사용자 인증을 지원합니다. IAM 정책을 사용하여 사용자 및 사용자 그룹에 개별적으로 권한을 부여할 수 있습니다. HTTPS 프로토콜을 사용하는 SSL 엔드포인트를 통해 Kinesis에서 안전하게 데이터를 가져오고 추가할 수 있습니다. 추가 보안이 필요한 경우, AWS Key Management Service(AWS KMS) 키를 사용한 서버 측 암호화를 통해 데이터 스트림에 저장된 데이터를 암호화할 수 있습니다. AWS KMS를 사용하면 암호화에 AWS에서 생성한 KMS 키를 사용할 수 있으며 원하는 경우 자체 KMS 키를 AWS KMS로 가져올 수도 있습니다. 마지막으로 자체 암호화 라이브러리를 사용하여 데이터를 Kinesis에 추가하기 전에 클라이언트 측에서 데이터를 암호화할 수 있습니다.

예. VPC 엔드포인트를 생성하면 Amazon VPC에서 Kinesis Data Streams API에 프라이빗로 액세스할 수 있습니다. VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 게이트웨이 또는 VPN 연결을 사용할 필요 없이 AWS 네트워크에서 VPC와 Kinesis Data Streams 간 라우팅을 처리합니다. Kinesis Data Streams가 사용하는 최신 세대 VPC 엔드포인트는 AWS PrivateLink에서 제공합니다. 이는 탄력적 네트워크 인터페이스(ENI)를 사용하는 AWS 서비스와 VPC 내 프라이빗 IP 간에 프라이빗 연결을 지원하는 기술입니다. PrivateLink에 대해 자세히 알아보려면 PrivateLink 설명서를 참조하세요.

예, 두 가지 옵션이 있습니다. 완전관리형 기능인 서버 측 암호화를 사용하여 데이터 스트림에서 데이터를 추가하고 가져옴에 따라 자동으로 암호화하고 복호화할 수 있습니다. 또한 클라이언트 측에서 암호화하고 복호화하는 방법으로 암호화된 데이터를 데이터 스트림에 작성할 수 있습니다.

다음과 같은 이유로 클라이언트 측 암호화보다 서버 측 암호화를 선택할 수 있습니다.

• 클라이언트 측 암호화를 적용하기가 어렵습니다.
• 클라이언트 측 암호화 위에 추가 보안 계층을 적용하길 원합니다.
• 클라이언트 측 키 관리 체계를 구현하기가 어렵습니다.

Kinesis Data Streams의 서버 측 암호화는 데이터가 데이터 스트림 스토리지 계층에 쓰여지기 전에 사용자 지정 AWS KMS 키를 사용하여 자동으로 데이터를 암호화하고, 스토리지에서 데이터를 가져온 후에 복호화합니다. 암호화를 하면 데이터 스트림에 쓰기 또는 읽기 작업을 하는 사용자가 데이터 스트림의 암호화를 위해 선택된 키를 사용할 권한이 있지 않은 한, 쓰기가 불가능하고 페이로드와 파티션 키를 읽을 수 없습니다. 따라서 서버 측 암호화를 하면 데이터에 관한 내부 보안 및 규정 준수 요구 사항을 좀 더 쉽게 충족할 수 있습니다.

서버 측 암호화를 사용하면 클라이언트 측 애플리케이션(생산자 및 소비자)에서 암호화를 인식하거나 KMS 키 또는 암호화 작업을 관리할 필요가 없으며, 데이터는 Kinesis Data Streams 서비스 내에서 저장 및 전송 중에 암호화됩니다. 서버 측 암호화 기능에서 사용하는 모든 KMS 키는 AWS KMS에서 제공합니다. AWS KMS를 사용하면 AWS에서 Kinesis용으로 관리하는 KMS('원 클릭' 암호화 방법), 사용자 자체 AWS KMS 고객 관리형 키 또는 암호화를 위해 가져온 KMS 키를 손쉽게 사용할 수 있습니다.

예. 사용자 설명서에 시작 가이드가 있습니다.

그럴 수도 있습니다. 이는 암호화에 사용하는 키와 해당 키에 대한 액세스를 관장하는 권한에 따라 다릅니다.

• AWS에서 Kinesis용으로 관리하는 KMS 키(키 별칭 = aws/kinesis)를 사용하는 경우, 이 키로 암호화를 활성화하거나 비활성화하더라도 애플리케이션은 영향을 받지 않습니다.
• 다른 KMS 키, 예를 들어 사용자 지정 AWS KMS 키 또는 사용자가 AWS KMS 서비스로 가져온 마스터 키를 사용하는 경우, 데이터 스트림의 생산자와 소비자가 암호화에 사용된 KMS 키를 사용할 권한이 없다면 PUT 및 GET 요청이 실패하게 됩니다. 서버 측 암호화를 사용할 수 있으려면 먼저 메시지의 암호화와 복호화를 허용하도록 AWS KMS 키 정책을 구성해야 합니다. AWS KMS 권한의 예와 추가 정보는 AWS Key Management Service 개발자 안내서의 AWS KMS API Permissions: Actions and Resources Reference 또는 Kinesis Data Streams 서버 측 암호화 사용자 설명서의 권한 지침을 참조하세요.

예. 하지만 AWS에서 관리하는 Kinesis용 KMS 키를 사용하고 AWS 프리 티어 KMS API 사용 비용을 초과하지 않는다면 서버 측 암호화는 무료로 사용할 수 있습니다. 다음은 리소스별 비용에 대한 설명입니다.

키:

AWS에서 관리하는 Kinesis용 KMS 키(별칭 = "aws/kinesis")는 무료입니다.
고객 관리형 KMS 키에는 KMS 키 비용이 적용됩니다. 자세히 알아보기.

KMS API 사용량:

API 사용 비용은 사용자 지정 KMS 키를 비롯한 모든 KMS 키에 적용됩니다. Kinesis Data Streams는 데이터 키를 교체할 때 약 5분 간격으로 KMS를 호출합니다. 한 달이 30일인 경우 Kinesis Data Streams에서 수행한 KMS API 호출 총비용은 몇 달러를 넘지 않습니다. 이 비용은 데이터 생산자와 소비자에서 사용하는 사용자 자격 증명 수에 따라 변동됩니다. 각 사용자 자격 증명이 AWS KMS로 개별 API 호출을 수행해야 하기 때문입니다. 인증을 위해 IAM 역할을 사용하면, 각 assume-role-call이 개별 사용자 자격 증명이 되므로 assume-role-call에서 반환한 사용자 자격 증명을 캐시하여 KMS 비용을 절감하는 것이 좋을 수 있습니다.

Kinesis Data Streams 서버 측 암호화는 중국(베이징) 리전을 제외한 모든 퍼블릭 리전과 AWS GovCloud 리전에서 사용할 수 있습니다.

이 모든 작업은 AWS Management Console 또는 AWS SDK를 사용하여 수행할 수 있습니다. 자세한 내용은 Kinesis Data Streams 서버 측 암호화 시작 가이드를 참조하세요.

Kinesis Data Streams는 암호화에 AES-GCM 256 알고리즘을 사용합니다.

아니요. 새로운 암호화 애플리케이션은 데이터 스트림에 새로 작성되는 데이터만 암호화(또는 복호화된 상태를 유지)합니다.

서버 측 암호화에서는 메시지 페이로드와 더불어 데이터 스트림 생산자 애플리케이션에서 지정하는 파티션 키를 암호화합니다.

서버 측 암호화는 스트림별 기능입니다.

예. AWS Management Console 또는 AWS SDK를 사용하여 특정 데이터 스트림에 적용할 새로운 KMS 키를 선택할 수 있습니다.

아니요. Kinesis Data Streams는 현재 AWS 프리 티어에서 사용할 수 없습니다. AWS 프리 티어는 AWS 서비스 그룹을 무료로 체험해 볼 수 있도록 하는 프로그램입니다. AWS 프리 티어에 대한 자세한 내용은 AWS 프리 티어를 참조하세요.

Kinesis Data Streams SLA는 Kinesis Data Streams의 월간 가동률을 최소 99.9% 보장합니다.

같은 리전 내에서 작업을 실행하고 있는 하나 이상의 가용 리전의 월간 가동률이 월별 청구 주기 동안 99.9%보다 낮은 경우, Kinesis Data Streams SLA에 따라 Kinesis Data Streams의 SLA 크레딧 지급 대상이 됩니다.

SLA 이용 약관과 요청 제출 방법에 대한 자세한 내용은Amazon Kinesis Data Streams SLA를 참조하세요.

Kinesis Data Streams는 사용량에 따라 지불하는 간편한 요금제를 사용합니다. 선결제 금액이나 최소 요금은 없으며 사용하는 리소스에 대한 비용만 지불하면 됩니다. Kinesis Data Streams에는 온디맨드 및 프로비저닝의 두 가지 용량 모드가 있으며 둘 다 특정 결제 옵션과 함께 제공됩니다.

온디맨드 용량 모드를 사용하면 애플리케이션이 수행할 것으로 예상되는 읽기 및 쓰기 처리량을 지정할 필요가 없습니다. 이 모드에서 가격은 계정의 각 데이터 스트림에 대한 시간당 요금과 함께 수집 및 검색된 데이터의 양을 기준으로 합니다. 옵션 기능에 대한 연장된 데이터 보존(처음 24시간 초과 및 처음 7일 이내), 장기 데이터 보존(7일 초과 및 최대 1년) 및 향상된 팬아웃과 같은 추가 요금이 있습니다. Kinesis Data Streams 비용에 대한 자세한 내용은 Amazon Kinesis Data Streams 요금을 참조하세요.

프로비저닝된 용량 모드에서는 쓰기 및 읽기 요청 속도를 기반으로 애플리케이션에 필요한 샤드 수를 지정합니다. 샤드는 1MB/초의 쓰기와 2MB/초의 읽기를 제공하는 용량 단위입니다. 각각의 샤드에 대해 시간 단위로 사용료가 부과됩니다. Kinesis 데이터 스트림에 기록된 레코드에 대한 비용도 지불합니다. 확장된 보존 및 향상된 팬아웃과 같은 선택적 기능을 사용하는 경우 추가 요금이 발생합니다.

다음은 Kinesis Data Streams 프로비저닝된 모드의 2개의 핵심 차원과 3개의 선택적 차원입니다.

• 시간당 샤드 비용은 Amazon Kinesis 데이터 스트림 내 샤드 수를 기준으로 결정됩니다.
• PUT 페이로드 단위 비용은 데이터 생산자가 데이터 스트림에 추가하는 25KB 페이로드 단위 수를 기준으로 결정됩니다.

선택 사항:

• 데이터 보존 기간 연장은 선택적 비용이며 데이터 스트림에서 발생한 샤드 시간 수를 기준으로 부과됩니다. 데이터 보존 기간 연장을 활성화하면 스트림의 각 샤드에 대해 보존 기간 연장 요금이 부과됩니다.
• 장기 데이터 보존은 장기 데이터 저장과 장기 데이터 검색의 두 가지 측면으로 구성된 선택적 비용입니다. 장기 데이터 저장은 7일 이상, 365일 이내의 기간에 저장되는 월별 GB 데이터 용량을 반영합니다. 장기 데이터 검색은 7일 이상 저장된 후 검색된 데이터의 GB 용량이 반영됩니다.
• 향상된 팬아웃은 소비자 샤드 시간과 데이터 검색의 두 가지 비용 범위가 포함되는 선택적 비용입니다. 소비자 샤드 시간은 스트림의 샤드 수에 향상된 팬아웃을 사용하는 소비자 수를 곱한 값을 반영합니다. 데이터 검색은 향상된 팬아웃을 사용하는 소비자에게 제공된 GB 수로 결정됩니다.

Kinesis Data Streams 비용에 대한 자세한 내용은 Amazon Kinesis Data Streams 요금을 참조하세요.

소비자 샤드 시간은 등록된 스트림 소비자 수와 스트림의 샤드 수를 곱하여 계산됩니다. 또한 향상된 팬아웃 사용을 위해 소비자가 등록된 시간의 비례 할당으로 계산된 부분에 대한 요금을 지불하게 됩니다. 예를 들어 10개의 샤드 데이터 스트림에 대한 소비자 샤드 시간 비용이 0.015 USD인 경우 이 소비자는 향상된 팬아웃을 사용하여 10개 샤드에서 읽을 수 있으므로 시간당 0.15 USD의 소비자 샤드 시간 요금이 발생합니다(소비자 1명 x 10개 샤드 x 소비자 샤드 시간당 0.015 USD). 향상된 팬아웃에 동시에 등록된 사용자가 2명인 경우 총 소비자 샤드 시간 요금은 시간당 0.30 USD가 됩니다(소비자 2명 x 10개 샤드 x 0.015 USD).

Kinesis Data Streams와 Amazon MSK는 모두 널리 사용되는 데이터 스트리밍 플랫폼으로, 특수한 요구 사항에 맞게 데이터를 처리하는 자체 스트리밍 워크로드를 구축하는 데 도움이 됩니다. 두 서비스 모두 확장 가능하고 안전하며 가용성이 높습니다. 둘 다 실시간 웹 및 로그 분석, 고객 경험 개인화, 이벤트 기반 아키텍처, IoT 분석, 실시간 사기 탐지와 같은 스트리밍 사용 사례를 실행하는 데 배포할 수 있습니다. 둘 중 하나를 선택할 때는 구체적인 사용 사례와 요구 사항을 고려하는 것이 중요합니다. 고려해야 할 몇 가지 요소는 다음과 같습니다.

익숙함

•  스트리밍 기술을 처음 사용하는 경우 Kinesis Data Streams를 사용하세요.
• Apache Kafka에서 실행 중인 기존 애플리케이션이 있는 경우 MSK를 사용하세요. MSK의 기존 Kafka 마이그레이션 프로그램(KMP)과 마이그레이션 가이드에서 수월한 마이그레이션에 도움이 되는 정보를 얻을 수 있습니다.

오픈 소스 선호

• 오픈 소스 기술을 선호한다면 MSK를 사용하는 것이 좋습니다. MSK와 MSK Connect는 각각 Apache Kafka 및 Kafka Connect와 완벽하게 호환됩니다.

Kinesis Data Streams는 빅 데이터 스트리밍을 실시간으로 처리할 수 있습니다. 또한 레코드를 순서대로 정리하고, 여러 개의 Amazon Kinesis 애플리케이션에서 같은 순서대로 레코드를 읽거나 재생할 수 있는 기능을 제공합니다. Amazon Kinesis Client Library(KCL)는 주어진 파티션 키에 대한 모든 레코드를 동일한 레코드 프로세서에 제공하므로 동일한 Kinesis 데이터 스트림의 데이터를 읽는 여러 개의 애플리케이션을 보다 손쉽게 구축할 수 있습니다(예: 계산, 집계 및 필터링 수행). Amazon Simple Queue Service(Amazon SQS)는 컴퓨터 간에 송수신하는 메시지를 저장하기 위한 안정적이고 확장성이 뛰어난 호스팅 대기열을 제공합니다. Amazon SQS를 사용하면 배포된 애플리케이션 구성 요소 간 데이터를 손쉽게 이동하고 자동화된 워크플로우 같이 메시지가 독립적으로 처리(메시지 수준 확인/실패 의미 체계 사용)되는 애플리케이션을 구축할 수 있습니다.

다음과 유사한 요구 사항의 사용 사례에서는 Kinesis Data Streams를 사용하는 것이 좋습니다.

• 관련 레코드를 동일한 레코드 프로세서로 라우팅합니다(MapReduce를 스트리밍하는 경우와 유사). 예를 들어, 주어진 키에 대한 모든 레코드가 동일한 레코드 프로세서로 라우팅되는 경우 계산 및 집계가 훨씬 간단해집니다.
• 레코드를 순서대로 정렬합니다. 예를 들어 애플리케이션 호스트의 로그 데이터를 로그 명령문의 순서는 유지한 채로 처리/보관 호스트로 전송하려는 경우가 이에 속합니다.
• 여러 개의 애플리케이션이 동일한 스트림을 동시에 사용할 수 있도록 하는 기능.  예를 들어 실시간 대시보드를 업데이트하는 애플리케이션이 있고 Amazon Redshift에 데이터를 보관하는 다른 애플리케이션이 있을 때 이 2개의 애플리케이션이 동일한 스트림의 데이터를 동시에 독립적으로 소비하길 원하는 경우가 이에 속합니다.
• 몇 시간 후 동일한 순서대로 레코드를 사용할 수 있도록 하는 기능. 예를 들어 결제 애플리케이션이 있고 결제 애플리케이션보다 몇 시간 뒤에 실행되는 감사 애플리케이션이 있는 경우가 이에 속합니다. Kinesis Data Streams는 데이터를 최대 365일간 저장하므로 결제 애플리케이션보다 최대 365일 뒤에 감사 애플리케이션을 실행할 수 있습니다.

다음과 유사한 요구 사항의 사용 사례에서는 Amazon SQS를 사용하는 것이 좋습니다.

• 메시징 의미 체계(예: 메시지 수준 확인/실패) 및 제한 시간 초과.  예를 들어 작업 항목 대기열이 있으며 각 항목이 개별적으로 완료되었는지 추적하려는 경우가 이에 속합니다. Amazon SQS는 확인/실패를 추적하므로 애플리케이션은 지속적인 체크포인트/커서를 유지할 필요가 없습니다. Amazon SQS는 구성된 제한 시간 초과 후 확인된 메시지를 삭제하고 실패한 메시지를 다시 전송합니다.
• 개별 메시지 지연.  예를 들어 작업 대기열이 있으며 개별 작업에 지연 시간을 지정하려 하는 경우가 이에 속합니다. Amazon SQS를 사용하면 최대 15분간의 지연 시간을 갖도록 개별 메시지를 구성할 수 있습니다.
• 읽기 시 동시성/처리량 동적으로 증가.  예를 들어 작업 대기열이 있으며 백로그가 지워질 때까지 더 많은 리더를 추가하려는 경우가 이에 속합니다. Kinesis Data Streams를 사용하면 샤드의 수를 충분히 늘릴 수 있습니다. 그러나 이 작업을 수행하기 전에 충분한 수의 샤드를 프로비저닝해야 한다는 점에 유의하십시오.
• Amazon SQS의 기능을 사용하여 투명하게 확장합니다. 예를 들어 이따금 발생하는 로드 스파이크 및 비즈니스의 자연스러운 성장으로 인한 요청과 로드 변경 사항을 버퍼링하려는 경우가 이에 속합니다. 버퍼링된 각 요청은 개별적으로 처리될 수 있으므로 Amazon SQS는 투명하게 확장하여 사용자의 프로비저닝 지침을 받지 않아도 로드를 처리할 수 있습니다.