Kinesis Analyticsの適用できない用途と、Kinesis Firehoseの苦労話
•
3 j'aime•5,179 vues
BigData-JAWS 勉強会#6での議論たたき台資料 https://jawsug-bigdata.connpass.com/event/52590/
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Kinesis Analyticsの適用できない用途と、Kinesis Firehoseの苦労話
Similaire à Kinesis Analyticsの適用できない用途と、Kinesis Firehoseの苦労話 (20)
Plus de Sotaro Kimura
Plus de Sotaro Kimura (13)
Kinesis Analyticsの適用できない用途と、Kinesis Firehoseの苦労話
- 1. Kinesis Analyticsの適用できない用途と Kinesis Firehoseの苦労話 2017/04/04 BigData-JAWS 勉強会#6 Kimura, Sotaro（@kimutansk） https://www.flickr.com/photos/haakondagestad/33264255180
- 2. 自己紹介 • Kimura, Sotaro(@kimutansk) – ドワンゴでデータエンジニアやってます • データ分析基盤の管理 • データ分析に必要な各種ETLパイプライン構築 • 生データを集計したデータマートの設計構築 • データフォーマット、内容等の設計 etc... – 好きな技術分野 • ストリーム処理（主にJVM上） • 分散システム • 実装言語：Scala, Go – 好きなAWSサービス • Amazon Kinesis Streams • Amazon Kinesis Firehose • Amazon Kinesis Analytics
- 3. Kinesisとの出会い • Apache Kafkaを試している頃にKinesis Streams発表 – これはつまりManaged Kafkaだ！とわくわく • ということで・・・ – こんなことを試してました。 • Amazon Kinesis + Storm を連携させて、 ストリームデータ処理を行ってみた • http://acro-engineer.hatenablog.com/entry/2013/12/25/151412 – kinesis-storm-spoutがreshardingに対応してない とかにもよくはまっていました • 今はもうresharding対応されています
- 4. アジェンダ • 背景：AWS上のリアルタイムログ収集機構 • 当初の想定システム構成 • Amazon Kinesis Analyticsだ！ > 爆死 • 実際のシステム構成 • Amazon Kinesis Firehose > S3の問題と対処
- 8. ログ収集機構構築の背景 • 目的 – AWS上で稼働しているサービスのログを リアルタイムでオンプレの分析基盤に取り込む • 構築前のログ収集対応 – SCPで日次取得 or 配置するなどの対応 • 問題点 – ログが活用可能になるまでのタイムラグが大きい – 以下のようなリアルタイム経路の機構も使用できない • リアルタイムログ異常確認 • Norikra+Grafanaコンテナ貸出での傾向分析 • 何らかの形でリアルタイム収集を行う必要があった
- 9. ログ収集機構構築の要件 • AWS上のサービスからログをリアルタイムに収集 – 明確に基準があるわけではないが、 ベストエフォートで数秒の遅延で収集 • 障害が発生した場合は後からバッチで取得可能 – 障害例： リアルタイム収集経路のネットワーク切断 サービス上のログの送信プロセスの障害 • 管理コストは極力小さく – 既にオンプレで複数クラスタを保持しており、 チームのリソース的に管理コストはおさえたい マネージドサービスのKinesisファミリーを ベースに検討を進める方針となった。
- 10. 当初の想定システム構成
- 12. 当初の想定システム構成 • Kinesis Streams + AWS Lambda + Kinesis Firehose – リアルタイム経路 • 各サービス上のfluentd > Kinesis Streams • Kinesis Streams > Kinesis Application • Kinesis Application > fluentd – fluentdで内容を基にタグを割り当て、サービス毎に分配 – バックアップ経路 • 各サービス上のfluentd > Kinesis Streams • Kinesis Streams > AWS Lambda • AWS Lambda > Kinesis Firehose – Lambdaで内容を基にサービス毎に分配
- 13. 当初の想定システム構成 • 前述のシステム構成とした理由 – Kinesis Streamsはサービスごとに作成すると 管理コスト・料金が大きくなるため、カテゴリ毎に分割 • ltsv、運用用 etc • AWS上に構築するサービスは、規模は小さめで数が多い • 1サービス1Streamを割り振るのは割に合わない – 上記構成のため、ログをサービス毎に分配する機構が必要 • リアルタイム経路ではfluentd • バックアップ経路ではAWS Lambda
- 14. Amazon Kinesis Analyticsだ！ > 爆死
- 15. システム構築開始時期 • Amazon Kinesis Analyticsが使用可能に！ – 標準SQLで記述可能 – リアルタイム分析アプリケーションを構築可能 – 弾力的にスケール これは、Kinesis Analyticsで サービス毎の分配を実現可能なのでは！？
- 18. Kinesis Analyticsの確認結果 • まずはSQLや設定可能な出力先を確認 – 各カラムの値で出力先切替を記述可能 – 出力先にはFirehoseを選択可能 • よし、機能的には満たせる！？ • しかし・・・
- 19. Kinesis Analyticsの制限に抵触 • 出力先で定義可能な数が限られる • Amazon Kinesis Analytics では、アプリケーション出 力の設定で合計 4 つの宛先をサポートしています。 • ただし、アプリケーションごとの宛先は 3 つに制限 されます。 • このような宛先の 1 つを使用して、アプリケーショ ン内エラーストリームでデータを永続化することをお 勧めします。 参照：http://docs.aws.amazon.com/ja_jp/kinesisanalytics/latest/dev/limits.html この段階でKinesis Analyticsを使用するという案は 潰える・・・
- 20. 実際のシステム構成
- 22. 実際のシステム構成 • fluentd > Kinesis Streams・Firehoseに並列投入 – AWS Lamdaは他の対応にも追われていたため、 オミットして対応を容易にできる構成に変更 • メリット – 初期の構築が容易な構成 • デメリット – fluentdの設定ファイルは各サービス毎に修正が必要 • Firehoseへの投入部分 – 他サービスのAWS Lamda等から直接Kinesis Streamsに 投入する場合、別途バックアップが必要 • ただ、実際はLambdaに入れる時点で別のデータストアに 保持されているため、実質的には問題ない
- 23. 実際のシステム構成 • fluentd > Kinesis Streams・Firehoseに並列投入 – AWS Lamdaは他の対応にも追われていたため、 オミットして対応を容易にできる構成に変更 • メリット – 初期の構築が容易な構成 • デメリット – fluentdの設定ファイルは各サービス毎に修正が必要 • Firehoseへの投入部分 – 他サービスのAWS Lamda等から直接Kinesis Streamsに 投入する場合、別途バックアップが必要 • ただ、実際はLambdaに入れる時点で別のデータストアに 保持されているため、実質的には問題ないこの構成で、リアルタイム経路と、 バックアップ経路の分配は問題なく完了
- 24. Amazon Kinesis Firehose > S3の 問題と対処
- 25. Kinesis Firehose > S3の難点 • Amazon Kinesis Firehose > S3を用いることで、 バックアップ用の経路自体は容易に構築 – 加えて、投入分ベースの金額のため、 起動しっぱなしでも金額がかからないのは素晴らしい • ただ、S3への投入仕様が扱いにくく、 復旧用のクライアント作成時に手間取った • Kinesis Firehose > S3の扱いにくい点 – S3のディレクトリ構成が使いにくい – 出力サイズが別システムに取り込む際に不適切
- 26. S3上のディレクトリ構成 • 「【ベースディレクトリ】YYYY/MM/DD/hh」 • 時刻はUTCベース • ファイルへの蓄積が始まった時刻ベースで、 配置先ディレクトリとファイル名が決定 /sample_service/2017/03/15/01 sample_service-1-2017-03-15-01-09-27-【Hash】.gz sample_service-1-2017-03-15-01-24-29-【Hash】.gz sample_service-1-2017-03-15-01-39-30-【Hash】.gz sample_service-1-2017-03-15-01-54-31-【Hash】.gz /sample_service/2017/03/15/02 sample_service-1-2017-03-15-02-09-31-【Hash】.gz sample_service-1-2017-03-15-02-24-33-【Hash】.gz sample_service-1-2017-03-15-02-39-35-【Hash】.gz sample_service-1-2017-03-15-02-54-35-【Hash】.gz
- 27. S3上のディレクトリ構成 • 以下の対応を行って対処 – 日付と実行元のLocationを基にディレクトリを算出 – 例：Asia/Tokyo”で2017/01/20のログ取得時の対象 • 2017/01/19/15 • 2017/01/19/16 • ・・・・ • 2017/01/20/13 • 2017/01/20/14 • 決して難しくはないのだが、手間取るし面倒・・・
- 28. 出力サイズが不適切 • ログがMAX15分 or 128MBのバッファリング – 生ログで128MBに達した時点で圧縮され、S3に出力 • そのため、そのままHDFSにアップするとブロック無駄遣い – 前述の通りファイルの配置先とファイル名は 「該当ファイルへの蓄積開始時刻ベース」 • つまり、hh=01ディレクトリ配下に JST 10時～11時のログが出力される・・・ /sample_service/2017/03/15/01 sample_service-1-2017-03-15-01-54-31-【Hash】.gz /sample_service/2017/03/15/02 sample_service-1-2017-03-15-02-09-31-【Hash】.gz 概ね 2017-03-15T10:54:31+09:00～ 2017-03-15T11:09:31+09:00のログを含む
- 29. 出力サイズが不適切 • 以下の対応を行って対処 – 取得後、1日分解凍＞結合し再圧縮し、HDFSにアップ • Splitableな形式のため、上限は気にしない。 • gunzip > ファイル結合 > 結合元ファイル削除 > 再圧縮・・ – 前後の1時間を余計に取得し、 クレンジング（データレイク化）の際に必要な時間に絞る • 前だけ取得すればいいという説もあるが、ストリーム処理は 本質的にOut of orderのため、遅延は発生しえると判断 • 遅延許容(DataflowでのAllowedLateness)は1時間と設定 • こちらも決して難しくはないのだが・・・
- 30. まとめ • Amazon Kinesis Analyticsは分配用としては 使用できない。 – 用途としては解説通り以下が適すると思われる。 • ストリームデータの複数出力先への複製 – 複製であれば、数は3つに収まるため • ストリームデータの変換 – Join、Window集計 etc • Amazon Kinesis Firehoseはフルマネージドで、 料金も使用しやすい。 – ただ、S3連携は以下のようにかゆい所に手が届かない • S3のディレクトリ構成が使いにくい • 出力サイズが別システムに取り込む際に不適切
- 31. Thank you for your attention! https://www.flickr.com/photos/84676839@N08/33487448221