スケーリングとは？垂直スケーリング・水平スケーリングを使い分ける

こちらの記事では、性能のためのスケーリングについて解説します。

スケーリングとは

単にスケーリング(Scaling)と言った場合、それは拡大縮小のことです。

ITシステム開発におけるスケーリングは、画像・映像のスケーリングと性能管理手法としてのスケーリングという意味があります。この記事では後者を扱い、以降、単に「スケーリング」と記述した場合はこれのことを指します。

性能管理手法としてのスケーリングとは

性能管理の文脈で言うスケーリングとは、処理量に見合った性能をリソースの減増によって実現することです。

性能とは、サービス提供におけるリソース利用の効率性です。簡単に言えば、ITシステムのスピードです。性能の詳細については以下の記事をご参照ください。 https://envader.plus/article/17

スケーリングには、垂直スケーリングと水平スケーリングの2種類があります。

• 垂直スケーリング

処理を担う各コンポーネントの性能を増減させることです。例えばサーバを対象にするのであれば、ハードウェアをより良いものに交換したり、逆に必要ないのでより性能の低いものに変えたりすることです。性能を上げる場合はスケールアップ、下げる場合はスケールダウンと呼びます。

• 水平スケーリング

分散処理を担うコンポーネントの数を増減させることです。例えばサーバを対象するのであれば、サーバを複数用意してそれらで分散処理したり、必要なければサーバ数を減らしたりすることです。増やす場合はスケールアウト、減らす場合はスケールインと呼びます。

垂直スケーリングと水平スケーリングの使い分け

垂直スケーリングと水平スケーリングはそれぞれメリット・デメリットが異なり、絶対的な優劣をつけられるものではありません。目的に応じて適切に使い分ける必要があります。

垂直スケーリング・水平スケーリングの長短

垂直スケーリングと水平スケーリングのメリット・デメリットが問題となる主要な側面は、メンテナンス量・実装難易度・ダウンタイム・性能限界の4つです。

• メンテナンス量

メンテナンス量はオンプレミスの時に問題となります。

この点ではスケールアップが優れています。スケールアウトがコンポーネントを増やすためにメンテナンス対象も増えるのに対し、スケールアップは既存コンポーネントをより高性能なものに置きかえるだけのためメンテナンス対象は増えません。

• 実装難易度

実装難易度についてはスケールアップの方が簡単です。ハードウェアを交換するだけのため、実装への影響は少ないからです。「少ない」であって「無い」と言い切れないのは、チューニング等パフォーマンスを考慮した実装が必要になったり不要になったりする可能性がゼロとは言い切れないためです。

スケールアウトする場合、複数コンポーネントで分散処理を行っているために、「どう分散するか」「コンポーネント間でデータ整合性をどう保つか」という問題が発生し、これに対応する必要があり難易度が高くなります（この件は後ほど詳述します）。

• ダウンタイム

ダウンタイムについてはスケールアウトに分があります。ダウンタイムとは、サービスの停止時間のことです。スケールアップはハードウェア自体の交換を行うためダウンタイムは避けられません。しかしスケールアウトは分散処理対象を増やすだけのため、トラブルがなければダウンタイムは必要ありません。

• 性能限界

性能限界についてはスケールアウトであればありません。一方でスケールアップはハードウェアの問題ゆえに物理的な制約が存在し、これによって向上できる性能には限界があります。

どう使い分けるか？

どうスケーリングさせるのが良いかは、どのようなサービスかによります。

例えば比較的小規模なサービスであるがゆえにダウンタイムも性能限界も許容できるのであればスケールアップを利用するかもしれません。逆に大規模で、かつある程度データの一貫性を犠牲にしても良いのであれば、スケールアウトを利用することになるでしょう。

全てを満たすのは難しい・コストがかかる事が多く現実的ではない場合、何は必須なのか・何は許容できるのか・許容不能な部分があるとすれば何をすれば許容範囲にまで制御できるのかを自身のサービスに合わせて検討しましょう。

水平スケーリングの難しさ

先述のように、水平スケーリングには垂直スケーリングにはない難しさがあります。「どう分散するか」「コンポーネント間でデータ整合性をどう保つか」です。

どう分散するか――負荷分散の問題

スケールアウトにより複数のコンポーネントが並列稼動している場合、個々のアクセスをどのコンポーネントに繋げるか＝負荷分散の設計が問題になります。どのように分散するかは要件により、適切な方式を選択する必要があります。

データ整合性をどう保つか――データ整合性の問題

スケールアウト対象のコンポーネントがデータを持つ場合、データが分かれる以上、データ間の整合性の保持が問題になります。整合性保持の設計が必要になります。

この点で最も大きな問題を抱えるのはRDBです。一般的にRDBのスケールアウトは難しいとされます。基本的にRDBは一貫性を求められるデータを扱いますが、この特性のデータはスケールアウトと相性が良くありません。問題となるのは更新処理です。

まず、複数RDBそれぞれにまったく同じデータを保持するケースを考えましょう。この場合、全てのRDBが同値になるように処理せねばならず、余分な同期処理の分、RDBが1つしかない時よりも遅くなり得ます。性能向上になりません。これを回避するために複数RDBがそれぞれ異なるデータを保持するようにしたら、複数RDB間で一貫性を求められるデータ処理（例えばRDB1とRDB2があったとして、RDB1のデータから数値を引いてその分をRDB2に足すような処理）をした時にトラブルが起きて処理が中断してしまった場合に備える複雑な仕組みが必要となります。

DBサーバ以外のサーバは基本的にデータを保持しないため、このような問題は生じません。セッションを保持する可能性がありますが、この場合はRDBほどではありませんがRDBと類似の問題が生じます。DBでも、NoSQLで扱われるのは一貫性を求めないデータであることが基本のため、こちらでもRDBのような問題は生じにくいです。

オンプレミス・クラウドのスケーリング

スケーリングの「容易性」「費用」は、オンプレミスかクラウドかで変わります。

スケーリングの容易性

スケーリングの容易性では、クラウドに圧倒的な分があります。

オンプレミスではスケーリングのためにはそれなりの準備と日数を必要とします。まず必要なリソースの見積もり＝サイジングが必要です。いざスケーリングするとなると、ハードウェアの調達作業が必要ですし、調達できたらハードウェアの各種設定作業＝キッティングも必要になります。

しかしクラウドであれば設定さえすればスケーリングが完了します。

スケーリングの費用

費用面に関しては、オンプレミスとクラウドのいずれが安いかはケースバイケースです。

スケーリング自体に必要な費用、スケーリング後の維持費用（オンプレミスであれば電気代等もかかります）、ノウハウを持つ人材の確保コスト等、様々な費用があり得ます。多角的な観点から費用を計算するべきでしょう。