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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介  池田将士 (@mashiike) 技術部 SREチーム所属好きなAWSサービス Amazon S3 Amazon Kinesis Data Firehose Amazon Redshift 2016年末に入社入社当時はサーバーサイドエンジニア現在はデータエンジニア活動趣味 ● ネットゲーム ● OSSを書くこと

Slide 3

Slide 3 text

会社紹介  鎌倉の地にて、主にWeb技術を用いて人の印象に深く残るような面白コンテンツを作る会社ゲームからWebサービス、ミュージアムetc… 様々なことに挑戦

Slide 4

Slide 4 text

会社紹介  鎌倉の地にて、主にWeb技術を用いて人の印象に深く残るような面白コンテンツを作る会社ゲームからWebサービス、ミュージアムetc… 様々なことに挑戦 https://www.kayac.com/　より引用本当に多種多様です。 

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

方針1: Redshift Spectrum メリット: ほぼリアルタイムデータデメリット: SUPER型やマテリアライズドビュー  といった機能が活用しづらい方針2: 低頻度にCopy メリット: Redshiftの機能をフル活用できる  デメリット: データの鮮度

Slide 16

Slide 16 text

Slide 17

Slide 17 text

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 より引用外部スキーマを定義して外部テーブルを定義する　（データの取り込みなし）

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

実は、このパーティション・・・  AWS Glue経由でも追加できる。    AWS GlueのAPI経由で追加してしまえば、Redshift Serverlessのワークグループは起きないっぽい

Slide 24

Slide 24 text

Redshift Serverlessで  Redshift Spectrumを使うときの節約ポイント  未来のパーティションを予め  　AWS Glue経由で  　　たくさん登録しておく 

Slide 25

Slide 25 text

Slide 26

Slide 26 text

方針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 が使えなくなる 

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

毎分 COPYコマンドで取り込むから、RPUをたくさん使うんだ！  1時間に1回とか低頻度でまとめて取り込めば良いのでは？  そう思って、Kinesis Data Firehoseの設定を開くと。。。 

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

Slide 33

Slide 33 text

ところで、昔はどうやって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…  で、まだまだ現役だったりする。  

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Slide 39

Slide 39 text

方針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時間分しゅっと取り込んでくれるかもしれないです?　（願望) 

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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