The Amazon Builders' Library - arosh/arosh.github.com GitHub Wiki

分散システムのリーダー選挙

リーダー選挙はシンプルなアイデアによって多くの問題を解決できるよい方法のように思えるが、いくつかの落とし穴があり事前に慎重な評価が必要である。

落とし穴の例としては…

• リーダーが単一であることに依存した分散システムはスケーリングに弱いかもしれない。単一のホストでは処理しきれないほどリーダーの処理量が増大したとき、あなたのシステムはスケールアウトできるようになっているだろうか？
• カナリアリリースに対応できないかもしれない。ブルー/グリーンデプロイの恩恵は受けられないだろう

この問題を解決するためには、最初からシャーディングを前提としてシステムを設計しなければならない。これはあなたが最初に思っていたほどシンプルな解決法だっただろうか？

リーダー選出によって動くプロセスを正確に実装するのはかなり難しい。自作しようとするのは愚行である。DynamoDB lock client や ZooKeeper を使うべきである。

リーダーがクラッシュしたとき、新しいリーダーはどこから処理を継続すればよいだろうか？これは残念ながらリーダーの処理をすべて冪等にするしかない。リーダーが必ず1台になることを保証するのはかなり難しく、0台または2台存在することがあり得ると考えるのが安全である。

実装時のベストプラクティスとしては

• 自分がリーダーであるかどうか頻繁に確認する
• リーダーシップの変化ログを保存する

https://aws.amazon.com/jp/builders-library/avoiding-fallback-in-distributed-systems/

https://aws.amazon.com/jp/builders-library/implementing-health-checks/

https://aws.amazon.com/jp/builders-library/challenges-with-distributed-systems/

https://aws.amazon.com/jp/builders-library/caching-challenges-and-strategies/

https://aws.amazon.com/jp/builders-library/avoiding-insurmountable-queue-backlogs/

https://aws.amazon.com/jp/builders-library/using-load-shedding-to-avoid-overload/

https://aws.amazon.com/jp/builders-library/timeouts-retries-and-backoff-with-jitter/

https://aws.amazon.com/jp/builders-library/instrumenting-distributed-systems-for-operational-visibility/