https://keyamb.hatenablog.com/entry/2016/03/14/161436

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 をリストする
- Session の内部仕様は https://www.consul.io/docs/internals/sessions.html を読む
  - Kv と統合されている機能がある
    - => Kv のロック機構で Session を利用している
    - 無効なセッションを指定してロックを獲得することはできない
  - Session に指定する JSON のプロパティ:
    - LockDelay - 無効化されたセッションが再利用されることを防ぐ時間。デフォルト15秒
    - Behavior
      - release ... 単にロックを解放するだけ。ロックされていた Kv は acquire 可能になる
      - delete ... Kv でロックされていたエントリを削除する
    - TTL - 10s 〜 86400s . デフォルトは "" (空文字列)で無期限を意味する。
Kv 側の使い方の話
- Session を指定してロックを取る
  - PUT /v1/kv/<path>?acquire=<session>
  - ロック中も読み書きはできるが、同じ Session を指定しないとロック獲得できない
    - ?acquire=<session> を付けたときはもちろんロック機構がはたらく。つまり有効なセッションにロックされている間は PUT 失敗する。

どう使うか

ふつうにセッションとして使えばいいのではないかと。
ただ、API を GET すると Kv も Session も中身が丸見えなので、クライアントが直接 API を叩けない状況で内部的に使うか、または性善説に基いて運用するか(？)。

例えばデプロイとかフェールオーバとかオートスケールとか、同時に多重実行されたくないような処理で Consul Kv でロックを取るようにしておくと安心感が得られそう。

ローカルホストのファイルロックでいいやってケースなら、あまりニーズはないかもしれないが、KVS を mutex 的に使っていたりする場合、置き換え候補になるかも(？)

例) デプロイの場合
- deploy/<app>/lock とかの key でロック
  - Session はデプロイ開始時に取得する
  - TTL はこんだけ長かったら異常って値にしておく
- => 排他ロックできる