分散アーキテクチャの過去と現在を10分で理解する

すべてのプログラマーにとって、分散アーキテクチャについて聞いたときの最初の反応は通常、それがハイエンドで、威圧的で、高級感があるというものです。例えば、アリババのさまざまなシステムは異なるマシンに展開されており、杭州、上海、深センなどの異なるサーバーにも分散されています。ファーウェイのサーバーも、世界中のユーザーのニーズを満たすことができるように、世界のさまざまな地域に分散されます。

さまざまな求人広告で、分散システムの開発に精通している人材を見かけることはよくあります。では、配布とは一体何でしょうか?こう言えば子供でも理解できます。

背景

分散とはモジュールでの開発と展開を意味し、分散の核となるのはモジュールであると考える人もいます。しかし、モジュール化は分散型の概念ではありません。 1990 年代初頭には、ソフトウェア機能をモジュールに従って分割することを提案する人もいました。ソフトウェアエンジニアリングでは、モジュールをより適切に分離することができ、作業では、モジュールをさまざまなタスクに適切に分割することもできます。モジュールで開発されていますが、同じマシンにデプロイされています。ソフトウェア、特にインターネットの発展に伴い、従来のモノリシックアーキテクチャはますます効果が低下しており、主に次の 3 つの側面に現れています。

パフォーマンスの問題: インターネット業界の初期の頃は、ハードウェアが非常に急速に発展し、ほぼすべての新しい世代のコンピュータチップのパフォーマンスが前世代の 2 倍になりました。しかし、ムーアの法則が期限切れとなり、ハードウェアの改善はソフトウェア業界の発展に追いつかなくなっています。チップの性能を 2 倍にするには、現在では数世代の製品が必要になるため、Intel は歯磨き粉を絞り出しているようなものだとよく言われます。そのため、モノリシックアーキテクチャのパフォーマンス問題が発生し、時代の変化に対応できなくなりました。
各モジュールは論理的に分離されているだけで、同じマシン上に展開されているため、拡張が困難です。各モジュールは、Yongyang の物理メモリ、同じハードディスク、同じネットワークカードを使用します。実際、各モジュールは、何千ものギアを備えた精密機械のように、互いに密接に依存しています。各モジュールの変更により、他のギアの回転が駆動されます。
システムの可用性が低いです。すべてのモジュールが同じマシン上に存在しないことは想像に難くありません。突然ディスク全体がいっぱいになったり、メモリがリークしたりするなど、1 つのモジュールに問題が発生すると、システム上の他のモジュールに影響が及び、システム全体がクラッシュすることになります。

特徴

従来のモノリシック構造と比較すると、分散アーキテクチャの最も重要な点は次のとおりです。

新しい機能の開発と実装が容易になります。従来のモノリシック構造では、モジュール間の依存関係が非常に深刻です。機能を実装する場合は、他のモジュールへの影響も評価する必要があります。分散設計では、モジュールはインターフェースを通じて相互に対話します。モジュールの内部実装は他のモジュールに対して透過的であり、影響は少なくなります。
単一点障害の影響は小さくなります。従来のモノリシックアーキテクチャの重大な問題は、1 つのモジュールに障害が発生すると、システム全体が簡単に使用できなくなる可能性があることです。簡単な例を挙げると、電子商取引システムでは評価システムはそれほど重要ではないかもしれません。しかし、ある日、評価システムに障害が発生し、メモリリークが発生してマシンが継続的に再起動するようになり、同じマシンに展開されている他のアプリケーションに影響を及ぼす可能性が高くなります。分散展開により、障害の可能性を大幅に減らすことができます。もちろん、分散にも障害の問題があり、優れた分散アーキテクトが合理的かつ適切なフレームワークを構築し、それを合理的に展開して、単一障害点による大規模な障害を回避する必要があります。
システムのスループットが向上します。以前のシングルポイント展開モジュールは、単一のマシンのパフォーマンスによって制限されていました。分散アーキテクチャでは、パフォーマンスのボトルネックがあるモジュールに対して、非同期を使用したり、より多くのマシンを展開したりすることで、単一マシンのパフォーマンスのボトルネックの問題を解決し、マシンの使用率を向上させることができます。簡単な例を挙げると、データベースモジュールではディスクのパフォーマンスと容量に対する要件が高くなります。より高性能なディスクを搭載したマシンに導入できます。 CPU とメモリ容量に対する要件が高いキャッシュの場合、より高いマシン使用率を実現できます。

分散は多くの問題を解決しますが、多くの欠点や困難も抱えているため、それらを克服して設計するにはプログラマーとアーキテクトが必要です。

主な困難

異機種混合システムには統一された標準はありません。分散システムでは、各モジュールは独自の開発言語と展開環境を選択でき、各システムは独自のデータ構造と通信プロトコルを選択できます。通信に HTTP プロトコルを使用したい人もいれば、Google の gRPC を使用したい人もいれば、Twitter の thrift を使用したい人もいるでしょう。さらに、プロトコル本体、エラーコード、エラーメッセージなどのデータ構造に一貫性がない可能性があり、開発に不便をもたらすだけでなく、統一された監視とガバナンスにも多くの問題をもたらします。
機械の台数が増えたために故障の可能性が高くなり、1 台の機械の性能や品質が以前ほど良くない可能性があります。同時に、保守や開発に携わる人数が増えると、単一の機械構造よりも単一の機械が故障する確率が高くなります。これは避けられない現象です。一度も失敗を経験したことのないエンジニアは、良いプログラマーとは言えません。そのためには、運用と保守を自動化しながら、障害の可能性と影響を軽減するための合理的な分散アーキテクチャを設計する必要があります。結局のところ、人は必ず間違いを犯しますし、頻繁に間違いを犯します。
サービス依存関係の問題に関しては、1 台のマシンがクラッシュしてもプログラム全体がクラッシュすると想定しないでください。これはモノリシックアーキテクチャでのみ発生します。分散環境には、いくつかの重要なサービスもあります。一度崩壊すると、ドミノ倒しのような現象が起こり、雪崩が発生することがよくあります。たとえば、ユーザーのログイン状態を維持するチャットソフトウェアのセッションサービスに障害が発生すると、すべてのサービスでログイン状態が失われ、サービス全体が利用できなくなる可能性があります。

やり方

分散によって生じる問題を解決するには、プログラマーやアーキテクトがスキルを発揮する必要があります。どのような方法を使用するかに関係なく、次の 2 つのことに他なりません。