トヨタ自動車との協業の実証実験開始当初は車両からのデータは大きなセンタに集めて、センタ内で多数のサーバを並べて分散処理していました。しかし、それでは目標となるスケーラビリティ（3000万台）と処理時間（7秒）を達成することができなかったため、車両とセンタの中間にエッジを配置し、エッジで一部のデータ処理を実施するようにしました。通常エッジというとデバイスそのもの、コネクティッドカーでは車両にあるコンピュートリソースをイメージすることが多いと思いますが、本協業ではセンタ基盤と車両の中間にあり、地理的に分散する拠点上に配置されたコンピュートリソースをエッジと呼び検討しています。
エッジを利用する際には、対応するアプリケーションアーキテクチャの確立だけでなく、ネットワーク技術という観点では、分散する拠点とサーバに対応して、負荷分散を考慮してデータを適切に運んでいくことが課題でした。そのために、車両とアプリケーション群の間に、「複数のネットワーク機能を持たせた基盤システム」を含むアーキテクチャを策定し、課題への有効性を実験にて検証しました。本協業では、この基盤システムを、同じくエッジ拠点上に配置するアプリケーション群とは区別するために、ネットワークエッジと呼んでいます（図1）。
ネットワークエッジは、車両視点ではデータアップロードの際に、またセンタ側アプリケーション視点では、ダウンロード方向である車両通知におけるゲートウェイとしても働き、ネットワークやインフラの複雑さを隠蔽し、アプリケーション開発者が機能開発に集中できるようになることをめざしました。

対応するユースケースを絞り込み過ぎないように、ネットワークエッジの検証では、基礎となるユースケースとして「車両の移動」と「広域切替」の2つを定めました（図2）。
1点目は「車両移動」に合わせて、接続先アプリケーション設備やサーバの切替を行うユースケースです。エッジでの処理は基本的に車両に近いエッジ、最寄りの拠点でデータ処理をして近隣の車両に対してフィードバックをするという、データの地産地消の概念に基づいており、車両が移動すると接続すべきエッジ拠点、さらに、その中のアプリケーション実行サーバも切り替えていくことが必要になります。それをネットワーク技術でサポート可能か検証しました。
2点目の「広域切替」は、拠点での障害発生や負荷分散をトリガーとし接続先アプリケーション設備の切替を行うユースケースです。エッジ拠点が分散してくると、エッジ拠点の故障・過負荷によって、隣接する拠点で処理を行いたいというニーズが出てくるため、ネットワークエッジとして故障を検知して切替えサポートが可能か検証しました。

ネットワークエッジに持たせた主な機能は、各データセンタ拠点・アプリケーションサーバへの経路制御と、メトリクスを活用したロードバランシング、広域分散メッセージキューの3つです。地理的な分散について除外すると、車両からのデータはモバイル網等の無線アクセス網を通ってネットワークエッジに到達します。そこで上記機能による制御を経て、エッジ上のアプリケーション群、場合によっては直接センタ上のアプリケーション群にデータが送られます。
実証実験では、2つのユースケース確認のために東京と大阪のデータセンタを使って、複数のネットワークエッジ拠点が存在する環境を実装し、3つの機能の有効性を検証しました（図3）。また、車両との通信はセキュリティ上TLS（Transport Layer Security）を用いた暗号化通信を想定しており、ネットワークエッジでTLSを終端することがボトルネックになる可能性があるため、TLS終端の性能検証を実施しました。以降では、それぞれの検証内容について説明します。

車両からアプリケーションサーバまでの経路制御の実現手段として「DNS方式」と「ロードバランサ（LB）方式」の2つを検討し、車両の移動、広域切替（設備故障）による挙動と、それぞれの基本機能と性能を確認しました。
①　DNS方式：最寄りのDNSサーバまではBGP Anycastで誘導され、DNSサーバが最適な拠点・アプリケーションサーバを選択し車両に通知します。
②　LB方式：最寄りのLBサーバまではBGP Anycastで誘導され、LBにて車両からのリクエストを最適な拠点・アプリケーションサーバへ転送します。
LB方式では、常にLBを介してアプリケーションと通信するので、性能面で不利になる一方、より細かい制御ができるようになります。実験初期に2方式の比較試験をし、どちらもユースケース対応が可能であることが分かったため、後半はLB方式をベースに実験をしています。

複数の拠点、さらに拠点内にも複数のサーバが並んで分散して処理を実施するというアプリケーションを前提に、どの拠点・サーバで処理を行うか、メトリクス情報を基に判断して、前述した経路制御も用いながら負荷分散する検証を実施しました。
アプリケーションサーバからの応答時間や設備情報、インフラリソースのメトリクス等を取得することで、サーバ、拠点の障害やソフトウェアプロセス障害、過負荷を検知し、状況に応じて負荷分散することと、極端な性能低下を回避できるか検証しました。実験の中では、アプリケーション負荷がしきい値を超えたことを検知し、拠点1で処理していたものを、7割は拠点1、3割を拠点2にオフロードするように、指定した割合で広域に分散することも検証しました。

ここまで何度か拠点やノードの障害について触れましたが、障害対応が拠点切替だけだと、その間、車両からのデータ送信は失敗します。その場合、車両はデータを再送するか、場合によっては送信を諦めることになるのですが、それを防ぐことが本機能の目標です。
メッセージキューという言葉から連想されるとおり、一時的にデータを受け取るという機能を持ちます。各エッジ拠点にメッセージキューがある状態になりますが、その間で連携をして、処理のオフロードをする場合でもデータを必要な拠点にまで運びます。
また、移動に伴って、接続するエッジが切り替わっていくので、センタ側から車両に対して通知をする際に、現在どこに接続しているのかが問題になります。それも、この仕組みを使って解決をめざしました。アプリケーションからはいったんメッセージを受け取り、仮に車両が別のエッジに移ってしまった後でも、受け取れるようになった段階で確実に送るということを検証しました。
これらをApache Kafka等のソフトウェアだけで実行しようとすると、無駄に拠点間でデータのやり取りをすることになったり、送達管理ができなかったりという問題が生じます。それをうまく処理するために、基本的なメッセージキュー機能はオープンソースソフトウェアであるNATSを利用しつつ、独自開発したProxy等を組み合わせたものをつくって検証しています。また、アップロードとダウンロード（通知）で求められる特性が異なるため、前者は対象データを選別して送信する仕組みを、後者はメタデータを共有し拠点をまたいで論理的なキューを構成する仕組みとなっています。

車両からの通信はセキュリティの関係上、TLSを利用して送られてきます。アプリケーションはHTTP（Hyper Text Transfer Protocol）やMQTT（Message Queueing Telemetry Transport）を使っているので、HTTPSやMQTTSで通信します。経路制御でLB方式を利用する方針にしたため、L7のソフトウェアLBで大量のトランザクションをさばく必要があり、通常のチューニングだけではCPUボトルネックとなることが想定されました。そこで、TLS処理を別のハードウェアにオフロードし、性能向上とリソースの効率化を確認する検証を行いました。ハードウェアは標準AMD64サーバに搭載可能な、TLS Accelerator、SmartNICの2種類を用いて、検証を行いました。車両からのアップロードが中心のトラフィックでは、まだ十分な効果が確認できていないものの、数1000万台車両を対象とするコネクティッドカーシステムではリソースを効率的に利用することで必要なサーバ台数を最小に抑えることが重要になるため、今後も継続して検証したいと考えています。

今回の実証実験を通して、車両とアプリケーション群の間に、複数の機能群を持つネットワークエッジを配置するアーキテクチャを実装し、その有効性を確認することができました^（1）。
これを基本形とし、各技術をさらに発展させるとともに、他技術の組合せも試行して、より高度な基盤の実現をめざします。例えば、メトリクスによるロードバランシングでのAI（人工知能）適用や、アプリケーションサーバ群の優先制御との連携等を考えています。インテリジェントなネットワーク基盤技術によって、高速移動する数1000万台車両のリアルタイム通信をサポートし、複雑なインフラ条件を気にすることなくアプリケーション開発に専念できるような世界を実現するため、継続して取り組んでいきます。

■参考文献
（1）　https://group.ntt/jp/topics/2021/11/29/techdoc_rel_ntt_toyota.html