今後のAsakusaの方向性	

NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

Agenda	n
n
n
n
n
n

NAUTILUS	  1.現状認識	  2.日本市場	  3.Hadoop/Spark	  4.新しいアーキテクチャ	  5.Asakusaの方向性	  6.	  New	  Engine	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

2	  1.現状認識	n

ビックデータ・IoT	  – なかなかビジネスになっていない	  n 少なくとも何兆円というマーケットに残念ながらなっていない	– ビックデータ	  n 結局は従来からのCRMとあまり変わっていない	  – MLにしても、もともとある手法の延長ではある	  n よって、取れるビジネスメリットも変わらない	  n ほとんどの案件が既存DWHのリプレース案件	  – ベンダー的にはレッドオーシャン	  – 一足飛びにAIという話になっているが、そもそも機械学習とAIはかなり異なる	  – IoT	  n 最終イメージまでできていないとなかなか大規模な投資にはならない。	  
n PoC案件が多い	  n まだまだ手探りの状態	  n Internetではなく、Intranetであることが多い	

NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

3	  1.現状認識	n

ビックデータは既存延長・IoTはPoCフェーズ	  – したがって、システムとしては大規模にはなりにくい	  – システム的な付加価値がそのままユーザの売上になりにくい	  nユーザーのスタンス	  – ユーザーサイドは大きな金額を突っ込める状況ではない。	  
– 「小さく・中規模で」・「お金をかけずに」	  – むしろ既存システムの更新処理の方に時間と人をさかないといけない状況	  – 既存DWHリプレースにしても、線形でのデータ増加であり、級数的に増えているわけではない	  n 勿論例外はある	  n上記を客観的に見ていく必要がある	  – 近年はIT系マスコミと実際のビジネスの乖離が酷いので正確な状況がつかめない	  NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

4	  2.日本市場	n

小規模・中規模が圧倒的多数	
– 弊社の実績	  – 結果として、投資総額が低い	
– クラスターノード数も10-­‐20ノードのサイズ件数として非常に多い	  – 特にエンタープライズ	  – 確かに大きなクラスターもあるが、数十Pクラスで、しかも運用的には大きなクラスターにして、割となんでも入れてしまうゴミ箱状態。	  
n そもそも業務別にある程度クラスターをクラスター化した方がいいぐらい		
つまり、日本市場では「金額を押さえつつ＝ノードを大規模せずに、	  ITでのレバレッジをどう効かすか？」を考えないといけない	  n

– 実際のユーザニーズや実態はこのポイントにある	

NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential5	  2.日本市場：どういうことかというと	サイト辺り	  データ総量	
PByte	

企業数は非常に少ない	

企業数は非常に多い	

左側は企業数は非常に多いが、企業あたりのデータ少ない	  
右側は企業数は非常に少ないが、企業あたりのデータは巨大	

GByte	
ノード数	  10ノード以下	

100~500ノード	

1000ノード以上	

日本は圧倒的に左側で、例外的にごく一部が右側	
NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

6	  3.Hadoop/Spark	n

Hadoop/Spark	  – まず、分散並列処理基盤としてきわめて優秀	  – 汎用機・大規模SQLバッチよりは、非常に高速に動くことがはっきりした	  nデータ集積の基盤としてはどうか？	  
– データ集積という視点では、そもそも想定しているユースケースが、日本市場に合わない。	  
– というよりもそもそも見ているマーケットサイズ・ユーザー規模が違う。	  
n データ集積という意味では、結果として日本のマーケットでは、効率の悪い仕組みになっている	

NAUTILUS	  nそもそも多数のノードをどう統括するか？という視点が強い。少数・中規模のノードをどう効率化するか？という視点は薄い。	  

n

他に代替がないので使っているという感じであり、ベストではない	
Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

7	  3.Hadoop/Spark	n

課題	  – 100ノード以上のクラスターが主要ターゲット	  – 何が問題なのか？	  
– 故障・障害の実際発生率の違い	  n大規模クラスター	  – 1000ノードの場合、0.1%の障害発生は、常に1ノードは壊れていることを想定しないといけない	  – サーバが壊れるのは普通の状態	  n 「常にサーバが一つは壊れている」	  – 障害対策と復旧に特段の仕組みが必要	  n 自動化しないととても無理	  n中規模・小規模クラスター	  – 10ノードのケースでは、	  0.1%の障害発生は、顕在化しない	  – サーバが壊れるのは異常事態	  n 障害対策はとりあえず止めて、復旧は手作業	  n 手動で間に合う（・・・まぁセンスはないが、現実はコレで十分）	  NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

8	  3.Hadoop/Spark	n

障害対策・復旧のアーキテクチャがそもそも論	  – Hadoop/Sparkに限らず、一般に分散クラスターでは、障害・復旧の仕組みは非常に難易度が高い	  – 常に何かあるので、その前提でノンストップにしなければならない	  n 何かあったら系全体がストップでは、事実上まったく動かない	  – 結果、往々にして以下のトレードオフが発生する	  – 1.アーキテクチャに制約が加わる	  n 複雑な処理は復旧が困難なんでなるべく簡単にする	  n 例）バリアーいれまくり	  – 2.オーバーヘッドを許容する	  n 余分にデータを持つ	  n 例）データ書きまくり・レプケーションとりまくり	  – 1+2→要するに「処理が遅くなる」	  NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

9	  3.Hadoop/Spark	n

結局、何が問題なのか？	  
– クラスター規模に合わせた、障害対策・復旧のアーキテクチャを選択できない	  – 本来はトレードオフなので、合わせて調整したい	

小規模	  
小回り優先	

大規模規模：	  ノンストップ優先	

日本市場はどっちかというと左より	強い障害対策不要	  レイテンシー優先	

強い障害対策必要	  トータルのスループット
要求	

規模に合わせて調整したいが・・・・できない	  実際は選択の余地がなく、右よりになっている	

NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

10	  4.新しいアーキテクチャ	n

トレンド：「ムーアの法則」の終了	  – ハードウェア開発はムーアの法則が限界に来ている	– メニーコア化	  nコア自体は微細化は限界ので、コア数を増やす	  – 周辺の強化	  特にメモリー周り	  n コアと使い切るようにメモリーバスを強化	  n IOスピードを上げる	  n ストレージのIOコストを減らす	  nnこれは、結果として複数のサーバノードを集めてひとつのノードにする、という方向に倒れつつある。	  
– インターコネクトの強化やメッシュ状のコア連携といった方向		
n「サーバクラスターの凝縮化（condensa3on）」	
– RSA(Intel)	   TheMachine(HP)	   Firebox(AMPLab)		
NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

11	  4.新しいアーキテクチャ	n

RSA	  – Intelの次世代アーキテクチャ	  – ラックスケール・アーキテクチャ	  n ラックのバックプレーンを共有化	  n 高速のインターコネクトを利用	  n RDMAをSoCで実装	  n NVMをDIMMソケットで連結	  – 1000コアが普通に透過的に利用可能	  – メモリーは基本的に共有化されて、普通に10数Tbyte	  – たかだか10~20台のサーバで構成される	  NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

12	  4.新しいアーキテクチャ	nRSA	  – マーケット：日本市場に「合う」	  n データザイズが、RSAにはまる大きさ	  – すでに事実上の先行ベンチマークが行われている	  – 「日本市場でのOracleEXAデータのバカ売れ」	  n 非常に高価にもかかわらず、日本「だけ」で馬鹿売れ	  n RSAとほぼおなじ構成かつサイズ・規模がまったく同じ	  – 超高速で、OracleEXAの100分１の価格で、同じようなものが出たらどうしますか？	  
n 普通に買うと思います	  n HadoopとかSparkとか買います？	  

– なので、Asakusaはこの辺を狙っていきます。	

NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

13	  5.Asakusaの方向性	nn

現状を踏まえる	  「金額を押さえつつ＝ノードを大規模せずに、ITでのレバレッジをどう効かすか？」に注力していく		n

先の対応はRSAになるが、まずは最初に1node	  startをベースにして、新しいアーキテクチャに対応して行く。		

n

すなわち、メニーコアに特化した仕組みを出していく。	  
これは高いスループットと低遅延要求を満たす方向を目指す。	  
Hadoop・Sparkが背負っている「100ノード前提」を排除して、身軽にすることでスピードを上げる	  かつAsakusaDSLの互換性は100%維持	  n

α版をすでにFixstars社と協同で開発中	

nn
n

NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

14	  6.New	  engine	n

Asakusaの新しい実行エンジン	  – C++実装	  – パフォーマンス重視	  n Spark・Hadoopの余計な部分は全部除去	  n 純粋に速さに特化	  n コア性能・メモリー性能を「物理的に使い切る」ことが目標	  n 理論的には世界最速	  n試験的なパフォーマンスでSparkの5-­‐10倍の速度	  – 現行のバッチ処理で言うと・・・	  n ヘビーSQL：8時間	  n Hadoop：20分	  n Spark:5分	  n C++：1分以下	  – 8時間のバッチ処理が1分を切るレンジまで来ている	  n 別に驚くことでなくて、メニーコアとバスを限界まで使えば本来、この位のアウトパフォーマンスは出るはず	  NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

15	  6.New	  engine	n

まずは1-­‐nodeスタート	  – したがってデータサイズはメモリーに乗るレベル	  – 近い将来RSAに対応	  n 結果として広いメモリー空間が利用可能	  n 日本のエンプラで十分な規模	  n1-­‐nodeのメリット	  – 導入が非常に簡単。一台でよい。（ただしメニーコアが前提）	
– スタートは最少投資でよい。	  
– 各エッジでのプリプロセッサーとして利用可能	
– 工場・拠点・各センターで処理をしてから、IDCに送る	
– IoT的なことをやるときにも、通信費・IDCのコスト削減することができる。		

NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

16	  6.New	  engine	n

投資可搬性の確保	  – 実行エンジンが複数選択可能	  – その上で、Asakusaで書いたアプリケーションはすべて実行可能	  – データがPクラスまで来て、サーバ台数が必要になった場合	  n そのままHadoop・Sparkに移行可能	  n アプリケーションは変更なし	  n テストもそのまま持って行ける	小規模	  小回り優先	

大規模規模：	  ノンストップ優先	

規模はさまざまになる	
強い障害対策不要	  レイテンシー優先	

強い障害対策必要	  トータルのスループッ
ト要求	

数ある分散環境のなかで、Asakusa「だけ」が選択が可能	

NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

17	  6.New	  engine	n

リリーススケジュール	– 12月内部α	– 2016/4 OSSとしてリリース（予定）	  – 詳細は担当営業に聞いてください！	

NAUTILUS	  Copyright	  ©	  2014	  Nau3lus	  Technologies,	  Inc.	  All	  rights	  reserved.	  
Proprietary & Confidential

18