HOME > ストレージ管理ソリューション部会 > Storage Magazine翻訳記事

時間が決め手だ

人々はパフォーマンスの飽くなき追求から、レイテンシ削減のために、データやコンピュート（演算処理）を移動する。

2018年10月号Storage Magazineより
Marc Staimer

全ては時間だ。時間とは、前にしか進めない、再生不能な資源だ。それは一度消費されると、修復したり巻き戻したりできないものだ。時間は事象と瞬間を切り離す構造体だ。ITの運用において、時間が潤沢にあることは決してない。もっと短い時間でも構わない、などと言った人は未だかつていない。1秒刻みでもっと多くのことをやれ、という絶え間ない圧力が存在している。

ハイパフォーマンス・コンピューティング（HPC）別名スーパーコンピューターと、計算回数すなわちFLOPS（1秒あたりの浮動小数点演算命令実行回数）の増加の飽くなき探究を例にとって考えてみよう。今日(こんにち)、測定値の単位は数十～数百petaFLOPSだが、次のゴールは千倍速い、exaFLOPS台だ。

同じように容赦ないプレッシャーがストレージにもかかっていることは、すぐわかるだろう。ストレージ基盤のパフォーマンスはIOPSとスループット毎秒で測定される。メガバイト～ギガバイト毎秒の単位は、テラバイト毎秒へと移行しつつある。

1秒あたりの基盤のパフォーマンスをもっと上げたいという絶え間ない渇望。そこには次の質問に隠された暗黙の命題がある：
データを移動するのとコンピュート（演算処理）を移動するのとではどちらが合理的か。

まずは一般論から

一般的な知恵によれば、コンピュートをデータのところに移動するのが合理的だ、ということになる。確かに、これは圧倒的多数のユースケースにあてはまる。この方が簡単だし速い。実行ファイルは入力されたデータよりデータ量が小さく、ネットワークやインターコネクトを軽快に動き回れるからだ。データの移動にはネットワーク帯域、時間、そしてほとんどの場合、熟練した手動作業が必要になる。この作業の必要性ひとつだけでも、ITマネージャーがコンピュートをデータへと移動することを選択するのに充分な理由になる。

コンピュートを移動する方法の好例はHadoopアーキテクチャーだ。Hadoop Job Trackerは、要求されたデータが置かれているコンピュート・ノードに対して、巧みなタスク・スケジューリングを行ってくれる。もし指定されたノードでのジョブが実行不可能な場合、このソフトはそのジョブを同一トラック内の他のコンピュート・ノードに割り付けようとする。そのノードも使えない場合は、ジョブはグリッド上のどこかに割り付けられるだろう。Hadoop Job Trackerのスケジュール・アルゴリズムのベースになっているのは、入力されたデータをコンピュート・ノードまで移動するのは時間がかかりすぎる、という原理だ。データの移動はジョブにレイテンシを加え、レスポンス時間を増大させる。

Hadoopの例は、データにコンピュートを移動するのが明確に最適である決定的な利用状況のほんの一例だ。他の例としては、コンピュートとデータ間の帯域が不足している場合だ。しかし、これとは違う状況も存在する。コンピュートを移動するのにあまりにコストがかかる、あるいは複雑すぎて実行不可能なケースだ。また、ワークフロー連携、セキュリティ、基盤が原因で、データを移動する方がより現実的な環境もある。

コンピュートをデータへ、データをコンピュートへ、これらの一つ一つのシナリオを分析し、それぞれのケースでデータかコンピュートか、どちらを移動するのがより合理的かを明らかにしよう。

コンピュートをデータに移動するケース

Hadoop Job Trackerが示すように、通常はデータを移動するよりもコンピュートを移動した方が簡単で速い。基盤パフォーマンスは、大抵コンピュートがデータに近い方が速い。この結果は、距離の短さから直接来ている。距離はレイテンシと等しい。レイテンシは、基盤のパフォーマンスを低下させ、光の速度と直に結びついている。古いジョークが言うように、「光の速度は限界っていうだけじゃない、そいつは法則なんだ」。

光の速度と距離は、（すぐには起きないだろうが）ワームホール（訳注：時空の2点間を直結するトンネル）技術が発明されるまでは、レイテンシの問題であり続けるだろう。距離とレイテンシを減らせば、レイテンシが時間あたりのパフォーマンスのボトルネックになっている場合、一秒あたりのパフォーマンスは改善する。ボトルネックがCPU、メモリ、ソフトウェアの非効率性、ストレージ基盤のいずれかにある場合、改善の度合は限られてくる。

コンピュートとデータを近接させることで最もメリットを享受するアプリケーションは、一般にレイテンシの影響を受けやすい。HFT（高頻度取引）のような大量トランザクション・アプリケーションにとってコンピュートをデータへ移動する方法は理想的だ。この世界では、1マイクロ秒が数百万ドルと等しいからだ。この方法でメリットを享受する、その他の大量トランザクションのアプリケーションとしては、HPC、OLTP（オンライン・トランザクション処理）、e-コマース、オンラインゲームなどがある。これらのアプリケーションは全て、コンピュートをデータの近くに移動することに利点を見出している。

コンピュートをデータに移動することの価値は、WAN越しに移動されるデータが大量に存在する場合、極めて明白になる。良い例として、あなたがクラウドのレポジトリに、まあ仮に1ペタバイトのデータを持っていて、それをネットワーク経由でオンプレミスに移動しなければならないとしよう。ここは、ハードウェア・セキュリティ・モジュール、別名アプライアンスとクラウド・ストレージゲートウェイの出番だ。これらの装置は、クラウドに移動したデータに対してオンプレミスの元のストレージがそれを読み、処理し、更新できるように復元する。

ギガビット毎秒の帯域の理論パフォーマンス値を125MB/秒としても、データを取得するまでに相当な時間がかかるだろう。実際のところ、TCP/IPは理論パフォーマンス値を提供しない。しかし仮に、その値が提供されるとしても、1ペタバイトのデータを目的の場所へ移動するのには、少なくとも93日かかることになる。実際に起こりそうなシナリオは、スループットが最大で公称値の約30％でデータ移動の期間が約309日、つまり10ヵ月以上にもなり、これではタイムリーとは言えない。WANオプティマイザーを使ったとしても、消費される時間は前述の値の中間のどこかに落ち着くだろう。これでもかかり過ぎだ。

このシナリオでコンピュートをデータに移動すれば、かかる時間は明らかに少なくなる。クラウド内に保存されたデータに対して、この処理はクラウド内でアプリケーションと共にコンピュートインスタンスをスピンアップさせて行われる。処理完了後、インスタンスは使用していない時も課金されないようにスピンダウンされる。オンプレミスでHadoop Job Trackerにデータを移動するのを待っているものよりデータの処理は、ずっと早く始まる。またクラウドストレージのデータを外に移動する（egress）巨額な費用も節約できる。

コンピュートをデータの近くに置くことでメリットを享受できるもう一つのアプリケーションのタイプは、多くのHPCエコシステムで使われている並列I/Oだ。HPCはLustre、Panasas、Quobyte、IBM Spectrum Scale（旧GPFS）、Weka IOなどの並列ファイルシステム経由で大量のデータを処理する。並列ファイルシステムのレイテンシ要求を満たすには、一般的にデータを個々のHPCサーバー・ノード内のストレージに配置する。それによってレイテンシ距離は短くなる。NVMe-oF（Nonvolatile Memory Express over Fabrics）とRDMA（Remote Direct Memory Access）はネットワークレイテンシを短縮することによって、このデータ配置の必要性を幾分変えつつあり、距離のレイテンシの影響を一定程度まで小さくしている。

とにかく、コンピュートを保存されたデータの近くに置くことによって両方が短縮する。Hadoop Job Trackerによって効果を上げているのと同じ原理が、Slurm Workload ManagerのようなHPCのジョブスケジューラーでも使われている。オープンソースのSlurmは、最高のパフォーマンスを得るために、最もデータに近く、最もリソースを備えた、一つまたは複数のノード上のジョブのスケジュールを巧みに組む。ラックスケールの新しい共有フラッシュストレージは、これをもっと単純化してくれる。追加されるのは、NVMe-oFによる5～10マイクロ秒の範囲のわずかなレイテンシだけだ。

OracleデータベースやSAP HANAなど、いくつかのSQLリレーショナルデータベースは、全てのデータをメモリ内で処理するバージョンを持っている。このユースケースでは、DRAM(ダイナミックRAM)の低レイテンシ、高パフォーマンスと、データをコンピュートに限りなく近接させることによる低レイテンシを利用して、データベースのパフォーマンスを大幅に改善している。とはいえ、このソリューションは高価なので、利用はI/Oパフォーマンス要求が最も厳しいアプリケーションに限られている。

また、コンピューㇳをデータの近くに移動させることによって、一部の高パフォーマンス・ストレージアーキテクチャーは、大幅な基盤パフォーマンスの増加を得ることができる。ストレージソフトウェアのサービスは一般的に、CPUとメモリへの依存度が高い。コンピュートをデータの近くに移動させることにより、ストレージコントローラーから多くの処理負荷を軽減し、リード・ライトに専念させることができる。SSDのニアラインコプロセッサーが、冗長でパフォーマンスを低下させるタスクをストレージコントローラーのCPUから肩代わりする発想もこれだ。（訳註：ScaleFluxやNGDなどの新興ベンダーがコントローラ付きのSSDを出している。）とはいえ、この方法は、必ずしもストレージのパフォーマンスを改善するとは限らない。コストが嵩んでパフォーマンスが低下することもある

データをコンピュートに移動するケース

データをコンピュートに移動するということは、一般的に基盤パフォーマンスが主要な関心事ではないということだ。主要な関心事は、コスト、セキュリティ、便利さ、簡単さ、といったところだ。

協業を例にとってみよう。協業の相手が、異なる組織、別会社、離れた地域に属し、違うアプリケーションを使っている場合、コンピュートをデータへと移動するのはほぼ不可能だ。正式に認可されていないアプリケーションを実装するために、自社のシステムにセキュリティを潜り抜けて外部からアクセスしてくるのを許す企業はほとんどないだろう。そのため、異企業間のワークフロー連携は、一般的にデータをコンピュートへ移動することになる。協業アプリケーションは数多く出ている。Box、Atlassian Confluence、Dropbox、Google Drive、Atlassian Jira、Microsoft Onedriveなどだ。これらはみな、データをコンピュートに移動して使われるものだ。

クラウドバースティングは、かつてはオンプレミスの資産が使えない場合に、クラウド・コンピュートの伸縮自在な拡張性を活用するためのものだったが、もうひとつのユースケースが、データをコンピュートに移動しなければならない場合だ。このシナリオではデータはコピーされ、クラウドに送られ、アプリケーション付きのクラウド・コンピュートがスピンアップし、データが処理される。次に、結果がオンプレミスに移行され、クラウドデータ・コピーは削除、クラウドインスタンスはスピンダウンされる。予想外の要求、あるいは一時的、季節的な要求のために、オンプレミスのコンピュートが一時的に不足する場合、このユースケースは費用対効果が高い。

解析は前段で説明した、コンピュートをデータに移動するユースケースだ。しかし、時としてデータがコンピュートに移動しなければならない場合は、解析も同様のユースケースになる。解析エンジンは、データを解析するためにデータを読まなければならない。そのためによくあるのが、解析を効率的に行うために、データを解析エンジンの方に移動するケースだ。

SparkはHadoop用解析エンジンで、最高のパフォーマンスを得るために、データは複数のHadoop分散ファイルシステム（HDFS）ノード上になければならない。そして、これらの常駐しているファイルやオブジェクトデータをHDFSのように見せるファイルシステムやオブジェクトストレージシステムは存在するが、必ずしも適切なパフォーマンスを提供してくれるわけではない。つまり、データをHadoopストレージに移動しなければならない、ということだ。Apache Cassandra、 Couchbase、DataStax、Apache HBase、MemcacheDB、MongoDB、Neo4J、SAP OrientDB、 RedisなどのNoSQLデータベースは、一般的にデータを自分たちの方へ移動することを要求する。

アグリケーション（集約）はデータをコンピュートに移動するもうひとつのユースケースで、この良い例がIoTだ。何千、何百万、何十億個のデバイスが生成したデータはリアルタイム解析と長期間バッチ処理による調査のために集約される。AIOps（Artificial intelligence for IT Operations：IT運用のためのAI）はこの機械データ集約とリアルタイム解析の一例だ。AIOpsは、BMC Software、Correlsence、Corvil、Hewlett Packard Enterprise、IBM、ITRS Group、Moogsoft、SAP、Splunk、StrongBox Data Solutionsなど多くのベンダーが製品を出している。

マルチノード分散ストレージシステムも、データをコンピュートに移動するのが合理的なユースケースだ。いくつかの分散ストレージシステムが常に異なるストレージノード間でバランスをとり、保存されたデータを移動してパフォーマンスの最適化を確保する。

ということで答えは？

基盤パフォーマンスを改善し、時間を節約するためにコンピュートをデータに移動するか、データをコンピュートに移動するかは、個々のケースによって変わってくる。絶対これ、というものはないし、いくつかの事例ではユースケースの異なる局面で両方が適用されることもある。

最後に、「データまたはコンピュートを移動することは合理的か」という質問に対する答えだが、パフォーマンス、機能性、コスト、実現性、使い勝手に対するアプリケーションの要件のバランスを取りながら行う事が大事、というところに落ち着く。

著者略歴：Marc StaimerはDragon Slayerコンサルティングの社長兼CDS