アプリケーションが成長するにつれて、適切なインフラストラクチャや変更がなければ、データベースがシステムのボトルネックになる可能性があります。トラフィックが急増すると、エンジニアは難しい選択を迫られることがよくあります。現在のサーバーを強化すべきか、サーバーを追加すべきか。このガイドでは、水平スケーリングと垂直スケーリングの違い、それぞれのトレードオフ、ニーズに合った適切なアプローチの選び方について説明します。
データベースのスケーリングは、システムの容量、パフォーマンス、可用性を高めるプロセスです。これにより、データベースでより多くのデータを処理し、ユーザー数の増加に対応できます。
業界では、専門家はこのプロセスに主に 2 つの用語を使用しています。垂直スケーリングは「スケールアップ」、水平スケーリングは「スケールアウト」です。この 2 つのパスを理解することが、信頼性の高いデータシステムを構築するための第一歩です。
スケールアップとも呼ばれる垂直スケーリングでは、既存のサーバーにさらに能力を追加します。同じデータベース ノードを維持しながら、CPU、メモリ、ストレージを増やして処理能力を向上させます。
これは、リレーショナル データベースをスケーリングする従来の方法としてよく見られます。すべてのデータが 1 か所に保存されるため、アーキテクチャがシンプルになります。
メリット
課題
Cloud SQL などのマネージド データベース サービスを使用すると、数回クリックするだけでマシンサイズを変更できるため、垂直スケーリングが容易になりますが、物理ハードウェアの制限に達する可能性があることを覚えておくことが重要です。
小規模: 急成長中のスタートアップが、単一のデータベースでウェブアプリを運用しているとします。トラフィックが増加し始めたら、より大きなインスタンスに移行できます。これにより、アプリケーション コードを書き換えることなく、より多くのコンピューティング能力で追加の訪問者を処理できます。
エンタープライズ規模: レガシー システムを使用する大企業も、垂直スケーリングを使用する可能性があります。これらのシステムは通常、データ間の複雑な関係に依存しています。コードが単一のデータベース向けに構築されているため、分散システムに移行しようとするのではなく、1 台のマシンにさらに処理能力を追加することでスケールアップできます。
社内ニーズ: 社内レポートに垂直スケーリングを使用している企業もあります。プライマリ データベース サーバーに RAM を追加して、リソースを大量に消費する大規模なクエリを高速に処理できるようにすることで、一般ユーザーのエクスペリエンスを低下させないようにするかもしれません。
水平スケーリング(スケールアウト)とは、1 台のマシンの性能を上げるのではなく、データベース システムにマシンを追加して、サーバーのグループ全体に作業を分散させることです。これは、最新のクラウド コンピューティングと分散システムのコアコンセプトです。
エンジニアは、データを複数のサーバーに分割するシャーディングや、データを複数のノードにコピーするレプリケーションなどの手法を使用して、これを実現しています。
メリット
課題
Spanner のような分散 SQL データベースは、これらの課題を管理することに役立ちます。Spanner は、複数のマシンにわたるデータの同期という難しい作業を自動的に処理するため、手動でデータを分割する必要や、リレーショナル データベースの安全性を犠牲にする必要はありません。これにより、システムを複雑にしすぎることなくスケールアウトできます。
容量: グローバルな e コマース プラットフォームでは、大規模なセールイベント中に水平スケーリングを使用する場合があります。何百万人ものユーザーが一度にサイトにアクセスすると、システムは新しいノード間でデータを自動的に再バランス化してトラフィックを処理し、単一のサーバーが過負荷にならないようにします。
冗長性: ミッション クリティカルな金融アプリケーションでは、水平スケーリングも使用されることがあります。データベースをアベイラビリティ ゾーンと呼ばれる複数の物理的な場所に分散できます。この設定により、1 つのデータセンターで問題が発生した場合でも、アプリケーションは稼働し続け、データの整合性という約束を守ることができます。
近接性: グローバルなゲーム会社は、世界各地にデータベース ノードをデプロイする可能性があります。データベース ノードをプレーヤーの近くに配置することで、ラグが非常に少ない、高速でスムーズなエクスペリエンスを提供できます。たとえば、プレーヤーが東京に住んでいる場合、そのプロフィール データは東京のデータベース ノードに保存され、超高速で読み取りと書き込みが行われます。
クラウド スケーリングについて話す場合、垂直方向のスケーリングとは、データベースをホストする仮想マシンのサイズをアップグレードすることを意味します。水平スケーリングでは、自動スケーリング グループまたは分散クラスタにマシン インスタンスを追加します。
企業によっては、両方の方法を組み合わせて使用することもあります。これは斜めスケーリングと呼ばれます。このアプローチでは、システムにノードを追加し(水平スケーリング)、ハードウェア容量をアップグレードします(垂直スケーリング)。大企業はこれを利用して、データベースの高可用性と、複雑なローカルタスクに対応できる強力なパフォーマンスを両立できます。
はい。従来は困難でしたが、Spanner のような最新の分散型 SQL データベースは、高度なクロック同期とスマート プロトコルを使用して、データの整理と正確性を維持しながら水平スケーリングを可能にしています。
CPU やメモリの使用率が高い、クエリ時間が長い、繁忙時にユーザーのレイテンシが増加しているなどの警告サインに注意してください。これらはすべて、現在のデータベースが対応に苦慮している可能性があることを示す兆候です。
水平スケーリングと垂直スケーリングの主な違いは、システムにリソースを追加する方法です。垂直スケーリングでは 1 台のマシンの処理能力を向上させますが、水平スケーリングではネットワークにマシンを追加します。
機能 | 垂直方向のスケーリング | 水平方向のスケーリング |
コンセプト | 1 台のマシンにリソースを追加する | ネットワークにマシンを追加する |
容量 | ハードウェアの厳格な上限 | 実質的に無制限 |
ダウンタイム | 通常はダウンタイムが必要 | ゼロ ダウンタイム(ノードは動的に追加) |
複雑さ | 低い(シンプルなアーキテクチャ) | 高(分散ロジックが必要) |
費用 | 大型ハードウェアの費用の増加 | 標準マシンによる線形スケーリング |
機能
垂直方向のスケーリング
水平方向のスケーリング
コンセプト
1 台のマシンにリソースを追加する
ネットワークにマシンを追加する
容量
ハードウェアの厳格な上限
実質的に無制限
ダウンタイム
通常はダウンタイムが必要
ゼロ ダウンタイム(ノードは動的に追加)
複雑さ
低い(シンプルなアーキテクチャ)
高(分散ロジックが必要)
費用
大型ハードウェアの費用の増加
標準マシンによる線形スケーリング
SQL と NoSQL データベースについては、業界にまだ浸透している時代遅れの考え方がいくつかあります。従来の SQL データベースのスケーリングの難しさの多くは、結合とデータ整合性の処理方法に集中していました。リレーショナル データベースを多数のサーバーに分散させることは技術的に難しい場合がありますが、最新の分散ソリューションではこれらの問題の多くが解決されており、開発者は必要なリレーショナル機能を失うことなく SQL を水平方向にスケーリングできます。よくある 3 つの誤解と、その裏にある真実をご紹介します。
事実: できます。従来のリレーショナル設計では垂直スケーリングが好まれていましたが、最新の分散 SQL システムでは、リレーショナル データベースを複数のマシンにまたがって配置できます。このアプローチは、SQL の整合性と最新のクラウド アーキテクチャの水平方向の成長力を組み合わせたものです。
真実: NoSQL は、大量の非構造化データセットには効果的ですが、複雑な構造化クエリには SQL データベースの方が適していることが頻繁に見受けられます。多くの場合において、アプリケーションがデータポイント間の深い関係に依存していると、適切に調整された SQL データベースは NoSQL よりも優れたパフォーマンスを発揮します。
事実: どちらかを選ぶ必要はありません。最新のアーキテクチャ パターンでは、システムを多数のマシンにスケールアウトしながら、データ安全性の厳格なルール(ACID コンプライアンス)をクラスタ全体で維持できます。
データベースのスケーリング方法を決定する際、多くの場合、予算、データ量、必要な稼働時間によって選択肢が決まります。一般的なアドバイスは次のとおりです。
Google Cloud は、スケーリング戦略に合わせて調整できるさまざまなデータベース ツールを備えています。スケールアップのシンプルさが必要な場合でも、スケールアウトの大容量パワーが必要な場合でも、これらのプロダクトが役立ちます。

