データ・セントリック時代のIT技術２ －近代データ工学５原則－

[Yoji_Inoue]

以前のブログでデータグラビティ（データ重力）の話をしましたが、今回はデータにまつわる5つの原則とそれぞれの対立する矛盾点、それらのトレードオフをいかに克服するかについていくつかの事例をもとに解説したいと思います。

近代データ工学５原則

以前のブログでも紹介しましたが、データにはグラビティ（重力）があります。つまりデータは重いので「できるだけ移動は避ける」、むしろ「アプリケーションやサービスをデータの近くに持ってくる」（Bring the cloud to your data）ことが重要だという話をしました。とはいえ近年はクラウドファースト時代です。特に今主流のハイブリッドクラウドでは、データの移動が必要なケースも出てくるため様々な問題点が出てきます。そのような問題点を避けるために、データを取り扱ううえで重要な5つの原則を紹介し、どの状況だとどの原則を優先したほうが良いのか、いくつかの事例をもとに解説したいと思います。

まずはデータ工学の５原則について解説してみます。

原則１：より多種類のデータソースを扱えるようにする

　近年のクラウド・モバイル・IoTの普及により、従来の構造化データに比べて非構造化データの比率が年々高まっています。さらに言うならAIやIoTデータの活用が進む現代では非構造化データである音声、画像、動画、センサーデータ等の相互関連付けが重要になるため、それらを別々にアクセスするよりは同じように扱えるデータプラットフォームが望ましいといえます。

原則２：データはできるだけ統合しサイロ化しない

　ビジネスのグローバル化、上述のようなより多くのデータの活用を鑑みると、グローバルレベルでデータを管理、読み書きできるプラットフォームが求められてくるでしょう。私はこれをグローバルデータメッシュと呼んでいますが、これを本当に実現するにはデータグラビティの問題を解決する必要があります。地球の裏側からでも大量のデータをアクセスできて、即座に読み込めるシステムの実現には高額な回線料金を払うか、高温超電導のような長距離のデータ移動をロスなく高速に送受信できる次世代通信技術が必要です。カーボンナノチューブ、シリコンフォトニクスなど研究は進んでいますが、まだまだ広く普及するには時間がかかりそうです。違うアプローチとしては、データを一か所に保存するのではなく世界中に広く分散しておいて、最も近いところからそれぞれのデータのパーツを読み出し、パズルのピースのように組み上げる手法もあり得ます。データの完全性、真正性はブロックチェーンのような技術を使って保証することも可能でしょう。

原則３：レイテンシはできるだけ小さくする

　これは前回のブログで説明したデータグラビティの考え方と同じです。重力の影響を大きく受けるデータとアプリケーション間のレイテンシはできるだけ小さいほうが良いのは当然です。そのためにアプリをデータの近くに置く、またはデータを高速に移動できる手段を利用する、といった対応策が考えられます。例えばエッジコンピュータなどは前者の考え方で、いわばデータの地産地消です。応用例の一つとしては自動車の衝突防止技術への応用があります。数ミリ秒レベルで状況を判断し即座にアクションを起こさなければいけないため、レイテンシが非常に重要になります。実際GPUを標準搭載した欧州車もあるくらいです。

原則４：データ資産に関する知見は多いほうが良い

　今最も注目されている職業の一つ、データサイエンティストなどはこの知見が必要でしょう。最適な予測モデルを作るのには質の良い大量のデータが必要になります。公開されているオープンデータだけではなく、より価値の高い非公開のデータが企業内にあったりしますが、それらは結局サイロ化していて、そのデータが何を意味するのか理解するのも一苦労だったりします。このような公開されていない隠れた価値のあるデータのことをダークデータと呼びますが、これらから価値を見出すにはデータの知見が必要というわけです。

原則５：一つのデータ構造で多様なデータ消費パターンをカバーするのは困難

　ストレージの種類として主に分類されるのが、ブロック、ファイル、オブジェクトストレージです。それぞれが用途別に最適化されているため、一つのシステムですべての用途をカバーすることは結構困難です。データにはグラビティがあり、それを移動するには様々なモビリティの手段があります。これはいうなれば物理的にグラビティのある人や荷物を運ぶ輸送手段と同じで、低コストで大量のものを運ぶのであればタンカーやコンテナ船が向いていますし、できるだけ早く輸送したいのであればコストは高いですが航空便を使うことになります。ストレージもそれと同じように最適化された様々なストレージシステムがあります。例えば前述のタンカーはオブジェクトストレージ、航空機はブロックストレージやインメモリーになるでしょう。このように最適なストレージ技術を上手に組み合わせて使い、管理を一元化またはAIのようなもので自動化することになるでしょう。

ケーススタディ

上記の5つの原則をすべて同時に達成するのは困難です。ではその優先順位を決めたり、何を妥協するべきなのでしょうか？　今回は実際にあったハイブリッドクラウドモデルの事例をいくつか使い解説してみたいと思います。

ユースケース１：　金融事業者A　ハイブリッドクラウド
　従来はデータもアプリもオンプレだったのが昨今のクラウドファースト戦略によりユーザー向けアプリはクラウドで運用することになりました。その場合データはどこに置くのが良いのでしょうか？　
　まずデータグラビティを考慮した場合アプリデータはクラウド側に置くのが適切と考えられます。ところが一方でそのデータベースはオンプレのアプリケーションでも使用されているため、最終的にオンプレ側に置くほうが優先されました。そうなると「アプリの近くにデータを置く」という原則３に矛盾してしまいます。結果としてそのデータベースの複製をクラウドに置き、低帯域ネットワークを介して、クラウド―オンプレ間で同期をする結果となりました。ここではデータの同期にかかる時間に関してはトレードオフとして、ある程度の犠牲を覚悟しなければなりません。

ユースケース２：企業B　DRのためのストレージコストと管理コストの増加に苦しんでいる
　このユーザーは最終的にDRデータをクラウドに置くことにしました。一方バックアップソフトはオンプレにあります。このパターンに問題点はないでしょうか？　この場合は一見原則３（レイテンシを小さくする）に違反しているように思えますが、オンプレとクラウドのデータが独立して利用されるため問題はないといえます。

ユースケース３：企業C　RDBMSのクラウド移行を考えている
　企業CはオンプレのRDBMSをクラウドに移行したいと考えています。この場合は問題ないでしょうか？　複雑に絡み合ったオンプレのデータベースを丸ごと一度にクラウドに移行するのはお勧めできません。もちろんDB全体を生涯にわたりオンプレとクラウドに二重に持つという選択肢もありますがコスト的にも現実味がありません。しかしながら、いくつかの代替え手段もあります。

　可能性のある方法としては、クラウドに移行したアプリに関係するDBだけをクラウド移行し、継続してバックグラウンドでデータ同期することでしょう。そうすることによって、クラウド側アプリのレイテンシの問題は解決しますし二重に持つストレージコストも削減できます。別の手法は、あくまでも条件が合うことが必要ですが、完全にある特定の論理データをクラウド側に移行することです。その場合オンプレミスからのアクセスは高レイテンシとなりますが、それでも運用に影響がない場合は有効な手法です。

このC社の例は多くの企業にとって、ハイブリッドクラウドを実現するうえで避けては通れない課題でしょう。とりわけ成熟した企業にとって、上記5つの原則を同時に実現するデータプラットフォームを構築することは極めて困難です。とうことで、今までの事例から浮かびあがってくるハイブリッドクラウドでのデータプラットフォーム構成時の注意点をシンプルに2つにまとめてみます。

ハイブリッドクラウド化でデータプラットフォーム設計をする際のガイドライン

1. データプラットフォームシステムは、各企業個別にデータ原則のバランス設定が必要である

2. データプラットフォームの最適化を行う際に注目すべき重要な要素はデータグラビティとレイテンシである

この2つのガイドラインを念頭に置いて、ハイブリッドクラウドのデータプラットフォームデザインをしてみてはいかがでしょうか？

関連記事

データ・セントリック時代のIT技術　－AI/GPU編ー