1カ月集中講座
2014年最新CPUの成り立ちを知る 第2回
～サーバー向けCPUはどうしてこうなった?
（2014/6/12 06:00）
スケールアウトで性能を高めたGoogle
前回はコンシューマ向けCPUがどうしてこうなった、という話をしたが、実はもっと劇的に変わったのはサーバー向けCPUである。
サーバーの分野で何が変わったかというと、「スケールアップ」から「スケールアウト」への転換である。どちらも「トータルの性能を上げる」という点では似た意味を持っているが、根本的なところで違う。
「スケールアップ」はサーバー自身の処理性能を引き上げることで性能を改善するのに対し、「スケールアウト」はサーバー自身の処理性能を上げずに、台数を増やして性能を改善する方向にあることだ。
この根本的な方式の違いとして語られるのが、Googleである。Googleがスケールアウトの音頭を取ったわけはないが、目に見える形でスケールアウトの成功例を構築したという観点で、よく引き合いに出される。
古い話になるが、Googleがサービスを始めた1990年代後半といえば、「AltaVista」という強力な検索エンジンがあった。これはDECのAlphaプロセッサを搭載したサーバー上で動く、当時としては非常に強力な検索エンジンだった。だが、やがてGoogleのエンジンに対して性能や対応ページ数などで見劣りするようになり、DEC(というかCOMPAQ)からスピンオフした後、数社に買収された。最終的にはYahoo!の一部としてサービスを続けていたものの、2013年7月には完全に終了してしまった。ここで、Googleが勝てた1つの要因となった“性能を上げるのが容易だったから”という点は見逃せない。
では、なぜGoogleが性能を上げることができたかと言うと、当初から「複数のマシンを上手く連動させて、負荷分散を行なえる仕組みを考えていた」ことに尽きる。2000年台中盤辺りまでのGoogle Search Engineの特徴を示すキーワードとしては、
- Google File System(GFS):
- 複数のマシン/HDDにまたがる巨大なファイルシステム。GFSは、Write Once/Read Manyという使い方がされることを前提に、これに沿った構成を実現している。またエラー対策が強固になされているのも特徴。
- BigTable:
- Google Search Engineで利用される、データベース的な性格を持った分散ストレージシステム。GFS上で稼動しており、内部は「Tablet」と呼ばれる単位で分割される。各々のTabletはTablet Serverで管理され、この数を増やすと性能も上がる。GFSを前提に、高い耐エラー性を実現。
- Chubby:
- 分散ロックサービス。一種のファイルシステムでもあるが、小容量(～1KB)で、むしろ同期(File Lock)やイベント通知などに利用される。GFS以上のエラー対策を実装している。
- MapReduce:
- 大規模分散処理のための汎用ミドルウェア。
- Sawzall:
- 小規模な分散処理を実現するための専用プログラミング言語。
といった用語が出てくる(*1)。これらは、それまでのサーバーとは全く異なる考え方、としてもいい。もちろんこれを支えるOSも独自のものである。Googleがすごいのは、こうしたOSやミドルウェア、言語を全て自前で揃えてしまったことにある。
*1これらの情報は「Googleを支える技術 巨大システムの内側の世界」(西田圭介著・技術評論社)が詳しい。本稿もこれを参考にしている。
この結果として何が実現されたかを今さら説明する必要はないだろう。やや古い数字だが、Google I/0 2008で示されたいくつかの数字を紹介すると、
- 世界中に36のデータセンターがあり、各々のデータセンターには最低数十個のコンテナが設置され、各コンテナには1,160台のサーバーが搭載されている。
- GFSは数PB(=数千TB)のファイルを複数個、格納している。そのGFSは200以上のクラスタで構成され、殆どのクラスタは各々数千台のサーバーで構成される。
といった話が出てくる。
これまでスケールアップで実現していたサーバーの場合、1つのプロセッサにどれだけのコアを搭載し、それをどれだけの密結合構成で増やせるか、という形で性能を上げていた。例えばXeonなら、現在はハイエンドの「Xeon E7-8800」シリーズが最大15コアで、最大8プロセッサの構成が可能だから120コアの密結合サーバーが構築できることになる。さらにサーバーベンダーの中には、この120コア分のプロセッサを1つのクラスタと見なし、複数のクラスタを独自のバックプレーンで繋ぎ、さらに大規模な密結合サーバーを構築する例もある。が、これらをもってしてもGoogleが必要とし、実際に運用している規模と比較すると数百分の1の規模でしかない。
こうした実装がGoogleだけで閉じていれば、トレンドになることはなかっただろう。実際にはTwitterしかり、Facebookしかり、Amazonしかり、eBayしかりといった具合に、大規模なサービスを提供するメーカーが、相次いでスケールアウトの方向に舵を切ることになった。この背景には「Cloud Computing(クラウドコンピューティング)」の普及がある。
クラウドコンピューティングという言葉を最初に使ったのは、Googleの元CEOであるEric Schmidt氏である。これは2006年のことであるが、その後2011年にNIST(アメリカ国立標準技術研究所)が「The NIST Definition of Cloud Computing」(英文PDF)という文章を出して、クラウドの詳細を定義した。
ただ、これに先んじて、例えばSalesforceは1999年にサービスを開始しているし、Amazonは「Amazon EC2」を2006年にβ版として供用開始するなど、さまざまなベンダーがクラウドコンピューティングに向けて走り出していた。NISTの文章は、ある意味こうした状況を整理して定義付けたものと言えるかもしれない。その結果としてクラウドを提供するためには、既存のスケールアップ型のサーバーでは無理で、スケールアウト型のアーキテクチャでないといけないことが明確に示されたのは非常にインパクトがある出来事だったと思う。
もちろん、理論的にはスケールアップ型でもクラウドのさまざまなサービスを提供することはできるが、同じ機能を提供しようとした場合、スケールアップ型でのシステム構築費用がスケールアウト型と比べて2～3桁増えかねないという状況では、スケールアップを選ぶべき理由はほとんどない。
x86サーバーに襲いかかるクラウドコンピューティングの波
この結果、既存のx86のサーバー市場は2つのダメージを受けることになる。まず1つ目は「x86のソフトウェア互換性は必ずしも必要でない」ことだ。NISTの定義ではクラウドには「SaaS」、「PaaS」、「IaaS」の3種類があることになっている。このうちIaaS(Infrastructure as a Service)は、ハードウェアやOS/ミドルウェアを提供する形になるので、ここでは既存のアプリケーションをそのまま動かすケースが多く、互換性は“あった方がいい”(基本的に仮想化環境なので、ハードウェアの互換性がなくてもソフトウェアエミュレーションで解決できるが、ハードウェアで直接実行した方が当然ながら効率がいい)。
ところがSaaS(Software as a Service)やPaaS(Platform as a Service)の場合、そもそも提供される環境では既存のソフトウェアは動かない。データベースアクセスだけを取っても、クラウドで標準的に使えるデータベースはそもそもSQLではないからだ(これを逆手にとって、例えばGoogleはクラウド上で動作するMySQLをGoogle Cloud SQLという名称で2012年から提供しているが、これが話題になるというのは、それが珍しいということでもある)。
従って、これまでサーバー上で動いていたさまざまなアプリケーションをクラウドに持っていく場合、基本的には開発や設計をし直すことになる。利用できる機能や使い方が、これまでサーバーOS上で提供されてきたものと大きく違うためだ。結果、既存のアプリケーションとの互換性は基本的になく、「既存アプリケーションとの互換性」が最大のメリットだったx86系プロセッサの、その最大のメリットがきれいに消えたことになる。実際、性能が間に合えば、PowerPCでもMIPSでもARMでも構わないからだ。
実はこのトレンドは、クラウドが出てくる前からあった。というのはWebベースのアプリケーションの場合、アプリケーションはJavaなどのプログラミング言語で記述されることになるケースが多く、そうなるともうサーバーのアーキテクチャが何であるかは問われず、単にJavaが高速に動作すればよいことになる。こうしたトレンドが、クラウドの進化でさらに加速された形だ。
2つ目のダメージは、スケールアウトの構成の場合、各ノードの性能はそれほど高い必要がないことだ。むしろ台数が増える分、どのように消費電力を抑えるかの方が重要である。AMDが2006年頃に提唱していた「ワット性能」が非常に重要になる。この結果、これまではサーバーと言えばIntelのXeonやAMDのOpteronといったハイエンド構成のコアが求められていたのが、もっと性能とコストの低いコアで足りるようになってきてしまった。つまり、ASP(平均小売価格)がグンと下がってしまったわけだ。もちろんCPUの数そのものの絶対数は明らかに従来より増えているのだが、利益率が下がって薄利多売の方向に向かわざるを得なくなった。
Intelでいえば、Xeon E7などの上位製品の比率が極端に減り、Xeon E5やE3でも十分で、場合によってはデスクトップ向けのPentiumなどでもOK、なんて話になってしまっているわけだ。そうなるとIntelとしては、Pentium程度の価格帯でもサーバー向けとしての利益をきちんと取れるような製品が求められるようになってきた。
こうしたトレンドに追い討ちを掛けるように出てきたトレンドが「In-Memory Processing」である。これまでデータベースなどはHDDを始めとするストレージ上にデータを置いて、これを読み出しながら処理するという形の実装であった。これにSSDを加えてキャッシングする、あるいはHDDをSSDに置き換えるといった形での高速化もあったが、当時のSSDの速度と容量・故障頻度を考えると、まだ全面的にSSDに移行というのはハイリスクであった。その代わりというわけでもないが、「いっそHDDを使わずに全部メモリ上に置けば高速なのでは?」という考え方があった。これがIn-Memory Processingである。とは言え、2006～2008年当時のメモリ搭載量といえば、Xeonクラスのマルチプロセッサシステムでせいぜい64GB程度で、一般的なマシンでは1～2GBだったから、絶対的なメモリ容量が足りない。
しかしながら幸いなことに、これを補う「Memcached」というソフトが、2003年頃から配布されていた。これは、搭載されているメモリをフルに使ってデータベースをキャッシングするものである。もちろん搭載メモリが2GBだとすると、せいぜい1.5GB程度しかキャッシュには使えない。しかし、このMemcachedは複数台のマシンを組み合わせることが可能になっており、例えば1台当たり1.5GBでも、100台用意すれば150GB分のデータベースキャッシュが実現できることになる。データベースを丸ごとキャッシングするには足りないが、データベースのアクセスはインデックスや一部のテーブルのみを煩雑にアクセスするパターンが多いので、これらをメモリにキャッシングするだけで大幅な高速化が可能になる。しかもこのMemcached、やってることは、
- リクエストを受ける
- そのリクエストに該当するデータをメモリから引っ張り出す
- 結果を返す
だけだから、大した処理能力はいらない。
以上の前提知識を元に、例えば下記の記事を読んでいただくと、非常に趣が深いと感じられるのではないかと思う。
この記事の後段にFacebookのMemcahcedに対する要求をまとめたプレゼンテーションが出ているが、Facebookはここまで説明した話を、さらに数桁スケールアップした形で実装していることが分かる。そしてIntelが「Avoton」で行なった実装は、まさにこうしたスケールアウトやCPUに演算が集中しない処理に向けたものとなっているのが分かる。特にビッグデータを取り扱おうという市場の場合、処理の大半は分析よりもデータの整理に費やされることになる。そうなるとメモリアクセスの性能の方が遥かに重要になる。その一方で、スケールアウト化が進むことにより、CPUのコア間での協調作業の頻度はぐんと減る。
元々、Intelなどが立てていたシナリオは
1.既存のサーバーのハードウェアのみを最新のシステムに入れ替えることで、ランニングコストの削減(主に性能/消費電力比の向上による消費電力の削減)が実現できる。しかも既存のソフトウェアの変更が必要ない。ただ、このままだと単純にサーバーの台数が減る。
2.ところが年々処理すべきデータ量や、処理の複雑さが増すことが予測されるので、これをカバーするために、従来と同程度の台数のサーバーを導入することになり、これで持続的な売り上げが可能になる。
というものだった。ところがクラウドの台頭により
1.既存のサーバー上のアプリケーションをクラウドに移行させてしまうことで、企業が個別に保有するサーバーの台数が単純減少。クラウドに移行できないアプリケーションは、ハードウェアのリプレースにより、引き続き手元で処理することになるが、新規の要件はクラウド側で行なう方向に移行しつつあり、結局サーバーの台数が単純に減る。
2.クラウド側のサーバーはスケールアウトをベースとしているので、こちらではハイエンドサーバーのニーズがどんどん減る。
となってしまった。Avotonなどが出てきた理由は、“この(2)の市場を死守するため”と考えればよい。
Cortex-A15の早期投入でサーバー市場へ布石を打ったARM
もっともこうした市場そのものの変化は、当然ながら新規プレーヤーにとって参入のチャンスである。(写真1)は、ARMが2010年に都内で「Cortex-A15」の説明会を行なったときのスライドであるが、Cortex-A15はARMがサーバー市場に参入するための「武器」で、(誤解を招くかもしれないが)「捨て石」になることを当初から想定されていたコアである。
なぜ「捨て石」かというと、いきなり新CPUを出してもすぐに使ってもらえるわけではないからだ。これはx64(x86-64)の時もそうだが、新しいプラットフォームを導入したければ、まずハードウェアを作り、次にその上で動くインフラを整え、最後にアプリケーションが移行してやっと導入が始まることになる。AMDは「Hammer」でx86-64を導入したものの、これにWindowsが対応するのは64bit版のXPがリリースされてからであり、本格的にユーザーへの浸透が始まったのはVistaを経てWindows 7がリリースされてからである。
ARMも同じ立場であり、この当時はサーバー向けにARMのプラットフォームはほぼゼロだった。そこでまずはサーバーに使えるレベルのハードウェアとしてCortex-A15をリリースし、色々なベンダーにOSの対応やミドルウェアの対応を進めてもらい、それからやっとアプリケーションの以降が進む形になる。
実際、ARMサーバーはCortex-A15の次の、64bit対応を行なった「Cortex-A57」で本格的に推進されることになるが、これを実現するために、まずCortex-A15を出して地ならしをする必要があった。Cortex-A15をベースに本格的なサーバーが出てくることはARM自身期待していなかった。
ただこの時期、ARM自身も苦労していたであろうことを想像できる。Cortex-A15は3.5 DMIPS/MHzの高い性能を持つコアで、これを実現するために内部は4命令のスーパースカラ/アウト・オブ・オーダー構成となっている。これは明らかにモバイル向けには高すぎる処理性能と消費電力であり、それが故に「Cortex-A7」と組み合わせてbig.LITTLEという形で消費電力を抑える必要性があった。ただCortex-A7は1.9 DMIPS/MHz程度の処理性能で、Cortex-A15とは性能差がありすぎる。
2014年に投入された「Cortex-A12」は、3 DMIPS/MHz程度に性能を抑え、その分モバイル向けに対応した消費電力枠に抑えたコアであり、Cortex-A7との性能バランスも良い。実際、モバイル向けだけを考えればCortex-A12クラスで十分であり、Cortex-A15はやや過剰である。ただいくらARMであっても、Cortex-A12とCortex-A15を同時に開発するのは無理であり、どちらかを優先する必要があった。結果、とにかく早いタイミングでサーバー市場向けの製品を出しておかないと間に合わない、と判断した結果Cortex-A15が先になったのだろうと想像される。
その結果としてどうなったか? というと、(写真2)のようなプレゼンテーションを2012年末には表明できるに至った。これは何かというと、サーバー向けと一口に言っても、用途に応じて異なるコアが適切であるという話であり、ブルーで示されたStatic WebとかCDN(Contents Delivery Network:コンテンツサーバーの事)や、「Caching/NoSQL」はARMのアーキテクチャが最適である、という表明である。
この「Caching/NoSQL」というのが、要するにMemchachedである。ARMとIntel、どちらが先かという判断は難しいが、結果的にCortex-A15ベースのSoCとAvotonなどの製品は、同じ市場に向けて似たような構成を取り、ここでがっぷりと四つに組んでぶつかり合っているわけだ。
非常に面白いのがAMDの立場である。Bulldozer系列の製品は本来サーバー向けであり、マルチスレッディングに特化したアーキテクチャになるはずだった。ただ理想はともかく実装には色々問題があり、結果同社が持っていたサーバー市場をほとんど失う羽目になったのはご存知の通り。
ところがクラウドやスケールアウトといったトレンド、そしてARMアーキテクチャの興隆によって、再び同社はよみがえるきっかけを見出したように思える。今年(2014年)5月に発表されたロードマップでは、来年(2015年)の「Skybridge」でx86側にBobcat系列の「Puma+」コアを使うことを明らかにしている。Puma+はAvotonに使われる「Silvermont」と同程度の性能および消費電力/エリアサイズのコアであり、もしx86アーキテクチャが必要な場合には十分Avotonに伍して戦えることになる。一方、それが必要なければCortex-A57ベースのコアも提供できるわけで、いわばIntelとARMのいいとこ取りといった選択が可能になる。前回はクライアント向けの話をしたが、サーバー向けでも同様に、低価格/低消費電力のトレンドが急速に沸き起こったことで、AMDは上手い位置に付けることに成功した、と言えるだろう。
今回はあまり後藤氏の記事を引用せずに終わってしまったが、次回はx86に絞って、もう少し細かなCPUアーキテクチャの推移をご紹介したい。