Save 37% off PRO during our Black Friday Sale! »

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

F40e385e485eafaed67850df08b122d0?s=47 ikeda-masashi
September 07, 2021

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

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

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

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

F40e385e485eafaed67850df08b122d0?s=128

ikeda-masashi

September 07, 2021
Tweet

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.  ありがとうございました