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

weblog of key_amb

主にIT関連の技術メモ

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 をリストする
    • 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 はこんだけ長かったら異常って値にしておく
    • => 排他ロックできる