アリババの専門家が分散システムを詳しく説明し、大規模ウェブサイトへの分散システムの実用化を分析します。

分散システム

分散システムは、オリジナルの CORBA から EJB、Web、SOA へ、クラスターから現在の NoSQL クラウド コンピューティング、ビッグ データ Hadoop などの分散システムへと進化してきました。 Scala のアウト/インの水平拡張は分散システム設計の特徴であり、信頼性とフォールト トレランスは 2 つの品質指標です。

分散システムとは何ですか?

1. 多数のサーバーが集合体を形成し、ユーザーにとっては全体として一貫したシステムとして表示されます。
2. A. Tanenbaum の定義: 分散型コンピュータ ネットワーク内のコンポーネント間の調整されたアクションは、メッセージを通じて伝達されます。
3. G. Coulouris の定義: コンピュータがクラッシュすることはわかっているが、ソフトウェアの実行が止まらない場合。
4. Leslie Lamport は、分散システムを、メイン メモリを共有せず、ネットワーク経由で非同期メッセージを送信することで連携する複数の自律処理要素で構成される物理アーキテクチャを活用できるアプリケーションとサービスの開発をサポートするように設計されたシステムと定義しています。
5. 階層化アプリケーションとの違い: 階層化アプリケーション (たとえば、3 層) は、アプリケーション ロジックを分割します。これは、物理的な階層化ではなく論理的な階層化ですが、分散システム DS は物理的な階層化であり、実際の展開に関連しています。

従来の集中型システムと比較して:

集中型システムは、スケールアウト/スケールイン、垂直拡張の一種であり、サーバーを中型または大型メインフレームにアップグレードするか、マルチコアにアップグレードして CPU コアの数を増やします。集中型の垂直拡張は、比較的集約度の高いデータの計算に適していますが、分散型は、ルーズデータ、非構造化データ、または半構造化データの計算に適しています。どのような拡張およびスケーリング ソリューションを採用するかは、ビジネス データの特性に基づいて決定する必要があります。

あらゆる分散システムでは、コンピューティングとストレージという 2 つのタスクを常に完了する必要があります。コンピューティングとストレージの分離は、分散システムの重要な機能です。通常、集中型またはスタンドアロン システムでは、SQL ステートメントによるクエリ後の並べ替えを実装するなど、これら 2 つを組み合わせることができます。クエリはストレージからデータを取得するためのものであり、ソートは計算です。したがって、この SQL ステートメントは実際には計算とストレージを結合します。ビッグデータや高い同時実行性を扱う場合、この便利なバンドルによってパフォーマンスの問題が発生します。分散コンピューティングと分散ストレージは複雑さをもたらしますが、システムの処理能力を向上させる余地も生まれます。

分散システムの機能:

1. 同時実行性: 共有リソース、ACID または Base 原則を採用します。CAP 定理を参照してください。
2. 分散システムの設計は CAP 定理に従います。 CAP は、一貫性、可用性、パーティション許容度の略語です。 CAP 定理によれば、3 つの CAP のうち 2 つだけが同時に満たされます。
3. スケーラビリティは重要な機能であり、これにより高パフォーマンス、高スループット、低レイテンシを実現できます。
4. 信頼性/可用性: 障害の検出と処理、および回復とフォールト トレラント処理。適切に機能するシステムでは、時間比例条件が存在します。ユーザーが比例的にシステムにアクセスできない場合、システムは利用不可とみなされます。可用性の計算式:
5. 可用性 = 稼働時間 / (稼働時間 + 停止時間)
6. フォールト トレラント フェイルオーバーとは、エラーが発生してもシステムが正常に動作し続けることを意味します。これは、システムがエラーを許容することを意味します。
7. メッセージ処理: 具体的な製品には、RabbitMQ、ZeroMQ、Netty などがあります。
8. 異種性: さまざまなオペレーティング システム、ハードウェア、プログラミング言語の開発者にとって、ミドルウェアはソリューションです。
9. セキュリティ: 認可と認証、SSO、シングル サインオン、Oauth など。

位置決めコマンド:

1. リソース URL の識別
2. ネーミングサービス
3. 見上げる
4. 主に SOA のサービス ルックアップを参照してください。たとえば、Zookeeper はサービス ルックアップを実装します。

透明性:

1. アクセスの透明性: ローカルとリモートのリソースに同じ操作を使用する
2. 場所の透明性: 物理的な場所やネットワーク上の場所を知らなくてもリソースにアクセスできます。
3. 同時実行の透明性: 複数のプロセスを同時に実行し、処理を妨害したりブロックしたりすることなく共有リソースにアクセスできます。
4. レプリケーションの透過性: リソースの複数のインスタンスをレプリケーションに使用することで、ユーザーがレプリケーションを実装するための特殊なアプリケーションを作成する必要なく、信頼性とパフォーマンスを向上させることができます。
5. 障害の透明性: ソフトウェアまたはハードウェアの障害が発生した場合でも、ユーザーとアプリケーションは影響を受けることなくタスクを続行できます。
6. モバイルの透明性: モバイル リソースとクライアントがシステム内に存在できるようにします。
7. パフォーマンスの透明性: 負荷の変化に応じてシステムを再構成し、パフォーマンスを向上させることができます。
8. スケーリングの透明性: アプリケーション構造を変更せずに、システムをスケールアップまたはスケールダウンしてスループット処理能力を向上させる機能。

分散システムの課題

分散システムは、理解、設計、構築、管理が困難です。単一のマシンよりも何倍も多くの変数が設計に導入されるため、アプリケーションの問題の根本原因を検出することがより困難になります。 SLA (サービス レベル契約) は、ダウンタイムやパフォーマンスの低下を測定するもので、ほとんどの最新アプリケーションでは、通常「9」ずつ増加する回復力の SLA レベルが想定されています (例: 月あたり 99.9 または 99.99% の可用性)。 9 が増えるごとに、達成するのがますます難しくなります。

さらに事態を複雑にしているのは、断続的なエラーやパフォーマンスの低下（一般にブラウンアウトと呼ばれる）という形で分散システムが障害を起こすケースが増えていることです。これらの障害モードの診断にはより多くの時間がかかります。たとえば、Joyent はクラウド コンピューティング インフラストラクチャの一部としていくつかの分散システムを運用しています。このようなシステム（高可用性の分散キー/値ストアを含む）において、Joyent は最近、一時的なアプリケーション タイムアウトを経験しました。ほとんどのユーザーにとって、システムは正常に動作し、応答遅延は SLA の範囲内です。ただし、リクエストの 5 ～ 10 パーセントは、事前に定義されたプログラム タイムアウトを超えます。このような障害は開発環境やテスト環境では再現されず、数分から数時間「消える」ことがよくあります。この問題のトラブルシューティングには、大量のデータ ストレージを必要とするシステム分析が必要です。

これらのシステムには、データ ストレージ API (node.js)、RDBMS (リレーショナル データベース管理システム)、システム内部で使用されるキー/値システム (PostgreSQL) のほか、オペレーティング システムやエンド ユーザー アプリケーションでも使用されるキー/値システムが含まれます。最終的に、過剰につながる根本的な問題は、アプリケーション内のセマンティック ロックインでしたが、これを特定するには、多くのエンジニアリング時間とさまざまな分野の専門知識を含む、かなりのデータ収集と相関関係の作業が必要でした。

分散システムは、次の 2 つの物理的要因によって制限されます。

• ノード数（必要に応じてストレージと計算能力を増加できます）
• ノード間の距離（理想的には光速で情報がどれだけ遠くまで移動できるか）

これら 2 つの制約により、次のような困難な状況が発生します。

• ノード数が増えると、独立したノードの障害の可能性が高まります（可用性が低下し、管理コストが増加します）。
• 独立したノードの数が増えると、ノード間の通信消費が増加する可能性があります（規模が大きくなるとパフォーマンスが低下します）
• 地理的な距離が長くなると、離れたノード間の通信遅延が長くなります（一部の操作のパフォーマンスが低下します）。

分散システムの設計方法

分散システム アーキテクチャに適用される最も一般的な用語の 1 つは、SOA (サービス指向アーキテクチャ) です。 SOA は、煩わしい CORBA (Common Object Request Broker Architecture) を回避し、WS-* 標準を通じて、独立した小さな機能を完了し、互いに独立した一連の疎結合 Web サービスが、回復力のある分散システムの基盤となります。サービスは、前世代と比較した新しいプロセスです。これらは、適切な抽象化レベルでシステム内の個別の機能です。

サービス指向アーキテクチャを構築する最初のステップは、各機能が全体的なビジネス目標にどのように貢献するかを決定し、これらのビジネスを独立した障害境界、スケーラビリティ、およびデータ負荷を持つ個別のサービスにマッピングすることです。各サービスを決定する際には、次の点を考慮する必要があります。

• 地理。システムは世界規模で運用されますか、それとも地域規模で運用されますか?
• データの分離。このシステムはシングルテナントモデルとマルチテナントモデルのどちらを提供しますか?
• SLA。可用性、レイテンシ、スループット、一貫性、冗長性をすべて定義する必要があります。
• 安全性。 IAAA（アイデンティティ、認証、承認、監査）、データの機密性とプライバシーはすべて考慮する必要があります。
• 在庫状況の追跡。システムの使用状況を把握することは、容量計画などの日常的なシステム運用の一部です。課金システムの使用状況やガバナンス (クォータ/レート制限) を強制するためにも使用できます。
• 展開と構成の管理。更新はどのように展開されますか?

分散システムのためのモデル抽象化

• システムモデル（非同期/同期）
• 障害モデル（クラッシュ障害、パーティション）
• 一貫性モデル（強力、最終的）

多くの場合、私たちが最もよく知っているパターン (分散システム上での共有メモリの抽象化の実装など) はコストがかかりすぎます。分散化が進むと、各要素の動作の自由度が高まり、パフォーマンスが向上する可能性がありますが、管理が難しくなる可能性もあります。これには、管理の容易さのためにパフォーマンスを犠牲にしないという極めて賢明な行動が求められます。したがって、分散システムを統一された単一のシステムとして考えようとすると、分散システムの拡張が妨げられます。

分散システムは CAP 定理に従い、高い一貫性、高い可用性、パーティション耐性の中から選択します。

• CA (一貫性 + 可用性)。これを保証するには、2pc 2 フェーズ トランザクション コミットを使用します。欠点は、パーティションのフォールト トレランスを実現できないことです。一度操作が失敗すると、システム全体が故障し、耐え難い状態になります (水が透明すぎると魚が死んでしまいます)。
• CP (一貫性 + パーティション許容度)。可用性を確保するには Paxos を使用しますが、可用性は低下します。
• AP (可用性 + パーティション許容度)。 Dynamo などの Gossip を使用して最終的な一貫性を実現します。
• CAP理論を正しく理解するにはどうすればいいでしょうか?

分散システム設計技術: パーティショニングとレプリケーション

データ セットを設計するには 2 つの方法があります。

1. パーティショニング: 複数のノードに分割して、より多くの並列処理が可能になります。パフォーマンスは向上しますが、フォールト トレランスは低くなります。
2. レプリケーション: 異なるノードに複製またはキャッシュしてクライアントとサーバー間の距離を短縮することもできます。また、耐障害性も強化されますが、レプリケーションによってパフォーマンスが低下します。重要なのは、複製されたデータ間の一貫性です。弱い一貫性により、レイテンシが低くなり、可用性が高まります。

分散システムの設計手法: クロックとシーケンス

分散システムには、コンピューティングとストレージに関するさまざまな戦略があります。データ ストレージの場合、主にパーティショニングとレプリケーションに重点が置かれ、コンピューティングの場合、分散コンピューティング タスクは Storm などのイベント駆動型であるため、主にイベントの順序の確保に重点が置かれます。イベントの順序はビジネス ロジックの順序を表します。イベントはツリーネストされたイベントになる場合があります。信頼性とは、ツリー コレクション内のすべてのイベントが、Web サイトによってトランザクション アトムとして実行される必要があることを意味します。