Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ikeda-masashi
September 27, 2022

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

JAWS-BigData 勉強会 #21

ikeda-masashi

September 27, 2022
Tweet

More Decks by ikeda-masashi

Other Decks in Programming

Transcript

  1. 2022/09/26 19:03 - 19:28 

    BigData-JAWS 勉強会#21 

    面白法人カヤック 池田将士 @mashiike 

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


    View Slide

  2. 自己紹介

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

    View Slide

  3. 会社紹介

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

    View Slide

  4. 会社紹介

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


    View Slide

  5. こんな弊社では、

    基本的には小規模ワークロード(ra3.4xlarge以上が必要にならない程度)


    View Slide

  6. えっ!? ra3.xlplusより小さいサイズないの!!?

    むしろ・・・


    View Slide

  7. そんな 
 にとって嬉しい

    Redshift Serveless
    GA! 


    View Slide

  8. 何が嬉しいのか?

    ● 使ったコンピューティング性能に対する課金 

    Redshift Processing Unit (RPU) で測定


    ● 素早いスケーリング


    ● 安心な可用性

    (ra3.xlplus 1ノードで運用することもあったので・・・)


    View Slide

  9. 何が嬉しいのか?

    ● 使ったコンピューティング性能に対する課金 

    Redshift Processing Unit (RPU) で測定


    ● 素早いスケーリング


    ● 安心な可用性

    (ra3.xlplus 1ノードで運用することもあったので・・・)


    View Slide

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


    View Slide

  11. 第3回 AWSで実践!Analytics Modernization ~事例祭り編~ の資料より
    その内容を要約すると・・・

    安く使うためには!!! 

    データ取り込み(LOAD)にRPUを使わない!!!


    View Slide

  12. 今回の内容は・・・

    小規模ワークロード向けに

    Redshift Serverlessで (料金がお安く)

    どうやってログデータを取り扱えば良いのか?

    ※仮に Kinesis Data Firehose経由で 

    1分に1回、取り込みに1秒かかるCopyコマンドを発行したとすると...

    24 [分/day] ✕ 0.494 [USD/ RPU hour] ✕ 32 [RPU] = 379.392 [USD/day] ??? 

    真面目にやると多分お高くなる。


    View Slide

  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] 

    配信中は計算ミスしてましたすみません! 


    View Slide

  14. どうしたら、いいのでしょう!

      方針は2つ!


    View Slide

  15. 方針1: Redshift Spectrum
    メリット: ほぼリアルタイムデータ
    デメリット: SUPER型やマテリアライズドビュー

    といった機能が活用しづらい
    方針2: 低頻度にCopy
    メリット: Redshiftの機能をフル活用できる

    デメリット: データの鮮度

    View Slide

  16. 方針1: Redshift Spectrum
    メリット: ほぼリアルタイムデータ
    デメリット: SUPER型やマテリアライズドビュー

    といった機能が活用しづらい
    方針2: 低頻度にCopy
    メリット: Redshiftの機能をフル活用できる

    デメリット: データの鮮度

    View Slide

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

    View Slide

  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 より引用
    外部スキーマを定義して
    外部テーブルを定義する (データの取り込みなし)
    外部スキーマの外部テーブルに対してクエリが可能 


    View Slide

  19. ところで、Redshift Spectrumを使うとき、

    ログだったら、使いますよね?パーティション

    https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c-spectrum-external-tables.html より引用
    1時間に1回起動したとして 

    6 USD/day = 180 USD/month 


    View Slide

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


    View Slide

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

    実際にS3のオブジェクトがなくても登録できます。

    つまり、1日に一回先読みで1日分入れてしまうと良い。何だったら、1年分でも・・・

    View Slide

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


    View Slide

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

    AWS Glue経由でも追加できる。


    AWS GlueのAPI経由で追加してしまえば、Redshift Serverlessのワークグループは起きないっぽい

    View Slide

  24. Redshift Serverlessで

    Redshift Spectrumを使うときの節約ポイント

    未来のパーティションを予め

     AWS Glue経由で

      たくさん登録しておく


    View Slide

  25. 方針1: Redshift Spectrum
    メリット: ほぼリアルタイムデータ
    デメリット: SUPER型やマテリアライズドビュー

    といった機能が活用しづらい
    方針2: 低頻度にCopy
    メリット: Redshiftの機能をフル活用できる

    デメリット: データの鮮度

    View Slide

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


    View Slide

  27. 方針1: Redshift Spectrum
    メリット: ほぼリアルタイムデータ
    デメリット: SUPER型やマテリアライズドビュー

    といった機能が活用しづらい
    方針2: 低頻度にCopy
    メリット: Redshiftの機能をフル活用できる

    デメリット: データの鮮度

    View Slide

  28. 方針1: Redshift Spectrum
    メリット: ほぼリアルタイムデータ
    デメリット: SUPER型やマテリアライズドビュー

    といった機能が活用しづらい
    方針2: 低頻度にCopy
    メリット: Redshiftの機能をフル活用できる

    デメリット: データの鮮度

    View Slide

  29. 毎分 COPYコマンドで取り込むから、RPUをたくさん使うんだ!

    1時間に1回とか低頻度でまとめて取り込めば良いのでは?

    そう思って、Kinesis Data Firehoseの設定を開くと。。。


    View Slide

  30. ● Kinesis Data Firehoseは止められない

    ● 最大でも900秒ごと

    ● 流量が多くなるともっと分割されて、COPY回数が増える


    View Slide

  31. ● Kinesis Data Firehoseは止められない

    ● 最大でも900秒ごと

    ● 流量が多くなるともっと分割されて、COPY回数が増える

    一体どうしたら良いのか・・・


    View Slide

  32. ところで、昔はどうやってKinesisに流れるログを取り込んでいたのか?

    実は、Kinesis Firehoseが発表されたのは 2015.10 、 東京に来たのは2017年 

    https://aws.amazon.com/jp/blogs/aws/amazon-kinesis-firehose-simple-highly-scalable-data-ingestion/

    View Slide

  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…

    で、まだまだ現役だったりする。 


    View Slide

  34. そうだ・・・Rinならば

    S3 NotificationをSQSにずっと溜めておいて、 

     数時間に一回起動して『一瞬に並列で取り込めば良い!』 


    View Slide

  35. そうだ!!? 時間が来るまで、元のQueueに戻すLambda関数があればいい

    https://github.com/mashiike/sqpulser
    RinもLambdaで起動するようにすれば、並列
    度とスケーリングも良い! 


    View Slide

  36. github.com/fujiwara/Rin

    とても便利です!おすすめです。


    View Slide

  37. Redshift Serverlessで

    Copyを使って取り込むときは

    Kinesis Data Firehoseの送信先Redshiftの設定に頼らない

    何か、取り込み間隔を制御できる仕組みを考えよう

    Rinを使うかは置いといて・・・ 


    View Slide

  38. 方針1: Redshift Spectrum
    メリット: ほぼリアルタイムデータ
    デメリット: SUPER型やマテリアライズドビュー

    といった機能が活用しづらい
    方針2: 低頻度にCopy
    メリット: Redshiftの機能をフル活用できる

    デメリット: データの鮮度

    View Slide

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


    View Slide

  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のストリーミング取り込みは

    ちょっぴり期待が高い!

    まとめ


    View Slide

  41. えっ!?大規模ワークロードは?

    小さいサイズのProvisiond Clusterを用意し、取り込みを続けるのが多分一番楽。 


    このときの注意点は、Proisiond ClusterとServerlessの暗号化を揃えるところ。 


    View Slide