最新レポート


Kubernetesは結局どこまで行くのか?
エンタープライズクラウドミートアップ

〜Google Cloud、さくらインターネット、日本マイクロソフト株式会社、レッドハット〜

「レッドハットの主催で、レッドハットのオフィスで行われていますが、実は、あまりRed Hat OpenShift Container Platformのことは語りたくないという変なイベントです」と、レッドハット クラウド・パートナー営業部部長 佐藤。Kubernetes中心に各登壇者のセッションが続いた「レッドハット on Cloud Day」の最後に行われたパネルディスカッションの冒頭で、改めてテーマが示された。コンテナはどうなってしまうのか、Kubernetesはどこまで行くのか。Google Cloud、さくらインターネット、日本マイクロソフト、レッドハットというそれぞれの所属を超え、個人的な立場で意見を交換することで描き出されたのは、どんな未来だろうか。

福田氏

Google Cloud
Customer Engineer
福田 潔

前佛氏

さくらインターネット株式会社
技術本部ミドルウェアグループ
前佛 雅人

 

寺田氏

日本マイクロソフト
シニア Java エバンジェリスト
寺田 佳央

佐藤

レッドハット株式会社
クラウド・パートナー営業部部長
佐藤 郁朗

 

須江

レッドハット株式会社
須江 信洋

 

使いたいという想いがエンジニアの意識を変える

最初にマイクを握ったレッドハットの須江は、「Kubernetesがある意味スタンダードになり、その上下のレイヤーで、競争が進むと思っています」と、Kubernetesを中心に、ソフトウェアベンダー、クラウドプロバイダーが注力するレイヤーと、開発者主導で進むレイヤーの両方での競争が、さらに活性化すると予測する。Google Cloud 福田氏は、須江の意見に頷きながら、昨年の北米のKubeConでケルシー・ハイタワーが提示した「kubectlというコマンドは、新しい時代のSSHだ。(kubectl is the new ssh…)」というステートメントを引用しながら、「KubernetesのベースになったBorgというコンテナオーケストレーションツールを使ってきたGoogle™のソフトウェアエンジニアは、もともとコンテナのレイヤーまでしか意識していません」と述べた上で、Kubernetes の普及により、エンジニアの意識変化が進むことに期待を寄せた。

逆に、コンテナ化は選択肢のひとつにとどめておくべきという立場を示したのが、さくらインターネットの前佛氏だ。Dockerが登場した当時から、無理に移行を進めるべきではないと考えていたという同氏は、ただし、「必要があれば採用できるようになったことはよいことでしょう」と評価する。同様の立場に立つのが、日本マイクロソフト寺田氏だ。コンテナはマイクロサービスの実行環境として最適だという考えを提示しつつ、そうしたニーズがないなら、違う選択肢を積極的に考えてもいいという立場だ。Javaエンジニアである寺田氏の感覚では、今のKubernetesは、発表当時のJDK1.0を取り巻く状況に近いという。「将来、Kubernetesはどんどん良くなってくるはずだが、現在はまだ足りないところもあり、それを自分たちが補わないといけない状況です。それでも使いたい場合には、覚悟を持って利用していく必要があると思います」。

そんななか、小さく始められるのがメリットになるという視点を提示したのが福田氏だ。論点がずれるかもしれないがと前置したうえで、「確かに、既存のシステム全部をKubernetesに置き換えるのは大変だと思います。ただ、システムの中の一つのAPIを切り出すなどして、小さく始めて改善していくというのもひとつの方法かなと思います」。と、最新情報のキャッチアップが難しく、誤情報も少なくないからこそ、小さく始められるのがメリットになるという。

正しい情報のキャッチアップに求められるのは英語力!?

「先日、de:code 2018というMicrosoftのイベントで同じような話をしたのですが、今巷に溢れているKubernetesの情報は、入門レベルの情報が多く、プロダクションレベルで活用していこうとするなら、自分自身で調べて、試して、やっていくしかないと思います」という寺田氏が、来場者に呼びかけたのは「皆さん英語も頑張っていきましょう」の一言だ。「Kubernetes関連の情報を探そうとするとStack Overflowか、Github Issueのどちらかにアクセスすることになりますが、どちらも英語で書かれている。私の経験ですが、調べたいことがあってドキュメントを最初から読んでいる間に、英語がネイティブのエンジニアはすぐに答えを見つけてしまう。解析力の問題だけではなくて、新しい技術のキャッチアップ力の差にも繋がっていると思うのです」と英語力の必要性を強調した。前佛氏は、「基本的に、日本語の情報はすべて古い、英語のドキュメントそのものにも古いものが多いと思っていただいていいと思います。自分で手を動かして、確信を持ったものしか信じてはいけないと思った方が正解でしょう」。確かに、Kubernetesに関しては、誤情報や誤解も少なくない。本来あるべき姿で、Kubernetesを使う。そのためのヒントは、どこに求めればいいのだろう。

頻繁なバージョンアップにどう対応するか

当日は、一般参加者からの質疑応答の機会も設けられた。まず参加者から発せられたのは、半年に2世代という頻繁なバージョンアップへの対応をどうするかという点だ。これに対して福田氏は、「基本は、余計な作業を自動化していくということだと思います」と、自動化が一つの答えになるという。須江は、オンプレミスで運用している場合に古いバージョンを使い続けたがる傾向が強いのは、バージョンアップをするとアプリが動かなくなってしまうという懸念があるからだとしたうえで、「OpenShiftは製品としては古いバージョンでもサポートはします。とはいえ、古いものをメンテナンスし続けるというのは厳しい面もあります」とし、自動化が答えになることに同意した。

対して、寺田氏は、バージョンアップにおける自身の苦い経験から、バージョンアップにおける障害を避けるため、新しい環境のクラスターをもう1セットつくることを勧める。「古いバージョンと新しいバージョンを用意し、新しいところに徐々にリクエストを振り分ける方が安全かと思います」。

OpenShiftか、GKE(Google Kubernetes Engine)、
AKS(Azure Kubernetes Service)か選択の基準はどこに?

いくつかの質問の最後に提示されたのは、「実際にプロダクションで使うことになった場合に、選択肢としてOpenShiftを使って行くのか、もしくはGKEなり、AKSを使っていくのか、その判断基準についてだった。

質問を受けたレッドハット佐藤が「会社の人間としてではなくて、個人的な見解として述べてみましょうか」と、それぞれ立場が異なるパネリストを見回すなか、福田氏は、インターフェースと実装を切り分ける必要があるとして、「インターフェースはベンダー間で違いはありません。ポイントはKubernetesのエンジンとして、特に実装面での違いがあるかどうかを意識することでしょう。あとは、導入時にデータはあまり動かしたくないと思いますので、そもそもどんなプラットフォームで稼働させたいのかが基準になるかもしれません」という。寺田氏は、「基本的にAKSは環境構築から運用までを自分たちでおこないます。それにより構築・運用費用を下げるという考え方もありますし、レッドハットのサポートを受けることで、自分たちのキャッチアップにかかる教育コストを減らし安心を得たいという場合には、OpenShiftを選ぶという選択肢もあると思います」と、費用対効果が選択のポイントになると指摘する。

最後に、補足を加えたのは、須江だ。「例えばJBoss EAPで作ったアプリケーションをコンテナ化して動かしたい、いうような話になると、サポートできるのはレッドハットだけです。コンテナまで含めてサポートが必要ということであればOpenShiftを選んでいただくしかない。メリットがあるのであれば使っていただきたいというのが答えになるかと思います」。

冒頭に宣言されたように、特別な製品、サービスを訴求するという要素を排除して展開された「レッドハット on Cloud Day」クラウドの未来、Kubernetesの行く先を探る機会となっただろうか。

イメージ

■ショートセッション概要

当日は、本パネルディスカッションに先立って、パネリスト4名を講師にショートセッションが開催されている。最初に登場したのは、さくらインターネット 前佛氏だ。物理サーバーの時代から、クラウド・ネイティブに至る歴史を紹介したうえで、クラウド・ネイティブは、唐突に言われ始めたものではなく、これまでの流れの延長線上にあるという視点から、コンテナやマイクロサービスのようなクラウド・ネイティブ技術が導く世界を俯瞰する。中立的立場で業界のまとめる役割を担うLinux Foundation配下のCNCF、その取り組みを案内するものとなった。

クラウド・ネイティブに至る流れ

続いて登壇した Google Cloud 福田氏は、Google Cloud Platform™が実現するMulti Cluster Ingressと、それを支えるGoogle Cloud Load Balancingについて紹介。クラウドという言葉が登場する以前から、利用者がブラウザベースで、インターネッ上のリソースにアクセスするモデルに取り組んでいたGoogle™が目指す、ハイブリッド・クラウドのあるべき姿を提示、合わせてクラスターの作成からアプリケーションのデプロイ、Multi Cluster Ingress作成のデモを行った。

GKEクラスタ基本構成

マスターノードとよばれるコントロールプレーンのなかで実際のアプリケーションワークロードが動く。

レッドハット須江が、「Jakarta EEエンジニア視点でのKubernetesのCNIとCSI」をテーマに行ったセッションでは、自身のキャリアと経験から導いた「競争のないところに発展はない」という考えに基づいて、ひとつの解として、インターフェースと インプリメンテーションを分離してインターフェースを統一することで、ユーザーにとっての利便性を保ちつつ、適切な市場競争が生まれるエコシステムが実現できるのではないかという。Kubernetes周辺では、ネットワークやストレージなどを統合するためのCNIとCSIが標準化を担保するのではないかとの考えを提示した。

最後に登壇した日本マイクロソフト寺田氏は、マイクロソフトにおけるハイブリッド・クラウドのシナリオを紹介したのち、サービスメッシュ技術であるIstioについて紹介した。Kubernetes上で動く Istioが、マイクロサービス間の通信を統一的な仕組みで制御することで、セキュリティの確保、流量制御、フェイルオーバーなどを容易にできることを紹介。本番稼働中のアプリケーションで、フロントエンドからの呼び出しの100%を特定バージョンのサービスに転送するルールや、新たなバージョンを開発した場合、開発者のみ新バージョンへのアクセスを許可するルール、さらに、80%と20%で転送を振り分けるカナリア・リリースを容易に実現する手法などを紹介した。

Istioの呼び出しフロー

Istioでは、サービスを直接呼び出しではなく、プロキシ経由で呼び出している


関連リンク

Kubernetesとは
Istio