大規模ドラレコデータ収集・機械学習基盤を支える AWS CDK 〜導入・運用事例紹介〜

Slide 1

Slide 1 text

AWS CDK Conference Japan 2024 大規模ドラレコデータ収集・機械学習基盤を支える AWS CDK 〜導入・運用事例紹介〜 2024.07.06 松浦慎平 GO株式会社

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© GO Inc. 4 主な事業タクシーアプリのキャッシュレス決済機能乗務員向けアプリの開発・運営 ※記載されている会社名や商品名などは、各社の商標または登録商標です。（出願中含む）タクシーの運行特性に応じたEV運行マネジメントとエネルギーマネジメントによるCO2削減アプリ注文のみを受け取る車両の配車 AIドラレコを活用した危険シーンを解析・報告し運行管理に活用タクシーサイネージメディア（動画広告） AIドラレコのデータを元に、地図と実際の道路情報の差分をAI技術によりメンテナンスタクシー配車や経費精算などを簡単効率化した法人向けサービスタクシー乗務員に加え様々な運輸職種を紹介 GO Reserve / GO Crew GO ジョブ GO GX TOKYO PRIME 乗務員 App 充電インフラ提供、エネルギーマネジメントシステムの提供、EV車両リースなど商用車の包括的脱炭素化サービス事業者協力型自家用有償旅客運送導入支援「日本型ライドシェア」対応「自家用有償旅客運送」対応市中の急速充電スポットの検索・予約・決済がオンラインで完結するEV充電サービス

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© GO Inc. 6 システム概要 DRIVE CHART センサー収集マップマッチ処理対象走行計算車両位置格納タスク作成タスク動画リクエスト動画格納車両位置動画物体検出物体位置推定差分判定認識物体地図 AWS Batch AWS Batch Aurora PostgreSQL Aurora PostgreSQL Aurora PostgreSQL Lambda / ECS / Batch S3 走行収集動画収集認識差分判定モジュールデータと処理の流れタスクの状態管理 The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/) The design is licensed under the Creative Commons 3.0 Attributions license

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© GO Inc. 10 モジュールとスタックの構成共通インフラモジュールロジックモジュール間で共有するリソースを管理する例: VPC、共有S3バケット、RDS、SQS、 CloudTrail ロジックモジュールロジックのコードとロジック内でのみ利用されるリソースをCDKで管理する共通インフラモジュール Network Stack 共通DB Stack 共通S3 Stack 共通SQS Stack ... ロジックモジュールA ロジックモジュールB ロジックモジュールN ... Lambda Stack Batch Stack ECS Stack S3 Stack S3 Stack S3 Stack PROD、QA、DEVの3アカウント

Slide 11

Slide 11 text

© GO Inc. 11 ロジックモジュール開発の流れロジック間のインターフェイス定義共通インフラにリソースを追加実装結合テスト/デプロイ - ロジック間のインターフェイス設計(主にデータ仕様) - 引き渡しに使用するサービスの選定(SQS、S3、RDS等) - 必要があればリソースを共通インフラのCDKに追加定義 - DEV環境に共通インフラをデプロイ - ロジックで使用するリソースをCDKで定義＆DEVへデプロイ - ローカル / DEV環境でロジックの実装 - CI/CD環境でQAへのデプロイ、結合テスト - CI/CD環境でPRODへのデプロイ

Slide 12

Slide 12 text

© GO Inc. 12 AWS CDK x GitHub Actions による CI/CD環境 Deploy ModuleA to QA Deploy ModuleA to QA Deploy ModuleA to QA Deploy ModuleA to QA Deploy ModuleA to QA Deploy ModuleA to PROD Integration test on QA GitHub Actions Workﬂows 独自実装のCI/CD CLIで結合テスト〜デプロイを制御 % deploy env=qa mod=Cm,A,B % invoke-itest % merge-and-tag mod=Cm,A,B % deploy env=prod mod=Cm,A,B ...① ...② ...③ ① ② ③ デプロイワークフローの中身 1. リポジトリのクローン 2. Assume Role(OIDC) 3. make build ○ cdk build, go build, docker build, etc... 4. make deploy ○ cdk -c env=qa deploy, docker push, etc... CI/CDリポジトリ ※コマンドはイメージです

Slide 13

Slide 13 text

© GO Inc. 13 ロジックモジュールのリポジトリ構成ルール思想: 自分が使うAWSリソースは自分で管理しよう！ / |- deployments/ | |- cdk/ | |- container/ | |_ migration/ |- src/ |_ Makeﬁle ● /deployments/cdk ○ ロジックモジュールに必要なインフラ定義 ● /src ○ ビジネスロジック(srcじゃないことも) ● Makeﬁle ○ 必ず以下ターゲットを実装する ■ make build ● ロジック、CDKなどのビルド ■ make deploy ● DB migration、CDKのデプロイ、イメージの PUSHなど

Slide 14

Slide 14 text

© GO Inc. 14 CDK実装のルールスタック間の参照のルール複数環境への対応モジュール間、内で推奨！参照方法 ● Secrets Manager ● SSM Parameter Store ● リソース名 ○ {env}-{mod name}-data-bucket 弱い参照モジュール内で使ってもよい参照方法 ● Prosp渡し依存によって依存元のリソース更新がつらくなるので極力使わない... 強い参照デプロイ環境の制御のためのルール ● CICDはmake deploy実行時に環境変数にデプロイ先を指定する ● コンテキスト変数でデプロイ先を制御できること ○ cdk deploy -c env=$PROJ_ENV 環境ごとの設定値の定義 ● cdk.json に定義する { “context”:{ “dev”: {“threads”: 1, ...}, “qa” : {“threads”: 1, ...}, “prod”: {“threads”: 5, ...} } } リソース名命名規則(ConstructIDはこれをパスカルケースにしたもの) ● {env}-{module name}-{resource name} 例: スタック名が ProdModAStackとなる

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© GO Inc. 17 実験環境管理ツール { “ExpID”: ”Exp1”, “Branches”: { “ModA”: “feat/exp1”, “ModB”: “v1.4”, “ModC”: “feat/exp1” }, “DataGroup”: [ “Group1”, “Group2” ] } モジュールデプロイのワークフロー git clone git@github.com/.../ModA -b feat/exp1 cdk deploy -c env=qa -c expid=Exp1 実験環境の定義実験環境の定義からCDKによるモジュールのデプロイ、実験データの配置を行うツールを運用例: スタック名が QAExp1ModAStackとなる共通インフラモジュール QA ModA QA ModB QAExp1 ModA QAExp1 ModB QAExp2 ModA QAExp2 ModB 無印モジュール Exp1モジュール Exp2モジュール

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© GO Inc. 19 やってよかったこと / うれしかったこと真っ先にCDK含むCI/CDを作ったこと高速にイテレーションを回す開発初期においてモジュール担当者がそれぞれ独立してインフラ含む開発 -> デプロイ -> テストのループを実施できた。 CDKのコマンド群を直接叩かない MakeﬁleにCDKのビルド、デプロイターゲットを定義することでコンテキスト変数の指定忘れなどを防げる。 QA環境や実験環境デプロイの自動化により、CDKを知らないジョインしたてのメンバーでも即環境構築->ロジック改善が可能になった。野良リソース恐怖症になった CDKで管理されていないリソースを見つけると「おや？」と思うようになる。権限管理が楽 grantXX関数でリソース間のアクセス許可を過不足なく設定できるので、サボってFullAccessつけちゃったりという事象がなくなった CDKの冪等性は実験環境の構築にも力を発揮パラメータが異なる環境を量産し実験することができ、定義さえ残っていれば環境を廃棄したあとでも特定のバージョンをチェックアウトして必要なときにまったく同じ実験が再現できる。

Slide 20

Slide 20 text

© GO Inc. 20 今から作るならこうするのに！/ 悩み cdk.jsonによる設定管理はやらない jsonによる定義は型チェックも働かないし、参照時もIDEによる補完の恩恵が受けられない。型エイリアスを定義し型アサーションしたこともあったが、それなら最初からconﬁg.tsで管理したほうがいいスタック分けすぎ問題当初TypeScript & CDKに慣れてないためリソース単位でスタック分割しているケースが多く、無駄なスタック間参照が多い。Constructでリソースをまとめて1モジュール1スタックにする。 (ただ、Stack分けすぎた弊害がすごい大きいのかと問われると、そこまで困っていない...) CICD環境のロールの権限が強力過ぎるのが悩みすべてのモジュールのデプロイを行う＆モジュールがどのようなリソース作成や参照を行うか把握できないのでCICD がAssumeRoleするロールの権限を強くせざるを得ない。そのためCICD環境のセキュリティは常に気を配る必要がある。早めにコミュニティには関わっておく悩みや成功体験は共有すべきですよね...