オンプレインフラエンジニアが ElastiCacheを使ってみた

2016/03/29 にAmazonさんで行われた「アプリケーション高速化のためのキャッシュ活用 」で発表した資料になります。

オンプレ時代とAWSのElastiCacheを利用した比較をもとに事例を発表させていただきました。

http://aws.amazon.com/jp/about-aws/events/2016/elasticache_20160329/

Transcript

1. オンプレインフラエンジニアが ElastiCacheを使ってみた 2016/03/29 株式会社サイバーエージェント　小貫 貴央
2. アジェンダ - 自己紹介 - オンプレでのmemcachedの使い方 - ElastiCacheでのmemcachedの使い方 - オンプレでのredisの使い方 - ElastiCacheでのredisの使い方 - まとめ
3. お前誰だよ？
4. お前誰だよ？ - 自己紹介 - 小貫 貴央 twitter:editnuki 　- 株式会社サイバーエージェント 　- サービスインフラグループ(Ameba、子会社も) 　- 次、ぴちぴちの社会人5年目(えっ？) 　- 残念ながらプログラムのプの字もできません 　- なので今日は完全にインフラ目線でお話します
5. 　このお二人には4〜5年くら い前からお世話になって おります
6. ・755,タップル誕生,spotlight,ペコリ等など 関わったサービス
7. 今担当しているサービス ・AmebaFRESH　 　EC2,S3,RDS,ElastiCache,Docker,ECS, CloudFront,Lambda,Route53などなどどっぷり AWS
8. ・AmebaFRESH　 　 Socker.IO (Node) chat-api (Go) tg-agent ElastiCache接続構成 Nginx api (Go) web (Node) tg-agent マルチAZは使っていない pubsub session
9. AmebaFRESHの発表 ・stormcat24さん(山田さん)のDocker周りの発表資料 https://speakerdeck.com/stormcat24/next-fresh-applications-with-amazon-ecs https://speakerdeck.com/stormcat24/oqian-falsedockerimezihamadazhong-i
10. ElastiCacheの前にオンプレの話 - memcachedやredisをオンプレで利用してる 時のお話を先にします - memcachedはあまり内容ないです
11. ・オンプレでmemcachedを使った場合 webサーバ memcached memcached memcached ElastiCacheの前にオンプレの話
12. - 複数台並べる - 全てに更新参照 - or Active – Standby - 1台死亡 - OSSのsdk(うちはjavaが多い)でコントロール - データ紛失 - memcachedに消えて困るものおいたらあかん ElastiCacheの前にオンプレの話
13. - 台数が増える - アプリに指定するサーバが多いので管理大変 - Trafficが多すぎる - ホストごと死ぬ(弊社プライベートクラウドｗ) ElastiCacheの前にオンプレの話
14. ElastiCacheの場合 ・ElastiCacheでmemcachedを使った場合 webサーバ memcached memcached memcached
15. ElastiCacheの場合 - AWS sdk - ノード追加したらアプリから自動追加される - マジ便利(๑•̀ㅁ•́๑)✧ - Traffic増えてもノード増やせば終わり - 管理 - EC2管理不要 - aws-cliや管理コンソールで操作できる
16. ElastiCacheの場合 - コスト - EC2に比べると少し高い - redisの場合は比較したので後で - sdkなしの場合 - アプリケーションでハンドリングしてない - 死んだサーバに向き続けるので延々死亡する(実 績あり！ｗ)
17. memcachedのまとめ memcachedは あんまり使ってないので よくわかりませんｗ
18. redisの話 - 弊社は3年くらい前からmemcachedよりもredisが多く使 われるようになりました - memcached自体はもっと軽い感じで使うことが多いです - redisではランキング(sort)を管理したり、セッション管理、 pubsub(chat関連)、イイね的な数のインクリメント - デク リメント、で利用していることが多いです - 少数ですが3.0系のredisクラスタの利用もあり
19. オンプレの場合 ・オンプレでredisを使った場合(初期構成) webサーバ redisマスター redis スレーブ redis スレーブ L B sentinel エイリアスIP 更新 参照 死活監視
20. オンプレ(初期構成)の問題 - エイリアスIP使用 - IPを付け替えに失敗したりする - VLANまたぎでarpingが必要になったり - フェイルオーバー用のスクリプトを自作して運 用する手間があった
21. オンプレの場合 ・オンプレでredisを使った場合(現在構成) webサーバ redisマスター + sentinel redis スレーブ +sentinel redis スレーブ +sentinel L B sentinel 更新 参照 死活監視 IPチェック
22. オンプレ(現在構成)の場合 - jedisとsentinel - マスターのIPが返ってくるのでそのIPをキャッシュし てマスターへ書き込みを行える - フェイルオーバー - タイムアウトで再度マスターIPを取得し直す - エイリアスIP不要
23. オンプレ(現在構成)の場合 - 高負荷時 - スレーブの台数増やしLBに追加 - レプリ管理 - スレーブ追加で自動的にsentinelが認識 - LB管理くらいで済む
24. オンプレの最大の障害 NW機器で障害！！！ プライベートクラウドの環境がはちゃめちゃ状態 ε≡≡ﾍ( ´Д`)ﾉ
25. オンプレの最大の障害 - sentinelが変な挙動をして - 親子孫ひ孫構成になる - エイリアスIPが 複数台に付いていたり＼(^o^)／
26. ElastiCacheの場合 ・ElastiCacheでredisを使った場合(現在構成) webサーバ redisマスター redis リードレプリカ redis リードレプリカ h a p r o x y 更新 参照
27. ElastiCacheの場合 ・ElastiCacheでredisを使った場合(現在構成) webサーバ redisマスター redis リードレプリカ redis リードレプリカ h a p r o x y 更新 参照
28. ElastiCacheの場合 - フェイルオーバー - sdk - dnsもちゃんと変わる - 監視とか変更作業不要 - ノードの管理 - aws-cli - 管理コンソール
29. ElastiCacheの問題 - ELBが使えない(EC2でも非推奨) - haproxyなどで参照を分散可 - haproxyのbackend管理が大変 - maxmemoryはスペックで固定 - bgsaveの周期ルールが変更不可 - golang対応はよ - golang対応してないのでredigoというライブラリを利用して いる
30. ElastiCacheの問題 - haproxyの問題に関して - Amazon ECSでHAProxyのDockerコンテナを各Taskに配置するのが なかなか良い件 - http://stormcat.hatenablog.com/entry/docker-haproxy-ecs
31. ElastiCacheの問題 - コンテナで済むので、構築の手間が省ける - 集約的にHAProxyを立てる場合、全体でどれくらい のリクエストを受けるかを見積って十分なキャパシティ のものを構築する必要がある - 各タスクに配置されるので基本的に冗長化とかを考え たりしなくて良い
32. ElastiCacheのコスト - 2台構成にした場合 - ElastiCache(6.5GB memory) - $0.240*2/hour = $0.480/hour - EC2 r3.large(15GB memory) - $0.200*2/hour = $0.400/hour - bgsaveでメモリを2倍使うので15GB memoryインスタンスで計算 ※2016/03/28 現在
33. オンプレの場合 ・オンプレでredisを使った場合(現在構成) webサーバ redisマスター + sentinel redis スレーブ +sentinel redis スレーブ +sentinel L B sentinel 更新 参照 死活監視 IPチェック
34. ElastiCacheのコスト - 2台構成にした場合+EC2でsentinel用のインスタンス1台 - ElastiCache(6.5GB memory) - $0.240*2/hour = $0.480/hour - EC2 r3.large(15GB memory) + m3.medium - $0.200*2/hour = $0.400/hour - bgsaveでメモリを2倍使うので15GB memoryインスタンスで計算 - $0.096/hour - $0.400 + $0.096 = $0.496 ※2016/03/28 現在
35. まとめ - ElastiCacheを利用することでメリットもある - EC2の管理コスト - フェイルオーバーなど対障害性 - レプリケーションを張るなどの作業コスト - マスターがどれかなどの管理コスト
36. まとめ - 構成によってコストの差が出るが大きくは変わ らない - まだ欲しい機能などもあるが、今のところ運用 していてそこまで困ったことがない
37. まとめ ElastiCache(・∀・)ｲｲﾈ!!
38. ありがとうございました