kikumotoのメモ帳

インフラ・ミドル周りを中心に、興味をもったことを適当な感じで。twitter : @takakiku

続：Consul 0.6でユーザのいるshardを探す（Prepared Queryを使う）

Consul HashiCorp

この記事は HashiCorp Advent Calendar 2015 - Qiita の２３日目です。（１時間ほど早めに公開したのでブログの日付は２２ですが）

前回の記事 Consul 0.6でユーザのいるshardを探す（Prepared Queryを使う） - kikumotoのメモ帳 の続編です。

id:fujiwara さんの

Consul 0.6でユーザのいるshardを探す（Prepared Queryを使う） - kikumotoのメモ帳

数百万のPQがconsulに登録されても大丈夫なものだろうか

2015/12/21 07:25
b.hatena.ne.jp というコメントを受けて、Prepared Queryを１００万件突っ込んでみた結果をまとめます。

結果

先に結果を。

100万件PQを突っ込みましたが、DNSの応答は10件だけ登録のときも、100万件登録後も、ほぼ2msecとなり特に性能面での変化は見られませんでした。

ただ、PQの登録については若干劣化（最初は0.9msくらいあったのが、1.5msくらいになった）するようです。ただし、環境が安定しているかどうかは確証がもてないので、参考程度に。

あと、

fujiwara on Twitter: "@takakiku ユーザーデータに関連するものは基本consulには入れないようにしています。kvは大量に更新するとメモリとdisk容量肥大化して、消しても勝手には小さくならないみたいなので"

というコメントもいただき、突っ込んだデータを削除しました。

確かに、Disk使用量が減ることはなかったです。

一方で、メモリの方は解放されているようです（Consul0.6のため？0.5では未検証）。

環境

項目 内容
Consul version 0.6
Consul server ５ノード
Consul client ４ノード
Consul データパス /dev/shm/consul_data（tmpfs）
メモリ（全ノード共通） 16GB
CPU Xeon(R) CPU E5-2407（４コア）
OS CentOS5,6,7混在

という感じで、特にデータは tmpfs 上において試しました。（これは各ノードのDisk性能が一律ではないため、今回の評価用にこの設定にしてあります。）

データの登録

データの登録は下記のようなrubyコードで行いました。Keep-Aliveしながら、一件ごとの登録にかかった時間を記録しています。

#!/usr/bin/env ruby

require 'net/https'
require 'uri'
require 'benchmark'

base_uri = "http://localhost:8500/v1/query"
uri = URI.parse(base_uri)
c = Net::HTTP.new(uri.host, uri.port)
req = Net::HTTP::Post.new(uri.path)

c.start do |x|
  11.upto(1000000) { |i|
    id = sprintf("%07d", i)
    req.body = <<-EOS
    {"Name":"mdb-#{id}","Service":{"Service":"db01","Tags":["master"]},"DNS":{"TTL":"30s"}}
    EOS
    res = nil
    time = Benchmark.realtime do
      res = x.request(req)
    end
    puts "#{id}, #{time}, #{res.code}, #{res.body}"
  }
end

登録は、leaderノード上で実行しました。

登録前後、削除後の状況

登録前は厳密には、10件だけPQを登録した状態です。

　 DNS応答(ms) データサイズ(byte) メモリ空容量(byte) １件登録時間(ms)
登録前 2 262144 6523371520 0.9 〜 1.0（10件登録した時）
登録後 2 134217728 5202753454 1.3 〜 1.6（100万件付近）
削除後 - 134217728 6361238449 -

◼︎ 測定方法について

  • DNSはdigの結果に表示されるQuery timeを取得（CacheにのっていないURLをqueryしてます）。
  • データサイズは /dev/shm/consul_data/raft/raft.db のサイズ。ls より。
  • メモリ空容量は、freeコマンでのfeeの値。
  • １件登録時間は、登録スクリプトの出力より、目でみておおよその値を抽出。

メモリの状況は下記グラフも載せておきます。下がり始めたところが、100万件データを入れているところ。回復しているところが削除しているタイミングなので、メモリは回復する感じです。

f:id:kikumoto:20151222112055p:plain

まとめ

  • 100万件PQ入れてもDNS引きに関して性能面での劣化はない。
  • データ登録については性能劣化がある。
  • データ削除しても、Disk容量は減らない。
  • データ削除するとメモリは解放される。

実際は各自の用法・設定に合わせて確認してもらうのが一番なので、以上の結果は参考程度にどうぞ。

また、利用用途としても多分ソシャゲのような数百万ユーザが対象なものについて、この方法を採るのはちょっと微妙かなという印象です。DNS引きに影響はないにしても、登録や削除が頻繁なものにはちょっとという気がします。（障害時のデータ復元も大変そう）

自分の想定環境では多くて１０万ユーザ、多分１万ユーザくらいの登録で、変動も頻繁でなく、PQのデータはすべてDBから復元可能なので、DNS引きだけでshardを解決できるという利点をとって採用方向で、今後本番環境内でConsulの動作試験していくかなぁという感じです。

何がご要望がいただければ、お正月に試すかもしれません。（ただ寝てるかもしれません）