コンテナ登場の背景と、難解なKubernetesをシンプルな操作で扱えるRancherの可能性

――NHNテコラスでは、データセンター事業から、今回新しくリリースしたCloudGarageのようなクラウド事業まで、ITインフラを幅広く取り扱っています。角さんはユーザーのシステムを色々と見ている立場として、昨今のインフラの変化をどのようにとらえていますか？

角 俊和氏（以下、角）　クラウド以前は、データセンターの設備を直接貸し出すサービスしかありませんでした。その後、ラック単位、サーバ単位でのサービス提供が可能になり、クラウドの登場により仮想OSがサービスの対象になっています。

　約20年間で、ITインフラのサービスはどんどん抽象化しています。仮想OSからさらに進み、コンテナという、より抽象化された概念が登場したのもその流れの一つです。インフラを利用するユーザーから見ると、自らが把握・管理するレイヤーが減り、移行性が高く、複製や再生成が容易な、サイズの小さなアプリケーションの開発・実行、すなわちマイクロサービスアーキテクチャに適した環境へと変化していると考えています。

――Dockerを中心にコンテナ関連の技術が進化していますね。Rancherはその中でどのような役割を担うのでしょうか？

新藤洋介氏（以下、新藤）　コンテナは、DevOpsやアジャイル開発、マイクロサービスなどと親和性が高い技術です。仮想サーバ上で複数のアプリの実行環境を確保するために利用しますが、コンテナを小さく作り、1つのコンテナ上で機能を細かく分割したマイクロサービスを1つ稼働して、複数のコンテナをまとめてオーケストレーションするという使い方が増えています。その結果、コンテナ管理が複雑になり、どのツールがよいか分からなくなったという問題が出てきました。Rancherは、複雑性を緩和し、オープン性を担保して、開発者にわかりやすく使いやすいソリューションを提供することを目的としています。

　Rancher 1.0をリリースしたのは2016年4月です。当時、Kubernetes、Docker Swarm、Apache Mesosなど非常に多くのオーケストレータがあり、玉石混交の状況でした。1.0は、インフラとしてオンプレミスでもどのクラウドでも利用できるマルチクラウドを実現し、さらにその上でKubernetesをはじめ任意のオーケストレータを利用できます。Rancherにより抽象化し、複数のクラウドおよびツールを横断的に利用可能であることが大きな特長と言えます。RancherはDisneyでも導入されていて、GCP、AWS、オンプレミスなど複数のインフラ上で異なるオーケストレータを使用していることが、Rancher採用の決め手となりました。

――2017年9月末リリースのRancher 2.0では一転してKubernetes対応となりましたが、その理由は？

新藤　Kubernetesは当初Googleによって開発され、のちにオープンソース化されました。Rancher Labsは、Kubernetesを管理するCNCF（Cloud Native Computing Foundation）の主要メンバーとして初期から関わっています。オーケストレータの勢力図は1年で大きく変わり、現在はKubernetesがデファクトスタンダードになったと考えています^[1]。しかし、Kubernetesは意外と複雑で、ラーニングコストがかかる。そこで、インフラを問わずにシンプルな操作で利用できるように、Kubernetesに全面的に対応したのが2.0です。