グローバルIoTスタートアップにおける2年強に及ぶちょうど良いデータ基盤への歩み / Global IoT Startup Data Infrastructure

AWS Startup Community Conference 2022での発表資料です。

掲載URL
・https://speakerdeck.com/yuzutas0/20200715
・https://qiita.com/hi1280/items/1efeb18c6668198982cd
・https://github.com/shinji19/embulk-input-athena
・https://hi1280.hatenablog.com/entry/2021/11/01/180000
・https://hi1280.hatenablog.com/entry/2022/07/10/210000
・https://hi1280.hatenablog.com/entry/2021/10/02/220747

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

Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

15. 14
 データ基盤の前提条件
 グローバル
 分散拠点
 言語対応
 IoT
 リアルタイム
 大量データ
 本環境での利用データは全て構造化データ
16. 15
 機能要件
 アプリケーションからデータ分析向けデータを分離する
 1時間あたり数百万件規模のIoTデータをリアルタイム処理
 データ基盤の要件
 非機能要件
 膨大なデータを処理しつつ、現実的なコストにする
 各国の拠点ごとに情報を保護する

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

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

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

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

23. 22
 データソースごとのデータ収集方法
 データソースごとにデータ収集する
 • IoTデータ収集
 • DynamoDBデータ収集
 • Aurora MySQLデータ収集
 DynamoDBデータ収集
24. 23
 データソースごとのデータ収集方法
 データソースごとにデータ収集する
 • IoTデータ収集
 • DynamoDBデータ収集
 • Aurora MySQLデータ収集
 Aurora MySQLデータ収集
25. 24
 データ基盤構成
 コスト、セキュリティ、パフォーマンスを考慮したGMSにおけるデータ基盤 
 データ変換

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

27. 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/<ACCOUNT-ID>/elasticloadbalancing/ap-northeast -1/${year}/${month}/${day} ' ) ALBのアクセスログ向けパーティション射影設定例
28. 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の構文
29. 28
 データ変換におけるコスト対応
 当初はGlue ETLジョブを試したがコストが高かった
 Glue ETLジョブからAthenaでのデータ変換処理に変更
 1/4以上のコスト削減効果があった

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

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

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

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

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

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

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

37. 36
 集計値を用意する
 実装
 Embulkを利用する
 • S3からAthenaを使ってMySQLにデータをロード
 • GitHub - shinji19/embulk-input-athena
 Embulk自体はECS上で実行
 Thanks to shinji19󰢛
38. 37
 データ基盤の残課題
 既存のデータ定義が変更されると大変
 S3にデータが置かれているだけなので、データを作り直すことになる
 パーティション分割されているとより大変
 データ分析者向けのサポートが弱い
 データ分析者に優しいデータ構造でデータを扱えるようにしたい
 
 
 
 
 Redshift Serverless + dbtを検討中
39. 38
 38
 できる限り運用を効率化して安定稼働
 させる

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

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

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

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

44. 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
45. 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
46. 45
 その他工夫したこと
 開発・運用体験
 • データ処理フローを一本化、べき等性を保証
 • コンテナ、Lambdaのデプロイを自動化
 • データソースとなるCSVの取り込みをGoogle Apps Script(GAS)で自動化
 • テスト環境作成
 • リファクタリング
 • データの復旧手順書を作成
 • Athenaでのデータ型変換方法をドキュメント化
 データ型変換方法について詳しくはこちら https://hi1280.hatenablog.com/entry/2021/10/02/220747
47. 46
 データ処理フローの一本化
 データ収集 データ変換 データ基盤構成のデータ収集、データ変換、データ分析・可視化は以下のようにStep Functionsで実現 
 RetryとCatchを利用してデータ処理フローを数回再施行して基本的に失敗でも止めずに流す 
 データ分析・可視化
48. 47
 苦労したこと
 運用の効率化は一日にして成らず
 安定稼働まで約1年ほどかかった

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

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

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

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

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

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

56. 55
 データ分析者向けドキュメントの整備
 データ基盤用のテーブル定義書を用意
 方法
 • Googleスプレッドシートを用いる
 • GASでGlueデータカタログのデータを転記する 仕組みを用意
 テーブル一覧 テーブル定義
57. 56
 実施したこと
 興味・関心を引く
 データ基盤での集計結果をアプリケーションで利用する
 全社レベルの障害対応に役立てる
 データ活用の社内イベント実施
 サービス契約数を可視化する
 

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

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

60. 59
 実施したこと
 教育
 モチベーションが高い一部の社内ユーザーを集めて勉強会を実施
 その後、個別指導を実施
 なぜこの方法になったか？
 多くのメンバーを集めて勉強会を実施したが定着しなかった
 エンジニア向けにはデータだけ渡して定着しなかった
 メンバーを厳選して、各自の業務に活用・定着に成功
61. 60
 教育内容
 勉強会
 SQLの教育を中心に実施
 個別指導
 ソフトウェアエンジニアが1on1でSQLの書き方を徹底 指導
 お世話しすぎない程度に実施
 勉強会カリキュラム 
 • SQL文の基礎
 ◦ 第1回
 ▪ SQLとは?
 ▪ SELECT句
 ▪ WHERE句
 ◦ 第2回
 ▪ WHERE句
 ▪ ORDER BY、LIMIT 
 ◦ 第3回
 ▪ 集計
 ◦ 第4回
 ▪ 結合
 ◦ 第5回
 ▪ サブクエリ
 • 第6回
 ◦ Redashの理解
 ▪ グラフの作り方
 ▪ パラメーターの使い方 
 • 第7回
 ◦ 社内データの理解 
 カリキュラムを作るにあたり、Progate様のSQLレッスンの内容を 参考にさせて頂きました󰢛

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

63. 62
 62
 まとめ

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

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