※このブログは2024年2月14日に公開された英語ブログ「What is Database Sharding? An Architecture Pattern for Increased Database Performance」の拙訳です。
データベースシャーディングは、データをチャンクと呼ばれるかたまりに分割し、それを複数のデータベースサーバー (またはデータベースインスタンス ) に「インテリジェント」に分散させることで、データベースのパフォーマンスを向上させるデータアーキテクチャ戦略です。これらのデータチャンクは「シャード」と呼ばれ、各シャードはデータのサブセットを含んでいます。すべてのシャードによって全体のデータセットを表し、各データの行は1つのシャードのみに存在します。
シャーディングは、複数のマシンで処理を行うことで、データベースがより多くのトランザクションを処理し、より多くのデータを保存できるようにします。データベースシャーディングは、スケーラビリティが必要な大規模な分散環境に非常に効果的です。
データベースシャードは、シェアード・ナッシング・アーキテクチャの一例です。各シャードは独立したデータベースサーバーであり、他のシャードとコンピューティングリソースを共有することはありません。シャードはデータベースのデータのサブセットを表し、すべてのシャードが全体のデータセットを構成しています。
以下の図の左側は、1 台のコンピューター上のテーブル (「Original Table」と表示) を示しています。
元のテーブルが非常に大きい場合、そのクエリには時間がかかります。しかし、シャーディングアーキテクチャに変更すると、クエリパフォーマンスを向上させることができます。図の右側に示されているように、テーブルはシャーディングされ、データの一部はデータベースサーバーDB1に存在し、残りはデータベースサーバーDB2に存在します。これがシャーディングであり、データを分割して複数のサーバーに分散させるプロセスです。
データベースのシャーディングを設定する際、どのようにデータを分割するかによって、高速なデータベースになったり、非常に低速なデータベースになったりします。このトピックについては、後のセクションで再度取り上げる予定です。
このブログ記事では、データベースシャーディングの背後にある概念を深く掘り下げ、この人気のアーキテクチャパターンを定義するすべての詳細を深掘りしていきます。
従来のデータベースの制限事項
従来のデータベースは通常、単一のマシン上で運用されます。これらのマシンはサーバー、仮想マシン (VM)、またはノードと呼ばれることがありますが、呼び方に関わらず、パフォーマンスには上限があります。
このパフォーマンスの限界は、最終的にデータベースをより高性能なマシンに移行する必要があることを意味します。「より高性能な」コンピュータという表現を聞いたときには、すぐに「非常に高価」と連想したことでしょう。データベースのサイズが急激に成長する状況では、キャパシティを確保するために必要以上のコンピューティングパワーを支払うことになります。一度データベースが現在のマシンの能力を超えると、より大きく、さらに高価なマシンに移行するプロセスを繰り返すことになります。
この状況に対処する方法はもう一つありますが、これは高価で複雑です。それは新しいデータベースマシンを環境に追加することができます。ただし、これにはデータを複数のマシンにインテリジェントに分散させる何らかの方法が必要です。これは、複数のデータベースサーバーに対してソフトウェアレイヤーを追加するか、アプリケーションにこの機能を組み込むことで実現できます。この手法は非常に一般的であり、「データベースシャーディング」と呼ばれています。
データベースシャーディングとパーティショニングの違い
データベースシャーディングが複数のデータベースサーバー (複数のマシン) にデータチャンクを戦略的に分散させることであることを理解したので、次にそれをパーティショニング (単一のマシン) と対比させてみましょう。パーティショニングは、データベースのデータを何らかのキーに基づいて分割する点でシャーディングに似ています。しかし、主な違いは、その範囲とデータの分割方法にあります。
パーティショニングでは、分割は単一のデータベースサーバー内で行われます。データは「パーティション」と呼ばれるセグメントに分割されますが、1つのデータベースシステムの下に留まります。これは、複数の倉庫 (シャード) に商品を分散させるのではなく、単一の倉庫内で異なるセクションを整理するようなものです。各パーティションはシャードのように全体のデータセットのサブセットを保持しますが、シャーディングとは異なり、すべてが同じデータベースサーバー内に存在します。このアプローチは、大きなテーブルの管理に特に有益であり、複数のサーバーに負荷を分散させることなくクエリパフォーマンスを向上させることができます。
以下の図の左側は前のものと似ています。主な違いは、元のテーブルがチャンクに分割されており、それが単一のデータベースサーバー上に存在する点です。シャーディングされたデータは複数のデータベースサーバーに分散されています。
データベース・シャーディングがスケーラビリティのために異なるデータベースにデータを分割・分散するのに対し、パーティショニングは効率的な管理とアクセスのために単一のデータベース内でデータを整理します。どちらもパフォーマンスの向上を目的としていますが、その方法は異なります。
ここでは詳しくは触れませんが、パーティショニングとシャーディングを単一のデータベースアーキテクチャに組み合わせることは非常に一般的です。したがって、パーティショニングとシャーディングはどちらか一方だけではなく、両者を組み合わせることができることを覚えておいてください。
データベースをシャーディングすべきタイミング
データベースをシャーディングするかどうか、またそのタイミングを決定することは、ビジネスを拡大する適切なタイミングを選ぶことに似ています。つまり、タイミングと必要性が重要です。データベースシャーディングは一律に適用できる解決策ではなく、独自の複雑さを伴います。
シャーディングのタイミング
- 高トラフィックと大規模データ量：データベースが数百万のユーザーやテラバイトのデータの負荷に苦しんでいる場合、シャーディングを検討するタイミングです。
- スケーラビリティの必要性：ビジネスが急速に拡大しており、継続的なデータとユーザーベースの成長が予想されるとき。
- パフォーマンスの低下：クエリの応答が遅くなり、データベースレベルでのボトルネックを示している場合。
シャーディングを行うべきでないタイミング
- 小規模から中規模のデータベース：ストレージや処理能力の上限に達していないデータベースの場合。
- シンプルなワークロード：複雑なクエリや高いトランザクションレートを経験していないデータベース。
- 限られた技術リソース：シャーディングの実装と管理には高度な専門知識が必要です。チームがその複雑さに対応できない場合は、実施を見送るか (またはよりシンプルな解決策を探すべきです) 。
データベース・シャーディングは強力なツールですが、必ずしも最初に使うべきものではありません。慎重に考慮し、データベースのニーズや課題に適しているかを確認してください。
最適なシャーディングアーキテクチャとは
データベースシャーディングについて理解したので、次はそれを実装する方法を理解する必要があります。これには多くの方法がありますが、幸いなことに、すべての方法は同じ概念に基づいています：シャーディングキーを使用してデータをシャードに分散させることです。
これらのアーキテクチャーにはそれぞれ長所と短所があり、その選択は対象となるデータベース固有の要件や特性に大きく依存します。そのため、その選択はデータベース固有の要件や特性によって大きく左右されます。
キーに基づくデータベースシャーディング
キーに基づくシャーディングでは、ユーザーIDやタイムスタンプなどの特定の値をシャーディングキーとして利用します。
以下の図でこれを確認できます。このアプローチでは、データの行がどのシャードに配置されるかを決定するためにキーを選ぶ必要があります。図では、シャードキーとして「Column 1 (列1)」を選択しています。次に、データ項目にハッシュ関数を適用します。このハッシュキーによって、データがどのシャードに送られるかが決定されます。
キーベースのシャーディングは、均等に分散されたデータには理想的ですが、データが大きくなるにつれて調整が複雑になる可能性があります。
このシャーディング方法では、特定のキー (ユーザーIDなど) に対してハッシュ関数を使用してデータをシャードに割り当てます。これによりデータの均等な分散が確保されますが、シャードの追加や削除を行う際には、既存のデータの再配置が必要になるため、複雑さが増すことがあります。
範囲ベースのデータベースシャーディング (水平シャーディング)
範囲ベースのシャーディングでは、データは日付範囲や地理的位置などの値の範囲に基づいて分割されます。
以下の図では｢Paint Color｣列に基づいてシャーディングを行うことにしました。Paint Colorは数値コードです。データベースはこのコードを取り、シャードの範囲を使用してデータをどこに配置すべきかを決定します。
範囲ベースのシャーディングは、明確に直線的に分割されたデータには効果的ですが、データの分散が不均一になる可能性があります。
このアプローチでは、アルファベット順や日付範囲などの範囲に基づいてデータを分割します。シンプルでタイムシリーズデータには最適ですが、特定の範囲に他の範囲よりも多くのデータが集中する場合 (いわゆるホットスポット) 、データの分散が不均一になることがあります。
垂直データベースシャーディング
垂直シャーディングでは、データをテーブルのカラムに基づいて分割し、異なるカラムをさまざまなシャードに分散させます。このパターンは、幅の広いテーブルを複数のテーブルに分割するために使用されます。一方のテーブルは、もう一方よりも狭くなります。この狭いテーブルには、最もよくクエリされるデータが含まれます。稀に2番目のテーブルのデータが必要になった場合は、2つ目のテーブルと1つ目のテーブルを結合します。
垂直シャーディングは、あまり使用されていない大きなカラムを持つテーブルに適しており、頻繁にアクセスされるデータを分離することでパフォーマンスを向上させます。
この戦略は、分析が行われる環境で特に有用です。分析ワークロードは、非常に幅の広いテーブルにアクセスする必要があることが一般的です。ただし、複数のシャードに同時にアクセスする必要があるクエリが複雑になる可能性があります。
ディレクトリベースのデータベースシャーディング
ディレクトリベースのシャーディングは、テーブルのカラムに基づいてデータを分割し、さまざまなシャードに異なるカラムを分散させます。
以下の図では、以前使用した｢Paint Color｣カラムを再確認しています。この例では、ディクショナリ (ルックアップテーブルとも呼ばれる) を使用して、特定のシャードにデータを配置しています。
ディレクトリベースのシャーディングは、あまり利用されていない大きなカラムを持つテーブルに適しており、頻繁にアクセスされるデータを分離することでパフォーマンスを向上させます。
このシャーディング方法では、どのデータがどのシャードにあるかを追跡するためにルックアップディレクトリを使用します。柔軟性が高く、不均一な分散にもうまく対応できますが、ルックアップディレクトリが単一の障害点となるリスクがあります。また、ディレクトリのメンテナンスと整合性も重要な考慮事項です。
手動シャーディングと自動シャーディングデータベース
すでにシャーディング戦略については議論しましたが、最も重要な詳細については触れていませんでした。それは、誰がシャーディングを担当するのかということです。別の言い方をすると、データベースを手動でシャーディングすることも、ミドルウェア層やデータを自動的に効果的にシャーディングするように設計されたデータベースを使用することもできます。
それでは、手動シャーディングまたは自動シャーディングデータベースを実装するために使用できる具体的な実装方法を見ていきましょう。
自動シャーディング：分散型SQLデータベースの利用
分散型SQLデータベースは、ネイティブで自動シャーディングをサポートしており、スケーラビリティとメンテナンスを簡素化します。
- 長所：内蔵のシャーディング、スケーラビリティ、高可用性、そして軽減されたメンテナンス。データを自動的にシャーディングするためにゼロから設計されています。
- 短所：既存システムからの移行や新たな運用専門知識が必要になる場合があります。公平を期すために言うと、すべてのシャーディングソリューションは環境の変更や新しいスキルの習得を必要とします。自動シャーディング用に設計されたデータベースを使用することが、長期的に最良の解決策です。
自動シャーディング：ミドルウェアソリューション
MySQLデータベースといっしょに、ProxySQLやVitessのようなミドルウェアを使用します。これらのツールは、アプリケーションとデータベースの間に位置し、シャーディングロジックを透過的に処理します。
- 長所：シャーディングプロセスを簡素化し、アプリケーションには透過的です。
- 短所：管理すべきレイヤーが増え、技術の取得が必要となる可能性があります。これにより、ソフトウェア、ハードウェア、管理コストが増加することがあります。
手動か自動シャーディングか： 組み込みのシャーディング機能を持つデータベースの使用
MySQL ClusterやMariaDBなどのデータベースは、MySQLに特化したシャーディングソリューションのために組み込みのシャーディング機能を提供します。
- 長所：MySQLエコシステムとのネイティブな統合
- 短所：シャーディング機能が後から追加されたため、他の分散型SQLデータベースに比べて柔軟性が劣る可能性があります。分散型SQLデータベースは、最初から自動シャーディングをサポートするように設計されています。
手動シャーディング：アプリケーションレイヤーのシャーディング
アプリケーションのロジックを変更して、データを複数のデータベースインスタンスに分散させます。このアプローチでは細かな制御が可能ですが、かなりの開発作業が必要になります。
- 長所：シャーディング・ロジックを高度に制御することが可能です。
- 短所：大規模な開発とメンテナンス作業が必要です。スケールアウトには多くの計画が必要となり、実行する際にはシステムが一時的に利用できなくなることが一般的です。このアプローチを実装することは、アプリケーションのライフサイクル全体にわたって繰り返されるコンサルティングプロジェクトが発生します。大変ですね！
要約すると、データベースシャーディングは多くの作業を伴う可能性があります。以下は、このタイプのプロジェクトが実際にどのようなものか、全体像を大まかに説明したものです。
データベースシャーディングプロジェクトのステップ
- シャーディングのニーズの特定：データベースを評価し、シャーディングの必要性を理解します。データ量、トランザクションレート、パフォーマンスの問題などの要素を考慮します。
- コンピューティングおよびストレージのニーズの決定：このプロセスの中で最も重要なステップの一つです。オンプレミスのデータベースをシャーディングする場合は、ハードウェアを購入する必要があるかもしれません。このステップでは、ハードウェアを選定します。クラウド環境で運用している場合は、必要な仮想マシンやストレージのコストを見積もります。また、ソフトウェアも忘れずに。追加のライセンスや製品が必要になることがあります。オープンソースソフトウェアを使用している場合は (賢い選択です)、サポート契約を増やす必要があるかもしれません。
- テスト環境の作成：テスト環境は多くの状況でプロセスを簡素化します。痛い思いをしますが、テスト環境を破壊するのは本番システムを壊すよりはるかによいです。テスト環境を追加するために、サイジングの計画書に戻ることを忘れないでください。
- コンピューティングおよびストレージリソースの取得：ハードウェアを注文し、必要なソフトウェアのライセンスを取得することを忘れないでください。
- シャーディング戦略の選択：キーベース、範囲ベース、垂直、ディレクトリベースのいずれかを選択します。データ構造と使用パターンに合わせて決定することが必要です。
- シャーディングキーの選択：このキーは、シャード間でデータがどのように分散されるかを決定します。バランスの取れたデータ分散を保証し、複雑なクロスシャード・クエリを最小限に抑えるキーを選びます。
- シャーディングロジックの実装：アプリケーションレベルでこれを行うことができます。データベースサーバーの上にシャーディングレイヤーを追加するか、自動シャーディングをサポートするデータベース管理システムを使用します。
- 徹底的な検証：本番稼働前にシャーディングされたデータベースを徹底的にテストし、データの整合性とパフォーマンスを確認します。
- モニタリングと最適化：実装後は、シャーディングされたデータベースのパフォーマンスを継続的に監視し、必要に応じてシャードのバランスを調整します。
データベースシャーディングの最適な長期ソリューションとは？
既に示したように、適切なデータベースシャーディング戦略を選択することは難しい場合があります。しかし組織の成長に合わせて進化できる、より良い選択肢があります。
PingCAPによって開発されたTiDBは、組み込みの自動シャーディングを持つ先進的なオープンソースの分散型SQLデータベースです。これは、柔軟性のあるスケーリング、リアルタイム分析、データへの継続的なアクセスを提供することで、最新のアプリケーションを強力にサポートします。TiDBをスケールアウトRDBMSやインターネットスケールのOLTPワークロードに使用する企業は、以下のような利点を活用できます。
- MySQL互換：TiDBはMySQL 8.0とプロトコル互換性があるため、開発者はデータベースの豊富なツールやフレームワークのエコシステムを引き続き利用できます。
- 水平方向の拡張性：TiDBは手動シャーディングなしでデータワークロードに対する完全な透明性を提供します。このデータベースのアーキテクチャは、コンピュートとストレージを分離しているため、必要に応じてデータワークロードを瞬時にスケールアウトまたはスケールインできます。
- 高可用性：TiDBは、自動フェイルオーバーと自己修復を保証しており、システムの障害やネットワークの不具合が発生してもデータへの継続的なアクセスを確保します。
- 強力な一貫性：TiDBは、データをグローバルに分散させる際にもACIDトランザクションを維持します。
- 混合ワークロードに対応：効率的な技術スタックにより、リアルタイム分析の実行が容易になります。TiDBのスマートなクエリオプティマイザーは、複数のオペレーターからなる最も効率的なクエリ実行計画を選択します。
- ハイブリッドおよびマルチクラウド対応：TiDBを使用することで、ITチームは世界中のどこにでもデータベースクラスターを展開でき、パブリック、プライベート、ハイブリッドクラウド環境でVM、コンテナ、またはベアメタル上で運用できます。
- オープンソース：Apache 2.0ライセンスのもとで100%オープンソースの分散データベースを活用し、ビジネスの革新を実現しましょう。
- 安全性：TiDBは、データをネットワーク転送中およびディスク保存時の両方でエンタープライズグレードの暗号化によって保護します。
TiDBは、GoogleのSpannerやF1データベースから影響を受けています。しかし、TiDBはグローバルに分散したファイルシステムを必要とせずに、同様の機能を提供することを目指しています。
まとめ
データベースシャーディングの複雑さや戦略を考慮してきた中で、シャーディングが大規模データや高いトランザクションボリュームを処理するための堅牢なソリューションを提供する一方で、普遍的な解決策ではないことが明らかになりました。特に手動でシャーディングを実装する場合、この点は特に重要です。シャーディングの決定は、データベースのサイズや成長の軌道、利用可能な技術リソースを慎重に考慮した上で行うべきです。
最終的に、シャーディングを選択するか別の戦略を採用するかにかかわらず、目指すところは同じです。それは、データベースがスケーラブルで効率的、メンテナンスが容易であり、現在および将来のアプリケーションのニーズをサポートできるようにすることです。
TiDBのような自動シャーディングを実装した分散型SQLデータベースは、これらの利点を同時に実現します。これにより、必要に応じてシステムを拡大したり縮小したりでき、データベースシャーディングの複雑さを扱いつつ、大量のデータに対して優れたパフォーマンスを提供します。
その他のリソース
TiDB Cloud Dedicated
TiDB Cloudのエンタープライズ版。
専用VPC上に構築された専有DBaaSでAWSとGoogle Cloudで利用可能。
TiDB Cloud Serverless
TiDB Cloudのライト版。
TiDBの機能をフルマネージド環境で使用でき無料かつお客様の裁量で利用開始。