Cloud Dataproc on Kubernetes の始め方
Google Cloud Japan Team
※この投稿は米国時間 2019 年 9 月 11 日に Google Cloud blog に投稿されたものの抄訳です。
Cloud Dataproc は Google Cloud のフルマネージド Apache Hadoop および Spark サービスです。そのミッションは、クラウド規模のデータセットに対する既存ツール、アルゴリズム、プログラミング言語の適用を、開発者やデータ サイエンティストにとって常にシンプルかつ直感的なものにすることです。Cloud Dataprocの高い柔軟性により、これまで活用してきたスキルやテクニックを、あらゆる規模のデータ探索で引き続き使用できます。私たち Google Cloud のもとには、データの処理と分析に Cloud Dataproc を活用しているとの声が世界中の企業や SaaS 企業から寄せられています。
Cloud Dataproc では、 今回新たに、 Google Kubernetes Engine (GKE) 上で Spark ジョブを実行できるようになりました。（アルファ リリース、詳細はこちら）。これにより、機械学習（ML）とビッグデータ分析への最新アプローチ（Apache SparkとGoogle Cloud）を、開発者やデータ サイエンティストから頼りにされている Kubernetes や GKE のクラウド管理機能と一緒に活用できるようになったわけです。これらのツールを併用することで、柔軟性や自動修復ジョブ、統一的なインフラストラクチャが得られ、インフラストラクチャのメンテナンスではなくワークロード自体に集中できます。詳細やアルファ プログラムへの参加については、こちらからメールでお問い合わせください。
それでは、現在の Cloud Dataproc と新しい GKE サポート（アルファ版）の機能を見ていきましょう。
現在の Cloud Dataproc : クラウドネイティブな Apache Spark
Cloud Dataproc は、フル機能の構成済み Apache Spark クラスタを数千のお客様向けに数分で起動できるようにして、ビッグデータとアナリティクスの処理を「民主化」しました。Cloud Dataproc を使用すると、コンポーネント ゲートウェイなどの機能によって、セットアップやインストール作業なしでノートブックにセキュアにアクセスでき、あらゆる規模のデータ探索をすぐに開始できるようになります。さらに、これらのノートブックを Cloud Dataproc の自動スケーリングと組み合わせれば、ノートブックから離れたりジョブの実行方法を気にしたりすることなく、ML トレーニングの実行やさまざまな規模のデータ処理が可能です。基盤となる Cloud Dataproc クラスタは、事前に定義された範囲内でコンピューティング リソースを必要に応じて調整します。
ML モデルやデータ エンジニアリング ジョブが、本番稼働や自動化、さらには反復可能な形での実行に堪える状態になったら、コマンドライン ツールの gcloud や Google Cloud Platform Console を使って Cloud Dataproc Jobs API の jobs.submit を HTTP 経由で呼び出すことで、既存の Cloud Dataproc クラスタにジョブを送信できます。Jobs API を使用して Spark コードを送信すると、クラスタ全体でジョブが管理されるだけでなく、ロギングやモニタリングも行われます。また、クラスタ上でジョブを送信するためのパーミッションと、クラスタ自体にアクセスするためのパーミッションを分離することも簡単になります（ゲートウェイ ノードや、Livy のようなアプリケーションは不要です）。
新しい Cloud Dataproc : GKE による Jobs API の拡張
Cloud Dataproc Jobs API は、Spotify の Spydra や Cloud Dataproc のワークフロー テンプレートなどのカスタム ツールでジョブの自動化や ETL（抽出、加工、ロード）ジョブをラップしようと考えている企業のニーズにぴったり合致します。
その一方で、コンテナ化と Kubernetes のクラウド管理機能を活用している開発者やデータ サイエンティストは、ビッグデータ処理サービスにもっと多くのことを期待するようになりつつあります。従来、Spark ジョブを自動化するためには、ジョブを作成したクラスタを実行し続けるか（コストがかかるうえに、クラウドの従量課金機能のメリットを享受できません）、クラウド内に同じクラスタ環境を再現する方法（構成、初期化スクリプト、conda 環境、ライブラリ / パッケージ管理スクリプトの複雑な組み合わせになることがあります）を注意深くたどっていかなければなりませんでした。このプロセスは、さまざまなソフトウェアパッケージ、構成、OS アップデートが原因でコンフリクトが生じることがあるマルチテナント環境では、さらに煩雑になることがありました。
Cloud Dataproc on Kubernetes の登場によって、さまざまなソフトウェアの組み合わせからなる複数のタイプのクラスタを、そのような面倒な思いをしながら作成する必要はなくなりました。Cloud Dataproc Jobs API が GKE に対応するよう拡張され、ジョブのさまざまな依存関係を 1 つの Docker コンテナにまとめられるようになったのです。この Docker コンテナを使用すれば、Spark ジョブをソフトウェア開発パイプラインに直接統合できます。
Cloud Dataproc Jobs API が GKE 対応に拡張されたことで、システム管理者も、Kubernetes の知識を活用できる統一的な管理システムが手に入ります。スタンドアロンの仮想マシン、もしくは Apache Hadoop YARN で管理しなければならない Spark アプリケーションのサイロ化を回避できます。
Kubernetes が新たなリソース ネゴシエータに ?
Apache Hadoop YARN（2012 年リリース）は、オンプレミスとクラウドの Spark プラットフォームで広く使用されているリソース ネゴシエータです。YARN は、Compute Engine による Cloud Dataproc クラスタのコンピューティング リソースをスケジューリングするコア機能を提供しますが、Cloud Dataproc の Jobs API が GKE 対応に拡張されたことで、YARN による管理を Kubernetes に置き換えられるようになりました。YARN ではなく Kubernetes を使用すると、次のような重要なメリットが得られます。
1. 柔軟性
Spark コードが含まれるソフトウェア ライブラリを一貫して構成できるため、本番ジョブの柔軟性が向上します。Spark ジョブをコンテナ化すると、クラスタ レベルではなくジョブ レベルで依存関係とリソースを管理できます。これによりワークロード サイクルを予測しやすくなり、問題が生じたときにトラブルシューティングの対象を絞りやすくなります。
2. 自動修復
Kubernetes により、Spark ジョブも宣言的に設定できるようになります。ジョブの開始時に、ジョブの処理に必要なリソースを宣言できるということです。何らかの理由で Kubernetes リソース（executor）が不健全な状態になったときには、Kubernetes が自動的にそれらを修復し、ジョブは最初に宣言したときのリソースで実行を継続します。
3. 統一的なインフラストラクチャ
Google では、Borg と呼ばれるシステムを使用して、データ アナリティクス、ウェブサイト、その他あらゆる処理を統一的に運用しています。Borg のアーキテクチャは Kubernetes の基盤となっており、ビッグデータ（YARN）のサイロを設ける必要はありません。
Spark ジョブを単一のクラスタ マネージャに移行すれば、Kubernetes が提供する今風のクラウド管理だけを考えれば済むようになります。Google では、単一のクラスタ マネージャ システムを使用することで、リソースを効率よく活用し、ロギングと管理のフレームワークを統一しています。これと同じことが、皆さんの会社でも可能になります。
Kubernetes は、ビッグデータ処理で使えるリソース ネゴシエータの 1 つというだけではありません。データおよびアナリティクス ワークロードの信頼性と管理性を大幅に高める、ビッグデータへのまったく新しいアプローチなのです。
GKE 上での Spark ジョブの実例
ここでは、Cloud Dataproc on Kubernetes（アルファ版）で Apache Spark ジョブを投入するにあたり、必要な手順を見ていきましょう。
ステップ 0 : Cloud Dataproc への GKE クラスタの登録
GKE 上で Cloud Dataproc ジョブを実行するためには、まず Cloud Dataproc に GKE クラスタを登録する必要があります。アルファ版次点では、登録は Helm のインストールによって行います。GKE クラスタを登録してから次のコマンドを実行すると、Cloud Dataproc クラスタに GKE クラスタが統合されていることを確認できます。
ステップ 1 : Cloud Dataproc Docker コンテナの定義
Cloud Dataproc は、Cloud Dataproc のイメージ バージョン リストに掲載されたソフトウェア バンドルに対応する Docker イメージを提供します。アルファ版では、Cloud Dataproc 1.4 と同じ Spark 2.4.3 パッケージをミラーリングした Debian 9 Stretch ベースのイメージが提供されます。これにより、Compute Engine で実行されている Cloud Dataproc と、GKE 上の Cloud Dataproc ジョブの間で、Spark コードをシームレスに移植できます。
この Docker コンテナは、Cloud Dataproc のジョブ管理エージェントをカプセル化するだけでなく、Google Cloud の Spark Operator for Kubernetes（ベータ）の上に構築されます。この完全なオープンソースの Kubernetes Operator は、Kubernetes と、次のような Google Cloud Platform サービスとの統合を可能にします。
Google のサーバーレス データ ウェアハウスである BigQuery
HDFS の代わりとなる Google Cloud Storage
Stackdriver Monitoring に送られるログ
Kubernetes 環境上の Spark アプリケーションのライフサイクルを管理するコマンドライン ツール sparkctl へのアクセス
この Cloud Dataproc Docker コンテナは、自社の Spark ジョブで必要となるパッケージや設定を含むようにカスタマイズできます。
ステップ 2 : ジョブの投入
Docker コンテナの準備ができたら、GKE クラスタに Cloud Dataproc ジョブを送信します。すべての Cloud Dataproc Spark ジョブで同じ方法を使用できます。
独自コンテナによる Cloud Dataproc の拡張
上記のジョブを実行すると、Kubernetes 上のソフトウェア環境が Cloud Dataproc の環境にミラーリングされますが、このとき GKE オプションを指定すれば、ジョブに関連づけられたコンテナ イメージを指定できるという新たなメリットが得られます。このコンテナ プロパティは、ジョブ コードと必要なソフトウェア構成の確実な組み合わせを提供します。
Cloud Dataproc on Kubernetes の本番稼働に向けて
本番ワークロードを Kubernetes に移行し、本稿で説明したメリットを享受している Google Cloud のお客様は数千社に上り、私たちはそうしたお客様と協力して作業にあたっています。とはいえ、Cloud Dataproc on Kubernetes は現時点ではアルファ版です。Cloud Dataproc のほうはすでに一般提供され、多くの企業でさまざまな基幹アプリケーションを実行するために使われていますが、Cloud Dataproc on Kubernetes は開発中のサービスであることを忘れないようにしてください。
Spark の最新安定バージョンに含まれる Kubernetes サポートは、まだ実験的な機能とされています。そのため将来のバージョンでは、構成、コンテナ イメージ、エントリ ポイントなどで動作が変更になる可能性があります。Cloud Dataproc プロダクトの中核である Google Cloud Spark Operator もベータ版であり、同じことが当てはまります。
私たちは、お客様が Kubernetes での Spark ジョブ対応を早期に導入し、新しいワークロードを開拓してきたことに大きな感銘を受け、感動もしています。多くのお客様と協力しながら、このシステムを本番稼働できるものに育てていくことを楽しみにしています。ぜひアルファ プログラムにご参加ください。
もっと詳しく知りたい方やアルファ プログラムへの参加をご希望の方は、こちらからメールをお送りください。
- By Christopher Crosbie, Product Manager, Google Cloud and Patrick Clay, Software Engineer, Google Cloud
