はじめに

近年、サーバー系はクラウドの風が吹いています。この風がIA-32系を強く押し出している、ということを書いてみたいと思います。

2013年現在の日本におけるサーバー市場の状況

IDC Japan 株式会社の発表「2013年第2四半期 国内サーバー市場動向を発表」によれば、

• 国内サーバー市場規模は前年同期比で、金額ベースで13.1%、出荷台数で16.0%減少
• x86サーバーの単価は前年同期比で7.4%上昇（3期連続上昇）
• x86サーバーの出荷台数はマイナスだったが、金額ベースでは上昇
• メインフレームはプラス成長
• RISCサーバーは6四半期連続マイナス成長
• IA-64サーバーは4四半期連続マイナス成長

となっており、x86サーバーの単価の上昇については、

サーバー仮想化の広がりにより、サーバーのメモリーやハードディスクの搭載量が増加し、平均単価を押し上げました。

と分析しています。

簡単にまとめると、国内のサーバー市場は縮小傾向にあるが、x86に関しては台数は減ったもののクラウド用のコンフィグレーションのために単価が上昇したためトータルでプラス成長となった、その他はメインフレームを除いてすべて減少傾向、ということになります。

このことから、サーバー仮想化、いわゆる広義の「クラウド」によってx86サーバー市場は成長しているということになります。

クラウドとIA-32系の関係

クラウドは大きく分けて、所有区分や使用区分などでパブリッククラウドとプライベートクラウドに分かれます。その2つの中で、どのレイヤーで提供されるかによって、IaaS、PaaS、SaaSなどに分かれます。が、いずれにしても最終的にはどこかの物理サーバーの中で実行されるという事実は変わりません。

一見すれば、各レイヤーのサービスが維持できるのであれば、物理サーバーのCPUはなんであってもいいように思われるかもしれません。それが、先日「VMware CEO パット・ゲルシンガーさんの見解」で書いたように、ARM系でクラウドを作るためのサポートをVMwareが行うかどうかという質問につながったのだろうと思います。

しかし、実際には先行導入されているCPUのアーキテクチャ、もっと正確に言うなら命令セットに強く依存します。

クラウドでは、複数の仮想マシンを効果的に物理サーバーに振り分けて実行する必要があります。このため、クラウド上で動くサービスがある程度多く、また同時にクラウドを構成するサーバーの台数を適切に管理できる環境である必要があります。^※1 クラウドの管理者は管理ツールでサーバー負荷が偏らないように仮想マシンを実行するサーバーを調整していきます。^※2 必要に応じてあるサーバーから別のサーバーに仮想マシンを移動させることもあります。^※3 このことから、クラウドを構成するサーバーは、仮想マシンを実行できるというレベルでの互換性が必要となるケースが多いのです。^※4

現在ではIA-32系のCPUを搭載したクラウドがほとんどを占めています。このことから「クラウドを構成するサーバーにはIA-32系のCPUを搭載したものが必要となる」ということになります。

仮に同じクラウドシステムの中にARM系を混在させる場合、仮想マシンのレイヤーではマイグレーションを実施することができません。それより上位の、少なくともPaaSのレイヤー以上でマイグレーションを行うためのシステムを新たに構築する必要があります。それは従来の一般的なクラウドのシステムとは異なるものとなりますし、適用できるサービス（あるいはサービスのレイヤー）にも制限が生まれます。

そうではなく、すべてARM系のクラウドを構築するとなると、既存の投資とは完全に別なクラウドを構築することになります。完全に新規でクラウドの投資を開始するようなケース以外ではなかなか踏み切れない決断になるでしょう。なぜなら、IA-32系だけで構築すれば足した分のサーバーリソースもクラウドの一部に融合され、クラウドのメリットを十分に受け取ることができますが、ARM系で別に構築するとなると、IA-32系とARM系のクラウドで別々にスケールすることになってしまいます。これではせっかくのスケールメリットを得ることが難しくなります。^※5

まとめ

このようなことから、クラウドを構成するサーバーは同じ命令セットを採用しているCPUで構成する方が、より多くのメリットを受けることができます。最近のIntelはXeon系からAtom系まで、いろいろな特色のあるCPUを用意しています。このライン^※6にARM系が割って入り込むためには、これらのIntel製品と十分以上に渡り合えるARM系の製品を投入でき、かつそれを運用するためのシステムの構築やノウハウの蓄積が必要となるわけです。これはそんなに低いハードルではないように思います。

実際、この命令セットによって生まれるハードルは決して低くないことは当事者のIntelもARMも十分以上に認識しているはずです。Intelはスマートフォンへの進出でこれを経験し、ARMはサーバーへの進出で経験しているか、経験しつつあるはずだからです。

一方で、NVIDIAが開拓しようとしているGPGPUサーバーの世界では単一命令セットである必要が相対的に薄いため^※7、NVIDIAのARMによるGPGPU計画はもしかするとわりとすんなりいく可能性がありそうです。

これは少し蛇足気味ですが、関連する話なのでついでに書いておきたいと思います。

AMDはx86仮想化について、そろそろIntel互換路線に切り替えるべきだと思います。現在はIntelのVirtualization Technologyと互換性のないAMD-V(AMD Virtualization)を採用しています。現在のところ、両社のCPUで互換性がとれる範囲の仮想化機能でクラウド用などの仮想化システムは構築されていますが、CPUで提供する仮想化機能が高度化していけば、いずれ吸収しきれない部分が出てくる可能性があります。その時、市場で8割以上に適用できる仮想化命令セットと市場で2割以下しか適用できない仮想化命令セットでは、ソフトウェアベンダーがどちらをより手厚くサポートしていくかは論じるまでもないでしょう。その前にすり合わせをしておく方が、後々のAMDのためになると思うのです。

• ^※1

  ここでは話を簡単にするためにストレージ、各種ネットワーク機器などは除外しています。
• ^※2

  最近は簡単な管理であれは事前に定義されたシナリオと設定に沿って自動的に調整する機能も提供されています。
• ^※3

  仮想マシンを稼働させたまま移動させることを「ライブマイグレーション」、稼働を停止させて移動させることを単に「マイグレーション」と言います。
• ^※4

  特定サービス専用クラウドなどではこの特性が不要なものもあります。
• ^※5

  例えば、IA-32側のクラウドのワークロードが超過してしまっても、ARM側のクラウドは空いている、しかしそこにワークロードを移すことができない、といったような事象が起こりえます。全体が単一のクラウドであればこのようなスケールの問題は起こりません。
• ^※6

  現状でIA-32系が占めているボリュームゾーンを指します。
• ^※7

  GPGPU、特にCUDAレベルで互換性が求められるため、それさえソースコードレベルで確保されるのであればバイナリーレベルでの互換性の必要性は相対的に低いものとなるためです。