クラウドネイティブで実現する、シミュレーションと実機テストのボーダーレス開発：仮想環境を使ったクラウド時代の組み込み開発のススメ（4）（3/4 ページ）

IoT／クラウドロボティクス時代のシステム開発を加速化する仮想環境の活用について解説する本連載。第4回は、前回紹介した「クラウドネイティブ」の考え方に基づき、製品開発の課題になっている、シミュレーション環境と実機テストの間にあるギャップを埋める方法を紹介する。

[福田竜也（株式会社インテック），MONOist]

インフラレイヤーのギャップを埋める（＝相似性を高める）

ギャップ要素を整理する

　これら前提条件を踏まえた上で、2つの環境を比較し、インフラレイヤーのどういった要素がギャップとなっているかを洗い出しました。システムを構成する各アプリケーションを異なるコンピュータで実行しようとすると、以下のようなギャップが発生します。

• コンピュータ資源
  • CPUアーキテクチャの差（armhf、arm64、amd64など）
  • メインメモリの搭載量の差
• ネットワーク資源
  • Hop数の差（送信元と送信先の間で通過しなければならない中間デバイスの数）
  • パケットロスに伴う、ネットワーク障害や遅延／揺らぎが発生する可能性

　例えば、図4の「ROS Robot」上で実行していたアプリケーション（Pod）を、シミュレーション環境に合わせてパブリッククラウド環境で動かそうとすると、Wi-Fiや4Gなど不安定なネットワークの有無、CPUアーキテクチャの違い、自律移動などの他アプリケーション（Pod）との通信に際してのHop数の違いなどが発生します。こうなると、結果が返ってくるまでの時間やタイミングが変化し、検証結果に間接的影響を及ぼす可能性もあります。（もちろん、この程度の外乱を想定し、ロバスト性のあるアプリケーションを開発することが最も重要です）。

クラウドネイティブな解決方法

　よって、インフラレイヤーのギャップを解消することも、ある程度は意識しなければなりません。しかし、アプリケーションエンジニアは、自分のアプリケーションに対し、シミュレーション環境／現実の作業環境、それぞれに特化した別々の実装をするのを避けたいと考えるでしょう。インフラレイヤーのギャップ解消のために「実装上のギャップ」という新しいギャップを作っては本末転倒です。

　そこで活躍するのが、クラウドネイティブの考え方／支える技術です。インフラレイヤーのギャップ解消という文脈では、「システム構成要素を細かく分解し、環境間の差分だけをピンポイントに埋めること」を助けます。合わせて、前提条件としている、大規模（数十〜数百台のコンピュータ／ROSロボット／IoTデバイスが互いにつながる）、好みで配置できる、興味に応じて試験できる、同じ挙動が再現できるといった要件の実現に寄与します。

アプローチ（要素技術）

　アプローチの解説に進む前に、前回記事で解説した「クラウドネイティブの定義」について、もう一度振り返っていただけるとより理解が深まるかと思います（図5）。

図5　クラウドネイティブの定義（前回に引き続き再掲）（クリックで拡大） 出典：「Kubernetesのロゴ」「モノリシックからマイクロサービスの図」はCNCFより引用。その他の図の組み立ては、「クラウドネイティブの定義」を基にした筆者解釈による

　クラウドネイティブな技術アプローチを中心軸に、ギャップ要素への対処方法を以下の通り整理しました。

• コンテナ／イミュータブルインフラ
  • CPUアーキテクチャの差への対処
    • athrill（箱庭のアセット、CPU命令セットシミュレーター）を、対象のコンテナと同一Pod内で宣言し、協調して稼働させる（サイドカー）
    • Docker Buildxなどでマルチアーキテクチャ対応のコンテナをビルドし、レジストリ（コンテナイメージの保存先）に保存。各Nodeでは、自身のCPUアーキテクチャに応じてコンテナを自動選択してダウンロードするため、差分を意識せずに済む
• サービスメッシュ
  • ネットワーク障害や遅延／揺らぎの差への対処
    • TCPは加重ルーティング機能によって、一部通信をダミーに飛ばすことができる（Wi-Fiや4Gなど不安定なネットワークを想定した、意図的なネットワーク障害を再現）
    • また、HTTPであればFault injection機能で遅延などのより高度なエラー注入が可能
• 宣言型API
  • メインメモリの搭載量への対処
    • Podをデプロイする際のManifestにて、各コンテナに対するメモリ使用量を制限することができる（超えると強制終了させることも可）
    • その他、CPUリソース使用量や、拡張リソース（GPUなど）に対しても同様の制限を課すことができる
• これら対処は、全て“宣言型API”でコントロール可能である

アプローチ（設計思想）

　このような考え方／技術による裏付けをもって、マイクロサービスという設計思想が意味を成します。また、「それぞれに特化した別々の実装をするのを避けたい」という考えは、マイクロサービス的設計思想に、とても重要なモチベーションです。重複実装を減らすといった、生産性への影響もさることながら、エンジニアに関心の分離^※3）を強く意識させることにつながります。

※3）関心の分離：ソフトウェア工学において、何をしたいのか（関心）ごとに分離された構成要素でプログラムを構築すること

　今回の例では、CPUアーキテクチャの差への対処で登場した「サイドカー」という考え方のように、「アプリケーションそのものは変更せず、目的に応じて別コンテナを作る」というアプローチがそれに当たります。結果的に、各アプリケーションはテストのしやすさが改善され、個別のみならず全体に対しての品質向上にも貢献します。

　冒頭に挙げた通り、「システム構成要素を細かく分解し、環境間の差分だけをピンポイントに埋めること」の実現によって、残りの大部分から見たインフラレイヤーは、環境間の差分を意識する必要がない、資源が「共用（Share）されている状態」を作り出します。このおかげで、アプリケーション開発者は、ピンポイントかつ極小な差分を埋めるだけで、2つの環境を跨ぐ開発に従来と比べて安心して臨むことができるのです。