分散アーキテクチャの進化についてお話ししましょう

1. 分散アーキテクチャとは何ですか?

分散システムは、ネットワーク上に構築されたソフトウェア システムです。

凝集性: 各データベース分散ノードが高度に自律しており、ローカル データベース管理システムを備えていることを意味します。

透明性: 各データベース分散ノードはユーザーのアプリケーションに対して透過的であり、ローカルであるかリモートであるかを判別できないことを意味します。

分散データ システムでは、ユーザーはデータが分散されているとは感じません。つまり、関係がパーティション化されているかどうか、コピーがあるかどうか、データがどのサイトに存在するか、トランザクションがどのサイトで実行されるかを知る必要がありません。

簡単に言えば、分散システムでは、独立したコンピューターのグループが、システムと同じように、ユーザーに統一された全体を提示します。

分散システムは、ユーザー全体にサービスを提供しており、MySQL サーバーを使用する場合と同様に、システム全体の内部連携はユーザーに対して透過的です。

たとえば、大量の同時データを処理する分散 MySQL ミドルウェア mycat などです。

2. 分散アーキテクチャの応用

1. 分散ファイルシステム

たとえば、有名なものとしては、Hadoop の HDFS、Google の GFS、Taobao の TFS などがあります。

2. 分散キャッシュシステム

例: memcache、hbase、mongdb など。

3. 分散データベース

たとえば、mysql、mariadb、postgreSql などです。

4. 分散Webサービス

5. 分散コンピューティング

例

分散MySQLデータベースミドルウェアmycatを例に挙げる

MySQL は現在、電子商取引やインターネット企業で広く使用されています。理由の 1 つは、無料かつオープンソースであることです。もう 1 つの理由は、分散システムの水平方向のスケーラビリティです。モバイルインターネットユーザーの爆発的な増加に伴い、Taobao、Tmall、Vipshopなどのインターネット企業やその他の電子商取引企業は、ユーザーの同時実行性と大量のデータの保存に対応するために分散システムを採用しています。 Mycat のビジネスケースでは、China Mobile の請求書決済プロジェクトにおいて、アプリケーションはピーク時に 1 日あたり 2 億のデータ ポイントをリアルタイムで処理しました。モノのインターネット プロジェクトでは、最大 26 億のデータ ポイントを処理し、リアルタイムのクエリ インターフェイスを提供しました。

MyCat の研究を通じて、分散システム アーキテクチャだけでなく、分散関連テクノロジ、分散一貫性 ZooKeeper サービス、高可用性 HAProxy/keepalived などの関連アプリケーションについての理解を深めることができます。

1> クラスターと分布

2> 負荷分散

3> 分散高可用性、災害復旧などに関する用語の説明

4> Mycatミドルウェアの学習

3. 分散アーキテクチャの進化

（１）初期段階のアーキテクチャ

特徴: アプリケーション、データベース、ファイルなどのすべてのリソースが 1 つのサーバーに配置されます。

（２）アプリケーションサービス、データサービス、ファイルサービスの分離

注: 良い時代は長くは続かなかった。システム トラフィックが再び増加すると、ピーク時間帯に Web サーバー マシンにかかる負荷が比較的高いレベルまで上昇することがわかりました。この頃、Web サーバーの追加を検討し始めました。

機能: アプリケーション、データベース、およびファイルは独立したリソースに展開されます。

（３）キャッシュを利用してパフォーマンスを向上させる

注: システム アクセス特性は 80/20 ルールに従います。つまり、ビジネス アクセスの 80% がデータの 20% に集中します。

キャッシュは、ローカル キャッシュとリモート分散キャッシュに分けられます。ローカル キャッシュはアクセス速度が速いですが、キャッシュされるデータの量が限られており、アプリケーションとのメモリの競合が発生します。

機能: 頻繁にアクセスされるデータベース データのごく一部がキャッシュ サーバーに保存されるため、データベース アクセスの回数が減り、データベース アクセスの負荷が軽減されます。

（4）「アプリケーションサーバー」クラスターの使用

注: データベースとテーブルのシャーディングのタスクを完了した後、データベースへの負荷は比較的低いレベルにまで軽減され、訪問者数が毎日急増するのを見ながら、再び幸せな生活を送り始めました。

ある日突然、システムへのアクセスが再び遅くなり始めたことに気付きました。この時、まずデータベースをチェックしたところ、圧力は正常であることがわかりました。次に、Web サーバーをチェックしたところ、Apache が多くのリクエストをブロックしている一方で、アプリケーション サーバーは各リクエストに対して比較的高速であることがわかりました。リクエスト数が多すぎるため、キューイングが発生し、応答が遅くなるようです。

特徴: 負荷分散により複数のサーバーが同時に外部にサービスを提供し、単一サーバーの処理能力とストレージ容量の制限の問題を解決します。

説明: クラスターの使用は、システムが高い同時実行性と大量のデータの問題を解決するための一般的な方法です。クラスターにリソースを追加することで、システムの同時処理能力が向上し、サーバーの負荷圧力がシステム全体のボトルネックになることがなくなります。

（５）データベースの読み書き分離

注: しばらくの間、システム アクセス ボリュームの急速な増加を楽しんだ後、システムが再び遅くなり始めたことがわかりました。今回は何が起こったのですか？調査の結果、データベースの書き込みおよび更新操作における一部のデータベース接続のリソース競合が非常に激しく、システムの速度が低下していることがわかりました。

特徴: 負荷分散により複数のサーバーが同時に外部にサービスを提供し、単一サーバーの処理能力とストレージ容量の制限の問題を解決します。

説明: クラスターの使用は、システムが高い同時実行性と大量のデータの問題を解決するための一般的な方法です。クラスターにリソースを追加することで、サーバーの負荷圧力がシステム全体のボトルネックになることはなくなります。

（6）リバースプロキシとCDNアクセラレーション

機能: CDN とリバース プロキシを使用してシステム アクセスを高速化します。

説明: 複雑なネットワーク環境やさまざまな地域のユーザーからのアクセスに対応するために、CDN とリバース プロキシを使用してユーザー アクセスを高速化し、バックエンド サーバーの負荷を軽減します。 CDN とリバース プロキシの基本原理はキャッシュです。

（７）「分散ファイルシステム」と「分散データベース」

注意: システムが実行し続けると、データの量が大幅に増加し始めます。この時点で、データベースを分割した後もクエリが少し遅いことがわかったので、データベースを分割するというアイデアに従ってテーブルを分割する作業が開始されました。

機能: データベースは分散データベースを使用し、ファイル システムは分散ファイル システムを使用します。

説明: 大規模システムの継続的に増大するビジネス ニーズを単一の強力なサーバーで満たすことはできません。ビジネスが発展するにつれて、データベースの読み取りと書き込みの分離では最終的にニーズを満たせなくなり、それをサポートするには分散データベースと分散ファイルシステムが必要になります。

分散データベースは、システム データベースを分割する最適な方法です。単一テーブルのデータ規模が非常に大きい場合にのみ使用されます。より一般的に使用されるデータベース分割方法は、異なる物理サーバー上に異なるビジネス データベースを展開するビジネス サブデータベースです。

（８）NoSQLと検索エンジンを使う

特徴: このシステムは NoSQL データベースと検索エンジンを導入します。

説明: ビジネスがますます複雑になるにつれて、データの保存と取得に対する需要もますます複雑になっています。システムでは、NoSQL などの非リレーショナル データベースや、検索エンジンなどの分散データベース クエリ テクノロジを採用する必要があります。

アプリケーション サーバーは、統合されたデータ アクセス モジュールを通じてさまざまなデータにアクセスし、複数のデータ ソースを管理するアプリケーション プログラムの煩わしさを軽減します。

（９）事業分割

特徴：業務に合わせてシステムを分割・再構築し、業務部門ごとにアプリケーションサーバーを個別に展開します。

説明: ますます複雑化するビジネス シナリオに対処するために、通常、システム ビジネス全体は分割統治法によって異なる製品ラインに分割されます。アプリケーションはハイパーリンクを介して接続され、データはメッセージ キューを介して配布できます。もちろん、多くの場合、それらは同じデータ ストレージ システムにアクセスして、完全で関連性のあるシステムを形成します。

垂直分割: 大きなアプリケーションを複数の小さなアプリケーションに分割します。新しいビジネスが比較的独立している場合は、独立した Web アプリケーション システムとして直接設計して展開します。垂直分割は比較的簡単です。事業を分類することで、関連性の低い事業を分離することができます。

水平分割: 再利用可能なビジネスを分割し、分散サービスとして個別に展開します。新規ビジネスでは、これらの分散サービスを呼び出すだけで済みます。水平分割には、再利用可能なビジネスの特定、サービス インターフェイスの設計、およびサービス依存関係の標準化が必要です。

（10）分散サービス

機能: 共通アプリケーション モジュールが抽出され、アプリケーション サーバー呼び出し用に分散サーバーに展開されます。

説明: ビジネスがますます小さな部分に分割されるにつれて、アプリケーション システム全体の複雑さは飛躍的に増大します。すべてのアプリケーションはすべてのデータベース システムに接続する必要があるため、最終的にはデータベース接続リソースの不足とサービス拒否が発生します。

4. 分散サービス アプリケーションはどのような問題に直面するでしょうか?

（１）サービス数が増えると、サービスURLの構成管理が非常に困難になり、F5ハードウェアロードバランサの単一点の圧力が増大します。

（２）開発が進むにつれて、サービス間の依存関係が複雑化・複雑化し、どのアプリケーションをどのアプリケーションより先に起動する必要があるのか​​が不明瞭になります。アーキテクトは、アプリケーション間のアーキテクチャ上の関係を完全に記述できなくなりました。

（３）その後、サービスコールの数が増加するにつれて、サービス容量の問題が明らかになります。このサービスをサポートするのに何台のマシンが必要でしょうか？いつマシンを追加すればよいですか?

（４）提供されるサービスが増えるにつれて、通信コストも上昇し始めます。サービスが失敗した場合は誰に連絡すればよいですか?サービス パラメータの規則は何ですか?

（５）サービスに複数のビジネスコンシューマーが存在する場合、どのようにしてサービスの品質を確保できるでしょうか？

（6）サービスは常にアップグレードされるため、誤ったキャッシュ書き込みによるメモリオーバーフローなど、予期しない事態が常に発生します。失敗は避けられません。コアサービスに障害が発生するたびに、広範囲に影響が及び、人々はパニックに陥ります。障害の影響をどのように制御できるでしょうか?サービスが低下する可能性はありますか?それとも資源の劣化でしょうか?