サーバレスコンピューティングの限界を、HPCへの適用で考える：「The Next Platform」で読むグローバルITトレンド（4）

サーバレスコンピューティングは、クラウドにおけるホットな話題となっている。だが、あらゆるワークロードに適用できるわけではない。その限界を、ハイパフォーマンスコンピューティングへの適用で考える。

» 2017年07月14日 05時00分公開

[Ben Cotton, The Next Platform]

英国のIT専門媒体、「The Register」とも提携し、エンタープライズITのグローバルトレンドを先取りしている「The Next Platform」から、＠IT編集部が独自の視点で“読むべき記事”をピックアップ。プラットフォーム3へのシフトが急速に進む今、IT担当者は何を見据え、何を考えるべきか、バリエーション豊かな記事を通じて、目指すべきゴールを考えるための指標を提供していきます。

　“サーバレス”の流れがクラウドコンピューティングの新たなホットトピックとなっている。サーバレスモデルでは、Infrastructure-as-a-Service（IaaS）のインスタンスを実行してサービスを提供するのではなく、個々の関数がオンデマンドで実行される。

　Web開発の世界はサーバレスの恩恵を受ける。サーバのプロビジョニング、構成、モニタリング、メンテナンスの管理オーバーヘッドがないUIドリブンのワークロードを作成できるからだ。もちろん、完全にサーバレス（サーバなし）で処理を実行できるわけではなく、どこかでサーバが稼働している。

　サーバレスのポイントは、顧客がOSのパッチ管理やネットワークの構成など、手間の掛かる作業を気にせずに済むことにある。ユーザーは、外部イベントに応じて1つの演算や操作を実行する、ステートレスなソフトウェアとしての“関数”の作成だけを気に掛ける。

　だが、ハイパフォーマンスコンピューティング（HPC）は、主に最先端のハードウェアで動作し、細かいチューニングが施されるアプリケーションの領域だ。HPCはサーバレスの波に加われるだろうか。端的な答えとしては、「まだ加われない」といえる。しかし、マチェイ・マロースキー氏の論文『Towards Serverless Execution of Scientific Workflows（科学ワークフローのサーバレスな実行に向けて）』は、サーバレスモデルを一部のHPCワークフローに適用する方法に目を向けている。

　2016年11月に米国で開催されたSupercomputing 16（SC16）と併催のワークショップ「Workflows in Support of Large-Scale Science」で説明されたこの論文では、「Google Cloud Functions」の利用による天文画像モザイクツールキット「Montage」について述べられている。マロースキー氏は、これはサーバレスサービスを使った科学ワークフローの試みに関する最初に発表された論文だと考えている。これによると、概念実証プロジェクトにより、サーバレスモデルの適用は一部の科学アプリケーションで実現できることが分かったという。

　サーバレスモデルに適したアプリケーションを特定する最も効果的な方法は、最初にこのモデルにそぐわない幾つかの大きなカテゴリーのワークロードを除外することだ。大手クラウドサービスで提供されているサーバレスサービスの実装では、多くの科学ワークフローがすぐにはねられてしまう。

　まず、メッセージのやりとりが必要なアプリケーションは「お呼びでない」。各関数は独立した演算単位であるため、ワークロードを結合したものはこのモデルに向かない（仮定上は、全ての関数の実行開始を待って、密結合されたコードを実行する関数を作成できる。だが、そのための労力は大きく、ネットワークのローカリティのような特性に対する管理手段が欠如しているため、これは、学問的な訓練以外の目的では愚かな選択ということになりそうだ）。

　長時間にわたるアプリケーション（実行に10分以上かかるアプリケーションなど）も、サーバレスモデルに合わない。これは、サーバレスパラダイムにおける本質的な制限のせいではなく、プロバイダーがサーバレスサービスで制限を設けているからにすぎない。HPCクラスタも、ポリシーで設定されたジョブの実行に極めて長い実時間がかかるかもしれない。クラウドプロバイダーは関数への柔軟性の提供と、ワークロードの暴走の防止を目的に関数の実行時間を制限している。

　プロバイダーが、「長時間にわたるサーバレス関数には適当な規模の市場がある」と考えるようになれば制限を調整するかもしれない。当面は、制限時間内で実行されるように分解できないジョブは、サーバレスモデルの適用対象の候補に入らない。

　サーバレスモデルにそぐわないもう1つのカテゴリーとして、特定のハードウェアやソフトウェアの構成を必要とするジョブが挙げられる。例えば、GPUはサーバレスサービスでは提供されておらず、大手プロバイダーは皆、関数当たりのメモリ使用量に上限を設けている。同様に、サーバイメージがないことから、ソフトウェアライブラリへの依存が多いアプリケーションも実行できない恐れがある。

　関数は、サポートされている言語（「Google Cloud Functions」ではNode.js、「AWS Lambda」ではJava、Node.js、Python、「Azure Functions」ではBash、Batch、C#、F#、JavaScript、PHP、PowerShell、Python）で作成され、クラウドストレージシステムから追加ファイルをコピーできる。だが、このファイル転送時間は実行制限の対象としてカウントされ、ジョブは通常のライブラリパスに書き込めない。このことから、関数自体の他にもコードが必要な場合は、ファットバイナリを構築するのが明らかに得策だ。

　現在のサーバレスサービスで実行できないワークフローに加えて、ワークフローの実行が困難または適さない原因となる特性もある。入出力に大容量ファイルの転送を伴うタスクは、計算に使える時間を圧迫してしまう。同様に、複数のタスクごとに同じ入力を読み込む必要があるワークフローや、あるタスクの出力を次のタスクに提供するワークフローは、同じデータを繰り返し再転送するコスト（時間と転送料金の両方）のせいで、あまりメリットがない。

　一方、サーバレスの利用に二の足を踏ませかねないビジネス管理上の問題もある。それは予算作成に関わるものだ。一般的に、クラウドでIaaSリソースを使ってワークフローを実行する場合は、かなり予算を立てやすい。「インスタンスが幾つ必要か」「大体どのくらいの時間が必要か」が分かるので、インスタンス当たりの単価を掛ければ、特定のワークフローの実行にどれだけの料金が掛かるかを概算で見積もれる。

　だが、サーバレス関数に掛かる一般的な料金は、リクエスト回数に応じたもの（1回当たりの単価は1セントよりはるかに小さい）と、リソースの利用（一般的に、GB／秒当たりの単価は1セントよりはるかに小さい）の合計だ。サーバレス方式で実行したことがないワークロードについて、ユーザーはそうした詳細なレベルで費用を見積もった経験はないだろう。同等のIaaSインスタンスを実行する場合と比べて（利用規模によっては）料金は安くなるかもしれないが、利用が急激に増加した場合を含めて、料金の確実な見通しが立たないのは頭の痛い問題だ。

　こうしたことは、科学コンピューティングのアプローチとしてのサーバレスに大きな影を投げ掛けるように見えるかもしれない。だがわれわれは、サーバレスサービスでできる作業が限られていることが、HPCサイトにとってサーバレスの魅力になる可能性があると考えている。

　サーバレスに最適なジョブは、典型的なHPCクラスタに最適ではない。そうした短時間のタスクが多いとスケジューラに大きな負担が掛かることがあり、スケジューリングのオーバーヘッドが総実行時間の中でかなりの割合を占める恐れもある。

　サーバレスサービスは、HPC管理者にこうしたジョブをより適切なリソースに移行し、強力なハードウェア機能が必要なワークフローのための環境を提供する。

　サーバレスアプローチを導入するには、これまでとは異なるスキルセットが必要になる。クラスタの実行ではシステム管理やオペレーションの役割の比重が大きいが、サーバレスははるかに開発寄りだ。DevOpsの取り組みも広がってきているが、現時点で確実なのは、まだ導入状況はまだら模様だということだ。サーバレスは、少なくとも特定のユースケースに関しては、NoOpsを実現する可能性を秘めている。だが、HPC管理者が気に掛ける必要はまだないと、われわれは考えている。

　科学コンピューティングの分野では、サーバレスはまだ出始めたばかりの考え方だ。サーバレスがサポートできるワークフローは限られており、今すぐに従来のHPCやハイスループットシステムに取って代わることはなさそうだ。現時点では、サーバレスは計算処理の後のデータセットや完了したシミュレーションの可視化、それらの分析ポータルの基盤として使用するのにうってつけかもしれない。

出典：Serving Up Serverless Science（The Next Platform）