データのパーティション分割戦略 (Building Real World Cloud Apps with Azure)
作成者: Rick Anderson、Tom Dykstra
Fix It プロジェクトのダウンロードまたは電子書籍のダウンロード
電子書籍『Building Real World Cloud Apps with Azure』は、Scott Guthrie が開発したプレゼンテーションに基づくものです。 これは、クラウド向け Web アプリの開発を成功させるために役立つ 13 のパターンとプラクティスについて説明しています。 このシリーズの詳細については、最初のチャプターを参照してください。
以前に、Web サーバーを追加および削除することで、クラウド アプリケーションの Web 層を簡単にスケーリングできる方法を紹介しました。 ただし、それらがすべて同じデータ ストアにアクセスしている場合、アプリケーションのボトルネックはフロントエンドからバックエンドに移動しますが、データ層のスケーリングは非常に困難です。 この章では、データを複数のリレーショナル データベースにパーティション分割したり、リレーショナル データベース ストレージを他のデータ ストレージ オプションと組み合わせたりすることで、データ層をスケーラブルにする方法について説明します。
パーティション構成の設定は、以前に説明したのと同じ理由で、アプリが運用された後にデータ ストレージ戦略を変更するのは非常に困難であるため、事前に設定しておくのが最も良い方法です。 事前にさまざまなアプローチについてよく検討しておけば、アプリのデータやデータ アクセス コードを再構成している間に、アプリがクラッシュしたり長時間停止したりして "Twitter の瞬間" に陥る事態を避けることができます。
データ ストレージの 3 V
パーティション分割戦略の要否とその内容を決定するには、データに関する次の 3 つの質問について検討します。
- 容量 (Volume) - 最終的に保存するデータの量はどのくらいですか? 数ギガバイトですか? 数百ギガバイトですか? テラバイトですか? ペタバイトですか?
- 速度 (Velocity) - データの増加率はどのくらいですか? 大量のデータを生成しない社内アプリですか? 顧客が画像や動画をアップロードする外部アプリですか?
- 多様性 (Variety) - どのような種類のデータを保存しますか? リレーショナル、画像、キーと値のペア、ソーシャル グラフのうちのどれですか?
容量、速度、または多様性が高いことが予想される場合は、アプリの拡大に合わせて効率的かつ効果的にスケーリングでき、ボトルネックが発生しないよう、最適なパーティション構成を慎重に検討する必要があります。
パーティション分割には基本的に 3 つの方法があります。
- 垂直的パーティション分割
- 行方向のパーティション分割
- ハイブリッド パーティション分割
垂直的パーティション分割
垂直分割は、テーブルを複数の列に分割するようなもので、列セットごとに別のデータ ストアが割り当てられます。
たとえば、アプリが人物に関するデータを保存しており、そのデータには画像も含まれているとします。
このデータをテーブルして表現し、さまざまな種類のデータを確認すると、左側の 3 つの列はリレーショナル データベースで効率的に保存できる文字列データであり、右側の 2 つの列は基本的に画像ファイルから得られるバイト配列であることがわかります。 リレーショナル データベースには画像ファイル データを保存でき、ファイル システムにデータを保存したくないという理由で、多くのユーザーが実行しています。 必要な量のデータを保存できるファイル システムがない場合や、バックアップと復元用のシステムを別に管理したくない場合があります。 この方法は、オンプレミス データベースやクラウド データベース内の少量のデータには適しています。 オンプレミス環境では、DBA ですべてを管理する方が簡単かもしれません。
ただし、クラウド データベースではストレージは比較的高価であり、大量の画像によりデータベースのサイズが効率的に動作できる限度を超えてしまう可能性があります。 これらの問題は、データを垂直方向にパーティション分割することで解決できます。つまり、データのテーブルの各列に最適なデータ ストアを選択します。 この例に最も適した方法は、文字列データをリレーショナル データベースに、画像を BLOB ストレージに保存することです。
データベースではなく BLOB ストレージに画像を保存する方法は、オンプレミス環境よりもクラウドの方が実用的です。ファイル サーバーの設定や、リレーショナル データベースの外部に保存されたデータのバックアップと復元の管理を心配しなくて済むためです。これらはすべて、BLOB ストレージ サービスによって自動的に処理されます。
これは、Fix It アプリに実装したパーティション分割方法です。コードについては、BLOB ストレージの章で説明します。 このパーティション構成を採用せず、平均画像サイズを 3 メガバイトと仮定した場合、Fix It アプリでは最大データベース サイズの 150 ギガバイトに達するまでに、約 40,000 件のタスクしか保存できません。 画像を削除すれば、データベースには 10 倍のタスクを保存できます。水平方向のパーティション構成の実装を考える必要が出てくるのは、ずっと先のことになります。 また、アプリが拡大しても、ストレージ ニーズの大半が非常に安価な BLOB ストレージに割り当てられるため、コストの増加はより緩やかになります。
水平的パーティション分割 (シャーディング)
水平分割は、テーブルを複数の行に分割するようなもので、行セットごとに別のデータ ストアが割り当てられます。
同じデータ セットであれば、顧客名の範囲ごとに別のデータベースを割り当てることもできます。
ホット スポットを回避するため、データが均等に分散されるよう、シャーディング構成には十分注意する必要があります。 この単純な例では、姓の頭文字を使用していますが、姓は特定の一般的な文字で始まる人が多いため、この要件を満たしていません。 ほとんどのデータベースは小規模のままですが、一部のデータベースは非常に大規模になるため、予想よりも早くテーブル サイズの上限に達します。
水平方向のパーティション分割の欠点は、すべてのデータにまたがるクエリを実行するのが難しい場合があることです。 この例では、アプリが保存するすべてのデータを揃えるには、最大 26 個の異なるデータベースからデータを取得する必要があります。
ハイブリッド パーティション分割
垂直方向と水平方向のパーティション分割を組み合わせることができます。 たとえば、このデータ例では、画像を BLOB ストレージに保存し、文字列データを水平方向にパーティション分割できます。
運用アプリケーションのパーティション分割
概念的には、パーティション構成がどのように機能するかは簡単に理解できますが、パーティション構成はコードの複雑性を高め、対処しなければならない多くの新たな問題が発生します。 画像を BLOB ストレージに移動している場合に、ストレージ サービスが停止したらどうしますか? BLOB のセキュリティはどのように管理しますか? データベースと BLOB ストレージの同期が切れた場合はどうなりますか? シャーディングを行っている場合、すべてのデータベースにまたがるクエリをどのように処理しますか?
この問題は、運用環境に移行する前に計画しておけば管理できます。 計画しなかった多くのユーザーが、計画しておけばよかったと後悔しています。 カスタマー アドバイザリ チーム (CAT) は、アプリが急成長を遂げているにもかかわらず、このような計画を立てていなかったお客様から、平均で月に 1 回程度パニック状態の電話を受けます。 そして、お客様はこう言うのです。「助けてください。 すべてのデータを 1 つのデータ ストアに保存しているのですが、あと 45 日で領域が足りなくなってしまいます。」データ ストアへのアクセス方法に多くのビジネス ロジックが組み込まれ、アプリを使用している顧客がいる場合、移行中に 1 日停止できるタイミングはありません。 結局、お客様がダウン タイムなしでデータをその場でパーティション分割できるよう、大変な努力を強いられることになります。 これは非常に刺激的で、非常に恐ろしく、できれば避けたい仕事です。 このことを前もって考え、アプリに組み込んでおけば、アプリが拡大した後でも、作業がずっと楽になります。
まとめ
効果的なパーティション分割により、クラウド アプリがボトルネックなしでクラウド内のペタバイト単位のデータにスケーリングできるようになります。 また、オンプレミス データセンターでアプリを実行している場合のように、大規模なマシンや広範なインフラストラクチャに先行投資する必要もありません。 クラウドでは、必要に応じて容量を段階的に追加でき、使用する分だけ料金が発生します。
次の章では、BLOB ストレージに画像を保存して、Fix it アプリで垂直方向のパーティション分割を実装する方法について説明します。
リソース
パーティション分割戦略の詳細については、次のリソースを参照してください。
ドキュメント:
- Windows Azure Cloud Services で大規模なサービスを設計するためのベスト プラクティス。 Mark Simms と Michael Thomassy によるホワイト ペーパー。
- Microsoft パターンとプラクティス - クラウド設計パターン。 データ パーティション分割のガイダンス、シャーディング パターンを参照してください。
動画:
- FailSafe: スケーラブルで回復性の高い Cloud Services の構築。 Ulrich Homann、Marc Mercuri、Mark Simms による 9 部構成のシリーズ。 Microsoft カスタマー アドバイザリ チーム (CAT) での実際のお客様とのやり取りの経験に基づくストーリーを紹介しながら、おおまかな概念とアーキテクチャの原則について、活用しやすく興味深い方法で説明します。 エピソード 7 のパーティション分割に関する説明を参照してください。
- 大規模な構築: Windows Azure のお客様から学んだ教訓 - パート 1。Mark Simms が、パーティション構成、シャーディング戦略、シャーディングの実装方法、SQL Database Federations について、19:49 以降に説明しています。 FailSafe シリーズに似ていますが、より詳細な操作方法について説明します。
サンプル コード:
- Windows Azure のクラウド サービスの基礎。 シャーディングされたデータベースを含むサンプル アプリケーション。 実装されているシャーディング構成については、Windows Azure ブログの「DAL - RDBMS のシャーディング」を参照してください。