時間は元に戻せないリソースだ。ひたすら前に進み続け、いったん消費したら取り返すことも巻き戻すこともできない。出来事や瞬間は、時間という概念で区別される。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の例は、システムをデータに近づけることに合理性がある一つの明確なユースケースにすぎない。システムとデータとの間の帯域幅が十分でない場合もこうした例の一つだ。だがシステムの方を移動するのが不可能なほどコストが高かったり、複雑化が進んでしまったりする状況もあるだろう。ワークフロー、コラボレーション、セキュリティ、インフラなどの観点から、データを移動する方が現実的な状況もある。
システムとデータのどちらを移動して双方の距離を縮めるかを、シナリオを細分化して考えてみる。そして、どちらを移動するのが合理的か、状況をはっきりさせてみよう。
2020年上期インターネット広告市場動向と下期業種別出稿動向予測――サイバー･コミュニケーションズ調査
国内のデジタルマーケティング業界の関係者を対象にした、新型コロナ禍におけるインター...
「ダークソーシャル」はユーザーの行動にどれだけ影響するか――ホットリンク調べ
DM（ダイレクトメッセージ）をきっかけとする消費者行動の実態とは。
東京五輪を「訪日観戦したい」 中国58.4％、米国21.0％――ブレインパッド調べ
東京五輪に関して世界の2大国で意識調査。米中ともに約半数が東京五輪の開催を希望してお...
ITmediaはアイティメディア株式会社の登録商標です。
