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

AWS CDK Conference Japan 2024

Transcript

1. AWS CDK Conference Japan 2024 大規模ドラレコデータ収集・機械学習基盤を支える AWS CDK 〜導入・運用事例紹介〜 2024.07.06 松浦 慎平 GO株式会社
2. © GO Inc. 2 自己紹介 GO株式会社 データビジネス部 KUUグループ グループマネージャ 松浦 慎平 Web地図サービス提供企業、GISソフトウェアベンダー、自動運転サービス提供企業で GIS エンジニアとして従事 現在は道路情報の自動差分抽出プロジェクトで GIS チョットデキル データエンジニアと して活躍？中 @PEmugi2
3. © GO Inc. 3 今日お話すること お話すること CDKを用いたバッチベースのデータパイプラインインフラの運用事例 特にCDKを組み込んだ開発フローについて話します お話しないこと ソースコードレベルでのCDKのベストプラクティスやアンチパターン (調べながら当インフラのCDK構成振り返るとまぁまぁアンチパターンふんでました...orz)
4. © GO Inc. 4 主な事業 タクシーアプリのキャッシュレス決済機能 乗務員向けアプリの開発・運営 ※記載されている会社名や商品名などは、各社の商標または登録商標です。（出願中含む） タクシーの運行特性に応じたEV運行マネジメントと エネルギーマネジメントによるCO2削減 アプリ注文のみを受け取る車両の配車 AIドラレコを活用した 危険シーンを解析・報告し運行管理に活用 タクシーサイネージメディア（動画広告） AIドラレコのデータを元に、地図と実際の道路情報の差 分をAI技術によりメンテナンス タクシー配車や経費精算などを簡単効率化 した法人向けサービス タクシー乗務員に加え様々な運輸職種を紹介 GO Reserve / GO Crew GO ジョブ GO GX TOKYO PRIME 乗務員 App 充電インフラ提供、エネルギーマネジメントシステムの提 供、EV車両リースなど商用車の包括的脱炭素化サービス 事業者協力型 自家用有償旅客運送 導入支援 「日本型ライドシェア」対応 「自家用有償旅客運送」対応 市中の急速充電スポットの検索・予約・決済 がオンラインで完結するEV充電サービス
5. © GO Inc. 5 プロジェクト概要 ドラレコの映像とセンサーデータから標識などの道路情報を 認識し地図との差分を検出するプロジェクト センサ情報 ドラレコ映像 車両位置の推定 道路上の物体を検出 当システム 物体位置の推定 現地の道路情報 地図 現地と地図の差分 削除 追加 存在確認 比較
6. © 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
7. © GO Inc. AWS CDKを組み込んだ チーム開発の流れ 7
8. © GO Inc. 8 AWS CDKの使用状況 採用言語 管理スタック数 QA 385 PROD 60 DEV 80 運用期間 2020年7月~ 運用人員 データエンジニア 5人 MLOps エンジニア 1人 自慢すべきことなのか...? 当時TypeScript経験者は １人だったのに採用...
9. © GO Inc. 9 AWS CDK導入の経緯 導入時期 • 2020年7月(v1.54.0) なぜCDKを採用したか • 研究開発PJとして発足したため頻繁なスクラップ&ビルド が想定され IaC 導入は必須だった • 他のIaCと比較してシンプルで短く記述できる(と思った) • 99% AWSのインフラ構成されている • DEV, QA, PRODでの一貫性のあるインフラの構築
10. © 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アカウント
11. © GO Inc. 11 ロジックモジュール開発の流れ ロジック間のイン ターフェイス定義 共通インフラにリ ソースを追加 実装 結合テスト/デプロ イ - ロジック間のインターフェイス設計(主にデータ仕様) - 引き渡しに使用するサービスの選定(SQS、S3、RDS等) - 必要があればリソースを共通インフラのCDKに追加定義 - DEV環境に共通インフラをデプロイ - ロジックで使用するリソースをCDKで定義＆DEVへデプロイ - ローカル / DEV環境でロジックの実装 - CI/CD環境でQAへのデプロイ、結合テスト - CI/CD環境でPRODへのデプロイ
12. © 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 Workflows 独自実装の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リポジトリ ※コマンドはイメージです
13. © GO Inc. 13 ロジックモジュールのリポジトリ構成ルール 思想: 自分が使うAWSリソースは自分で管理しよう！ / |- deployments/ | |- cdk/ | |- container/ | |_ migration/ |- src/ |_ Makefile • /deployments/cdk ◦ ロジックモジュールに必要なインフラ 定義 • /src ◦ ビジネスロジック(srcじゃないことも) • Makefile ◦ 必ず以下ターゲットを実装する ▪ make build • ロジック、CDKなどのビルド ▪ make deploy • DB migration、CDKのデプロイ、イメージの PUSHなど
14. © 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となる
15. © GO Inc. AWS CDKによる量産型QA環境 15
16. © GO Inc. 16 CDKによる実験室 モチベーション 機械学習による認識モデルや複雑なロジックのパラメータ チューニング、ロジック選定のために気軽に作って気軽に壊せ る実験環境がほしい！ AWS Batch主体のこの部分の みを量産をする
17. © 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モジュール
18. © GO Inc. さいごに 18
19. © GO Inc. 19 やってよかったこと / うれしかったこと 真っ先にCDK含むCI/CDを作ったこと 高速にイテレーションを回す開発初期においてモジュール担当者がそれぞれ独立してインフラ含む開発 -> デプロイ -> テストのループを実施できた。 CDKのコマンド群を直接叩かない MakefileにCDKのビルド、デプロイターゲットを定義することでコンテキスト変数の指定忘れなどを防げる。 QA環境や実験環境デプロイの自動化により、CDKを知らないジョインしたてのメンバーでも即環境構築->ロジック 改善が可能になった。 野良リソース恐怖症になった CDKで管理されていないリソースを見つけると「おや？」と思うようになる。 権限管理が楽 grantXX関数でリソース間のアクセス許可を過不足なく設定できるので、サボってFullAccessつけちゃったりという 事象がなくなった CDKの冪等性は実験環境の構築にも力を発揮 パラメータが異なる環境を量産し実験することができ、定義さえ残っていれば環境を廃棄したあとでも特定のバー ジョンをチェックアウトして必要なときにまったく同じ実験が再現できる。
20. © GO Inc. 20 今から作るならこうするのに！/ 悩み cdk.jsonによる設定管理はやらない jsonによる定義は型チェックも働かないし、参照時もIDEによる補完の恩恵が受けられない。 型エイリアスを定義し型アサーションしたこともあったが、それなら最初からconfig.tsで管理したほうがいい スタック分けすぎ問題 当初TypeScript & CDKに慣れてないためリソース単位でスタック分割しているケースが多く、無駄なスタック間参 照が多い。Constructでリソースをまとめて1モジュール1スタックにする。 (ただ、Stack分けすぎた弊害がすごい大きいのかと問われると、そこまで困っていない...) CICD環境のロールの権限が強力過ぎるのが悩み すべてのモジュールのデプロイを行う＆モジュールがどのようなリソース作成や参照を行うか把握できないのでCICD がAssumeRoleするロールの権限を強くせざるを得ない。 そのためCICD環境のセキュリティは常に気を配る必要がある。 早めにコミュニティには関わっておく 悩みや成功体験は共有すべきですよね...
21. © GO Inc. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください