Amazon Kinesis Data Streamsに、サービス側がパーティションキーを管理する新機能が追加されました。対象はOn-Demand StandardおよびOn-Demand Advantageストリームです。
これまでプロデューサーは、レコードをどのシャードへ振り分けるかを考慮してパーティションキーを指定する必要がありました。今回の機能では、レコード公開時に顧客がパーティションキーを指定せず、Kinesis Data Streamsが利用可能なウォームキャパシティに基づいて自動的にレコードを分散します。
ログ集約、メトリクス収集、IoTテレメトリのように、レコード単位の順序性を必要としないワークロードでは、パーティションキー設計と運用の負担を減らせる可能性があります。
パーティションキーが運用課題になる理由
Kinesis Data Streamsでは、プロデューサーが指定したパーティションキーをもとにレコードがシャードへ分散されます。一般的には、同じパーティションキーを持つレコードを同じシャードへ送ることで、キー単位の順序性を扱いやすくします。
一方で、キーの偏りがあると、ストリーム全体には余裕があっても特定のシャードへ負荷が集中します。これがいわゆるホットパーティションです。
例えば、次のようなキー設計では偏りが発生しやすくなります。
- 特定の顧客やデバイスにデータが集中する
- 時刻や地域など、値の種類が少ない属性をキーにする
- 一部のテナントだけが大規模なイベントを発生させる
- キーの分布が時間帯によって大きく変化する
ホットパーティションが発生すると、ストリーム全体の集計スループットが十分でも、特定のパーティションキーに関連するレコードでスロットリングが起こる場合があります。結果として、再試行、バッファリング、遅延監視、キー設計の見直しが必要になります。
ランダムキーでも完全には解決しない
順序性が不要な処理では、UUIDなどのランダムな値をパーティションキーとして使い、レコードを分散させる設計がよく採用されてきました。
この方法は固定キーによる偏りを抑える有効な手段ですが、ランダムである以上、一定期間に生成されたキーが完全に均等に分布するとは限りません。特に短時間に大量のレコードを送信する場合、確率的な偏りによって一部のシャードに負荷が集中する可能性があります。
つまり、ランダムキー方式では次のような実装・運用が必要でした。
- ランダムなキーを生成する処理
- 送信エラーやスロットリングへの再試行処理
- シャード単位の負荷や遅延の監視
- 高負荷時にキー分布を調整する検討
- キー変更による下流処理への影響確認
サービス管理のパーティションキーは、この分散ロジックをプロデューサー側で持たなくてよい点が大きな違いです。
従来方式とサービス管理方式の比較
| 方式 | パーティションキー | 主な利点 | 注意点 |
|---|---|---|---|
| 固定・業務キー | 顧客IDやデバイスIDなどを指定 | キー単位の順序性を扱いやすい | キーの偏りでホットパーティションが起きやすい |
| ランダムキー | UUIDなどをアプリケーションで生成 | 実装しやすく負荷を分散しやすい | 確率的な偏りや生成ロジックの運用が残る |
| サービス管理キー | レコード公開時に指定しない | 分散ロジックをサービスに任せられる | 順序性が必要な用途には適さない |
この機能は、従来のパーティションキーを置き換える万能機能ではありません。順序性を捨てられるワークロードで、取り込み処理を簡素化するための選択肢と考えるのが適切です。
向いているユースケース
サービス管理方式を検討しやすいのは、レコード同士の順序に依存せず、個々のイベントを独立して処理できるワークロードです。
- アプリケーションやインフラのログ集約
- メトリクスや監視イベントの収集
- 大量のIoTテレメトリ取り込み
- 行動イベントやアクセスイベントの収集
- 後段で集計・検索するためのストリーム投入
- 一時的な大量イベントを受け付けるデータ収集基盤
特に、送信元やテナントごとにデータ量の差が大きいシステムでは、アプリケーション側で適切なキーを設計する負担を減らしやすくなります。
利用に向かないケース
一方、次のような要件がある場合は、既存のパーティションキー設計を維持する必要があります。
- 同じ顧客やデバイスのイベント順序が重要
- 1つのエンティティに属するレコードを順番どおりに処理したい
- 下流処理がパーティションキーを単位として状態を管理する
- キー単位での集約やウィンドウ処理を前提としている
- 再生時にも特定のキーに関する順序を維持したい
サービス管理方式では、プロデューサーが意図した業務単位と、Kinesis側の分散単位を一致させる設計ができません。順序性や状態管理が必要なら、パーティションキーを明示する方式のほうが適しています。
導入時に確認すべきポイント
1. 順序性の要件をイベント単位で整理する
まず、ストリーム全体ではなく、どの単位で順序性が必要かを洗い出します。
例えば、監視ログの収集ではログ同士の順序が不要でも、決済イベントでは同一取引の状態遷移順序が重要になることがあります。同じストリームに異なる性質のデータを混在させる場合は、サービス管理方式に切り替える範囲を慎重に分けるべきです。
2. プロデューサーのSDKを更新する
この機能を利用するには、最新のAWS SDKまたはKinesis Producer Libraryの利用が案内されています。導入前には、プロデューサーの実行環境ごとに次の点を確認します。
- 使用しているAWS SDKまたはKPLのバージョン
- レコード公開処理がパーティションキーなしの送信に対応しているか
- 使用中の言語向けSDKの対応状況
- リトライやバッファリングの挙動
- IAM権限やリージョン設定への影響
実際の更新では、まず開発環境や検証用ストリームでSDKを更新し、既存の送信失敗処理やメトリクス収集に影響がないことを確認します。
3. ストリームのモードと対象範囲を確認する
サービス管理のパーティションキーは、On-Demand StandardおよびOn-Demand Advantageストリームが対象です。プロビジョンドモードなど、対象外の構成を含む環境では、既存の設計をそのまま置き換えられるとは限りません。
複数のストリームを運用している場合は、対象ストリームを一覧化し、次のような観点で適用候補を絞り込みます。
- ストリームの容量モード
- データの順序性要件
- 現在のパーティションキーの分布
- スロットリングや遅延の発生状況
- 下流コンシューマーの状態管理方式
導入前後の検証方法
単にスロットリングの件数だけを見るのではなく、送信から処理完了までの挙動を比較することが重要です。代表的な検証項目は次のとおりです。
- プロデューサー側の送信成功率
- スロットリングや再試行の発生回数
- レコードの取り込み遅延
- コンシューマー側の処理遅延
- バックログの増加量
- アプリケーションのCPU使用率とメモリ使用量
- レコード欠落や重複に対する既存処理の動作
- ピーク時と通常時のスループット
検証では、通常負荷だけでなく、アクセス集中やデバイスの一斉接続など、実際に偏りが発生しやすい負荷パターンを再現します。ランダムキー方式とサービス管理方式で同程度の入力データを流し、負荷の分布や遅延を比較すると、導入効果を判断しやすくなります。
ただし、サービス管理方式に変更した結果、キー単位の順序性を前提としていた下流処理が変わる可能性があります。性能指標だけでなく、集計結果や状態遷移の正しさも検証対象に含める必要があります。
段階的な移行が現実的
既存システムを一度に切り替えるのではなく、対象を限定した段階移行が安全です。
- 順序性が不要なストリームを特定する
- 対象ストリームのプロデューサーを最新SDKまたはKPLへ更新する
- 検証環境でパーティションキーなしの送信をテストする
- 本番では一部の送信元または低リスクなデータから適用する
- スロットリング、遅延、エラー、下流処理結果を比較する
- 問題がなければ適用範囲を拡大する
移行時には、従来方式へ戻せるように設定やリリース手順を準備しておくと、想定外の順序性問題やコンシューマー側の遅延に対応しやすくなります。
運用負荷を減らせる一方、監視は不要にならない
サービス管理方式では、パーティションキー生成や分散ロジックの保守を減らせます。しかし、Kinesisへの送信エラー、コンシューマーの処理遅延、データの再試行、下流システムの詰まりまで自動的に解決するものではありません。
引き続き、次のような監視設計が必要です。
- プロデューサーのエラーと再試行
- 取り込み遅延
- コンシューマーの処理遅延
- バックログや未処理レコードの増加
- 想定スループットとの差分
- データ欠落や重複を検知する仕組み
特に、順序性を不要と判断した後でも、運用担当者が障害調査や監査で時系列を参照することはあります。業務要件としての順序性と、調査に便利な表示上の時系列を混同しないことが大切です。
まとめ
Amazon Kinesis Data Streamsのサービス管理パーティションキーは、順序性を必要としない大量データの取り込みを簡素化する機能です。固定キーによるホットパーティションだけでなく、ランダムキー方式に残る分散ロジックや確率的な偏りへの対応も減らせます。
導入の判断では、次の点を優先して確認します。
- 対象ストリームがOn-Demand StandardまたはOn-Demand Advantageであること
- レコードの順序性が本当に不要であること
- 下流処理がパーティションキー単位の状態管理に依存していないこと
- 最新のAWS SDKまたはKPLへ更新できること
- 導入前後でスループット、遅延、エラー、処理結果を比較できること
ログ、メトリクス、IoTデータなど、順序性よりも取り込みの簡便さとスケール性を重視する基盤では、有力な選択肢になります。一方で、顧客単位やデバイス単位の順序が業務要件に含まれる場合は、パーティションキーを明示する従来方式を維持するのが適切です。
詳細はAmazon Kinesis Data Streamsのドキュメントで確認できます。
出典： AWS What’s New