Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Google Cloud の新サービス「Memorystore for Redis Clust...

Google Cloud の新サービス「Memorystore for Redis Cluster 」導入事例:「Memorystore for Memcached」からの移行と運用

GREE Tech Conference 2024で発表された資料です。
https://techcon.gree.jp/2024/session/TrackB-6

gree_tech

October 25, 2024
Tweet

Video

More Decks by gree_tech

Other Decks in Technology

Transcript

  1. Google Cloud の新サービス 「Memorystore for Redis Cluster 」導入事例 :「Memorystore for

    Memcached」からの 移行と運用 株式会社 WFS エンジニア 檜垣颯汰
  2. アジェンダ • プロダクトの課題:Memorystore for Memcached • Memorystore for Memcached 移行先の検討

    • Memorystore for Redis Cluster 導入試験 • Memorystore for Redis Cluster 負荷検証 • Memorystore for Redis Cluster の本番運用について • まとめ • 今後の展望 3
  3. プロダクトの前提 • Google Kubernetes Engine (GKE) + PHP + Apache

    • キャッシュサーバーとして Memorystore for Memcached を使用 • 極力全体メンテナンスを行わない運用 5
  4. 課題 1 メンテナンスで最大数時間停止する メンテナンスウィンドウは最低 3 時間必要 > ウィンドウの期間は 3〜8 時間の間でユーザーが構成できます。

    https://cloud.google.com/memorystore/docs/memcached/about-maintenance#duration-faq 実際にメンテナンスを行なった際は 3 時間を少し超えて完了した 7
  5. プロダクトの課題(再掲) キャッシュサーバーとして Memorystore for Memcached を使用 以下の問題を抱えていた • メンテナンスで最大数時間停止する •

    台数変更の運用コストが高い • フェイルオーバーできない 11 Memorystore for Memcached からの移行を検討
  6. 移行先候補 (1) Memorystore for Redis • ◦ すでにランキングなどで使用しているので移行が楽 • ×

    プライマリのスケールアウトができず、CPUが頭打ちになる懸念あり 13
  7. 導入試験結論 1. △ メンテナンスで最大数時間停止する 2. ◦ 台数変更の運用コストが高い 3. △ フェイルオーバーできない

    一部導入後でないと実際に確認できないものはありつつも、 課題の解決が望める 28
  8. Memorystore for Redis Cluster Memorystore for Memcached ロールバックの流れ 31 クライアント

    (PHPサーバー) Memorystore for Redis Cluster にアクセスしている状態
  9. DB ロールバックの流れ 32 社内管理ツール 管理ツールから使用可否を設定 canUse = false Memorystore for

    Redis Cluster Memorystore for Memcached クライアント (PHPサーバー) クライアント (PHPサーバー)
  10. DB ロールバックの流れ 33 社内管理ツール キャッシュ使用時にDBから使用可否を判断 canUse = false Memorystore for

    Redis Cluster Memorystore for Memcached クライアント (PHPサーバー) クライアント (PHPサーバー) APCu
  11. DB ロールバックの流れ 34 社内管理ツール canUse = false ならアクセスを止める canUse =

    false Memorystore for Redis Cluster Memorystore for Memcached クライアント (PHPサーバー) ❌ クライアント (PHPサーバー) APCu
  12. DB ロールバックの流れ 35 社内管理ツール 設定をデプロイし、止めたまま向き先を変える canUse = false Memorystore for

    Redis Cluster Memorystore for Memcached クライアント (PHPサーバー) ❌ クライアント (PHPサーバー) APCu
  13. DB ロールバックの流れ 36 社内管理ツール canUse = true にし、切り替え完了 canUse =

    true Memorystore for Redis Cluster Memorystore for Memcached クライアント (PHPサーバー) クライアント (PHPサーバー) APCu
  14. 負荷試験の目標 • API サーバー が 5000 RPS 以上捌けること • Memorystore

    for Redis Cluster が 50000 コマンド/s 以上捌けること • その他メトリクスに問題が生じないこと ◦ CPU 使用率 ◦ メモリ使用量 ◦ コネクション数 など • プロダクトの挙動に問題が生じないこと 39
  15. API サーバー • GKE API pod: 1000台 • Apache MaxRequestWorkers:

    25 Redis Cluster • persistent connection: true • シャード: 3台(必要あれば増台) • レプリカ: シャードごとに 1台 その他負荷試験の設定 42 クライアント (PHPサーバー) プライマリ  レプリカ
  16. persistent connection 永続的接続 PHPの worker プロセスが終了するまでコネクションを継続する persistent connection = false

    だと 毎回 PHP と Redis Cluster でコネクションを貼るため、I/O 帯域を圧迫しや すい 43
  17. PHP API サーバー(Pod) コネクションのイメージ 44 Apache worker Apache worker Apache

    worker PHP API サーバー(Pod) … … プライマリ/レプリカ
  18. 負荷試験の目標(再掲) • API Server が 5000 RPS 以上捌けること • Memorystore

    for Redis Cluster が 50000 コマンド/s 以上捌けること • その他メトリクスに問題が生じないこと ◦ CPU 使用率 ◦ メモリ使用量 ◦ コネクション数 • プロダクトの挙動に問題が生じないこと 56
  19. 負荷試験の目標(再掲) • ◦ API Server が 5000 RPS 以上捌けること •

    ◦ Memorystore for Redis Cluster が 50000 コマンド/s 以上捌けること • △ その他メトリクスに問題が生じないこと ◦ ◦ CPU 使用率 ◦ ◦ メモリ使用量 ◦ △ コネクション数 • ◦ プロダクトの挙動に問題が生じないこと 57
  20. コネクションのイメージ(再掲) コネクション数 🟰 Pod 台数 ✖ Pod 1台あたりのworker数 でおおよそ見積もることができる 60

    PHP API サーバー(Pod) Apache worker Apache worker Apache worker PHP API サーバー(Pod) … … プライマリ/レプリカ
  21. コネクション数の問題:対策案 1 HPAのCPU utilization target を上げる 具体例:4000 RPS, podあたりworker数が 25

    の場合 63 CPU target Pod 1台のRPS Pod 台数 コネクション数 before 25 % 5 800 20000 after 50 % 10 400 10000
  22. コネクション数の問題:対策案 3 Pod 1台あたりの Apache Worker 数を減らす コネクション数 = Pod

    台数 × Pod 1台あたりの worker 数 Pod 1台あたりの worker 数を減らせば良い 66
  23. コネクション数の問題:対策案(再掲) • HPA の CPU utilization target を上げる • persistent

    connection をやめる • Pod 1台あたりの Apache Worker 数を減らす 67
  24. コネクション数の問題:対策案(再掲) • △ HPA の CPU utilization target を上げる •

    △ persistent connection をやめる • ◦ Pod 1台あたりの Apache Worker 数を減らす 68
  25. コネクション数の問題:対策案(再掲) • △ HPA の CPU utilization target を上げる •

    △ persistent connection をやめる • ◦ Pod 1台あたりの Apache Worker 数を減らす 69 ここに朗報が 飛び込む
  26. MaxClients の上限解放 2024年 4月 Max Clients(コネクションの最大値) 10000 → 最大 64000

    まで引き上げられた 負荷試験では 30000 コネクション で目標値に到達していたため、十分と判断した 70 https://cloud.google.com/memorystore/docs/cluster/quotas
  27. 負荷試験の目標(再掲) • ◦ API Server が 5000 RPS 以上捌けること •

    ◦ その他メトリクスに問題が生じないこと ◦ ◦ CPU 使用率 ◦ ◦ メモリ使用量 ◦ ◦ コネクション数 • ◦ プロダクトの挙動に問題が生じないこと 71
  28. 負荷試験の目標(再掲) • ◦ API Server が 5000 RPS 以上捌けること •

    ◦ その他メトリクスに問題が生じないこと ◦ ◦ CPU 使用率 ◦ ◦ メモリ使用量 ◦ ◦ コネクション数 • ◦ プロダクトの挙動に問題が生じないこと 72 負荷試験の目標を 達成できた!
  29. メモリ使用量の増加への対処 キャッシュデータ保存時に圧縮処理を入れる 1KB 以上のキャッシュアイテムを gzencode で圧縮 81 if (len($setValue) >

    $this->config->threshold()) { $setValue = $this->gzencode($setValue, $level); } $result = $this->redisCluster->set($key, $setValue, $expiration);
  30. 今後の展望: 長期的展望 Valkey の動向を注視 Redis の fork 先である Valkey の

    マネージドサービス Memorystore for Valkey が 2024 年 8 月末 プレビューでリリースされた Redis/Redis Cluster はライセンスなどの懸念があるため、Valkey の動向も注 視していく https://redis.io/blog/redis-adopts-dual-source-available-licensing/ 88
  31. 89