Consul Kv の Lock 機構の仕様と使い方のメモ
Consul の Kv は気軽に使えるデータストレージという印象だけど、ロック機構もあるようだ。
何度かドキュメントに目を通したけど、イマイチ使い所がわからなくて素通りしていた。
が、意を決して読み込んで手元で試したりして、だいたい理解できたと思うのでメモしておく。
仕様メモ
- まず Session について理解していないといけない
- Session の REST API については https://www.consul.io/docs/agent/http/session.html
- Endpoints:
/v1/session/<operation>
create
,destroy/<session>
,info/<session>
,list
,renew
=> あなたが期待する挙動をするでしょう。node/<node>
... node に紐付いた session をリストする
- Endpoints:
- Session の内部仕様は https://www.consul.io/docs/internals/sessions.html を読む
- Session の REST API については https://www.consul.io/docs/agent/http/session.html
- Kv 側の使い方の話
- Session を指定してロックを取る
PUT /v1/kv/<path>?acquire=<session>
- ロック中も読み書きはできるが、同じ Session を指定しないとロック獲得できない
?acquire=<session>
を付けたときはもちろんロック機構がはたらく。つまり有効なセッションにロックされている間は PUT 失敗する。
- Session を指定してロックを取る
どう使うか
ふつうにセッションとして使えばいいのではないかと。
ただ、API を GET すると Kv も Session も中身が丸見えなので、クライアントが直接 API を叩けない状況で内部的に使うか、または性善説に基いて運用するか(?)。
例えばデプロイとかフェールオーバとかオートスケールとか、同時に多重実行されたくないような処理で Consul Kv でロックを取るようにしておくと安心感が得られそう。
ローカルホストのファイルロックでいいやってケースなら、あまりニーズはないかもしれないが、KVS を mutex 的に使っていたりする場合、置き換え候補になるかも(?)
- 例) デプロイの場合
deploy/<app>/lock
とかの key でロック- Session はデプロイ開始時に取得する
- TTL はこんだけ長かったら異常って値にしておく
- => 排他ロックできる