Hondaが取り組むAWSアーキテクチャ刷新の変遷、モビリティ・グローバル・サービスをつなぐスケーラブルな構成とは

アーカイブ動画

コネクテッドが実現。2800万台のパワーユニットがシームレスにつながる世界

本田技研工業株式会社
電動事業開発本部BEV開発センター
ソフトウェアデファインドモビリティ開発統括部
コネクテッドソリューション開発部 部長　野川 忠文氏

最初に登壇したのは、システム開発会社でシステムエンジニアを経験した後、Hondaにジョインした野川忠文氏だ。アメリカでの駐在も含め、一般的なカーナビでは取得することが難しい災害情報なども取得できる、Honda独自のカーナビシステム「インターナビ」の開発に従事してきた。

野川氏は仕事に対する意気込み、チャレンジングな気持ちを次のように述べた。

「20年間インターナビ、コネクテッドの仕事に携わっていますが、まだまだやりたいことが実現できているとは思っていません。コネクテッドでモビリティの世界を変えていきたいです」（野川氏）

Hondaは四輪自動車以外にも二輪自動車、マリン、小型ジェット機、発電機など、年間約2800万台もの人々が行動する「パワーと原動力」を生み出す製品を世に送り出している。

これらの製品をつなぎシナジーを生み出すことが、Hondaが描くソフトウェアデファインドビークルの世界観だと野川氏は語る。

「個別最適化されているハードウェアファーストの時代では実現が難しかったのですが、共通プラットフォームの進化など、ソフトウェアベースの開発への移行が進んできたことで実現できるようになってきました」（野川氏）

100年に一度の大変革期。自動車業界は、このような言葉で表現されることが多い。実際、自動運転や電動自転車、MaaSといった新しい技術やモビリティサービスが登場しているが、その実現において必須領域の技術が「コネクテッド」である。

Hondaでは1998年に最初のコネクテッド（テレマティクス）製品をリリースしたのをきっかけに、以降、数多くの世界初となる技術を実装した製品を世に送り出してきた。

例えば2003年のフローティングカーデータシステムは、それまで道路に埋め込んでいたセンサーからのデータにより交通情報を得ていたシステムを刷新。通信機能を搭載した車両からの情報とすることで、大幅なコスト削減を実現した。

今では当たり前の地図情報を常にアップデートするサービスも、Hondaが世界で初めてリリースしている。

Hondaのグローバル展開は2000年からであり、2013年からはオンプレからクラウドでも展開。現在は36カ国で、それぞれサービス利用の近いリージョンにクラウド基盤を展開している。

野川氏は、これまでのソフトウェアデファインドにおける課題を指摘するとともに、「解決するためには共通のクロスドメイン開発プラットフォームが必要」だと述べた。

In Car、Out Carのソフトウェア、さらにはデータ分析、実車データなど、すべてのソフトウェア環境をクラウド上の仮想化で行う。

各領域や職種関係なく、共通の開発プラットフォームをEnd to Endで構築することが重要であり、それが「爆速開発」にもつながるという。

野川氏は、このような開発プラットフォームを構築するために、AWSとのコラボレーションやイベント登壇なども行っていることを紹介し、次のメンバーにバトンを渡した。

失敗とチャレンジを重ね、数百万台が安定接続するクラウド基盤に成長

本田技研工業株式会社
電動事業開発本部BEV開発センター
ソフトウェアデファインドモビリティ開発統括部
コネクテッドソリューション開発部
コネクテッドソリューション課　野上 大樹氏

続いて登壇したのは、新卒でソニーに入社し、WindowsやAndroid環境のアプリ開発などに従事した後、ITスキルを自動車業界で活かしたいと、Hondaに入社した野上大樹氏だ。

野川氏が紹介したクラウド基盤についての変遷はもちろん、どのようなチャレンジを行ったのかを紹介した。

まずは2013年の初期の状況について。当初はオンプレ構成をクラウドシフトしただけ、EC2（Elastic Compute Cloud）が中心で、冗長化もAZ（Availability Zone）を2つ用いた程度であったと、野上氏は振り返る。

「まだまだひよっこなアーキテクチャでした」（野上氏）

ひよっこだったのは、アーキテクチャだけではなかったという。ELB（Elastic Load Balancing）のConnection Draining機能を正しく設定していなかったために、冗長化した2つのインスタンス両系統共が、ダウンするといったトラブルが発生した。

「こんな初歩的なミスをしてしまうなど、クラウドに慣れていないことが分かるかと思います」（野上氏）

それから約3年後となる2016年頃になると、モバイルアプリなど、複数のサービスが実行される状況となってきた。そのため、各種マネージドサービスなどを導入し、基盤の一部を刷新していった。

具体的には、データベースをRDS（Relational Database Service）に変更、オートスケーリングを一部のアプリに導入、Lambda、SQS（Simple Queue Service）、Kinesisといったサービスの利用などである。

このような刷新に伴い、運用スタイルも変わっていった。AMI（Amazon Machine Images）機能を使い、検証環境と本番環境2つのインスタンスを作成するなど、検証環境で確かめてから本番環境に移行するという流れとした。

新しいコードは手作業で検証環境にアップロード、車と接続し動作を確認。その後、更新後のAMI2を取得するという流れとした。

しかし、車が突然動かなくなるなどのトラブルが発生する。AMI2をオートスケーリンググループに設定していなかったため、AMI1の内容に戻ってしまっていたからだ。

そこで野上氏ら開発チームは、以下スライドのような検証環境も含めて、リリースはAMIで統一するという運用面における対策を講じることで、トラブルを解決していった。

同時期の基盤では、インフォテイメント系だけでなく、ストリームデータなど車両系データも扱うようになっていった。そこで、より積極的に車両データを扱えるシステムにすべく、Kinesisを活用したアーキテクチャを設計した。

テスト段階では問題なかったのでリリースに至るも、本番環境ではトラブルが発生してしまう。野上氏は、その原因を次のように述べた。

「実際のデータでは、どうしても処理できないデータが含まれていました。しかしその処理できない、読めないデータをもう一度キューに投入する設計としていたため、処理できないデータがどんどん溜まっていく事象が発生してしまいました。コスト増につながる懸念もありました」（野上氏）

次は、2020年の状況である。同時期はスマホを活用した各種リモート、コネクテッド機能の登場により、車両のアーキテクチャも変化。それに伴い、コネクテッド基盤も刷新することになり、新世代の基盤をスクラッチ開発していった。

データベースにはAuroraやDynamoを採用、コンピューティングはすべてコンテナ化。MQTT （Message Queuing Telemetry Transport）やAWS IoTも導入。「非常にうまくいっていた部分もありますが、変化し過ぎたことですごいことが起きてしまいました」と野上氏は振り返る。

具体的には、以下スライドのような構成を組み、得たデータを処理しAuroraに格納。モバイルアプリ、他のシステムとの連携などに活用できるようにした。

ところがしばらくすると、モバイルアプリの情報更新が遅いなどのクレームが入るようになったため、詳しく調べていった。

すると、データベースにつなぐコネクションプールの枯渇により、スループットが低下していることが分かった。結果として、入り口の部分でデータが滞留している状況が見えてきた。

データベースのスケールアップなどを行えば対処できるように感じる。実際、野上氏は当初はそのような対策も浮かんだという。

だが、この先コネクテッド基盤を利用する車両が増えることが明確であったため、アーキテクチャの設計そのものを見直すという対策で進めた。

見直しの際には、改めて構造のどこに問題があったのか、リアーキ部隊という専門チームを立ち上げ、検証していった。

すると、データの入り口で利用用途などを考慮せず、データを処理していること、無駄なフェッチ処理が多いことなど、それぞれの領域での課題が見つかった。そして、判明した問題点に対して、改善を行った。

最終的に刷新されたのが、下記スライドで示したアーキテクチャである。入り口のレーンを機能ではなく、用途ごとに分ける。その結果、可視化ツール用などすぐに必要ではないデータはバッチ処理で行うなどして、コストを抑える。

KCL（Kinesis Client Library）を活用したり、同じくDainamoDBを活用したりすることで異なるデータストアでもアクセスしやすくなるような工夫も行った。

最後に野上氏は、現在の基盤状況を紹介した。MQTTの利用用途を拡大し、AWSが独自開発したプロセッサGravitonを採用するなどして、運用系の機能強化ならびに安定性を実現している。

現在では数百万台もの車両が安定した基盤にまで成長したと成果を述べ、次のように改めてこれまでのチャレンジを振り返り、セッションを締めた。

「失敗してもいいけれど、繰り返さない。我々Hondaにはこのような文化があるので、これまで挑戦できてきたと思います。今後もチャレンジを続け、クラウド側からクルマのつくり方を変えていきたい。そのように思っています」（野上氏）

One for All? All for One?どちらが正しい？ グローバルサービス展開から得た学び

本田技研工業株式会社
電動事業開発本部BEV開発センター
ソフトウェアデファインドモビリティ開発統括部
コネクテッドソリューション開発部
コネクテッドソリューションプラットフォーム課　梁 ヒン淇氏

続いては、社内向けインフラの企画・構築を新卒入社後に担当した後、2020年より現在のコネクテッドクラウド基盤の開発に従事した、中国出身の梁（りょう）ヒン淇氏が登壇。地域展開におけるチャレンジについて紹介した。

野上氏が紹介したコネクテッドクラウド基盤には、最新の2023年と2020年バージョンでは開発における違いがある。それは、「One for AllとOne for Allの違い」だと梁氏は語る。

2020年ではグローバル担当チームが、車両連携機能といったコアの部分を作り上げる。そのコアを利用して、各地域のメンバーがお客様向けサービス、いわゆるフロントエンド領域をつくり込んでお客様に提供する流れであった。

それが2023年の直近の基盤では、グローバルメンバーが全サービスを作り上げ、それを各リージョンに提供するという流れに変わった。なぜ、変わったのか。梁氏はそれぞれにおけるプロコン（Pros & Cons）と合わせて説明した。

まずはOne for All、以前の開発体制におけるProsである。当然とも言えるが、各地域のビジネス環境や要件に応じて、サービスを作ることができる。具体的なサービス事例も合わせて紹介した。

続いてはconsである。地域の仕様をグローバルで把握できていないため、トラブルが発生。梁氏は実際に起きたエンジンのリモート操作でのトラブル事例を紹介した。GTSとはグローバル全体の基盤であり、RTSとは地域ごとのサーバーを意味する。

RTSでは、ステータスの中身を確認することなく、エンジンがついたという連絡をユーザーに送る仕様になっていた。そのためグローバルサーバー（GTC）は「失敗」と送ったのに、ユーザーには「成功、エンジンがついた」という連絡がいってしまったのである。

「凡ミスではありますが、我々グローバルメンバーではRTSの中身を確認できないため、起こってしまった失敗でもありました」（梁氏）

梁氏はもう1つ、One for Allにおけるcons事例を紹介した。セキュリティに関してである。地域のホワイトハッカーは、セキュリティの強度を確かめるために、擬似的な攻撃を行った。

ところがグローバル本部に連絡することなく、しかも本番環境で実施したため、ユーザーのサービスすべてを止める事態に発展してしまう。このようなトラブルを解消すべく、現在のAll for Oneの開発体制に移行することになった。

開発体制を変えると、効果は早速現れた。グローバルで一元的に運用管理を行うようになったため、まさに先のOne for Allにおけるconsが改善されたからだ。だが、All for Oneにしてもconsは発生してしまう。要件の擦り合わせである。

事前に仕様書を確認してもらうが、開発を進めていくとどうしても現場メンバーからは、新たな要望が出てくる。当初は一部対応していたそうだが、リソースや納期の関係から法規以外の要件は対応しないと決めた。

するとグローバル的には開発はスムーズに進むようになった一方で、地域部門にとっては自分たちが望むサービスなどが設計されないため、不満を感じてしまう問題が生じていった。

このような結果から、梁氏は次のように話しセッションをまとめた。

「One for All、All for Oneはどちらも一長一短あり、どちらかに寄せるものではありません。大切なのは、OneとAll どちらもが支え合いながら、グループ全体の利益最大化のための関係性を築いたり、行動したりすることだと考えています」（梁氏）

2カ月の現地テストが3カ月に延期。地域整合の難しさと得た学び

本田技研工業株式会社
電動事業開発本部BEV開発センター
ソフトウェアデファインドモビリティ開発統括部
コネクテッドソリューション開発部
コネクテッドソリューションプラットフォーム課　菊地 賢一氏

続いては、中学生のときにラリーカーに憧れ自動車業界に入ったという菊地賢一氏が登壇した。Web開発や事業の企画部門などを経て、現在はアジア地域の展開開発の責任者を務めている。

地域展開開発でエンジニアは何を求められているのか。今回のセッションでは、実際に地域開発で現地を訪れた際の苦労やそこから得た学びを語った。

まず菊地氏は、開発の流れやスキームについて述べた。車両の最終的な検証との兼ね合いから、今回の開発ではウォーターフォール型で行っている。地域ごとでのビジネスや法規の適合などを考慮しながら、検討を進めていくという。

最後の検証フェーズでは、グローバル基盤のGTCはもちろん、地域ごとのアプリケーションであるモバイルのフロントエンド領域まで行う。GTCからRTCがEnd to Endでリンクしているかはもちろん、すべての領域ならびにサービスや機能において、正しく動作するか動作検証を行い、最終的に品質を担保する。

今回の検証では、新しい要素が盛り込まれていたことに加え、コロナ禍の影響で一度帰国すると再度の渡航が難しくなるといった事情があった。2カ月間じっくりと現地に腰を据え行うこととなり、菊地氏もメンバーと一緒に海を渡った。

早速、地図情報に関するテストを行うも、結果を確認すると道路がない箇所をほぼ真っ直ぐ行き来しているような結果が得られてしまった。つまり、この機能にはバグが残っていたのである。しかし、菊地氏も先の2人と同じく失敗を振り返り、学びを得たと語る。

まずはなぜ、このような事象が生じたのか。走行日数が限られていたため片道100km以上あったそうだが、期間内に必要な走行テストを終える為、一度に走る距離を長くしてデータを取得した。

この一気にデータ取得したことでバグに直面することとなったと、菊地氏は分析する。というのも、サードパーティ製の地図APIの仕様を確認すると、一度に規定以上のデータを送るとエラーが発生するという記述があったからだ。

設計にあったにも関わらず、長距離走行をするまで見抜けなかったことは、実装品質や上流テストでの弱さがあったと、菊地氏は振り返る。

続いては、通信プロトコル、MQTTのテストでのトラブルである。何度かテストを重ねていくと、明らかに速度が満足するものではないという事象が発生する。

菊地氏らは原因を明らかにするために、車両ログ、パケットキャプチャなどを取得し、AWSの方でパケットロスが起きていないかなど、GTCの開発チームにも確認してもらうなど、関係者が集まり、ありとあらゆる方法を試みた。

その結果、通信キャリアの持つパケットGWで利用されている技術との相性により、高速通信を保てなくなっていたことを見つけ出す。しかし、菊地氏は次のように述べた。

「解消することはできましたが、解消の提案をしてくれたのは、通信キャリアのエンジニアでした。つまり、ネットワーク領域の深い部分で起きていたトラブルだったため、通信キャリアが変わり、再び同じような事象が発生しても、私たちだけでは対応しきれない問題であるということです」（菊地氏）

だが菊地氏は、このようなトライアンドエラーも含め、コネクテッド領域はクルマという巨大なフィジカルを、クラウド側の動きも考慮しながら取り組んでいく。「強大で謎解き的な仕事であり、だからこそ面白い」と語った。

このようにコネクテッド領域におけるソフトウェアエンジニアの仕事の面白さ・やりがいと特徴を述べ、セッションを締めた。

【Q＆A】参加者からの質問に登壇者が回答

セッション後は、イベント参加者からの質問に登壇者が回答した。

Q．リージョンが複数あるとAWSアカウントの管理が大変なのではないか？

野上：おっしゃるとおりです。そこで社内にクラウドCoEというグループを設け、Organizationsの管理などを行っています。

Q．AWSを選んだ理由は？

野川：GCPやAzureも検討しましたが、AWSはそもそもAmazonのインフラを構築するために生まれたものです。まさしく我々が行いたいのもSDVのプラットフォーム環境の構築でしたから、いろいろとナレッジが共有できるのではないかと感じ、AWSに決めました。

Q．国や会社ごとに異なる通信や認証にどのように対応しているのか

菊地：私たちの部門ではありませんが、通信機側を専門に開発しているメンバーがいて、それぞれの地域や国で使われている電波をすべて捉えた上で、適切な周波数帯の電波を使い分けて認証を進めている状況です。

Q．個人情報保護法などは国ごとに異なる。どのように対応していったのか？

梁：中身も含めて規制が緩い国、逆に厳しい国もあります。その中でGDPR（General Data Protection Regulation）が一番厳しいため、基本的には同法律をクリアする前提でシステムを構築しています。

Q．通信プロトコルにおいて、CANなど自動車とHTTPなど、AWSとの変換アーキテクチャは大変か？

野上：CANやLINの周期はすごく細かいため、データを全部クラウドにアップするとボリューム的にもその後のクルマ側の処理負荷となるため、現実的ではありません。

そこで周期を落としたり、データを集めたりするタイミングやトリガーを絞って、部分的に高周期で集める仕組みを構築しています。このような考えは今広まっており、AWSのサービス、Fleetwise、他のサードパーティツールも同様だと思っています。

Q．ウォーターフォールからアジャイル開発への移行における課題や取り組みは？

野川：最終的にクルマはインテグレーションテストを行う必要があるため、そこに関してはウォーターフォールに合わせる必要があります。

一方で目線を変えると、その最終テストまでに作るものに関しては、具体的にはクラウドやアプリはアジャイル開発で開発できるため、変えられる部分は変える。このようなスタンスで、アジャイル開発も取り入れています。

Q．地域展開において、SDKを用意して地域ごとでカスタマイズする体制を取らなかったのはなぜか？

菊地：実は以前、作ったことがあります。すると既に各地域にアプリはあるので、逆に組み込む方が難易度が高いといった理由で導入する地域がほとんどありませんでした。このような失敗を経て、現在も最適解を模索しています。

Q．AWSに詳しくない関係者への説明や調整はどのように行っているのか

野上：個人的な理解ですが、目的がしっかりとしている。必要なアプローチもロジカルに説明できる。このような条件が整っていれば、中身の細かい部分は理解してもらえなくとも必要性は伝えられるし、承認してもらえると捉えています。

野川：正直、私は中身の深いところまで理解していません（笑）。ただ現状維持では新しいものは生まれませんし、新しいことを実現するために必要なものなのだろう。そのような理解ならびに判断できていますので、詳しいメンバーに任せるようにしています。

Q．All for OneとOne for Allはトレードオフの関係なので、いいとこ取りするのは難しいのではないか

梁：たしかに非常に難しいと考えています。イメージとしては、One for Allするとグローバルと地域の責任割合は半々です。逆にAll for Oneにするとほぼ100％我々、グローバルの責任に捉えられがちです。そこでグローバル70％、地域30％ぐらいの線引きがよいのではないかと考えています。

Q．企画、開発、地域部門が一緒にやって成功させるポイントとは？

野川：それぞれ立場や考え方が異なるので、かなり難しいです。ただ私は幸いにして各業務をこれまでのキャリアで経験しているため、それぞれの考えや求めていることが理解できます。そのため、相手の立場に立った上でのコミュニケーションを心がけていますし、うちのメンバーも同じくさまざまな地域を訪れているので、同じような気持ちだと思います。

本田技研工業株式会社
https://www.honda.co.jp/

本田技研工業のキャリア採用情報
https://www.honda-jobs.com/

本田技研工業の採用情報
https://global.honda/jp/jobs/?from=navi_footer_www