翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
大きなレコードの処理
Amazon Kinesis Data Streams は、最大 10 メビバイト (MiB) のレコードをサポートします。この機能は、デフォルトの 1 MiB のレコードサイズ制限を超える断続的なデータペイロードを処理する場合に推奨されます。既存および新規に作成されたストリームのデフォルトの最大レコードサイズは 1 MiB に設定されています。
この機能は、断続的に大きなデータペイロードを処理する必要がある IoT アプリケーション、変更データキャプチャ (CDC) パイプライン、機械学習ワークフローに有用です。ストリームで大きなレコードの使用を開始するには、ストリームの最大レコードサイズ制限を更新します。
重要
1 シャードあたりのスループット制限 (書き込み 1 MB/秒、読み取り 2 MB/秒) は、大きなレコードサイズをサポートしても変更されません。Kinesis Data Streams は、1 MiB 以下のレコードをベースとしたトラフィックに加えて、断続的に発生する大きなレコードを処理できるように設計されています。継続的に大量の大きなレコードを取り込む用途向けには設計されていません。
大きなレコードの仕組み
Amazon Kinesis Data Streams は、最大 10 MiB のサイズのレコードを受け入れます。ストリームは、持続的な書き込みスループットを超えて一時的にバーストし、時間の経過とともにベースラインレートに戻ることで、大きなレコードに対応します。このバースト容量は継続的に補充されるため、ストリームは手動で容量を調整することなく、通常のトラフィックとともに断続的な大量のレコードを処理できます。
この動作を視覚化するには、ストリームの書き込み容量を一定のレートで補充するタンクと見なします。10 MiB レコードなどの大きなレコードを送信すると、タンクは一時的に枯渇します。その後、すぐに補充が開始されます。つまり、容量が利用可能になると、より小さなレコードを引き続き送信できます。
容量が補充される速度は、いくつかの要因によって異なります。
大きなレコードのサイズ
ベースラインレコードのサイズ
ストリーム上の全体的なトラフィックパターン
選択したパーティションキー戦略
最良の結果を得るには、均一に分散されたパーティションキーを使用して、ストリームの使用可能な容量全体に大きなレコードを分散します。
オンデマンドモードでは、Kinesis Data Streams は自動的に容量を管理します。ストリームはトラフィックパターンに基づいてスループットをスケールアップおよびスケールダウンし、大きなレコードバースト容量は透過的に処理されます。大規模なレコードを使用するには、容量をプロビジョニングまたは管理する必要はありません。オンデマンドモードのスケーリング方法の詳細については、「オンデマンドモードの機能とユースケース」を参照してください。
大きなレコードを使用するようにストリームを更新する
Kinesis Data Streams で大きなレコードを処理するには、次の手順を実行します。
Kinesis Data Streams コンソールに移動します。
ストリームを選択し、[設定] タブを開きます。
[最大レコードサイズ] の横にある [編集] をクリックします。
最大レコードサイズ (最大 10 MiB) を設定します。
変更内容を保存します。
この設定は、この Kinesis データストリームの最大レコードサイズのみを調整します。この上限を引き上げる前に、すべての下流アプリケーションが大きなレコードを処理できることを確認してください。
AWS CLI を使用してこの設定を更新することもできます。
aws kinesis update-max-record-size \ --stream-arn \ --max-record-size-in-ki-b 5000
大きなレコードでストリームのパフォーマンスを最適化する
大きなレコードは断続的な使用のために設計されています。最良の結果を得るには、大きなレコードをトラフィック全体の 2% 未満に維持します。ストリームは一時的に持続的なスループットを超えてバーストし、大きなレコードを配信するため、大量のレコードを頻繁に送信すると、ベースライントラフィックで使用できる容量を減らすことができます。大きなレコードでストリームのパフォーマンスを最適化する方法の詳細については、「最適なパフォーマンスのためのスロットリングとベストプラクティス
大きなレコードによるスロットリングを軽減する
大きなレコードは一時的にバースト容量を消費するため、ストリームは容量が補充されるまで後続の書き込みをスロットリングする可能性があります。次の手順は、スロットリングを減らすのに役立ちます。
スロットリングを軽減するには
プロデューサーアプリケーションに指数バックオフを伴う再試行ロジックを実装します。
ランダム化されたパーティションキーを使用して、ストリームの使用可能な容量全体に大きなレコードを分散します。
継続的に大きなレコードをストリーミングする場合は、ペイロードを Amazon S3 に保存し、メタデータ参照のみをストリームに送信します。詳細については、Processing large records with Amazon Kinesis Data Streams
を参照してください。
Kinesis Data Streams API を使用して大きなレコードを処理する
大きなレコードのサポートでは、新しい API が 1 つ追加され、既存の 2 つのコントロールプレーン API が更新され、最大 10 MiB までのレコードを処理できるようになりました。
レコードサイズを変更するための API:
UpdateMaxRecordSize: 既存のストリームに対して最大 10 MiB までのレコードサイズ上限を設定します。
既存 API の更新点:
CreateStream: ストリーム作成時にレコードサイズ上限を設定できるオプションパラメータMaxRecordSizeInKiBが追加されました。DescribeStreamSummary: 現在のストリーム設定を表示するためのMaxRecordSizeInKiBフィールドが返されます。
ここに挙げたすべての API は、既存のストリームとの下位互換性を維持しています。API ドキュメントの詳細については、Amazon Kinesis Data Streams Service API リファレンスを参照してください。
AWS 大きなレコードと互換性のあるコンポーネント
次の AWS コンポーネントは、大きなレコードと互換性があります。
| コンポーネント | 説明 |
|---|---|
|
AWS SDK |
AWS SDK は、大規模なレコードの処理をサポートしています。 AWS SDKs で使用可能なメソッドを使用して、ストリームの最大レコードサイズを最大 10 MiB に更新できます。詳細については、AWS 「 SDK でこのサービスを使用する」を参照してください。 |
|
Kinesis Consumer Library (KCL) |
バージョン 2.x 以降、KCL は大きなレコードの処理をサポートしています。大きなレコードのサポートを使用するには、ストリームの |
|
Kinesis Producer Library (KPL) |
バージョン 1.0.5 以降、KPL は大きなレコードの処理をサポートしています。大きなレコードのサポートを使用するには、ストリームの maxRecordSize を更新し、KPL を使用します。詳細については、Develop producers using the Amazon Kinesis Producer Library (KPL) を参照してください。 |
|
Amazon EMR |
Apache Spark を使用した Amazon EMR は、Kinesis Data Streams の上限 (10 MiB) までの大きなレコードの処理をサポートしています。大きなレコードのサポートを使用するには、 |
|
Amazon Data Firehose |
Kinesis Data Streams と併用する場合、Amazon Data Firehose の大きなレコードの動作は配信先によって異なります。
大きなレコードを Snowflake または Redshift に配信する必要がある場合は、まず Amazon S3 にデータを配信します。その後、抽出、変換、ロード (ETL) プロセスを使用してデータをロードします。その他の配信先については、本番環境にスケールする前に概念実証 (PoC) 環境で大きなレコードの動作を確認してください。大きなレコードの処理方法は配信先によって異なります。 |
|
AWS Lambda |
AWS Lambda は最大 6 MiBs のペイロードをサポートします。この上限には、base64 エンコードに変換された Kinesis ペイロードと、イベントソースマッピング (ESM) に関連付けられたメタデータが含まれます。6 MiB 未満のレコードは、追加設定なしで ESM を使用して処理されます。6 MiB を超えるレコードは、Lambda が失敗時の送信先を使用して処理します。処理上限を超えるレコードを扱うには、ESM を使用して失敗時の送信先を設定する必要があります。失敗時の送信先に送信される各イベントは、失敗した呼び出しに関するメタデータを含む JSON ドキュメントです。 レコードサイズにかかわらず、ESM 内で失敗時の送信先を作成することをお勧めします。これにより、いかなるレコードも破棄されないことが保証されます。詳細については、「失敗した呼び出しの送信先の設定」を参照してください。 |
|
Amazon Redshift |
Amazon Redshift は、Kinesis Data Streams からデータをストリーミングする場合、1 MiB 未満のレコードサイズのみをサポートしています。この上限を超えるレコードは処理されません。処理されなかったレコードは |
|
Flink connector for Kinesis Data Streams |
Kinesis Data Streams からデータを取り込む方法には、Kinesis ソースコネクタ と Kinesis シンクコネクタ の 2 つのアプローチがあります。ソースコネクタは 1 MiB 未満から最大 10 MiB までのレコードの処理をサポートしています。1 MiB を超えるレコードにはシンクコネクタを使用しないでください。詳細については、Use connectors to move data in Amazon Managed Service for Apache Flink with the DataStream API を参照してください。 |
大きなレコードがサポートされるリージョン
この Amazon Kinesis Data Streams 機能は、次の AWS リージョンでのみ使用できます。
| AWS リージョン | リージョン名 |
|---|---|
|
eu-north-1 |
欧州 (ストックホルム) |
|
me-south-1 |
中東 (バーレーン) |
|
ap-south-1 |
アジアパシフィック (ムンバイ) |
|
eu-west-3 |
欧州 (パリ) |
|
ap-southeast-3 |
アジアパシフィック (ジャカルタ) |
|
us-east-2 |
米国東部 (オハイオ) |
|
af-south-1 |
アフリカ (ケープタウン) |
|
eu-west-1 |
欧州 (アイルランド) |
|
me-central-1 |
中東 (アラブ首長国連邦) |
|
eu-central-1 |
欧州 (フランクフルト) |
|
sa-east-1 |
南米 (サンパウロ) |
|
ap-east-1 |
アジアパシフィック (香港) |
|
ap-south-2 |
アジアパシフィック (ハイデラバード) |
|
us-east-1 |
米国東部 (バージニア北部) |
|
ap-northeast-2 |
アジアパシフィック (ソウル) |
|
ap-northeast-3 |
アジアパシフィック (大阪) |
|
eu-west-2 |
欧州 (ロンドン) |
|
ap-southeast-4 |
アジアパシフィック (メルボルン) |
|
ap-northeast-1 |
アジアパシフィック (東京) |
|
us-west-2 |
米国西部 (オレゴン) |
|
us-west-1 |
米国西部 (北カリフォルニア) |
|
ap-southeast-1 |
アジアパシフィック (シンガポール) |
|
ap-southeast-2 |
アジアパシフィック (シドニー) |
|
il-central-1 |
イスラエル (テルアビブ) |
|
ca-central-1 |
カナダ (中部) |
|
ca-west-1 |
カナダ西部 (カルガリー) |
|
eu-south-2 |
欧州 (スペイン) |
|
cn-northwest-1 |
中国 (寧夏) |
|
eu-central-2 |
欧州 (チューリッヒ) |
| us-gov-east-1 | AWS GovCloud (米国東部) |
| us-gov-west-1 | AWS GovCloud (米国西部) |
