Google Cloud Platform は、Google Kubernetes Engine (GKE) クラスタ上で実行される Apache Spark ジョブ専用の Dataproc サービスのアルファ リリースをまもなくリリースする予定です。
Apache Sparkは、ETL（抽出、変換、ロード）やデータサイエンスアプリケーションの処理エンジンとして設計されたクラスタコンピューティングフレームワークです。Apache Hadoopと併用されることが多く、Apache Hadoopはリソース管理用のHadoop YARN（Yet Another Resource Negotiator）と分散データストレージ用のHDFSを提供しています。GoogleのDataprocサービスは、Google Cloud Platform上でHadoopとSparkを提供しています。このサービスは、Amazon EMR（Elastic Map Reduce）を提供するAWSや、HDInsightを提供するMicrosoft AzureのマネージドHadoopディストリビューションに似ています。
クラスタ上のコンテナをオーケストレーションするための Kubernetes (K8s) を作成した Google は現在、Dataproc を K8s 上で実行できるように移行中ですが、YARN は引き続きオプションとしてサポートされます。
YARNの何が問題なのでしょうか？「YARNはかなり重いスタックです」と、Google Cloudプロダクトマネージャーのジェームズ・マローン氏はThe Regに語りました。「YARNの置き換えは長い間試みられてきました。YARNは当初ベアメタル上で動作するように設計され、その後VM上でも動作するように適応されましたが、YARNの管理レイヤーの進化はK8sよりも遅く、それがK8sへの顧客の関心を高めています。」
マローン氏は、「YARNには顧客にとっていくつか問題点がある」とし、「現時点でYARNでコンテナを使用することは問題ありませんが、素晴らしいとは言えません。コンテナ化されたワークロード向けに最初から設計されたものではありません」と述べている。
Google のソリューションは、オープンソースの Spark on Kubernetes オペレーターの開発から始まりました。
「これは、エコシステムをKubernetes上で稼働させるための第一歩です。SparkはKubernetes上でどこでも稼働できます。私たちにとってはそれで問題ありません」とマローン氏は述べた。
GoogleはKubernetes上にApache Sparkを実装した
マローン氏によると、K8s上でSparkを実行すると「リソース管理がはるかに容易になる」とのこと。これには自動スケーリングや自動修復といった機能も含まれる。
K8sへの移行にはSparkコードのコンテナ化が必要ですが、Googleはこれを良いことだと考えています。「Sparkコードをコンテナ化すれば、開発、テスト、そして本番環境のライフサイクルが容易になります。また、Sparkの新バージョンがリリースされたとしても、必ずしもディストリビューション全体のアップデートを待つ必要はありません。そのコンポーネントをアップデートするだけで使えるのです」とマローン氏は述べています。
本日のSpark on K8sリリースはアルファ版であり、テストと実験のみを目的としています。「まずはSparkから始めます。最終的にはDataprocの2つのバージョンを提供する予定です。1つはYARNベースで、当面は継続します。Kubernetesフレーバーも提供する予定です。より優れた開発エクスペリエンスを提供するため、多くの新規ビルド開発がK8s上で行われると予想しています」とマローン氏は語りました。
もう一つの示唆は、サードパーティベンダーのコンポーネントの統合が簡素化される可能性があることです。マローン氏は次のように述べています。「YARNエコシステムにベンダー製のカスタマイズされたコンポーネントをインストールすることは可能ですが、エクスペリエンスは必ずしも良好ではありません。Kubernetesなら、はるかに容易になります。」さらに彼は、「多くのオープンソースコンポーネントのビジネスモデルも、この方向に向かっていると考えています。これらの企業にエンドツーエンドのエクスペリエンスを委ねるのではなく、クラスタ管理ツールやデプロイメントツールなどの開発を不要にしたいと考えています。」と述べています。
言い換えれば、マローン氏は、サードパーティのコンポーネントベンダーが Google のようなパブリック クラウド プラットフォームに依存することを予測しており、これは Google にとっては良いことだが、サードパーティにとっては必ずしも良いことではない。
Sparkは、GoogleがK8sオペレーターを開発しているプロジェクトの1つに過ぎません。他には、Apache Flink、Presto、Apache Druidなどがあります。
既存のDataprocプロジェクトをK8s対応に変換したい場合はどうすればいいでしょうか？マローン氏は、それは簡単なはずだと述べています。「プログラミングモデルは変わりません。SparkはSparkです。ワークロードをパッケージ化してコンテナ化する必要があるかもしれませんが、一般的にはそれほど難しくありません。一度そうしてしまえば、コードの移植性は大幅に向上します。」
管理面では、K8sを直接操作するよりも、GoogleのDataproc APIやクラウドコンソールを使用する方が簡単です。「ご希望であればK8sコマンドラインツールの使用もサポートしますが、ほとんどのお客様は当社のクライアントツールをご利用になります。なぜなら、クライアントツールは完全なサポートが提供され、多くのエラーチェック機能を備えており、お客様が望むほとんどの機能をサポートできるように設計されているからです」とマローン氏は述べています。
初期リリースの制限事項として、「Dataproc は既存の K8s クラスタ上に Spark リソースを作成します」とマローン氏は語りました。「しかし、Dataproc は現在、クラスタリソースを独自に作成および破棄できるため、K8s クラスタの作成と破棄をサポートするのは時間の問題です。」
ハイブリッドクラウドやマルチクラウドのシナリオでは、GoogleのAnthosプロジェクトは、コードの実行場所を柔軟に選択できるようにします。「Google Cloud上で実行している場合でも、オンプレミスのAnthosで実行している場合でも、あるいは別のクラウドのAnthosで実行している場合でも、Dataprocが単一のコントロールプレーンとなることが私たちのビジョンです」とマローン氏は述べています。
K8sの勢いは、こうした移行を不可避なものにしています。Google Cloud Platformは市場シェアでAWSやMicrosoft Azureに後れを取っていますが、K8sの発明者としての立場を活かして、そのさらなる活用を推進していくのは当然のことです。®
