【レポート】AWS Summit Tokyo 2017: AWSでのストリーム処理入門 #AWSSummit

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。

当エントリでは、AWS Techトラック 3のセッション、「 AWS でのストリーム処理入門」をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通りです。

概要

AWSでストリーム処理を実践するための入門レベルの話

自己紹介

• 半場 光晴
• ソリューションアーキテクトとしてAWSの利活用に関して技術的な支援

セッションでお伝えしたいこと

• どのような処理にストリーム処理がマッチするのか
• ストリーム処理にAmazon Kinesisを選択することの利便性

セッションの内容

1. ストリーム処理の概要
2. Amazon Kinesisの特徴
3. Amazon Kinesis を用いたストリーム処理の適用例

ストリーム処理の概要

• ストリーム処理がなぜ必要なのか
• ストリーム処理には何が必要なのか
• ストリーム処理の典型的な利用シナリオ

多くのデータが継続的に発生している

サービスを運用すると、様々なデータが生成され続ける 次々に発生するタイムリーにデータを取得したい ストリーム処理は永続的に発生するデータを素早く捉え続ける

なぜ今をしることが有益なのか?

• 時間の経過とともにデータの価値は失われる
• 新鮮なデータに価値がある
• 過去に得た洞察も、時間がたつと、陳腐化する
• 最新のデータで洞察をアップデータをし続ける
• 最新情報と過去の情報を組み合わせることで、情報を高められる
• ストリーム処理は鮮度の高い情報で次のアクションを決める上で非常に有効

リアルタイムなストリーム処理の要素

パイプライン

• データを取り込み
• 前処理のための変換
• 分析
• リアクション
• データを永続化

このパイプラインを永続的に発生するデータの流量の変化に追従して、実行し続ける必要がある

流量に応じて実行し続けるためには以下が必要

• 取り込んだデータをロストしてはいけない
• 流量に応じて、一定の処理性能を維持
• 安定して稼働

これらを実装して保守するのは重要だが直接的にビジネス価値を生み出すものではない。 そのため、マネージド・サービスの Amazon Kinesis にオフロードし、コアビジネスに注力すべし

ストリーム処理の典型的なシナリオ

• 広告・マーケ
• IoT
• ゲーム
• 運用・セキュリティ

処理の流れ

• STep1:取り込み／変換／ロード
• STEP2:タイムリー・継続的にメトリクスを生成し続ける
• STEP3:分析、機械学習や次のアクションにつなげる洞察

Kinesis の実例

• Cookpad 様の昨年のAWS Summit Tokyoでの資料

バッチ処理とストリーム処理の違い

バッチ処理

• サイズ・時刻
• 最初・終了が明確
• 有限なデータをもとに、一時的な処理を実行

バッチ的なストリーム処理方法

無限のデータを有限に処理

• 無限なデータを有限に切って、定期実行
• 時間ベース
• ファイルサイズベース

課題

• 区間をまたいだ分析が苦手
• 区間をまたぐには結果の出力が遅延し、時間を浪費する

ストリーム処理

• 無限のデータを逐次処理
• 永続的に処理し続ける

ストリーム処理のウィンドウ

データを区切るのではなく、ストリーム処理側で擬似的に時間を区切りながら、無限のデータを逐次処理し続ける

擬似的な区切りを「ウィンドウ」と呼ぶ

以下の3パターンがある

• fixed：重複のない固定長ウィンドウ
• sliding：部分的に重複
• sessions:可変長の開始・終了をもつウィンドウ

区切りとなる時間はどの時間？

ストリーム処理のタイムスタンプは3種類ある

1. イベント時刻(event time):イベントが発生した時刻
2. 収集時刻(ingest time):ストリームにデータが入った時刻
3. 処理時刻(processing time):イベントレコードが処理対象として補足された時刻

クライアントでオフラインが発生したり、ネットワーク障害でイベント時刻と処理時刻が異なることは多々ある。

以下を考慮

• ストリーム処理で時間軸が必要な処理をする場合には、どの時刻を使ってどのような間隔で処理を発火させるのか
• どの時間軸を使って、どの程度遅れるかもしれないデータを待ち続けるのか

参照

• The world beyond batch: Streaming 101 - A high-level tour of modern data-processing concepts. By Tyler Akidau August 5, 2015
• The world beyond batch: Streaming 102 - The what, where, when, and how of unbounded data processing. By Tyler Akidau January 20, 2016

データの到達遅延はバッチ処理とストリーム処理のどちらにも存在する

以下のトレードオフ

• 完全性
• レイテンシ(即時性)
• コスト(複雑さ)

例えば、データの到達遅延を許容すると、結果出力は遅延し、レイテンシは上昇する。また、ウィンドウ跨ぎをあとから補正しようとすると、システムの複雑さが増す

サービス要件に見合うように3つのバランスを取る事が重要

バッチ処理とストリーム処理の対比

処理はバッチ処理の上位互換

バッチとストリーム処理を組み合わせて、3つのバランスを取ったサービスを構成することが重要

ストリーム処理のウィンドウやタイムスタンプを利用したAWSでの事例

Gunosy さまの事例

• Kinesis Firehoseを利用してログの取り込み・変換・ロードの加速
• Kinesis Analyticsを利用して継続的なメトリクスの生成

詳細

• Gunosy Amazon Kinesis AnalyticsとES/Kibana4でリアルタイムダッシュボード構築

Kinesis の紹介

ここからストリーム処理を効率的に行うための Kinesis の紹介

Amazon Kinesis 全般の特徴

3種類ある

• Kinesis Streams
  • ストリーム処理をする独自アプリケーションで利用
• Kinesis Firehose
  • S3, Redshift, Elasticsearch にストリームデータを配信
• Kinesis Analytics
  • Streams/Firehoseのストリームデータに標準SQLをなげる

Amazon Kinesis の事例

事例の業種・用途は多岐に渡る

サードパーティーコネクター

ストリームと連携するために、多くのベンダーがツールを出している

Amazon Kinesis の構築を得意とするパートナー

日本ではクラスメソッドが登録されている

Amazon Kinesis :ストリーム処理

• 簡単に利用できる
• リアルタイムな処理が可能
• 個別の用途に合わせられるサービス
• 従量課金
• 利用しやすい

Kinesis Streamsの紹介

• Step1:取り込み／変換／ロードの加速を担う
• Step2,3 はスコープ外

ストリーム処理の基礎を担う

特徴は3つ

• ストリームの作成・キャパシティの上下までスケールコントロールがかんたん
• 独自アプリケーションの実装が可能
• 低コスト:従量課金であらゆるワークロードに高いコスト効果を発揮

アーキテクチャー概要

• 数100万のクライアントから100TB/時間 のような大規模なストリームデータを受取可能
• ストリームに書き込まれたデータは3AZに分散.可用性／耐久性を高めている
• ストリームに対して、複数のアプリをぶら下げられる。サービスの要求に合わせて並列でアプリを実行可能

主要コンセプト

• ストリームは内部的にシャードで構成
• シャードを増減させて、ストリームの処理能力を変動
• ストリームのデータは最大で7日間データ保持可能

データレコードの分散

• partition key を渡してデータを書き込む
• このキーのハッシュ値により、振りあてられるシャードがきまる
• partition key を分散させれば、シャードも分散される
• partition key の設計は十分に考慮すること

順序性

• シーケンス番号が割り当てられる
• ストリーム内でユニーク
• シャード内で順序保障される
• シーケンス番号で読み取り開始位置を指定できる

プロデューサー・コンシューマー

• プロデューサー:データを書き込む
• コンシューマー:データを読み取る
• プロデューサーとコンシューマーは様々な組み合わせが考えられる
  • AWS マネージドサービス
  • 独自実装
  • 互換性のあるサードパーティー

利用料金

3つの軸で構成される

• シャード数
• PUTリクエストの量
• ストリームデータの保持期間

Kinesis Firehoseの紹介

• STEP1:取り込み・変換／ロードの加速
• STEP2, 3 はスコープ外

を担うサービス

東京ではまだ利用できない Kinesis Streamsがあるのに、なぜKinesis Firehoseが必要なのか？

Firehoseの特徴4つ

• 管理不要.配信先を選んでFirehoseを作成すれば、あとはストリームにデータ投入するだけ
• データストアとダイレクトに結合(S3, Redshift, Elasticsearch)
• シームレースにスケール：スケールコントロールは不要。自動的にスケール
• サーバレスETL：Lambdaを使ってフォーマットの変換などを行える

主要なコンセプト

• 配信ストリームを作成するだけ
• パーティションキーやシャードのコントロールは不要
• 無制限にスケール。シャード数の管理は不要。

S3 への配信

• バッファリング後にS3出力
• オプションでLambdaを使い、データレコードの変換処理可能
• 変換失敗時には、失敗レコードが別バケットに流れる。→リカバリに利用

Redshift への配信

• S3経由でロードされる
• バッファリング後にS3書き込み
• その後、定期的にRedshiftに定期的にロード
• オプションでLambdaのデータ変換可能
• 変換失敗時には、失敗レコードが別バケットに流れる。ロード失敗時には、記録される。→リカバリに利用

Elasticsearch への配信

• バッファリング後に書き込み
• オプションでLambdaのデータ変換可能
• 変換失敗、変換結果によらず全データをバケット書き込み可能。
• Elasticsearch に書き込まれなかったデータも記録される。→リカバリに利用

利用料金

• 流入量で料金が決まる

Kinesis Analytics の紹介

• Step 1はスコープ外
• Step 2:継続的なメトリクスの生成
• Step 3:分析

とより高度な処理を担う

3つの特徴

• 標準SQLでStreams/Firehoseにクエリー可能
• 1秒以下のレイテンシーで連続的にクエリーし続ける事が可能
• 弾力的にスケール：SQLの複雑さ等によって自動スケール

主要なコンセプト

• 分析単位でアプリケーションを作成
• アプリごとにソース(Streams/Firehose)・デスティネーションを用意
  • デスティネーション：アプリ毎に3つまで定義可能

実装例

• 内部ストリーム→ポンプ(SQL)→出力ストリーム
• select insert するアプリを「ポンプ」と呼ぶ

時間軸対応

3つのタイムスタンプに対応している

• イベント時刻：your_own_event_time_column
• 収集時刻：approximate_arrival_time
• 処理時刻：rowtime

ウィンドウ問い合わせ

• タンブリングウィンドウ(固定ウィンドウの一種)→対応
• スライディングウィンドウ→対応
• セッションウィンドウ:条件を駆使すれば実現可能

ユースケース

• 10秒のスライディングウィンドウから変化量を算出
• 閾値を超えるデータを抽出し、アラートを発火

参照テーブルの結合

• S3 にマスタデータを設置し、参照テーブルとして結合可能
• PUMP のSELECTのなかでJOINすればOK

料金

• 東京ではまだ利用できない
• KPU(Kinesis Processing Unit)によって決まる

ストリーム処理の適用例

はじめの123歩

ストリーム処理を始めたい人は、以下の流れで作業すると良い

1. 可視化
   • FirehoseからElasticsearchにシステム監視項目を流す
   • テストデータを流したいときは、KDG(Kinesis Data Generator)を利用すると、簡単にテストデータを生成出来る
2. 仮説検証
   • S3にバックアップをとっておくと、Athenaを使ってS3に対してクエリー可能
   • 過去に遡って検証可能
3. 自動化
   • 検証の結果、恒常的にアクション取るべきと判断すれば、Kinesis Analyticsにする
   • クエリーにマッチする条件が検出されれば、Lambda→SNSなどで、マッチした条件にアクションを取る

Elasticsearch Service 再訪

• OSSのElasticsearchとKibanaを利用するマネージドサービス
• Elasticsearchは検索エンジン・分析・監視として非常に人気
• OSS版ElasticsearchのAPIをそのまま利用可能。
• クラスター内のノード障害、ノード入れ替え含めて自動で行う。可用性・信頼性
• Kinesis以外の他のAWSサービスとも緊密に連携

Kibanaによる可視化

• 非常にな可視化ツール
• OSS の可視化ツールを牽引
• Elasticsearch Service には Kibanaも含まれている

Kinesis Data Generator

• https://aws.amazon.com/blogs/big-data/test-your-streaming-data-solution-with-the-new-amazon-kinesis-data-generator/
• https://github.com/awslabs/amazon-kinesis-data-generator
• 簡単にデータを生成
• 毎秒数1000のレコードを連続して送信可能
• 固定・ランダムデータに対応
• 継続利用のために、テンプレート保存可能

Amazon Kinesis Analyticsとストリーム

Firehose/Streams -> Analytics -> Firehose -> Redshift -> ...
                              -> Streams ->A pp -> ...

と連鎖させることもできる

Amazon EMRとの結合パターン

• 独自のストリームアプリケーションとして分散システム Amazon EMRを利用できる
• より大量のストリームデータを扱うことが出来る
• レイテンシーをあげずに複雑な処理が実行しやすくなる
• 分散処理システムの選択によってストリーム処理の完全性・レイテンシー・コストのパラメーターは好きにふれる
• Kinesis StreamsとSpark/EMR->Redshiftの連携も可能。
• tumbling Windowを利用したレポーティング
• 連携にはKinesis Client Library・AWS SDKを利用する
• tumbling/Fixed Windowによる集約

KCL

• KCL は分散処理だけのものではない
• AWS SDKに比べてよりハイレベルなAPIを提供
• より簡単にストリーム処理を実装出来る
• ステート管理にAmazon DynamoDBを利用。
  • シャードとワーカーのマッピング
  • どこまでレコードを処理したかのチェックポイント
  • ワーカーインスタンス／シャードの増減を管理

AWS Lambda

• EMRを使うまでもないような、よりシンプルな処理で利用。
• サーバーレスに処理

セッションの振り返り

• ストリーム処理の適用シーン
• Amazon Kinesis の利便性
• ストリームとバッチの対比
  • 完全性/レイテンシ/コストのトレードオフ
  • ストリームはバッチの上位互換
  • ストリーム・バッチの二者択一ではない。サービス要件に応じて適宜使い分け、パイプラインを最適化すること
• ストリーム処理の運用は難しい。直接的にビジネス価値を生み出すものではないので、マネージドサービスのAmazon Kinesisを利用し、その上にアプリを構築したほうが良い。
• ストリーム処理初心者は、ストリーム処理123歩にしたがって始めると良い

最後に

• ストリーム処理は Kinesisの3種類のサービスを使い分ければ怖くない
• 一人でも多くの人がストリーム処理に取り組んでくれれば幸い

感想

• バッチ処理とストリーム処理の特性
• AWSの提供するフルマネージドなAmazon Kinesisファミリーサービス概要とユースケース
• Kinesis と S3/Redshift/Elasticsearch Service/EMR/Lambda など他のAWSサービスとの連携

がコンパクトにまとまっており、スッキリと整理する事ができました。

セッション終盤で紹介頂いた様に、弊社クラスメソッドはKinesis Service Delivery Programを取得した日本で唯一のパートナーでもあります。Kinesis案件について気になるところがありましたら是非ともご相談頂けますと幸いです。(※大事な事なので2回言ってみました)