Serverlessで構成するEvent Driven Data Platform

Slide 1

Slide 1 text

Serverlessで構成する Event Driven Data Platform SREマネージャー前田

Slide 2

Slide 2 text

自己紹介 ● 前田和樹（　 @kzk_maeda ） ● SRE Manager at Progate ● ギターやベースなど弾きます ● 週末は2人の子どもに忙殺されてます

Slide 3

Slide 3 text

1. About Company 2. About System 3. About Data Platform 4. About Future 5. Closing Index

Slide 4

Slide 4 text

About Company 何をしている会社？

Slide 5

Slide 5 text

オンラインプログラミングサービス初心者でも学びやすい学習環境をご用意。日本語版と英語版を展開しています。イラスト中心のスライドで学ぶプログラムを書いて学ぶ紙の本よりも直感的で、動画よりも学びやすい「スライド学習」を採用しました。自分のペースで学習できること、復習しやすいことが強みです。実際にプロダクトを作りながら学ぶから、使えるスキルが身につきます。ブラウザ上でコードを書いて結果も確認。すぐにプログラミングが実践できます。 | About Our Service 概要

Slide 6

Slide 6 text

スライド演習スライド演習達成達成

Slide 7

Slide 7 text

累計ユーザー数推移　日本 over 1,450,000人（2020/12/01 時点）単位：人

Slide 8

Slide 8 text

累計ユーザー数推移　インド（2020/12/01 時点） over 200,000人単位：人

Slide 9

Slide 9 text

累計ユーザー数推移　インドネシア（2020/12/01 時点） over 70,000人単位：人

Slide 10

Slide 10 text

About System どうやって創っている？

Slide 11

Slide 11 text

Architecture概要

Slide 12

Slide 12 text

複数のAWSアカウントをOrganizationで管理 - Production / Staging / Base（認証用） Architecture概要

Slide 13

Slide 13 text

基本のWeb機能は ALB + EC2(ASG) + Redis + Aurora(MySQL） Github + CircleCIでRolling Update Architecture概要

Slide 14

Slide 14 text

ユーザーのコード実行環境として EC2でホストしたDocker Swarmクラスタを構成 - chatbotからcluster毎B/G Deploy可能 Architecture概要

Slide 15

Slide 15 text

ProductionのSwarm Clusterは複数Regionに分散 Architecture概要

Slide 16

Slide 16 text

Application周りのログはfluentd+KDF -> S3 監視はNewRelicに統合中 Architecture概要

Slide 17

Slide 17 text

使用技術 ● Frontend ○ React / React Native ● Server-Side ○ Ruby on Rails / Node.js ● Infrastructure ○ AWS（ALB, EC2, Fargate, RDS, ElastiCache, Lambda, APIGW, KDF, etc...） ○ Terraform / Serverless Framework ○ Docker / Docker Swarm ● Other ○ Github / DockerHub / Circle CI / Slack / Asana / DocBase

Slide 18

Slide 18 text

About Data Platform データ基盤について

Slide 19

Slide 19 text

対象とするデータ更新頻度分析活用埋蔵金 ● 活用用途を見出せてないデータ Master Data ● Users ● Lessons ● Languages Transactional Data ● UserCodes ● LessonHistories ● Logs

Slide 20

Slide 20 text

データ要件 ● 1日ごとの全件同期 ● センシティブなデータの取り扱い ○ 特定データには認可された人のみがアクセス可能な状態 ● BI（redash）からクエリ

Slide 21

Slide 21 text

Data Platform Architecture

Slide 22

Slide 22 text

Data Platform Architecture RDS上のデータを DataCatalog化する

Slide 23

Slide 23 text

Data Platform Architecture ● RDS SnapshotのS3Export機能を活用 ○ parquet形式のファイルをS3に定期Upload可能 ○ RDSに対してread負荷がかからない ● Data PipelineのレイヤはDatalake的な思想で構成 ○ 収集→蓄積→変換→分析 ○ 各レイヤをイベントドリブンで接続 ● DataCatalogをセキュリティレベル別に分離 ○ Sensitiveなデータとそうではないデータ ○ 同一DataSourceからPipeline上で複数のCatalogを生成

Slide 24

Slide 24 text

Data Platform Architecture 収集蓄積変換分析 DataPipelineをDatalake思想で構成収集→蓄積→変換→分析各Layerはイベントドリブン（SNS/SQS + Lambda）で接続

Slide 25

Slide 25 text

Data Platform Architecture Event RDSのSnapshot関連のイベントトリガーは、RDS Event Subscription→SNS SNSのSubscriberとしてLambdaが起動 Event Event

Slide 26

Slide 26 text

Data Platform Architecture Sensitive Data Normal Data Sensitive DataのLayerとNormal Dataの Layerで構成ここもイベント接続

Slide 27

Slide 27 text

詰まった点１ RDS Event Subscriptionの仕様

Slide 28

Slide 28 text

なにが起きたか ● Snapshotの作成とSnapshot Exportが同じEvent SubscriptionのEvent Categoryに属するので、どちらも同じSNS TopicにSubscribeされる ● 別のEventとして単一責務のLambdaをSubscriberに設定する予定だったが、それぞれのEventを同一Lambda内で処理する必要性が

Slide 29

Slide 29 text

なにが起きたか同じEvent Subscriptionから通知される

Slide 30

Slide 30 text

どうしたか ● 後続のLambdaを同一Functionとし、SNSのMessageによって実行する処理を分岐 ○ snapshot created イベントに対しては snapshot export を実施 ○ export task completed イベントに対しては後続の GlueJobをKick ● 管理上関数を分けたかったが、全体をterraformで管理することとResource Groupを有効にすることで許容

Slide 31

Slide 31 text

詰まった点２ Snapshot Exportの仕様

Slide 32

Slide 32 text

なにが起きたか ● RDS Snapshot ExportタスクによってSnapshotがS3にExportされる際、 Export Task名のPrefix配下にSnapshotが配置される ● 後続処理でExportされたSnapshotデータを特定する際に、Export Task名として何が指定されたかを正確に把握する必要がある ○ yyyy-mm-ddなどで値を決めると、リトライが発生した際のハンドリングが面倒

Slide 33

Slide 33 text

なにが起きたかここで決めたTask名をこっちで正確に知る必要がある

Slide 34

Slide 34 text

どうしたか ● Export Task実行時に決めた名前をSQSにメッセージング ● 後続のLambdaの中でSQSにキューイングされたメッセージから設定された Export Task名を取得し、S3上のPathを把握 ● GlueJob / Crawlerの実行を容易にするため、/latest 配下にcopy

Slide 35

Slide 35 text

どうしたか Task名をQueuing SQSからTask名を取得→/latestにcopy

Slide 36

Slide 36 text

詰まった点３ Data Pipelineのモニタリング

Slide 37

Slide 37 text

なにが起きたか ● StepFunction管理にしなかったので、Pipelineのどこまで実行されているのかなどのモニタリングが困難 ● X-Rayでかっこよくいけるやろと思ってたけど、机上で調べてる限りやりたいことの実現は難しそう ※理想

Slide 38

Slide 38 text

どうしたか ● PipelineのStep毎にDynamoDBに状況を書き込むようにした ○ Export Task名をPrimary Keyとして利用 ● エラーで落ちた場合はエラーメッセージもDDBに格納されるので、どこまで実行されてなぜ落ちたのかの大体の情報はDDBで完結 Step毎に書き込みエラー時はメッセージも

Slide 39

Slide 39 text

その他の知見 ● 大まかなアーキテクチャはAWSのAsk an expertを活用してレビューしてもらえた。ライトに相談できる場としてすごく助かる。 ● AWSから毎日のようにアナウンスされる便利機能アップデートは銀の弾丸ではない。自分たちのシステムに落とし込む上では考えたり実装したりするポイントがたくさん出てくる ● AWSサービスのアイコンを並べて設計した気になってるおじさんにならないように気を付ける

Slide 40

Slide 40 text

About Future 今後の展望

Slide 41

Slide 41 text

データの更なる活用更新頻度分析活用埋蔵金 ● 活用用途を見出せてないデータ Master Data Transactional Data 活用ラインの拡大多様なトランザクションデータ取得

Slide 42

Slide 42 text

データの更なる活用データ活用の多面化・組織化

Slide 43

Slide 43 text

新しい技術の活用 ● 先日リリースされたマネージドAirFlow（MWAA）で後半のジョブネットはワークフロー化できるかもしれないので、折を見て検証したい ● 今日発表された Glue Elastic View との親和性など？？ ○ 作ってるやつほぼ捨てられる・・・・？？？

Slide 44

Slide 44 text

Closing 最後に

Slide 45

Slide 45 text

結論 ● RDSのsnapshot export機能を使えば、Master DataをDatalakeに簡単に格納することが可能 ● だと思っていた時期がありました。 ● イベントドリブンなパイプラインのモニタリングはX-Ray ● だと思っていた時期がありました（要追加検証）。 ● マネージドサービスを実要件での活用に落とし込んで行くには、結局はエンジニアリングが必要。 ● AWS支援体制は積極的に活用していくのがいい

Slide 46

Slide 46 text

エンジニア積極採用中 ● Progateではエンジニアを積極採用しています ● プログラミング教育事業に興味がある、グローバルサービスに携わりたい、など、気になるポイントあれば是非ご連絡ください ● 詳しくは採用サイトへ ○ https://prog-8.com/about/careers

Slide 47

Slide 47 text

TechBlogはじめました ● Progate TechBlogを開設しました ● Advent Calendar期間を活用し、積極的に発信していきます ● 詳しくはBlog ○ https://tech.prog-8.com/

Slide 48

Slide 48 text

ご清聴ありがとうございました