時間は元に戻せないリソースだ。ひたすら前に進み続け、いったん消費したら取り返すことも巻き戻すこともできない。出来事や瞬間は、時間という概念で区別される。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の例は、システムをデータに近づけることに合理性がある一つの明確なユースケースにすぎない。システムとデータとの間の帯域幅が十分でない場合もこうした例の一つだ。だがシステムの方を移動するのが不可能なほどコストが高かったり、複雑化が進んでしまったりする状況もあるだろう。ワークフロー、コラボレーション、セキュリティ、インフラなどの観点から、データを移動する方が現実的な状況もある。
システムとデータのどちらを移動して双方の距離を縮めるかを、シナリオを細分化して考えてみる。そして、どちらを移動するのが合理的か、状況をはっきりさせてみよう。
インターネット広告に関するユーザー意識 8割のユーザーが情報活用に不安――JIAA調査
ユーザーのインターネットメディア・広告への意識、情報取得活用への意識、業界が取り組...
BeautyTech関連アプリは浸透しているのか？――アイスタイル調べ
BeutyTech関連アプリがこの1年で浸透し始めたことが明らかになりました。
日本国内に住む中国人女性のSNS利用実態――アライドアーキテクツ調査
在日中国人女性464人に聞いたSNSの利用状況と、SNSを通じて行われる情報提供の実態につい...
ITmediaはアイティメディア株式会社の登録商標です。
