分散システムにおける信頼性とフォールトトレランスのエンジニアリング

ユーザーは、提供されるサービスに信頼できることを期待しています。実際には、避けられない要因によりサービス障害が発生する可能性がありますが、その場合でも、サービス障害を回避するために最善を尽くす必要があります。

この記事では、エンジニアリングの信頼性とフォールト トレランスとは何かを詳しく説明し、エンジニアリングの信頼性とフォールト トレランスを実現するために Ably プラットフォームがどのように設計されているかを説明します。

議論の前提条件として、まずいくつかの定義を示します。

信頼性

ユーザーが製品やサービスに置くことができる信頼の度合い。これは、システムが利用可能であるだけでなく、ユーザーの期待どおりに動作し続けるために広範な冗長性が設計されていることを意味します。

可用性

必要なときに製品またはサービスが利用できる程度。これは通常、システム障害が発生した場合に十分なリソース冗長性があるかどうかに帰着します。

フォールトトレランスとは何ですか?

フォールト トレランスとは、一部のコンポーネントまたはサブシステムに障害が発生した場合でも、システムの可用性と信頼性が維持されることを意味します。

フォールト トレラント システムは障害を許容できます。これらは、システムに対する有害事象の影響を軽減し、ユーザーがシステムを引き続き利用できるように設計されています。フォールト トレラント技術を使用すると、可用性と信頼性を向上させることができます。

可用性は、大まかに言えば、システムが正常に動作していることを保証することだと考えられます。信頼性は、システムが動作中に提供するサービスの品質と考えることができます。つまり、システム障害時にも機能とユーザー エクスペリエンスが可能な限り効果的に維持されることを保証します。

サービスが利用できない場合は、利用不可とみなされます。サービスが利用可能であっても、使用時に期待どおりに動作しない場合は、信頼性が十分ではありません。フォールト トレラント設計アプローチは、これらの欠陥に対処し、ビジネスとユーザー エクスペリエンスの継続性を実現します。

可用性、信頼性、ステータス

ほとんどの場合、フォールト トレラント設計の主な基礎は冗長性です。サービスに必要な最小限の数以上のコンポーネントまたは容量を提供すること。重要な問題は、「冗長性」をどのように管理するかです。

現実の世界では、可用性と信頼性には違いがあります。

• 可用性とは、車のタイヤ交換などのサービスの短時間の中断が許容されることを意味します。
• 信頼性はサービスの継続性を保証する必要があるため、「冗長性」が不可欠です。たとえば、飛行機には複数のエンジンが搭載されている場合があります。
• 継続性の要件は、冗長容量の提供方法に影響します。
• 分散システムでは、コンポーネントを「ステートフル」と「ステートレス」の 2 つのカテゴリに分類できます。

ステートレス コンポーネントは、いかなる状態にも依存せずに機能を実行します。各サービス コールは独立して完了でき、前のサービス コールに依存しません。これらのコンポーネントのフォールト トレランス設計は比較的単純です。一部のリソースに障害が発生しても、他のステートレス コンポーネントがそれを処理できるように、十分なリソースを提供するだけです。

ステートフル コンポーネントは、サービスを提供するために何らかの状態に依存する必要があります。状態は、サービスの呼び出しを過去および将来の呼び出しに暗黙的にリンクします。これらのコンポーネントは、航空機のエンジンのようにフォールト トレラントな性質を備えているため、動作の継続性が保証されます。具体的には、サービスが依存する状態の継続性です。

この記事の残りの部分では、各ケースの例を示し、実際にフォールト トレランスを実現するときに直面するエンジニアリング上の課題について説明します。

フォールトトレラント設計では障害を通常のものとして扱う

大規模システムでは、コンポーネントの障害は遅かれ早かれ発生すると想定する必要があり、すぐに発生する可能性があり、継続的に発生することが予想されます。

大規模システムでは、障害は非バイナリであることが多く、個々のコンポーネントの信頼性に依存できず、サービス障害は伝播効果をもたらします。ビザンチンの失敗は典型的な例です。

たとえば、コンポーネントが断続的に動作したり、コンポーネントが誤解を招く出力を生成したり、依存している外部コンポーネントに障害が発生したりする可能性があります。これは、システム全体の信頼性と、システムがこれらのエラーを許容できるかどうかに影響します。

非バイナリ障害を許容するには、多くの思考、エンジニアリング、そして時には人間の介入が必要になります。潜在的な障害はすべて特定して分類し、広範なテストと堅牢な設計上の決定を通じて迅速に修復または回避できる必要があります。フォールト トレラント システムを設計する際の中心的な課題は、障害の性質を理解し、特に断続的な障害が発生した場合に、ユーザーに可能な限りサービスを提供し続けながら、障害を検出して修復する方法を理解することです。

ステートレス サービス

ステートレス サービスには、個々のコンポーネントのサービス継続性に関する要件はありません。リソースの可用性は、コンポーネントの可用性に直接反映されます。リソースの可用性を確保することは、ステートレス サービスの可用性を確保するための鍵となります。可能な限り、コンポーネントは、可用性を向上させるだけでなく、スケーラビリティを向上させるためにも、ステートレスになるように設計する必要があります。

ステートレス サービスの場合、サービスを継続的に提供する、独立して利用可能な複数のコンポーネントがあれば十分です。状態が存在しないため、個々のコンポーネントの耐久性は問題になりません。

しかし、十分なリソースがあるだけでは十分ではありません。これらを効果的に使用する必要があります。リソースの可用性を検出し、冗長リソース間で負荷を分散する方法が必要です。

したがって、次の質問に答える必要があります。

• さまざまな失敗を乗り越えるには？
• どの程度のレベルの冗長性が可能ですか?
• リソースでこのようなレベルの冗長性を維持するためのパフォーマンス コストはどれくらいでしょうか?
• これらのレベルの冗長性を管理するための運用コストはいくらですか?

結果として生じるトレードオフは次のようになります。

• 高可用性に対するユーザーのニーズを満たす
• 運営コスト
• 現実世界でそれを可能にするエンジニアリングの実現可能性

冗長コンポーネントとその依存関係は、独立した方法で設計、構成、および運用する必要があります。単純な計算は次のようになります。冗長性のレベルが上がるにつれて、個々のコンポーネントの障害がシステム全体の壊滅的な障害を引き起こす確率は、統計的に指数関数的に低くなります。

Ably では、システムの可用性を高めるために、コンポーネントを複数の可用性ゾーンに分散し、単一の可用性ゾーンでの障害から保護しています。 AWS サービスを使用すると、これは簡単に実行できます。複数のアベイラビリティゾーン (AZ) が同時に失敗することがあります。場合によっては、ローカル接続の問題によりゾーンへのアクセスが妨げられることがあります。場合によっては、リージョンの容量制限により、そのリージョン内のすべてのサービスをサポートできないことがあります。そのため、複数の地域でサービスを提供することで、サービスの可用性も向上します。

複数のリージョンにわたって冗長性を構築することは、複数のゾーンをサポートするほど簡単ではありません。たとえば、ロード バランサ自体がリージョン内に存在していて、使用できなくなる可能性があるため、単にロード バランサを使用してリクエストをリージョン間で分散することは意味がありません。

代わりに、さまざまな対策を組み合わせて、クライアントのリクエストが、正常であるとみなされ、常に利用可能なサービスがあるリージョンにルーティングされるようにします。

ステートフルサービス

Ably では、信頼性とはステートフル サービスのビジネス継続性を意味しますが、これは可用性よりもはるかに複雑な問題です。

ステートフル サービスには、個々のサービス呼び出し全体にわたって存在する状態に対する固有の依存関係があります。この状態の継続はサービスの正確性につながります。継続性の要件は、サービスがフォールト トレラントでなければならないことを意味します。冗長性を使用することで、障害が発生した場合でも状態が失われないようにすることができます。起こりうるビザンチン障害はコンセンサスメカニズムを通じて解決されます。

最も単純な例えは飛行機の安全性です。航空機の墜落は壊滅的ですが、航空機は継続的にサービスを提供する必要があります。これを行わないと、状態が失われ、飛行機が墜落します。

状態に依存するサービスの場合、代替サービスが選択されると、以前のサービスが中断したところから再開できる必要があります。したがって、状態を保持することは必須であり、このような場合には可用性だけでは不十分です。

Ably では、すべての顧客の可用性ニーズをサポートするのに十分なコンピューティング能力を備えたステートレス サービスをプロビジョニングします。ただし、ステートフル サービスの場合、冗長なサービスを提供するだけでなく、冗長性を活用してサービスをサポートし、機能の継続性を確保するための特定のメカニズムも必要です。

たとえば、リクエストがクラスター内のインスタンス上で実行されており、そのインスタンスに障害が発生してリクエストが強制的に転送される場合、リクエストが引き続き実行できることを保証するメカニズムが必要です。

継続実行という目的を達成するために、これはいくつかのレベルで協調した努力の結果です。あるレベルでは、リクエストが正常なサービスに再割り当てされることを保証するメカニズムが存在する必要があります。別のレベルでは、再割り当てされたサービスが、以前のサービスが中断したところから継続されるようにする必要があります。さらに、各サービス自体も一定の冗長性を持って実装・運用されており、サービス全体の信頼性を確保しています。

メカニズムの有効性はサービスの有効性に直接反映されます。例として、保留中のメッセージについて、メッセージの処理結果（成功か失敗か）を正確に把握する必要があるシナリオを考えてみましょう。

クライアントが Ably に公開用のメッセージを送信すると、サービスは公開用のメッセージを受け入れ、クライアントはメッセージの結果を取得することを期待します。この時点で、可用性に関する主な質問は、サービスがメッセージを承認または拒否するのにどのくらいの時間がかかるかということです。

許容される最短時間は 4 秒です。

メッセージを公開したいのに公開できないと言われたら、それはユーザビリティの欠陥です。これはあまり良いことではありませんが、少なくとも当社のサービスが現在利用できないことはご理解いただけます。

しかし、「はい、あなたのメッセージを受け取りました」とうまく返答したとしても、実際にそれを実行しない場合は、それは別の種類の失敗です。これは機能上の問題であり、信頼性の欠陥です。さらに、分散システムにおける信頼性の問題を解決することははるかに複雑であり、信頼性の要件を満たすには多大なエンジニアリングの労力と複雑さが必要になります。

信頼性に対するアーキテクチャアプローチ

以下は、冗長性を活用してメッセージを処理するために Ably で採用しているアーキテクチャ アプローチの説明です。

ハッシュの一貫性

通常、水平スケーラビリティは、スケーラブルなリソースを割り当てることによって実現されます。ステートレス サービスの場合、さまざまな地理的場所にサービスを展開します。リクエストが来ると、ロード バランサは地理的に隣接するサービスやその他の最適化の考慮事項に基づいて、リクエストを処理するサービスを決定します。

同時に、ステートフル サービスの場合、サーバーの配置が特に重要です。サーバーに障害が発生した場合でも、他のサーバーの正常な動作には影響しません。この目標はハッシュの一貫性を通じて達成できます。

具体的な例としては、ハッシュ一貫性アルゴリズムを使用して、どのサーバーがメッセージを処理するかを決定し、同時に、処理のためにメッセージをさまざまなサーバーに均等に分散するように最大限努めます。

メッセージの永続性

メッセージが公開されると、そのメッセージは処理され、応答 (成功または失敗) が呼び出し元に返されます。信頼性とは、メッセージが失われないことを意味します。逆に言えば、メッセージを永続化することによってのみ、サーバーに障害が発生したときに後でメッセージを取得して処理できることを意味します。

まず、少なくとも 2 つの異なるアベイラビリティ ゾーン (AZ) でメッセージの受信を記録します。これは Ably メッセージの永続性の核心であり、複数の場所にメッセージを書き込み、メッセージの書き込みプロセスがトランザクション的であることを保証します。メッセージが正常に書き込まれたか、失敗したかは常にわかります。この保証により、メッセージのその後の処理が保証されます。

単一のイベントまたは原因によってデータが失われないように、メッセージが複数の可用性ゾーンにわたって保持されるようにします。複数の場所への書き込みがトランザクション的であることを保証するには、メッセージ永続性レイヤーでの分散一貫性が必要です。

この方法で構築されたシステムは、すべての可用性ゾーンで同時に障害が発生した場合にのみ使用できなくなりますが、これは非常にまれなイベントです。

私たちの数学モデルでは、ノードに障害が発生した場合、障害を修復するために必要な時間に加えて、各可用性ゾーンの障害率と各可用性ゾーンで連続して障害が発生する確率が既にわかっています。信頼性を最大限に高めるには、8 ～ 9 個の可用性ゾーンが必要であるという結論に達しました。

フォールトトレランスに関するエンジニアリング上の考慮事項

フォールト トレランスを実現するための理論的なアプローチがあったとしても、考慮すべき実際的およびシステム エンジニアリング上の課題は依然として数多くあります。

分散一貫性

ハッシュの一貫性などの上記のメカニズムは、すべてのサーバーが適切に動作している場合にのみ機能します。

これは典型的な一貫性の問題です。クラスター内のメンバーは、それぞれの ID について合意に達する必要があります (マスターとスレーブの関係)。 Raft/Paxos は重要な理論的保証ですが、実際のネットワーク環境、特に複数の地域にまたがるネットワークでは、サーバー間のネットワーク遅延が大きすぎると、これらのアルゴリズムの有効性が低下します。

上記のメカニズム (ロール配置アルゴリズムなど) は、参加しているすべてのエンティティがクラスターのトポロジと各ノードの状態と正常性について合意している場合にのみ有効になります。

代わりに、最終的に一貫性があり、フォールト トレラントで、リージョン間で機能する同時ゴシップ プロトコルを使用します。

結論は

フォールト トレランスの目的は、システムへの障害の影響を軽減し、顧客にサービスを継続的に提供できるようにすることです。

Ably では、サービスをステートフルとステートレスの 2 つのタイプに分類しています。ステートレス サービスは耐障害性が極めて高いですが、ステートフル サービスの場合は、サービスの継続性を確保するために状態の継続性を確保する必要があります。調整

フォールト トレラント システムを実現するには、障害を異常なイベントではなく通常のイベントとして扱う必要があります。理論的なサポートに加えて、フォールト トレラント システムの設計には、多くのシステム エンジニアリングの課題も伴います。これには、インフラストラクチャの可用性とスケーラビリティの問題、分散一貫性の問題、世界中のすべてのノードのネットワーク トポロジを調整する方法、予測不可能なノードの健全性状態の検出の困難さなどが含まれます。

Ably プラットフォームは、クラス最高のエンタープライズ ソリューションを提供することを目標に、これらの原則に基づいてゼロから設計されました。そのため、当社はフォールト トレランスを保証しながら、サービスの可用性と信頼性を自信を持って保証できます。