ApacheCon North AmericaでChristopher Crosbie氏が、"Yet Another Resource Negotiator for Big Data? How Google Cloud is Enhancing Data Lake Processing with Kubernetes"と題した基調講演を行った。講演の中で氏が強調したのは、Kubernetesクラスタ内でApacheソフトウェアを動作させるためのコントロールプレーンを提供する、オープンソースのKubernetesオペレータを開発することによって、Apacheのビッグデータソフトウェアを"クラウドネイティブ"にするという、Googleの取り組みについてだった。
GoogleのOpen Data and AnalyticsプロダクトマネージャであるCrosbie氏の講演は、Hadoopに影響を与えたmap-reduce論文に始まる、Googleのオープンソースビッグデータコミュニティへのコントリビューションの歴史を振り返ることから始まり、現在のGoogle Cloud Platform(GCP)で提供されている、さまざまなApacheアプリケーションのマネージドバージョンについて言及した。Crosbie氏が担当するGCP Cloud Dataprocサービスでは、Apache SparkとHadoopクラスタのマネージドバージョンを提供している。講演では、これらクラスタの管理に伴う問題点と、クラスタ管理をKubernetesに切り替えることによって、その問題の多くを解決できることが紹介された。Dataprocチームは自分たちのプロダクトにKubernetesサポートを組み込んでいるが、その開発成果の多くがオープンソース化されているため、ユーザが自身のKubernetesクラスタでSparkとHadoopを実行することも可能である。
SparkとHadoopは、クラスタ化されたマシン上で動作する分散システムであるため、さまざまなクラスタノードの正常性の確認、障害の発生したノードの再起動または置き換え、ジョブのスケジューリングといった、さまざまな管理タスクを処理するクラスタ管理システムが必要になる。いずれのシステムも、YARNやMesosなど、複数のクラスターマネージャをサポートする。Dataprocチームのこれまでの開発は、その多くがYARNのコントロールプレーンの構築とGCP APIへの統合を中心としたものだ。
一方で、YARNの使用にはいくつかの問題点がある、とCrosbie氏は言う。YARNの他のコンポーネントへの依存関係が、結果としてオープンソースソフトウェアスタック構成となり、依存関係の管理やバージョン管理、およびジョブの調整が困難になるのだ。運用上のオーバヘッドの削減を目的に、すべてのジョブを単一のクラスタで運用している組織は珍しくはない。このような構成では、ジョブがリソースを奪い合うことになり、クラスタが過剰にプロビジョニングされる可能性がある。
クラスタマネージャとしてKubernetesを使用することで、これらの問題を解決できる、とCrosbie氏は主張する。現在では多くの組織が、コンテナ化した独自アプリケーションのクラスタマネージャとしてKubernetesを運用しているが、Sparkの管理にKubernetesを使用することによって、YARNやMesosなどの第2のリソース管理インターフェイスが不要になり、オペレーションを簡略化することができる。アプリケーションはコンテナ化されていて、依存関係やバージョン管理が各コンテナに"ビルトイン"されているため、運用はさらに分離される。セキュリティパッチとO/SアップデートはKubernetesクラスタ自体より下位のレベルで処理され、SparkやHadoopコンテナの変更を必要としないので、システム全体のレジリエンスも向上する。
SparkのホストにKubernetesを使用する上で鍵となるのは、カスタムリソース定義とオペレータを使用したKubernetes APIの拡張である。これによってKubernetesコントロールプレーンAPIが、ホストされているアプリの"ことばを話す"ことができるようになる。Crosbie氏のチームでは、Spark用とApache Flink用のオペレータをオープンソースとして開発している。ユーザは、Googleのクラウド上でホスト型ソリューションを実行することも、helm chartをダウンロードして独自のKubernetesクラスタ上で実行することも可能だ。
YARNからKubernetesに切り替えることの長所と短所をリストアップして、Crosbie氏は自身の講演を締め括った。短所の多くは、運用上の"惰性"によるものだ。例えば、既存のジョブがYARNで実行するように設定されている場合、Kubernetesに移行するためには、改めて設定する必要がある。同じような例として、YARNのログファイルの規則に習熟していて、それを対象とした監査や監視機能が構築されている場合も考えられる。Crosbie氏は、複数のレイヤを持つKubernetesのセキュリティを、"ロシア人形"に例える。
Kerberosは[Kubernetes] RBACコントロール内にあり、それがVMサービスアカウント内にあります。さらにそれがクラウドIAM内にあり、多くの場合、外部と同期されたCloud Identityによって支えられているのです。
Spark用Kubernetesオペレータは、IBMおよびMicrosoftと共同で開発されたものだ。昨年アルファ版としてオープンソース化され、今年になってベータ版としてリリースされた。Flinkのオペレータは先週オープンソース化されたが、公式リリースのタグはまだ付けられていない