REL 4: 障害を防ぐために、分散システムの操作をどのように設計しますか?
分散システムは、サーバーやサービスなどのコンポーネントを相互接続するために通信ネットワークを利用しています。このネットワークでデータの損失やレイテンシーがあっても、ワークロードは確実に動作する必要があります。分散システムのコンポーネントは、他のコンポーネントやワークロードに悪影響を与えない方法で動作する必要があります。これらのベストプラクティスは、故障を防ぎ、平均故障間隔 (MTBF) を改善します。
リソース
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems,
Big and Small ARC337 (includes loose coupling, constant work, static stability)
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge
(MAD205)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
Amazon EC2: Ensuring Idempotency
The Amazon Builders' Library: Challenges with distributed systems
ベストプラクティス:
-
必要な分散システムの種類を特定する: ハードなリアルタイム分散システムでは、応答を同期的かつ迅速に行えるようにする必要がありますが、ソフトなリアルタイムシステムでは、応答に数分以上の余裕をもった時間枠があります。オフラインシステムは、バッチ処理または非同期処理を通じて応答を処理します。ハードなリアルタイム分散システムは、最も厳格な信頼性要件を持っています。
-
疎結合の依存関係を実装する: キューイングシステム、ストリーミングシステム、ワークフロー、ロードバランサーなどの依存関係は、緩やかに結合しています。疎結合は、コンポーネントの動作をそれに依存する他のコンポーネントから分離するのに役立ち、弾力性と俊敏性を高めます。
-
すべての応答にべき等性を持たせる: べき等のサービスは、各リクエストが 1 回だけで完了することを約束します。そのため、同一のリクエストを複数回行っても、リクエストを 1 回行ったのと同じ効果しかありません。べき等サービスを使用すると、リクエストが誤って複数回処理されることを恐れる必要がなくなるため、クライアントが再試行を行いやすくなります。このために、クライアントはべき等性トークンを使用して API リクエストを発行できます。リクエストが繰り返される場合は常に同じトークンが使われます。べき等サービス API はトークンを使用して、リクエストが最初に完了したときに返された応答と同じ応答を返します。
-
動作を継続的に行う: 負荷が急激に大きく変化すると、システム障害が発生することがあります。たとえば、何千台ものサーバーの状態をモニタリングするヘルスチェックシステムは、毎回同じサイズのペイロード (現在の状態の完全なスナップショット) を送信しています。障害が発生しているサーバーがなくても、またはそのすべてに障害が発生していても、ヘルスチェックシステムは、大きく急激な変更なしに常に作業を行っています。
改善計画
必要な分散システムの種類を特定する
The Amazon Builders' Library: Challenges with distributed systems
- ハードなリアルタイム分散システムでは、応答を同期的かつ迅速に与える必要があります。
- ソフトなリアルタイムシステムでは、応答に数分以上の余裕をもった時間枠があります
- オフラインシステムは、バッチ処理または非同期処理を通じて応答を処理します。
- ハードなリアルタイム分散システムは、最も厳格な信頼性要件を持っています。
疎結合の依存関係を実装する
AWS re:Invent 2019: Moving to event-driven architectures (SVS308)
What Is Amazon EventBridge?
What Is Amazon Simple Queue Service?
- Amazon EventBridge では、疎結合で分散されたイベント駆動型アーキテクチャを構築できます
AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (MAD205) - 1 つのコンポーネントを変更すると、それに依存する他のコンポーネントも強制的に変更される場合、それらは密結合されています。疎結合はこの依存関係を壊すため、依存関係コンポーネントが知る必要があるのは、バージョン付きで公開されたインターフェイスのみです。
- 可能な限り、コンポーネントのインタラクションを非同期にします。このモデルは、即時応答を必要とせず、要求が登録されていることの確認が十分である状況では、どのような対話にも最適です。
AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda (API304)
すべての応答にべき等性を持たせる
- クライアントはべき等性トークンを使用して API リクエストを発行できます。リクエストが繰り返される場合は常に同じトークンが使われます。べき等サービス API はトークンを使用して、リクエストが最初に完了したときに返された応答と同じ応答を返します。
Amazon EC2: Ensuring Idempotency
動作を継続的に行う
AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work)
- 成功または失敗の数に関係なく、ペイロードサイズが一定になるようにワークロードをエンジニアします。
- たとえば、ヘルスチェックシステムが 100,000 台のサーバーをモニタリングしている場合、通常のサーバー障害率が軽いときは、その負荷はわずかです。ただし、重大なイベントによってこれらのサーバーの半分が異常な状態になると、ヘルスチェックシステムは、通知システムを更新し、クライアントに状態を通知しようとして過負荷になります。したがって、ヘルスチェックシステムは、現在の状態の完全なスナップショットを毎回送信する必要があります。サーバーヘルス状態が 100,000 (それぞれ 1 ビットで表される) のペイロードは、12.5 KB にすぎません。サーバーで障害が発生しているかいないかにかかわらず、すべてのサーバーについて、ヘルスチェックシステムは常に作業を行っており、大規模で急速な変化があっても、システムの安定性は脅かされません。実際、Amazon Route 53 ヘルスチェックのコントロールプレーンはこのように設計されています。