　それではここから、「2.2 インフラレイヤーの相似性」を高めるための筆者らのアプローチを紹介します。実現の鍵は、前回記事で重点的に解説した「クラウドネイティブ」の考え方とこれを支える技術です。さまざまな制約由来の課題を、「徹底した抽象化」という考え方と、それを裏付ける「高度な仮想化」という技術で克服します。クラウドネイティブの考え方／支える技術を実践する方法として、コンテナ・オーケストレーターのデファクトスタンダードである「Kubernetes」の利用を前提に進めます^※2）（図3）。

※2）もちろん、Kubernetesだけでなく実現方法には多様な手段があります。

　Kubernetesは、宣言的な構成管理と自動化を促進し、コンテナ化されたワークロードやサービスを管理するための、ポータブルで拡張性のあるオープンソースのプラットフォームです。詳細は、Kubernetes公式解説「What is Kubernetes」をご参照ください。

図3　「Kubernetes」によって抽象化／仮想化されたインフラレイヤーのスタック（クリックで拡大）出典：「Kubernetesのロゴ」はCNCF、「Dockerのロゴ」はDocker, Inc.のメディアキットから引用

システムの要件

　検討を進める上で、“想定要件”に対して、シミュレーション環境および現実の作業環境のインフラレイヤーは、どういった構成を取り得るかという前提をそろえておきたいと思います。

　本記事における想定要件は次の通りです。

“つながる”デバイスが数多く持ち寄られる
- 「箱の中に、さまざまなモノをみんなの好みで配置して、いろいろ試せる！」という、シミュレーション環境「箱庭」のコンセプト
- ROSロボットも含む（画像処理や自律移動などの計算負荷が高い制御ループを伴う）
シミュレーション環境は、GPUを搭載するプライベートクラウド／パブリッククラウド上のCI／CD（継続的インティグレーション／継続的デリバリー）用サーバで実行される
- 「箱庭」を想定

　これらの要件を考慮し、以下のようなインフラレイヤー構成を想定し、Kubernetesクラスタを、プライベートクラウドとパブリッククラウドを組み合わせたハイブリッドクラウド上に構築します（図4）。

図4　本記事で想定するインフラレイヤーの構成（簡略図）（クリックで拡大）

　このインフラレイヤーは「性能（低遅延、高セキュリティ）」と「経済性（常時起動が必要なIaaSを減らす）」の両立を目指した構成です。現実の作業環境（本番、テスト、開発）／プライベートクラウド／パブリッククラウドはVPN（Virtual Private Network、仮想専用線）で接続されており、Kubernetesの各Node（Workerマシンのこと）は相互にネットワーク接続することができます（Node Network）。

　また、Kubernetesでは、1つ以上のコンテナの集合である「Pod」を、ワークロード（≒アプリケーション）の最小かつ最も基本的な実行単位として扱います。実行するためにはManifestに、ワークロードの“望ましい状態”をYAML／JSON形式で記述します。コントロールプレーン（図4のKubernetes Master）は、Manifestで定義された“望ましい状態”を維持するために、クラスタ全体を制御します。また、Pod同士は、Node Network上に「ソフトウェア的に構成される論理ネットワーク（Cluster Network）」を使って通信します。これは、ノード上のPodが、NATなしで全てのノード上の、全てのPodと通信できることを保証するためです。

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

前のページへ 1|2|3|4 次のページへ