大量データをRedisに入れる際の 容量問題にどう対処したか

Transcript

1. 大量データをRedisに入れる際の 容量問題にどう対処したか
2. どういうことを話すか？ • 背景 • Redisの容量問題にどう対処したか • Redisクラスターを使う注意点 • AWS Elasticacheの設定をどうするか • パフォーマンスチューニング
3. 背景 DPAフィードデータを入れる際に、 Redisの容量問題に遭遇した
4. DPAとは？ ECサイトなどの閲覧履歴元に広告を配信する仕組み
5. DPAフィードデータとは？ DPAフィードデータ Redis 閲覧履歴 配信システム zero
6. どうやってDPAフィードデータを入れている？ ... ... ... RDS Elasticache 在庫あり 在庫なし 全部 保存 削除 保存 前日 今日 差分 差分 1. 差分の作成 2. 差分の取り込み
7. どんな問題が発生していた？ cache.r6g.12xlarge Elasticache（Redis） 3億件 90% cache.r6g.16xlarge Elasticache（Redis） 3億件 最大 yahooなど
8. どう対応したか？
9. どんな解決策があった？ Re Re Re Re Re Re Re Re Re プロキシ ノードの対応関係を 定期的にロード Redisクラスター Proxy
10. なぜRedisクラスターへ移行することにしたの？ コスト面、運用面でのコストが 最も低いため
11. AWSで使うには？ Elasticache（Redis）で クラスターモードを有効にする
12. どういう設定にする？ シャード数をどうするか？ • 制限に気をつける ◦ 上限は、90 例: レプリカ2、プライマリ1構成であれば30ノード。 ◦ redis5.0.3以上の場合、500まで緩和可能 ノードタイプ をどうするか？ • クラスターの各ノードタイプ は全て同じ コスト面から少しずつ増やしたいなら小さいものを選ぶ。
13. RedisとRedisクラスターの違いとは？ • マルチ操作がスロット単位でしか行えない • リダイレクトが発生する • ライブラリがサポートしていない可能性
14. どんな対応をしたの？ Re Redis Redisクラスター Re Re Re MSET SET リダイレクト
15. 何か問題は発生した？
16. 問題1: go-redisのSETパフォーマンス 4時間で40万件ほどしかデータが入らなかった 全データ（約3億件）入れるのに4ヶ月ほどかかりそう。。 40万件 4時間後 Redisクラスター Redisクラスター
17. 問題1: go-redisのSETパフォーマンス 参考: https://blog.yuuk.io/entry/2020/goredis-performance-degradation 【原因】 古いgo-redisでRedis6にPipelineを使うと パースエラーのせいでCOMMANDコマンドの結果を キャッシュできない。 【対応】 go-redisのバージョンをv8以上にした。
18. 問題1: go-redisのSETパフォーマンス 100倍高速になった これでも既存MGETの10倍遅い。 全データ入れるのに9日ほどかかる。。
19. 問題1: go-redisのSETパフォーマンス シェルスクリプトで実行すると 高速化する話を聞き、書き直した
20. 問題1: go-redisのSETパフォーマンス ... 各直列の10000 コマンド SET SET SET ... 1000件同時実行 Redis クラスター
21. 問題2: 圧縮したバイト配列をそのまま流せない 圧縮したバイト配列をそれぞれファイルに入れて、 次のように実行する必要があった redis-cli -x set key <compressed.txt
22. 問題2: 圧縮したバイト配列をそのまま流せない 500万レコード入れるのに、 500万ファイル作成するのは現実的ではなさそう。。
23. 圧縮はせず、 JSONフィールド名の短縮を行なった 問題2: 圧縮したバイト配列をそのまま流せない
24. 問題3: 260万件ほど書き込むとそれ以降進まなくなった Redis クラスター ... 大量のTIME_WAIT サーバー TIME_WAITコネクションが溜まりポートが枯渇してしまった
25. 問題3: 260万件ほど書き込むとそれ以降進まなくなった TIME_WAITコネクションを再利用できるよう カーネルパラメータ を変更した net.ipv4.tcp_tw_reuse = 1 参考: https://blog.spacemarket.com/code/aws-batch-%E3%81%A7%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB-%E3%83%91 %E3%83%A9%E3%83%A1%E3%83%BC%E3%82%BF-%E3%83%81%E3%83%A5%E3%83%BC%E3%83%8B%E3%83%B3%E3 %82%B0/
26. 問題3: 260万件ほど書き込むとそれ以降進まなくなった 1000万件入れるのにかかる時間が、 60分 -> 5分と12倍高速になった ※ redisのコマンド実行部分だけでの比較
27. 問題4: 1コマンドごとの結果をファイルに書き出していたら遅い 【対応】 コマンドを実行する大元のスクリプトの実行結果を ファイルに書き出してエラーチェックするようにした 【結果】 1000万件処理する場合、 バッチの実行時間が43分 -> 39分になった。
28. 問題5: 値をダブルクオートしていると遅い 【対応】 値を囲むのを、 ダブルクオートからシングルクオートに変更した。 【結果】 1000万件処理する場合、 バッチの実行時間が39分 -> 17分と半分以下になった。
29. 問題6: Operation timed outが発生する 【対応】 Redisコマンドの同時実行数を1000 -> 500に変更。 【結果】 Operation timed outは発生しなくなった。 時々発生する。
30. 問題7: jedisのGETパフォーマンス 【200件取得のパフォーマンス比較】 既存のMGET: 　　　　　　 5.157 ms RedisクラスターのGET: 　 24.835 ms 5倍ほど遅い。。
31. 問題7: jedisのGETパフォーマンス Re Re Re GET リダイレクト Re Re Re MGET jedis lettuce
32. 問題7: jedisのGETパフォーマンス 【200件取得のパフォーマンス比較】 既存のMGET: 　　　　　　 5.157 ms RedisクラスターのGET（lettuce）: 　 5.386 ms RedisクラスターのGET（jedis）: 　 24.835 ms 既存とほぼ同じくらいになった jedisと比較して5倍高速に。
33. 結果 【バッチの実行時間】 1000万件入れるのに30分 ただし、キャッシュへの挿入のみ