小規模ワークロードにおけるRedshift Serverlessのログの取り扱い

JAWS-BigData 勉強会 #21

Transcript

1. 2022/09/26 19:03 - 19:28 
 BigData-JAWS 勉強会#21 
 面白法人カヤック 池田将士 @mashiike 
 小規模ワークロード向けのRedshift Serverlessのログの取り扱い

2. 自己紹介
 池田 将士 (@mashiike) 技術部 SREチーム所属 好きなAWSサービス Amazon S3 Amazon Kinesis Data Firehose Amazon Redshift 2016年末に入社 入社当時はサーバーサイドエンジニア 現在はデータエンジニア活動 趣味 • ネットゲーム • OSSを書くこと
3. 会社紹介
 鎌倉の地にて、主にWeb技術を用いて 人の印象に深く残るような面白コンテンツを作る会社 ゲームからWebサービス、ミュージアムetc… 様々なことに挑戦
4. 会社紹介
 鎌倉の地にて、主にWeb技術を用いて 人の印象に深く残るような面白コンテンツを作る会社 ゲームからWebサービス、ミュージアムetc… 様々なことに挑戦 https://www.kayac.com/　より引用 本当に多種多様です。

5. こんな弊社では、
 基本的には小規模ワークロード(ra3.4xlarge以上が必要にならない程度）

6. えっ！？ ra3.xlplusより小さいサイズないの！！？
 むしろ・・・

7. そんな 
 にとって嬉しい
 Redshift Serveless GA! 

8. 何が嬉しいのか？
 • 使ったコンピューティング性能に対する課金　
 Redshift Processing Unit (RPU) で測定
 
 • 素早いスケーリング
 
 • 安心な可用性
 (ra3.xlplus 1ノードで運用することもあったので･･･)

9. 何が嬉しいのか？
 • 使ったコンピューティング性能に対する課金　
 Redshift Processing Unit (RPU) で測定
 
 • 素早いスケーリング
 
 • 安心な可用性
 (ra3.xlplus 1ノードで運用することもあったので･･･)

10. 先日、9/22にてこういう内容で話したりも

11. 第3回 AWSで実践！Analytics Modernization ～事例祭り編～ の資料より その内容を要約すると・・・
 安く使うためには！！！ 
 データ取り込み(LOAD)にRPUを使わない！！！

12. 今回の内容は・・・
 小規模ワークロード向けに
 Redshift Serverlessで　（料金がお安く）
 どうやってログデータを取り扱えば良いのか？
 ※仮に Kinesis Data Firehose経由で 
 1分に1回、取り込みに1秒かかるCopyコマンドを発行したとすると...
 24 [分/day] ✕ 0.494 [USD/ RPU hour] ✕ 32 [RPU] = 379.392 [USD/day] ??? 
 真面目にやると多分お高くなる。

13. 今回の内容は・・・
 小規模ワークロード向けに
 Redshift Serverlessで　（料金がお安く）
 どうやってログデータを取り扱えば良いのか？
 ※仮に Kinesis Data Firehose経由で 
 1分に1回、取り込みに1秒かかるCopyコマンドを発行したとすると...
 24 [分/day] ✕ 0.494 [USD/ RPU hour] ✕ 32 [RPU] = 379.392 [USD/day] ??? 
 真面目にやると多分お高くなる。
 0.4 [hour/day] ✕ 0.494 [USD/ RPU hour] ✕ 32 [RPU] = 6.3232 [USD/day] 
 配信中は計算ミスしてましたすみません！ 

14. どうしたら、いいのでしょう！
 　　方針は２つ！

15. 方針1: Redshift Spectrum メリット: ほぼリアルタイムデータ デメリット: SUPER型やマテリアライズドビュー
 といった機能が活用しづらい 方針2: 低頻度にCopy メリット: Redshiftの機能をフル活用できる
 デメリット: データの鮮度
16. 方針1: Redshift Spectrum メリット: ほぼリアルタイムデータ デメリット: SUPER型やマテリアライズドビュー
 といった機能が活用しづらい 方針2: 低頻度にCopy メリット: Redshiftの機能をフル活用できる
 デメリット: データの鮮度
17. Redshift Spectrum
 Amazon S3上に存在するデータを直接参照する機能 before:
 after:
 https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c-getting-started-usi ng-spectrum-create-external-table.html より引用 外部スキーマを定義して 外部テーブルを定義する　（データの取り込みなし）
18. Redshift Spectrum
 Amazon S3上に存在するデータを直接参照する機能 before:
 after:
 https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c-getting-started-usi ng-spectrum-create-external-table.html より引用 外部スキーマを定義して 外部テーブルを定義する　（データの取り込みなし） 外部スキーマの外部テーブルに対してクエリが可能 

19. ところで、Redshift Spectrumを使うとき、
 ログだったら、使いますよね？パーティション
 https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c-spectrum-external-tables.html より引用 1時間に１回起動したとして 
 6 USD/day = 180 USD/month 
 

20. 実は、このパーティション・・・

21. 実は、このパーティション・・・
 実際にS3のオブジェクトがなくても登録できます。
 つまり、1日に一回先読みで1日分入れてしまうと良い。何だったら、1年分でも・・・
22. 実は、このパーティション・・・

23. 実は、このパーティション・・・
 AWS Glue経由でも追加できる。
 
 AWS GlueのAPI経由で追加してしまえば、Redshift Serverlessのワークグループは起きないっぽい
24. Redshift Serverlessで
 Redshift Spectrumを使うときの節約ポイント
 未来のパーティションを予め
 　AWS Glue経由で
 　　たくさん登録しておく

25. 方針1: Redshift Spectrum メリット: ほぼリアルタイムデータ デメリット: SUPER型やマテリアライズドビュー
 といった機能が活用しづらい 方針2: 低頻度にCopy メリット: Redshiftの機能をフル活用できる
 デメリット: データの鮮度
26. 方針1: Redshift Spectrum メリット: ほぼリアルタイムデータ デメリット: SUPER型やマテリアライズドビュー
 といった機能が活用しづらい 方針2: 低頻度にCopy メリット: Redshiftの機能をフル活用できる
 デメリット: データの鮮度 https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/materialized-view-create-sql-co mmand.html Redshift Spectrumのデメリット例:
 マテリアライズドビューのAUTO REFRESH が使えなくなる

27. 方針1: Redshift Spectrum メリット: ほぼリアルタイムデータ デメリット: SUPER型やマテリアライズドビュー
 といった機能が活用しづらい 方針2: 低頻度にCopy メリット: Redshiftの機能をフル活用できる
 デメリット: データの鮮度
28. 方針1: Redshift Spectrum メリット: ほぼリアルタイムデータ デメリット: SUPER型やマテリアライズドビュー
 といった機能が活用しづらい 方針2: 低頻度にCopy メリット: Redshiftの機能をフル活用できる
 デメリット: データの鮮度
29. 毎分 COPYコマンドで取り込むから、RPUをたくさん使うんだ！
 1時間に1回とか低頻度でまとめて取り込めば良いのでは？
 そう思って、Kinesis Data Firehoseの設定を開くと。。。

30. • Kinesis Data Firehoseは止められない
 • 最大でも900秒ごと
 • 流量が多くなるともっと分割されて、COPY回数が増える

31. • Kinesis Data Firehoseは止められない
 • 最大でも900秒ごと
 • 流量が多くなるともっと分割されて、COPY回数が増える
 一体どうしたら良いのか・・・

32. ところで、昔はどうやってKinesisに流れるログを取り込んでいたのか？
 実は、Kinesis Firehoseが発表されたのは 2015.10 、 東京に来たのは2017年 
 https://aws.amazon.com/jp/blogs/aws/amazon-kinesis-firehose-simple-highly-scalable-data-ingestion/
33. ところで、昔はどうやってKinesisに流れるログを取り込んでいたのか？
 実は、Kinesis Firehoseが発表されたのは 2015.10 、 東京に来たのは2017年 
 https://aws.amazon.com/jp/blogs/aws/amazon-kinesis-firehose-simple-highly-scalable-data-ingestion/ https://speakerdeck.com/fujiwara3/aws-devday-tokyo-2019?slide=14 弊社は、隙間家具OSS 『Rin』を使っていた（いる） 
 実は、
 • Kinesis firehoseの取り込み再試行は最大2時間 
 • メンテナンス時に取り込みを止められない 
 • 昔から使い続けてるから変えられない 
 • etc…
 で、まだまだ現役だったりする。 

34. そうだ・・・Rinならば
 S3 NotificationをSQSにずっと溜めておいて、 
 　数時間に一回起動して『一瞬に並列で取り込めば良い！』 

35. そうだ！！？ 時間が来るまで、元のQueueに戻すLambda関数があればいい
 https://github.com/mashiike/sqpulser RinもLambdaで起動するようにすれば、並列 度とスケーリングも良い！ 

36. github.com/fujiwara/Rin
 とても便利です！おすすめです。

37. Redshift Serverlessで
 Copyを使って取り込むときは
 Kinesis Data Firehoseの送信先Redshiftの設定に頼らない
 何か、取り込み間隔を制御できる仕組みを考えよう
 Rinを使うかは置いといて・・・ 

38. 方針1: Redshift Spectrum メリット: ほぼリアルタイムデータ デメリット: SUPER型やマテリアライズドビュー
 といった機能が活用しづらい 方針2: 低頻度にCopy メリット: Redshiftの機能をフル活用できる
 デメリット: データの鮮度
39. 方針1: Redshift Spectrum メリット: ほぼリアルタイムデータ デメリット: SUPER型やマテリアライズドビュー
 といった機能が活用しづらい 方針2: 低頻度にCopy メリット: Redshiftの機能をフル活用できる
 デメリット: データの鮮度 https://aws.amazon.com/jp/about-aws/whats-new/2022/02/amazon-redshift-public-preview-streaming -ingestion-kinesis-data-streams/ 覚えていますか？このPreview どうやら外部スキーマに対する 
 マテリアライズドビューのようです。 
 
 Previewでは手動更新のみですが、 
 GAではどうなるのでしょうか？ 
 
 もしかしたら、Redshift Serverlessの 
 ワークグループが起動したタイミングで 
 24時間分しゅっと取り込んでくれるかもしれないで す?　（願望)

40. • Redshift Serverlessでログを取り扱うときは要注意
 • Kinesis Data Firehoseを使ってCopyすると高くなるかも？
 • 方針は2つ！節約のポイントはそれぞれあるよ！
 ◦ 方針1: Redshift Spectrumを使う
 節約ポイントはAWS Glue経由で未来のパーティションを！
 
 ◦ 方針2: 低頻度Copy
 節約ポイントはKinesis Data Firehoseに頼らない取り込み方法を考え よう！
 （弊社は github.com/fujiwara/Rin の再登場！）
 • プレビュー中のKinesis Data Streamのストリーミング取り込みは
 ちょっぴり期待が高い！
 まとめ

41. えっ！？大規模ワークロードは？
 小さいサイズのProvisiond Clusterを用意し、取り込みを続けるのが多分一番楽。 
 
 このときの注意点は、Proisiond ClusterとServerlessの暗号化を揃えるところ。