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
   

   View Slide

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
   

   View Slide

3. 暖かくなってきました。
   皆様
   お出かけしたいですね
   ……
   そんな中、とある仕事
   でのweb APIをpython
   で作る案件で
   

   View Slide

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 じゃない
   

   View Slide

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の実装の⽅向性
   

   View Slide

6. redis v5.x後半のゴタゴタとは
   • CPU Coreあたりの処理能⼒が上限になりつつあった2019年
   • クロックはあまり上がらず、Core数が増える時代
   • Intel より AMD がマルチ・ダイでマルチコアの効率化
   • その時のredisの⽅向性
   • redis clusterでshardして、処理インスタンスあたりのCore割当を分散
   する
   • è shardするover headも⼤きい
   • KeyDBを考えた⼈たち
   • è そんなことより、単⼀インスタンスあたりの性能をマルチスレッド
   化で
   ⾼めて、shardなんて複雑化しないでover head減らそう
   

   View Slide

7. ⽅向性の違い è fork : KeyDB
   5.x Faster : 5倍
   早いだとぉぉ
   (当時)
   Oct. 2019 :
   Redis v5.0.9⽐較
   

   View Slide

8. View Slide

9. View Slide

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)
    

    View Slide

11. benchmark取るときには、設
    定もチューニング必要
    ゆっくり考えてね
    

    View Slide

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
    

    View Slide

13. たまには良いけど、アプリ
    ケーションサービスのメッ
    シュを⼿動で組むとか今どき
    じゃないね
    皆さんは、dockerなり、kubernetesとか使いましょう
    haproxyいれて、⼿動でメッシュしても、きっとどこか抜けている!!
    

    View Slide

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を書き換えておく
    

    View Slide

15. KeyDB multi master start
    • あとは起動
    • # systemctl enable keydb
    • # systemctl start keydb
    

    View Slide

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.
    

    View Slide

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)必要
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

21. KeyDB普通に使えるね
    by multi-master
    Operationはredisと同じ、
    Configは違いもあるけど、楽な点も多い
    

    View Slide

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ごとに⼀回削除して、作り直してもすぐに復帰してた
    • コンテナの運⽤性も良さそうだ
    

    View Slide