ElastiCacheを利用する上でキャッシュをどのように有効に使うべきか

2. Amazon ElastiCache • Managed in-memory service • Memcached or Redis • Cluster of nodes • Read replicas • Monitoring + alerts

3. ELB Web/App External APIs Modern Web / Mobile App

4. ELB Web/App Modern Web / Mobile App ブラウザキャッシュデータストア及びAPIレスポンス、Appでの処理結果のキャッシュストレージエンジンのキャッシュ及びクエリキャッシュ NginxなどWebサーバでの Webリクエストへのレスポンスキャッシュ

5. それぞれの代表的なキャッシュデータ • ブラウザキャッシュ • Webサーバレスポンス（HTML、js、CSS、画像などの静的ファイル）のキャッシュ • Webサーバキャッシュ • アプリケーションからのレスポンスデータ • SSLセッション • 静的ファイルデータ • キャッシュストレージ • データストアやAPIの結果 • それらを処理した結果 • セッションデータ • データストアキャッシュ • ストレージエンジンが処理で利用するキャッシュ • クエリの結果

6. それぞれの代表的なキャッシュパターン • それぞれキャッシュする内容は違うが目的は高速なレスポンスを実現する事と負荷を軽減させる • キャッシュ出来る内容は要件によって異なる。即時反映させなければいけない物はブラウザ〜Webサーバまでの場所でキャッシュは難しい • 大人数が共通して利用出来るjs、CSS、画像ファイルはCloud Frontを利用した方が良い • キャッシュはあくまでもキャッシュなので、キャッシュが参照出来なくなっても実際のデータは必ず改めて参照出来るようにする事

7. 今回触れるのは ELB App External APIs データストア及びAPIレスポンス、Appでの処理結果のキャッシュ

8. ElastiCacheでキャッシュする目的 • データストアからの結果をキャッシュする事でデータストアへのアクセスを減らす • 外部APIの結果をキャッシュする事で外部APIへのアクセスを減らす • これらのデータを用いて計算した結果をキャッシュする事で同じ処理を減らす • アプリケーション内部でこれらのキャッシュを保持する機構を分離する • アプリケーション単体で保持出来ない容量のキャッシュを保持する • アプリケーション単体のダウンに影響されないようにする • アプリケーションが生成したキャッシュをアプリケーションクラスタ全体で利用可能にする

9. Memcached vs Redis: Cage Match • Multithreaded • No persistence • Flat string cache • Low maintenance • Easy to scale horizontally • Single-threaded • Persistence • Advanced data types - http://redis.io/topics/data-types • Atomic operations • Pub/sub messaging • Read replicas / failover

10. Caching Strategies and Tactics

11. Setting up caching The questions • キャッシュ可能なのか？ • どのくらいのキャッシュ空間が必要か？ • キャッシュ障害が起きた場合の影響範囲は？ • キャッシュ戦略を成功させる為に何が必要か？

12. Data set properties キャッシュ可能なデータの特性 • 読み取り専用でべき等な物 • 繰り返しアクセスされ、生存期間が長いものすぐに変更されてしまうものはキャッシュに向かない。許容出来る範囲で多少古い物や一貫性の無いデータを返しても良い物がキャッシュに向いている

13. Data Properties: item sizes 大きな塊としてキャッシュすべきか、細かく分けた方が良いのか • 例として10個のデータを元にするHTMLデータ自体をキャッシュすると仮定する • この時最終的なデータを１つの塊としてキャッシュするとヒットする時は１回のリクエストで良いが、少しでも変更があれば毎回updateをする必要が出る。 • また、他のHTMLと共通化出来るもの（フッター情報など）をそれぞれ重複してキャッシュする事になる • 個別に分けると可能な限り無駄は減るがキャッシュストレージへのアクセスは増加する。 • これはどちらの負荷がよりコントロールしやすいかで最終的に判断、調整する必要がある。

14. The Thundering Herd キャッシュミスはデータストアへのアクセススパイクを引き起こす。 • 重要な事は計画と分析一般的な原因と緩和策 • コールドキャッシュ– キャッシュに階層型キャッシュの仕組みを取り入れる、キャッシュウォーミングのシーケンスを導入します。 • 同じタイミングでのTTL切れ– ランダムジッタをTTLに設定します。 • Undersized cache – ヒットレート、データセットの解析 • アクセスパターンの変更– 分析, 計画, テスト • より高いヒットレートへの対応 – 冗長性 , スケーリングの向上

15. Data Properties: related items アプリケーションは全く同じデータか、もしくはいくつかのデータを１つのグループとしてキャッシュストレージにアクセスします。この時TTLを全ての項目で同じ値か、特定の間隔の倍数に設定すると最悪の場合、全て同一のタイミングでキャッシュミスが発生する可能性があります。これを避ける為にTTLをセットする場合はランダムな値で調整する事でTTL切れによるキャッシュミスを平滑化します。

16. Data liveness どのようにキャッシュアイテムのTTLを最小限に抑えるか • 生存期間は短ければ短いほどネガティブキャッシュにヒットする可能性やパージする処理を記述するコストが減るどのようにキャッシュアイテムのTTLを伸ばすか。 • 生存期間が長いほどキャッシュヒットする事によるデータストアへのアクセスなどは減少出来る

17. Data Consistency ノードの追加などによるクラスタリサイズを実施するとコンシステントハッシングの再計算が行われ、各ノードで持っているキャッシュ情報へのアクセスパターンが変更される。緩和策: • TTLの最小化：古いデータが生存する可能性を減少させる。 • 確認されたアップデート手法 • 固定されたコンシステントハッシングパターンを取る

18. App Caching Patterns

19. Web Cache with Memcached # Gemfile gem 'dalli-elasticache’ # config/environments/production.rb endpoint = “mycluster.abc123.cfg.use1.cache.amazonaws.com:11211” elasticache = Dalli::ElastiCache.new(endpoint) config.cache_store = :dalli_store, elasticache.servers, expires_in: 1.day, compress: true # if you change ElastiCache cluster nodes elasticache.refresh.client Ruby on Rails Example

20. ElastiCache twemproxy config mycache-dev: listen: 0.0.0.0:11311 hash: fnv1a_64 distribution: ketama timeout: 100 preconnect: true auto_eject_hosts: true server_retry_timeout: 2000 server_failure_limit: 3 servers: - mycache-dev.0001.use1.cache.amazonaws.com:11211:1 - mycache-dev.0002.use1.cache.amazonaws.com:11211:1 - mycache-dev.0003.use1.cache.amazonaws.com:11211:1 - mycache-dev.0004.use1.cache.amazonaws.com:11211:1

21. Be Lazy # Python def get_user(user_id): record = cache.get(user_id) if record is None: # Run a DB query record = db.query("select * from users where id = ?", user_id) cache.set(user_id, record) return record # App code user = get_user(17)

22. Write On Through # Python def save_user(user_id, values): record = db.query("update users ... where id = ?", user_id, values) cache.set(user_id, record) return record # App code user = save_user(17, {"name": "Nate Dogg"})

23. Combo Move! def save_user(user_id, values): record = db.query("update users ... where id = ?", user_id, values) cache.set(user_id, record, 300) # TTL return record def get_user(user_id): record = cache.get(user_id) if record is None: record = db.query("select * from users where id = ?", user_id) cache.set(user_id, record, 300) # TTL return record # App code save_user(17, {"name": "Nate Diddy"}) user = get_user(17)

24. Storing JSON – Memcached vs Redis # Memcached: Serialize string str_json = Encode({“name”: “Nate Wiger”, “gender”: “M”}) SET user:nateware str_json GET user:nateware json = Decode(str_json) # Redis: Use a hash! HMSET user:nateware name “Nate Wiger” gender M HGET user:nateware name >> Nate Wiger HMGET user:nateware name gender >> Nate Wiger >> M

25. ElastiCache with

26. Not if I destroy it first! It’s mine! Need uniqueness + ordering Easy with Redis Sorted Sets ZADD "leaderboard" 1201 "Gollum” ZADD "leaderboard" 963 "Sauron" ZADD "leaderboard" 1092 "Bilbo" ZADD "leaderboard" 1383 "Frodo” ZREVRANGE "leaderboard" 0 -1 1) "Frodo" 2) "Gollum" 3) "Bilbo" 4) "Sauron” ZREVRANK "leaderboard" "Sauron" (integer) 3 Real-time Leaderboard!

27. Ex: Throttling requests to an API Leverages Redis Counters ELB Externally Facing API Reference: http://redis.io/commands/INCR FUNCTION LIMIT_API_CALL(APIaccesskey) limit = HGET(APIaccesskey, “limit”) time = CURRENT_UNIX_TIME() keyname = APIaccesskey + ":” + time count = GET(keyname) IF current != NULL && count > limit THEN ERROR ”API request limit exceeded" ELSE MULTI INCR(keyname) EXPIRE(keyname,10) EXEC PERFORM_API_CALL() END Rate Limiting

28. • Redis counters – increment likes/dislikes • Redis hashes – list of everyone’s ratings • Process with algorithm like Slope One or Jaccardian similarity • Ruby example - https://github.com/davidcelis/recommendable Recommendation Engines INCR item:38927:likes HSET item:38927:ratings "Susan" 1 INCR item:38927:dislikes HSET item:38927:ratings "Tommy" -1

29. Chat and Messaging • PUBLISH and SUBSCRIBE Redis commands • Use Cases: • Chat rooms • Server Intercommunication

30. Redis – Read/Write Connections # Ruby example redis_write = Redis.new( 'mygame-dev.z2vq55.ng.0001.usw2.cache.amazonaws.com') redis_read = Redis::Distributed.new([ 'mygame-dev-002.z2vq55.ng.0001.usw2.cache.amazonaws.com', 'mygame-dev-003.z2vq55.ng.0001.usw2.cache.amazonaws.com' ]) redis_write.zset("leaderboard", "nateware", 1976) top_10 = redis_read.zrevrange("leaderboard", 0, 10)

31. Tune It Up!

32. Alarms Monitoring with CloudWatch • CPU • Evictions • Memory • Swap Usage • Network In/Out • https://docs.aws.amazon.com/ja_jp/AmazonEl astiCache/latest/UserGuide/CacheMetrics.Whi chShouldIMonitor.html

33. Key ElastiCache CloudWatch Metrics • CPUUtilization • Memcached – up to 90% ok • Redis – divide by cores (ex: 90% / 4 = 22.5%) • SwapUsage low • Evictions low • CacheMisses / CacheHits Ratio low • CurrConnections stable • Whitepaper: http://bit.ly/elasticache-whitepaper

34. Scaling Up Redis 1. Amazon S3へスナップショットを書き出す http://bit.ly/redis-snapshot 2. Snapshotからクラスタを作成 http://bit.ly/redis- seeding 3. クラスタ作成完了 4. 必要な分のデータコピーを実行する 5. ※クラスタ自体のスケールアップ、エンジンアップグレードには対応

35. まとめ 1. 何をキャッシュすべきか 2. どうキャッシュすべきか 3. キャッシュしたあとどうすべきか 4. これらを気をつける事でより効果的にElastiCacheを利用頂けます！

36. Thank you!

ElastiCacheを利用する上でキャッシュをどのように有効に使うべきか

Amazon Web Services Japan

ElastiCacheを利用する上でキャッシュをどのように有効に使うべきか