このページの本文へ

前へ 1 2 3 次へ

ロードマップでわかる!当世プロセッサー事情 第181回

AMDのARMコアが狙うのは「Cloud」向けサーバーCPU

2012年12月10日 12時00分更新

文● 大原雄介(http://www.yusuke-ohara.com/

  • この記事をはてなブックマークに追加
  • 本文印刷

 問題は残るCloudである。ここで想定される用途は、現在とは異なる領域になる。下の画像は12月5日に都内で開催されたARMの記者説明会のものだが、サーバー市場における用途を分類したものだ。

ARMが想定する、サーバー別の用途。縦軸は扱うストレージ容量、横軸が扱うネットワーク帯域を示したもの。緑は計算処理が主体、オレンジはほどほどの計算処理、水色はほとんど計算がない処理

 「One Size Does Not Fit All」というのは、「1種類のコアですべての用途を賄うのは無理」という意味。具体的に言えば、図中の「Compute Intensive」はARMベースサーバーには向いておらず、主に水色の「Modest Compute」を狙うとしている。

 「Static Web」とは静的な(書き換えのない簡単な)Webサーバー。「CDN」はContents Delivery Network(コンテンツ配信ネットワーク)で、ようするに動画などを配信するサーバーのことだ。最後の「Caching/NoSQL」が、これから話題にする分野である。前回の記事でも、「Hadoop」「Cassandra」「Memcached」といったキーワードに触れたが、まさしくこれがCaching/NoSQLに該当する。

 NoSQLについてもう少し説明しよう。NoSQLとは「検索言語『SQL』をベースにしたリレーショナルデータベースシステムを“使わない”大規模データベース」の意味である。ところが、例えばGoogleやYahoo!といった超大規模検索エンジンだと、リレーショナルデータベースでは性能(検索速度)や容量(格納できるデータ件数)の点で不適当である。そこでこうした企業はリレーショナルデータベースを使わずに、自分で巨大な検索エンジンを構築した。これがNoSQLと呼ばれるもので、ようするにSQL言語を使わずに検索するという仕組みである。

 こうした検索エンジンの場合、データ量が巨大であるため、1台のマシンでデータを全部保存するのはもちろん無理だ。そのため、大量のマシンにデータを分散させて細かくデータを保持し、検索をかけて結果を返すという仕組みを取る。この際に利用されるアプリケーションが、HadoopやCassandraである。

 しかしHadoopやCassandraを使っても、最終的にデータがHDDに入っているのであれば、それをメモリーに取り込んで返すので時間がかかりすぎる。そこで、こうした検索の結果をあらかじめメモリーにキャッシュしておくことで応答時間を短縮しよう、というのが「Memcached」である。

 この仕組みがCloudに分類されがちなのは、クラウド・コンピューティングの基本的な概念である「必要なリソースを必要な時に、必要なだけ提供する」という仕組みを作るのに、このHadoop/Cassandra/Memcachedといったアプリケーションが非常に適しているからでもある。

 こうしたアプリケーションは、実は64bit ARMコアと原理的に親和性が高い。例えばMemcachedは、とにかく大量のメモリーを積んで、ネットワーク経由でリクエストが来たら、自分の保持するメモリーの中にそのデータがあるかどうかを判断。データがあればその結果を返すだけのものである。そのためそれほど高いCPU性能は必要なく、その代わりメモリーI/O性能とメモリー搭載量だけが問題になる。

 32bitのARMコアでは最大メモリー搭載量は4GBまでだが、64bitコアならCortex-A53ですら、1TBのメモリー搭載量に対応する。これならばx86に見劣りしない。メモリーI/O性能を1コアだけで比較した場合、インテルの「Haswell」やAMD「Piledriver」コアの後継である「Steamroller」コアほどは高くないと思われる。HaswellやStamrollerで2スレッドを動かした場合の性能と、2基のCortex-A57/A53でそれぞれ1スレッドずつ動かした場合のトータル性能はおそらく互角以上と思われ、その一方でダイサイズや消費電力はずっと小さくできる可能性がある。これはHadoop/Cassandraでもほぼ同じである。

 こうしたアプリケーションの場合、最終的には消費電力がランニングコストの大勢を占めている現状からすれば、Steamrollerやさらにその後に控えている「Excavator」といったBulldozer系列のコアよりも、Cortex-A57/A53を使った製品の方が競争力が高いことが予想される。AMDもこのことを理解しているだろう。ARMベースのOpteronの特徴をこのように表明している。

ARMベースのOpteronはこんなシステムになるという想像図

 上掲のスライドにある3番目の「small cores and large cores」とは、「big.LITTLE」構成を採用するという意味と思われる。つまりCortex-A57とCortex-A53の両方を搭載することになる。ひとつのダイにどれくらいのコアが入るのかは不明だ(ARMのインターコネクト技術「CoreLink」を使うと、理論上は最大32コアまで可能)。

 こうしたダイを大量に並べて、SeaMicroの技術であるFreedom Fabricを利用することで、トータルとして大量のコアを利用できるようにするというのがAMDの狙いと思われる。メモリー容量は記載されていないが、このシステムで「最大外部ストレージ容量:5PB」(5000TB)とあるあたり、Hadoopの利用を前提に考えていると思われる。

 Memcachedについても、現実問題として1つのコアに接続できるメモリー量が、バス幅やDIMM容量で制限されることを考えると、なるべく多くのコアを集積するほうが、トータルの容量を稼ぐのに有利である。そのため多数のコアが入ったプロセッサーをFreedom Fabricでつなぐのが得策と考えられる。

 実のところこうした市場は、インテルが開発中といわれる22nmのAtomベースCPU「Avanton」も、同じところを目指している。従来AMDは、ここにBobcatシリーズの将来製品を投入すると言われていたが、これを思い切りよくARMに入れ替えた、と考えるのがわかりやすい。ようするにAMDのARMベースOpteronは、こうしたCloud向けの一部用途が最初のターゲットになる。

 もちろん、将来的にはもう少し幅が広がってゆく可能性はある。だがそれはARMベースサーバーがどこまで広がるかに依存する部分で、現状ではそこまで見通すのは難しい。そのためまずは確実に、このCloud向けのサーバー市場を取るのがAMDの目標になると思われる。

前へ 1 2 3 次へ

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン