1.　はじめに

ネットワークに接続された車であるコネクティッドカーの普及が進んでいる．コネクティッドカーはネットワークを介してクラウド上のシステムと連携し，ナビゲーションや情報配信といったインフォテイメントサービスを実現している．今後は，運転支援や自動運転，車両センサ情報収集等の様々なコネクティッドサービスの実現が期待される．

クラウド上のサーバへの車両アプリケーションのコンピュテーションオフローディングは今後実現が期待されるユースケースの1つである[1]．特に，自律自動運転機能を搭載したコネクティッドカー（Connected and Autonomous Vehicle; CAV）のアプリケーションのオフローディングが期待される．CAVはサーバに匹敵する規模のコンピュータを搭載し，推論処理等の複雑な計算処理を行う様々なアプリケーションを常時実行する[2]ため，車両バッテリーを大きく消費する．このような処理を積極的にオフローディングすることで，車両バッテリー消費を節約し走行可能距離を拡大できる．また，オフローディングが中心になることで，車載機の求められる機能がシンプルになり車載機の開発コストが削減されると期待される．

しかし，CAVのアプリケーションの多くは低遅延応答が求められる[3]．特に，サーバからの遠隔運転を行うアプリケーションは常時安定して処理応答時間が往復100ミリ秒以内に収まる必要があるとされる[4]．しかし，クラウド上のサーバと接続する場合，無線アクセスネットワーク，モバイルコアネットワーク，そしてインターネットを介してサーバと接続する必要がある．各ネットワークでそれぞれ通信遅延が変動するため，End-to-Endで常時100ミリ秒以内の処理応答時間を維持することは不可能であることから，クラウド上のサーバでオフローディングを安定的に継続することは困難である．

このような課題に対しエッジコンピューティングの適用が期待される．エッジコンピューティングは，クラウドと端末の中間に位置するエッジサーバで処理を行うことで低遅延処理や中継トラフィック削減を実現する新しいパラダイムである．特に，モバイル通信キャリアの設備内にエッジサーバを配置するMulti-access Edge Computing（MEC）は，安定かつ低遅延通信でサーバ接続が可能になる技術として着目されている[5]．コネクティッドカーはエッジコンピューティングの重要なユースケースの1つとして様々な研究が進められる[6]．

また，近年はDockerやKubernetes（K8s）をはじめとするコンテナ仮想化技術とオーケストレーションソフトウェアがエッジコンピューティング基盤にも導入されており，車載機アプリケーション基盤としての利用も検討される．たとえば，すでに商用MECサービスとしてリリースされるMobiledgeX Edge Cloud^*1やAWS Wavelength^*2はいずれもマネージド型K8sサービスを提供する．DENSO社は，コネクティッドカーのElectronic Control Unit（ECU）をK8sで制御するプラットフォームを開発する[7]．このような動向を踏まえると，近い将来クラウドに加えてエッジサーバと車載機でもK8sで制御されるコンテナ型アプリケーションが動作するようになると予見される．そして，コンテナの特徴であるアプリケーションの可搬性から，クラウド，エッジサーバ，そして車載機間で動的にコンテナをスケジューリングすることも可能になると考えられる．

しかし，従来のK8sは，クラスタのノードのCPUやメモリを指標としてスケジューリングを行うため，ノードの地理的な場所やノード間の通信遅延はスケジューリングに用いられない．地理的に分散配置されるサーバを用いて端末との低遅延応答を実現するようにコンテナをスケジューリングするには，端末とサーバ間の通信遅延や距離等の情報を用いるスケジューリング手法が新たに必要となる．文献[8]や文献[9]では，エッジサーバの位置情報やエッジサーバ間のRTT値を使用し，指定場所に近いエッジサーバにコンテナを効率よくスケジューリングする手法が提案される．このような手法は，端末とサーバ間の通信遅延が安定する環境においては低遅延応答を実現するスケジューリングが可能となるが，端末とサーバ間の距離や通信遅延が時事刻々と変化する環境においては，低遅延応答を安定して実現するスケジューリングは不可能である．車両のように，高速で移動しモバイル通信回線の品質や各サーバとの距離や通信遅延が大きく変化する環境においては，端末とサーバ間の遅延変動を考慮したスケジューリング手法が新たに必要となる．

このような課題を踏まえ，我々はコンテナ仮想化技術とK8sを用いた車両向けコンテナ型アプリケーションの動的エッジオフローディングフレームワークの開発に取り組んでいる[10]．本フレームワークでは，アプリケーションをクラウド，エッジサーバ，および車載機の中から最適な場所に動的に配置，実行することを可能にする．文献[10]では，エッジサーバが複数存在する環境で，車両移動に伴い近接するエッジサーバが変化する場合において，車載機と複数のエッジサーバ，および車載機とクラウドサーバ間の遅延値を定期的に測定し，平均遅延値が最も小さくなるサーバに動的にオフローディング先を変更する手法が提案される．

しかし，文献[10]の手法は，複数のエッジサーバ間でのオフローディング先変更を目的としており，エッジサーバとクラウド間のオフローディング先変更は考慮されていない．1つのエッジサーバとクラウドが利用可能であり，クラウドへオフローディングしても車載機が要求する低遅延応答品質が確保される環境においても，文献[10]の手法では基本的にエッジサーバが使用される．エッジサーバはクラウドと比較して利用可能なリソースが限られていることから，エッジサーバへのオフローディングは必要最小限に抑えることが望ましい．

そこで本稿では，1つのエッジサーバとクラウドが利用可能な環境において，クラウドを優先してオフローディングを行うフレームワークの設計と実装を新たに提案する．具体的には，クラウドサーバの応答時間が事前に定義された閾値を下回る間はオフローディング先としてクラウドサーバを選定し，閾値を上回る間は一時的にエッジサーバにオフローディング先を切り替える．また，ネットワーク接続断等の理由で遠隔サーバへのオフローディングが不可能な場合は一時的にオフローディング先を車載機内部に切り替える．評価にあたり，車載機からLTE回線を介してクラウドサーバに一定期間アクセスする際の遅延値の時系列データを事前に測定し，測定された遅延値を用いて検証環境にて車載機とクラウドサーバ間の通信遅延を付与する実験を行う．100ミリ秒以内の応答時間を要求する車両アプリケーションを用いてオフローディング実験を行い，エッジサーバを使用しない手法と比較し，応答時間が100ミリ秒を超えるリクエスト数が最大で91%削減されることを示す．

以降の構成は以下のとおりである．続く2章では関連研究を紹介する．3章と4章では，本研究で提案するエッジオフローディングフレームワークの設計と実装を紹介する．5章では評価実験の結果と考察を述べる．最後にまとめと今後の課題について述べる．

2.　関連研究

コネクティッドカー向けにエッジコンピューティングを用いる研究は近年盛んに行われており[6]，エッジオフローディングに関する研究は最も活発な研究分野の1つである[1]．文献[11]では，協調型自動運転の実現に向け，車両とエッジサーバ，および車両とクラウド間のネットワーク品質の測定値に基づき，車両が接続する遠隔運転制御アプリケーションの実行場所をエッジサーバとクラウド間で動的に切り替える手法が提案される．アプリケーションの実行場所をエッジサーバとクラウド間で動的に変更する点は本研究と類似するが，エッジサーバとクラウド双方に予めアプリケーションがインストールされ常時稼働する点が異なる．本研究では，オフローディング先のサーバ上のみコンテナが動作し，他のサーバではコンテナが削除されるため，オフローディング先でないサーバのリソースを節約することが可能である．

コンテナとK8sを使ったエッジコンピューティング実装に関する研究は複数なされている．文献[8]では，エッジサーバが広域に多数分散配置されるエッジコンピューティング基盤において，コンテナとK8sを用いたエッジアプリケーションの効率的なデプロイメントとオーケストレーション手法が提案される．K8sのカスタムスケジューラが用いられ，標準のK8sスケジューラと比較してより高速かつCPU計算量の少ないコンテナのスケジューリングが実現される．文献[9]ではフォグコンピューティング環境向けに，指定場所に近いエッジノードに優先的にコンテナを配置するK8sスケジューラ実装方法が提案される．これらはいずれも，エッジサーバに対してK8sを用いてコンテナをスケジューリングする手法が提案される点で本研究と類似するが，端末はコンテナの実行場所では無いことと，端末とエッジノード間の通信品質の変動は考慮されていないことが本研究とは異なる．

また，文献[12]では，車両のコンテナ型アプリケーションをエッジにオフローディングするフレームワークとアルゴリズムが提案される．しかし，ネットワークの輻輳や遅延の影響と，コンテナのエッジオフローディングを実現するソフトウェア実装が考慮されていない点が本研究とは異なる．

3.　エッジオフローディングフレームワークの設計

本章では，本研究で提案するフレームワークの設計について述べる．フレームワークの概要を図1に表す．フレームワークは，車載機，エッジサーバ，そしてクラウドサーバから構成され，車載機上のクライアントは各サーバ上のアプリケーションにモバイルアクセス回線を介してアクセスする．エッジサーバは，モバイル網の基地局に直接接続しており，車載機クライアントからは安定かつ低遅延で接続可能なサーバを利用する．車載機，エッジサーバ，クラウドサーバはいずれもコンテナ仮想化基盤およびオーケストレーションシステムを持つ．各環境ごとにオフローディング先サーバ上のアプリケーションとの応答時間が測定され，測定値に基づきオフローディング実施判断やオフローディング先切替が実行される．

本フレームワークは3つの特徴を持つ．（a）応答時間の一定期間interval_avgにおける平均値が事前に定義された閾値（timeout）を下回る間は，クラウドサーバが優先的にオフローディング先として選定される．（b）クラウドサーバとの応答時間の平均値がtimeoutを上回り，かつエッジサーバとの応答時間の平均値がtimeoutを下回る場合は，その間に限りエッジサーバがオフローディング先として一時的に選定される．（c）モバイル回線の遅延増加や接続断，オフローディング先サーバの切替動作の影響で応答時間の平均値がtimeoutを下回りオフローディング先サーバが存在しない間は，クライアントアプリケーションはただちに接続先を車載機内で稼働するアプリケーションに切り替える．

以降，フレームワークの構成要素について述べる．

3.1　オフローディングアプリケーション

フレームワークのユーザが用意する，コンテナランタイム上で実行されるオフローディング対象のコンテナ型アプリケーションである．本アプリケーションは，車載機では常時起動しリクエストを待機する一方，エッジサーバとクラウドサーバについては，マルチクラスタスケジューラによって選定されたサーバ上でのみ稼働する．

3.2　クライアント

オフローディングアプリケーションを利用する，車載機に配置されるクライアントである．マルチクラスタスケジューラが指定するオフローディング先サーバ上のアプリケーションに対して一定間隔interval_clientで，リクエストを送信しレスポンスを受け取る処理を継続する．

また，以下に述べる「ローカルフォールバック機能」を持つ．

• ・オフローディング先サーバのProbe Listenerに対してヘルスチェック間隔interval_probeでヘルスチェックを行う．
• ・ヘルスチェックに2回連続失敗した場合は一定時間クライアントからのリクエストを車載機上のオフローディングアプリケーションに対して転送する．
• ・オフローディング先サーバのProbe Listenerとのヘルスチェックに再び成功したら，リクエストをオフローディング先サーバに転送する．

3.3　応答時間測定器

車載機と各サーバ間の応答時間を一定間隔で測定する．具体的には，Probe Agentを車載機に，Probe Listenerを各サーバに配置し，Probe Agentは一定間隔interval_probeで各Probe Listenerに対してヘルスチェック用リクエストを送信し応答時間を測定する．測定結果をマルチクラスタスケジューラに送信する．

3.4　マルチクラスタスケジューラ

クラウドサーバに配置され，エッジサーバとクラウドサーバ間でのオフローディング先変更の判定および実行を行う．一定間隔interval_avgで以下のオフローディング先サーバの判定処理を繰り返す．

• ・Probe Agentから送信される各サーバの応答時間を取得し，一定間隔interval_avgでの平均値を計算する．
• ・クラウドサーバの応答時間の平均値がtimeoutを下回る場合はクラウドサーバをオフローディング先候補サーバとして選定する．
• ・クラウドサーバの応答時間の平均値がtimeoutを上回る場合は，各サーバの応答時間の平均値の最小値を確認し，その値がtimeoutを下回る場合はそのエッジサーバをオフローディング先候補サーバとして選択する．timeoutを上回る場合はオフローディング先候補サーバは存在しないと判断する．
• ・オフローディング先候補サーバに，現在オフローディング中ではないサーバが2回連続で選択された場合，オフローディング先候補サーバをオフローディング先サーバに選定し，そのサーバ上のK8sクラスタにオフローディングアプリケーションをデプロイする．

さらに，車載機のクライアントに対して，アクセス先をオフローディング先サーバに変更するようリクエストを送信する．

4.　実装

本章では，前章で紹介するフレームワークの各構成要素の実装方法を説明する．実装の概要を図2に表す．

4.1　オフローディングアプリケーション

フレームワークのユーザが用意する任意のアプリケーションが実行可能であるが，クライアントからgRPCリクエストを受け，処理を実行後にgRPCでレスポンスを返す仕様を満たす実装である必要がある．

4.2　クライアント

本実装では，クライアントアプリケーションとEnvoy Proxy^*3の2つのコンテナを用いて実装する．クライアントアプリケーションは，オフローディングアプリケーションに対して一定間隔interval_clientでgRPCリクエストを送信しレスポンスを受け取る．リクエストとレスポンスはEnvoy Proxyを経由する構成とし，マルチクラスタスケジューラが指定するオフローディング先サーバへの転送と，ローカルフォールバック機能はEnvoy Proxyが行う．具体的には，EnvoyのAggregate Cluster機能を用いて，すべてのオフローディング先サーバのアプリケーションと車載機上のアプリケーションをclustersに指定する．ただし，車載機上のアプリケーションは最も優先度が低くなるようclustersの末端として登録する．本設定により，オフローディング先サーバが正常稼働しない場合のみ車載機上のアプリケーションにリクエストが転送されるようになる．

4.3　応答時間測定器

3.3に記述する機能はすべてPythonアプリケーションとして実装する．

4.4　マルチクラスタスケジューラ

本実装では，Graphite^*4，スケジューリングアプリケーション，そしてKubeFed^*5の3つのコンテナを用いて実装する．Graphiteはオープンソースのモニタリングツールであり，本実装では送信されるProbe Agentから送信される応答時間の集約と，一定間隔interval_avgごとの応答時間の平均値算出に用いる．スケジューリングアプリケーションは，3.4に記述する動作をPythonアプリケーションとして実装する．KubeFedは，単一のAPIセットを用いて複数のK8sクラスタへの設定を可能とするオープンソースソフトウェアである．本実装では，オフローディング先サーバ上のK8sクラスタへのアプリケーションのデプロイをKubeFedのAPIを用いて行う．

5.　評価と考察

本章では，通信遅延を擬似的に変動させる環境でエッジオフローディングフレームワークを動作させフレームワークの有効性を検証する．具体的には，車載機クライアントとオフローディングアプリケーションとの応答時間の変化と，アプリケーションの実行場所の変化を測定する．また，応答時間が一定時間を超えるリクエストはエラーとし，エラー発生率を測定する．あらかじめ一定時間車載機とクラウド間の通信遅延を測定し，その測定値を用いて検証環境にて車載機とクラウド間，およびエッジサーバとクラウド間の遅延を擬似的に発生させることで動作検証を行う．

車載機とクラウド間の通信遅延については，LTE回線を用いて遅延値を測定する予備実験を行い，その測定値を用いて検証環境で遅延値を擬似的に再現する．

車載機とエッジサーバ間の通信遅延については，基地局に接続されるエッジサーバが利用可能なMECサービスは未だ実現されていないため，現時点では実測することが不可能である．しかし，無線アクセス網（RAN）部分のデータレートに限定すれば99.999%の信頼性を確保した上でLTEでは片道5ミリ秒，5Gでは片道1ミリ秒以内の通信を実現するための3GPP規格が存在するため，端末とエッジサーバ間の通信も低遅延かつ信頼性の高い通信が実現されやすい[13]．また，端末とクラウド間のEnd-to-End通信における遅延要因は，ホップ数と伝送距離が大きくなるほどモバイルコアネットワーク区間とインターネット区間が大部分を占めるとされる[14]．そこで，本研究では，モバイルコアネットワークとインターネットがEnd-to-End通信における遅延要因の大部分を占めており，RAN区間は安定かつ低遅延通信が実現されている環境を仮定し，検証環境における車載機とエッジサーバ間の通信遅延には固定的な通信遅延を付与する．しかし，端末とMEC上のエッジサーバ間の通信遅延はRAN区間の遅延が支配的になると推察されるものの，明確な標準規格が無いため，今後商用MECサービスが提供されても端末とエッジサーバ間の通信遅延はMECサービスを提供する通信キャリアの実装に依存すると推測される．AT&T社がMECによって遅延値が5ミリ秒から20ミリ秒に収められると唱えている[15]ことから，本研究ではその上限値20ミリ秒を，検証環境における車載機とエッジサーバ間の通信遅延値として用いる．

エッジサーバとクラウド間の通信遅延は，車載機とクラウド間の通信遅延と車載機とエッジサーバ間の通信遅延の差分値であるとし，検証環境で遅延値を擬似的に再現する．

5.1　クラウド環境との遅延測定

まず，車載機とクラウド間の通信遅延の変動を測定する．本研究では，au LTE回線のモバイルルータとSoftbank LTE回線のモバイルルータを接続したノートPCを車両に搭載し，ノートPCからAWS EC2（東京リージョン）上に設置するサーバに向けてpingコマンドを5秒間隔で実行する際のRTT値を測定する．静岡県裾野市周辺の幹線道路を約2時間走行し測定を行う．

測定結果を図3および表1に示す．au回線，Softbank回線ともにRTTの中央値は60ミリ秒を下回るが，しばしばRTTが散発的に200ミリ秒以上となることが確認できる．具体的には，au回線ではRTTが100ミリ秒以上となる割合は3.8%，75ミリ秒以上となる割合は6.5%，Softbank回線ではRTTが100ミリ秒以上となる割合は9.7%，75ミリ秒以上となる割合は28.1%となる．

1章で述べたように，遠隔運転アプリケーションでは100ミリ秒以内の応答を継続することが求められるが，通信遅延だけでも10%近くのリクエストが100ミリ秒を超える．従って，遠隔運転のように安定的に100ミリ秒以内の応答が求められるアプリケーションのオフローディング先として，LTE回線を経由したクラウド上サーバだけを利用することは現実的ではないと言える．

5.2　スケジューリング実験

次に，前節の遅延測定結果を用いて，AWS EC2を用いる環境で擬似的に通信遅延を発生させることでフレームワーク動作の評価を行う．

5.2.1　実験構成と実験手法

図4に示すように，車載機，エッジサーバ，およびクラウドサーバを想定する仮想マシンをAWS EC2インスタンスを用いてそれぞれ構築する．EC2インスタンスタイプは，Vehicle1にはt3.large（vCPU数2，メモリ8 GiB）を，Edge1とCloud1にはm6i.4xlarge(vCPU数16，メモリ64 GiB）をそれぞれ割り当てる．なお，Edge1は通信キャリアのMECサービスが提供する仮想マシンを用いることを想定している．NTTドコモが現在提供するMECサービス^*6では，1インスタンスあたり最大でvCPU数31，メモリ126,976 MBの性能を持つ仮想マシンを利用することが可能であることから，m6i.4xlargeインスタンスタイプはMECサービスの仮想マシンとしては一般的な性能を持つといえる．

いずれの仮想マシンもOSはubuntu 18.04.5 serverを用いる．

なお，同時に使用するコンテナ数が多い場合はエッジサーバとクラウドサーバではいずれも複数の仮想マシンを用いてKubernetesクラスタを構成する手法が一般に用いられる．しかし，本研究では同時に使用可能なコンテナ数は評価の対象としていないことから，Edge1とCloud1はいずれも1つの仮想マシンを用いる．

各仮想マシン間の通信には，tcコマンドを用いて以下のとおり遅延を挿入する．車載機とエッジサーバ間の通信遅延は，往復20ミリ秒の固定的な遅延を付加するtcコマンドを実験開始前に一度実行する．車載機とクラウドサーバ間の通信遅延は，図3に示すau，Softbankのそれぞれの回線で5秒間隔で計測された往復遅延の時系列データを用いて，実験開始時刻から5秒ごとに計測された往復遅延時間をtcコマンドを用いて反映する．エッジサーバとクラウドサーバ間の通信遅延は，車載機とクラウドサーバ間の往復遅延値から20ミリ秒をひいた値を同様にtcコマンドを用いて反映する．

実験に用いる共通パラメータ値を表2に示す．au回線構成とSoftbank回線構成それぞれについて，エッジサーバの有無，ローカルフォールバック機能の有無，timeout値の設定（100ミリ秒または75ミリ秒）を変化させ，計8パターンずつ実験を行う．

実験用オフローディングアプリケーションには，クライアントからのリクエストを受信したら以下の処理を行うコンテナを用いる．

• ・ランダムな1024バイトのバイト列を生成する
• ・生成されたバイト列の各々のバイトに対し，ランダム値とのXORを計算し上書きする処理を200回繰り返し実行する
• ・リクエストに対する応答を返す

また，このコンテナを実行する仮想マシンがVehicle1，Edge1，Cloud1のいずれであっても，コンテナを実行するポッドのリソースの要求値と制限値として以下の値を割り当てる．

• ・CPU: 300 m
• ・memory: 128 MiB

なお，この処理は単にCPUへの負荷を与えることを目的とするものであり，特定の用途は想定されていない．

本実験構成にて，クライアントがオフローディングアプリケーションにリクエストを送信してから完了通知を受信するまでの応答時間と各処理の実行場所を測定する．また，timeout以内に応答を受信しないリクエストはエラーとし，リクエストのエラー率をあわせて測定する．

5.3　スケジューリング実験結果

応答時間の時系列変化について，au回線構成における実験結果を図5に，Softbank回線構成における実験結果を図6に示す．また，実験パターンごとのアプリケーション実行場所とリクエストのエラー率，応答時間の平均値および期待値について，au回線構成における実験結果を表3に，Softbank回線構成における実験結果を表4に示す．

パターンau-(g)，au-(h)，sb-(g)，sb-(h)は，クライアントが接続先を切り替えることなくクラウドサーバのアプリケーションにリクエストを送信し続けるパターンであり，本研究におけるベースラインに位置づけられる．表3と表4が示すように，パターンau-(g)ではリクエストのエラー率は10.8%にとどまるものの，パターンau-(h)では51.9%，パターンsb-(g)では37.6%，パターンsb-(h)では73.9%と高いエラー率を示している．遠隔運転のように100ミリ秒以下の低遅延応答が継続して要求されるアプリケーションは，LTE回線を経由してクラウドサーバにアクセスするだけではオフローディング処理を安定的に継続することは難しいことが確認できる．

次に，フォールバック機能だけ有とする実験パターンの結果を確認する．リクエストのエラー率は，パターンau-(e)では5.4%，パターンau-(f)では21.3%，パターンsb-(e)では7.6%，パターンsb-(f)では7.9%となっている．パターンsb-(f)については，ベースライン構成のパターンsb-(h)と比較すると最大で90%近くエラー率が減少している．このことからも，フォールバック機能により，モバイル通信遅延が急増する場合にもエラー発生を抑えて処理を継続できていることが確認できる．一方，パターンau-(f)では依然高いエラー率を示している．これは，フォールバック切替が発生する前のエラー数が多いことに起因する．本提案手法では，クライアントのリクエストが2回連続してタイムアウトするとフォールバック切替が発生する手法を採用している．すなわち，応答時間がtimeoutを上回るほど通信遅延が高まっても，少なくともフォールバック切替前の2回のリクエストはエラーとなる．図3から確認されるように，車両とクラウド環境間の通信遅延は離散的に発生していることから，フォールバック切替の発生頻度が大きくなるため，必然的にフォールバック切替前のエラー数も多くなる．

エラー率を減少させるには，ヘルスチェック間隔interval_probeを，アプリケーションへのリクエスト送信間隔interval_clientよりも小さくすることが有効である．しかしながら，interval_probeを減少させるほどヘルスチェックによるシステム負荷が高まることから，許容できる負荷とエラー率を鑑みてこれら閾値を設定する必要がある．

続いて，エッジサーバだけ有とする実験パターンのエラー率を確認する．パターンau-(c)では4.6%，パターンau-(d)では34.1%，パターンsb-(c)では21.9%，パターンsb-(d)では23.0%であり，ベースライン構成と比較するといずれもエラー率が改善されているものの，フォールバック機能だけ有とするパターンよりもエラー率が高い結果となっている．これは，クラウドサーバからエッジサーバへクライアントの接続先切替が完了するまでに要する時間が，フォールバック機能と比較して大きいためである．本提案手法では，エッジサーバへの切替はProbe AgentとProbe Listenerによるヘルスチェック結果を用いてマルチクラスタスケジューラが各K8sクラスタと車載機のEnvoy Proxyに対してリクエストを行うことで実行される．マルチクラスタスケジューラの実行間隔interval_avgはヘルスチェック間隔interval_probeよりも必然的に大きく設定されることに加え，マルチクラスタスケジューラのオフローディング先サーバ切替は少なくとも2interval_avgの時間を要する．本実験ではinterval_avgを10秒としているため，エッジサーバへの切替には少なくとも20秒を要する．

interval_probeとinterval_avgの閾値をともに小さくすることでエッジサーバへの切替時間を短縮することは可能である．しかし，interval_probeを小さくすると応答時間測定による負荷が，interval_avgを小さくすると不要な切替が多発する可能性がそれぞれ高まるデメリットがあるため，システム全体の規模や負荷をふまえてこれらパラメータを調整する必要がある．

次に，提案手法，すなわちフォールバック機能とエッジサーバの両方を有とする実験パターンでのエラー率を確認する．パターンau-(a)では1.4%，パターンau-(b)では17.4%，パターンsb-(a)では6.7%，パターンsb-(b)では6.9%となる．特にパターンsb-(b)について着目すると，ベースライン構成のパターンsb-(h)，エッジだけ有とするパターンsb-(d)，フォールバック機能だけ有とするパターンsb-(f)と比較し，それぞれ91%，70%，13%ずつエラー率が減少している．

さらに，実行場所がクラウドサーバの割合と実行場所がエッジサーバの割合の和をオフローディング実行割合と定義し，オフローディング実行割合を確認する．パターンsb-(h)のオフローディング実行割合は26.1%，パターンsb-(d)のオフローディング実行割合は31.1%+45.9%=77.0%，パターンsb-(f)のオフローディング実行割合は26.3%であるのに対し，パターンsb-(b)のオフローディング実行割合は29.8%+44.0%=73.8%と高い割合を示す．これらの結果から，本提案手法はエラー率を最も低減しつつ，70%以上の高いオフローディングを実現できることが確認できる．また，sb-(h)の結果が示すように，クラウドだけだと73.9%ものリクエストがエラーとなるほど通信遅延が大きい環境においても，sb-(b)の結果が示すように，提案手法を用いることでエッジサーバの実行割合を44.0%に抑えられていることも確認される．

フォールバック機能だけ有のパターンよりもエラー率が改善している理由は，本実験では車載機とエッジサーバ間の通信遅延は往復20ミリ秒に固定されており，エッジサーバへのオフローディング発生中は応答遅延がtimeoutを超えることが無いことからフォールバック切替が発生せず，オフローディング先切替の発生数が最も少なくなるためである．エッジサーバだけ有とする構成ではオフローディング先切替に時間を要しエラーが多く発生する問題があるが，本構成では，マルチクラスタスケジューラがエッジサーバへの切替を準備する間にもフォールバック機能が補完的に車載機にオフローディングを行うことでエラー率の低減に成功している．

なお，本提案手法においてtimeoutを75ミリ秒とする場合，モバイル回線遅延の中央値はau回線よりSoftbank回線のほうが高いにも関わらず，パターンsb-(b)のエラー率が6.9%，パターンau-(b)のエラー率が17.4%となり，au回線のほうが高いエラー率が発生している．これは，実験時のau回線のほうが通信遅延のばらつきが大きく，頻繁にtimeoutを上回る事象が生じていることに起因する．フォールバック機能だけ有とするパターンと同様に，フォールバック切替が発生するには少なくとも2回のエラーが発生するため，timeoutを上回る通信遅延が頻繁に発生するほど，エラー率は高くなる．エラー率を減少させるにはヘルスチェック間隔を小さくすることが有効である．

以上に述べるように，提案手法を用いることでエラー率を減少させつつエッジの実行割合を低く抑えることに成功している．しかし，au-(a)の結果が示すように，最もエラー率が低くなる場合でもエラー率が1.4%を示している．従って，提案手法は少なくとも数%のエラー率が許容できるアプリケーションのみ適用可能であるといえる．本研究で想定するサーバからの遠隔運転アプリケーションは，往復100ミリ秒以内の応答が期待されるものの，現時点では許容されるエラー率については明確に定義されていない[4]．よって，遠隔運転アプリケーションを提案手法に用いる場合は，アプリケーションをエラー率が一定値以上許容される機能と許容されない機能に分類し，各機能をコンテナ型マイクロサービスに分割し，許容される機能のマイクロサービスのみ，提案手法の動的エッジオフローディング対象とすることが有効である．

6.　おわりに

本研究では，車両向けコンテナ型アプリケーションのオフローディング先を車載機，エッジサーバ，クラウドの中から選定し動的に切り替えるフレームワークを提案した．本フレームワークでは，車載機と各サーバ間の応答時間が測定され，応答時間の平均値に基づきオフローディング先サーバが切り替えられる．クラウドの応答時間の平均値が一定の閾値を下回る場合はクラウドが，閾値を上回る場合はエッジサーバが，そしてネットワークの接続断や切替時の影響でクラウドとエッジサーバどちらもオフローディング先サーバとして使用できない場合には車載機が，オフローディング先サーバとして選定される．Kubernetesとコンテナ仮想化技術を用いて本フレームワークを実装し，複数モバイル通信キャリアのLTE回線の通信遅延を車載機とクラウド間に付与する環境にて本フレームワークを動作させる実験を行った．100ミリ秒以内の応答時間を要求する車両アプリケーションのオフローディングを行い，従来手法と比較してエラー率が最大で91%減少しつつ，オフローディング実行割合が70%以上となることを示した．

今後の課題と展望を以下に述べる．本フレームワークは現状，オフローディング先の切り替えが発生するたびにコンテナが初期化される．そのため，切替前のコンテナが起動後に生成するファイルやメモリ情報を切替先にも移行するには別の仕組みが求められる課題がある．今後は，共有ストレージやサーバ間での個別送信を用いた切替先へのファイルマイグレーション機能や，CRIU^*7を用いるプロセスのメモリ情報のマイグレーション機能をフレームワークに組み込むことを検討している．

また，本稿では車載機からエッジサーバへのアクセスには固定的な遅延値を割り当てる実験をおこなっている．しかし，現実にはエッジサーバへのアクセスにおいても遅延は変動する．特に，今後エッジサーバは多数地理的に分散配置されていくと見込まれるが，通信キャリアによってエッジサーバの展開地域やアクセス方法なども異なる．今後は，複数の通信キャリアが提供するエッジサーバとの通信遅延値を測定し評価を行う予定である．