so this is KeyDB! So what.

redisの代わりにkeydbを使ってみた話
OSunC 2021/04/17 Spring/Onlineより

Transcript

1. KeyDBですが、なにか? So this is the ”KeyDB”, so what? DB alternative探訪シリーズ part 3 forked redis OSunC 2021 Online Spring / 2021-04-17 @naoto_gohko
2. LT presenter(Itʼs me) • Naoto Gohko / 郷古 直仁 (@naoto_gohko) • Cloud Service development divistion, GMO Internet Inc., • OpenStackでpublic cloudサービス • 最近の活動主体 • Japan OpenStack user会 / OSC onlineお⼿伝い(Zoom修⾏) • 最近 • 最近とある製品のre: brandにより、美雲あんずは ConoHaショップ店⻑になったらしい @MikumoConoHa @MikumoAnzu
3. 暖かくなってきました。 皆様 お出かけしたいですね …… そんな中、とある仕事 でのweb APIをpython で作る案件で
4. 古きVM構成と冗⻑とローカリティ • Python flask(rest API) + celery + redis + mongodb構成 • 低コスト(3 VM : node)で冗⻑性について考えてみる • redis : Celeryのbroker store (MQ) • mongodb : APIの処理の結果を永続保存 • flaskでのrest APIをceleryでfront(API) + celery(worker)に分離する • node A : • node B : どうはいちする? • node C : • docker/container じゃない
5. その時のredisについて考える • Redis 3.0から : Redis clusterにてmulti-master対応 • è 普通にmult-masterならとくに問題ない • 2020/10⽉ぐらい • è Redis 6.0 branch (v5.9.103) 以降 redis6 multithread I/Oが⼊ってきている その少し前 • redis 5X時のゴタゴタ • バンドの⽅向性の違い è MultiThreadの実装の⽅向性
6. redis v5.x後半のゴタゴタとは • CPU Coreあたりの処理能⼒が上限になりつつあった2019年 • クロックはあまり上がらず、Core数が増える時代 • Intel より AMD がマルチ・ダイでマルチコアの効率化 • その時のredisの⽅向性 • redis clusterでshardして、処理インスタンスあたりのCore割当を分散 する • è shardするover headも⼤きい • KeyDBを考えた⼈たち • è そんなことより、単⼀インスタンスあたりの性能をマルチスレッド 化で ⾼めて、shardなんて複雑化しないでover head減らそう
7. ⽅向性の違い è fork : KeyDB 5.x Faster : 5倍 早いだとぉぉ (当時) Oct. 2019 : Redis v5.0.9⽐較
10. 今のKeyDB and Redis • Redis 6.2.x (latest) • 結局はmultithread I/O を受け⼊れる • default 1 thread • CONF: io-threads {INT} • CPU Core数 ‒ 1 と⼿動設定 • KeyDB 6.0.16 (latest) : 設定細かい • 標準thread対応 • default 1 thread • CONF: server-threads {INT} ## 2とかにすると良い CONF: server-thread-affinity true ## なるべくCPUpinする(defautl)
11. benchmark取るときには、設 定もチューニング必要 ゆっくり考えてね
12. で、結局どうしたのか : KeyDB node C node B node A keydb keydb keydb py py mongod arbiter mongod primary mongod secondary • KeyDB multi-master è 普通に使えますね • Pythonからは、localhostでアクセス • KVSとしてはデータローカリティ • haproxyはtcp socketでprimary判定check haproxy haproxy haproxy haproxy haproxy 192.168.1.5 192.168.1.6 192.168.1.7
13. たまには良いけど、アプリ ケーションサービスのメッ シュを⼿動で組むとか今どき じゃないね 皆さんは、dockerなり、kubernetesとか使いましょう haproxyいれて、⼿動でメッシュしても、きっとどこか抜けている!!
14. KeyDB multi-master (example • /etc/keydb/keydb.conf 変更点 (node A : 192.168.1.5) replica-read-only no ## yes を noに変更 cluster-node-timeout 5000 ## peerが切れたら諦めろ multi-master yes active-replica yes replicaof 192.168.1.6 6379 ## node B peer replicaof 192.168.1.7 6379 ## node C peer • node B, node Cはpeer nodeのIPを書き換えておく
15. KeyDB multi master start • あとは起動 • # systemctl enable keydb • # systemctl start keydb
16. status • # systemctl status keydb • • keydb.service - Advanced key-value store • Loaded: loaded (/usr/lib/systemd/system/keydb.service; enabled; vendor preset: disabled) • Drop-In: /etc/systemd/system/keydb.service.d • └─limit.conf • Active: active (running) since ⼟ 2021-04-17 00:27:21 UTC; 6s ago • Docs: https://docs.keydb.dev, • man:keydb-server(1) • Process: 11922 ExecStart=/usr/bin/keydb-server /etc/keydb/keydb.conf (code=exited, status=0/SUCCESS) • Main PID: 11927 (keydb-server) • CGroup: /system.slice/keydb.service • └─11927 /usr/bin/keydb-server 0.0.0.0:16379 • 4⽉ 17 00:27:21 iso-man11012.g1.tyo1.v4.internal-gmo systemd[1]: Starting Advanced key-value store... • 4⽉ 17 00:27:21 iso-man11012.g1.tyo1.v4.internal-gmo systemd[1]: PID file /var/run/keydb/keydb-server.pid not readable (yet?) after start. • 4⽉ 17 00:27:21 iso-man11012.g1.tyo1.v4.internal-gmo systemd[1]: Started Advanced key-value store.
17. KeyDB 失敗談 • KeyDBでclusterで⾏こうとしたけど、失敗 • keydb-cli --cluster create \ 192.168.1.5:6379 \ 192.168.1.6:6379 \ 192.168.1.7:6379 --cluster-replicas 1 • replica 1だと、6 node(or instance)必要
18. node A write / read node A # keydb-cli -p 16379 Message of the day: Join the KeyDB community! https://community.keydb.dev/ 127.0.0.1:6379> set k2 2 OK 127.0.0.1:6379> get k2 "2" 127.0.0.1:6379> exit
19. node B read node B check # keydb-cli -h 192.168.1.6 -p 6379 Message of the day: Join the KeyDB community! https://community.keydb.dev/ 192.168.1.6 :6379> get k2 "2" 192.168.1.6 :6379> exit
20. node C read node C check # keydb-cli -h 192.168.1.7 -p 6379 Message of the day: Join the KeyDB community! https://community.keydb.dev/ 192.168.1.7 :6379> get k2 "2" 192.168.1.7 :6379> exit
21. KeyDB普通に使えるね by multi-master Operationはredisと同じ、 Configは違いもあるけど、楽な点も多い
22. benchmarkについては、 今回の⽤途では頑張る必要なし • まとめ • 冗⻑でローカリティアクセスのredisをKeyDB multi-masterでできた • cluster構成は3 nodeで失敗 (replica設定 1) è 6 node必要みたい • KeyDBかんたん、悪くないかも • reidis : BSD-3 or commercial license available • KeyDB : BSD-3 (community version and Enterprise version) • nodeごとに⼀回削除して、作り直してもすぐに復帰してた • コンテナの運⽤性も良さそうだ