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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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のアクセスログ向けパーティション射影設定例

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の構文

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

62  62  まとめ 

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

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

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

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

More Decks by Hiroshi Oda

Other Decks in Technology

Featured

Transcript