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
10
2.6k
Curiosity & Persistence
recruitengineers
PRO
2
150
結果的にこうなった。から見える メカニズムのようなもの。
recruitengineers
PRO
1
340
成長実感と伸び悩みからふりかえる キャリアグラフ
recruitengineers
PRO
1
130
リクルートの オンプレ環境の未来を語る
recruitengineers
PRO
3
170
LLMのプロダクト装着と独自モデル開発
recruitengineers
PRO
1
220
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 ビジネス編
recruitengineers
PRO
2
130
新規検索基盤でマッチング精度向上に挑む! ~『ホットペッパーグルメ』の開発事例 技術編
recruitengineers
PRO
0
140
大規模プロダクトにおける フロントエンドモダナイズの取り組み紹介
recruitengineers
PRO
5
120
Other Decks in Technology
See All in Technology
日経電子版 for Android の技術的課題と取り組み(令和最新版)/android-20250423
nikkei_engineer_recruiting
1
600
AI 코딩 에이전트 더 똑똑하게 쓰기
nacyot
0
440
Cross Data Platforms Meetup LT 20250422
tarotaro0129
1
880
Web Intelligence and Visual Media Analytics
weblyzard
PRO
1
5.9k
OpenLane-V2ベンチマークと代表的な手法
kzykmyzw
0
140
企業が押さえるべきMCPの未来
takaakikakei
0
240
Новые мапы в Go. Вова Марунин, Clatch, МТС
lamodatech
0
1.1k
SnowflakeとDatabricks両方でRAGを構築してみた
kameitomohiro
1
550
グループ ポリシー再確認 (2)
murachiakira
0
200
品質文化を支える小さいクロスファンクショナルなチーム / Cross-functional teams fostering quality culture
toma_sm
0
170
Compose におけるパスワード自動入力とパスワード保存
tonionagauzzi
0
170
コスト最適重視でAurora PostgreSQLのログ分析基盤を作ってみた #jawsug_tokyo
non97
1
840
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
68
11k
Rebuilding a faster, lazier Slack
samanthasiow
81
9k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.2k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
19
1.2k
Raft: Consensus for Rubyists
vanstee
137
6.9k
The Cost Of JavaScript in 2023
addyosmani
49
7.8k
Music & Morning Musume
bryan
47
6.5k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.8k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
34
2.2k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.2k
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. リソース枯渇時の対応心得
▪ 二次障害を発生させない事前準備 ▪ ソースコードレベルでの挙動把握