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

Slide 1

Slide 1 text

〜のデータ基盤〜 MWAA＋Redshiftで構成されたデータ基盤の構築 2021/09/07 19:00~ BigData-JAWS 勉強会#18 面白法人カヤック池田将士 @mashiike

Slide 2

Slide 2 text

アジェンダ 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5. まとめ 6. 次回予告

Slide 3

Slide 3 text

自己紹介 ※アイコンは季節によってバリエーションがあります Github,Twitter: @mashiike 所属: 技術部役割: ● データエンジニア ● サーバーサイドエンジニア ● SRE 趣味: オンラインゲーム ※2021/09 時点ではElite: Dangerousをプレイ日本酒: 八海山

Slide 4

Slide 4 text

会社紹介商号：株式会社カヤック所在地：鎌倉事業内容：日本的面白コンテンツ事業

Slide 5

Slide 5 text

会社紹介　　　　　　は、一言でいうと・・・誰かが面白そうだ！と思ったことを一緒にやる会社（語弊）『つくる人を増やす』そんな経営理念の会社です https://www.kayac.com/vision/vision 弊社ホームページより

Slide 6

Slide 6 text

事業紹介『大会』は選手にとって晴れ舞台しかし、大会を主催するためには大きな労力が必要大会主催者の力になる！このミッションを実現する世界的な大会プラットフォームを目指しています

Slide 7

Slide 7 text

アジェンダ（再掲） 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5. まとめ 6. 次回予告

Slide 8

Slide 8 text

背景 Tonamelは2017年7月7日からβサービス開始（当時の名前はLobi-tournament）モジュラモノリスなPerlアプリケーションとして成長本番Aurora MySQL DB Readerに直接アクセス

Slide 9

Slide 9 text

背景 2020年11月にダブルエリミネーションの実装トーナメント表管理モジュールが独立し、Go言語製のマイクロサービスユースケースや負荷等に適切であろうDynamoDBをデータソースとして採用 Read Heavy 『Purpose built databases』

Slide 10

Slide 10 text

背景 Redashからトーナメント表のデータにアクセスできない！！！サービスの成長により、アプリケーションの構成が変わり、データのサイロ化が加速し始めました。新たなるデータ基盤の必要性 2021年1月、、、 Tonamelデータ基盤構築プロジェクトが始動 (立案は2020年12月）

Slide 11

Slide 11 text

課題 1. サービスの状況由来の課題として ● 今後は旧来の様々なモジュールの分離独立を予想 ● 新機能は最初から、マイクロサービスとして実装モジュラモノリスアーキテクチャー =>マイクロサービスアーキテクチャーデータソースは多種多様、データ量の著しい増大 2. データ基盤の構築における課題として ● 社内のデータエンジニアの層が薄い。人という意味でコストが厳しい構築は1人（分業）保守・運用も1人（分業）期間は7月くらいまでに何かそれっぽいものが・・・楽に作れる! 管理コストの低め ! 　スケーラブルなデータ基盤が必要！！！！

Slide 12

Slide 12 text

アジェンダ（再掲） 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5. まとめ 6. 次回予告

Slide 13

Slide 13 text

un 　　　本格運用構築調査・設計立案スケジュール構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月: プロジェクト立案（リソース調整） 2021年1月: データ基盤設計（現状のワークロード調査） 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜

Slide 14

Slide 14 text

主な検討要素 1. ワークフローオーケストレーションはどうするのか？ ● Cron(or CloudWatch Events)+スクラッチ開発 ● Glue ● Step Functions ● Apache Airﬂow => 使い勝手はステロイドCronなのでよいが、インフラ管理が大変 2. データ保管場所（どこにデータを集める？）そしてクエリエンジンどうする？ ● S3 + Athena ● Aurora MySQL ● Redshift ● BigQuery? コレ使いたいが、インフラの構成と管理が大変

Slide 15

Slide 15 text

主な検討要素 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/ マネージドなAirﬂowがAWSに来た・・・だと・・・使うなら今しかないっしょ！！！ワークフローオーケストレーション MWAAを採用

Slide 16

Slide 16 text

どこにデータを集めるのか？最終的にS3案とRedshift案まで絞ることができました。その際、AWSの方とご相談する機会があり、大いなるお力添えを頂きました。　 ※BigQueryは今後のデータ量増大によるNATGatwayの通信量とノウハウの少なさから選択肢からなくなる。 Redshift S3 (+ Aurora MySQL）

Slide 17

Slide 17 text

どこにデータを集めるのか？データを集める場所を決める際の大きな決定要素 ● データレイクの構築ノウハウがない ● サイロ化はできるだけ防ぎたい ● Redshiftの運用ノウハウは社内にある。 ● SQL実行構文の差異をできるだけ少なくしたい（PrestoとMySQLは結構差がでかい） MWAA + Redshiftによるデータ基盤最終的にはに決定

Slide 18

Slide 18 text

設計完了 Redshift案（再掲） Redshift MWAA

Slide 19

Slide 19 text

un 　　　本格運用構築調査・設計立案スケジュール（再掲）構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月: プロジェクト立案（リソース調整） 2021年1月: データ基盤設計（現状のワークロード調査） 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜 2月初旬：設計完了

Slide 20

Slide 20 text

実際に構築を開始してみたら・・・ ● 必要となるユースケースの優先順序が低下 ● Redshift MySQL Federated Queryのプレビューが開始構築を先送り楽に構築でき、プレビューでの使用感も良いのでFederated QueryのGAを待つことに

Slide 21

Slide 21 text

実際に構築を開始してみたら・・・ SUPERがDynamoDBと相性良い！ ● DDB StreamをKinesisで取り込み。 ● PartiQLでわかりやすいアクセス！

Slide 22

Slide 22 text

実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に!

Slide 23

Slide 23 text

実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に! JSON in JSON

Slide 24

Slide 24 text

実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に! Varcharで定義して json_parseでSuper型に

Slide 25

Slide 25 text

実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に! クエリしやすい！ ※enable_case_sensitive_identiﬁer を TRUEにしておくこと CamelCaseのKeyなJSONデータも読めるのでおすすめ。

Slide 26

Slide 26 text

実際に構築を開始してみたら・・・ AirﬂowはDAGと呼ばれるものの単位でワークフローを表現 DAGはタスクの依存関係で表現タスクの実装は以下の組み合わせで表現 ● Operator : 処理を実行するもの ● Sensor : 処理を待つもの・検出するもの 3rdParty製のOperatorがたくさんある自作のCustomOperatorもできる。

Slide 27

Slide 27 text

実際に構築を開始してみたら・・・ Airﬂowはタスクの実行管理のためのGUIが超強力 Cronの延長として使う分には困ることは少ない

Slide 28

Slide 28 text

実際に構築を開始してみたら・・・ CustomOperatorは沼 ● テストがないと辛い。 ● Airﬂowのアップデートの影響を思わず受ける（Hook消滅、import path変更 etc…) ● トラブルシュートが大変 ● Pythonに書きなれてないと大変 LambdaやECS Taskを起動するようなOperator BashOperatorの積極的な利用をおすすめします。（でも使いこなせると便利）

Slide 29

Slide 29 text

実際に構築を開始してみたら・・・ CustomOperatorでUNLOAD! S3に書き出す。 COPYコマンドでS3から読み込む！！！ S3の読み書きでデータレイク的なものはできる。しかし、、、データカタログがないので沼化！！！ Lake Formationの出番か？

Slide 30

Slide 30 text

実際に構築を開始してみたら・・・データ基盤の性能としては良いのでは？ ● MWAAの(Custom)Operatorで任意の場所にデータを搬送可能 (Slack, Spreadsheet, S3, etc…: 色々なレポーティング) ● DDB Streamは実質的にはChange Data Capture (DDB StreamをMinutelyで処理を行っている。遅延が大体5分以内) ● Redshiftのコンピューティングのちからは強い PreviewのMySQL Federated Queryも加われば、ほぼ全てのデータがニアリアルタイムでRedshiftに集約可能　（GAが待ち遠しい）何より、管理が楽

Slide 31

Slide 31 text

Slide 32

Slide 32 text

アジェンダ（再掲） 1. 自己紹介・会社紹介・事業紹介 2. 背景・課題 3. 設計・構築 4. 成果 5. まとめ 6. 次回予告

Slide 33

Slide 33 text

実際のデータ基盤の活用例 (認定大会支援）ゲームデベロッパーや3rdパーティと協力し、大会主催者の応援活動支援の条件がタイトルごとに異なる

Slide 34

Slide 34 text

実際のデータ基盤の活用例 (認定大会支援）従来の運用フローここが大変！ Redashからトーナメント表データにアクセスできないので、 TonamelサービスのWeb上で公開されている情報をオペレータが確認しに行っていた。確認するものの例 ● 大会規模 ● 大会開催日時 ● 参加者のアクセス情報 etc... 従来は人の目が頼り

Slide 35

Slide 35 text

実際のデータ基盤の活用例 (認定大会支援）データ基盤を使った運用フロー Spreadsheetをデータ基盤が読んで、判断に必要な情報を付加して書き戻すようにした。基本的には Spreadsheet を見ればOK MWAAのDAG

Slide 36

Slide 36 text

実際のデータ基盤の活用例認定大会支援 ● オペレータがWebサイトを見に行く必要がなくなり業務が効率化カスタマーサポート ● DynamoDBの情報を見れるため、Redashからトーナメント表情報を参照可能マーケティング ● KPIのSlack通知や初歩的なオートメーションで素早く情報キャッチ MWAA+Redshiftによるデータ基盤の導入よって・・・

Slide 37

Slide 37 text

まとめサービスの成長に伴い、データベースが増えるそのため、データのサイロ化が加速そこで、MWAA＋Redshiftでデータ基盤を構築・運用し始めたメリット ● SQLだけでほぼETLが完結する ● RedshiftにSuper型が登場、半構造データが取り扱い！より強力になった。 ● MWAA(Airﬂow)はCronの延長として使う分には使いやすい。 ● インフラの構成・管理が楽デメリット ● この構成だけだと、データカタログがないのでS3が沼化し始める ● CustomOperatorに手を出すと沼に浸かり始めるので要注意その他 ● 弊社ではデータエンジニアの仲間を募集しています。（助けてください。）

Slide 38

Slide 38 text

次回予告なんとか軌道に乗ってきたTonamelのデータ基盤、　　　そこに様々な問題が浮上する。 https://nakanoshima-dev.connpass.com/event/221243/ 発表予定

Slide 39

Slide 39 text

Develop環境にしか存在しない機能やマイクロサービス Production環境 Develop環境 ● 『Productionにテーブルができるのは・・・リリース前日かなー？』 ● 『リリースしたらできる限り早くデータを見たい。これとこれ・・・』

Slide 40

Slide 40 text

増え続けるコピペ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の申請というのもありまして・・・』

Slide 41

Slide 41 text

迷走し始めるのデータ基盤…　そして、現る救世主 https://www.getdbt.com/ https://www.amazon.co.jp/Building-Scalable-Data-Warehouse-Vault/dp/0128025107 〜人のスケールはできないが、データ基盤はスケールさせたい〜この先、いったい何が待ち受けているのだろうか？

Slide 42

Slide 42 text

俺（たち）の戦いはこれからだ！！！！ ※データエンジニア周りの採用活動は継続的に行っています。のデータ基盤次回：〜データモデリング編〜 https://nakanoshima-dev.connpass.com/event/221243/ 発表予定

Slide 43

Slide 43 text

　ありがとうございました