HPE Blog, Japan
1824219 メンバー
3983 オンライン
109669 解決策
新規ポスト
Yoji_Inoue

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

GettyImages-926334112_800_0_72_RGB.jpgSoRからSoEへ、メインフレーム時代には特権階級の所有物であったデジタルデータは、クライアントPC時代に分散され民主化が実現しました。さらにメガクラウドの出現でデータの集中が起こりつつありますが、今後はIoTやエッジコンピューティング時代の到来で再び分散に向かうとみています。以前からデータには価値があり、次世代の通貨になるといわれ続けてきましたが、近年ディープラーニング、AI技術の革新によりデータの通貨化は現実のものになりつつあります。それを可能にしてきた立役者としてGPUの存在を否定する人はおそらくいないでしょう。しかしそのGPUにもあがなえない自然界の法則があります。それはデータには「グラビティ=重力」があるということなのです。

 

データには「グラビティ=重力」がある

Data Gravity」(データには重力がある)。このフレーズは2010年当時VMwareの社員だったDave McCrory 氏が自身のBlogに掲載した記事に由来しますが、データが爆発的に増え始めた近年では、その重要性がよりひしひしと感じられます。「Data Gravity」は簡単に言うと、データには重力があり、データが大きくなれば大きくなるほどその重力が増すため、アプリケーションやサービスがよりデータの近くに引き寄せられるという概念です。すでにHPC(High Performance Computing)の世界ではこの概念は取り入れられつつあり、HPEとしても2017年The Machine というプロトタイプで稼働を始めているMDC(Memory Driven Computer)があります。datagravity.png

データはできるだけ「移動しない」「変換しない」が鉄則

以前のブログでも書きましたが近年の一般的なコンピュータで消費される電力の70~80%はデータの移動で消費されているといわれています。もちろんデータの移動にかかる時間はデータ処理の時間に加算されるため、IOPSの低下やレイテンシの増加などにも結び付きます。せっかくプロセッサーが高性能になっても、そのほとんどのエネルギーがデータの移動に使われるのは何とも無駄な感じがしますね。そこでプロセッサーやメモリー間のデータ移動を極力少なくしようという発想が出てきます。一方アプリケーションにはそれぞれ独自データフォーマットがあります。これがサイロ化されたシステムなら問題ないのですが、複数のOSS (Open Source Software) で同じデータを何度も利用されるとなると、フォーマットの変換だけでも相当な無駄になります。例えば、国際会議で各国数名の通訳がいて話を進めると2倍以上の時間がかかりそうですが、全員が同じ言語を話せれば通訳の時間と経費が節約できます。つまりデータの変換も極力少なくすることが重要です。

 

GPUの世界でも 進むさらなるデータ処理の高速化HPE20181025006_800_0_72_RGB.jpg

データの移動と変換Copy & Convert といいます)の無駄を無くしさらなる高速化を実現するために、ITベンダー各社も新しいテクノロジーを導入してきています。例えば2016年に発表されすでに多くのベンダーが参加している新しい高速インターコネクト「Gen-Z」コンソーシアム、最近インテルを中心に主要ITベンダーにより発表された新規格「Compute Express Link」(CXL)」などがあります。一方GPUの雄NVIDIA社もRAPIDS というデータワークフロー全体の高速化を実現する技術を発表しています。このRAPIDSはエンドTOエンドのデータサイエンスと分析パイプラインをGPUだけで行うことを目的としたオープンソースソフトウェアライブラリですが、そのデータパイプラインのアーキテクチャーは2017年に発表されたGOAI (GPU Open Analytics Initiative)がベースになっています。GOAI の最初のプロジェクトは「GPU Data Frame」と呼ばれるもので、この技術を使うことによりCPUを介さずにアプリとGPU間だけでデータ移動ができるようになり、さらにカラム型インメモリデータベースであるApacheArrowにより様々なアプリのフォーマットを共通化してデータの変換を不要にしてパフォーマンスを大幅に改善することができます。

具体的には以下のように大幅にデータ移動、変換プロセスが削減できます。ここでプロセスの削減率は約半分ですが、性能としては10倍以上になることが確認されているケースもあります。

従来のGPU/Sparkプロセス

  1. HDFS Read
  2. GPU Read
  3. Query
  4. CPU Write
  5. GPU Read
  6. ETL (Extract Transfer Load)
  7. CPU Write
  8. GPU Read
  9. ML Train

RAPIDS利用

  1. Arrow Read
  2. Query
  3. ETL (Extract Transfer Load)
  4. ML Train

データの移動と変換を最小限に抑えることはシステムのパフォーマンスを上げ、同時に消費電力を低減する基本ですので、ハードウェアの選択からデータセンターやネットワーク設計、クラウド利用をも含むIT基盤全体設計に非常に役に立つ指標といえるでしょう。

 

今回はGPU周辺の「データ移動の低減技術」を紹介しましたが、実際のデータ移動はCPUやGPUの外でも多く発生しています。そこはどうなっているのでしょうか?また別の記事で紹介したいと思います。

 

関連ブログ

2020年のITはどうなる? -2-  テクノロジー編 (後編)

 

0 感謝
作者について

Yoji_Inoue

Technology Evangelist, Composable Infrastructure, Software Defined Data Center and Cloud Technology Architect, Hyper Converged, Storage, Memory centric-Data driven computing, Specialist