データベースの水平スケーリングと垂直スケーリング

アプリケーションが成長するにつれて、適切なインフラストラクチャや変更がなければ、データベースがシステムのボトルネックになる可能性があります。トラフィックが急増すると、エンジニアは難しい選択を迫られることがよくあります。現在のサーバーを強化すべきか、サーバーを追加すべきか。このガイドでは、水平スケーリングと垂直スケーリングの違い、それぞれのトレードオフ、ニーズに合った適切なアプローチの選び方について説明します。

Google Cloud データベースでスケーリングとイノベーションを実現

データベースのスケーリングとは

データベースのスケーリングは、システムの容量、パフォーマンス、可用性を高めるプロセスです。これにより、データベースでより多くのデータを処理し、ユーザー数の増加に対応できます。

業界では、専門家はこのプロセスに主に 2 つの用語を使用しています。垂直スケーリングは「スケールアップ」、水平スケーリングは「スケールアウト」です。この 2 つのパスを理解することが、信頼性の高いデータシステムを構築するための第一歩です。

垂直方向のスケーリングとは

スケールアップとも呼ばれる垂直スケーリングでは、既存のサーバーにさらに能力を追加します。同じデータベース ノードを維持しながら、CPU、メモリ、ストレージを増やして処理能力を向上させます。

これは、リレーショナル データベースをスケーリングする従来の方法としてよく見られます。すべてのデータが 1 か所に保存されるため、アーキテクチャがシンプルになります。

垂直スケーリングのメリットと課題

メリット

  • シンプルさ: データベースはアプリケーションにとって単一のマシンのように見えるため、コードは同じままです。
  • メンテナンスが容易: 管理と更新が必要なサーバーは 1 台のみ
  • 整合性: 複数のサーバー間でデータを同期する必要がない

課題

  • ハードリミット: すべてのマシンには最大容量があります。最終的には、1 台のサーバーにハードウェアを追加できなくなります。
  • ダウンタイム: ハードウェアのアップグレードを行うには、データベースを一時的にオフラインにする必要がある場合が多い
  • 単一障害点: 1 台のサーバーがダウンすると、アプリケーション全体がダウンする可能性があります。

Cloud SQL などのマネージド データベース サービスを使用すると、数回クリックするだけでマシンサイズを変更できるため、垂直スケーリングが容易になりますが、物理ハードウェアの制限に達する可能性があることを覚えておくことが重要です。

垂直スケーリングの例と一般的なユースケース

小規模: 急成長中のスタートアップが、単一のデータベースでウェブアプリを運用しているとします。トラフィックが増加し始めたら、より大きなインスタンスに移行できます。これにより、アプリケーション コードを書き換えることなく、より多くのコンピューティング能力で追加の訪問者を処理できます。

エンタープライズ規模: レガシー システムを使用する大企業も、垂直スケーリングを使用する可能性があります。これらのシステムは通常、データ間の複雑な関係に依存しています。コードが単一のデータベース向けに構築されているため、分散システムに移行しようとするのではなく、1 台のマシンにさらに処理能力を追加することでスケールアップできます。

社内ニーズ: 社内レポートに垂直スケーリングを使用している企業もあります。プライマリ データベース サーバーに RAM を追加して、リソースを大量に消費する大規模なクエリを高速に処理できるようにすることで、一般ユーザーのエクスペリエンスを低下させないようにするかもしれません。

水平方向のスケーリングとは

水平スケーリング(スケールアウト)とは、1 台のマシンの性能を上げるのではなく、データベース システムにマシンを追加して、サーバーのグループ全体に作業を分散させることです。これは、最新のクラウド コンピューティングと分散システムのコアコンセプトです。

エンジニアは、データを複数のサーバーに分割するシャーディングや、データを複数のノードにコピーするレプリケーションなどの手法を使用して、これを実現しています。

水平スケーリングのメリットと課題

メリット

  • 無限の成長: ニーズの増大に応じてマシンを追加し続けることが可能です
  • 高可用性: 複数のサーバーがあるため、1 つのノードに障害が発生してもシステムはオンラインのままです
  • 費用対効果: 1 台の巨大で高価なサーバーを購入する代わりに、より安価な標準ハードウェアを使用できます

課題

  • 複雑さ: アプリケーションは複数のサーバーと通信する方法を認識する必要があるため、設計上の課題が増えます
  • データの整合性: 多くの異なるマシン間でデータを同期させるのは管理が困難です
  • コードの変更: 分散データベース環境を処理するために、アプリケーション コードの変更が必要になる場合があります

Spanner のような分散 SQL データベースは、これらの課題を管理することに役立ちます。Spanner は、複数のマシンにわたるデータの同期という難しい作業を自動的に処理するため、手動でデータを分割する必要や、リレーショナル データベースの安全性を犠牲にする必要はありません。これにより、システムを複雑にしすぎることなくスケールアウトできます。

水平スケーリングの例と一般的なユースケース

容量: グローバルな e コマース プラットフォームでは、大規模なセールイベント中に水平スケーリングを使用する場合があります。何百万人ものユーザーが一度にサイトにアクセスすると、システムは新しいノード間でデータを自動的に再バランス化してトラフィックを処理し、単一のサーバーが過負荷にならないようにします。

冗長性: ミッション クリティカルな金融アプリケーションでは、水平スケーリングも使用されることがあります。データベースをアベイラビリティ ゾーンと呼ばれる複数の物理的な場所に分散できます。この設定により、1 つのデータセンターで問題が発生した場合でも、アプリケーションは稼働し続け、データの整合性という約束を守ることができます。

近接性: グローバルなゲーム会社は、世界各地にデータベース ノードをデプロイする可能性があります。データベース ノードをプレーヤーの近くに配置することで、ラグが非常に少ない、高速でスムーズなエクスペリエンスを提供できます。たとえば、プレーヤーが東京に住んでいる場合、そのプロフィール データは東京のデータベース ノードに保存され、超高速で読み取りと書き込みが行われます。

よくある質問

クラウド スケーリングについて話す場合、垂直方向のスケーリングとは、データベースをホストする仮想マシンのサイズをアップグレードすることを意味します。水平スケーリングでは、自動スケーリング グループまたは分散クラスタにマシン インスタンスを追加します。

企業によっては、両方の方法を組み合わせて使用することもあります。これは斜めスケーリングと呼ばれます。このアプローチでは、システムにノードを追加し(水平スケーリング)、ハードウェア容量をアップグレードします(垂直スケーリング)。大企業はこれを利用して、データベースの高可用性と、複雑なローカルタスクに対応できる強力なパフォーマンスを両立できます。

はい。従来は困難でしたが、Spanner のような最新の分散型 SQL データベースは、高度なクロック同期とスマート プロトコルを使用して、データの整理と正確性を維持しながら水平スケーリングを可能にしています。

CPU やメモリの使用率が高い、クエリ時間が長い、繁忙時にユーザーのレイテンシが増加しているなどの警告サインに注意してください。これらはすべて、現在のデータベースが対応に苦慮している可能性があることを示す兆候です。

水平スケーリングと垂直スケーリングの主な違い

水平スケーリングと垂直スケーリングの主な違いは、システムにリソースを追加する方法です。垂直スケーリングでは 1 台のマシンの処理能力を向上させますが、水平スケーリングではネットワークにマシンを追加します。

機能

垂直方向のスケーリング

水平方向のスケーリング

コンセプト

1 台のマシンにリソースを追加する

ネットワークにマシンを追加する

容量

ハードウェアの厳格な上限

実質的に無制限

ダウンタイム

通常はダウンタイムが必要

ゼロ ダウンタイム(ノードは動的に追加)

複雑さ

低い(シンプルなアーキテクチャ)

高(分散ロジックが必要)

費用

大型ハードウェアの費用の増加


標準マシンによる線形スケーリング

機能

垂直方向のスケーリング

水平方向のスケーリング

コンセプト

1 台のマシンにリソースを追加する

ネットワークにマシンを追加する

容量

ハードウェアの厳格な上限

実質的に無制限

ダウンタイム

通常はダウンタイムが必要

ゼロ ダウンタイム(ノードは動的に追加)

複雑さ

低い(シンプルなアーキテクチャ)

高(分散ロジックが必要)

費用

大型ハードウェアの費用の増加


標準マシンによる線形スケーリング

SQL と NoSQL のスケーリング: 誤解を解く

SQL と NoSQL データベースについては、業界にまだ浸透している時代遅れの考え方がいくつかあります。従来の SQL データベースのスケーリングの難しさの多くは、結合とデータ整合性の処理方法に集中していました。リレーショナル データベースを多数のサーバーに分散させることは技術的に難しい場合がありますが、最新の分散ソリューションではこれらの問題の多くが解決されており、開発者は必要なリレーショナル機能を失うことなく SQL を水平方向にスケーリングできます。よくある 3 つの誤解と、その裏にある真実をご紹介します。

事実: できます。従来のリレーショナル設計では垂直スケーリングが好まれていましたが、最新の分散 SQL システムでは、リレーショナル データベースを複数のマシンにまたがって配置できます。このアプローチは、SQL の整合性と最新のクラウド アーキテクチャの水平方向の成長力を組み合わせたものです。

真実: NoSQL は、大量の非構造化データセットには効果的ですが、複雑な構造化クエリには SQL データベースの方が適していることが頻繁に見受けられます。多くの場合において、アプリケーションがデータポイント間の深い関係に依存していると、適切に調整された SQL データベースは NoSQL よりも優れたパフォーマンスを発揮します。

事実: どちらかを選ぶ必要はありません。最新のアーキテクチャ パターンでは、システムを多数のマシンにスケールアウトしながら、データ安全性の厳格なルール(ACID コンプライアンス)をクラスタ全体で維持できます。

適切なスケーラビリティ アプローチの選択

データベースのスケーリング方法を決定する際、多くの場合、予算、データ量、必要な稼働時間によって選択肢が決まります。一般的なアドバイスは次のとおりです。

  • トラフィック量が予測可能で、それほど多くない場合は、垂直スケーリングから始めるのが簡単です。設定がシンプルで、すぐに完了するためです。
  • グローバル スケールで構築する場合や、常に稼働している必要がある場合は、最初から水平スケーリングを計画することをおすすめします。設計には手間がかかりますが、後で大きな問題が発生するのを防ぐことができます。

Google Cloud でシームレスにスケーリング

Google Cloud は、スケーリング戦略に合わせて調整できるさまざまなデータベース ツールを備えています。スケールアップのシンプルさが必要な場合でも、スケールアウトの大容量パワーが必要な場合でも、これらのプロダクトが役立ちます。

次のステップ

$300 分の無料クレジットと 20 以上の Always Free プロダクトを活用して、Google Cloud で構築を開始しましょう。

  • Google Cloud プロダクト
  • 100 種類を超えるプロダクトをご用意しています。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。また、すべてのお客様に 25 以上のプロダクトを無料でご利用いただけます(毎月の使用量上限があります)。
Google Cloud