Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Redisのメモリ溢れと戦った話 / tech-meetup2_akechi
Search
Recruit
PRO
January 21, 2022
Technology
1
1.4k
Redisのメモリ溢れと戦った話 / tech-meetup2_akechi
2022/01/20_RECRUIT TECH MEETUP #2での、明智の講演資料になります
Recruit
PRO
January 21, 2022
Tweet
Share
More Decks by Recruit
See All by Recruit
毎晩の 負荷試験自動実行による効果
recruitengineers
PRO
5
43
Transformerを用いたアイテム間の 相互影響を考慮したレコメンドリスト生成
recruitengineers
PRO
0
35
Javaで作る RAGを活用した Q&Aアプリケーション
recruitengineers
PRO
1
160
問題解決に役立つ数理工学
recruitengineers
PRO
13
2.8k
Curiosity & Persistence
recruitengineers
PRO
2
200
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
430
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
200
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
370
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
380
Other Decks in Technology
See All in Technology
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
130
ポストコロナ時代の SaaS におけるコスト削減の意義
izzii
1
260
20250707-AI活用の個人差を埋めるチームづくり
shnjtk
6
4.1k
マルチプロダクト環境におけるSREの役割 / SRE NEXT 2025 lunch session
sugamasao
1
390
VS CodeとGitHub Copilotで爆速開発!アップデートの波に乗るおさらい会 / Rapid Development with VS Code and GitHub Copilot: Catch the Latest Wave
yamachu
2
340
ClaudeCodeにキレない技術
gtnao
0
560
アクセスピークを制するオートスケール再設計: 障害を乗り越えKEDAで実現したリソース管理の最適化
myamashii
1
330
モニタリング統一への道のり - 分散モニタリングツール統合のためのオブザーバビリティプロジェクト
niftycorp
PRO
1
360
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
55
22k
ビジネス職が分析も担う事業部制組織でのデータ活用の仕組みづくり / Enabling Data Analytics in Business-Led Divisional Organizations
zaimy
1
310
How to Quickly Call American Airlines®️ U.S. Customer Care : Full Guide
flyaahelpguide
0
240
TableauLangchainとは何か?
cielo1985
1
150
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
138
34k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
The World Runs on Bad Software
bkeepers
PRO
69
11k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
Site-Speed That Sticks
csswizardry
10
700
Transcript
Redisのメモリ溢れと戦った話 明智 那央
自己紹介:明智那央(あけちなお) 略歴 2015年新卒入社 2015年〜2017年:社内向け基盤の開発を担当 2017年〜2019年:『ホットペッパービューティー』の開発を担当 2019年〜2019年:『ホットペッパーグルメ』の開発を担当 202019年12月〜:SREチームリーダーに任用
本日お話したいこと Redisのメモリ溢れに対応する中で得たもの • Redisに関するナレッジ • リソース枯渇時の対応心得
アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.
OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
ホットペッパーグルメのシステム構成 ORACLE Elasticsearch カスタマー クライアント DBはカスタマーとクライアント向けプ ロダクトで共用している
セッション管理にRedisを導入 Redis導入の目的 • アクセス断を伴わないリリース方式への変更 ◦ stickysessionのため、Tomcat再起動時にセッションが破棄 されていた • DBの負荷軽減 ◦
負荷が高いセッションの処理をDBから切り離し
RAFTEL LB Redisのシステム構成 Application VIP(write/read) healthchecker healthchecker healthchecker sentinel sentinel
sentinel Master Slave Slave replication healthcheck healthcheckで確認 ・Redis自体の生存 ・RedisがMasterであること ・stopfileがないこと load balance
アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.
OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
Redisがメモリ上限を使い切る 導入後24日でメモリ上限に到達し、キーの削除処理が走り出した 影響:セッションが有効期限前に破棄される可能性がある メモリ上限:16GB ★導入日
対応:Redisのメモリ上限を引き上げ • 引き上げるメモリのサイジング ◦ 24日で16GBに到達したので、1日で0.67GB増えている ◦ 0.67(GB/日) * 30(日) *
1.3(安全率) = 27GB • スペックがメモリ32GBだったので、同期に必要なメモリを確保するためにメ モリ64GBのサーバにスケールアップ
Slaveに同期されない スケールアップ中にF/Oが発生し、その後Slaveに同期されなくなった 原因:同期に必要なメモリを確保できなかった healthchecker healthchecker healthchecker sentinel sentinel sentinel Master
Slave Slave replication replication
Slaveへの同期の仕組み healthchecker healthchecker healthchecker sentinel sentinel sentinel Master Slave Slave
replication ①Masterノードでダンプファイ ルを出力する (バックグラウンド実行) ②出力したダンプファイルを Slaveノードに転送する ③Slaveノードでダンプファイル をメモリにロードする
Slaveに同期されなかった理由 healthchecker healthchecker healthchecker sentinel sentinel sentinel Master Slave Slave
replication ①Masterノードでダンプファイ ルを出力する (バックグラウンド実行) ②出力したダンプファイルを Slaveノードに転送する ③Slaveノードでダンプファイル をメモリにロードする cannot allocate memory
対応:swap領域の拡張 • swapをオンラインで拡張し、同期に必要なメモリを確保する • 拡張の流れ 1. swap割り当て用のディスクを確保する(ddコマンド) 2. 確保したディスクをswapファイルに変換する(mkswapコマンド) 3.
swapファイルを有効化する(swaponコマンド)
swap領域を拡張してスケールアップ再実施 swap領域を拡張することでSlaveに同期できるようになり、スケールアップ作 業は問題なく完了(使用量の増加によりメモリ上限を 33GBに引き上げ) healthchecker healthchecker healthchecker sentinel sentinel sentinel
Master Slave Slave replication replication
アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.
OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
Redisがメモリ上限を使い切る(再) 再びメモリ上限に到達し、キーの削除処理が走り出した 影響:セッションが有効期限前に破棄される可能性がある メモリ上限:33GB ★スケールアップ日
“ Note that maxmemory should be set calculating the overhead
that Redis has, other than data, and the fragmentation overhead. So if you think you have 10GB of free memory, set it to 8 or 9.” —Redisの公式ドキュメント https://redis.io/topics/admin ➡OSのfree memoryの8~9割に 設定すべきと解釈
対応:Redisのメモリ上限を引き上げ(再) • 引き上げるメモリのサイジング ◦ Redisが確保しているメモリは33GB ◦ OSのfree memoryは17GB ◦ free
memory(33+17) * 0.9 = 45GB • Slaveへの同期にはRedisと同じメモリ量が必要になるため、 swap領域も拡張
Redisのメモリ上限を引き上げ メモリ上限の引き上げ作業は問題なく完了 healthchecker healthchecker healthchecker sentinel sentinel sentinel Master Slave
Slave replication replication
再びメモリ上限に到達し、キーの削除処理が走り出した 影響:セッションが有効期限前に破棄される可能性がある Redisがメモリ上限を使い切る(再) メモリ上限:45GB
アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.
OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
Redisに格納しているデータ セッション名 有効期間 用途 memory 短期 予約遷移でのデータ引き回し token 短期 セキュリティ関連対策のトークン
permanentdb 長期 オートログイン判定 info 長期 有効期間を制御するためのメタ情報
Redisに格納されているデータの分析 • どこに手を打つべきなのかを明確にするために、各セッションの メモリ使用量を把握する必要がある • 分析方法 ◦ redis-rdb-toolsを使って、ダンプファイルからメモリ使用量を 算出する
redis-rdb-tools • Redisのダンプファイルを解析するためのPythonツール • 主な機能 ◦ メモリレポートを生成する←今回はこれ目的で使用 ◦ ダンプファイルをJSONに変換する ◦
標準diffツールを使ってダンプファイルを比較する
Redisに格納されているデータの分析結果 • infoはキーの登録数・データ量がともに最も多く占めている • Redisのメモリ使用量とダンプデータのサイズが大きく乖離している セッション名 有効 期間 登録数 データ量
件数 割合(%) サイズ(GB) 割合(%) memory 短期 58883 0.08 0.11 0.60 token 短期 5082154 6.22 3.41 18.77 permanentdb 長期 966779 1.18 0.79 4.34 info 長期 75551260 92.52 13.86 76.28 合計 81659079 100 18.17 100 有効期限切れのキーが 削除されていない?
Redisの有効期限切れキーの削除アルゴリズム • passive wayとactive wayの2つの方法で有効期限切れキーの 削除を行う • active way:1秒間に10回下記の処理を実行する 1.
有効期限が設定されているキーを20個サンプリングする 2. サプリングしたキーの中で有効期限切れキーを削除する 3. 有効期限切れキーが25%(5個)より多ければステップ1に戻る →有効期限切れキーの割合は25%以下になるはず
有効期限切れキーが多い理由(仮説) • 有効期限の長いinfoキーがほとんどの割合を占めているので、 有効期限の短いmemoryやtokenがサンプリングされる確率が 低く、結果として有効期限は切れているが削除されていない • 有効期限の異なるキーが混在していることが問題
削除アルゴリズムをソースコードでも確認 わかったこと • RedisのDB毎に削除アル ゴリズムが実行される
対応:RedisのDBを分離 キーの有効期間に応じてRedisのDBを分離することで、有効期限切れキーの 削除を促進する memory token permanentdb info permanentdb info memory
token 分離
permanentdbとinfoの有効期限が切れ始めるあたりからデータが 平準化されるが、55GB(最大75GB)程度必要になる Redis DB分離の効果見立て(分離前) セッション名 有効期間 1分あたりの発行数 memory 短期 850
token 短期 1765 permanentdb 長期 22 info 長期 2637
infoが増加し終わったあたりからデータが平準化され、38GB程度必要になる Redis DB分離の効果見立て(分離後) セッション名 有効期間 1分あたりの発行数 memory 短期 850 token
短期 1765 permanentdb 長期 22 info 長期 2637
アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.
OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
ホストのメモリ使用率が95%に到達した ホストのメモリ使用率が警告域に 95%
対応:Redisのメモリ上限を引き下げ • メモリ上限を45GBから40GBに引き下げることで、Redisが 使用するメモリ量を削減する • セッションが有効期限前に破棄される可能性があるが、今も 起きていることなのでOSメモリ枯渇の解消を優先
F/Oが発生しSlaveに同期されない メモリ上限引き下げ時にF/Oが発生し、Slaveに同期されなくなった 原因:同期に必要なメモリを確保できなかった healthchecker healthchecker healthchecker sentinel sentinel sentinel Master
Slave Slave replication replication
対応:swap領域の拡張(再) • swapをオンラインで拡張し、同期に必要なメモリを確保する • 拡張の流れ 1. swap割り当て用のディスクを確保する(ddコマンド) 2. 確保したディスクをswapファイルに変換する(mkswapコマンド) 3.
swapファイルを有効化する(swaponコマンド)
swap拡張してもSlaveに同期されない swap領域を拡張しても、Slaveに同期されなくなった 原因:同期に必要なメモリを確保できなかった healthchecker healthchecker healthchecker sentinel sentinel sentinel Master
Slave Slave replication replication
対応:有効期限切れキーを削除 • 有効期限切れキーを削除することで、Redisが使用するメモリ量を 削減する ◦ scanコマンドを使ったpassive wayで削除する • コンテプラン 1.
overcommit_memoryを有効化する a. Redisの推奨設定だが、OOM Killerによるプロセス強制削除の リスクがある 2. セッションデータを全て破棄する a. 最悪の場合に備えて事業調整
有効期限切れキーを削除してSlave復旧 有効期限切れキーの削除とovercommit_memoryを有効化することで Slaveへの同期されるようになった healthchecker healthchecker healthchecker sentinel sentinel sentinel Master
Slave Slave replication replication
アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.
OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
Redis DB分離の実施 • 実装としてはdiconファイルの変更のみ • テストで分離後も問題ないことを確認して、リリースへ
Redisに登録されているキーの数が大幅に増えているので、想定通り有効期限 切れキーの削除は行われているが、その分新しいキーが登録されている Redis DB分離の効果 DB分離実施日 ★ DB分離後に二千万件程度増加している
アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.
OSメモリの枯渇 6. 恒久対応の実施(不十分) 7. 突然のF/O 8. 恒久対応の実施
F/Oが発生しSlaveに同期されない(再) F/Oが発生し、Slaveに同期されなくなった 原因:同期に必要なメモリを確保できなかった healthchecker healthchecker healthchecker sentinel sentinel sentinel Master
Slave Slave replication replication
対応:overcommit_memoryを有効化(再) • overcommit_memoryを有効化して、同期に必要なメモリを 確保できるようにする
Slaveに同期されない overcommit_memoryを有効化しても、Slaveに同期されない 原因:ダンプファイルを出力するプロセスがOOM Killerに殺される healthchecker healthchecker healthchecker sentinel sentinel sentinel
Master Slave Slave replication replication
対応:Redisプロセスの再起動 • Redisのプロセスを再起動することにより、Redisが使用する メモリ量を削減する • 作業手順 1. sentinelのMasterがダウンしたと判断する時間を伸ばす(F/O防止) 2. 有効期限切れキーを削除する(使用メモリ量を事前に削減)
3. フォアグラウンドでダンプファイルを出力する 4. Redisのプロセスを再起動する 5. 手順1の切り戻し
Redisプロセスを再起動してSlave復旧 Redisのプロセスを再起動することでSlaveへの同期されるようになった healthchecker healthchecker healthchecker sentinel sentinel sentinel Master Slave
Slave replication replication
アジェンダ 1. Redisの導入 2. メモリ溢れの発生 3. メモリ溢れの再発 4. 恒久対応の検討 5.
OSメモリの枯渇 6. 恒久対応の実施(失敗) 7. 突然のF/O 8. 恒久対応の実施
有効期限切れキーを日次削除 • 有効期限切れキーを日次で削除することで、Redisが使用するメモリ量を 削減する • 削除対象 1. Redis上有効期限が切れているもの a. scanコマンドで削除可能
2. infoに紐づくキーがないもの a. infoに紐づいていない場合は、delコマンドで削除可能
有効期限切れキー削除時の注意点 • 使っているRedisがシングルスレッドでしか使えないため、 有効期限切れキーの削除を一気に行うとオンラインの処理に 影響を与えてしまう恐れがある • オンライン処理に影響を与えないように、本番相当の負荷をかけてRedis のレイテンシが悪化しないかを事前に確認する
有効期限切れキー削除ジョブを装着後は、Redisのメモリ使用量が10GB以下 に抑えることができた 恒久対応の効果
まとめ • 『ホットペッパーグルメ』で発生したRedisのメモリ溢れに対応した内容を共 有しました a. Redisに関するナレッジ ▪ 有効期限切れキーの削除アルゴリズム b. リソース枯渇時の対応心得
▪ 二次障害を発生させない事前準備 ▪ ソースコードレベルでの挙動把握