Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
MWAA+Redshiftで構成されたデータ基盤の構築
Search
ikeda-masashi
September 07, 2021
Technology
0
430
MWAA+Redshiftで構成されたデータ基盤の構築
BigData-JAWS 勉強会#18 登壇資料
https://jawsug-bigdata.connpass.com/event/215161/
こちらのイベントで発表した内容です。
ikeda-masashi
September 07, 2021
Tweet
Share
More Decks by ikeda-masashi
See All by ikeda-masashi
運用の役立たないダッシュボードの作り方。
mashiike
3
840
Amazon Aurora MySQL と Amazon Redshift の Zero-ETL Integration について使い所を考えてみた!
mashiike
0
640
Warningアラートを放置しない!アラート駆動でログやメトリックを自動収集する仕組みによる恩恵
mashiike
5
3.7k
Prepalert ~Mackerelアラートにログや集計値を貼り付けてくれるトイル削減ツール~
mashiike
0
1.7k
人狼ゲームで考えるデータ基盤 〜データとはいったい・・・〜
mashiike
0
250
『エンタープライズ』という言葉の重さ 〜Data Vault 2.0をやめた2022年冬〜
mashiike
2
3.8k
Redshift ServerlessとProvisioned Cluster のちょっとした違い
mashiike
0
4.1k
「北欧、暮らしの道具店」のデータ基盤の変遷
mashiike
1
3.2k
小規模ワークロードにおけるRedshift Serverlessのログの取り扱い
mashiike
0
560
Other Decks in Technology
See All in Technology
【若手エンジニア応援LT会】AWSで繋がり、共に成長! ~コミュニティ活動と新人教育への挑戦~
kazushi_ohata
0
180
ABEMA のコンテンツ制作を最適化!生成 AI x クラウド映像編集システム / abema-ai-editor
cyberagentdevelopers
PRO
1
180
AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book
iselegant
15
4k
ユーザーの購買行動モデリングとその分析 / dsc-purchase-analysis
cyberagentdevelopers
PRO
2
110
20241031_AWS_生成AIハッカソン_GenMuck
tsumita
0
110
신뢰할 수 있는 AI 검색 엔진을 만들기 위한 Liner의 여정
huffon
0
380
Forget efficiency – Become more productive without the stress
ufried
0
150
ネット広告に未来はあるか?「3rd Party Cookie廃止とPrivacy Sandboxの効果検証の裏側」 / third-party-cookie-privacy
cyberagentdevelopers
PRO
1
140
大規模データ基盤チームのオンプレTiDB運用への挑戦 / dpu-tidb
cyberagentdevelopers
PRO
1
110
CAMERA-Suite: 広告文生成のための評価スイート / ai-camera-suite
cyberagentdevelopers
PRO
3
270
10分でわかるfreee エンジニア向け会社説明資料
freee
18
520k
生成AIと知識グラフの相互利用に基づく文書解析
koujikozaki
1
150
Featured
See All Featured
Building Your Own Lightsaber
phodgson
102
6.1k
Designing the Hi-DPI Web
ddemaree
280
34k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Unsuck your backbone
ammeep
668
57k
Writing Fast Ruby
sferik
626
61k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
14
1.9k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
GraphQLとの向き合い方2022年版
quramy
43
13k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Transcript
〜 のデータ基盤〜 MWAA+Redshiftで 構成されたデータ基盤の構築 2021/09/07 19:00~ BigData-JAWS 勉強会#18 面白法人カヤック 池田将士
@mashiike
アジェンダ 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5.
まとめ 6. 次回予告
自己紹介 ※アイコンは季節によってバリエーションがあります Github,Twitter: @mashiike 所属: 技術部 役割: • データエンジニア •
サーバーサイドエンジニア • SRE 趣味: オンラインゲーム ※2021/09 時点ではElite: Dangerousをプレイ 日本酒: 八海山
会社紹介 商号:株式会社カヤック 所在地:鎌倉 事業内容: 日本的面白コンテンツ事業
会社紹介 は、一言でいうと・・・ 誰かが面白そうだ!と思ったことを一緒にやる会社(語弊) 『つくる人を増やす』そんな経営理念の会社です https://www.kayac.com/vision/vision 弊社ホームページより
事業紹介 『大会』は選手にとって晴れ舞台 しかし、大会を主催するためには大きな労力が必要 大会主催者の力になる! このミッションを実現する世界的な大会プラットフォームを目指しています
アジェンダ(再掲) 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5.
まとめ 6. 次回予告
背景 Tonamelは2017年7月7日からβサービス開始(当時の名前はLobi-tournament) モジュラモノリスなPerlアプリケーションとして成長 本番Aurora MySQL DB Readerに直接アクセス
背景 2020年11月にダブルエリミネーションの実装 トーナメント表管理モジュールが独立し、Go言語製のマイクロサービス ユースケースや負荷等に適切であろうDynamoDBをデータソースとして採用 Read Heavy 『Purpose built databases』
背景 Redashからトーナメント表の データにアクセスできない!!! サービスの成長により、アプリケーションの構成が変わり、 データのサイロ化が加速し始めました。 新たなるデータ基盤の必要性 2021年1月、、、 Tonamelデータ基盤構築プロジェクトが始動 (立案は2020年12月)
課題 1. サービスの状況由来の課題として • 今後は旧来の様々なモジュールの分離独立を予想 • 新機能は最初から、マイクロサービスとして実装 モジュラモノリスアーキテクチャー =>マイクロサービスアーキテクチャー データソースは多種多様、データ量の著しい増大
2. データ基盤の構築における課題として • 社内のデータエンジニアの層が薄い。人という意味でコストが厳しい 構築は1人(分業) 保守・運用も1人(分業) 期間は7月くらいまでに何かそれっぽいものが・・・ 楽に作れる! 管理コストの低め ! スケーラブルなデータ基盤が必要!!!!
アジェンダ(再掲) 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5.
まとめ 6. 次回予告
un 本格運用 構築 調査・設計 立案 スケジュール 構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月:
プロジェクト立案(リソース調整) 2021年1月: データ基盤設計(現状のワークロード調査) 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用 人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜
主な検討要素 1. ワークフローオーケストレーションはどうするのか? • Cron(or CloudWatch Events)+スクラッチ開発 • Glue •
Step Functions • Apache Airflow => 使い勝手はステロイドCronなのでよいが、インフラ管理が大変 2. データ保管場所(どこにデータを集める?) そしてクエリエンジンどうする? • S3 + Athena • Aurora MySQL • Redshift • BigQuery? コレ使いたいが、インフラの構成と管理が大変
主な検討要素 https://www.youtube.com/watch?v=xiOsbCs7T9k その当時、AWS re:Invent 2020 救世主現る 実はre:Inventの直前に発表はされてた https://aws.amazon.com/jp/about-aws/whats-new/2020/11/introducing-amazon-managed-workflows-for-apache-airflow-mwaa/ マネージドなAirflowがAWSに来た・・・だと・・・ 使うなら今しかないっしょ!!! ワークフローオーケストレーション
MWAAを採用
どこにデータを集めるのか? 最終的にS3案とRedshift案まで絞ることができました。 その際、AWSの方とご相談する機会があり、大いなるお力添えを頂きました。 ※BigQueryは今後のデータ量増大によるNATGatwayの通信量とノウハウの少なさから選択肢からなくなる。 Redshift S3 (+ Aurora MySQL)
どこにデータを集めるのか? データを集める場所を決める際の大きな決定要素 • データレイクの構築ノウハウがない • サイロ化はできるだけ防ぎたい • Redshiftの運用ノウハウは社内にある。 • SQL実行構文の差異をできるだけ少なくしたい(PrestoとMySQLは結構差がでかい)
MWAA + Redshiftによるデータ基盤 最終的には に決定
設計完了 Redshift案(再掲) Redshift MWAA
un 本格運用 構築 調査・設計 立案 スケジュール(再掲) 構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月:
プロジェクト立案(リソース調整) 2021年1月: データ基盤設計(現状のワークロード調査) 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用 人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜 2月初旬:設計完了
実際に構築を開始してみたら・・・ • 必要となるユースケースの優先順序が低下 • Redshift MySQL Federated Queryのプレビューが開始 構築を先送り 楽に構築でき、プレビューでの使用感も良いのでFederated
QueryのGAを待つことに
実際に構築を開始してみたら・・・ SUPERがDynamoDBと相性良い! • DDB StreamをKinesisで取り込み。 • PartiQLでわかりやすいアクセス!
実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に!
実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に!
JSON in JSON
実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に!
Varcharで定義して json_parseでSuper型に
実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に!
クエリしやすい! ※enable_case_sensitive_identifier を TRUEにしておくこと CamelCaseのKeyなJSONデータも読めるのでおすすめ。
実際に構築を開始してみたら・・・ AirflowはDAGと呼ばれるものの単位でワークフローを表現 DAGはタスクの依存関係で表現 タスクの実装は以下の組み合わせで表現 • Operator : 処理を実行するもの • Sensor
: 処理を待つもの・検出するもの 3rdParty製のOperatorがたくさんある 自作のCustomOperatorもできる。
実際に構築を開始してみたら・・・ Airflowはタスクの実行管理のためのGUIが超強力 Cronの延長として使う分には困ることは少ない
実際に構築を開始してみたら・・・ CustomOperatorは沼 • テストがないと辛い。 • Airflowのアップデートの影響を思わず受ける (Hook消滅、import path変更 etc…) •
トラブルシュートが大変 • Pythonに書きなれてないと大変 LambdaやECS Taskを起動するようなOperator BashOperatorの積極的な利用をおすすめします。 (でも使いこなせると便利)
実際に構築を開始してみたら・・・ CustomOperatorでUNLOAD! S3に書き出す。 COPYコマンドでS3から読み込む!!! S3の読み書きで データレイク的なものはできる。 しかし、、、 データカタログがないので沼化!!! Lake Formationの出番か?
実際に構築を開始してみたら・・・ データ基盤の性能としては良いのでは? • MWAAの(Custom)Operatorで任意の場所にデータを搬送可能 (Slack, Spreadsheet, S3, etc…: 色々なレポーティング) •
DDB Streamは実質的にはChange Data Capture (DDB StreamをMinutelyで処理を行っている。遅延が大体5分以内) • Redshiftのコンピューティングのちからは強い PreviewのMySQL Federated Queryも加われば、 ほぼ全てのデータがニアリアルタイムでRedshiftに集約可能 (GAが待ち遠しい) 何より、管理が楽
un 本格運用 構築 調査・設計 立案 スケジュール(再掲) 構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月:
プロジェクト立案(リソース調整) 2021年1月: データ基盤設計(現状のワークロード調査) 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用 人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜 2月初旬:設計完了 6月:本格的な運用開始
アジェンダ(再掲) 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5.
まとめ 6. 次回予告
実際のデータ基盤の活用例 (認定大会支援) ゲームデベロッパーや3rdパーティと協力し、大会主催者の応援活動 支援の条件がタイトルごとに異なる
実際のデータ基盤の活用例 (認定大会支援) 従来の運用フロー ここが大変! Redashからトーナメント表データにアクセスできないので、 TonamelサービスのWeb上で公開されている情報をオペレータが確認しに行っていた。 確認するものの例 • 大会規模 •
大会開催日時 • 参加者のアクセス情報 etc... 従来は 人の目が頼り
実際のデータ基盤の活用例 (認定大会支援) データ基盤を使った運用フロー Spreadsheetをデータ基盤が読んで、判断に必要な情報を付加して書き戻すようにした。 基本的には Spreadsheet を見ればOK MWAAのDAG
実際のデータ基盤の活用例 認定大会支援 • オペレータがWebサイトを見に行く必要がなくなり業務が効率化 カスタマーサポート • DynamoDBの情報を見れるため、Redashからトーナメント表情報を参照可能 マーケティング • KPIのSlack通知や初歩的なオートメーションで素早く情報キャッチ
MWAA+Redshiftによるデータ基盤の導入よって・・・
まとめ サービスの成長に伴い、データベースが増える そのため、データのサイロ化が加速 そこで、MWAA+Redshiftでデータ基盤を構築・運用し始めた メリット • SQLだけでほぼETLが完結する • RedshiftにSuper型が登場、半構造データが取り扱い!より強力になった。 •
MWAA(Airflow)はCronの延長として使う分には使いやすい。 • インフラの構成・管理が楽 デメリット • この構成だけだと、データカタログがないのでS3が沼化し始める • CustomOperatorに手を出すと沼に浸かり始めるので要注意 その他 • 弊社ではデータエンジニアの仲間を募集しています。 (助けてください。)
次回予告 なんとか軌道に乗ってきたTonamelのデータ基盤、 そこに様々な問題が浮上する。 https://nakanoshima-dev.connpass.com/event/221243/ 発表予定
Develop環境にしか 存在しない機能やマイクロサービス Production環境 Develop環境 • 『Productionにテーブルができるのは・・・リリース前日かなー?』 • 『リリースしたらできる限り早くデータを見たい。これとこれ・・・』
増え続けるコピペSQL どうしても、似たような処理が出 てくるよね・・・ CONVERT_TIMEZONE(‘JST’, getdate()) ... CONVERT_TIMEZONE(‘JST’, getdate()) ... CONVERT_TIMEZONE(‘JST’,
getdate()) … DATE_TRUNC(‘hour’, getdate())... DATE_TRUNC(‘hour’, getdate())... DATE_TRUNC(‘hour’, getdate())... 破綻するデータモデル 『実はここ、部分的にSPAでして・・・』 『nginxのアクセスログが 当てにならないだ・・・と・・・』 『実はZONeの申請というのもあ りまして・・・』
迷走し始める のデータ基盤… そして、現る救世主 https://www.getdbt.com/ https://www.amazon.co.jp/Building-Scalable-Data-Warehouse-Vault/dp/0128025107 〜人のスケールはできないが、 データ基盤はスケールさせたい〜 この先、いったい何が待ち受けているのだろうか?
俺(たち)の戦いはこれからだ!!!! ※データエンジニア周りの採用活動は継続的に行っています。 のデータ基盤 次回: 〜データモデリング編〜 https://nakanoshima-dev.connpass.com/event/221243/ 発表予定
ありがとうございました