クラスタを利用して大規模なテクニカル コンピューティングをクラウドで実行する

このソリューションでは、Google Cloud で大規模なテクニカル コンピューティングを実行するためのガイダンスを提供します。多くのテクニカル コンピューティング アプリは大量のコンピューティング ノードを必要とします。これらのアプリでは、ノードを相互に接続してクラスタを構成し、ノード間でのコンピューティングとデータアクセスを調整しています。

クラスタ コンピューティングの基になるコンセプトと技術が生まれたのは 2、30 年前のことです。その後、これらの技術は進化を続け、現在ではコンピューティングの主流となっています。ソフトウェア スタックを Google Cloud に移行すると、新たな問題を抱える可能性もありますが、シンプルな方法でコストが削減され、現在のハイ パフォーマンス コンピューティング環境におけるボトルネックを解消できます。このガイドでは、Google Cloud 上でコンピューティング クラスタを実行するためのテクノロジー、課題、現在のソリューションの概要を説明します。

クラスタ コンピューティングでは、1 つの作業を処理するために複数のマシンを集約し、調整を行います。クラスタは通常、1 つのヘッドノード(マスターノードともいいます)と複数のコンピューティング ノードから構成されます。この他に特別なノードが存在する場合もあります。ヘッドノードがシステムの頭脳となり、次の処理を行います。

  • コンピューティング ノードのシステムへの登録
  • ノードのモニタリング
  • 特定のノードへのジョブの割り当て
クラスタは、ヘッドノードと複数のコンピューティング ノードから構成されます。
図 1 クラスタは、ヘッドノードと複数のコンピューティング ノードから構成されます。ユーザーはヘッドノードにアクセスし、ヘッドノードがコンピューティング ノードの作業を調整します。

ユーザーが送信するジョブは複数のタスクから構成され、これが基本的な作業単位となります。アプリによっては、ジョブのすべてのタスクを同時に実行しなければならない場合があります。並列アルゴリズムを実装するため、複数のタスクが相互に通信を行う場合もあります。ジョブによっては、タスクの依存関係が複雑なこともあります(たとえば、特定のタスクを他のタスクよりも優先的に処理する場合など)。また、メモリ、CPU、他の特定のハードウェアなど、特定のノード構成を必要とする場合もあります。タスクは、ストレージから入力データを読み取り、データを処理して結果を生成し、最終的な結果をストレージに書き込みます。

クラスタ コンピューティングのワークロードには、主に 2 つのタイプがあります。

  • ハイ パフォーマンス コンピューティング(HPC) - タスクを実行するために、多くのワーカーノードが緊密に結合され、同時に実行されます。これらのマシンを有効に活用するには、ネットワークのレイテンシを低くする必要があります。このようなアプリとしては、気象モデリング、数値流体力学(CFD)、エンジニアリングでのストレス モデリング、電子設計などがあります。

  • 高スループット コンピューティング(HTC) - 他のコンピューティング ノードと通信を行わずに個別に処理される複数のタスクがアプリに存在します。これらのワークロードは、驚異的並列ワークロード、バッチ ワークロードともいいます。この種類としては、メディア レンダリング、変換、ゲノミクス、素粒子物理学事象のシミュレーションや処理などがあります。大量のファイルを処理する必要がある場合には、HTC ワークロードの方が適切です。

クラスタ コンピューティングのソフトウェア スタック

クラスタ コンピューティングのソフトウェア スタックは、次のものから構成されます。

  • クラスタのプロビジョニングや作成を行うシステム管理ソフトウェア
  • ジョブの実行をオーケストレートするスケジューラ
  • エンドユーザー アプリ

以下のセクションでは、システム管理ソフトウェアとスケジューラについて説明します。

システム管理ソフトウェア

クラスタリング ソフトウェアは、ハードウェアで直接実行することも(オンプレミス クラスタ)、仮想環境(クラウド環境)で実行することもできます。クラスタの複数のノードを手作業でオーケストレートすると、時間がかかるだけでなく、エラーも発生しやすくなります。特別なクラスタ管理ソフトウェアを使用すると、複数のノードとリソースをプロビジョニングし、繰り返し同じ方法で実行されるように構成できます。

チューリッヒ大学がオープンソースで提供している ElastiCluster はクラウド ネイティブの方法でクラスタを管理します。ノードのプロビジョニングに Compute Engine を利用し、ノードの構成に Ansible プレイブックを使用します。ElastiCluster は、ノードをプロビジョニングして、ベースとなるソフトウェア スタックをインストールします。たとえば、ファイル提供用に NFS、ユーザー アカウントの管理用に NIS、ユーザーアプリの実行用にジョブ スケジューラをインストールします。ElastiCluster はさまざまなスケジューラに対応しているので、そのまま使用することも、小規模から中規模のチームの要件に合わせてカスタマイズすることもできます。

その他の構成管理システムを使用して Chef、Puppet、Terraform などの HPC クラスタを管理している場合は、利用可能なツールやプラグインを使用して、Google Cloud に移行する際に活用できます。詳細については、Puppet、Chef、Salt、Ansible での Compute Engine の管理をご覧ください。

Google Cloud には、マルチノード ソフトウェア システムのプロビジョニングとデプロイを行うネイティブ サービスが用意されています。Cloud Deployment Manager では、Compute Engine、Compute Engine のマネージド インスタンス グループ、Cloud Storage などのクラウド リソースをプロビジョニングできます。Cloud Deployment Manager とマネージド インスタンス グループを使用してクラスタのプロビジョニングと構成を行う方法については、HTCondor チュートリアルをご覧ください。

ジョブ スケジューラ

クラスタの稼働後は、ジョブ スケジューラがタスクの実行とノードの割り振りを管理します(このスケジューラは、ワークロード マネージャー、キュー マネージャーともいいます)。多くの場合、クラスタの管理ツールにジョブ スケジューラが付いています。ジョブ スケジューラは、次のようにジョブやタスクの管理に必要な機能を提供します。

  • ユーザーとグループ間でジョブの優先度をサポートします。これにより、ポリシーベースのジョブ スケジューリングを行います。
  • 失敗したタスクをサポートします。タスクをキューに入れ、スケジュールを再設定します。
  • タスクの依存関係とタスクの割り振りに必要なリソースを判別します。
  • キュー内のジョブ数に応じてクラスタサイズをスケーリングします。

市販またはオープンソースでよく利用されているジョブ スケジューラとしては、ウィスコンシン大学の HTCondor、SchedMD の SlurmUniva Grid Engine、IBM の LSF Symphony などがありますが、それぞれに強みがあります。

HTCondor はシェアードナッシングで設計され、共有リソース間で使用されます。状況に応じてアイドル状態のリソースにジョブをスケジューリングします。独自のデータ移動機能を用意しているので、共有ファイル システムは必要ありません。結果として、HTCondor は数十万のコアにスケーリングし、複数のゾーンとリージョンで使用できます。HTCondor は、オンプレミスとクラウドで作業を共有または分割するハイブリッドなワークロードに利用されてきましたが、その名前のとおり、高スループットのジョブで、密結合でない並列ジョブを対象にしています。

Slurm と Univa Grid Engine は従来型の HPC クラスタ環境を提供し、高スループットと高性能の両方の並列アプリに対応しています。いずれも、ノード間の共有ファイル システムの存在を前提としているので、データを移動する必要はありません。オンプレミスでも同じツールを使用するため、アプリの開発には便利で使いやすい環境を提供します。小規模から中規模のクラスタの場合、これらの従来型のジョブ スケジューラで十分ですが、クラスタのサイズが大きくなると、ファイル サーバーに対する負荷が処理速度のボトルネックになります。この場合、並列ファイル システムや分散ファイル システム(次のセクションを参照)の方が有効です。あるいは低レイテンシのファイル アクセスが不要であれば、Cloud Storage を利用することもできます。これにより、API または gcsfusePOSIX 互換が必要な場合)を使用したオブジェクトの並列アクセスが可能になります。

最後に、Google Cloud には、高スループット ワークロード用に Compute Engine で Docker ベースのタスクをスケジュールできる Cloud Life Sciences Pipelines API という、シンプルなサービスが用意されています。このサービスでは、ジョブをタスクに分割し、タスク間の依存関係とタスクのライフサイクルを管理する必要があります。dsub オープンソース プロジェクトは、バッチジョブを起動するためのコマンドライン ツールを提供し、Cloud Life Sciences Pipelines API をサポートします。

ストレージ

ほとんどの HPC アプリケーションには、POSIX API をサポートするファイル ストレージ ソリューションが必要です。小規模クラスタの場合、FileStore によって Google が管理する NFS ベースのファイル ストレージ サービスが提供されます。ただし、大規模なクラスタでは、アプリケーションの I/O がパフォーマンスのボトルネックになる可能性があります。Elastifile(Google 傘下)、LustreQuobyte などのスケールアウト ファイル システムや並列ファイル システムは、大規模クラスタ(または I/O が重い小規模クラスタ)へのスケーリングに役立ちます。

あるいは低レイテンシのファイル アクセスが不要であれば、Cloud Storage を利用することもできます。これにより、API または gcsfusePOSIX 互換が必要な場合)を使用したオブジェクトの並列アクセスが可能になります。

クラウドでクラスタ コンピューティングを行うメリット

クラウドでコンピューティング クラスタを実行するメリットは次のとおりです。

  • 短時間での開始。クラウドで本番環境と同品質のクラスタを数分で起動できます。数百のコアを使用した 10 ノードのクラスタから、数十万のコアを使用した大規模なクラスタまで、用途に合ったクラスタを構築できます。オンプレミスで新しいクラスタを構築する場合、運用開始までに数か月かかることもあります。オンプレミスのクラスタが利用できる場合でも、クラスタの使用率が高く、キューの待機時間が長くなるため、ジョブが実行されるまでに数時間あるいは数日かかる場合があります。クラウドの場合、独自のクラスタを構築してワークロードで使用し、解析が完了したらクラスタを終了できます。

  • 総所有コストの低減。Google Cloud で解決できるのは時間だけではありません。プリエンプティブル VM、長期使用割引、動的スケーリングにより、総所有コストを削減できます。ジョブがキューに入ったときにノードを追加し、不要になったときにノードを削除できます。

  • コラボレーションのサポート。多くの場合、コンピューティング解析の開発には異なる組織の複数の担当者が参加します。Google Cloud の Identity and Access Management ツールを使用すると、データや解析ツールに対するアクセスを制御できます。許可されたユーザーは同じアプリ、データ、クラスタにアクセスできるので、データのコピー、バージョン管理、クラスタ構成の同期を行う必要がありません。

  • タスクごとに調整可能なリソース。ジョブのコストはインスタンスの数ではなく、コア時間の合計によって変わります。クラウドでクラスタを実行することで、チームまたはグループごとに専用のクラスタを所有できます。これにより、複数のグループで使用するポリシーを開発する場合の問題を解消できます。また、専用のクラウド クラスタをアプリに合わせて調整することも可能です。オンプレミスのクラスタは、複数のグループやアプリで画一的なリソースを共有する傾向があります。このような環境の場合、グループ間で共有するポリシーの設定と維持は複雑になります。

  • 統合。大規模なコンピューティング ジョブを実行する前に、データセットの準備が必要になりますが、その作業量は膨大なものになります。クラウドに移行すると、クラウドでビッグデータ ツールを利用できます。また、コンピューティング システムの出力も分析しなければなりません。BigQuery や Datalab などのツールは、オンプレミスのシステムで利用できない機能を提供します。

標準的なオンプレミス クラスタは、ユーザーとグループ間で共有され、複数のアプリの異なる要件を処理しています。
図 2 標準的なオンプレミス クラスタは、ユーザーとグループ間で共有され、複数のアプリの異なる要件を処理しています。一方、Google Cloud に移行すると、アプリの要件に合わせてクラスタのプロパティをカスタマイズできるので、コストを削減し、パフォーマンスを向上させることができます。

アーキテクチャに関する注意事項

このようなメリットは非常に魅力的ですが、移行プロジェクトで問題になる技術的な課題もあります。

  • データの移動。クラスタのコンピューティング ノードで処理されるデータセットは、通常は、ジョブの実行前にクラウドにステージングする必要があります。データの量や管理方法によっては、データ移動の管理が複雑になる場合もあります。Avere などのツールも有効です。このツールは、クラウド キャッシュ レイヤを使用して、必要に応じてデータを自動的に移動します。ただし、多くのアプリでは、データセットを手動でステージングしなければなりません。

  • データアクセス。多くの HPC アプリは、ファイルとディレクトリに対する共有アクセスを必要とします。アクセスの制御方法によっては、アプリのパフォーマンスが著しく低下する可能性があります。Cloud Storage や NFS サーバー(FileStore など)に格納された共有データを使用したり、ストレージ セクションで説明した並列ファイル システムを使用したりできます。

  • セキュリティ。機密データの場合は、アクセスするときに常に認証が行われ、データの保存中や転送中に適切に暗号化されるように注意する必要があります。Cloud Storage は保存時と送信時にデータを暗号化しますが、さらにアクセス制御を追加できる他、Cloud Key Management Service や独自のサービスでキーを管理できます。キーは、ジョブの実行前にコンピューティング ノードで取得またはインストールしておく必要があります。

  • ノード間のレイテンシ。密結合の HPC アプリの場合、クラスタのノード間レイテンシによってパフォーマンスが影響を受ける場合があります。Google Cloud では、ノードで 64 コアまで使用できるため、ノード間を移動せずに 64 個の並列ジョブを実行できます。通常、1,000 コア以下のジョブであれば、特殊でないネットワーク ハードウェアでも十分な速度で処理されます。

  • ソフトウェアのライセンス管理。市販の多くのアプリは、ライセンス サーバー(キーサーバー)を使用しています。アプリによっては、ライセンス サーバーが組み込まれていたり、推奨のライセンス サーバーが同梱されていたりします。また、既存のライセンス サーバーと互換性がある場合もあります。ライセンス管理に対応しているジョブ スケジューラもあります。このようなスケジューラでは、ライセンスが使用可能になるまでジョブを停止します。

テクニカル コンピューティングでは、状況に応じてさまざまなツールとアプローチが利用されています。選択肢が多いため、どれから始めればよいのかわからなくなりますが、クラスタ管理ソフトウェアやスケジューラの選択にかかわらず、Google Cloud での実行時にはさまざまなおすすめの方法を使用できます。

  • 可能な限り、プリエンプティブ VM を利用する。プリエンプティブル VM は、Compute Engine の通常の VM と同じですが、料金は通常の VM と比べて最大 80% 安くなります。ただし、回収の通知が直前まで行われないことがあります。高スループット ワークロードの場合、ジョブ スケジューラがノードの損失を検出してエラーとして処理し、そのノードで実行中のタスクを別のリソースに再スケジューリングします。損失したノードに対して行った作業は失われる可能性がありますが、低料金のメリットを上回るほどノード損失の可能性は高くありません。予想される損失率は 5% から 15% です。プリエンプティブル VM は最大 24 時間使用でき、それを超えると回収されます。
  • 独自の並列ファイル システムではなく、Cloud Storage のコストと帯域幅を利用する。Cloud Storage では、強整合性とスケーラビリティに優れた並列処理を低コストで利用できます。先頭バイトのレイテンシは約 100 ミリ秒ですが、Compute Engine で並列ファイル サーバーを実行するより Cloud Storage を利用できるアプリのほうがコスト効率が良くなります。多くのアプリでは、Cloud Storage とコンピューティング ノードの間で利用できる帯域幅で十分です。23 GB/秒を超える集約帯域幅が持続したという報告もあります。
  • 1 つのアプリまたは 1 つのグループにクラスタを作成する。従来型のクラスタは、複数のユーザー、グループ、アプリで共有されています。この場合、キュー内でのジョブの待機時間が長くなり、アプリでのリソースの使用効率が低下します。Google Cloud では、グループまたはプロジェクトごとに複数のクラスタを作成し、特定のアプリ用にクラスタを最適化することを検討してください。1 つのクラスタを 2 時間実行しても、2 つのクラスタをそれぞれ 1 時間実行しても、全体のコストは変わりません。ただし、後者の方がキューでの待機時間が短くなり、アプリのパフォーマンスが向上します。

実際の状況はそれぞれ異なりますが、ここでは 3 つの一般的なケースを採り上げ、全般的な推奨事項を説明します。

個人の研究者がデータを処理する場合

研究者は通常、データ全体にアプリを実行して、できるだけ速く結果を得たいと考えていますが、自分の研究領域でないクラスタ管理について詳しく知りたいとは考えていません。

高スループットのワークロードを実行している場合は、Cloud Life Sciences Pipelines API の使用を検討してください。Pipelines API では、アプリを Docker コンテナに配置し、入力ファイルを Cloud Storage バケットに配置する必要があります。配置が済んだら、gcloud コマンドライン ツールを使用して Cloud Storage バケット内の各ファイルに対してアプリを実行し、結果を別の Cloud Storage バケットに配置できます。

次のコマンドは、SAMtools を使用して BAM 入力ファイルから BAM インデックス ファイルを生成するタスクを実行します。

gcloud alpha genomics pipelines run --pipeline_id [PIPELINE_ID] \
--logging gs://[YOUR_BUCKET/YOUR_DIRECTORY]/logs \
--inputs inputFile=gs://genomics-public-data/gatk-examples/example1/NA12878_chr22.bam \
--outputs outputFile=gs://[YOUR_BUCKET]/[YOUR_DIRECTORY]/output/NA12878_chr22.bam.bai

ここで

  • [PIPELINE_ID] は Pipelines API のアプリ ID を表します。
  • [YOUR_BUCKET] は Cloud Storage バケット名を表します。
  • [YOUR_DIRECTORY] はディレクトリの名前を表します。

クラスタのプロビジョニングも管理も必要ありません。タスクは、Pipelines API がプロビジョニングして管理している VM で完了するまで実行されます。Compute Engine では 1 秒あたりの使用量で課金されるため、これはコスト効率の良い方法です。

1 つのプロジェクト / チームで小規模または中規模のクラスタを使用している場合

プロジェクトまたはチームのメンバーが、会社全体で利用するクラスタや、オフサイトの HPC センターの大規模なリソースにアクセスしている場合があります。いずれの場合も、クラスタは専門の部署で管理され、標準のツールでアクセスされています。たとえば、ヘッドノードへの接続には ssh を使用し、実行ジョブの送信には Grid Engine submit スクリプトを使用します。

このようなチームの場合、ElastiCluster を使用してオンプレミス システムと類似したクラスタ環境を定義します。アプリに最適な Compute Engine マシンタイプを選択してクラスタをカスタマイズし、アプリのソフトウェアの依存関係をインストールするように起動スクリプトを変更します。入力データは引き続き Cloud Storage にステージングし、gcsfuse をコンピューティングノードにインストールして、入力データをマウントします。

これらの詳細は ElastiCluster の構成ファイルに記録され、計算が必要になった場合は、次のようなコマンドライン ツールを使用してクラスタを起動します。

% elasticluster start astrocluster1

構成ファイルに指定されたクラスタ astrocluster1 がプロビジョニングされ、指定どおりに構成されます。構成ファイルには自由に定義できます。ヘッドノードとコンピューティング ノードに異なるノードタイプを使用することもできます。一時的な領域として Compute Engine の永続ディスクを設定し、高スループット ワークロード用にプリエンプティブル VM を設定してコストを下げることもできます。また、高速オペレーション用の GPU も指定できます。10 個のコンピューティング ノードと 1 個のヘッドノードから構成され、CentOS ベースの 32 コア仮想マシンを使用する Slurm ベースクラスタの基本構成は次のようになります。

[cluster/astrocluster1]
 cloud=google
 login=google
 setup=ansible-slurm
 security_group=default
 image_id=centos-7-v20170327
 flavor=n1-standard-32
 frontend_nodes=1
 compute_nodes=10
 ssh_to=frontend
 boot_disk_size=50
 

最後に、システムで実行中のジョブがなくなったら、クラスタを停止できます。

% elasticluster stop astrocluster1

ワークロードのサイズが大きくなった場合には、次のことを行います。

  • クラスタマシンのタイプを変更して、コストを抑える。
  • 外部の並列ファイラーを追加して、パフォーマンスを向上させる。
  • 自動スケーリング機能を追加して、キューの深さに応じてノードを追加または削除する。

HPC センターで既存のクラスタにバースト機能を追加する場合

中央の HPC センターでは、さまざまなコンピューティング機能が実行されていますが、このセンターは会社や部門の多くのグループが利用しています。このため、HPC センターの使用率は常に高く、キューの待機時間も長くなっています。通常、一定の本番環境での容量を想定して設備投資が行われていますが、予期しないワークロードにより、処理能力が著しく低下することもあります。

このような状況では、コンピューティング ノードを一時的にクラスタに追加することで、Google Cloud 環境にバーストできます。クラスタはハイブリッド(ヘッドノードと一部のコンピューティング ノードがオンプレミスで実行され、他のコンピューティング ノードが Google Cloud で実行される)になります。ジョブキューがドレインされると、追加ノードは解放されます。

クラウドのバーストには次のようなメリットがあります。

  • ジョブ送信と管理で一貫したユーザー環境を維持できます。ノードが追加されても、ユーザーがそれを意識することはありません。
  • IT 管理者は、バースト時間をポリシーで定義し、コストを管理できます。

オンプレミスと Google Cloud のノードでユーザージョブを処理する場合の最大の課題は、データとファイルの名前空間の整合性を維持することです。Google Cloud のノードが、オンプレミス ノードと同じ内部ファイル システムにアクセスできない場合があります。この場合、これらのファイルを参照するジョブは失敗します。

Google Cloud ノードに内部ファイルへのアクセス権限が構成されている場合はジョブが実行されますが、その場合はネットワーク帯域幅と下り料金が加算される可能性があります。また、アプリの部分間で追加のレイテンシが発生し、オンプレミス ノードとクラウドノードで分割した並列ジョブがうまく実行されない可能性もあります。

高スループット ジョブの場合、HTCondor を使用してクラウド リソースをバーストすると、この問題の多くを回避できます。HTCondor は、GlideInWMS を使用した動的プロビジョニングをサポートしています。送信したジョブがキューに入ると、ノードのプロビジョニングが開始され、クラスタに追加されます。ノードが追加されると、condor スケジューラが入力ファイルを指定のノードに転送し、追加ノードを使用してタスクを実行して、キューをドレインします。

次のステップ

Google Cloud でのクラスタ コンピューティングのユースケースを見る:

次のドキュメントを見る:

クラスタのスタートガイド:

GitHub 上のプロジェクトの例: