MySQLスケーラブル設計の基本原則

序文

情報量の急速な増加に伴い、ハードウェア機器の開発は徐々にアプリケーションシステムの処理能力要件に追いつかなくなってきました。この時点で、システムのパフォーマンス要件にどのように対処すればよいでしょうか?

唯一の方法は、システムのアーキテクチャを変革し、低処理能力のハードウェアデバイスを複数組み合わせて高処理能力のシステムを実現することで、システムのスケーラビリティを向上させることです。つまり、スケーラブルな設計を行う必要があります。

1. スケーラビリティとは何ですか?

スケーラビリティについて議論する前に、多くの友人が次のように尋ねるかもしれません。特定の Web サイトやシステムがスケーラビリティの観点からいかに適切に設計されているか、またそのアーキテクチャがいかに優れているかについて人々が話しているのをよく耳にしますが、スケーラビリティとは正確には何でしょうか。スケーラブルとは何ですか?スケーラビリティとは何ですか?実際、よく耳にする 3 つの言葉は、「スケール」、「スケーラブル」、「スケーラビリティ」です。

データベースの観点から見ると、スケールとは、データベースがより強力なサービス機能とより強力な処理機能を提供できることを意味します。スケーラブルとは、データベース システムが、対応するアップグレード (単一のマシンの処理能力の向上やサーバーの数の増加を含む) 後に、より強力な処理機能を提供できることを意味します。理論的には、どのデータベース システムもスケーラブルですが、必要な実装方法は異なります。

最後に、スケーラビリティとは、対応するアップグレードを通じてデータベース システムの処理能力を向上させることの難しさを指します。理論上は、どのシステムでも対応するアップグレードによって処理能力を向上させることができますが、異なるシステムで同じ処理能力を向上させるために必要なアップグレード コスト (資金と人的資源) は異なります。これが、さまざまなデータベース アプリケーション システムのスケーラビリティの大きな違いと呼ばれるものです。

ここで言及した異なるデータベース アプリケーション システムは、データベース ソフトウェア自体の違いを指すのではなく (データベース ソフトウェアが異なればスケーラビリティも異なる可能性があります)、同じデータベース ソフトウェアの異なるアプリケーション アーキテクチャ設計を指します。

まず、データベース システムのスケーラビリティは、実際には主に 2 つの側面に反映されることを理解する必要があります。1 つは水平方向の拡張であり、もう 1 つは垂直方向の拡張であり、後者はスケール アウトとスケール アップと呼ばれるものです。

スケールアウトとは、水平方向の拡張、外向きの拡張、つまり処理ノードを追加することで全体の処理能力を高めることを指します。より具体的に言えば、マシンを追加することで全体の処理能力を高めることを意味します。

スケールアップとは垂直的な拡張を意味し、現在の処理ノードの処理能力を高めることで、全体の処理能力を高めることを意味します。簡単に言えば、メモリの増設、CPU の増強、ストレージシステムのハードウェア構成の増強など、既存のサーバーの構成をアップグレードしたり、より強力な処理能力やより高度なストレージシステムを備えたサーバーに直接置き換えたりすることで実現します。

2 つのスケール方法を比較すると、それぞれの利点と欠点が簡単にわかります。

スケールアウトの利点:

1. 低コスト。低価格の PC サーバーを使用して、非常に強力な処理能力を備えたコンピューティング クラスターを簡単に構築できます。
2. ホストを追加することで処理能力を簡単に増強できるため、ボトルネックが発生しにくくなります。
3. 単一ノードの障害はシステム全体に与える影響は小さいですが、デメリットもあります。コンピューティング ノードが増えると、ほとんどの場合サーバー ホストになるため、システム全体のメンテナンスの複雑さが増します。いくつかの側面では、メンテナンス コストが確実に増加し、アプリケーション システムのアーキテクチャ要件がスケール アップよりも高くなり、クラスター管理ソフトウェアの連携が必要になります。
   

スケールアウトのデメリット:

1. 処理ノードの数が多いと、システム アーキテクチャの全体的な複雑さとアプリケーション プログラムの複雑さが増します。
2. クラスターのメンテナンスはより困難になり、コストもかかります。

スケールアップの利点:

1. 処理ノードが少なく、メンテナンスが比較的簡単です。
2. すべてのデータが集中管理されており、アプリケーションシステムのアーキテクチャがシンプルで、開発が比較的容易です。
   

スケールアップのデメリット:

ハイエンド機器は高価で、競争相手が少なく、メーカーによる制限を受けやすいです。
ハードウェア デバイスの開発速度によって制限されるため、単一ホストの処理能力は常に限られ、最終的に解決できないパフォーマンスのボトルネックが発生しやすくなります。
設備やデータが集中しているため、障害の影響が大きくなります。
短期的には、スケールアップは、運用と保守のコストを簡素化し、システム アーキテクチャとアプリケーション システム開発を簡素化し、技術要件も簡素化できるため、より大きな利点があります。

しかし、長期的な視点で見ればスケールアウトの方がメリットが大きく、システムが一定規模に達した後は避けられない流れでもあります。なぜなら、単一のマシンの処理能力は、どうしてもハードウェア技術によって制限され、ハードウェア技術の開発速度も常に制限されるため、ビジネス開発のスピードに追いつくのが難しい場合が多いからです。さらに、ハイエンド機器の処理能力が高くなるほど、コストパフォーマンスは必ず悪くなります。したがって、複数の安価な PC サーバーを使用して高処理能力の分散クラスターを構築することは、コストを節約し、全体的な処理能力を向上させるための企業にとって常に目標となります。この目標を達成する際にはさまざまな技術的な問題に遭遇する可能性がありますが、常に勉強して練習する価値はあります。

以下のコンテンツでは、分析と設計におけるスケールアウトの側面に焦点を当てます。適切にスケールアウトするには、分散システム設計が必要です。データベースの場合、より優れたスケールアウトを実現するためには、2 つの方向性しかありません。1 つは、データを継続的に複製して、完全に同一のデータ ソースを多数実現することで拡張を実現することです。もう 1 つは、集中化されたデータ ソースを多数のデータ ソースに分割することで拡張を実現することです。

次に、優れたスケーラビリティを備えたデータベース アプリケーション システム アーキテクチャを設計する際に従う必要がある原則を見てみましょう。

2. 取引の相関を最小化する原則

分散データベース クラスターを構築する場合、多くの人がトランザクションの問題を懸念します。結局のところ、トランザクションはデータベースの非常に重要な機能です。

従来の集中型データベース アーキテクチャでは、トランザクションの問題は非常に簡単に解決でき、データベース自体の非常に成熟したトランザクション メカニズムに依存することで完全に保証できます。ただし、データベースを分散アーキテクチャとして使用すると、元々単一のデータベースで完了していた多くのトランザクションが、複数のデータベース ホストにまたがる必要が生じる場合があります。このように、元の単一マシン トランザクションに分散トランザクションの概念を導入する必要が生じる場合があります。

しかし、分散トランザクション自体が非常に複雑なメカニズムであることを誰もがある程度理解する必要があります。大規模な商用データベースシステムであれ、さまざまなオープンソースデータベースシステムであれ、ほとんどのデータベースメーカーは基本的にこの機能を実装していますが、多かれ少なかれさまざまな制限があります。また、特定のトランザクションが確実に実行されなかったり、スムーズに完了しなかったりする原因となるバグもいくつかあります。

現時点では、この問題を解決するために他の代替手段を探す必要があるかもしれません。結局のところ、トランザクションを無視することはできません。どのように実装するにしても、常に実装する必要があります。

現在、主な解決策は 3 つあります。

まず、スケールアウトを設計する際には、分散トランザクションを回避するために、トランザクションに必要なデータが可能な限り同じ MySQL サーバー上にあるように、セグメンテーション ルールを合理的に設計します。

データ セグメンテーション ルールを設計する際に、すべてのトランザクションが単一の MySQL サーバー上で完了できることを保証できれば、ビジネス ニーズをより簡単に達成でき、アプリケーションは最小限の調整でアーキテクチャの変更に対応できるため、全体的なコストが大幅に削減されます。結局のところ、データベース アーキテクチャの変革は DBA の仕事だけではなく、多くの外部の協力とサポートも必要です。まったく新しいシステムを設計する場合でも、データベース自体のコスト投資だけでなく、対応する開発コストも含め、各環境と各作業への全体的な投資を考慮する必要があります。さまざまなリンク間で利益相反がある場合は、その後の拡張と全体的なコストに基づいてトレードオフを行い、現在の段階に最も適したバランスポイントを見つける必要があります。

ただし、シャーディング ルールが適切に設計されているとしても、すべてのトランザクションに必要なすべてのデータを同じ MySQL サーバー上に保持することは困難です。したがって、このソリューションはコストが最も低いものの、ほとんどの場合、コアとなる事柄のほとんどしか考慮できず、完璧なソリューションではありません。

2 番目に、大規模なトランザクションは複数の小規模なトランザクションに分割されます。データベースは各小規模なトランザクションの整合性を保証し、アプリケーションは小規模なトランザクション間の全体的なトランザクション整合性を制御します。

以前のソリューションと比較して、このソリューションでは、アプリケーションの変更がさらに多く行われ、アプリケーションに対する要件がより厳しくなります。アプリケーションは、元の大規模なトランザクションの多くを分割する必要があるだけでなく、各小規模トランザクションの整合性も確保する必要があります。言い換えれば、アプリケーション自体に特定のトランザクション機能が必要となり、アプリケーションの技術的な難易度が間違いなく高まります。

ただし、このソリューションにも独自の利点が数多くあります。まず、データ分割ルールがよりシンプルになり、制限に遭遇しにくくなります。シンプルになればなるほどメンテナンスコストも低くなります。第二に、データ セグメンテーション ルールにあまり多くの制限がないため、データベースはよりスケーラブルになり、あまり多くの制約を受けなくなります。パフォーマンスのボトルネックが発生した場合、既存のデータベースをすぐにさらに分割できます。最後に、データベースは実際のビジネス ロジックからさらに離れているため、その後のアーキテクチャ拡張が容易になります。

3 番目に、上記の 2 つのソリューションを組み合わせ、それぞれの利点を統合し、それぞれの欠点を回避します。

前述の 2 つのソリューションにはそれぞれ長所と短所があり、基本的には互いに矛盾しています。それぞれの利点を十分に活用し、2 つのソリューションの設計原則を調整して、全体的なアーキテクチャ設計のバランスをとることができます。たとえば、一部のコアトランザクションに必要なデータを同じ MySQL サーバー上に配置しながら、特に重要ではない他のトランザクションを小さなトランザクションに分割してアプリケーション システムと組み合わせることができます。さらに、特に重要ではない一部のトランザクションについては、トランザクションの使用が不可欠であるかどうかを詳細に分析することもできます。

このバランスのとれた設計の原則に従うことで、アプリケーション全体の整合性を確保するためにアプリケーションが多数の小さなトランザクションを処理する必要がなくなると同時に、複雑な分割ルールが多すぎてその後のメンテナンスが困難になり、スケーラビリティが妨げられる状況も回避できます。

もちろん、すべてのアプリケーション シナリオを上記の 2 つのソリューションを組み合わせて解決する必要はありません。たとえば、特に厳格なトランザクション要件を持たないアプリケーションや、トランザクション自体が非常に単純なアプリケーションの場合、わずかに設計された分割ルールによって関連する要件を満たすことができます。最初のソリューションを使用するだけで、アプリケーションが特定の小さなトランザクションの全体的な整合性を維持する必要がなくなります。これにより、アプリケーションの複雑さが大幅に軽減されます。

非常に複雑なトランザクション関係やデータ間の相関性が高いアプリケーションの場合、トランザクションデータを集中管理するために設計する必要はありません。どれだけ努力しても要件を満たすことは難しく、ほとんどの場合、全体像を見失う状況に遭遇するからです。この場合、データベースをできるだけシンプルに保ち、アプリケーションにいくつかの犠牲を払わせたほうがよいでしょう。

現在の多くの大規模インターネット アプリケーションでは、上記のすべてのソリューションが使用されています。たとえば、誰もがよく知っている eBay は、主に 3 番目のソリューションを組み合わせたものです。組み合わせのプロセスでは、2 番目のオプションがメイン オプションとなり、最初のオプションが補助オプションとなります。アプリケーション シナリオのニーズに加えて、このアーキテクチャを選択する理由は、その強力な技術力により、十分に堅牢なアプリケーション システムの開発も保証されるからです。もう 1 つの例は、国内の大規模な BBS アプリケーション システム (実名は非公開) です。トランザクションの相関関係は特に複雑ではなく、さまざまな機能モジュール間のデータ相関も特に高くありません。このシステムでは、1 つ目のソリューションを完全に採用し、データ分割ルールを合理的に設計することで、トランザクション データ ソースが複数の MySQL サーバーにまたがることを完全に回避しています。

最後に、トランザクションは多ければ多いほど良いが、少なければ少ないほど良く、小さければ小さいほど良いという点も理解しておく必要があります。どちらのソリューションを使用する場合でも、アプリケーションを設計するときには、データのトランザクション的関連性を低くするか、トランザクション的関連性の必要性を排除する必要があります。もちろん、これは相対的なものに過ぎず、確かに一部のデータだけがこれを行うことができます。ただし、データの特定の部分にトランザクションの関連性がなくなると、システム全体の複雑さが大幅に軽減され、アプリケーションとデータベース システムの両方にかかるコストが大幅に削減される可能性があります。

3. データ一貫性の原則

スケールアップするかスケールアウトするかに関係なく、またアーキテクチャをどのように設計するかに関係なく、データの最終的な一貫性を確保することは、違反してはならない原則です。すべての読者は、この原則を確保することの重要性を非常に明確に理解している必要があると思います。

さらに、データの一貫性を確保することは、トランザクションの整合性を確保することと同じです。システムをスケールアウトするように設計すると、いくつかの問題が発生する可能性もあります。もちろん、規模を拡大すれば、このようなトラブルに遭遇することは稀でしょう。もちろん、多くの人々の目には、データの一貫性も、ある程度はトランザクションの整合性の範疇に入ります。ただし、その重要性と関連する特性を強調するために、ここでは個別に分析します。

では、スケールアウトしながらデータの一貫性を確保するにはどうすればよいでしょうか?この問題は、トランザクションの整合性を確保するのと同じように、多くの場合私たちの頭を悩ませており、多くの建築家の注目を集めています。多くの人の練習を経て、ようやく全員がBASEモデルをまとめることができました。つまり、基本的に利用可能、柔軟な状態、基本的に一貫性があり、最終的に一貫性があるということです。 これらの言葉は複雑で深遠に思えるかもしれませんが、実際には、非リアルタイム一貫性の原則として簡単に理解できます。

つまり、アプリケーション システムは関連テクノロジを通じて実装され、システム全体では、ユーザーのニーズを満たしながら、データが短時間非リアルタイムの状態になることを許可し、後続のテクノロジを使用して、データが最終的に一貫した状態になることを保証します。この理論モデルは単純に聞こえますが、実際の実装では多くの困難に遭遇するでしょう。

まず、最初の質問は、すべてのデータを非リアルタイムで一貫性を保つ必要があるかどうかです。私の読者のほとんどは間違いなくこれに反対票を投じるだろうと思います。すべてのデータが非リアルタイム整合性ではない場合、どのデータがリアルタイムで整合性を保つ必要があり、どのデータが非リアルタイムの結果整合性のみを必要とするかをどのように判断すればよいでしょうか?実は、これは基本的に各モジュールの業務優先度の区分とも言えます。優先度の高いアプリケーションは、当然のことながら、データのリアルタイム整合性を確保する陣営に属し、やや優先度の低いアプリケーションは、短期間の不整合は許容するが、最終的には整合性を確保する陣営に分かれると考えられます。これは非常に難しい問題です。安易に決断することはできず、非常に詳細な分析と慎重な評価を経て決断する必要があります。すべてのデータがシステム内で短期間に不整合な状態で現れるわけではなく、すべてのデータが後で処理されて整合状態に達するわけでもないため、少なくともこれら 2 種類のデータはリアルタイムで整合している必要があります。これら 2 種類のデータを区別するには、ビジネス シナリオと商業ニーズを詳細に分析し、徹底的な評価を行って結論を導き出す必要があります。

第二に、システム内の不整合なデータを最終的に整合させるにはどうすればよいでしょうか?一般的に言えば、このタイプのデータ用に設計されたビジネス モジュールと、リアルタイムで一貫性のあるデータを必要とするビジネス モジュールを明確に分離する必要があります。その後、関連する非同期メカニズム技術と対応するバックグラウンドプロセスを通じて、現在不整合なデータは、システム内のデータ、ログ、およびその他の情報を通じてさらに処理され、最終データが完全に整合した状態になります。異なるモジュールに異なるバックグラウンド プロセスを使用すると、データの混乱を回避できるだけでなく、同時実行が可能になり、処理効率が向上します。ユーザーメッセージ通知などの情報については、厳密なリアルタイム一貫性を実現する必要はなく、処理が必要なメッセージを記録し、バックグラウンド処理プロセスで順番に処理することで、フォアグラウンド業務の混雑を回避できます。

最後に、リアルタイム整合性データと結果整合性データ間のフロントエンドのオンライン相互作用を回避します。 2 種類のデータ状態が不一致なため、相互作用プロセス中に 2 種類のデータが乱れる可能性が高くなります。リアルタイム整合性のないデータとリアルタイム整合性のあるデータは、アプリケーション内で可能な限り効果的に分離する必要があります。特殊なシナリオでも、異なる MySQL サーバーでレコードを物理的に分離する必要があります。

4. 高可用性とデータセキュリティの原則

上記の 2 つの原則に加えて、システムの高可用性とデータ セキュリティという 2 つの側面についても触れておきたいと思います。スケールアウト設計により、システム全体のスケーラビリティが大幅に向上し、全体的なパフォーマンスも自然に簡単に向上します。しかし、システム全体の可用性を維持することは以前よりも困難になっています。システム全体のアーキテクチャが複雑になるため、アプリケーションとデータベース環境は以前よりも大きく複雑になります。これによる最も直接的な影響は、メンテナンスが困難になり、システムの監視が困難になることです。

このような設計変更によってシステムが頻繁にクラッシュし、ダウンタイムが発生するようでは、誰も納得できないと思います。そのため、さまざまな技術的手段を駆使して、システムの可用性が低下しないようにし、さらには全体的に向上させる必要があります。

したがって、これは自然に、スケールアウト設計プロセスの別の原則、つまり高可用性の原則につながります。システム アーキテクチャをどのように調整しても、システム全体の可用性を低下させることはできません。

実際、システムの可用性について議論する場合、密接に関連する別の原則、つまりデータ セキュリティの原則を持ち出すのは自然なことです。高可用性を実現するには、データベース内のデータが十分に安全でなければなりません。ここで言うセキュリティとは、悪意のある攻撃や盗難ではなく、異常な損失を指します。言い換えれば、ソフトウェア/ハードウェア障害が発生した場合にデータが失われないようにする必要があります。データが失われると、まったく利用できなくなります。さらに、データ自体はデータベースアプリケーションシステムの中核リソースであり、失われてはならないという原則は疑う余地がありません。

高可用性とデータ セキュリティを確保する最善の方法は、冗長性メカニズムを使用することです。すべてのソフトウェアおよびハードウェア デバイスにより単一点のリスクが排除され、すべてのデータが複数のコピーで存在します。これがこの原則をより確実にする唯一の方法です。技術面では、MySQL Replication や MySQL Cluster などのテクノロジーを通じてこれを実現できます。

要約する

アーキテクチャをどのように設計するか、スケーラビリティがどのように変化するかに関係なく、この章で説明する原則のいくつかは非常に重要です。特定の問題を解決する原則、保証の原則、可用性を確保する原則、データ セキュリティを確保する原則など、設計時には常に注意を払い、念頭に置く必要があります。

MySQL データベースがインターネット業界で非常に人気がある理由は、そのオープン ソース特性と使いやすさに加えて、もう 1 つの非常に重要な要素として、スケーラビリティの面で大きな利点があることです。さまざまなストレージ エンジンの特性により、さまざまなアプリケーション シナリオに対応できます。レプリケーション機能とクラスタ機能は、スケーラビリティを向上させる非常に効果的な手段です。

上記は、MySQL スケーラブル設計の基本原則の詳細な内容です。MySQL スケーラブル設計の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。