Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Akka Clusterの
耐障害設計
安田裕介
Scala 関西 2016
スピーカーノート
https://github.com/TanUkkii007/blog/blob/master/akka_cluster_resilience.md
自己紹介
• 安田裕介
• @TanUkkii007
• 東京でScalaの仕事をしています
• Akka 好き
Akka Clusterの適用領域
Basically
Soft state
Eventually consistent
Available
client-facingで
な分散システム
Akka Clusterを使う利点
• 位置透過性
• サービスの成長に合わせてスケール戦略を切り替えら
れる
• スケール戦略が変わってもコードが変わらない
• エコシステム
• シャーディングやレプリケーションなど、分散システ
ムでよく用い...
Akka Clusterの基本
Akka Clusterとは?
• クラスターのメンバーシップ管理を行うAkka拡張
• Amazon Dynamoやriakに影響を受けている
• gossipプロトコルによるメンバーの状態伝播と、
failure detectorによる障害...
failure detector
• クラスターのメンバーは互いにハー
トビートを送り合っている
• failure detectorはハートビートをも
とにメンバーの生死を推測する
• 生きているメンバーはreachable、
死んでいるメン...
gossipプロトコルと
メンバーシップライフサイク
ル
• メンバーには状態があり、gossipプロトコルで他のメン
バーと状態を同期する
• gossip収束時に一意に決まるリーダーという役割がある
• リーダーがメンバーの状態を変える行為...
Akka Clusterの
耐障害性設計
故障の単位:プロセス
• 故障の単位をプロセスという
• アクタープログラミングではプロセスはアクター
• この発表ではAkka Clusterの1ノードをプロセスとする
• つまりAkka ClusterのUNIXプロセスと同義
故障の種類
クラッシュストップ故障
オミッション(切り捨て)故障
クラッシュ・リカバリー故障
ビザンチン(任意)故障
Reliable and secure distributed programming, Ch.2
クラッシュストップ故障
オミッション(切り捨て)故障
クラッシュ・リカバリー故障
ビザンチン(任意)故障
Reliable and secure distributed programming, Ch.2
クラッシュストップ故障
クラッシュストップ故障
• 正常に処理を実行していたプロセスがある時刻以降
処理を停止して2度と戻らない故障
• 故障のなかでもっとも単純
• Akka Clusterのレイヤーで考えなければならない故
障のほぼ全てはこれ
クラッシュストップ故障で
停止する処理
• unreachableなメンバーがいると、gossipプロトコルで状
態を完全に同期できない(gissip非収束状態)
• クラスターの状態を変えるリーダーアクションが行えな
くなる
• →メンバーの...
gossip非収束状態の解決
• unreachableなメンバーのハートビート
が回復してfailure detectorによって再び
reachableになる
• unreachableなメンバーをdown状態にす
る
クラスターのメンバー...
Auto-downing
• デフォルトではunreachableなメンバーを自動的に
down状態にはしない
• リーダーがunreachableなメンバーを指定時間後に
自動的にdownする機能にauto-downがある
• auto-do...
なぜauto-downを
使ってはならないのかを考える
根本的な問題は、failure detectorがメンバーを
unreachableと判定したとき、そのメンバーは本当に死
んでいるのか、ネットワーク遅延や分断なのか、GCや
負荷による遅...
split brain問題
• failure detectorがメンバーを死と推
定したとしても、実際には生きてい
る場合がある
• 生きているメンバーをクラスターか
ら分離すると、結果的にクラスター
が分裂する問題をsplit brain問...
リーダーの決定
• リーダー選出という過程はない
• 各メンバーがgossipプロトコルで同期されたメンバーリストから独立に決める
• リーダーはunreachableでないメンバーのうちUpとLeaving状態のものを優先的に選択し、アドレス...
auto-downが引き起こすsplit brain
split brain問題を解決するには
• リーダーよりも整合性の高い方法で決定でき、
downを果たせる役割は何か?
• 2つ以上に分割される場合、どれが正しいクラスタ
ーなのか?
• 正しくないクラスターを決めたとして、そのメンバ
ーをど...
split brain resolver
• Keep Reference
• Keep Oldest
• Static Quorum
• Keep Majority
• Lightbend Reactive Platform
• TanUkk...
Keep Oldest
• 最古のメンバーがいる側を正のクラスターとする
• 最古のメンバーとは起動時のタイムスタンプがもっとも小さいもの
• そうでない側のメンバーは自らシャットダウンする
• unreachableなメンバーをdownする役...
Keep Oldest
Static Quorum
• 残存メンバーがquorum sizeに満たない場合、そのメンバーを
downしする
• 他のメンバーをdownする役割はリーダーが担う
• quorum-size * 2 - 1を超えるメンバーを追加しない限りs...
Static Quorum
FLP Impossibility
“非同期なシステムにおいては、
ただ1つのプロセスが故障しただけでも、
完璧に合意できる分散アルゴリズムは存在しない”
Fisher, Lynch, Paterson (1985) Impossibility...
オミッション(切り捨て)故障
クラッシュ・リカバリー故障
ビザンチン(任意)故障
Reliable and secure distributed programming, Ch.2
オミッション(切り捨て)故障
クラッシュストップ故障
オミッション(切り捨て)故障
• プロセスが送るべきメッセージを送らない、あるいは
受信するべきメッセージを受信できない故障
• プロセスがクラッシュした場合も送るべきメッセージ
を送れないので、オミッション故障はクラッシュスト
ップ故障のより...
Akka Remoteにおける
オミッション故障
• システムメッセージを送信できず、ローカルとリモートのアクターシ
ステム間の状態が同期できなくなったときにオミッション故障となる
• システムメッセージには、リモートスーパーバイザーに管理され...
オミッション(切り捨て)故障
クラッシュ・リカバリー故障
ビザンチン(任意)故障
Reliable and secure distributed programming, Ch.2
クラッシュ・リカバリー故障
クラッシュストップ故障
クラッシュ・リカバリー故障
• プロセスがクラッシュしただけでなく、そこからリ
カバリーできない、あるいはクラッシュと再起動を
繰り返してしまう故障
• リカバリーできない場合、送るべきはずのメッセー
ジを送れないので、オミッション故障と見るこ...
Akka Clusterにおける
クラッシュ・リカバリー故障
• クラッシュして取り除かれたノードが再起動してク
ラスターに再加入することを前提としていない
• クラッシュ・リカバリー故障はおきない
メンバーの識別
• Akka Clusterはメンバーをhostname:port:uidの3つの識別子で
認識する
• uidはアクターシステム起動時に発行されるユニークなID
• ホストとポートが同じでも、再起動した後ではuidが異なる
•...
蘇り(incarnation)ノード
• Q: クラッシュしたメンバーはunreachableとなってリーダーアクションが
とれなくなるため、再起動してもノードがクラスターに再加入できるの
か?
• A: できる
• クラスターのメンバーと同じ...
再起動が引き起こす
split brain問題
正しい第一seed設定
再起動が引き起こす
split brain問題
誤った第一seed設定
Upcoming SlideShare
Loading in …5
×

Akka Clusterの耐障害設計

4,506 views

Published on

Scala Kansai summit 2016で発表した資料です

Published in: Engineering
  • Be the first to comment

Akka Clusterの耐障害設計

  1. 1. Akka Clusterの 耐障害設計 安田裕介 Scala 関西 2016 スピーカーノート https://github.com/TanUkkii007/blog/blob/master/akka_cluster_resilience.md
  2. 2. 自己紹介 • 安田裕介 • @TanUkkii007 • 東京でScalaの仕事をしています • Akka 好き
  3. 3. Akka Clusterの適用領域 Basically Soft state Eventually consistent Available client-facingで な分散システム
  4. 4. Akka Clusterを使う利点 • 位置透過性 • サービスの成長に合わせてスケール戦略を切り替えら れる • スケール戦略が変わってもコードが変わらない • エコシステム • シャーディングやレプリケーションなど、分散システ ムでよく用いるアルゴリズムを実装した拡張がある
  5. 5. Akka Clusterの基本
  6. 6. Akka Clusterとは? • クラスターのメンバーシップ管理を行うAkka拡張 • Amazon Dynamoやriakに影響を受けている • gossipプロトコルによるメンバーの状態伝播と、 failure detectorによる障害検知を可能にする
  7. 7. failure detector • クラスターのメンバーは互いにハー トビートを送り合っている • failure detectorはハートビートをも とにメンバーの生死を推測する • 生きているメンバーはreachable、 死んでいるメンバーはunreachable とマークする
  8. 8. gossipプロトコルと メンバーシップライフサイク ル • メンバーには状態があり、gossipプロトコルで他のメン バーと状態を同期する • gossip収束時に一意に決まるリーダーという役割がある • リーダーがメンバーの状態を変える行為をリーダーアク ションという • クラスターに参加するメンバーはjoining状態から始まる • リーダーはjoining状態のメンバーをup状態にし、クラス ターに参加させる • down状態になったメンバーは、リーダーによって removed状態にされ、クラスターから取り除かれる doc.akka.io
  9. 9. Akka Clusterの 耐障害性設計
  10. 10. 故障の単位:プロセス • 故障の単位をプロセスという • アクタープログラミングではプロセスはアクター • この発表ではAkka Clusterの1ノードをプロセスとする • つまりAkka ClusterのUNIXプロセスと同義
  11. 11. 故障の種類 クラッシュストップ故障 オミッション(切り捨て)故障 クラッシュ・リカバリー故障 ビザンチン(任意)故障 Reliable and secure distributed programming, Ch.2
  12. 12. クラッシュストップ故障 オミッション(切り捨て)故障 クラッシュ・リカバリー故障 ビザンチン(任意)故障 Reliable and secure distributed programming, Ch.2 クラッシュストップ故障
  13. 13. クラッシュストップ故障 • 正常に処理を実行していたプロセスがある時刻以降 処理を停止して2度と戻らない故障 • 故障のなかでもっとも単純 • Akka Clusterのレイヤーで考えなければならない故 障のほぼ全てはこれ
  14. 14. クラッシュストップ故障で 停止する処理 • unreachableなメンバーがいると、gossipプロトコルで状 態を完全に同期できない(gissip非収束状態) • クラスターの状態を変えるリーダーアクションが行えな くなる • →メンバーの追加ができない
  15. 15. gossip非収束状態の解決 • unreachableなメンバーのハートビート が回復してfailure detectorによって再び reachableになる • unreachableなメンバーをdown状態にす る クラスターのメンバーがクラッシュストップ故障を起こすと、そのメ ンバーにgossipプロトコルによってクラスターの状態を伝播できなく なる。このときgossipは収束しない。 gossipの非収束を解決する方法 doc.akka.io
  16. 16. Auto-downing • デフォルトではunreachableなメンバーを自動的に down状態にはしない • リーダーがunreachableなメンバーを指定時間後に 自動的にdownする機能にauto-downがある • auto-downは使ってはならない _人人人人人人人人_ > <  ̄Y^Y^Y^Y^Y^Y^Y ̄ doc.akka.io
  17. 17. なぜauto-downを 使ってはならないのかを考える 根本的な問題は、failure detectorがメンバーを unreachableと判定したとき、そのメンバーは本当に死 んでいるのか、ネットワーク遅延や分断なのか、GCや 負荷による遅延なのかが分からないということ。 この問題が分散システムを難しくしている理由の1つ。 downしたメンバーが実は生きていた場合、split brain問 題がおきる。
  18. 18. split brain問題 • failure detectorがメンバーを死と推 定したとしても、実際には生きてい る場合がある • 生きているメンバーをクラスターか ら分離すると、結果的にクラスター が分裂する問題をsplit brain問題とい う • 分離したクラスターの状態は同期出 来ず、誤った情報をクライアントや DBに伝える
  19. 19. リーダーの決定 • リーダー選出という過程はない • 各メンバーがgossipプロトコルで同期されたメンバーリストから独立に決める • リーダーはunreachableでないメンバーのうちUpとLeaving状態のものを優先的に選択し、アドレス順に並べて先頭のもの /** * Up|Leaving, Joining, Exiting, Downの順に並べ先頭のものがリーダー。同じ状態の場合最小のアドバイスのものを選ぶ。コードは以下を参照。 * https://github.com/akka/akka/blob/v2.4.10/akka-cluster/src/main/scala/akka/cluster/Gossip.scala#L190-L196 */ val leader = reachableMembers.min(Ordering.fromLessThan[Member] { (a, b) ⇒ (a.status, b.status) match { case (as, bs) if as == bs ⇒ Member.addressOrdering.compare(a.address, b.address) <= 0 case (Down, _) ⇒ false case (_, Down) ⇒ true case (Exiting, _) ⇒ false case (_, Exiting) ⇒ true case (Joining, _) ⇒ false case (_, Joining) ⇒ true case _ ⇒ Member.addressOrdering.compare(a.address, b.address) <= 0 } })
  20. 20. auto-downが引き起こすsplit brain
  21. 21. split brain問題を解決するには • リーダーよりも整合性の高い方法で決定でき、 downを果たせる役割は何か? • 2つ以上に分割される場合、どれが正しいクラスタ ーなのか? • 正しくないクラスターを決めたとして、そのメンバ ーをどうすべきか?
  22. 22. split brain resolver • Keep Reference • Keep Oldest • Static Quorum • Keep Majority • Lightbend Reactive Platform • TanUkkii007/akka-cluster-custom-downing split-brain-resolverのストラテジ
  23. 23. Keep Oldest • 最古のメンバーがいる側を正のクラスターとする • 最古のメンバーとは起動時のタイムスタンプがもっとも小さいもの • そうでない側のメンバーは自らシャットダウンする • unreachableなメンバーをdownする役割は最古メンバーが担う • 最古のメンバーはgossip非収束時にも一意に決まる(※例外あり) • 可用性の点で問題あり。最古のメンバーが故障した場合、全クラスター がシャットダウンする。(オプションで回避可能) val oldest = members.filterNot(_.status == Removed).min(Member.ageOrdering)
  24. 24. Keep Oldest
  25. 25. Static Quorum • 残存メンバーがquorum sizeに満たない場合、そのメンバーを downしする • 他のメンバーをdownする役割はリーダーが担う • quorum-size * 2 - 1を超えるメンバーを追加しない限りsplit brainは おきない • quorum-sizeと総ノード数で可用性を調節可能 • メンバーの数を固定しなければならない点が弱点。quorumを適用 するロールを限定して他のロールのメンバー数を動的にすると良 い。
  26. 26. Static Quorum
  27. 27. FLP Impossibility “非同期なシステムにおいては、 ただ1つのプロセスが故障しただけでも、 完璧に合意できる分散アルゴリズムは存在しない” Fisher, Lynch, Paterson (1985) Impossibility of Distributed Consensus with One Faulty Process 完璧なsplit brain resolverのストラテジはない
  28. 28. オミッション(切り捨て)故障 クラッシュ・リカバリー故障 ビザンチン(任意)故障 Reliable and secure distributed programming, Ch.2 オミッション(切り捨て)故障 クラッシュストップ故障
  29. 29. オミッション(切り捨て)故障 • プロセスが送るべきメッセージを送らない、あるいは 受信するべきメッセージを受信できない故障 • プロセスがクラッシュした場合も送るべきメッセージ を送れないので、オミッション故障はクラッシュスト ップ故障のより一般的な場合と見ることができる
  30. 30. Akka Remoteにおける オミッション故障 • システムメッセージを送信できず、ローカルとリモートのアクターシ ステム間の状態が同期できなくなったときにオミッション故障となる • システムメッセージには、リモートスーパーバイザーに管理されたア クターのライフサイクルイベント、watchによる死活監視、リモート アクターのデプロイメントがある • このときAkka Remoteの状態はquarantinedになり、そのメンバーは unreachableから戻ってこれなくなる • split brain resolverを使用している場合、unreachableなメンバーはク ラスターから取り除かれ、取り除かれたメンバーはシャットダウンす る→クラッシュストップ故障と全く同じ扱いになる
  31. 31. オミッション(切り捨て)故障 クラッシュ・リカバリー故障 ビザンチン(任意)故障 Reliable and secure distributed programming, Ch.2 クラッシュ・リカバリー故障 クラッシュストップ故障
  32. 32. クラッシュ・リカバリー故障 • プロセスがクラッシュしただけでなく、そこからリ カバリーできない、あるいはクラッシュと再起動を 繰り返してしまう故障 • リカバリーできない場合、送るべきはずのメッセー ジを送れないので、オミッション故障と見ることも できる
  33. 33. Akka Clusterにおける クラッシュ・リカバリー故障 • クラッシュして取り除かれたノードが再起動してク ラスターに再加入することを前提としていない • クラッシュ・リカバリー故障はおきない
  34. 34. メンバーの識別 • Akka Clusterはメンバーをhostname:port:uidの3つの識別子で 認識する • uidはアクターシステム起動時に発行されるユニークなID • ホストとポートが同じでも、再起動した後ではuidが異なる • つまりクラッシュして再起動したプロセスは、以前のプロセス と別物と認識される • →新しくクラスターに加入することと全く同じ:クラッシュ・ リカバリー故障はおきない
  35. 35. 蘇り(incarnation)ノード • Q: クラッシュしたメンバーはunreachableとなってリーダーアクションが とれなくなるため、再起動してもノードがクラスターに再加入できるの か? • A: できる • クラスターのメンバーと同じホスト:ポートのペアをもつメンバーが加 入(joining)してきた場合、リーダーは古いメンバーを自動的にdownす る • 同じホスト:ポートのペアをもつメンバーが同時に2つ存在することは ありえない。古いメンバーはクラッシュしたことをリーダーは判断でき る。 • auto-downやsplit brain resolverを使わなくてもこの機能は働く
  36. 36. 再起動が引き起こす split brain問題 正しい第一seed設定
  37. 37. 再起動が引き起こす split brain問題 誤った第一seed設定

×