分散データベース システムのフォールト トレランス - 100% の成功率、タイムアウト、パフォーマンス

[[408364]]

以前、「信頼できるコミュニケーションの3原則」を紹介する記事を書きました。分散データベースの場合、100% の高可用性 (つまり、クライアントの要求が失敗を返さないこと) を実現したい場合は、信頼性の高い通信の 3 つの原則の再試行理論と重複排除理論を使用して解決することもできます。しかし、実際には、成功率と時間の消費（速度とパフォーマンス）の点でトレードオフを行う必要があります。この記事では、実践的な経験を共有し、どのような選択肢が普遍的であるかを紹介し、参考にしていただけます。

クライアントはデータベース サーバーにアクセスし、大量のリクエストを開始します。すべてのリクエストが成功することは絶対に不可能です。ネットワーク上の理由によりリクエストが失敗する可能性があります。サーバーの内部処理の競合や分散ノード間の調整の競合により、リクエストが失敗する場合があります。

いわゆるフォールトトレランスとは、エラーが発生したときに再試行することです。エラーは必ず発生するため、IP 層でパケットが失われるのは避けられないのと同様に、再試行によってのみエラーの影響を排除できますが、TCP プロトコルは再送信によってある程度の信頼性の高い送信を実現します。

基本的な Paxos + ログ レプリケーション ステート マシン モデルを実装する一部のシステムでは、いわゆる「リーダーレス」が原因で多くの競合が発生します。 Raft を使用している場合でも、予期しない選択によってリクエストの競合が発生する場合があります。

競合 (失敗) が発生した場合、誰が再試行する必要がありますか?これには、エンジニアリングの実践におけるモジュールの責任の分割が含まれます。多くの場合、モジュールの責任の分割はコードの実装よりも重要です。一般的に、再試行が発生する場所が低いほど、パフォーマンスは向上します。再試行が発生する場所が高ければ高いほど、再試行するかどうかを判断する基準は包括的になります。

データベース システム (エコシステム) を、最下層 (左) から最上層 (右) まで、いくつかの大きなモジュールに分割します。

レプリケーション -> サーバー -> クライアント SDK -> ユーザー

最も一般的なアプローチは、ユーザー自身に再試行させることです。たとえば、一般的な Redis SDK では、サーバーがクラッシュしてリクエストが失敗した場合、ユーザーは IP を変更し、接続を再確立して、リクエストを繰り返す必要があります。

一部のシステムでは、独自のクライアント SDK がカプセル化されます。たとえば、公式の Redis SDK は、各リクエストの結果をインターセプトするために単純にカプセル化されています。エラーが見つかった場合、SDK は自動的に再試行します。この方法では、ユーザーは再試行ロジックを用意する必要がなく、コードを簡素化できます。つまり、複数の共同モジュールの 1 つのモジュールが一部の責任を引き受ける場合、その上位レベルのモジュールは一部の作業を節約できます。

ユーザーが再試行を望まず、クライアント SDK も再試行を望まない場合はどうなるでしょうか?すべての責任をサーバーに押し付けることができますか?絶対に不可能です。この記事の要約をご覧ください。では、SDK が再試行した後、ユーザーが再試行する必要がないのはなぜでしょうか? SDK とユーザーは同じ操作空間にあるため一体であり、両者の間には信頼性の高い伝送の問題はありません。

つまり、クライアント SDK には再試行ロジックが必要なので、サーバーには再試行ロジックは必要ないのでしょうか?理論上はそうですが、実際には、サーバー自体が自身の障害率を下げる必要があり、障害率を下げるために必要な手段は再試行することです。たとえば、サーバーは paxos モジュールに操作ログの同期を要求しますが、予期しないマルチマスターのため、同じ位置を他のノードと競合できません。このとき、サーバーがクライアントに直接エラーを報告すると、サーバーの障害数が 1 つ増加します。ただし、サーバーは再試行して、成功するまで次の位置を競うために再度 paxos モジュールを呼び出すことができます。この方法では、クライアントがサーバーからのエラー報告を目にすることはほとんどありません。

ただし、再試行のたびに時間がかかるため、サーバーまたはクライアントが無限に再試行することは不可能です。最も極端なケースでは、再試行に数時間、あるいは永久に時間がかかる可能性があり、これは当然受け入れられません。したがって、タイムアウトメカニズムを導入する必要があります。一定回数再試行しても失敗した場合は、上位層にエラーを報告する必要があります。

再試行すると、合計の消費時間が増加し、上位層に悪影響を及ぼします。つまり、上位層は下位層が遅く、パフォーマンスが低いと判断します。そのため、体系的な思考、判断、総合的なトレードオフが必要になります。経験上、成功率を向上させるには、サーバーとクライアント SDK の両方で分析と改良を行い、可能な限り再試行する必要があります。ほとんどの場合、開発者は再試行を諦めすぎて、再試行が少なくなる傾向があります。結局のところ、再試行シナリオが 1 つ増えるということは、コードをもう 1 つ書くことを意味し、人々は常に怠惰になりたがります。

信頼性の高いシステムを設計するには、信頼性の高い伝送の 3 つの原則は非常に役立つ基本理論ですが、万能薬ではありません。本質的に、ソフトウェア開発とは、システムの複雑さの制御だけでなく、多くの分析と改良を行うことです。

再試行に関する追加の問題は、信頼性の高いトランスポートの 3 つの原則の 2 番目の原則である重複排除です。 「べき等性」という言葉を聞いたことがあるかもしれません。これは重複排除と同じです。操作がべき等性でない場合は再試行できません。

しかし、実際には、冪等性の責任を可能な限り上位層まで押し上げることができます。結局のところ、少なくともユーザーにとっては、100% の成功率は、べき等性に関する疑問よりもはるかに優先されます。ユーザーは、下位​​層が冪等性を考慮せず大胆に再試行することに同意しますが、下位層の偶発的な障害には非常に敏感になります。要するに、べき等性については心配せず、タイムアウト制限内で大胆に再試行してください。