分散アーキテクチャの過去と現在を理解するために、1つの画像で段階的に説明します。

  [[267639]]

目次：

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

• 分散アーキテクチャの進化
• 分散型サービスが直面する問題
• 分散アーキテクチャとは何ですか?

分散システムは、ネットワーク上に構築されたソフトウェア システムです。典型的な特徴が 2 つあります。

• 結合性: 各データベース分散ノードは高度に自律しており、ローカル データベース管理システムを備えています。
• 透明性: 各データベース分散ノードはユーザーのアプリケーションに対して透過的であり、ローカルであるかリモートであるかを判別することはできません。

つまり、分散システムでは、ユーザーはデータが分散されていることを実感できず、データが分割されているかどうか、コピーがあるかどうか、データがどのノードに存在するかを知ることができません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ある日突然、システムへのアクセスが再び遅くなり始めたことに気付きました。この時、まずデータベースをチェックしたところ、圧力は正常であることがわかりました。その後、Web サーバーをチェックしたところ、Apache が多くのリクエストをブロックしていることがわかりました。

アプリケーション サーバーは、各リクエストに対しても比較的高速です。リクエスト数が多すぎるため、サーバーが待機状態になり、応答速度が遅くなっているようです。

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

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

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

注: システム トラフィックが急激に増加した期間の後、システムが再び遅くなり始めたことがわかりました。今回は何が起こったのですか？

調査の結果、データベースの書き込みおよび更新操作における一部のデータベース接続のリソース競合が非常に激しく、システムの速度低下を引き起こしていることがわかりました。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（９）事業分割

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

説明: ますます複雑化するビジネス シナリオに対処するために、通常、システム ビジネス全体は分割統治法によって異なる製品ラインに分割されます。アプリケーションはハイパーリンクを介して接続され、データはメッセージ キューを介して配布することもできます。

もちろん、多くの場合、同じデータ ストレージ システムにアクセスすることによって、完全で関連性のあるシステムが形成されます。

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

垂直分割は比較的簡単です。これは、事業を分類し、関連性の低い事業を売却することによって実現できます。

水平分割: 再利用されたビジネスを分割し、分散サービスとして独立して展開します。新規ビジネスでは、これらの分散サービスを呼び出すだけで済みます。

水平分割には、再利用可能なビジネスの特定、サービス インターフェイスの設計、およびサービス依存関係の標準化が必要です。

（10）分散サービス

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

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

分散型サービスはどのような問題に直面していますか?

• サービスの数が増えると、サービス URL 構成の管理が非常に困難になり、F5 ハードウェア ロード バランサの単一ポイントの圧力が増大します。
• システムがさらに発展するにつれて、サービス間の依存関係が複雑かつわかりにくくなり、どのアプリケーションをどのアプリケーションより先に起動すべきかさえ不明瞭になります。アーキテクトはアプリケーションのアーキテクチャ上の関係を完全に説明することはできません。
• その後、サービス呼び出しの回数が増えると、サービスの容量の問題が露呈します。このサービスをサポートするには何台のマシンが必要ですか?マシンはいつ追加する必要がありますか?
• サービスが増えると、通信コストも上昇し始めます。サービスが失敗した場合は誰に連絡すればよいですか?サービスの合意されたパラメータは何ですか?
• サービスに複数のビジネス コンシューマーがある場合、サービスの品質をどのように確保すればよいでしょうか?
• サービスは絶えずアップグレードされるため、キャッシュ エラーによるメモリ オーバーフローなど、予期しないことが常に発生します。失敗は避けられません。コアサービスに障害が発生するたびに、広範囲に影響が及び、人々はパニックに陥ります。障害の影響をどのように制御しますか?サービス機能をダウングレードすることはできますか？それとも資源の劣化でしょうか?