グローバルIoTスタートアップにおける2年強に及ぶちょうど良いデータ基盤への歩み / Global IoT Startup Data Infrastructure

Slide 1

Slide 1 text

0  グローバルIoTスタートアップにおける2年強に及ぶ  ちょうど良いデータ基盤への歩み  Oda Hiroshi / @hi1280  2022-08-26  AWS Startup Community Conference 2022 

Slide 2

Slide 2 text

1  自己紹介  Oda Hiroshi / @hi1280  Global Mobility Service株式会社  エンジニアリングマネージャ兼インフラエンジニア   Udemy講師  AWS / Kubernetes / Terraform / データエンジニアリング   好きなAWSサービス：Amazon EKS、Amazon ECS    

Slide 3

Slide 3 text

2  車両販売店エンドユーザー金融機関 MCCS 車両販売 MCCS装着ローン MCCSを利用した FinTechサービス支払車両のエンジン遠隔起動制御・モニタリング GMSのFinTechサービス MCCSとMSPFによる車両エンジン遠隔起動制御により、金融機関のデフォルトリスクを低減より多くの人にファイナンス機会を創出エンドユーザーの支払いが滞った際にエンジン遠隔制御を実施エンドユーザーの支払いを促進し、万が一支払いができなくなった場合、車両回収を確実に行える仕組みを構築

Slide 4

Slide 4 text

3  本発表の対象者  サービスを成長させるためにデータ活用を具体的に  推進したいと思っている方 

Slide 5

Slide 5 text

4  本発表について  ベストプラクティスを紹介するものではありません  事例紹介になります  課題と解決策を示しています 

Slide 6

Slide 6 text

5  目次  1. 本発表で伝えたいこと  2. コスト、セキュリティ、パフォーマンスを考慮した  データ基盤作り  3. できる限り運用を効率化して安定稼働させる  4. データ基盤を社内ユーザーに活用してもらうための工夫  5. まとめ 

Slide 7

Slide 7 text

6  6  本発表で伝えたいこと 

Slide 8

Slide 8 text

7  データ基盤を作る動機  Data Platform Guide - 事業を成長させるデータ基盤を作るには #DataEngineeringStudy / 20200715 - Speaker Deck より引用データ基盤をSSOT: Single Source of Truth（信頼できる唯一の情報源）とする  

Slide 9

Slide 9 text

8  スタートアップの課題  専門人材の  不足  データエンジニアリング   未経験  人手不足  開発運用の人数が  少ない  資金の節約  コストをかけすぎない  

Slide 10

Slide 10 text

9  どう解決するか  スタートアップにちょうど良いデータ基盤を作る  1. 機能要件と非機能要件に合わせてデータ基盤を作る  2. できる限り運用を楽にする  3. ユーザーに使ってもらえるように工夫する ←イマココ  4. ユーザーの声を聞き、継続的に改善する   

Slide 11

Slide 11 text

10  データ基盤構築・運用の変遷  運用  2020年11月〜  普及  2021年12月〜      構築  2020年4月〜2020年10月  兼任  専任  データエンジニアリング未経験  

Slide 12

Slide 12 text

11  11  コスト、セキュリティ、パフォーマンスを考慮したデータ基盤作り 

Slide 13

Slide 13 text

12  IoTデータがうまく活用できていない  データ基盤作りのきっかけ 

Slide 14

Slide 14 text

13  パフォーマンス  膨大なIoTデータを現実的な処理時間で扱うことが難しい    データ分析体験  アプリケーションとの密結合によるデータ分析のしづらさ    セキュリティ  DBのアクセス権限があいまいでデータ管理が不安      データ基盤以前の課題 

Slide 15

Slide 15 text

14  データ基盤の前提条件  グローバル  分散拠点  言語対応  IoT  リアルタイム  大量データ  本環境での利用データは全て構造化データ

Slide 16

Slide 16 text

15  機能要件  アプリケーションからデータ分析向けデータを分離する  1時間あたり数百万件規模のIoTデータをリアルタイム処理  データ基盤の要件  非機能要件  膨大なデータを処理しつつ、現実的なコストにする  各国の拠点ごとに情報を保護する 

Slide 17

Slide 17 text

16  機能要件  ✅アプリケーションからデータ分析向けデータを分離する  1時間あたり数百万件規模のIoTデータをリアルタイム処理  データ基盤の要件  非機能要件  膨大なデータを処理しつつ、現実的なコストにする  各国の拠点ごとに情報を保護する 

Slide 18

Slide 18 text

17  データ基盤構成  コスト、セキュリティ、パフォーマンスを考慮したGMSにおけるデータ基盤   詳しくはこちら https://qiita.com/hi1280/items/1efeb18c6668198982cd

Slide 19

Slide 19 text

18  データ基盤構成  コスト、セキュリティ、パフォーマンスを考慮したGMSにおけるデータ基盤   データ収集 

Slide 20

Slide 20 text

19  データソースごとのデータ収集方法  データソースごとにデータをS3上に収集する  ● IoTデータ収集  ● DynamoDBデータ収集  ● Aurora MySQLデータ収集  IoTデータ収集

Slide 21

Slide 21 text

20  IoTデータを収集する  方法  ストリームデータの処理に適したKinesis Data Firehoseを利用する  特徴  ● Lambdaによるデータ変換処理  ● データ分析に適したデータ形式への変換処理  ● データ処理前のデータをバックアップ  ● 特定の送信先(S3など)へのデータ書き込み 

Slide 22

Slide 22 text

21  機能要件  アプリケーションからデータ分析向けデータを分離する  ✅1時間あたり数百万件規模のIoTデータをリアルタイム処理  データ基盤の要件  非機能要件  膨大なデータを処理しつつ、現実的なコストにする  各国の拠点ごとに情報を保護する 

Slide 23

Slide 23 text

22  データソースごとのデータ収集方法  データソースごとにデータ収集する  ● IoTデータ収集  ● DynamoDBデータ収集  ● Aurora MySQLデータ収集  DynamoDBデータ収集

Slide 24

Slide 24 text

23  データソースごとのデータ収集方法  データソースごとにデータ収集する  ● IoTデータ収集  ● DynamoDBデータ収集  ● Aurora MySQLデータ収集  Aurora MySQLデータ収集

Slide 25

Slide 25 text

24  データ基盤構成  コスト、セキュリティ、パフォーマンスを考慮したGMSにおけるデータ基盤   データ変換 

Slide 26

Slide 26 text

25  データ変換  やること  データ分析をしやすい形にデータを変換する  ● 欠損値の補完  ● 重複の排除  ● データ構造の変換 

Slide 27

Slide 27 text

26  データ変換方法  データ変換にはAthenaを使用  AthenaでS3上のデータをクエリするには Glueデータカタログが必要  必要に応じて、パーティション分割する  パーティションを作成する場合にはパーティション射影の機能が便利  CREATE EXTERNAL TABLE `alb_logs_partition_projection`( … TBLPROPERTIES ( 'has_encrypted_data '='false', 'projection.enabled '='true', 'projection.day.digits '='2', 'projection.day.interval '='1', 'projection.day.range '='1,31', 'projection.day.type '='integer', 'projection.month.digits '='2', 'projection.month.interval '='1', 'projection.month.range '='1,12', 'projection.month.type '='integer', 'projection.year.digits '='4', 'projection.year.interval '='1', 'projection.year.range '='2020,2025', 'projection.year.type '='integer', 'storage.location.template '='s3://your-alb-logs-director y/AWSLogs//elasticloadbalancing/ap-northeast -1/${year}/${month}/${day} ' ) ALBのアクセスログ向けパーティション射影設定例

Slide 28

Slide 28 text

27  データ変換方法  AthenaのCREATE TABLE AS SELECT(CTAS)でSELECTクエリを使用してテーブルとデータを作成する  INSERT INTOでデータを追加する  CREATE TABLE table_name [ WITH (property_name = expression [, ...] ) ] AS query [ WITH [ NO ] DATA ] INSERT INTO destination_table SELECT select_query FROM source_table_or_view CTASの構文 INSERT INTOの構文

Slide 29

Slide 29 text

28  データ変換におけるコスト対応  当初はGlue ETLジョブを試したがコストが高かった  Glue ETLジョブからAthenaでのデータ変換処理に変更  1/4以上のコスト削減効果があった 

Slide 30

Slide 30 text

29  機能要件  アプリケーションからデータ分析向けデータを分離する  1時間あたり数百万件規模のIoTデータをリアルタイム処理  データ基盤の要件  非機能要件  ✅膨大なデータを処理しつつ、現実的なコストにする  各国の拠点ごとに情報を保護する 

Slide 31

Slide 31 text

30  データ基盤構成  コスト、セキュリティ、パフォーマンスを考慮したGMSにおけるデータ基盤   データ分析・可視化 

Slide 32

Slide 32 text

31  データ分析・可視化  やること  ユーザーがデータの可視化や分析できるようにする  データのアクセス権限を適切に設定する  方法  社内メンバー向けにRedashを提供する  ● Redashからのみデータを扱える  頻繁に利用される集計値を用意する 

Slide 33

Slide 33 text

32  データ基盤におけるセキュリティ方針  クエリの作成者を限定する  社内メンバー全員がデータを見れるようにする  意図  ● 利便性を損なわない  リスク対策  ● 他拠点で見られても問題ないデータのみとする  ● データを集計することで情報を保護する  ○ 生データをそのまま見せない 

Slide 34

Slide 34 text

33  データアクセス制御方法  Redashのアクセス権限機能を使用する  管理者  ● 全権限を保有  ● データ基盤構築・運用メンバー用  データ分析者  ● 分析者が所属する拠点のデータに対してのみクエリを作成可能  ● 各拠点の承認フローに基づいて本権限を付与する  データ閲覧者  ● 参照権限のみ  ● 社員用Googleアカウント保有者 

Slide 35

Slide 35 text

34  機能要件  アプリケーションからデータ分析向けデータを分離する  1時間あたり数百万件規模のIoTデータをリアルタイム処理  データ基盤の要件  非機能要件  膨大なデータを処理しつつ、現実的なコストにする  ✅各国の拠点ごとに情報を保護する 

Slide 36

Slide 36 text

35  集計値を用意する  課題  Athenaは集計値の再集計に適していない  更新処理をサポートしていないため  ※現在はApache Iceberg対応がある  解決策  MySQLで集計処理を行う 

Slide 37

Slide 37 text

36  集計値を用意する  実装  Embulkを利用する  ● S3からAthenaを使ってMySQLにデータをロード  ● GitHub - shinji19/embulk-input-athena  Embulk自体はECS上で実行  Thanks to shinji19󰢛

Slide 38

Slide 38 text

37  データ基盤の残課題  既存のデータ定義が変更されると大変  S3にデータが置かれているだけなので、データを作り直すことになる  パーティション分割されているとより大変  データ分析者向けのサポートが弱い  データ分析者に優しいデータ構造でデータを扱えるようにしたい          Redshift Serverless + dbtを検討中

Slide 39

Slide 39 text

38  38  できる限り運用を効率化して安定稼働  させる 

Slide 40

Slide 40 text

39  データ基盤の運用における課題  人手不足  開発の片手間で運用  複雑なシステム  長いワークフロー  様々なサービス  イベント駆動 

Slide 41

Slide 41 text

40  解決策  できる限り運用を効率化する 

Slide 42

Slide 42 text

41  運用効率化のために工夫したこと  監視  データ処理のエラー  データの不整合  データ定義変更       

Slide 43

Slide 43 text

42  データ処理のエラー監視  やり方  ● スケジュール実行のデータ処理をStep Functions内で完結させる  ● Step FunctionsメトリクスにCloudWatch Alarmsを設定する  Step Functionsメトリクスの内容  ● ExecutionsFailed  ● LambdaFunctionsFailed  ● ServiceIntegrationsFailed  ○ ECS、CodeBuildによるデータ処理が対象   ○ 個別処理ごとに監視はできないが、気づけないよりは良い    

Slide 44

Slide 44 text

43  データ不整合の監視  PythonプログラムからAthenaでSQLを実行してデータを監視      - description: データ存在チェック sql: | SELECT * FROM default.alb_logs limit 1 sql/sample.yaml 詳しくはこちら https://hi1280.hatenablog.com/entry/2021/11/01/180000

Slide 45

Slide 45 text

44  データ定義変更の監視  GitHub Actionsでマイグレーションファイルに対してのPRを監視  GitHubにある各アプリケーションのリポジトリに適用  name: database migration notice on: pull_request: branches: - main paths: - "src/migration/**" … .github/workflows/db-migration-notice.yml .github/workflows/db-migration-notice.yml Slackの通知詳しくはこちら https://hi1280.hatenablog.com/entry/2022/07/10/210000

Slide 46

Slide 46 text

45  その他工夫したこと  開発・運用体験  ● データ処理フローを一本化、べき等性を保証  ● コンテナ、Lambdaのデプロイを自動化  ● データソースとなるCSVの取り込みをGoogle Apps Script(GAS)で自動化  ● テスト環境作成  ● リファクタリング  ● データの復旧手順書を作成  ● Athenaでのデータ型変換方法をドキュメント化  データ型変換方法について詳しくはこちら https://hi1280.hatenablog.com/entry/2021/10/02/220747

Slide 47

Slide 47 text

46  データ処理フローの一本化  データ収集データ変換データ基盤構成のデータ収集、データ変換、データ分析・可視化は以下のようにStep Functionsで実現   RetryとCatchを利用してデータ処理フローを数回再施行して基本的に失敗でも止めずに流す   データ分析・可視化

Slide 48

Slide 48 text

47  苦労したこと  運用の効率化は一日にして成らず  安定稼働まで約1年ほどかかった 

Slide 49

Slide 49 text

48  48  データ基盤を社内ユーザーに活用して  もらうための工夫 

Slide 50

Slide 50 text

49  データを活用するモチベーションがない    社内ユーザーに使ってもらう際の課題  データ分析のリテラシーがない IoTデータのみだと関心があるユーザーは限定される

Slide 51

Slide 51 text

50  データを活用するモチベーションがない  → 実際に見せる    解決策  データ分析のリテラシーがない    IoTデータのみだと関心があるユーザーは限定される   

Slide 52

Slide 52 text

51  データを活用するモチベーションがない  → 実際に見せる    解決策  データ分析のリテラシーがない    IoTデータのみだと関心があるユーザーは限定される  → 業績に直結するデータを示す 

Slide 53

Slide 53 text

52  データを活用するモチベーションがない  → 実際に見せる    解決策  データ分析のリテラシーがない  → 教育する  IoTデータのみだと関心があるユーザーは限定される  → 業績に直結するデータを示す 

Slide 54

Slide 54 text

53  実施したこと  準備  全社メンバー向けにデータ可視化・分析用ツール(Redash)を用意  データ分析者向けドキュメントの整備  業務活動データから業績にどのように繋がっているかを理解する 

Slide 55

Slide 55 text

54  初期の取り組み  走行距離、デバイス接続数（車両台数）でサービス状況を可視化 

Slide 56

Slide 56 text

55  データ分析者向けドキュメントの整備  データ基盤用のテーブル定義書を用意  方法  ● Googleスプレッドシートを用いる  ● GASでGlueデータカタログのデータを転記する仕組みを用意  テーブル一覧テーブル定義

Slide 57

Slide 57 text

56  実施したこと  興味・関心を引く  データ基盤での集計結果をアプリケーションで利用する  全社レベルの障害対応に役立てる  データ活用の社内イベント実施  サービス契約数を可視化する   

Slide 58

Slide 58 text

57  集計結果を利用する  社内メンバーが普段から利用するアプリケーション上でデータを見せることで普段の業務でデータを意識してもらう  IoTデータを集計して分かるデータ(例えば、走行距離など)をアプリケーションに提供する 

Slide 59

Slide 59 text

58  全社レベルの障害対応  通信キャリアの誤りにより多数のIoTデバイスの通信が停止  データ基盤のデータを用いて迅速に状況調査 

Slide 60

Slide 60 text

59  実施したこと  教育  モチベーションが高い一部の社内ユーザーを集めて勉強会を実施  その後、個別指導を実施  なぜこの方法になったか？  多くのメンバーを集めて勉強会を実施したが定着しなかった  エンジニア向けにはデータだけ渡して定着しなかった  メンバーを厳選して、各自の業務に活用・定着に成功

Slide 61

Slide 61 text

60  教育内容  勉強会  SQLの教育を中心に実施  個別指導  ソフトウェアエンジニアが1on1でSQLの書き方を徹底指導  お世話しすぎない程度に実施  勉強会カリキュラム   ● SQL文の基礎  ○ 第1回  ■ SQLとは?  ■ SELECT句  ■ WHERE句  ○ 第2回  ■ WHERE句  ■ ORDER BY、LIMIT   ○ 第3回  ■ 集計  ○ 第4回  ■ 結合  ○ 第5回  ■ サブクエリ  ● 第6回  ○ Redashの理解  ■ グラフの作り方  ■ パラメーターの使い方   ● 第7回  ○ 社内データの理解   カリキュラムを作るにあたり、Progate様のSQLレッスンの内容を参考にさせて頂きました󰢛 

Slide 62

Slide 62 text

61  グローバル対応  英語化できてないコンテンツが多々ある  利用ユーザー数が伸び悩み気味    社内ユーザー向けの残課題 

Slide 63

Slide 63 text

62  62  まとめ 

Slide 64

Slide 64 text

63  まとめ  スタートアップにちょうど良いデータ基盤を作る  1. 機能要件と非機能要件に合わせてデータ基盤を作る  2. できる限り運用を楽にする  3. ユーザーに使ってもらえるように工夫する  4. ユーザーの声を聞き、継続的に改善する   

Slide 65

Slide 65 text

64  We Are Hiring! https://recruit.global-mobility-service.com/