分散システムの問題: ネットワークの問題

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

分散システム上でのソフトウェア開発は、単一のマシン上でのソフトウェア開発とはまったく異なります。主な違いは、分散システムでは問題が発生する可能性が高く、障害の形態がスタンドアロン システムとは異なる可能性があることです。この記事では、ネットワークの問題とクロックの問題という 2 つの考えられる問題について説明します。

これら 2 つの問題を紹介する前に、大規模なコンピューティング サービスを構築するための 2 つのオプションを見てみましょう。

• 高性能コンピューティング (HPC): つまり、スーパーコンピュータの使用です。このタイプのコンピュータには数千個の CPU が搭載されており、非常に強力なパフォーマンスを発揮します。このタイプのマシンは、リアルタイムの天気予報など、計算負荷の高い科学計算タスクに適しています。
• クラウド コンピューティング: 使用するマシンは比較的一般的なものですが、複数のデータ センターに展開され、イーサネット経由で相互に通信する場合があります。

もちろん、多くの企業はこの 2 つを組み合わせて使用​​しています。つまり、各マシンのパフォーマンスは良好で、複数の同様のマシンがクラスターを形成してサービスを提供しています。ハイパフォーマンス コンピューティングとクラウド コンピューティングの違いは次のとおりです。

• 多くのクラウド サービス アプリケーションはオンラインであるため、いつでもユーザーにサービスを提供できます。したがって、クラウド サービス全体が停止することは許容できません。ただし、オフライン タスクはいつでも停止して再開できます。
• スーパーコンピュータの方向性は、ノードが共有メモリと RDMA (リモート ダイレクト メモリ アクセス) を介して通信する、信頼性が高く安定したシステムを構築することです。しかし、クラウドサービスの各ノードは非常に安価であり、使用されるハードウェアは必ずしも安定していないため、障害率は非常に高くなります。
• 大規模なデータ センター ネットワークは、多くの場合、IP とイーサネットをベースとしており、高速ネットワークを提供します。スーパーコンピュータの方向性は、スーパーコンピュータ通信専用のネットワーク構造を使用することです。
• クラウド サービス システムが大規模になり、コンポーネントの数が増えるほど、問題が発生する可能性が高くなります。大規模なシステムでは、エラー処理戦略に欠陥があると、エラーからの回復に時間がかかることがあります。
• クラウドサービスは世界中に分散して展開され、データ通信はインターネットを介して行われます。スーパーコンピュータのノードは通常、互いに非常に近い位置にあります。

したがって、分散システムを使用して独自のサービスを作成する場合、このサービスはフォールト トレラントである必要があります。言い換えれば、信頼性の低いコンポーネントから信頼性の高いシステムを構築する必要があるということです。ソフトウェア設計段階では、エラー (障害) を処理し、エラー処理を十分に考慮する必要があります。ソフトウェアにエラーが発生した場合に、ソフトウェアでどのような問題が発生するかを知る必要があります。

システムを構築するときは、サービスが完璧で問題が発生しないと想定するのではなく、より多くの起こり得る問題を考慮する必要があります。分散システムでは、あらゆる疑念、悲観、粘り強さが報われます。 (分散システムでは、疑念、悲観、偏執が報われます。)

これら2つの問題については以下で紹介します。

1. ネットワークの問題

1.1.ネットワークの問題の概要

分散ネットワークは信頼性の低いネットワークです。データセンター間やパブリック ネットワーク間のネットワークのほとんどは、非同期パケット スイッチング ネットワーク (非同期パケット ネットワーク) です。このタイプのネットワークでは、ノードはデータ パケットを別のノードに送信できますが、ネットワークはパケットがいつ到着するか、または到着するかどうかを保証しません。したがって、サーバーにリクエストを送信すると、いくつかの問題が発生する可能性があります。

• 要求は他のノードに送信される前に失われました。たとえば、ネットワーク ケーブルが接続されていません。
• リクエストはネットワーク上でキューに入れられ、送信されるのを待機する場合があります。たとえば、ネットワークの過負荷などです。
• サーバーはリクエストを処理できませんでした。たとえば、サーバーがクラッシュしたりシャットダウンしたりした場合です。
• サーバーは一時的にリクエストを処理できません。たとえば、サーバーはガベージ コレクションを開始し、サービスを一時停止します (ガベージ コレクションの一時停止)。
• サーバーは要求を処理しましたが、結果はネットワーク上で失われました。たとえば、スイッチの構成に問題があります。
• サーバーはリクエストを処理しましたが、結果が遅延しており、送信を待機しています。たとえば、ネットワークまたはマシンが過負荷になっている場合などです。

ネットワーク要求失敗図

したがって、送信者が応答を受信しない場合、パケットがサーバーに正常に到達したかどうかさえわかりません。確認する唯一の方法はサーバーの応答を確認することですが、この応答が届かない可能性があります。応答がない場合、サービスがログに記録しない限り、何が問題だったのかを知ることはほぼ不可能です。

この問題に対処する一般的な方法は、タイムアウトを設定することです。つまり、一定時間が経過すると結果を待つのをやめます。ただし、タイムアウトが設定されている場合でも、リクエストがサービスによって処理されたかどうかはわかりませんので注意してください。

ネットワークの問題に対処するということは、必ずしも何らかのアクションを実行するということではなく、ユーザーにエラー情報を返すだけの場合もあります。しかし、ソフトウェアがさまざまなネットワークの問題にどのように対応するかを把握し、これらの処理操作によってデッドロックなどのシステム問題が発生しないようにする必要があります。

1.2.エラーの検出

多くのシステムでは、障害のあるノードを自動的に検出する機能が必要です。たとえば、ロードバランサ、シングルリーダー分散データベースなど。ただし、ネットワークの不確実性のため、ノードがまだ動作しているかどうかを検出することは非常に困難です。ネットワークの問題に関する情報を取得すると役立つ状況がいくつかあります。

ノード マシンは引き続き動作しますが、対応するターゲット ポートをリッスンしているプロセスがない場合 (たとえば、プロセスがクラッシュした場合)、システムは TCP 接続を拒否し、RST または FIN パケットを返します。

ノード プロセスがクラッシュした場合でも、ノードは正常に動作しているため、クラスターはリクエストを別のノードにすぐに渡して処理できる場合があります。たとえば、HBase。

データセンター内のネットワーク スイッチにアクセスできる場合は、ハードウェア レベルで問題があるかどうかを確認できます。しかし、通常はスイッチにアクセスできません。

IP アドレスが到達不能な場合は、ICMP 宛先到達不能パケットが返されることがあります。

さらに、TCP 要求は自身で再試行され、アプリケーション層に対して透過的になります。しかし、アプリケーション層で私たち自身で再試行する方がよいでしょう。タイムアウト期間が経過しても結果が得られない場合は、ノードに問題があることを意味します。

1.3.タイムアウト設定

タイムアウトを設定するのは簡単なことではありません。設定時間が長すぎると、サーバーが長時間待機しなければならない場合があります。設定が短すぎると誤判定の恐れがあります。サーバーネットワークが一時的に混雑し、速度が遅くなっている可能性があります。一部のロード バランサは、タイムアウトを使用してノードがアクティブかどうかを判断します。ノードの生存状態が誤って判断された場合、サービスのパフォーマンスに影響が出る可能性があります。

システムの理想的なネットワーク遅延が で、サーバーの処理時間が の場合、タイムアウト時間は に設定するのが最適です。しかし、現実には、ほとんどのシステムのネットワーク遅延は無制限です。つまり、ネットワークは可能な限り高速に配信しようと最善を尽くしますが、無限に遅くなる可能性もあります。サービス自体では正確な最大処理時間を示すことはできません。

1.4.ネットワークの輻輳とキューイング

車で目的地に到着するまでの時間が不確実なのは、主に車が道路上で待機する時間が不確実であるためです。同様に、ネットワーク パケット遅延の不確実性は、ネットワーク内のパケットのキューイングによっても発生する可能性があります。キューが発生する原因はいくつか考えられます。

• 多くの人が同時に宛先にパケットを送信する場合、スイッチはこれらの要求をキューに入れて、ターゲット ネットワーク リンクに 1 つずつ送信する必要があります。したがって、パケットを宛先ネットワーク リンクでキューに入れる必要がある場合があります。キュー内のパケットが多すぎる場合、後から送信されたパケットは直接破棄され、再送信が必要になる場合があります。
• パケットがサーバーに到着したときに、すべての CPU がビジー状態の場合、アプリケーションが要求を処理するためのタイムスライスを取得するまで、現在の要求はオペレーティング システムによってキューに入れられます。この待機時間は現在のマシンの負荷によって異なり、短くなる場合も長くなる場合もあります。
• 仮想環境の場合は、別の仮想環境が現在 CPU タイムスライスを取得している可能性があり、現在の仮想環境も待機する必要がある場合があり、ネットワーク要求も処理のためにキューに入れられます。
• TCP 輻輳制御 (フロー制御、輻輳回避、またはバックプレッシャー)。送信者は、ネットワークまたはターゲット マシンに過負荷がかからないように送信速度を制限する場合があり、その場合、パケットはネットワークに入る前にキューに入れられることがあります。

ポート1、2、4はポート3にパケットを送信しようとする

さらに、TCP が ACK を受信しない場合、要求を再送信します。このプロセスはアプリケーション層に対して透過的ですが、アプリケーション層ではレイテンシが高くなる可能性があります。

サービスのアイドル時間が長い場合、キューに入れられたタスクはすぐに処理され、クリアされます。しかし、サーバーの処理限界に近づくと、キューは急速に長くなり、深刻なネットワーク遅延が発生します。

同時に、クラウド環境では、同じサーバーを共有するサービスが多数ある可能性があるため、ネットワーク遅延を制御することが困難です。そのため、ネットワークが混雑している場合は、他のサービスが混雑を引き起こし、当社のサービスに影響を与える可能性があります。

1.5.まとめ

クラウド サービスのシナリオでは、現在のテクノロジではネットワークの遅延と信頼性を保証することができないため、ネットワークの輻輳、キューイング、無制限の遅延を考慮する必要があります。タイムアウト期間には固定の基準値は存在せず、実験を通じて設定する必要があります。

次回の記事では引き続き時計問題について紹介します。

（つづく）

参考文献

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