Storage Class Memory
ACMの2016 Jan.の会報の記事に上がっていたので、面白かったのでちょっとまとめておきます。
http://cacm.acm.org/magazines/2016/1/195724-non-volatile-storage/abstract
前提として、SCM（Storage Class Memory）について書いておくと、いわゆる不揮発性メモリー(Non-Volatile memory)で、次世代の主流になるだろうとは言われています。DRAMまでのレイテンシーは出ていないので、DRAMのリプレースにはならないと思われる（のが今の常識）ですが、ストレージとしては最速で、一般にDiskの1000倍（3桁）は速い。が、値段は30倍と言われていますね。
・ハイライトハイライトは以下
・The aged-old assumption that I/O is slow and computation is fast is no longer true
要するに「I/Oが遅いものだ」という今までの前提はあまり通用しないということかと。特にSCMを考えればそれはそうなるとは思います。まぁ今までは、メモリーと比較されるレベルのレイテンシーのストレージというものは、そもそも想定しませんからね。
・The relative performance of layers in systems has changed by a factor of a thousand over a very short time
これは特にSCMでのパフォーマンスの向上が1000倍とかそんな単位ですぐに来てしまうので、システムレイヤーでのパフォーマンス・ギャプの絵面が変わるという意味ですね。
・Pile of existing enterprise datacenter infrastructure – hardware and software – are about to become useless (or, at least, very inefficient).
結果として、特にDCの既存資産は、まぁゴミになると言っています。割と極端なものいいですが、それだけSCMのインパクトが強いということでしょう。
・概要
詳細は直接エッセイを読んでもらうとして、内容を要約すると大体以下の考え方になっています。
・SCMのレイテンシーはかなり低減されていて、Diskは遅いという話は過去のものになるだろう。概ね、既存Disk比で1000倍（IOPS)は違う。（このあたりは、そもそもSSDでもその位は行っていた気がするので、それよりも向上していると思いますけど）
・SCMを導入するときに問題になるのはコスト。これが高い。特に対CPU比になると、従来はCPUが高くてDiskが安い、という話が前提だったが、むしろ逆転するレベル。すなわち「CPUの方が安い」ということになる。この場合は、投資対効果（特にDCのような場合）を考えると、どれだけSCMのIOを使い切れるのか？ということの方が重要になってくる。
その上で、以下の四つのポイントを提示しています。
1.Balanced systems
まずボトルネックがストレージI/OからCPUに移ることになる。処理待ちのデータをメモリーに保持するために、かなりのRAMを必要になってしまう。というかRAM上のデータが単純に処理待ちで手持ちぶさたになる。CPU仮想化のようにストレージの仮想化が必要になるかもしれない。ストレージの利用率を上げることが必要になるので、ワークロードに見合ったバランスのよいCPUや適切なメモリーが提供されることが必要になる。ただ、まぁこれは結構難しい。
2.Contention-free I/O-centric scheduling
ハードウェアのバランスが整っても次に時間軸の問題がある。これはNWの高速化の時のスループットを上げる手法と同じように、できるだけinterruptedさせない手法もやり方としてはあるだろう。勿論複数のコアで並列処理はするようにはなるとは思うが、できるだけ競合しないようにスケジューリングする必要がある。うまくシリアル化しないと、簡単にロックしてパフォーマンスがでない。SCMドライブのサチュレーションをさせながら、クライアントとのやりとりを邪魔しないやり方が必要になる。
3.Horizontal scaling and placement awareness
これは単一ストレージではなくて、まとめてクラスター的に扱った場合の話で、JBODのような単純な仕組みではなくて、分散ストレージ的に扱わないと無理って話です。
4.Workload-aware storage
SCMの特性が実際のワークロードには当然合わない、ということがあるので、うまくtiringした方がよい、という話です。まぁNUMAのように同じデバイス層で複数のレイテンシーがある場合は、データ管理はある程度階層化するのは普通にある話です。シーケンシャルな処理が得意なストレージとの組み合わせも確かにあるでしょう。
いずれにしても、今までのように「単純なストレージ・デバイス」として扱うと、コストに見合うだけのパフォーマンスが得られない。したがって、可能な限りの工夫をしなければならない、というのが趣旨です。
・思うところ
SCMの導入により、ストレージのレイテンシーやスループットは今までのIOボトルネックを（というか、他にボトルネックが他に移るほどに）解消できるほどに向上するが、その分コストがあがる、よって、それを「使い切る」アーキテクチャにしなければ、見合わないという考え方は、面白いと思います。
コストあたりで見たときにストレージのI/Oを使い切るために、うまくCPU資源の利用を考える、という発想はあまりなかったと思います。（正確にいうと大昔にはあったと思いますが。・・そもそも高速ストレージ自体が貴重だった時代には確か、そんな話があったとうっすら記憶しています。もっともおそらく30年以上前ではないかと思いますが・・・）
ここ10数年の流れは、ストレージ（disk）はどんどん安くなるからデータはどんどん置いておけ、というコンテクストが主流でした。そのなかでビックデータとかIoTとか、クラウドとか、そういった「アーキテクチャ」の台頭があったと思います。そのアーキテクチャの一環として、増えたデータを一気にロードする仕組みとしてHadoop/Sparkとかその手の仕掛けが出てきたことには異論はないでしょう。
その流れが変わりますよ、とそういう話ですね。
正直、個人的にはNVMはストレージとして見るのは、ちょっと割が合わないなぁ〜とは思っていました。“超高級”超高速SSDじゃねーの、と。SCMは大量のデータの置き場としては、コストが全然ペイしないでしょう。むしろミドルの、今までのストレージではパフォーマンス的に合わないクリティカルな部分への導入にちょうどいい(たとえばlog管理・snapshotの置き場)ぐらいで、他に用途はないだろうと思っていたので、ここまでの発想はちょっとありませんでした。
また、ストレージに対して「相対的にCPUコアのコストが下がる」というのは、そもそも従来の発想とは真逆の考え方だと思います。CPUは貴重だし、処理能力も高い。よって、割と単純な単一タスクだけでは割が合わないので分け合いましょうというのが、今までの流れです。汎用機時代のTSSや、現在の仮想化技術も同じコンテクストにあるでしょう。
翻って見れば、ムーアの法則の限界は、コア出力の向上の終焉になります。他方、確かにストレージメモリーの技術は進化が進んでいます。この半世紀はCPUコアの出力の伸びに対して、ストレージの向上は相対的には微々たるものでした。まぁ、そのストレージがメモリー並のパフォーマンスになるまで向上するのであれば、今後の考え方にも影響があるでしょう。
その意味では今後主流になるアーキテクチャがバス周りやストレージ周りを強化する方向に倒れるというのは、必然で（代表的なものがRSAみたいなものですね。）、かつ、そのときにコスト構造のコアがNVM・SCMである、という読みは多分正しいと思います。確かに高いですよ。むしろCPUは安い。
データの有りようも、基本的に「Small Big Data」のような感じになっているのがまぁ常識になっている現状で、この中でSCMを考えるのであれば、なるほど、どうコストを回収できるように使い倒すか？というのは考え方としてはアリでしょう。
ど安めのストレージにだらだらデータを放り込んだところで、結局、利用する場合は絞ってレイテンシー勝負になるのは、もうその辺にいくらでも転がっている話です。テープの代わりにDiskを使って適当にクレンジングしたあとはSCMにベースをおいて、スピード（レイテンシーもスループットも）勝負という図式は、特にビジネスのレスポンスを上げるという意味では普通に考えることでしょう。
この進展の場合、いろいろポイントがあると思います。
1.基本的にミドルとアプリの問題はでかい。
まず、現時点でSCMをきっちり使い倒すミドルウェアがないですね。一応、この手のバス強化の話の研究は死ぬほどあり、どの実装も工夫はしていますが、現実にパフォーマンスが一気に1000倍あがるというような場合は、既存のものは全く役に立ちません。ので、いろいろ再検討になります。使えなかった方式が復活したり、新しく別のコンセプトが出てくると思います。当然、ミドルは全面見直しです。アプリレイヤーからさらに、という話であれば、現状ではあまり現実ではないと思います。
ミドル屋から見るとこれは相当危なっかしい話にも見えます。この手のアーキテクチャはいままでの通例だとH/W依存が高いので、結果アプライアンスや特定パッケージにソリューションが集中するようにも見えます。この場合、ユーザサイドから見た場合は、あまり選択の余地がない可能性にもなると思います。アーキテクチャの大きな曲がり角では、主導権争いは常に起きるものですが、どうなるかはちょっと見えない感じです。
普通に考えるのであれば、まずは小回りの効く割と単純な仕組みで、まずは組み上げて、うまく特定のアプリケーションに乗せる、というのが一番近道には見えます。ツボにはまれば凄まじいパフォーマンスをたたき出す「システム」が構築できると思います。（それが構築仕切れないユーザーは、ウン十億払って割と中途半端なアプライアンスを買う羽目になるかな？）
2.DCの問題はある
既存のDCでは問題になると思います。オンプレで個別に構えている場合は、まぁこの手のアーキテクチャの変更は、ある意味エイヤでやれますが、特にクラウドになってくるとそうは行かないでしょう。
まぁ単純に超速いIO（桁が3っつ違う）が提供されて、それをうまく共有化できる仕組みができて、その上でサービス化（たとえばDB）されれば、ま、普通にそっち使うだろうって話です。単価が高いのでどう使い倒すかが鍵になるでしょう。
ある程度、資本力の差がでるかな、と思います。既存のハードを相当一気に入れ替えることができないと、「入れかえることができるクラウドベンダー」に対して、価格どころか、そもそもユーザに提供できるパフォーマンスが、おそらく平均で2-3倍は違うということになるでしょう。これは厳しい。しかもハードを単純に入れただけではペイしないので、うまく使い倒すミドルを開発？する必要が出てくるでしょう。（某国のクラウドベンダー群の実態を見る限り、これは絶望的に厳しい）
3. いずれにしても
それなりに課題があるので、そうそうすんなりいかないと思います。ただし、数十年にわたって、ITを縛り続けてきたムーアの法則、というかムーアの呪いが、解けた現在、その影響は普通に考えて地殻変動なみに出てくるだろうな、と思います。これもその流れの一つだろうなとは思いますし、その意味では注意はしておきたい。
奇しくも、データ爆発の流れで分散処理やクラウド的なものが一般化（というか精神的なハードルが下がった）し、同時期にムーアの法則が終焉しているという事情は、汎用機→オープン化に続く、大きなパラダイムシフトの幕開けと見て、それほど間違いではないでしょう。
そんな感じ。
