Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ikeda-masashi
September 07, 2021

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

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

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

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

ikeda-masashi

September 07, 2021
Tweet

More Decks by ikeda-masashi

Other Decks in Technology

Transcript

  1. 自己紹介 ※アイコンは季節によってバリエーションがあります Github,Twitter: @mashiike 所属: 技術部 役割: • データエンジニア •

    サーバーサイドエンジニア • SRE 趣味: オンラインゲーム ※2021/09 時点ではElite: Dangerousをプレイ 日本酒: 八海山
  2. 課題 1. サービスの状況由来の課題として • 今後は旧来の様々なモジュールの分離独立を予想 • 新機能は最初から、マイクロサービスとして実装 モジュラモノリスアーキテクチャー =>マイクロサービスアーキテクチャー データソースは多種多様、データ量の著しい増大

    2. データ基盤の構築における課題として • 社内のデータエンジニアの層が薄い。人という意味でコストが厳しい 構築は1人(分業) 保守・運用も1人(分業) 期間は7月くらいまでに何かそれっぽいものが・・・ 楽に作れる! 管理コストの低め !  スケーラブルなデータ基盤が必要!!!!
  3. un    本格運用 構築 調査・設計 立案 スケジュール 構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月:

    プロジェクト立案(リソース調整) 2021年1月: データ基盤設計(現状のワークロード調査) 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用 人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜
  4. 主な検討要素 1. ワークフローオーケストレーションはどうするのか? • Cron(or CloudWatch Events)+スクラッチ開発 • Glue •

    Step Functions • Apache Airflow => 使い勝手はステロイドCronなのでよいが、インフラ管理が大変 2. データ保管場所(どこにデータを集める?) そしてクエリエンジンどうする? • S3 + Athena • Aurora MySQL • Redshift • BigQuery? コレ使いたいが、インフラの構成と管理が大変
  5. un    本格運用 構築 調査・設計 立案 スケジュール(再掲) 構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月:

    プロジェクト立案(リソース調整) 2021年1月: データ基盤設計(現状のワークロード調査) 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用 人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜 2月初旬:設計完了
  6. 実際に構築を開始してみたら・・・ JSON string value にSuper型が救世主 LogがJSON in JSON Spectrumではvarchar(max)として読む JSON_PERSEでSuper型に!

    クエリしやすい! ※enable_case_sensitive_identifier を TRUEにしておくこと CamelCaseのKeyなJSONデータも読めるのでおすすめ。
  7. 実際に構築を開始してみたら・・・ CustomOperatorは沼 • テストがないと辛い。 • Airflowのアップデートの影響を思わず受ける (Hook消滅、import path変更 etc…) •

    トラブルシュートが大変 • Pythonに書きなれてないと大変 LambdaやECS Taskを起動するようなOperator BashOperatorの積極的な利用をおすすめします。 (でも使いこなせると便利)
  8. 実際に構築を開始してみたら・・・ データ基盤の性能としては良いのでは? • MWAAの(Custom)Operatorで任意の場所にデータを搬送可能 (Slack, Spreadsheet, S3, etc…: 色々なレポーティング) •

    DDB Streamは実質的にはChange Data Capture (DDB StreamをMinutelyで処理を行っている。遅延が大体5分以内) • Redshiftのコンピューティングのちからは強い PreviewのMySQL Federated Queryも加われば、 ほぼ全てのデータがニアリアルタイムでRedshiftに集約可能  (GAが待ち遠しい) 何より、管理が楽
  9. un    本格運用 構築 調査・設計 立案 スケジュール(再掲) 構想 2020年11月: プロジェクト構想(※当時別事業部) 2020年12月:

    プロジェクト立案(リソース調整) 2021年1月: データ基盤設計(現状のワークロード調査) 2020年 2021年 2021年3月: 構築開始 2021年7月~: 本格運用 人員数: 0.5人 (1人が分業) 期間: 7ヶ月〜 2月初旬:設計完了 6月:本格的な運用開始
  10. まとめ サービスの成長に伴い、データベースが増える そのため、データのサイロ化が加速 そこで、MWAA+Redshiftでデータ基盤を構築・運用し始めた メリット • SQLだけでほぼETLが完結する • RedshiftにSuper型が登場、半構造データが取り扱い!より強力になった。 •

    MWAA(Airflow)はCronの延長として使う分には使いやすい。 • インフラの構成・管理が楽 デメリット • この構成だけだと、データカタログがないのでS3が沼化し始める • CustomOperatorに手を出すと沼に浸かり始めるので要注意 その他 • 弊社ではデータエンジニアの仲間を募集しています。 (助けてください。)
  11. 増え続けるコピペ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の申請というのもあ りまして・・・』