DEA / ドメイン1 データの取り込みと変換

ストリーミング取り込みの設計

ストリーミング取り込みでは、途切れなく届くデータを、取りこぼさず、重複させず、必要な処理系へ配ります。サービスの機能を覚える前に、ファンイン/、と、再現性という3つの設計の考え方を押さえると、・・・ のどれを選ぶ問題も解きやすくなります。

Point
  • ファンイン (fan-in) は、多数の送信元からのデータを1つの流れに集めることです。
  • ファンアウト (fan-out) は、1つの流れを複数の受け手へ配ることです。
  • 和訳

概要

概要の図 IoT デバイス ストリームKinesis Data Streams / MSK Web サーバー モバイルアプリ Lambdaアラート Managed Service for Apache Flink集計 Data FirehoseS3 へ保存

多数のプロデューサー (送信側) から1つのストリームへ集め (ファンイン)、複数のコンシューマー (受信側) がそれぞれの目的で同じデータを読みます ()。ストリームはデータを一定期間保持するため、コンシューマーは自分のペースで読み、失敗したら読み直せます。

試験では、次の3点を判断します。

判断例
受け手を増やしたときに遅延や上限をどう避けるか、→
処理が過去のデータ (状態) を必要とするかウィンドウ集計は 、1件ごとの変換は
障害時にどこから、どう再処理するか保持期間、、な書き込み

主要技術

①ファンインの管理

多数の送信元からの書き込みは、ストリームの書き込み上限と、の偏りが問題になります。

課題対処
送信元が増えて総量が上限を超える はを増やすかモード、 はパーティションとブローカーを増やす
特定のキーに書き込みが集中する (ホットパーティション)分散しやすいパーティションキーにする。順序が不要ならランダムなキーを使う
小さなレコードが大量に届き、 の呼び出しが多いKinesis Producer Library (KPL) の集約 (aggregation)、PutRecords でまとめて送る
送信元の一時的なで再送する (「スロットリングとレート制限」の章)

Kinesis Data Streams では、同じパーティションキーのレコードは同じシャードに入り、シャード内で順序が保たれます。順序が必要な単位 (例: デバイス ID、注文 ID) をパーティションキーにし、キーの種類を十分に多くすることで、順序と分散を両立します。

②ファンアウトの管理 ⚠️ 頻出

1つのデータを複数の処理系へ配る方法は、サービスによって異なります。

方式仕組み向くケース
の共有のコンシューマーあたり毎秒 2 MB・毎秒5回の読み取りを全コンシューマーで分け合うコンシューマーが少ない (2〜3個程度)
Kinesis の (EFO)登録したコンシューマーごとに、シャードあたり毎秒 2 MB の専用の読み取りをプッシュで受け取るコンシューマーが多い、低遅延が必要
のコンシューマーグループグループごとに独立してオフセットを持ち、同じトピックを読む のエコシステムを使う
→ 複数の SNS のトピックへ発行し、購読した複数のキューへ配るメッセージ単位の通知・作業の配布
のルール1つのイベントを条件に合う複数のターゲットへ配るAWS サービスのイベントや業務イベントの配布
Streamsシャードあたり同時に読めるのは2つまで変更の受け手が多いなら Kinesis Data Streams for DynamoDB を使う

EFO のコンシューマーは、プロビジョンドモードと (Standard) モードのストリームで、1ストリームあたり20個まで登録できます (On-demand Advantage モードでは50個まで)。

⚠️ 頻出: 「コンシューマーを増やしたら、既存の処理の遅延が伸びた」「ReadProvisionedThroughputExceeded が出る」は、共有スループットの奪い合いです。Enhanced Fan-Out を有効にします。シャードを増やすのは、書き込みが上限に達している場合です。

③ステートレスとステートフルの処理 ⚠️ 頻出

種類意味例向くサービス
1件ごとに完結し、過去のレコードを覚えておく必要がない形式の変換、マスキング、フィルター、1件ずつの書き込み、 の変換
過去のレコードや途中の計算結果 (状態) を保持して処理する5分ごとの集計、移動平均、セッション単位の集計、重複排除、ストリーム同士の結合、/ のストリーミング

ステートフルな処理では、状態を障害時にも失わないことが重要です。Managed Service for Apache Flink は状態を定期的にへ保存し、障害時はそこから再開します。Lambda は呼び出しごとに状態を持たないため、状態が必要なら などの外部ストアに保存します。Lambda のタンブリングウィンドウ (最大 900 秒) で簡単な集計を行うこともできますが、長いウィンドウや複雑な結合は を選びます。

データの取引 (トランザクション) の観点でも同じ区別があります。ステートレスなトランザクションは、各リクエストが前のリクエストに依存しません。ステートフルなトランザクションは、セッションや途中結果を前提にするため、順序の保証と状態の保存が必要です。

Point
  • State = 状態です。ステートフル (stateful) は「状態を持つ」、ステートレス (stateless) は「状態を持たない」です。
  • 「直近5分間の合計」「同じユーザーの前回のイベント」と出たらステートフルです。
  • 和訳

④取り込みパイプラインの再現性 ⚠️ 頻出

再現性とは、障害やロジックの修正のあとで、同じ入力から同じ結果を作り直せることです。

手段内容AWS での実現
リプレイ (再読込)ストリームの保持期間内なら、過去の位置から読み直す の保持期間 (既定 24 時間、最大 365 日)、 のトピックの保持設定
生データの保存取り込んだままのデータを に残す で raw を S3 へ配信
どこまで処理したかを記録し、再開位置にする の のリース表、 のチェックポイント、 のイベントソースマッピング
な書き込み同じレコードを2回処理しても結果が変わらない一意キーでの 、DynamoDB の条件付き書き込み、 の MERGE
開始位置の指定読み始める位置を選ぶTRIM_HORIZON (最も古い)、LATEST (最新)、AT_TIMESTAMP (指定時刻)

多くのストリーム処理は「少なくとも1回 (at-least-once)」の配信です。Lambda のイベントソースマッピングも同じレコードを重複して処理することがあるため、関数を冪等に作ります。

④取り込みパイプラインの再現性 ⚠️ 頻出の図 障害後に再開位置を読む ストリーム保持期間内 コンシューマー チェックポイント 書き込み先一意キーで upsert

⚠️ 頻出: 「処理ロジックのバグを直したので、過去3日分を処理し直したい」は、保持期間を延ばしたストリームを AT_TIMESTAMP から読み直すか、S3 に残した raw から再処理します。保持期間の既定は 24 時間なので、長い再処理が要件なら事前に延ばします。

⑤ストリーミングサービスの位置づけ

サービス役割決め手
順序付きのストリームを保持し、複数の処理系が読むAWS ネイティブ、単位の順序、リプレイ
互換のストリーム既存の Kafka クライアント・コネクタを使う
・・ などへ、バッファして配信コンシューマーのコードを書かずに保存したい
ストリームの処理ウィンドウ集計、結合、
メッセージを1つのワーカー群で処理するキューリプレイや複数の処理系は不要、作業の分配

試験対策

①判断マトリクス

問題文のキーワード選ぶ方式・サービス
コンシューマーが増えて遅延が伸びた
書き込みが上限に達した (WriteProvisionedThroughputExceeded)を増やす、モード、キーの見直し
特定のシャードだけ負荷が高いの分散
同じデバイスのイベントは順番どおりデバイス ID をパーティションキーにする
5分ごとの集計、移動平均、セッション処理 ()
1件ずつの変換、マスキング処理 (、 の変換)
過去のデータを処理し直したい保持期間を延ばし、AT_TIMESTAMP から再読込
二重処理しても結果を変えたくないな書き込み (一意キーの )
1つのメッセージを複数のキューへ → の

②よくある誤答

  • の遅延に対して、を増やすこと。読み取りの奪い合いは EFO で解決します。
  • 順序をストリーム全体で保証できると考えること。 の順序はシャード内 (同じ) だけです。
  • に複数の処理系の再読込を期待すること。SQS は受信して削除したメッセージを読み直せません。
  • に長時間の状態を持たせること。状態が必要な集計は か外部ストアを使います。

参考文献

  1. ※1出題比率: AWS 公式の試験ガイドに記載された、採点対象の設問のうちその分野が占める割合です。

検索

キーワードを入力してください