時間は元に戻せないリソースだ。ひたすら前に進み続け、いったん消費したら取り返すことも巻き戻すこともできない。出来事や瞬間は、時間という概念で区別される。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の例は、システムをデータに近づけることに合理性がある一つの明確なユースケースにすぎない。システムとデータとの間の帯域幅が十分でない場合もこうした例の一つだ。だがシステムの方を移動するのが不可能なほどコストが高かったり、複雑化が進んでしまったりする状況もあるだろう。ワークフロー、コラボレーション、セキュリティ、インフラなどの観点から、データを移動する方が現実的な状況もある。
システムとデータのどちらを移動して双方の距離を縮めるかを、シナリオを細分化して考えてみる。そして、どちらを移動するのが合理的か、状況をはっきりさせてみよう。
新型コロナウイルスの感染拡大で注目される「巣ごもり消費」に関する意識――カンム調査
外出控えムードの中、消費意欲は「自宅でのエンタメ」に向かっているようです。
オンライン医療が進む中国と台湾、日本 iOS「メディカル」アプリ最新人気ランキング
今回は、2020年2月度における中国、台湾、日本市場におけるiOS「メディカル」モバイルア...
SDGsへの取り組みが最も高く評価された企業はトヨタ自動車――ブランド総合研究所調査
国内の主力企業のSDGsへの取り組みやESG活動に対して1万500人に聞いています。
ITmediaはアイティメディア株式会社の登録商標です。
