isuconに行って平凡な記録を残してきた

もう先週のことになりますが、去る8月27日にid:pekeqさんに誘われてisuconに行って平凡な記録を残してきました。
参加者はpekeqさんとrshさんと無職で暇な奴ということで私

準備編

rshさんがノリノリで高速なKVSを実装するということになった。memcachedはsocketで接続して読み書きするが、この独自KVSはshmでデータを保持する。仕組み上ホストを跨いだデータの共有が出来ないが同一ホスト内での単純なKVSとしてはこれ以上に高速な仕組みはなかなか無いだろうという見込み。
アプリはperlで記述されているとのことなので、XSで読み書きできるところまでを当日までに実装してgithubに置いておくことに。これでレギュレーションで指定された外部で公開されているアプリの利用ということになるだろうということになった。
実際、rshさんの事前の計測では同一ホストで動くmemcachedよりはXS経由でも10倍程度高速なものが完成した。急造品であるため異なるデータサイズへの対応がmemcachedよりも柔軟ではないことや、原理的にホスト間でのデータ同期が問題になるが、そこはフロントのプロキシで分離することでなんとかしようということになった。
おおまかな作業分担は、私がフロントのプロキシ、rshさんが例のKVS、pekeqさんがSQLとそれ以外。

当日編

当日は奇跡的に全員遅刻もせず会場入り
pekeqさんがisuconということでhttp://www.nhk.or.jp/kids/program/miitsuketa.html:NHKの幼児向け番組のイスのキャラ「コッシー」のおもちゃを持ち込む。「これなら投げつけても大丈夫なはずだ…」お子さんが入る家庭でないとそのネタは分からないよ!

前半戦

競技の開始と同時に各人がざっと構成を把握。
私の担当部分はApacheのmod_proxyを使った単純な構成と判明。設定の書き方もApacheとしてはかなり整理された記述で移植が楽そうであると判断した。
アプリの本体はコードを読んだ人間が口々に「こんなに短かいのか…」と呟くほどあっさりした記述。現代的なperlによるアプリケーション記法に慣れていないためのカルチャーギャップに動揺が走る。
この初期状態での測定結果は800qps程度
全員が担当パートをざっと把握したところで軽く意識合わせ。私はnginxに変更のうえ、スタティックな画像やcssなどをリバースプロキシに置くところまで作業することに。
私の担当パートであるリバースプロキシについてもApacheでの設定が簡素であったのでnginxへの移植はすぐに終った。MySQLの各種パラメータが初期状態のままであったため、更新のディスク反映を遅延させたり、クエリキャッシュを有効にしたり、バッファの量を増やしたり、トランザクションログを大きめにするといった基本的な変更を実施。
この時点で再度ベンチマークを流してみたところ1200qps程度まで上昇。隣りのチームがいきなり20000qpsを越える値を叩き出して、余裕の昼食に出たため衝撃が走る。
SQLはアプリに直書きされているものを全て列挙しても両手で数えられるほど、ほとんどは単純なキーによる検索のみであると即断できる程度のものだった。一つだけ明らかに遅くなりそうなSQLはpekeqさんは目視で発見。
記事とコメントがそれぞれ違うテーブルで保持されているのだが、このSQLは最近コメントが付いた順で記事の最新数件のタイトルを取得するというもの。コメントがつくたびに記事が上に上がってくる、スレッドフロート型の掲示板を想像するといいだろうか。
記事と対応するコメントを内部結合し、記事のidで集約、そのうち付けられた最新のコメントをMAX()で出しその降順で出力するというものだった。
これはすぐに非正規化による高速化が可能であると結論されたので、最新のコメント日付と記事のidを保持するだけのテーブルを作ってコメントが付けられると同時にそちらにも書くようにした。同じ記事への書き込みによって日付のみが更新される場合もあるのでMySQLの拡張構文'insert on duplicate key update'を使うことで簡単に書けた。
ここまでのチューニング結果を測定してみたところ21000qpsほど。一瞬ではあったが暫定2位に踊り出た

後半戦

前半は比較的順調だったのだが、後半はいろいろと酷かった。
例のキャッシュシステムの機構を色々な場所に入れてキャッシュをしてみるが一向に速くならない。データベースもリバースプロキシも最初の段階で当初想定していた変更を出し切ってしまっていたのであとは微妙なパラメータを変更する程度。
変更する都度、主催側が用意したベンチマークを走らせるのだが1分間という測定時間内に完全に作業を止めてまでそちらに専念しなかったこともあって、測定中に他のパートが設定変更したことによるfailや結果への影響が排除できなかったためどの変更がどれだけ効果があったのか(あるいは無かったのか)が判然としないまま、暗中模索が続いてしまった。
SQLの変更については別テーブル方式から記事テーブル自体にコメント時刻を持たせ、それを更新する方式に変更した。ただし、パフォーマンスはさほど変化せず。
最後にはアプリケーションがレンダリングした結果自体をキャッシュに入れることで高速に返すよう改修を実施していたのだが、それもベンチマーク側での内容チェックを抜けることが出来ず最後にはロールバックして終了。
会場のメインモニターには各チームの途中結果が表示されていたのだが、それを見る限りfujiwara組とシーサーが頭ひとつ抜けた80000qps越え。それ以降チューニングに成功したチームが70000qpsから30000qpsぐらいで第二集団を形成するといった具合。我々は第二集団の最後尾ぐらい

結果

正式には開催側から発表があると思いますが、最終結果は7位でテストが完走したチームの中では下から数えた方が速い程度

懇親会

1位と2位のチームに終了後に話を聞く機会があったのですが、1位のfujiwara組がかなりアグレッシブなキャッシュ戦略と絶妙なチューニングによって高性能とテスト完走のいずれも勝ち取ったのに対して、2位のいんふらえんじにあーは比較的正攻法のコードの最適化を重視した結果手堅い結果を残したようだった。もちろんSELinuxは有効状態で(ｷﾘｯ
最終結果ではfailだったが、シーサーもかなり高速な暫定結果を残しており恐らく手法としてはfujiwara組と近いものであったのではないかと推測される。

反省

いや、もう反省点だらけの結果であった。
ベンチマークは主催側で用意されているからと測定ツールは用意しなかったのだが、やはり1分間かかる測定できっちりと意味のある結果を測定できなかったため色々と裏目に出てしまった。仮に自前の測定ツールを作ったところで例のkeepaliveや内容チェックの罠を再現しないまま適当なテストをしてしまい逆にあさっての方向へ改修をしてしまう可能性もあった。事実、ウォームアップ用のスクリプトを使って簡易的にレスポンスを測っているときにはどんどん結果が良くなっていたので気を良くしてコスい変更をいろいろとしてしまった。そして、それが裏目裏目に出た結果、自己最高記録さえも上回れない最終結果となってしまった。
作業のやり方という点では、普段一緒に仕事をしているわけではない3名だったため、作業の進め方も意識を合わせられなかった。ホワイトボードとはいわなくとも、紙のノート1冊でも有ればそれにタスクリストを作ってチェックしながら進めることができただろう。
skypeチャットなりIRCなりで各人の作業を小まめに共有していれば、ベンチマーク中の作業中断ももっとスムーズにできただろう。
測定の1分間を毎時05分からと決めて、次の測定までに行なう変更を明確にするといったチェックポイントを作ったほうが効率的だっただろう。
あとは、アプリケーションのボトルネック調査を適当にしてしまったこと。10倍速いキャッシュもキャッシュがネックになっている局面に正しく投入しないと効果が無いということだ。今回の測定内容からするとキャッシュを効果的に入れることがかなり難しく、それを突破できたかが勝敗の別れ目になった感がある。Livedoor社内での事前実施で好成績を残した方の手法はコンテンツの性質に応じて適切な粒度でキャッシュをし、その有効期間を管理するというものだった。
後知恵ではあるが、リバースプロキシでのSSIもmemcachedの利用も競技中に検討しないではなかったのだが、アプリへ手を入れる工数を考えると採用に踏み切れなかった。この辺は普段からperlで手を動かしている人との差が顕著に出てしまったと考える

最後に

isuconという非常に刺激的な場を提供くださったLivedoorの皆様には大変感謝しております。機材や場所といったリソースはもちろん、競技用のコードの準備といった人的リソースは多大なものであったと想像致します。

U300でセルスタンバイでやたらと電力を食う問題について追う(1)

android

どういう問題かは宮川さんが書かれている通りです。
無線部分の細かい制御を読むのはちょっと無理だと思うのだけど、せっかくAndroidでソースがあるのだからと読める範囲で追いかけてみました。
とっかかりを掴むまで

  • CM7のコードを取ってくる
  • "セルスタンバイ"という文字列を検索
    • リソースファイルが見付かる
    • ./packages/apps/Settings/res/values-ja/strings.xml
    • "power_cell"がリソース名であるようだ
  • "power_cell"でgrep
    • ./packages/apps/Settings/src/com/android/settings/fuelgauge/PowerUsageSummary.javaで使われている
    • というかここだけ
    • ファイル名からすると電力消費に関係する箇所のようだ

ここをとっかりとして読み進める。
呼び出し元

    private void processMiscUsage() {
        final int which = mStatsType;
        long uSecTime = SystemClock.elapsedRealtime() * 1000;
        final long uSecNow = mStats.computeBatteryRealtime(uSecTime, which);
        final long timeSinceUnplugged = uSecNow;
        if (DEBUG) {
            Log.i(TAG, "Uptime since last unplugged = " + (timeSinceUnplugged / 1000));
        }

        addPhoneUsage(uSecNow);
        addScreenUsage(uSecNow);
        addWiFiUsage(uSecNow);
        addBluetoothUsage(uSecNow);
        addIdleUsage(uSecNow); // Not including cellular idle power
        addRadioUsage(uSecNow);
    }

バッテリ駆動に切り替わってからの経過時間のマイクロ秒(といっても1000倍しているだけ)を渡して、電話、画面、WiFi、Bluetoothなどなどコンポーネント毎の利用電力を出している。
で、以下が実際にpower_cellというリソース名が使われている部分。無線コンポーネントに関係する電力消費を算出しているメソッド

    private void addRadioUsage(long uSecNow) {
        double power = 0;
        final int BINS = BatteryStats.NUM_SIGNAL_STRENGTH_BINS;
        long signalTimeMs = 0;
        for (int i = 0; i < BINS; i++) {
            long strengthTimeMs = mStats.getPhoneSignalStrengthTime(i, uSecNow, mStatsType) / 1000;
            power += strengthTimeMs / 1000
                    * mPowerProfile.getAveragePower(PowerProfile.POWER_RADIO_ON, i);
            signalTimeMs += strengthTimeMs;
        }
        long scanningTimeMs = mStats.getPhoneSignalScanningTime(uSecNow, mStatsType) / 1000;
        power += scanningTimeMs / 1000 * mPowerProfile.getAveragePower(
                PowerProfile.POWER_RADIO_SCANNING);
        BatterySipper bs =
                addEntry(getString(R.string.power_cell), DrainType.CELL, signalTimeMs,
                R.drawable.ic_settings_cell_standby, power);
        if (signalTimeMs != 0) {
            bs.noCoveragePercent = mStats.getPhoneSignalStrengthTime(0, uSecNow, mStatsType)
                    / 1000 * 100.0 / signalTimeMs;
        }
    }

BatterySipperにどの用途でどれぐらいの電力消費があったかを計算して登録する処理を行なっている。
addEntryで登録を行なっているのでそこから逆に読んでいく。
addEntryの引数は

    private BatterySipper addEntry(String label, DrainType drainType, long time, int iconId,
            double power) {

とあるので、最後のpowerが消費電力。powerは+=で足し合わせて2パートからなっており、前半ではシグナル強度の5段階(BatteryStats.NUM_SIGNAL_STRENGTH_BINS)ごとの時間と消費電力の積を合算している。
後半ではスキャンの時間とそのときの電力消費の積を足している。今回の症状から電波を掴んでいる状態での電力消費ではなく、スキャンで浪費していると推測されるので問題は後半のPOWER_RADIO_SCANNINGだろう。
どの状態のときにどれぐらい電力消費があるかという情報はPowerProfileというクラスで定義されており、各ステートと電力消費の対応はxmlから読み込んでHashMapとして保持している。
xml自体ももちろん配布系に含まれており

./frameworks/base/core/res/res/xml/power_profile.xml

に実際の数字が書いてある。が、これは端末ごとに異なるはずなので各機種版もあり各モデル毎のバイナリを作るときに差し替えているはず(読んでない)。例えば

./device/htc/heroc/overlay/frameworks/base/core/res/res/xml/power_profile.xml

とかはディレクトリ名からHTC Hero用。特に各機種版のxmlを読むとradio.scanningとradio.onの消費電力がそれぞれ分かる。同じくHTC Heroから読むと

  <item name="radio.scanning">70</item>
  <array name="radio.on"> <!-- Strength 0 to BINS-1 -->
      <value>3</value>
      <value>3</value>
  </array>

とあり、スキャン中は70mAで掴んでいるときは強度に依らず3mAとある。機種ごとに多少の大小はあるものの、スキャン中はどれも70から88と非常に電力を消費するのに対してradio.onの状態ならば20分の1以下の小さい電力で済むようだ。
フィーチャーフォン時代にも圏外となる状態で電源を入れていると基地局を探すために電池の持ちが悪くなるという話はよく聞いたので、これはそれとも合致する。
以上から、mStats.getPhoneSignalScanningTimeが非常に大きな値を返しているのではないかと推測される。文字通りスキャンに時間を消費してしまって電力を浪費しているのだろう。
(続くかもしれない)

Investigation: Is Your SSD More Reliable Than A Hard Drive?

hardware

SSDは本当にHDDよりも信頼性が高いのかという記事。ありがちな「俺が使って大丈夫だったから、大丈夫」とか「外れを引いて痛い目にあったから、SSDは信頼できん」とかいう短絡的な話ではなく大量導入したケースの故障率を追いかけていて面白い
曰く

  1. MTBFは信頼性について何も語らない
  2. 年間平均故障率はメーカが主張する値よりも高い
  3. ドライブは使い始めの年に壊れやすい傾向はない。故障率は利用年数に応じて増加する
  4. SMARTはあてになる故障の前兆現象の検出にはならない
  5. 「企業向け」と「個人向け」は故障率の面では非常に似通っている
  6. 同一アレイにある一つのドライブが故障は他のドライブの故障する可能性が高い
  7. 温度は故障率に対して大した影響は与えない

とのこと。
大量導入されて故障率のデータが上がってきているのは必然的に発売からやや時間が経過したドライブばかりなのでそれを差し引く必要はあるが、故障率という点ではHDDよりも安全とは言えそうだ。ただ、やはり無視できないレートで故障はする。
エンタープライズ向けでIOPSを稼ぐためには今までHDDを大量に束ねて使っていたわけだし、単体性能が一桁違うドライブになったために数が減って単純に故障点が減っているだろうという指摘には納得した。しかしSSDの性能を十分に生かせるほどのRAIDコントローラが十分にあるかと言われるとまた別問題である。

Googleのサイトへの経路が切り替わった件

network

id:halfrackｾﾝｾｲが面白い事象を観測したようなので、これを機にGoogleの内部ネットワークを邪推
以下、OCN東京収容ユーザからwww.google.comへのtraceroute

(snip)
 9  61.126.89.38 (61.126.89.38)  11.850 ms  6.207 ms  6.406 ms
10  209.85.241.90 (209.85.241.90)  6.077 ms  6.173 ms  5.031 ms
11  209.85.255.58 (209.85.255.58)  8.598 ms 209.85.255.56 (209.85.255.56)  7.837 ms  7.441 ms
12  209.85.255.217 (209.85.255.217)  37.527 ms 209.85.255.39 (209.85.255.39)  39.231 ms  38.913 ms
13  209.85.250.101 (209.85.250.101)  37.954 ms 209.85.250.103 (209.85.250.103)  39.401 ms 209.85.243.21 (209.85.243.21)  40.219 ms
14  72.14.238.42 (72.14.238.42)  38.647 ms  38.723 ms  49.272 ms
15  tz-in-f99.1e100.net (64.233.183.99)  37.057 ms  36.803 ms  38.059 ms

9までがOCNの網内
10がGoogle側の対向ルータ。恐らく対外BGPを話すボーダールータ。RTTからすると大手町か少なくとも東京近郊であるようだ。
11から先はper packetかper flowでバランスされた2つの経路を通っている。IPアドレスの近さからいってActive/Activeの冗長化をしていると思われる。
12で急にRTTが30msぐらい増える。ここでちょっとRTTの話。光ファイバ回線は高速とはいえ距離に応じて伝送に時間がかかる。ざっと目安は国内なら20ms以内、アジア圏内で十分に直接経路がある場合で50ms以内、日本と北米で100ms前後。近距離であればルータのバッファリングや一時的な混雑でRTTで大きく影響を受けるが、遠距離になるほどケーブルの伝送遅延が効いてくる。ntt.netがSLAのために自身の網内でRTTを測定しており、その結果が一般でも見ることができる。
グローバルIPネットワークサービス | NTTコミュニケーションズ 法人のお客さま
この結果からすると30msというのは国内であればかなり遠方である。よほど光ファイバが物理的に変な経路を回っているか、常時混雑でもしているのではない限りは考えられない。いずれも可能性は低そうなので、恐らく国内ではないだろう。北米にしては速すぎるので、アジア圏と推測される。
上の結果と同じsrcからpingでRTTを測ったところ、台湾の最大手ISPであるHiNetのホストがRTTが35ms前後であるとわかった。対象にしたホストはHiNetのウェブサイト
その他、香港やシンガポールも幾つか測ってみたが経路にも依るがこれよりはややRTTが長かった。よって、tracerouteの結果の12以降は恐らく台湾ではないかと推測される。
注目すべきは、GoogleのASの内部で日本から台湾への回線を使っているということ。その経路は素直に読む限り2経路以上に冗長化されている。
13までは複数の経路でバランスしているのが見えるが14から先は1経路のみに見える。ホストの手前はL2で冗長化している可能性がある。

www.l.google.com.       5       IN      A       72.14.203.147
www.l.google.com.       5       IN      A       72.14.203.99
www.l.google.com.       5       IN      A       72.14.203.103
www.l.google.com.       5       IN      A       72.14.203.104
www.l.google.com.       5       IN      A       72.14.203.105
www.l.google.com.       5       IN      A       72.14.203.106

手元のDNSから引くとwww.google.comのA レコードには6レコード登録されている。いずれも同じ/24以下にいる。上記の結果と合わせれば最終段では経路冗長化よりはDNSラウンドロビンによる冗長化を図っているのではないか。また、これほど特定のIPアドレスブロックに集中しているホストだけでサービスを行うのは可用性の点で考え難いのでGSLB的な仕組みで分散しているのではないかと推測される。
AkamaiのGSLBはパテントが絡むのでどうやって住み分けしているかは謎

まとめ

  • 日本でwww.google.comを見ると多分台湾のホストを見ているみたい
  • Googleは海底ケーブルも冗長化しているみたい
  • IPアドレスの分散からしてGSLBしているかも
  • これの切り替えで事故ったのかは不明

追記(5/10)

id:halfrackｾﾝｾｲのgoogle.comへのRTTの長期的な観測結果によれば

とあるので、京都からは従来10ms強で落ちついていたものが3月の末ぐらいで40msぐらいに上昇している。東京は従前から40msなのでもともと国内ではなかったようだ。つまり3月末で国内のサイトが選択されなくなったと見える。RTTからするとどちらも現在は台湾のホストが選択されているようだ。
これがGSLBの調整の結果なのか、そもそも国内から撤退したのかは不明

WiMAXのモバイルAPの各種製品について

network hardware

WM3300Rからの買い替え候補として検討中

型番 Aterm WM3500R URoad-9000 WMX-GWMR
メーカ NEC シンセイコーポレーション I/O DATA
サイト http://121ware.com/product/atermstation/product/wimax/wm3500r/ http://www.shinseicorp.com/wimax/wimax05.html http://www.iodata.jp/product/mobile/wimax/wmx-gwmr/
価格 オープン 24,800円 22,050円
バッテリ駆動時間 約8時間 標準型：約3.5時間/大容量：約7時間 約6時間
重量 約120g 標準型：約102ｇ/大容量：約140g 約99g
WiFi 802.11b/g/n 802.11b/g/n 「Wi-Fi CERTIFIED」は、IEEE802.11g/bとして認証 802.11b/g (11nテクノロジーという独自拡張あり)
クレードル オプション 標準添付 標準添付
有線LANへの接続 クレードル経由 不可 クレードル経由
USBポート MicroUSB MicroUSB MiniUSB
備考 バッテリは取り外し不可 外形が円柱形

実売価格次第だけど、Atermはやっぱり手堅い印象。バッテリが交換可能でも実際には複数持ちするよりモバイルブースターを持った方が楽。自宅の有線接続を廃止するつもりならI/Oのも有力か

Facebookのデータセンタについて

Facebookが自社のデータセンタを更新するにあたって、設備の情報を資料付きで公開した。
Home » Open Compute Project
建屋も含めて新設するなんていうのは日本のサービス事業者にはなかなか出来ない規模だが、個々のテクノロジーは参考になるものが非常に多くて興味深い。

サーバ

外装なしの板金の上にマザーボードを乗せているのみの、いわゆる自作サーバ系を主力にしているようだ。外装がないとはいえ、横板はあるし上下で間を詰めてマウントするのでエアフローは板金上に搭載されているファンで十分に確保できそう。物理的な高さは66mm(2.60inch)なので、Unit数換算では1.5U
シャーシ上にはマザーボードの他、ディスクが6本と電源が搭載できる。この辺は市販の1Uサーバとほとんど同じ構成、もちろん外装がないのはかなり特異だ。単なる板きれと市販サーバのどちらに近いかと言えば、外装が無いだけで市販サーバに近い作り込みがされていると感じる(板の上に乗せているだけのサーバが悪いと言っているわけではない)。
マザーボードはプロセッサタイプに応じてIntel系とAMD系を併用している。汎用品ではなくそこそこ手の入った特注品であるようだ。キャパシタが固体コンデンサを使っているなどはやはり耐久性などを考慮してだろう。基板は大きめだが、機能は市販品よりも削っているようで部品実装点数も少なめ。
面白い機能としては、Reboot on LANというのがある。通常のWakeup On LANの逆でマジックパケットを受けとるとNICが本体をリブートさせる機能だ。確かにソフト的にハングアップなどしたときはリモートから再起動だけするようなオペレーションをすることはよくある。リモートから管理画面をとって確認するまでもないときはこの機能は便利かもしれない。
写真ではIntel系には1つのRJ-45の口しかないように見えるが、ドキュメントにはいずれのタイプでもNICは3つ搭載しているらしい。最近のコントローラは1つで2個の口を提供するタイプが多いので、搭載NIC数も2か4というのが多いのでちょっと珍しい。実装されている写真ではEthernetが1本しか結線されていない物もあるので、ある程度バリエーションがあるのかもしれない。
電源はAC/DC変換の12.5Vの単一給電。DC給電にしてしまわないのはちょっと意外だったが、12.5Vの単一給電はGoogleも提唱しているものなのでやはりそこに落ちつくようだ。UPS(後述)からのDC給電を受ける口もある。

ファシリティ

エネルギー効率を重視しているのは今時のデータセンタの流儀の通り。従来Facebookが使っていたのはPUE1.5だったところを、今回のデータセンタでは1.07という驚異的な高効率になっている。国内のデータセンタが新しいところでも1.5以上、古いところなら2や3を超えているなかでは凄い数字だ。
LED照明やバックアップ電源、高効率配電などは定石通り。LED照明はPower over Ethernetで給電しているとある。アラートと照明を連動させているのは面白い。Facebookをcrackする照明をチカチカさせることが出来るわけですね ;-P
先日見学させていただいたIIJの新型コンテナDCと同様に外気冷却を中心とした冷却システムを使っているが。今回建設したオレゴンの環境条件は高温多湿の日本とは違うため、より長い期間で外気での冷却が可能なようだ。
湿度に関しては日本と違い低すぎるときもあるため、加湿機構を持っている。外気が低すぎるときはサーバ排気を混合して温めるなどは、IIJのケースと同様だ。サーバに給気する条件としてASHRAEの基準を使っているのも同じ。
ラックについては3連の独自な作りを採用している。通常のデータセンタが1ラック単位で設置するのに対してまとまった規模で自社利用する場合はこのような構造の方が空間効率が良さそう。バッテリによるUPSはこの3連ラックのペアに対して1つの割り合いで設置されており、左右の3連ラックに対して給電するようになっている。これも通常の設置単位とは違うためにできる技だ。
3連ラック自体の高さは42Uと一般的な高さ。上に2つのスイッチを置き、残りの空間を30台のサーバが占めている。

PCI-Express接続のSSDについて

hardware

NVM Expressという規格が策定されつつある。
Intel and Standards
Intelが提唱しているPCI-Express経由で不揮発メモリ(この場合フラッシュ)にアクセスするインターフェイスの規格。ようするにFusion-ioのioDriveをコモディティ化してしまおうという動き。現在SSDのコントローラを作っている主要な会社(IntelはもちろんMarvell、Micron、SandForceなど)が賛同しているので、このまま主流になりそうな予感だ。
具体的な製品例としてはボイス｜エルミタージュ秋葉原にある、2011/Q3に発売予定のPCI-E接続のSSDとは恐らくこちらのインターフェイスを使ったものになるのではないかと推測される。
Intelのページにある仕様書とLinuxのドライバを斜め読みした限りだと、現代的なSATAのコントローラの機能を包含し更に多機能にしたところを目標にしている。位置付けとしては既存のSATAコントローラとSSD側のコントローラを一体化したようなものになるので、機能不足なSATAコントローラに足を引っぱられることなく十分な性能が発揮できるようになるはずだ。
互換性に関してはUSBのホストコントローラが仕様を統一した(OHCIやUCHI、EHCI)ことによってドライバについて各OSでそれらのドライバを実装するだけで、その後あまり悩まなくても使えたようにNVMHCIのドライバさえあればチップメーカを問わず使えるようになることが期待できる。
NVM自体は仕様上様々なスペックのコントローラが作ることができるので、エンタープライズ向けのリッチなものからコンシューマ向けのミニマムなSSDも同じ仕様で使える。コンシューマ向けではI/Oキューが2個程度でハイエンドでは128個のキューをサポートしたものといった具合で差別化を図ることができる。ここまで多くのキューをサポートできると各プロセッサ毎に独立したI/Oキューを割り当てるということも可能になる。
Linuxのドライバは既にそこそこ完成しているようで、本家に統合できる形で開発が進んでいる。実際の完成度は動くデバイスが無いのでなんとも言えないが少なくとも最低限の機能は揃っているように見える。
ではioDriveとの比較ではどうなのかという話だが、ioDriveについてはid:syuu1228さんが過去にエントリにしておりこちらを参考にした。
Fusion-ioのioDriveは単なるSSDと何が違うのか - syuu1228's blog
このエントリによるとioDriveのキモはソフトウェア側の処理に多くの機能を実行させていることによるとあるが、これに比べるとNVMは比較的穏当で既存のI/O処理に近くハード処理とソフト処理の区分を変えるというほどではないように思う。
syuu1228さんの指摘にもあるが、ハード処理をソフト処理に代替させるというのはネットワークスタックでの動きと反対に思える。LWNでの記事でSolid-state storage devices and the block layer [LWN.net]というものがあり、SSDでの急激な性能向上に対応するためにはblock layerでもネットワークスタックで急速な性能向上(10Baseから10Gbps overへ)への対策を手本にしていくべきだという話とは正反対にも思える。
一方で運用者としては近年のCPUの多コア化によるソフト処理性能をやや持て余し気味であるのも事実だ。一部ではもはやCPUは余っている状況になっている。ただしシングルスレッド性能はさほど向上していないので十分に考えられた多重化を大前提だが、ソフト処理へのシフトというのは有りではないかとも感じている。
ioDriveの作り込みは興味深いとは感じつつも、過去の例からすると大量に出荷されるハードウェアに独自仕様が勝利するケースは少ないので、そのままではioDriveが厳しいのではないかと考える。ただ、強みは量産コストがかからないソフトウェア実装であるため今後も独自の機能を盛り込んでいけばハイエンドとして生き残る可能性はあるのではないか。
結論としては、Fusion-ioのioDriveほどの超絶性能ではないがかなり速いそしてコモディティ化することによってかなり安価なPCI-Express接続のSSDが今年後半から出始める。適度な大きさのフラッシュが十分に安価になったら、M/Bに組み込まれた状態のSSDとかも出てくるのではないか。これらをブートドライブとしてHDDは必要に応じて付けたり付けなかったりというスタイルに移行してくるかもしれない