複雑さの原因である高可用性についてお話ししましょう

高可用性は、システムが継続的かつ中断なく機能を実行する能力として定義され、システムの可用性を測定するための重要な指標の 1 つです。このコンセプトの中核は「中断のない」運用を実現することですが、これは実装における主な課題でもあります。ハードウェアとソフトウェアはどちらも障害の影響を受けるため、ハードウェアは故障したり老朽化したりする可能性があります。また、ソフトウェアは時間の経過とともにバグが発生したり、複雑化や大規模化したりする可能性があります。さらに、停電や自然災害などの外部要因によってシステム サービスの中断が発生する場合もあり、これは予測不可能で制御が難しいことがよくあります。

したがって、システムの高可用性を実現するには、通常、「冗長性」の概念に依存します。つまり、サービスの継続性を確保するのに 1 台のサーバーでは不十分な場合は、2 台のサーバーを使用します。 2 つでは足りない場合は 4 つに増やします。停電に備えて、サーバーを複数の地理的な場所に配置できます。ネットワークチャネルの不安定さが心配な場合は、複数のネットワークサービスプロバイダーを同時に使用することもできます。表面的には、パフォーマンスを向上させる場合でも、高可用性を実現する場合でも、解決策はマシンを追加することであるように見えますが、両者の目的はまったく異なります。パフォーマンスを向上させる目的は、システムの処理能力を「拡張」することであり、高可用性を実現する目的は、「冗長」ユニットを追加することでサービスの継続性と安定性を確保することです。

コンピューティングの高可用性

ここでの「計算」とは、ビジネスの論理的な処理を指します。コンピューティングの特徴の 1 つは、どのマシンで計算を実行しても同じアルゴリズムと入力データによって同じ出力結果が生成されるため、計算をあるマシンから別のマシンに移行してもビジネスに影響がないことです。この場合、高可用性を計算する際の複雑さはどこにあるのでしょうか?分析のために、1 台のマシンを 2 台のマシンに変更するという最も単純な例を取り上げます。まず、単一マシンがデュアルマシンになる簡単なアーキテクチャ図を見てみましょう。

写真

前述の 2 台のマシンのアーキテクチャは、前述の「高パフォーマンス」のトピックで説明したものと非常によく似ているため、複雑さも同様であることに気付くかもしれません。具体的には：

上記の説明は基本的なデュアルマシン アーキテクチャについてのみですが、より複雑な高可用性クラスター アーキテクチャについてさらに詳しく説明します。単純なデュアルマシン設定と比較すると、高可用性クラスターの割り当てアルゴリズムはより複雑です。構成には、アクティブ 1 台とスタンバイ 3 台、アクティブ 2 台とスタンバイ 2 台、アクティブ 3 台とスタンバイ 1 台、アクティブ 4 台とスタンバイ 0 台が含まれますが、これらに限定されません。絶対に勝てるアルゴリズムは存在しないため、構成ソリューションの選択は実際のビジネス ニーズに基づいて分析および判断する必要があります。たとえば、ZooKeeper は 1 つのマスターと複数のスレーブのモデルを採用していますが、Memcached はすべてのマスターと 0 つのスレーブの戦略を採用しています。

ストレージの高可用性

データ ストレージを必要とするシステムを設計する場合、ストレージの高可用性を確保することが、システム設計全体の鍵および課題になります。ストレージ タスクとコンピューティング タスクの基本的な違いは、データをネットワーク ラインを介して 1 台のマシンから別のマシンに転送する必要があることです。この送信速度は物理的な制限を受けます。同じコンピュータ室内でも、伝送速度はわずか数ミリ秒になる場合があります。ただし、異なる地域のコンピューター ルーム間では、伝送遅延が数十ミリ秒または数百ミリ秒にまで増加する可能性があります。たとえば、広州と北京のコンピュータ室間では、ネットワーク遅延は安定している場合は約 50 ミリ秒ですが、不安定なネットワーク環境では、遅延が 1 秒以上に増加する可能性があります。

この問題を解決するために、通常はシステム設計にタスク アロケータが追加されますが、その選択はパフォーマンス、コスト、保守性、可用性など、多くの要因によって決まります。タスクディスパッチャは、ビジネスサーバーとの接続と対話を処理するだけでなく、適切な接続方法を選択し、接続の確立、検出、切断後の処理戦略など、これらの接続を適切に管理する必要もあります。

さらに、タスク アロケータには、マスター スレーブ、デュアル マスターなどのモードなどの効率的な割り当てアルゴリズムが装備されている必要があります。マスター スレーブ モードはさらに、コールド スタンバイ、ウォーム スタンバイ、ホット スタンバイに分類できます。ミリ秒レベルの時間差は人間にはほとんど感知できませんが、高可用性を追求するシステムにとって、この時間差はデータの瞬間的な不整合を意味し、システム全体の業務に根本的な影響を及ぼします。

例えば、銀行の貯蓄業務において、顧客が北京のデータセンターに預金したが、そのデータがまだ上海のデータセンターに同期されていない場合、顧客が残高を確認すると、新しく預金した金額が表示されず、ユーザーに不安を与える可能性があります。この経験は顧客にとって非常に悪いものです。資金の安全性を心配する顧客もおり、それが苦情や警察への通報につながる可能性もあります。最終的に問題が単にデータ同期の遅延であったことが判明したとしても、ユーザーにとってその体験は依然としてマイナスのものです。

写真

物理的な伝送速度の制限に加えて、ネットワーク回線の信頼性も重要な考慮事項です。回線に停止、輻輳、異常（データエラー、損失など）が発生する可能性があり、これらの問題の修復には最大数時間かかる場合があります。 2015年に光ファイバーケーブルの掘削によりアリペイ業務が4時間以上影響を受けた事故や、2016年に中国と米国間の海底光ファイバーケーブルが破損し、3時間にわたって通信が途絶えた事故などが、過去の事故の典型例です。これらの回線の問題により、データの同期が一時的に中断され、システムが一定期間不整合になる可能性があります。

より広い視点で見ると、通常時の伝送遅延であれ、異常時の伝送中断であれ、ある時点または一定期間内にシステム内のデータの不整合を引き起こし、業務上の問題を引き起こす可能性があります。ただし、冗長データ バックアップがなければ、システムの高可用性は保証されません。したがって、高可用性ストレージ システムを設計する際の課題は、データのバックアップ自体ではなく、データの不整合がビジネスに与える影響をどのように軽減または回避するかにあります。

分散システムの分野では、ストレージの高可用性の複雑さを理論的に証明する有名な CAP 定理があります。 CAP 定理によれば、分散システムは一貫性、可用性、分断耐性の 3 つの要件を同時に満たすことはできず、最大でそのうちの 2 つしか満たすことができません。つまり、アーキテクチャを設計する際には、ビジネス ニーズに基づいて適切なトレードオフと選択を行う必要があります。

高可用性ステータスの決定

コンピューティングやストレージの高可用性を実現するには、その核心は「状態判断」にあります。つまり、システムは現在の状態が正常か障害かを識別でき、障害が検出されたときには高可用性を維持するための対策を講じることができなければなりません。しかし、国家の意思決定プロセスに誤りや間違いがあった場合、その後のすべての最適化対策は有効性と価値を失ってしまいます。実際の運用では、根本的な課題があります。システムの可用性を向上させるために冗長メカニズムに依存している一方で、絶対的に正確なステータス決定を達成することはほぼ不可能です。次に、一般的に使用されているいくつかの意思決定方法を分析することで、この問題を詳細に検討します。

1. 権威主義的

コンピューティングとストレージの高可用性を確保する方法を議論する場合、「状態判断」の重要性、つまり、システムが現在の状態が正常か異常かを正しく判断し、異常が見つかった場合に高可用性を維持するために適切な対策を講じることができるかどうかに重点を置く必要があります。問題は、状態判断プロセス自体にエラーや間違いがあると、その後の最適化や処理措置がすべて意味を失ってしまうことです。実際には、これには根本的な矛盾が隠されています。冗長性を追加することでシステムの可用性は向上しますが、状態の決定の絶対的な正確性を保証することは困難です。この課題をさらに理解するために、いくつかの主要な意思決定方法について詳細な分析を行います。

写真

2. 交渉

協議による意思決定とは、2 人の独立した個人が情報を交換し、ルールに基づいて意思決定を行うことを指します。最も一般的に使用される協議による意思決定は、アクティブ/スタンバイの決定です。

このアーキテクチャの基本的なネゴシエーション ルールは、次のように設計できます。

写真

協議による意思決定の構造とルールは複雑ではありません。難しいのは、両者間の情報交換に問題がある場合（プライマリ接続とバックアップ接続の中断など）に、どのようにステータス決定を行うかということです。

包括的な分析により、協議に基づく国家の意思決定には、特定のシナリオでは常に何らかの問題があることが示されています。

両方のサーバーは起動時にバックアップ マシンになります。

2台のサーバーが接続されています。

2 つのサーバーはステータス情報を交換します。

1 台のサーバーがマスター サーバーになることを決定し、もう 1 台のサーバーは引き続きバックアップ サーバーとして機能します。

接続が中断されたときにスタンバイ マシンがマスター マシンに障害があると判断した場合は、スタンバイ マシンをマスター マシンにアップグレードする必要があります。ただし、マスター マシンに障害がない場合、システムには 2 つのマスターが存在することになり、元の設計 (マスター 1 台とスタンバイ 1 台) と一致しません。

写真

接続が中断されたときにスタンバイ マシンがマスター マシンに障害があると判断した場合は、スタンバイ マシンをマスター マシンにアップグレードする必要があります。ただし、マスター マシンに障害がない場合、システムには 2 つのマスターが存在することになり、元の設計 (マスター 1 台とスタンバイ 1 台) と一致しません。

写真

接続の中断が状態の意思決定に及ぼす悪影響を軽減するための 1 つの方法は、デュアル接続戦略やトリプル接続戦略などを使用して複数の接続を追加することです。このアプローチは、確かに単一の接続障害がシステムの状態判断に与える影響を軽減できますが、問題を完全に排除することはできず、新しい課題が生じます。異なる接続によって送信される情報が異なる場合、システムはどの接続の情報に基づいて決定を下すべきでしょうか。現実には、この問題に対する万能の解決策は存在しません。意思決定の基盤として何らかの接続を選択すると、特定の状況では常に困難や課題が生じます。

写真

包括的な分析により、協議に基づく国家の意思決定には、特定のシナリオでは常に何らかの問題があることが示されています。

3. 民主的

民主的な意思決定プロセスでは、複数の独立した主体が投票メカニズムを通じて共同で国家の判断を下します。このアプローチは、ZooKeeper クラスターでリーダーを選出するときに使用されます。

写真

このように、クラスター内のすべてのメンバーがリーダー選挙に参加し、投票結果に基づいて最終的にリーダーが決定されます。

この意思決定メカニズムはアルゴリズム的に複雑ですが、それ自体に「スプリット ブレイン」現象という本質的な問題もあります。この用語は医療分野に由来し、脳の左半球と右半球の間の切断により、互いに情報を交換できなくなり、身体が制御されて異なる動作や矛盾した動作が行われることを表します。分散システムでは、スプリットブレインとは、ネットワークによって、元々統合されていたクラスターが 2 つの独立したサブクラスターに分割されることを意味します。各サブクラスターは独立してリーダーを選出し、結果として 2 つの異なるリーダーが誕生します。これは、システム内に 2 つの「頭脳」が存在するのと似ています。民主的な意思決定とは、複数の独立した個人が投票を通じてステータスの決定を行うことを指します。たとえば、ZooKeeper アンサンブル。

写真

理想的な分散システム設定では、通常、1 つのノードがプライマリ ノードとして選択され、他のノードはバックアップとして機能します。通常の動作環境では、ノード 5 がプライマリ ノードであり、他のノードはバックアップとして機能すると想定します。ただし、ネットワーク障害によってノード間の接続が切断されると、ノード 1、2、3 が独立したサブクラスターを形成し、ノード 4 と 5 が別のサブクラスターを形成する可能性があります。これら 2 つのサブクラスターは、切断されているため相互に通信できません。民主的な意思決定メカニズムに従って、2 つのサブクラスターはそれぞれノード 2 とノード 5 などの独自のマスター ノードを選出できるため、システムには同時に 2 つのマスター ノードが存在することになります。

このマルチマスターノード状態は、各マスターノードが独立して決定を下すため、システム状態が混乱する原因となり、システムの本来の設計意図に反します。このスプリットブレイン現象の発生を防ぐために、民主的な意思決定を使用するシステムでは通常、投票に参加するノードの数がシステム内のノードの総数の半分を超える必要があるというルールを実装します。上記の例では、ノード 4 とノード 5 で構成されるサブクラスター内のノードの合計数がシステム内のノードの合計数の半分未満であるため、選出は実行されず、スプリット ブレインの問題が回避されます。ただし、このアプローチはスプリットブレインを防ぐことができますが、システム全体の可用性が低下する可能性もあります。たとえば、ノード 1、2、3 の障害がスプリット ブレインの問題によるものではなく、実際の障害である場合、ノード 4 と 5 がまだ正常であっても、システムは新しいマスター ノードを選択できません。これは、一部のノードがまだ正常な状態であるにもかかわらず、システム全体が停止していることに相当します。