13日の朝に、Vice President, Distributed Database DevelopmentのBenny Souder氏によるGrid Computingに関する講演が行なわれた。ここでは、OracleがイメージするGrid Computingの姿をご紹介しよう。
 |
|---|
| Grid Computingについて説明するOracleのBenny Souder氏(Vice President, Distributed Detabase Development) |
Grid Computingの可能性
最近何かと話題に上るGrid Computingだが、Oracleでの取り組みは決して流行に乗ったという軽いものではなく、Oracleの“Core Value”となるとの考えから長期的な視野で取り組んでいるという。しかも、その一方でこの取り組みは最近になって急に始まったものではなく、クラスタデータベースの開発の過程でずっと取り組んできた動きでもあるし、ある意味では既に実現済みのものだと見ることもできるとの見解である。
Grid Computingは、最近一般的になりつつあるユーティリティモデルとも密接な関連があるとSouder氏は言う。氏は類似のたとえ話として発電所を挙げた。電力供給を止めないために電力会社は多数の発電機をさまざまな場所に設置し、運用管理を行なっている。ユーザーは、発電機がどこにいくつあるかを気にすることはない。サービスのためのインフラは、Grid的な構成となるのがいわば必然ということだろう。逆に、このことからOracleの考えるGridが「メッシュ状に構成された多数のコンピューティングノードの集合による並列演算」というイメージよりは、むしろクラスタ構成の発展型というイメージに近いだろうことも伺える。
そして、Souder氏はこうしたGridのプラットフォームとしてBladeサーバに大きな可能性を見ていると語った。Bladeサーバは演算に必要な最低限のリソースをブレードと呼ばれる小さなカードにまとめ、これを多数集積することで少ない設置面積に多数のサーバを配置することを可能にするデザインだ。利点は、設置面積が少なく高密度実装が可能になること、ブレードにはCPU以外のコンポーネントは最小限度しか載らないため、結果としてCPUを追加する際のコストが安くなることだという。この点に関しては、少なくとも現時点では、ブレード自体の価格はともかく、ブレードを差し込む先となるシャシーが比較的高価なため、システム総額では必ずしも従来のボックス型サーバよりも安価だとは言えない状況だが、Bladeサーバが普及するに従って解消されていくことになるだろう。
スケールアップとスケールアウト
従来のデータベースサーバは、大規模なSMPサーバを高可用性クラスタ構成で利用するのが一般的であった。“スケールアウト”に対する“スケールアップ”アプローチで、サーバの数を増やすのではなく、処理能力を増大させていくことで拡張性を維持する、という考え方だ。拡張性を高めるにはより多くのCPUを搭載可能とする必要があるし、そうした大規模なサーバが簡単にダウンしてしまうようだと影響が大きいので、必然的に高度な信頼性対策を施すことになる。結果として、巨大で高価なサーバができあがる。
一方、スケールアウトのアプローチは、言い換えれば“数で勝負”ということになる。数が多いことから、ある程度の障害発生も吸収が容易だ。1台しかないサーバがダウンするのと、10台のサーバのうちの1台がダウンするのとでは影響はまったく異なる。したがって、スケールアウトアプローチでは、個々のサーバには高度な信頼性対策は不要で、それらを省いて低価格を実現する方が数を揃えやすくなるので有利だということになる。この方向性の最先端がBladeサーバということだ。
一方、単に安価なサーバを多数配置するだけなら、従来から利用されているWebサーバのような個々に独立した比較的軽い処理を担うなら問題なくても、データの整合性を維持し、処理の競合を避けるなどの処理を必要とするデータベースには不向きである。この、サーバ間の連携の機能を担うのが、Oracle9iデータベースのRAC（Real Application Cluster）というわけだ。むしろ、RACによってデータベース側で分散データベースへの対応ができたため、ハードウェアやOSにあまり多くを求めなくて済むようになった、というほうが順序としては正しいのだが。
Bladeサーバのような安価で小型のサーバを多数配置することで従来型の巨大SMPサーバを置き換えることができるのであれば、コストメリットを最大限に追求するためにも、各コンポーネントはもっとも安価なものが優先的に利用されることになる。そこで、OSとして浮上してくるのがLinuxというわけだ。Linuxは、大規模SMPサーバで利用することを考えると、CPU数の増加に応じたスケーリングが実現できないとか、クリティカルな業務サーバに利用するには信頼性に不安があるとかいった普及阻害要因があった。しかし、Oracle9i RACを利用することを前提にすれば、個々のサーバに多数のCPUを搭載する必要はないし、ダウンしてもRACが信頼性を確保すると言うことで欠点が解消され、コストメリットだけが残ることになる。
リソースの効率的な利用が重要
なお、Souder氏は、SMPサーバに対するBladeサーバの優位性として、リソースの効率的な利用が可能である点を挙げた。SMPサーバの場合、必要となる処理能力のピーク値に合わせてCPUを搭載しておくことになるため、通常は一部のCPUが遊んでしまう結果になる。一方、BladeサーバベースのRACシステムなら、必要になったときにサーバの割当数を増やし、ピークが過ぎたら他の用途に転用してしまう、といったダイナミックな構成変更が容易に行なえる。このため、所有するCPUの利用率が向上し、結果としてコスト削減に繋がるわけだ。しかしながら、氏が高価なSMPシステムの代表として挙げたSun Microsystemsでは、N1というコンセプトでCPUの利用効率を向上させるための管理フレームワークを構築しつつある。少なくとも、CPUの利用率の高低に関しては、BladeサーバとSMPサーバで本質的な差は生じない可能性があるわけだ。この点をSouder氏に尋ねたところ、「SunともN1やGrid Computingに関しても意見交換を行なっている」とのことで、SMPを完全に否定する意図ではないようだった。ただし、現実の問題としてSMPサーバとBladeサーバの集積には明らかなコストの差があり、この点が問題なのだという認識であることが確認できた。
