会社の期待を背負った新商品のAWSクラウド活用の裏側を話します！
パイオニアが昨年3月に満を持して発表した新商品である、“会話するドライビングパートナー”「NP1（エヌピーワン）」。
次世代通信型ドライブレコーダー、スマート音声ナビ、クルマWi-Fiなど多彩な機能を搭載し、運転中のあらゆる場面で会話を通してドライバーをサポートする世界初※のAI搭載通信型オールインワン車載器です。
今回は若手クラウドエンジニアがNP1の新機能である「マイカーウォッチ」のAWSアーキテクチャについて紹介します。
※ドライビングパーソナル音声AIを搭載したコネクテッドデバイスとして、ESP総研調べ （2022年3～4月実施のカーエレクトロニクス製品に関する市場調査）
自己紹介
皆さん、はじめまして！
2018年に新卒入社して現在5年目になるクラウドエンジニア 兼 データエンジニアの吉山です。
趣味は楽曲制作活動で、最新技術に日々驚愕しながら試行錯誤しては偶然の産物に一喜一憂する そんな忙しない日々を繰り返しています。
パイオニアでは、市販製品（NP1、サイバーナビ）のクラウド機能開発業務やデータ分析業務（データマネタイズ、データエンジニアリング、プラットフォーム構築）に携わっています。
直近では、2022年12月22日にリリースされたNP1の「マイカーウォッチ」のクラウド機能開発を担当しておりました。
マイカーウォッチの詳細はこちら↓
今回の記事では、Amazon Web Services（以下、AWS) での開発の肝となるAWSアーキテクチャについて、マイカーウォッチの事例を踏まえつつ紹介していけたらと思います。よろしくお願いします！
そもそもAWSアーキテクチャとは？
AWSアーキテクチャとは、数あるAWSサービスをどのように組み合わせてサービスを実現するのかを表現したAWSサービスの設計図のようなものです。
ユーザーに対して同じサービスを提供するとして、要件に応じて適切なAWSサービスを選択できなければ想定以上の運用費が発生してしまったり、インシデントが頻発しやすい設計となってしまいます。
例えるなら、カレーを食べるときってスプーンを使いますよね。でもカレーの具をがっつり食べようとしてフォークを使うとカレー自体を食べにくくなりますよね。
逆にパスタを食べるときはスプーンじゃなくてフォークの方が食べやすいですよね。食べやすさによってコストがかかるイメージです。
食材（要件）に合わせて適切な食器（AWSサービス）を選択することが大切です。
逆に言えば、適切なAWSサービスを選択できさえすれば、より運用費を安く、より迅速にクラウドシステムを実現することに近づきます。
感覚としては、パズルを組み合わせていかに最適な組み合わせを見つけられるかのゲームをしている感覚に近いです。カツ丼を食べるときは丼ぶりにお箸！シチューを食べるときはスープカップにスプーン！パスタを食べるときにはお皿とフォーク！食べるもの（要件）によって食器（AWSサービス）同士の相性も大事になるということです。
AWSでは、要件（食べるもの）に応じてベストプラクティス（おすすめの食器の組み合わせ）が紹介されているので基本的にはそれに則って設計することが多いです。※執筆者 個人の見解にもとづく説明です。
NP1について
では、早速NP1のマイカーウォッチのAWSアーキテクチャを紹介していきたいところなのですが、その前にNP1とマイカーウォッチの機能について簡単に紹介させてください。
NP1は、車載端末、クラウド、アプリが融合され音声によってナビゲーションやおすすめスポットの紹介、クラウド連携ドライブレコーダーなどさまざまな機能を提供する「会話するドライビングパートナー」です。使い方や設定、案内補助などは、MyNP1アプリを使ってより便利に使えるようになります。
マイカーウォッチについて
マイカーウォッチは、NP1に搭載されている機能の一つで車外のスマートフォンからNP1の映像をリアルタイムで確認できます。
駐車中に衝撃検知をした際、周りの状況を確認したり、駐車場で車の位置がわからなくなってしまったときに位置情報と映像で場所を確認するなどの使い方ができます。
実際の操作画面がこちらです。MyNP1アプリを使うとNP1が見ている映像を車外にいながら確認することができます。
マイカーウォッチの機能の中で、クラウドはどんなことをしているのかというと主に以下のことが行われています。
マイカーウォッチ残り利用時間の管理
NP1とスマートフォンの状態管理
マイカーウォッチ（映像・音声共有）を行うためのリソース作成
それらをどのように実現しているのかアーキテクチャを元に説明していきましょう。
マイカーウォッチのアーキテクチャ
マイカーウォッチを実現しているAWSアーキテクチャが以下になります。
認証関係や顧客データ管理等の情報も書き出してしまうと煩雑になってしまうので、ポイントとなる箇所だけに絞って表現しております。
それぞれのAWSリソースがどのように機能しているのか、マイカーウォッチの使い方の流れと合わせて説明していきます。
まず、ユーザー視点でマイカーウォッチをはじめる際には、スマートフォンアプリMyNP1からマイカーウォッチの画面へ遷移し、マイカーウォッチで接続したいNP1を選択し、「NP1に接続する」ボタンを押下します。
このとき、AWSクラウドでは、マイカーウォッチの映像共有に必要となるAmazon Kinesis Video StreamsのSignaling Channel（画面共有するために必要なリソース）、AWS Security Token Service（画面共有を一時的な認証をするために必要なリソース）を生成します。
■AWSサービスの選定ポイント①：
マイカーウォッチでは、リアルタイムで映像を共有するという要件があり、それを実現するためにKinesis Video Streamsを採用しました。完全マネージドなサービスで保守性が優れている点と他のAWSサービスと連携しやすい点の2点を重視しました。
生成したSignaling ChannelやSecurity Tokenなどの情報は
Amazon DynamoDBで管理します。マイカーウォッチ残り利用時間の管理もこちらで行います。
■AWSサービス選定ポイント②：
マイカーウォッチはプル型の機能ゆえ、機能の使用傾向が読みにくい特徴があります。そのため、DBはスケーリング性能に優れていてかつ高スループットのDynamoDBを選定いたしました。AWSのDB代表格であるAmazon Relational Database（RDS）を使用するケースを検討しましたが、運用費の試算を行ったところDynamoDBに軍配があがりました。
リソースの生成が完了したら、ウェブアプリケーション用のURLをスマートフォンに渡してスマートフォンをMyNP1アプリからウェブアプリケーションへ遷移させます。
スマートフォンではMyNP1アプリからWebブラウザに遷移後、接続待ちとなります。
マイカーウォッチ機能は車のエンジンがOFFの状態でも使える機能なのでNP1を起動させる必要があります。なので、この接続待ちの間にクラウドはIoT Coreを通じてNP1に対して起動リクエストを送信します。
■AWSサービス選定ポイント③：
NP1はエンジンOFF中にもリクエスト を受信するためバッテリー電源の少ない電力でメッセージ受信待機しなければなりませんでした。そのため、軽量で双方向通信可能なMQTTを採用することになりAWS IoT Coreを選定しました。将来の拡張性が高い点とセキュリティ機能が豊富な点も選定のポイントとなりました。
NP1が起動すると、クラウドに対してステート確認を行います。必要なAWSリソースが事前に作成されているか、スマートフォン側のコネクションが切れていないかなどを確認します。確認して問題なければ、画面共有に必要な情報をNP1とスマートフォンに伝えます。
その後、NP1側とスマートフォン側が受け取った画面共有情報をもとに映像を繋ぎます。
これでNP1と映像共有して車内外の状況を確認できる、という流れになります。
サーバレスアーキテクチャにこだわった理由
マイカーウォッチのAWSアーキテクチャのポイントはサーバレスアーキテクチャであることです。
サーバレスアーキテクチャとは、（明確な定義はされておりませんが）常時稼働するサーバーを運用せず、マネージドなサーバサービスだけを選択することで、あたかもサーバーが存在しないかのように振る舞うアーキテクチャです。
サーバレスアーキテクチャの魅力、こだわった理由は以下の通りです。
1: 運用が楽だから！
個人的にはサーバレスの最大の魅力だと思っています！サーバーの存在を意識する必要がないのでサーバーの調達やOSの保守、スケーリング、可用性などについての悩みを少なくすることができるため、集中して機能開発に取り組むことができます。
特にNP1は日々アップデートされていくため開発にスピード感が求められます。そのため、考えること・悩みポイントを減らせるサーバレスアーキテクチャは重宝しています。
2: 安い運用費ではじめやすいから！
もしマイカーウォッチのアプリケーションをサーバレスではない常時稼働させた仮想サーバーEC2で構築した場合、マイカーウォッチが使用されていない期間も余分に仮想サーバーの料金が発生してしまいます。
さらに料金節約のために常にAmazon Elastic Compute Cloud（Amason EC2）のリソース（CPU、メモリ）をふんだんに使われているようにチューニングするには熟練の技とユーザー傾向の把握が求められるためハードルが高いです。
その点、サーバレスはユーザー利用に応じてアプリケーションが起動し、処理が完了したら終了するためリソースをあますことなく使用することができます。料金も使った分だけ課金されるためアイドルタイムを気にしなくてもよい部分も大きなメリットです。
3: IoT開発と相性がいいから！
IoTデバイスでは様々な機能を持っていたり、新しい機能が追加・修正されたりすることが多いです。NP1も同様でマイカーウォッチ以外にもドライブトピックやドライブコールといった複数の機能を持ち、アップデートで新しい機能・修正が日々追加されていきます。
そこで大事な考え方となるのがマイクロサービス化です。各機能をマイクロサービス化し、責任分界点を明らかにしつつ疎結合とすることで機能の拡張や修正を行いやすくなり、より開発のスピードをあげることができます。
もし開発でなにかしらの失敗をしたとしても影響範囲を絞ることができるので他チームに影響を与えにくいというのは心理的な負担を軽減することができます。
パイオニアでのAWSアーキテクチャの決め方
AWSのアーキテクチャは基本的に機能担当者が提案することが多いです。それでもし、不安な点・不明点がある場合はAWSのサポートに頼ったり、自社内でそれが得意分野の人に相談したりして解決します。
社内には、データ処理が得意な人や運用費の節約が得意な人たちなど、それぞれ個性的なスキルを持った方々がたくさんいますので相談内容に応じて適切な相談相手を選ぶことも大事になってきます。
面白そうな人に積極的に声をかけて仲良くなると後々大きな成果に繋がることもしばしばあります。
接点のない人同士が1つのプロダクトに対して熱中できる、そして化学反応を起こす。これが組織でのものづくりの醍醐味だと私は考えています。
また、アーキテクチャ設計は何を重視して設計するのか要点を抑えるセンスと知識を問われる分野ですので同僚やチームで議論する際にはとても盛り上がります。
最近のエピソードだと、ある機能を実現するためのAWSアーキテクチャを決める際にDBをどのAWSサービスにするかで意見が分かれたことが印象的でした。
上司がAmazon Neptune、先輩がDynamoDB、私がAmazon RDSを提案し、それぞれのメリット・デメリットについて議論し合ったのです。
それぞれ人によっての価値観やスキル、サービスの展望が異なるので新しい観点に気づけたり、フィードバックがあったりと学びが多いのでアーキテクチャの議論は面白いです。さらに、自分の提案したアーキテクチャが採用されたときは達成感が得られます。
そのときは、私が提案者の中で一番の後輩だったのですが、パイオニアには個々の意見を尊重する文化が根付いているためどんなに年下であっても どんなに経験がなくとも意見をないがしろにされることはありません。よりよいプロダクトを作り上げるためには、経験や年齢関係なく同じ目的をもって議論し、行動することが大事だと私は思っています。
最後に
以上がNP1のマイカーウォッチのクラウド開発の肝となるアーキテクチャについての紹介です。
パイオニアでは変革に向けて一緒に働く仲間を募集しておりますので、もっと深くAWSのことについて語りたい方、よりよいプロダクトづくりについて熱い思いをお持ちの方は是非ともごお応募ください！