Hadoop JobTrackerの例で示したように、通常はデータを移動するよりもシステムを移動する方が単純かつ高速になる。往々にして、システムとデータが近いほどインフラパフォーマンスは向上する。距離が短くなるほど処理結果は即座にもたらされる。通信の遅延はインフラのパフォーマンスを低下させ、光の速度に影響を受ける。

　光の速度と距離が遅延の問題の原因であることは今後も変わらないだろう。ワームホールなどのタイムワープできる技術が発明されれば話は別だが、近い将来実現することはない。遅延が時間当たりのパフォーマンスのボトルネックになっているならば、距離と遅延を減らせば毎秒のパフォーマンスは向上する。だがボトルネックがCPU、メモリ、ソフトウェア、ストレージインフラならば、改善手段は限られる。

　システムをデータに近づけ、その距離を縮めることで最も大きなメリットを得るのは、遅延の影響を受ける可能性が高いアプリケーションだ。頻繁に取引をするなど大量のトランザクションを扱うアプリケーションがその例に当たる。こうした金融分野ではマイクロ秒が数百万ドルに相当するためだ。大量のトランザクションが発生するような、距離を近づけることでメリットが得られるアプリケーションとしてはHPC、オンライントランザクション処理、電子商取引、オンラインゲームなどがある。このようなアプリケーションではいずれも、システムをデータに近づけて遅延を削減するのが有効だ。

大量の送受データ

　システムをデータに近づける価値は、ワイドエリアネットワーク（WAN）経由で送受するデータが大量にある場合に極めて明白になる。クラウドストレージに1P（ペタ）Bのデータがあり、ネットワーク経由でこのデータをオンプレミスに移さなければならないような状況がその例だ。アプライアンスやクラウドストレージゲートウェイがこのような仕組みで動作する。これらはデータの読み取り、処理、変更をするために、クラウドに移動したデータをいったんストレージに移し、元の状態に戻す必要がある。

　帯域幅の理論性能が125Mbpsだとすると、1PBのデータの取得には非常に長い時間がかかる。TCP/IPではその理論性能は実現できないだろう。仮に実現するとしても、その回線で1PBを目的地まで送信するには93日以上掛かることになる。もっと現実的に考えれば、スループットの最高値は理論値の30％程度にとどまるだろう。そうなれば、移動時間は約309日、つまり10カ月間以上にまで延びる。お世辞にも適切な時間とは言えない。WAN最適化ツールを使用しても、必要な期間はせいぜい90日から300日の範囲内に落ち着く程度だ。やはり時間がかかり過ぎる。

　こうしたシナリオでは、システムをデータに近づけると、必要な時間が大幅に短縮できる。これにより、アプリケーションを含むシステムのインスタンスをクラウドで稼働し、クラウドに保存されたデータを処理する、というプロセスを踏むことになる。処理が完了したらインスタンスは破棄されるため、使用した分以上に課金されることはない。データ処理はオンプレミスのデータがHadoop JobTrackerに移動するのを待つよりもはるかに迅速だ。クラウドストレージから取り出す際の多額のコストも節約できる。

並列処理システム

　システムをデータに近づけることでメリットを得られるアプリケーションの種類はもう一つある。HPCエコシステムで使用されている並列入出力（I/O）だ。この場合、HPCは並列ファイルシステムを利用して大量のデータを並列処理する。こうした並列ファイルシステムには「Lustre」「Panasas」「Quobyte」「IBM Spectrum Scale」（旧「General Parallel File System」）「WekaIO」などがある。並列ファイルシステムのレイテンシ要件を満たすには、通常HPCの各ノードにある内蔵ストレージにデータを配置する必要がある。それによって、遅延の原因になる距離を縮められる。SSDストレージのプロトコル「NVMe over Fabrics」（NVMe-oF）やリモートダイレクトメモリアクセス（RDMA）により、こうした要件は変わってきている。ネットワーク遅延が減少し、距離による遅延の影響もある程度抑えられるためだ。

　格納されたデータに比較的近い場所にシステムを配置すれば、ネットワーク遅延と距離による遅延の両方が削減される。この原理はHadoop JobTrackerや「Slurm Workload Manager」などのHPCジョブスケジューラーでも利用されている。Slurm Workload Managerはオープンソースのスケジューラーだ。利用可能なリソースが豊富で、最もデータから近いノードに各ジョブを巧みにスケジューリングし、パフォーマンスを最大限に引き出す。新しい共有ラックスケールフラッシュストレージではジョブのスケジューリングが単純化され、増える遅延は5～10マイクロ秒とごくわずかだ。

リレーショナルデータベース

　リレーショナルデータベースのうち「Oracle Database」や「SAP HANA」などは、処理対象の全データをメモリ内に保持するバージョンを用意している。こうしたユースケースでは、低遅延かつ高パフォーマンスのDRAM（Dynamic Random Access Memory）を利用できることに加え、システムに極めて近づけることで遅延が減少するという両方のアプローチが生かされる。その結果、データベースパフォーマンスが大幅に向上する。ただしコストが高いため、最もI/Oパフォーマンスの要求レベルが高いアプリケーションに限って使用すべきだ。

ハイパフォーマンスストレージ

　システムをデータに近づけると、パフォーマンスが高い一部のストレージアーキテクチャで処理速度が大幅に短縮される可能性もある。一般的に、ストレージソフトウェアサービスではCPUとメモリの負荷が高くなる。システムをデータに近づけることで、ストレージコントローラーからプロセスをオフロードでき、それによって読み書きに余裕が生まれる。このような考え方が、SSDのニアライン（オンラインとオフラインの中間）コントローラーによる共同処理を支えている。こうしたコントローラーは、パフォーマンスを下げる冗長タスクをメインストレージコントローラーのCPUからオフロードする。しかしこの操作によって必ずしもストレージパフォーマンスが改善するわけではなく、コストが増加しパフォーマンスが低下してしまう恐れもある。

データを移動する方がよい場合

　データをシステムに近づけることは通常、インフラのパフォーマンスが最も重要な懸念事項ではないことを意味する。この場合の主な懸念事項は、コスト、セキュリティ、便利さ、単純さである可能性が高い。

共同作業

　ユースケースとして共同作業を考える。共同作業者がそれぞれ属する組織、企業、地域がさまざまで、使用するアプリケーションが異なる場合、システムをデータに近づけることはほぼ不可能だ。セキュリティ対策を破って自社のシステムにアクセスし、承認されていないアプリケーションを導入することを、社外の共同作業者に許可する企業はほとんどないだろう。そのため、異なる企業間の共同作業におけるワークフローでは一般に、データをシステムに近づけざるを得ない。共同作業用のアプリケーションの例としては「Box」「Confluence」「Jira」「Dropbox」「Google Drive」「OneDrive」などがある。これらはいずれもデータをシステムに近づける。

クラウドバースト

　オンプレミスのリソースに負荷がかかって利用できなくなると、クラウドリソースに作業が自動で割り振られるクラウドバーストも、データをシステムに近づける必要のあるユースケースの一つだ。クラウドバーストは、クラウドコンピューティングの伸縮性を生かすために利用される。オンプレミスのリソースにかかる負荷が増すと、アプリケーションはデータをコピーしてクラウドに送り込む。そのクラウドで、アプリケーションを含むクラウドコンピューティングインスタンスを稼働し、データを処理する。その後、結果をオンプレミスに戻し、クラウドのデータコピーを削除してから、クラウドインスタンスを破棄する。これは、予期しない一時的な需要や季節ごとの需要によってオンプレミスコンピューティングが一時的に不足する場合のユースケースで、コスト効率に優れている。

データ分析

　分析は、システムをデータに近づけるユースケースに当たる。一方でデータを頻繁にシステムへ近づけなければならないユースケースでもある。分析エンジンはデータを読み取って分析しなければならない。効果的な分析を実現するには、たいていの場合分析エンジンにデータを近づける必要がある。

　Apache Software Foundationの「Apache Spark」はHadoop用の分析エンジンだ。Apache Sparkで優れたパフォーマンスを実現するには、Hadoopの分散ファイルシステム「Hadoop Distributed File System」（HDFS）における複数のノードにデータを配置する必要がある。常駐ファイルやオブジェクトデータをHDFSとして表示できるファイルシステムやオブジェクトストレージシステムもある。だがこれらのファイルシステムは、常に適切なパフォーマンスを提供するとは限らない。従ってデータをHadoopストレージに移動させる操作が欠かせない。NoSQLデータベースでも、一般的にはデータの移動が必要になる。NoSQLデータベースの例としては「Apache Cassandra」「Apache HBase」「Couchbase Server」「DataStax」「MemcacheDB」「MongoDB」「Neo4j」「OrientDB」「Redis」などがある。

データ収集

　収集もまた、データをシステムに近づけるユースケースの一つだ。例えばIoT（モノのインターネット）では、数千、数百万、数十億という数のデバイスから生成されるデータを、リアルタイム分析や長期にわたるバッチ検出のために収集する。こうした機械データ収集とリアルタイム分析の一例には、「AIOps」（Artificial Intelligence for IT Operations：人工知能を使った運用）がある。AIOps製品は、BMC Software、Correlsense、Corvil、Hewlett Packard Enterprise、IBM、ITRS Group、Moogsoft、SAP、Splunk、StrongBox Data Solutionsなど、さまざまなベンダーが提供している。

分散ストレージ

　分散マルチノードストレージシステムも、データをシステムに近づける方が合理的なユースケースとなる。複数の分散ストレージシステムが、異なるストレージノード間で常に負荷を分散し、データを移動することで、パフォーマンスを最適化する。

結局どちらが適切なのか

　インフラのパフォーマンスを改善して時間を短縮するには、システムをデータに近づけるべきか、それともデータをシステムに近づけるべきか。それはユースケースに応じて異なる。絶対的なものではなく、ユースケースの異なる側面に両方が当てはまるような場合もある。結局のところ「データとシステムのどちらを移動する方が合理的か」という問いへの答えは何になるのか。パフォーマンス、機能、コスト、セキュリティ、実用性、使いやすさという観点のアプリケーション要件に対し、いかにバランスを取るかが答えとなるだろう。