RSA（Rack-Scale-Architecture)

一応、Asakusaのアドベントカレンダーのネタです。
いろいろ今後のAsakusaの対応について、現状を踏まえて一回まとめます。

1.ビックデータの敗北
まず、現状のビックデータの現状はちゃんと踏まえておきたい。というのは、いままでの分散処理の技術革新は、クラウド・ビックデータ関連を中心で進んできたわけで、当然次の流れはその「歴史」を考慮しなければ、ビジネス的な先はないでしょう。

まず、経験的には日本での「ビックデータ」の実行基盤としての大規模クラスターの展開はほぼ全滅に近いと思います。特に、日本ではPByteを越えるデータはその辺に転がっているものではありません。もちろん何百台・何千台ものクラスターを構成・運用しているところもありますが、おそらく十指を越える程度でしょう。日本の企業数が5万としても、99.9%の企業はそんなクラスターは持っていません。ただし、企業数が多いので結果としてのデータ総量はチリツモで相当な量にはなっていると思います。このあたりの傾向は世界的にも似たようなものかな、と思います。図にすると以下になるかと。

日本では大抵の企業は左端に位置します。そしてHadoop・Spark等の分散処理のOSSは基本的に右端の企業から出てきています。これは結果としてアーキテクチャのミスマッチが発生します。右端の大規模クラスターの仕組みは、左の小規模クラスターの運用には「いろいろと過剰」です。結果、余計なコストがかかります。つまりパフォーマンスが落ちます。具体的に何か？といえばいろいろあるのですが、ざっくり言えば、大規模クラスターでは実行処理中にノード（というかクラスターの構成要素）の障害が顕在化することが多いので、その障害対策をかなり入れています。小規模クラスターではそうそう簡単に障害が顕在化することはないので、処理の度に大きな障害対策のコストを払うことは割に合いません。

では、単ノード処理でいいのか？というとそういうわけにはいきません。大抵のデータは線形に増加しているのが現状です。要するに今の単一ノードのシステムでは問題ですが、数百ノードは不要というのが実態です。ただし代わりの仕組みがないので、ないよりはましで、HadoopとかSparkを利用しているのが現実です。
（別の見方をすれば日本は完全にIT後進国で、自国の情勢にあったITインフラを利用することができていない、ということにもなるのですが・・今まではトップエンドの技術の「おこぼれ」を一種の量産効果化後に、自己で投資をせずに安く利用してきたというメリットもあったが現状は逆になりつつあるということですかね？）

要するに日本もそれなり既存の仕組みではちょっと回らないな、という感じになりつつも、利用手段が合っていないのであまり効率が宜しくない、という状態が分散環境の現状でしょう。

話は逸れますが、現実問題として、アーキテクチャ云々というよりも、「ビックデータも思ったほどビックでもないし、なんかイマイチだよね」というのが普通の感覚ではないでしょうか。結局、従来のCRMと何が違うのか？といえばそれほど大差はないわけでして。
いまや、ビックデータというワードは、一般の会社では「ウチの”ビックデータ”君」という風にインプットの書類を机に山のように積み上げ、ゴミも集まれば宝の山になるといいつつも、まったくアウトプットの出ない人のことを揶揄する言葉になっていたりします。まじで。・・つぎはレポート上の数字が芳しくない営業課長あたりが苦虫かみつぶして「ウチの”データ・サイエンティスト先生”呼んでこい！」と怒鳴る感じになるかと。

2.ムーアの法則の限界とRSA
もう一つの押さえておくポイントは、さんざん言われているムーアの法則の限界です。要するにCPUの微細化が限界で、コア出力が上限に達しつつあります。この結果として、メニーコアが進んでおり、当然そのコア間をつないだり、メモリー周り・IO・NW等を強化する方向に開発が進んでいます。

その結果が、RSA（Rack-Scale-Architecture）です。

この言葉自体はIntelが提唱していますが、別にIntelのオリジナルというわけではなく、たとえばHPあたりはTheMachineという形で進めています。複数のノードを「高密度」にRack内部で組み上げて凝縮性をあげて、ラックベースの一つのコンピュータと見なすアーキテクチャのことです。結果として、数千のコア数と10~100TクラスのDRAMを持つモンスターマシーンができあがります。スーパーコンピューターのダウンサイジング版と考えてよいと思います。

実は、このRSAの利用するデータサイズが、数百ノードでは多すぎるが、単ノードでは辛いという「現状の日本市場」にはサイズ的にはマッチすると思います。RSAはスタートは最小構成は1ノードです。この場合はRSAいう意味はほとんどないのですが、それから普通に2,3,4と増やして行くことが可能です。別にラック満載のモンスターにする必要もなく、4-5台で100コア前後でメモリー数Tというあたりがよい感じではないとか思います。尚、上限はラックベースなので30~40台がぐらいが現実線でしょう。ちなみにRack-Overも当然あります。

まず、データサイズはちょうど良い案配でしょう。メモリーもそんなTByteも使わないよっていうところもあるのと思いますが、実は処理が複雑になると一時的に中間データが膨らむこともあり、これをDiskに書き出さずにメモリーで処理できるのは大きいです。まぁいい感じに見えます。また、複雑な処理はやはり数百ノードで展開するには、いろいろとオーバーヘッドがかかり過ぎます。細かいデータのやりとりは特にスループットよりもよりレイテンシーに振られることが多いので、高密度化は「余計なことをしなければ」有利に働くのが普通でしょう。

3.RSAの内部構造
ではそのRSAとやらは一体なんですか？ということになるのですが、RSAの特徴は、以下の二点につきます。（とりあえずメニーコアは前提になっている）

1.RDMA (Remote-Direct-Memory-Access)
要するにRemoteのDMA。一般にNUMAに属します。端的に言うと「他のコア配下のメモリーに別のコアが直接アクセスする」ということです。まぁ普通に考えると分散・並列処理でのデータの受け渡しでは理論上最速ですが、ただしうまくやらないとかなり簡単にヤバイことになりますね。このあたりの技術はかなり枯れつつあって、実際にHPC系では普通に使われている技術になっています。研究や試行錯誤はかなり長く、とにかくパフォーマンスが出ないというのが相場でしたが、そのあたりがハードの向上でいろいろ変わりつつあるというのが実態のようです。
ぶっちゃけいろいろ調べていますが、とにかく、言われている数値のばらつきがいろいろで、上はremoteがlocalの+30%のレイテンシー（驚異的なんですがｗ）でアクセス可能とか、いや30倍かかる（これでもかなりマシ）とか、実際は300倍ならマシな方だとか、いろいろあって実際にベンチやらんとなんとも言えません。ま、とにかく今急ピッチで競って開発されています。

これは展開は以下のようになることが、ほぼ決まっています。というかそういう選択肢になるしかないのが現実です。

・NW経由での接続
remoteのアクセスがNIC経由になります。
まぁ一回相手（別のノード）に電話かけて会話する感じになりますかね。
この場合はlocalとのレイテンシー比で相当に（1000倍以上かな・・）は遅いと思います。既存のハードウェアプラットフォームを利用することが可能なので、わりと形だけなら作ることができます。現在の開発のエミュレーションはこれで行われていることが多いですね。
この形で一旦製品としてリリースされるでしょう。

・直接のバスを結線する
メッシュ状に各コア・各DRAMを直接インターコネクトする仕組みです。これが本命。
要するに脳みそと脳みそを直接つなげるくらいの感じでしょう。
localレイテンシー比で50倍以内にはなると思います。目標は10倍くらいが現実路線でしょう。localのレイテンシー比で+30%というのもあながちデタラメではないと思います。ただし、バスから何から作る必要があるので、そうそう簡単にはできませんね。ただ製品として確実に出てくるでしょう。

2.NVM (Non-Volatile-Memory)
不揮発性メモリー。これは個人的には「RSAをそのままのH/Wで」という意味ではRSAの構成要素として必須である気がしません。この場合は、高速のSSDでしかないでしょう。実際、現状ではNVMを単純により速いストレージデバイスとしか見ていないのが、今のマスコミ一般の見方でしょう。ただし、RSAの制御ミドルから見た場合は、まったく別の見方になり、割と必須の機能になります。

基本的にRSAは分散並列の仕組みです。この場合、障害対策、特にメタデータやそれにまつわるデータの保全は非常に厄介です。この部分の実装は、分散ミドルの肝になることが多く、実装にひどく骨が折れます。その部分を不揮発性メモリーを利用して一気に解決してしまおう、というのがトレンドです。ログ管理やMVCCのイメージ管理、障害復旧の手段ですね。これは大きい。これはこれでまたどっかでまとめます。

要はRDMAの利用と制御用にNVMを利用する、というのが今のRSAのコアになります。あとはバックプレーンの共有化とかバスの高速化とかありますが、それはブレードサーバでもあるし、普通にどのNW構成でも行う話なので、RSA特有というわけではないですね。

4.技術論
さてでは、RSA上のミドルウエアの話になります。このあたりが我々のフィールドなので。ます、複雑なアプリケーションをミドルなしでRSA上に書くことはたぶん人間にはかなりハードルが高い、というか無理ですね。無理。なのでミドルの出番。

RSAのミドルは個人的には三つのカテゴリーになると思っています。（だんだん書くのが疲れてきた。）

1.仮想制御基盤
まぁRSAのコンピューターリソースの効率のよい利用環境を目的としたミドルですね。VM管理とかそのあたりの制御です。流行のクラウド基盤が行きたい感じだと思いますが、いろいろともめる気がします。NW周りがまるで違うし、そもそもRDMAとかどう考えるのか、正直イメージが沸きません。NUMAなんぞかなり昔に倒したわという基盤がいろいろ登場するとは思うのですが、まぁ当時とかなり環境が違うので、はてさて。そもそもこの場合OSの位置づけもかなり意味がわからない感じになる気がします。単純なレイヤリングというわけにも行かないでしょう。正直、この辺はよくわからんので、専門家の人とか頑張ってください。

2.分散DB
今一番熱いのが、このカテゴリーになります。分散OLTPですね。RDMAでのパフォーマンスがあがると、分散Txはかなり現実的になります。現状の分散Txは疎結合のノード分散を前提にしているのでSerializableにするには、いろいろread/writeのvalidationで工夫する必要があり、できても制限的だ、というのが実態です。これがある程度解決することに加えて、厄介なリカバリーも分散ARIESみたいな、ナニソレ？みたいなアクロバティックなこともしなくてもNVMからのリカバリーで一発です、ということになります。実際、いろんなRDBMSベンダー（というかSAPとMSですかね）が論文とか出しているので、いろいろやってるみたいです。個人的にはHPLabの木村さんがやってるFoedusに注目してます。OSSですしね。この辺はあとでまたまとめます。

3.DAGの実行基盤
この辺でやっとAsakusaの話になります。現在、Fixstars社の方々と共同でC++ベースの実行エンジンを開発中です。AsakusaDSLで書いたアプリケションをリコンパイルするだけで、RSA上で高速に動かす予定です。現在は単ノードのメニーコア特化ですが、RDMAが対応できれば、基本的なアーキテクチャの大幅な変更なしで、対応できると思います。前述のように、日本のデータサイズやプログラムの複雑性にはマッチする上に、HadoopやSparkのような余計な荷物を背負っていません。普通に高速にDAGの処理が終わります。まぁいい感じです。

んでじゃー、最後にデータがもっと増えたらどうなんだということになりますが、Asakusaであれば、そのままSpark・Hadoopでやってくださいね、とこういうことになります。そんな感じです。

今後はこんな流れが進んでいくだろうな、と思っています。

でわ。