分散システムの問題: クロックの問題

[[440449]]

この記事はWeChatの公開アカウント「Programmer Sir」から転載したもので、著者はProgrammer Sirです。この記事を転載する場合は、Programmer Sir の公開アカウントにご連絡ください。

前の記事ではネットワークの問題について説明しました。この記事では、さらに別の難しい問題である時計問題を紹介します。

2. 時計の問題

クロックはアプリケーションにとって非常に重要であり、多くの指標をクロックで測定できます。たとえば、1 秒あたりのリクエスト数、平均リクエスト時間など。これらのデータは時間間隔 (期間) で表されます。別のカテゴリには、記事の公開時間、キャッシュの有効期限などが含まれます。これらは時点によって表されます。

分散システムでは、すべてのリクエストがネットワーク遅延の影響を受け、ネットワーク遅延の長さがわからないため、複数のマシンが関与し、各マシンがイベントの発生時刻を記録する場合、ネットワーク遅延が不確実であるため、イベントの発生順序を判断できない可能性があります。イベントが時間的に非常に近い場合、クロックの問題が発生する可能性もあります。

また、各マシンにはハードウェアによって決定される独自のクロックがあるため、多少の違いが生じる可能性があります。クロックの非同期の問題は、ネットワーク タイム プロトコルを通じて軽減できます。また、GPS などのサービスを通じて正確なネットワーク時間を取得することもできます。

2.1.単調時計と時刻時計

現代のコンピュータには、壁時計時間 (通常の時計に対応する時計) と単調時計の少なくとも 2 種類の時計が含まれています。本質的にはどちらも時間を示しますが、目的は異なります。

壁時計の時間

壁掛け時計は、カレンダーに従って現在の日付と時刻を返します。これは、私たちの日常の理解における時計の概念と一致しています。たとえば、Java の System.currentTimeMillis() は、1970 年 1 月 1 日からのミリ秒数を表します。

壁時計は通常、クロック同期に NTP を使用しますが、ローカル クロックが NTP サーバーよりもはるかに速い場合は、誤った時点にジャンプする可能性があります。さらに、壁時計はうるう秒を無視するため、経過時間の計算には適していません。

単調な時計

モノトニック クロックは、タイムアウトやサーバー応答時間などの時間間隔 (期間、時間間隔) を計算するのに適しています。たとえば、Java の System.nanoTime() は単調なクロックを返します。単調クロックでは、時間の数値が常に大きくなります。

NTP は、ローカルの水晶がタイム サーバーよりも速いか遅いことを検出すると、ローカルの水晶の振動周波数を調整します。デフォルトでは、NTP は最大周波数の変更を許可します。ただし、NTP はモノトニック クロックの値を直接調整しません。モノトニッククロックは非常に高い精度を誇り、通常はマイクロ秒単位の時間間隔を測定できます。

単調クロックの値は無意味であり、異なるノード上の単調クロックの値を比較することは、意味と基底が異なる可能性があるため無意味であることに注意してください。単調性は通常、タスクの期間を測定するために使用されます。

2.2.クロック同期と精度

モノトニック クロックは同期する必要はありませんが、ウォール クロックは NTP サーバーに基づいて調整する必要があります。ただし、クォーツ時計自体の振動ドリフトや NTP 同期中のネットワーク遅延などにより、壁時計と NTP が一致しない可能性もあります。データによれば、ネットワーク経由で時刻同期を実行すると、誤差は少なくとも 35 ミリ秒になり、最悪の場合には誤差が 1 秒を超えることもあります。さらに、一部のユーザーは、意図的にローカル クロックを間違った日付に調整する場合があります (たとえば、ゲームの時間チェックを回避するためなど)。そのため、壁掛け時計は非常に不正確になる可能性があります。

問題がクロックの同期に依存する場合は、同期が行われていない場合にアプリケーションにどのような問題が発生するかを考慮する必要があります。

たとえば、よくある問題は、ノード間でのイベントの順序付けです。クロック同期に大きく依存すると、問題が発生する可能性があります。たとえば、次の例をご覧ください。

クロックを使用すると問題が発生する可能性があるもう 1 つの例として、データベースにパーティションごとにマスターが 1 つしかなく、マスターのみが書き込みを受け入れることができる場合が挙げられます。では、他のノードはどのようにして現在のマスターノードがまだマスターノードであることを確認できるのでしょうか? 1 つのアイデアは、マスター ノードが他のノードからリースを取得することです。リースがタイムアウトしていない場合、現在のノードは要求を処理できますが、そうでない場合は処理できません。疑似コードは次のとおりです。

 （真）の間{
    リクエスト = getIncomingRequest(); 
 
    // リースには常に少なくとも10 秒残っていることを確認します
    リース有効期限が 10000 より短い場合、System.currentTimeMillis() は 10000 に設定されます。
        リース = リース.renew();
    } 
 
    リースが有効かどうか
        プロセス(リクエスト);
    }
 }

現在のリースがまだ有効で、残り 13 秒であるが、lease.isValid() に 15 秒かかる場合、process(request) の実行が開始されたときにリースの有効期限が切れており、別のノードがプライマリ ノードになっている可能性があります。この結果、現在のノードはプライマリ ノードではなくなりますが、書き込み要求を処理する操作は引き続き実行されます。これは問題を引き起こします。

この状況は、プロセスの一時停止によって発生する可能性があります。プロセスは、ガベージ コレクション (GC) など、さまざまな理由で一時停止されることがあります。

要約する

分散システムでは、ネットワークの問題やクロックの問題などが発生する可能性があります。さらに、分散システムの主な特徴は部分的な障害です。したがって、分散環境において、部分的な障害を許容できるソフトウェア システムを構築することが私たちの目標です。

これを実現するには、まずエラーを検出できなければなりませんが、これは簡単ではないため、ほとんどの分散アルゴリズムはタイムアウトを利用してサービスが正常かどうかを判断します。しかし、タイムアウトでは、それがネットワークの問題なのか、ノード障害なのかを区別できません。ノード障害が一時的なネットワーク上の理由による障害であると誤って識別された場合、ノードは「誤って非難」され、サービスの不安定性を引き起こす可能性があります。

エラーが検出された後、システムがそのエラーをどのように許容できるかも難しい問題です。分散環境では、各ノードはネットワークを介して通信しますが、ネットワーク自体は信頼できません。したがって、単一のノードでは正しい決定を下せない可能性があり、決定を下すには複数のノードが一緒に投票する必要があります。

参考文献

[1] クレップマン、マーティン。データ集約型アプリケーションの設計: 信頼性、拡張性、保守性に優れたシステムの背後にある重要なアイデア。 「オライリーメディア社」、2017年。