Slide 1

Slide 1 text

Kayac. Inc Amazon Aurora MySQL と Amazon Redshift の Zero-ETL Integration について使い所を考えてみた! AWS for Games Live: これからのゲームデータ分析環境を考える 2023/10/19 19:35-20:05 面白法人カヤック 池田将士 (@mashiike)

Slide 2

Slide 2 text

Kayac. Inc @mashiike 面白法人カヤック その他事業部 SREチーム データエンジニア Amazon S3 Amazon Kinesis Data Firehose Amazon Redshift 好きなAWSサービス 最近ハマったゲーム ● ARMORED CORE VI ● City Skylines ● Pay Day 2

Slide 3

Slide 3 text

Kayac. Inc 主にWeb技術を得意とする ゲームやコミュニティなど 多種多様な事業を展開する おもちゃ箱のような会社。 経営理念『つくる人を増やす』

Slide 4

Slide 4 text

Kayac. Inc アジェンダ ● Zero ETL Integrationとは? ● 使い所は? ○ VPC超えが必要な場合 ○ VPC超えが不要な場合 ● まとめ

Slide 5

Slide 5 text

Kayac. Inc Zero ETL Integrationとは? 2023年10月時点でPublic Previewの機能 https://aws.amazon.com/jp/blogs/news/getting-started-guide-for-near-real-time-operational-analytics-using -amazon-aurora-zero-etl-integration-with-amazon-redshift/

Slide 6

Slide 6 text

Kayac. Inc Zero ETL Integrationとは? 少ないステップでAurora MySQLのデータを Redshiftへニアリアルタイムで転送

Slide 7

Slide 7 text

Kayac. Inc 箸休め:実際にお試ししてみた。 慌てすぎてBinlog設定し忘れたり

Slide 8

Slide 8 text

Kayac. Inc 箸休め:実際にお試ししてみた。

Slide 9

Slide 9 text

Kayac. Inc Zero ETL Integrationスゲーぞ! GAが待ち遠しいですね。 https://aws.amazon.com/jp/blogs/news/getting-started-guide-for-near-real-time-operational-analytics-using -amazon-aurora-zero-etl-integration-with-amazon-redshift/

Slide 10

Slide 10 text

Kayac. Inc 🤔使い所 は?

Slide 11

Slide 11 text

Kayac. Inc 『VPC超え』 キーワードは ※ジャガーノートを倒す必要はありません

Slide 12

Slide 12 text

Kayac. Inc 使い所を考える上で大事なポイント。 『VPC超え』が必要か?否か?これで旨味が変わる VPC超えが必要 クロスアカウントなど VPC超えが不要

Slide 13

Slide 13 text

Kayac. Inc 使い所を考える上で大事なポイント。 『VPC超え』が必要か?否か?これで旨味が変わる VPC超えが必要 クロスアカウントなど VPC超えが不要 まずはこちら

Slide 14

Slide 14 text

Kayac. Inc Case.『VPC超え』が必要 1つの会社で 複数のGame運営を行っている場合 単一の統合分析アカウントを持って いるケースが多いと思います。

Slide 15

Slide 15 text

Kayac. Inc 既存手法1. S3 を経由

Slide 16

Slide 16 text

Kayac. Inc 既存手法1. S3 を経由 ● スナップショットなので リアルタイムではない。 ● StepFunctionsなど地味に色々な ものが必要。

Slide 17

Slide 17 text

Kayac. Inc 既存手法2. VPC Peering を活用

Slide 18

Slide 18 text

Kayac. Inc 既存手法2. VPC Peering を活用 ● VPC Peering: 2 つの VPC 間でト ラフィックをルーティングするこ とを可能にするネットワーク接続 ● Redshift Federated Queryや Binlog Clientを使うことができ る。 ● しかし、IP Range等の設定で気 をつける必要があり、結構面倒。

Slide 19

Slide 19 text

Kayac. Inc 『VPC超え』の難点 どうやって異なるネットワーク上にある Aurora MySQLのデータを取ってくるか? ここに難所がある。 他にもPublic Access + IAM認証などの手もある

Slide 20

Slide 20 text

Kayac. Inc Zero ETL Integrationがあるとどうなる?

Slide 21

Slide 21 text

Kayac. Inc Zero-ETLは別アカウントでもOK アカウントが違っても OKということは、 VPCが異なっていても 転送できるということ。

Slide 22

Slide 22 text

Kayac. Inc 『VPC超え』が必要なケースの旨味 Aurora MySQLも RedshiftもStorageは AWS Managedな管理 AWS Managedな領域で ニアリアルタイム転送を やってくれるので 異なるネットワークに あることを考えなくていい。

Slide 23

Slide 23 text

Kayac. Inc 使い所を考える上で大事なポイント。 『VPC超え』が必要か?否か?これで旨味が変わる VPC超えが必要 クロスアカウントなど VPC超えが不要

Slide 24

Slide 24 text

Kayac. Inc 使い所を考える上で大事なポイント。 『VPC超え』が必要か?否か?これで旨味が変わる VPC超えが必要 クロスアカウントなど VPC超えが不要 今度はこちら

Slide 25

Slide 25 text

Kayac. Inc Case.『VPC超え』が不要 1つのゲームの運用チームが ログ分析やゲーム運用のために Redshiftを持っているケース。 同一ネットワークにあるので リアルタイムのデータを見たいときはFederated Queryで十分

Slide 26

Slide 26 text

Kayac. Inc Federated Queryについて詳しく 同一ネットワークにあるMySQLを外部スキーマという形で定義できる。

Slide 27

Slide 27 text

Kayac. Inc Federated Queryについて詳しく 普通のスキーマ 外部スキーマ:MySQL側のテーブルがそのまま並ぶ

Slide 28

Slide 28 text

Kayac. Inc Federated Queryについて詳しく MySQLに次のクエリが発行される SELECT * FROM organization WHERE id = 1

Slide 29

Slide 29 text

Kayac. Inc Federated Queryについて詳しく MySQLに次のクエリが発行された後に、Redshift上で集計する SELECT * FROM organization 全行ロード!!!!! 負荷!!!?大丈夫?

Slide 30

Slide 30 text

Kayac. Inc Tips: とある本番環境のAurora MySQL 1時間毎にスパイクがありますね 1時間ごとにFederated QueryでKPIを集計した結果

Slide 31

Slide 31 text

Kayac. Inc 『VPC超え』が不要なケースでは 同一ネットワークにあるので、 RedshiftからMySQLにクエリを発行して データを取ってくるFederated Queryが あれば十分だが、 大量のデータを取り扱うときに MySQL側の負荷が気になるかも?

Slide 32

Slide 32 text

Kayac. Inc Zero ETL Integrationがあるとどうなる?

Slide 33

Slide 33 text

Kayac. Inc Zero-ETLのある場合 Hyblid Transactional/ Analytical Processing 2種類のストレージを使い分け

Slide 34

Slide 34 text

Kayac. Inc ズバリ、HTAPが嬉しいのは? 『ログデータ』へのクエリ

Slide 35

Slide 35 text

Kayac. Inc CREATE TABLE game_action_log ( action_timestamp TIMESTAMP,   player_id BIGINT, action_type VARCHAR(50), — 省略 purchase_value BIGINT, purchase_unit VARCHAR(6), PRIMARY KEY (action_timestamp, player_id, action_type) ); Aurora MySQLにこんなテーブルを用意

Slide 36

Slide 36 text

Kayac. Inc 用意したテーブルにLogをInsertしちゃう

Slide 37

Slide 37 text

Kayac. Inc OLTPなクエリはFederated Queryで SELECT * FROM federated.game_action_log WHERE action_timestamp >= getdate() - interval ’1 hour’ AND player_id IN (1234, 5678) MySQLのKeyやIndexが 有効的である。

Slide 38

Slide 38 text

Kayac. Inc OLAPなクエリはZero-ETLで WITH game_action_log as ( SELECT action_timestamp , player_id, purchase_value , purchase_unit FROM zero_etl.prod.game_action_log WHERE action_timestamp >= getdate() - interval '1 year' AND action_type = 'purchase' ), monthly_player as ( SELECT DATE_TRUNC ( 'MONTH', DATE(action_timestamp ) ) AS action_month, player_id, purchase_unit , SUM(purchase_value ) AS total_purchase_value FROM game_action_log GROUP BY 1,2,3 ) SELECT action_month , COUNT(distinct player_id) as paid_players, AVG(total_purchase_value ) as arppu FROM monthly_player GROUP BY 1

Slide 39

Slide 39 text

Kayac. Inc 『VPC超え』が不要なケースの旨味 行指向と列指向という 2種類のストレージを活用して用い 効率よく分析をすることができる Redshiftはアクセスするカラム数が多いとク エリに時間がかかるので、 Federated Queryと併用することで効率UP!

Slide 40

Slide 40 text

Kayac. Inc まとめ ● Zero-ETL IntegraionはAWS Managedな領域で CDC(Change Data Capture)をして Aurora MySQLからRedshiftへ ニアリアルタイムにデータを運んでくれるすごい機能 ● この機能の旨味は… ○ VPC超えが必要だった場合は、単純に楽になる! ○ Federated Queryとの併用でHTAPな使い方ができる。

Slide 41

Slide 41 text

Kayac. Inc ご清聴 ありがとうございました