読者です 読者をやめる 読者になる 読者になる

テストステ論

高テス協会会長が, テストステロンに関する情報をお届けします.

Bizur: 不明点と欠陥点

(不明) クライアントがあるバケットについてリーダーを探す方法が不明

これは単に書かれていない. Raftと同等にすれば出来ると考えられる.

(不明) Leader Electionをキックする方法が不明

これも, 何をきっかけにしてProcedure STARTELECTIONを実行するのかが書かれていない. Raftのようにheartbeatを飛ばすと仮定すると, もしそれがShard単位であるとしてもheartbeatが飛びすぎるように思う. あと, heartbeatを飛ばすにしても, Raftのようにログを持っていないので, heartbeatに対してackするかどうかの判定が出来ない. bucketのclockを上げてtouchすることが同等の処理かも知れないが, heartbeatが多すぎる.

(欠陥) Reconfigurationが危険

これは言ってることがおかしい. BizurのReconfigurationの仕組みは, 2つのBizurインスタンスを作って, 新しい方をrwキャッシュのように扱い, アクセス契機にmigrationをするというものなのだが, まずこれがどうやって実行されるかが分からない.

さらに, メンバーシップの変更はRaftではログとして実行される. 実際にはこれを同等のことをしなければいけないはずだが, なぜか同時刻に全BizurインスタンスがReconfigurationを始められることになっている. それは保証出来ないから, 中間的にmajorityの定義がサーバー間でずれてしまい, 実際には全サーバの中でmajorityが合意したわけではないのに合意したことになってしまうタイミングが存在しうる.

議論がラフなので実用性がない.

一つの解決策として思い付くのは, RaftとBizurを組み合わせることだ. 入り口はRaftにして, 実際の実行はBizurにする.

ただ, これは元アイデアとして挙げている  https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/eurosys2006.pdf を読まないと断言は出来ない.

(欠陥) 挙げているログベースの問題を全解決してるわけではない

ログベースの問題として挙げている

a slow operation will affect unrelated succeeding operations

は解決されない. 仮に同じバケットに対する処理が2つあって, 最初に実行が始まった処理が重い場合はあとの処理が待たされることには変わらない. 単にShardやBucketに散らしていることによって可能性を定数で減らしているにすぎない.

(欠陥) Reconfigrationで2倍の容量が必要になる

Reconfigurationは2つのBizurインスタンスを作って, oldからnewにmigrateしていくことになる. 途中で電源断などが起こる場合を考えると, 全部migrateし終えるまではoldを消せない. これはコピーGCのようなものだから, 論理容量の2倍の容量(メモリがストレージかは用途次第)を必要とする.