スケールアウトとスケールアップ：サーバ処理能力向上の2つのアプローチ

スケールアップが適する場合

　スケールアウトは、コストが低く、高可用性も実現できるため良いことずくめのようにも思えるが、スケールアウトではうまく処理能力が向上できないアプリケーション領域も存在する。すなわち、ひとつのイメージのデータベースに対して頻繁に更新が発生する、いわゆるOLTP（オンライントランザクション処理）である。

　OLTPでは、データベースの排他制御がパフォーマンスに大きな影響を与える。排他制御のオーバーヘッドが大きければ、いかに強力なサーバを使用しても高パフォーマンスを実現できない。排他制御を効率的に行うためには、更新処理を行う複数プロセスが可能な限り短い遅延時間内で通信する必要がある。遅延の短い通信をするには、同じ筐体内でのメモリ経由の通信が最適といえる。異なった筐体間でネットワーク経由の通信をすると、遅延は長くなり、そこが処理全体のボトルネックになってしまう。結果的に、OLTP系のアプリケーションに対しスケールアウトのアプローチでサーバを追加しても、処理能力は比例して増加しない。むしろ、低下してしまうことすらあるほどだ。このような場合には、スケールアップのアプローチが必要となる。

　SAPやOracleなどが提供するエンタープライズアプリケーションパッケージは、システム的に言えば複雑性が高いOLTPだ。これらのパッケージ製品を大規模に展開するためには、スケールアップのアプローチ、すなわち大規模サーバがほぼ必須となる。より正確に言えば、アプリケーションサーバではスケールアウトが可能でも、データベースサーバではスケールアップが必要だ。Oracleが提供するRAC（リアルアプリケーションクラスタ）などの共用キャッシュを生かしたテクノロジにより、複数システムによるデータベース更新処理の排他制御のオーバーヘッドは飛躍的に低下した。それでも、スケールアウトにより性能向上ができる上限は数台レベルまでで、数百台のサーバを使用して処理能力を数百倍にするというのは非現実的だ。

　OLTP系のアプリケーションにおいても、データベースを分割してスケールアウトのアプローチができないわけではない。しかし、前述のように、このような方法では処理能力増強（サーバ追加）のたびにデータベースの再分割作業が必要で、運用上の負担がきわめて大きくなるリスクがある。また、一般的な業務アプリケーションでは、全プロセスから更新される制御テーブルのような共用データ項目が存在し、データベースを完全に分割することが困難な場合も多い。さらに、アプリケーションパッケージ製品を使用している時は、パッケージ側がデータベースの分割を前提に作られていなければ、いずれにせよスケールアウトの適用は困難である。

やはりスケールアウトもスケールアップも必要

　「ローコストの小規模サーバを多数組み合わせたスケールアウト構成を取れば、スケールアップ構成、すなわち高価な大規模サーバは不要である」と主張する人もいる。これは、ウェブサービングなどの特定の処理には当てはまるが、あらゆるタイプの処理に当てはまるわけではない。特に、大規模OLTPではスケールアップ的なアプローチが依然として必要である。

　スケールアウトとスケールアップの特性の相違は、サーバ内通信とサーバ間通信の遅延の違いという物理法則に由来するものだ。ゆえに、今後も長期的にスケールアウトとスケールアップの使い分けは必要となっていくだろう。本来スケールアップが適した領域にスケールアウトを適用しようとしたり、その逆を行おうとしたりすることで、根本的に不適切なシステムを構築することは避けなければならない。