優れたアプリケーションパフォーマンスに対する欲求は尽きない。遅延を減らすためには、データの方をシステムに近づけるか、システムの方をデータに近づけるか、どちらが適切なのだろう。
時間は元に戻せないリソースだ。ひたすら前に進み続け、いったん消費したら取り返すことも巻き戻すこともできない。出来事や瞬間は、時間という概念で区別される。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の例は、システムをデータに近づけることに合理性がある一つの明確なユースケースにすぎない。システムとデータとの間の帯域幅が十分でない場合もこうした例の一つだ。だがシステムの方を移動するのが不可能なほどコストが高かったり、複雑化が進んでしまったりする状況もあるだろう。ワークフロー、コラボレーション、セキュリティ、インフラなどの観点から、データを移動する方が現実的な状況もある。
システムとデータのどちらを移動して双方の距離を縮めるかを、シナリオを細分化して考えてみる。そして、どちらを移動するのが合理的か、状況をはっきりさせてみよう。
ジェンダーレス消費の実態 男性向けメイクアップ需要が伸長
男性の間で美容に関する意識が高まりを見せています。カタリナ マーケティング ジャパン...
イーロン・マスク氏がユーザーに問いかけた「Vine復活」は良いアイデアか？
イーロン・マスク氏は自身のXアカウントで、ショート動画サービス「Vine」を復活させるべ...
ドコモとサイバーエージェントの共同出資会社がCookie非依存のターゲティング広告配信手法を開発
Prism Partnerは、NTTドコモが提供するファーストパーティデータの活用により、ドコモオ...
ITmediaはアイティメディア株式会社の登録商標です。
