時間は元に戻せないリソースだ。ひたすら前に進み続け、いったん消費したら取り返すことも巻き戻すこともできない。出来事や瞬間は、時間という概念で区別される。IT運用に関して言えば、常に時間が足りず誰もが時間を必要としている。毎秒すべきことがあるというプレッシャーは絶えることがない。
ハイパフォーマンスコンピューティング（HPC）またはスーパーコンピュータと呼ばれる分野では、実行する計算の数、つまり1秒当たりの浮動小数点演算の回数（FLOPS：Floating point number Operations Per Second）を向上させることを常に追求している。本稿執筆時点の2018年10月における測定値は数十〜数百ペタFLOPS単位で、その1000倍高速なエクサFLOPSが次の目標になっている。
ストレージにも同様のプレッシャーが掛かっているのは明らかだ。ストレージインフラのパフォーマンスはIOPSと1秒当たりのスループットで計測され、毎秒MB、GBから毎秒TBに移っている。
1秒当たりのインフラパフォーマンスを向上させたいという果てなき欲求が背景にあることを前提にした場合、次の疑問が浮かび上がる。データとシステムの距離を近づけるとしたら、どちらをもう片方に近づけるのが合理的なのだろう。
「システムをデータに近づける方が合理的だ」というのが一般的な見解であり、よくあるユースケースは実際その通りだ。たいていの場合簡単かつ高速になるのは、実行可能ファイルの方が入力データと比べ、ネットワーク間でやり取りするデータの割合が大幅に少ないためだ。データの移動にはネットワーク帯域幅、時間、そして熟練者の手作業が必要になる。手作業の必要がないというだけでも、IT管理者はシステムをデータに近づける方法を選ぶだろう。
こうした好例がApache Software Foundationのデータフレームワーク「Hadoop」だ。タスク管理ツール「Hadoop JobTracker」では、個別のタスク実行スケジュールを、必要なデータが存在するコンピューティングノードで設定できる。コンピューティングノードでジョブが設定できない場合は、同じラック内にあるコンピューティングノードにそのジョブの実行スケジュールを設定する。そのノードも利用できなければ、グリッドの他のノードにジョブの実行スケジュールを移す。Hadoop JobTrackerのスケジューリングアルゴリズムを支えているのは、入力データをコンピューティングノードに移動するのは時間がかかり過ぎるという考え方だ。データを移動することでジョブの遅延が増え、応答時間が長くなってしまう。
Hadoopの例は、システムをデータに近づけることに合理性がある一つの明確なユースケースにすぎない。システムとデータとの間の帯域幅が十分でない場合もこうした例の一つだ。だがシステムの方を移動するのが不可能なほどコストが高かったり、複雑化が進んでしまったりする状況もあるだろう。ワークフロー、コラボレーション、セキュリティ、インフラなどの観点から、データを移動する方が現実的な状況もある。
システムとデータのどちらを移動して双方の距離を縮めるかを、シナリオを細分化して考えてみる。そして、どちらを移動するのが合理的か、状況をはっきりさせてみよう。
ITツールの利用効果に対する実感に世代間ギャップ――Dropbox Japan調査
国内企業における創造性とITツール利用に関する実態調査です。
エードット×BIRDMAN デジタルクリエイティブ界の強力タッグが目指す「広告のいらない世界」
プロデュースカンパニーとして急成長中のエードットが総合クリエイティブプロダクション...
10代女子に聞いたお年玉の使い道、「貯金」「推し活」が上位に――バイドゥ調べ
イマドキの女子はもらったお年玉をどう使っているのでしょうか。
ITmediaはアイティメディア株式会社の登録商標です。
