Kubernetes以降のRancherの向かう先は？ RancherのVPが語るその方向性
オープンソースのコンテナ管理ソフトウェアであるRancherを開発するRancher Labsが、都内で事例セミナーとMeetupを開催した。本社から来日したセールス担当のVPであるShannon Williams氏が、Rancherの事例紹介や現在、開発が進んでいる2.0の概要を紹介した。
VP of SalesのShannon Williams氏
まずWilliams氏は「コンテナを実際に運用することは複雑なタスクである」と語り、アプリケーションカタログやオーケストレーション、モニタリング、セキュリティなど多様な要素を管理する必要があることを強調した。
コンテナサービスは様々な要素から構成される
そして現在のエンタープライズITにおいては、オンプレミスとパブリッククラウドの双方を管理するツールが必要であるとして、その部分にRancherの役割があると解説した。ここではVMwareやOpenStackなどの企業が持つデータセンターでの利用から、AWS、Azure、GCPの3大クラウドベンダーのプラットフォームまでをカバーできるという部分がRancherの訴求ポイントだ。
マルチクラウドをサポートするRancher
事例として紹介されたDisneyでは、VMware、AWS、GCPのそれぞれのインフラストラクチャーを使って複数のチームがコンテナ上のアプリケーションを実装していると説明し、ここでもRancherがインフラストラクチャーを抽象化するためのレイヤーとして利用されていることを解説した。
DisneyでのRancherの事例のポイントはマルチクラウド
またSonyのPlayStation Networkでも、Rancherが利用されていることが紹介された。ここではPlayStationのゲームデベロッパー向けのサービスを、DockerとRancherで構築しているという。特にRancherのApp Catalogが、そのソリューションの大きな部分を占めている事を紹介した。
Sony PlayStation Networkでの事例
ゲームデベロッパー向けのツールなどを公開することによって、生産性の向上を果たしていると言う。
RancherのApp Catalogを公開している
そして再度、Kubernetesが様々なインフラストラクチャーの上でRancherを通して利用できることを強調する。Rancher独自のオーケストレーション機能であるCattleは、今回のセミナーでは言及されることはなく、すでにKubernetesがオーケストレーションの中心となっていることが、あらためて確認された。
KubernetesがRancherにおけるオーケストレーションの標準となった
最後にRancher 2.0の紹介を行なって、Williams氏のプレゼンテーションは終了した。
Rancher 2.0の紹介
セミナーの後に開催されたMeetupでは、Rancher 2.0に関する質問を受けたWilliams氏が、より詳細な解説を行なった。ポイントとしてはやはり、Cattleと言うRancher自前のオーケストレーションツールを諦め、Kubernetesに移行するという点だろう。他にも、App CatalogはKubernetesのApp-SIGで開発が進むHelmに移行し、データストアもMySQLからetcdに移行するという。
Kubernetesがコンテナオーケストレーションのデ・ファクト・スタンダードとなったことを受けて、2.0でその流れに乗ったというようにも見えなくはない。また参加者からは、MySQLではなくetcdに移行することでこれまでの知見が使えなくなることと、etcdに対する不安が質問という形式でWilliams氏に投げかけられた。それに対する回答は、Kubernetesが利用するデータストアであるetcdに対しては「これだけ使われているKubernetesと同じデータストアを使うことに対して不安は無用である」というもので、ここでもRancher LabsとしてのKubernetesに対する評価を垣間見ることができた。
その後に登壇したのは、IIJでRancherを用いた検証を行っている寺田充毅氏だ。IIJでは、自社で開発するオブジェクトストレージの開発・検証環境の構築に、DockerとRancherを利用しているそうだ。
IIJの寺田氏
寺田氏が使用したスライドは、以下を参照されたい。
Rancherの現行バージョンを利用してシステムを構築し、すでに2.0に対しても検証を進めているというIIJであったが、HelmベースのApp Catalogに移行する際には、それなりに痛みを伴うのではないだろうか。メタデータに関しては、Kubernetes 1.8から導入されたCustom Resource Definitionを利用することも検討したと回答したWilliams氏であったが、今のところは別の方法を利用する方向のようだ。
今回のセミナーとMeetupによるQ＆Aでは、Rancher Labsが目指すKubernetes以降のコンテナサービスの向かう先を垣間見ることができた。特に「サービスメッシュが次に向かう先である」と強調した部分は、HelmやIstioなどのマイクロサービスが当たり前の世界でRancherがどこに向かおうとしているのか、Rancherの存在意義は何か？ を問いかけているようであった。
