MWAA＋Redshiftで構成されたデータ基盤の構築

BigData-JAWS 勉強会#18 登壇資料

https://jawsug-bigdata.connpass.com/event/215161/

こちらのイベントで発表した内容です。

Transcript

1. 〜 のデータ基盤〜 MWAA＋Redshiftで 構成されたデータ基盤の構築 2021/09/07 19:00~ BigData-JAWS 勉強会#18 面白法人カヤック 池田将士 @mashiike
2. アジェンダ 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5. まとめ 6. 次回予告
3. 自己紹介 ※アイコンは季節によってバリエーションがあります Github,Twitter: @mashiike 所属: 技術部 役割: • データエンジニア • サーバーサイドエンジニア • SRE 趣味: オンラインゲーム ※2021/09 時点ではElite: Dangerousをプレイ 日本酒: 八海山
4. 会社紹介 商号：株式会社カヤック 所在地：鎌倉 事業内容： 日本的面白コンテンツ事業
5. 会社紹介 　　　　　　は、一言でいうと・・・ 誰かが面白そうだ！と思ったことを一緒にやる会社（語弊） 『つくる人を増やす』そんな経営理念の会社です https://www.kayac.com/vision/vision 弊社ホームページより
6. 事業紹介 『大会』は選手にとって晴れ舞台 しかし、大会を主催するためには大きな労力が必要 大会主催者の力になる！ このミッションを実現する世界的な大会プラットフォームを目指しています
7. アジェンダ（再掲） 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5. まとめ 6. 次回予告
8. 背景 Tonamelは2017年7月7日からβサービス開始（当時の名前はLobi-tournament） モジュラモノリスなPerlアプリケーションとして成長 本番Aurora MySQL DB Readerに直接アクセス
9. 背景 2020年11月にダブルエリミネーションの実装 トーナメント表管理モジュールが独立し、Go言語製のマイクロサービス ユースケースや負荷等に適切であろうDynamoDBをデータソースとして採用 Read Heavy 『Purpose built databases』
10. 背景 Redashからトーナメント表の データにアクセスできない！！！ サービスの成長により、アプリケーションの構成が変わり、 データのサイロ化が加速し始めました。 新たなるデータ基盤の必要性 2021年1月、、、 Tonamelデータ基盤構築プロジェクトが始動 (立案は2020年12月）
11. 課題 1. サービスの状況由来の課題として • 今後は旧来の様々なモジュールの分離独立を予想 • 新機能は最初から、マイクロサービスとして実装 モジュラモノリスアーキテクチャー =>マイクロサービスアーキテクチャー データソースは多種多様、データ量の著しい増大 2. データ基盤の構築における課題として • 社内のデータエンジニアの層が薄い。人という意味でコストが厳しい 構築は1人（分業） 保守・運用も1人（分業） 期間は7月くらいまでに何かそれっぽいものが・・・ 楽に作れる! 管理コストの低め ! 　スケーラブルなデータ基盤が必要！！！！
12. アジェンダ（再掲） 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5. まとめ 6. 次回予告
13. un 　　　本格運用 構築 調査・設計 立案 スケジュール 構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月: プロジェクト立案（リソース調整） 2021年1月: データ基盤設計（現状のワークロード調査） 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用 人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜
14. 主な検討要素 1. ワークフローオーケストレーションはどうするのか？ • Cron(or CloudWatch Events)+スクラッチ開発 • Glue • Step Functions • Apache Airflow => 使い勝手はステロイドCronなのでよいが、インフラ管理が大変 2. データ保管場所（どこにデータを集める？） そしてクエリエンジンどうする？ • S3 + Athena • Aurora MySQL • Redshift • BigQuery? コレ使いたいが、インフラの構成と管理が大変
15. 主な検討要素 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を採用
16. どこにデータを集めるのか？ 最終的にS3案とRedshift案まで絞ることができました。 その際、AWSの方とご相談する機会があり、大いなるお力添えを頂きました。　 ※BigQueryは今後のデータ量増大によるNATGatwayの通信量とノウハウの少なさから選択肢からなくなる。 Redshift S3 (+ Aurora MySQL）
17. どこにデータを集めるのか？ データを集める場所を決める際の大きな決定要素 • データレイクの構築ノウハウがない • サイロ化はできるだけ防ぎたい • Redshiftの運用ノウハウは社内にある。 • SQL実行構文の差異をできるだけ少なくしたい（PrestoとMySQLは結構差がでかい） MWAA + Redshiftによるデータ基盤 最終的には に決定
18. 設計完了 Redshift案（再掲） Redshift MWAA
19. un 　　　本格運用 構築 調査・設計 立案 スケジュール（再掲） 構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月: プロジェクト立案（リソース調整） 2021年1月: データ基盤設計（現状のワークロード調査） 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用 人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜 2月初旬：設計完了
20. 実際に構築を開始してみたら・・・ • 必要となるユースケースの優先順序が低下 • Redshift MySQL Federated Queryのプレビューが開始 構築を先送り 楽に構築でき、プレビューでの使用感も良いのでFederated QueryのGAを待つことに
21. 実際に構築を開始してみたら・・・ SUPERがDynamoDBと相性良い！ • DDB StreamをKinesisで取り込み。 • PartiQLでわかりやすいアクセス！
22. 実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に!
23. 実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に! JSON in JSON
24. 実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に! Varcharで定義して json_parseでSuper型に
25. 実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に! クエリしやすい！ ※enable_case_sensitive_identifier を TRUEにしておくこと CamelCaseのKeyなJSONデータも読めるのでおすすめ。
26. 実際に構築を開始してみたら・・・ AirflowはDAGと呼ばれるものの単位でワークフローを表現 DAGはタスクの依存関係で表現 タスクの実装は以下の組み合わせで表現 • Operator : 処理を実行するもの • Sensor : 処理を待つもの・検出するもの 3rdParty製のOperatorがたくさんある 自作のCustomOperatorもできる。
27. 実際に構築を開始してみたら・・・ Airflowはタスクの実行管理のためのGUIが超強力 Cronの延長として使う分には困ることは少ない
28. 実際に構築を開始してみたら・・・ CustomOperatorは沼 • テストがないと辛い。 • Airflowのアップデートの影響を思わず受ける （Hook消滅、import path変更 etc…) • トラブルシュートが大変 • Pythonに書きなれてないと大変 LambdaやECS Taskを起動するようなOperator BashOperatorの積極的な利用をおすすめします。 （でも使いこなせると便利）
29. 実際に構築を開始してみたら・・・ CustomOperatorでUNLOAD! S3に書き出す。 COPYコマンドでS3から読み込む！！！ S3の読み書きで データレイク的なものはできる。 しかし、、、 データカタログがないので沼化！！！ Lake Formationの出番か？
30. 実際に構築を開始してみたら・・・ データ基盤の性能としては良いのでは？ • MWAAの(Custom)Operatorで任意の場所にデータを搬送可能 (Slack, Spreadsheet, S3, etc…: 色々なレポーティング) • DDB Streamは実質的にはChange Data Capture (DDB StreamをMinutelyで処理を行っている。遅延が大体5分以内) • Redshiftのコンピューティングのちからは強い PreviewのMySQL Federated Queryも加われば、 ほぼ全てのデータがニアリアルタイムでRedshiftに集約可能 　（GAが待ち遠しい） 何より、管理が楽
31. un 　　　本格運用 構築 調査・設計 立案 スケジュール（再掲） 構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月: プロジェクト立案（リソース調整） 2021年1月: データ基盤設計（現状のワークロード調査） 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用 人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜 2月初旬：設計完了 6月：本格的な運用開始
32. アジェンダ（再掲） 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5. まとめ 6. 次回予告
33. 実際のデータ基盤の活用例 (認定大会支援） ゲームデベロッパーや3rdパーティと協力し、大会主催者の応援活動 支援の条件がタイトルごとに異なる
34. 実際のデータ基盤の活用例 (認定大会支援） 従来の運用フロー ここが大変！ Redashからトーナメント表データにアクセスできないので、 TonamelサービスのWeb上で公開されている情報をオペレータが確認しに行っていた。 確認するものの例 • 大会規模 • 大会開催日時 • 参加者のアクセス情報 etc... 従来は 人の目が頼り
35. 実際のデータ基盤の活用例 (認定大会支援） データ基盤を使った運用フロー Spreadsheetをデータ基盤が読んで、判断に必要な情報を付加して書き戻すようにした。 基本的には Spreadsheet を見ればOK MWAAのDAG
36. 実際のデータ基盤の活用例 認定大会支援 • オペレータがWebサイトを見に行く必要がなくなり業務が効率化 カスタマーサポート • DynamoDBの情報を見れるため、Redashからトーナメント表情報を参照可能 マーケティング • KPIのSlack通知や初歩的なオートメーションで素早く情報キャッチ MWAA+Redshiftによるデータ基盤の導入よって・・・
37. まとめ サービスの成長に伴い、データベースが増える そのため、データのサイロ化が加速 そこで、MWAA＋Redshiftでデータ基盤を構築・運用し始めた メリット • SQLだけでほぼETLが完結する • RedshiftにSuper型が登場、半構造データが取り扱い！より強力になった。 • MWAA(Airflow)はCronの延長として使う分には使いやすい。 • インフラの構成・管理が楽 デメリット • この構成だけだと、データカタログがないのでS3が沼化し始める • CustomOperatorに手を出すと沼に浸かり始めるので要注意 その他 • 弊社ではデータエンジニアの仲間を募集しています。 （助けてください。）
38. 次回予告 なんとか軌道に乗ってきたTonamelのデータ基盤、 　　　そこに様々な問題が浮上する。 https://nakanoshima-dev.connpass.com/event/221243/ 発表予定
39. Develop環境にしか 存在しない機能やマイクロサービス Production環境 Develop環境 • 『Productionにテーブルができるのは・・・リリース前日かなー？』 • 『リリースしたらできる限り早くデータを見たい。これとこれ・・・』
40. 増え続けるコピペ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の申請というのもあ りまして・・・』
41. 迷走し始める のデータ基盤…　そして、現る救世主 https://www.getdbt.com/ https://www.amazon.co.jp/Building-Scalable-Data-Warehouse-Vault/dp/0128025107 〜人のスケールはできないが、 データ基盤はスケールさせたい〜 この先、いったい何が待ち受けているのだろうか？
42. 俺（たち）の戦いはこれからだ！！！！ ※データエンジニア周りの採用活動は継続的に行っています。 のデータ基盤 次回： 〜データモデリング編〜 https://nakanoshima-dev.connpass.com/event/221243/ 発表予定
43. 　ありがとうございました