スーパークラウドのスケール

Nicole Hemsoth

「私たちが人類として直面する一番の問題は、彼らが買った箱の外で人々を考えさせることである。」とCycle ComputingのCEO、Jason Stoweは言う。

彼の会社は大きな波を作り、Amazonサーバーと彼らの独自の革新の組み合わせが、HPCアプリケーションのユーザーのための新しい基盤オプションを開くことが出来ることを証明した。例えば、それらは、8つの地理的地域を跨いで量子化学アプリケーションのパワーをSchrödingerに供給するため156,000コアのAmazon Webサービス(AWS)クラスタを稼働させた。皆さんの多くは、その規模のスーパーコンピュータは、コストかもしれないものと推測できるが、それらの実行の継続期間は、彼らには約3.3万ドルの費用を、そして16,788インスタンスに分散させて1日未満で実行された。

彼らは、生命科学とその先の幾らかの他のユーザのための大規模な同じようなプロジェクトを行っていたが、しかし、彼らが拡張し続けているように、彼らは計算を追加する複雑さと、HPCセンターが行うのと同じベアメタルの課題の幾つかに遭遇し、複数の地域の異なるデータセンターを横断し、社内のスーパーコンピュータで出来るよりもより複雑な方法でマシンを停止し、起動する必要がある。

これらの課題への答えは、同社自身で独自開発したJupiter、AWS上で大規模で複雑なワークロードを実行するいくつかの重要な課題に取り組むこの世界の外のHPCクラウド管理ツールのコードネーム、に見つけることが出来る。

「私たちが行った5万コアで100万時間に実行の時に戻って、ある時点で、タスク分散環境をスケールすることは、従来のバッチスケジューラおよびサービス指向アーキテクチャーが大量の計算パワーがやって来て、ワークロードが増減するようなことが起きる方向に向かった場合に対応出来ないため、とりわけ疑わしくなります。」とStoweは言った。「また、これらの環境は、非常に障害に寛容ではなく、私たちは規模と障害の両方の要件を満たしている何かを開発する必要がありました。 」

しかしながら、彼らが微調整している可能性があるワークロード管理オプション(StoweはCondor、Grid Engine、PBSやPlatform/IBM等の確かなものを挙げる)が、クラウド環境のための能力を欠き、ワークロードトリックのタイプがHPCクラウドジョブを実行するために必要だったため、これをCycle側でゼロから開発する必要があった。

「数百万のプロセッサを持つ今のスーパーコンピューティング環境の多くで、それらの上のスケジューラが、ひとつのMPIジョブを実行するためにそれらのプロセッサのすべてに伝えることは本当に良いです。しかし、私たちが望んでいたことと正反対で、私たちは一度に数千のことを行うために、数千から数百万のプロセッサに伝えることができるものが欲しかったのです。」言い換えれば、例えば、ひとつのMPIジョブを扱うクラウドベースのシステムが「シンプル」に知らせる事ではなかった。それは、分散コンピューティング環境の内側で5万以上のMPIジョブがやっていることだろう。「私たちは、必ずしもバッチをしたくなかったが、あなたがワークロードのよりプログラム的なスケジューリングを行い、会話的に結果を得ることができるので、低いオーバーヘッドのスケジューリングをサポートしたいと思いました。 」

幾つかの地理的地域を横断してのサーバーでの作業の別の課題のひとつは、効率に対する視点だけでなく組込まれた耐障害性があることを確認することである。価格と計算サイクルは、流動的になっているので、Cycleは、ダウンタイムになった場合にアプリケーションの実行を維持するために必要であれば、全サーバー、データセンター、さらには地域でさえもオフにする機能を構築する必要があった。彼らがユーザーポリシーに応じて、手動または自動の両方で、この機能を用いて実験を行ったとStoweは言う。彼らは、別の領域にその処理を迂回させる十分なエネルギーを得る事が出来なかったため、ある実験中にオーストラリアのすべてのプロセッサをシャットダウンした。

Jupiterについてのオーバーヘッドの点で、極めて少数のサーバーで十分であるとStoweは言う。「私たちは最近、20以下のほんの一握りのサーバーで16,000サーバーを管理することができました。」とStoweは言った。これらの少数のサーバーは、8つの地理的地域を横断して156,000コアの実行のために全てのタスク分配サービスを提供し、もし必要であれば、より少ない数でも行うことが出来ました。各地域にひとつのヘッドノードを持っていて欲しかったため、私たちが行わなかった唯一の理由です。 」

ChefベースのJupiterツールは、特注の金融サービスクラウドプロジェクトのために2009年の仕事から来ている高度にスケーラブルで、低オーバーヘッドなクラウドスケジューラをどのやって作成するかについての早い時期の教訓とともに根底から構築された。拡張性と信頼性に向けての目標は類似していたが、彼らはSchrödingerの例にコスト効果的かつ、彼らが望んでいたやり方で取り組むのに十分な堅牢さを提供することができた。

Cycleは、YahooやHadoopで何が起こったのかと同様の方法で、2014年にJupiter(大規模な雲を持っている惑星にちなんで名付けられた)の話とアクセス可能性を立ち上げるだろ。「私たちは、このソフトウェアを中心に大幅な精査をしており、それがより広く利用可能なように簡単にダウンロード出来ることを目指して作業しています。」

高い遅延度やセキュリティ、その他の認知された障害を含め、HPCクラウドについて多々引用される課題があるにも係らず、高性能コンピューティングでのクラウドの採用が拡大している。ほんの数年前、HPCサイトのわずか約10％がクラウドを使っていると報告されたが、最も最近のIDCの推計によれば、24％近くまで跳ねあがっている。これはパブリッククラウド対プライベートクラウド(検討事項が若干異なるように)に関する議論を先導できる一方、Stoweはこれはここ数年、彼の会社が推進してきたクラウドが国境のない大規模なスケールで複雑なアプリケーションのためにうまく機能するのに十分堅牢にすることができるという考え方を推進してきたことへの肯定と見ている。

セキュリティ、クラウド上のアプリケーション、運用管理、レポーティング、高性能でコスト効率的な実行などの技術的な障害は、FacebookからNetflixやGoogleまで我々の多くが当てにするWebサービスを提供する多くのハイパースケール環境で対処されている。Stoweと彼の会社は、その世界からの教訓とツールをしまっておき、彼らのHPCアプリケーションでの長い仕事経験でそれらをかみ合せている。