はじめに
2020年2月14日に開催されたDevelopers Summit2020に参加してきました。
テーマ
【14-A-7】TOYOTA x Serverless x Microservices 〜 グローバル展開のコネクティッドカーを支えるアーキテクチャとエンジニアリングチーム
カテゴリ
アーキテクチャ
登壇者
- 浦山 雄也さん[トヨタ自動車]
- Uchiumiさん[AWS]
発表資料
講演メモ1：浦山さんより
若手主導のチャレンジングなチーム
- 20代中心のチーム
- 裏山さんは入社３年目
- めっちゃ若い
なぜトヨタがサーバレスを選んだか？
- コネクテッド・カーのプラットフォーム開発
- ×エンドユーザのスマホ
- 車のヘルスチェックサービス
- ×security
- 盗難検知
- 追跡
- エンジンをかからなくする
- ×エンドユーザのスマホ
- 日本、中国、北米でサービス開始
- 圧倒的スピードでお客様へ
- 爆速でやる
圧倒的スピードでお客様へを実現するには
- 人的・コストリソースの確保がマスト
- トヨタとは言え無限にあるわけではない
- 価値を産まない無駄を削減
- トヨタが得意とする領域
事例１：無駄の削減
- 1日のアクセス推移
- 夜間：低
- 日中：12倍
- 従来
- 常時MAX＋αのリソースを確保していた
- サーバレス化
- 必要な文だけプロビジョニング
事例２：長いライフサイクルへの対応
- 車何年乗る？
- 平均8.5年
- 8.5年動くハードウェア
- 動き続けているコネクティッドサービス
- 維持・保守の無駄
- サーバレス化
- 無駄をすべてマネージドに
事例３：より広い地域での提供
- 法整備がまだまだ整備中
- 各国個別に対応
- シェア大の国
- シェア小の国
- 最低リソースの確保が困難
- サーバレス化
- シェアに合わせてリソース確保
プラットフォームの概要
- 世界規模、事業体レベルで疎結合
- Mobility Gateway
- クルマと地域サービスを双方向につなぐGateway
- 必要機能数：約250
- capability
- 機能が多く、大規模
- 学習が容易であること
- 変更や拡張が継続発生
- 短いサイクルでリリース
- ダウンタイムが広範囲に影響
- 局所化する仕組みが必要
- 負荷が大幅変動する
- キャパシティを動的に拡大縮小
- 安価で価値提供
- 不要な待機リソースを抑制
- 機能が多く、大規模
- 設計指針
- 一貫して分割
- 自立・緩やかに統合
- ステートレス
講演メモ２：AWS内海さん
アーキテクチャスタイル
- Nティアー
- 伝統的なアーキテクチャ
- HTTP <-> 設計対象
- 構成要素３つ
- Gateway
- ロジック
- データ
- 伝統的なアーキテクチャ
- ウェブ・キュー・ワーカー・イベントドリブン
- マイクロサービス
- 小さく分割していく
- ライフサイクル毎にまとめる
設計
- 車載デバイスと地域サービスをつなぐGateway
- 論理モデル
- ９つのビルディングブロック
- 中央にデータ
- 四隅にプロセス
- プロセス間はインテグレーションでつなぐ
- ９つのビルディングブロック
- 物理モデル
- Gateway＋ウェブプロセス
- ２パターンある
- リアクティブ
- API Gateway＋Lambda
- プロアクティブ
- ALB+Fargate
- 即時応答
- スケーリングに余裕をもたせたい
- ALB+Fargate
- リアクティブ
- ２パターンある
- データ
- DynamoDBで全て管理
- オンデマンド
- ProVisioned
- DynamoDBで全て管理
- インテグレーション
- SQS
- SNS
- Kinesis Data Streams
- シャードの数を変えてスループットを上げられる
- ワーカープロセス
- Lambda
- Gateway＋ウェブプロセス
- 構成としては非常にシンプル
- ただし、実際のデプロイメントが非常に多い
- 独自の運用ツールを作った
- プラットフォームチームをどう作るか
講演メモ３：松本さん（トヨタ）どんなチームを作ったか？
セオリー
- アーキテクチャと組織を一致させる
- 地位遺作自立し、開発運用するまでカバーするチーム
- できなかった（涙）
- 車載デバイス開発と地域サービス開発の協調が必要
原因
- ２チームのスタンスがぜんぜん違う
- 車載デバイス
- 人命に関わる
- 厳格な長期開発
- 数年かかる
- １ヶ月で作ったクルマには乗りたくないwww
- 地域サービス
- 数ヶ月で作る
- 単回開発を何度も繰り返す
- お客様ニーズが何度も変化する
- いわゆるアジャイル
プラットフォームチームを、どう組織したか？
- 責務に合わせてチームも切る
- 車載チームとやるなら厳密な仕様ですすめる
- サービスチームとやるならアジャイル
- （セオリーは無視できないので）最後はもとに戻した
- すごい大変だった
- やるべきことと判断して、ワンチームにした
- 繰り返し繰り返し改善してきた
- 少しずつ戻してきた
開発から運用までできるチームをどう組織したか？
- 求める人材
- AWS
- 車載デバイス知識
- 開発スキル
- Scrumスキル
- 運用スキル
- 上記５つを持つ人
- 要求スキルが高すぎるwwwwwwww
- 結局、今のチーム全員で勉強しながら、スキルアップした
- 振り返り
- 初めてのScrum
- ボードに色々書いた
- 目標ベロシティを定めた
- 自分たちのPJにどう当てはめればいいかわからない
- 手探りで進めるのは危ない！！！
- アジャイルコーチを招致した
- 作ったアーキテクチャが正しいのかわからない
- 自身が持てない・・・
- AWSに聞いてみた
- 考えていたアーキテクチャはあっていた
- あと一歩伸びが足りない
- AWS勉強会を実施
- スキルの個人差が広がってきた
- さらにペアプロ・モブプロ
- 目標ベロシティ達成！！
- メンバー追加
- Knowledge集約を実施
- 教育体制を整えた
- サービスイン！！
- 問題解決能力も上がってきた
- クルマ１台あたりのクラウドコストをいかに削減するかなど高度な議論ができるようになった
- 初めてのScrum
講演メモ４：浦山さん（トヨタ）達成できたこと
困難を乗り越えた先に何が起こったか
- 目標
- 無駄の削減
- 運用コストが５０％減
- 結果、開発にコストが使えるようになった
- 結果、開発サイクルが高速化した
- １ヶ月に624回デプロイ（開発～本番）
- サーバレスやってよかった！！
- 無駄の削減
今後
- スケーリング最適化など
感想とまとめ
日本を代表する企業トヨタがデブサミにいる！！ということで、どんな話をされるのか楽しみにしていました。これからの未来を担うコネクティッドカーをAWSのサーバレス技術を使って、スクラムチームを組んで実現していく実体験は、まさにエンジニアの現場そのものでした。トヨタは製造業ですが、今後、車の在り方が大きく変わるにつれて、情報製造業にシフトしていくのかなと実感しました。ハードウェアとソフトウェアの両方が作れることが強みになるのかしれません。
私は車を持っていないため、普段は車に全く乗りませんが、トヨタのコネクティッドサービスは使ってみたいなと感じました。これからもトヨタを応援しています！
