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
420
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
790
Amazon Aurora MySQL と Amazon Redshift の Zero-ETL Integration について使い所を考えてみた!
mashiike
0
590
Warningアラートを放置しない!アラート駆動でログやメトリックを自動収集する仕組みによる恩恵
mashiike
5
3.6k
Prepalert ~Mackerelアラートにログや集計値を貼り付けてくれるトイル削減ツール~
mashiike
0
1.7k
人狼ゲームで考えるデータ基盤 〜データとはいったい・・・〜
mashiike
0
230
『エンタープライズ』という言葉の重さ 〜Data Vault 2.0をやめた2022年冬〜
mashiike
2
3.5k
Redshift ServerlessとProvisioned Cluster のちょっとした違い
mashiike
0
3.6k
「北欧、暮らしの道具店」のデータ基盤の変遷
mashiike
1
3.2k
小規模ワークロードにおけるRedshift Serverlessのログの取り扱い
mashiike
0
540
Other Decks in Technology
See All in Technology
Swift Testingのconfirmationを コードリーディング/Dive into Swift Testing confirmation
laprasdrum
2
260
PDF Viewer作成の今までとこれから
hunachi
0
470
なにもしてないのにNew Relicのデータ転送量が増えていたときに確認したこと
tk3fftk
2
230
タイミーのレコメンドにおける ABテストの運用
ozeshun
1
160
Road to Single Activity
yurihondo
2
240
『GRANBLUE FANTASY Relink』キャラクターの魅力を支えるリグ・シミュレーション制作事例
cygames
0
120
アプリをリリースできる状態に保ったまま 段階的にリファクタリングするための 戦略と戦術 / Strategies and tactics for incremental refactoring
yanzm
6
1.4k
Creative UIs with Compose: DroidKaigi 2024
chrishorner
1
590
PdMはどのように全てのスピードを上げられるか ~ 非連続進化のための具体的な取り組み ~
sansantech
PRO
4
1.3k
突撃! 隣のAmazon Bedrockユーザー 〜YouはどうしてAWSで?〜
minorun365
PRO
3
390
ナレッジグラフとLLMの相互利用
koujikozaki
0
420
たった1人からはじめる【Agile Community of Practice】~ソース原理とFearless Changeを添えて~
ktc_corporate_it
1
490
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
190
16k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
What's in a price? How to price your products and services
michaelherold
242
11k
Raft: Consensus for Rubyists
vanstee
135
6.5k
A Modern Web Designer's Workflow
chriscoyier
691
190k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
109
6.9k
Happy Clients
brianwarren
96
6.6k
The Language of Interfaces
destraynor
153
23k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.4k
Producing Creativity
orderedlist
PRO
340
39k
Designing Experiences People Love
moore
138
23k
KATA
mclloyd
27
13k
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/ 発表予定
ありがとうございました