Cloud and Distributed Systems Laboratoryはじめに
今日、プロセスを監視・管理できる方法は今更作る必要がないほどあります(Zabbixだったりコマンドを打って見たり)。便利な世の中です。ですが、ここでは自分なりのプロセスの監視・管理方法を提案させていただこうと思います。
障害の透過性
分散システムには「透過性」という概念があります。簡潔に言うと、システムのあらゆる側面、処理を隠すことです。透過する対象はいくつかありますが、特に障害の透過性の実現は困難とされています。死んだプロセスと非常に反応が遅いプロセスの判別をつけることが難しいことが原因とされています。
なにがしたい
分散システム内の死んだプロセスと非常に反応が遅いプロセスの判別をしたい。
提案
登場人物
- Leader
- 全体の動きをコントロール、Reporterに処理を渡したりとみんなのまとめ役
- 状態判別の決定を行う
- 監視サーバにいる
- Reporter
- 分散システムを構成している各ノードに常駐する
- Leaderからの要求に応じてプロセス状態の送信
- Reporterは以下の返事を送ることができる
- Alive：プロセスが生きていた
- Dead：プロセスが死んでいた
- NoReply：返事が無かった
処理の流れ
下の図はReporter2が常駐しているノードのプロセスに異常の可能性が見られる状況を表しています。
1. 異常を検出したときのアラートをLeaderが受け取る
2. Leaderは健康なノードのReporter1,3へプロセス状態の確認を依頼する(返事が来なかったらNoReply)
3. 依頼を受けたReporter1,3はプロセス異常が疑われるノードのReporter2にプロセス状態の送信を依頼。Reporter2は自ノードのプロセス状態をReporter1,3へ送信
4. Reporter2から受けた応答(Alive or Dead)をLeaderへ返す。返ってこなかった場合はNoReplyをLeaderへ返す。
5. Leaderは返された状態(Alive or Dead)の数が過半数に達した方をそのプロセスの状態として決定する.
信頼度
LeaderはReporterが送ってきたプロセス状態から過半数に至った状態(Alive,Dead)を最終決定とします。いわばプロセス状態選挙のようなものです。しかし、このままではどちらも過半数得られない、票が割れてしまった場合は一つに決定できません。そこで、これまでの各Reporterに信頼度という重みをつけてみる事を提案します。皆さんにも信頼できる人、できない人がいるはずです。そんな現実の人間関係のしがらみを持ち込みます。本提案の信頼度は以下の３つになります。
normalを初期値として,Leaderへ返した状態が過半数に達したときに、そのReporterの信頼度を上昇させます。過半数に達しなかった場合は下降します。票が割れてしまった場合、Leaderは信頼度の高いReporterからの情報を優先して判断材料にします。以下に示す図のようになります。
上の図ではAliveとDeadが2票で票数だけでは判断できません。しかし、Aliveと送ったtrustのReporterが2つと、Deadと送ったReporterよりも信頼度が高いのでAliveと判定されます。
会議ID
各ノードで通信する関係上、応答が遅延してしまう事も考えられます。前のプロセス判別の処理(会議1とします)が終了した後、次のプロセスの判別の処理(会議2とします)が開始されたとします。会議2の途中で、遅れていたReporterが会議1の返答を送ったとしたら大変です。前の議題の回答を送っているわけです(今晩の晩御飯のメニューについて話し合っているのに、遅れて参加してきて、すでに済ませた今日の昼食のメニューの回答をしてくるような感じ)。これが起こってしまったら正常に処理が行われなくなる可能性があります。
その対策として,プロセス状態の決定の一連の処理(以下、会議とします)に会議IDという固有のIDをつけることを提案します。Leaderは会議が完了するたびに会議IDを１ずつ変更します。会議IDはLeaderのみ管理することが出来ます。このIDと共に通信を行う事により,現在の議題についての回答かわかるようになります。以前の会議の返答をしたReporterは会議に不参加とします。途中参加は認めません。
以上の説明を以下の図にまとめてみました。
まとめ
本記事で提案の説明をさせていただきました。読んでいると気付かれる方もいるかもしれませんが、本提案は分散合意アルゴリズム(Raft,Paxos,etc)に多分に影響を受けています。さらに、現状では実験が出来ておらず定量的な評価を示せていない点もも私の力不足です。記述していませんが他にも問題点が山積みです。本提案を実用的なものには程遠いものです。最適なアプローチの模索、実験をすべきです。
記事は以上になります。お疲れさまでした。