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
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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を採用
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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の申請というのもあ
    りまして・・・』
    

    View Slide

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

    View Slide

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

    View Slide

43. 　ありがとうございました
    

    View Slide