Tweet
Tweet

Slide 1

Slide 1 text

オンプレインフラエンジニアが ElastiCacheを使ってみた 2016/03/29 株式会社サイバーエージェント　小貫 貴央

Slide 2

Slide 2 text

アジェンダ - 自己紹介 - オンプレでのmemcachedの使い方 - ElastiCacheでのmemcachedの使い方 - オンプレでのredisの使い方 - ElastiCacheでのredisの使い方 - まとめ

Slide 3

Slide 3 text

お前誰だよ？

Slide 4

Slide 4 text

お前誰だよ？ - 自己紹介 - 小貫 貴央 twitter:editnuki 　- 株式会社サイバーエージェント 　- サービスインフラグループ(Ameba、子会社も) 　- 次、ぴちぴちの社会人5年目(えっ？) 　- 残念ながらプログラムのプの字もできません 　- なので今日は完全にインフラ目線でお話します

Slide 5

Slide 5 text

　このお二人には4〜5年くら い前からお世話になって おります

Slide 6

Slide 6 text

・755,タップル誕生,spotlight,ペコリ等など 関わったサービス

Slide 7

Slide 7 text

今担当しているサービス ・AmebaFRESH　 　EC2,S3,RDS,ElastiCache,Docker,ECS, CloudFront,Lambda,Route53などなどどっぷり AWS

Slide 8

Slide 8 text

・AmebaFRESH　 　 Socker.IO (Node) chat-api (Go) tg-agent ElastiCache接続構成 Nginx api (Go) web (Node) tg-agent マルチAZは使っていない pubsub session

Slide 9

Slide 9 text

AmebaFRESHの発表 ・stormcat24さん(山田さん)のDocker周りの発表資料 https://speakerdeck.com/stormcat24/next-fresh-applications-with-amazon-ecs https://speakerdeck.com/stormcat24/oqian-falsedockerimezihamadazhong-i

Slide 10

Slide 10 text

ElastiCacheの前にオンプレの話 - memcachedやredisをオンプレで利用してる 時のお話を先にします - memcachedはあまり内容ないです

Slide 11

Slide 11 text

・オンプレでmemcachedを使った場合 webサーバ memcached memcached memcached ElastiCacheの前にオンプレの話

Slide 12

Slide 12 text

- 複数台並べる - 全てに更新参照 - or Active – Standby - 1台死亡 - OSSのsdk(うちはjavaが多い)でコントロール - データ紛失 - memcachedに消えて困るものおいたらあかん ElastiCacheの前にオンプレの話

Slide 13

Slide 13 text

- 台数が増える - アプリに指定するサーバが多いので管理大変 - Trafficが多すぎる - ホストごと死ぬ(弊社プライベートクラウドｗ) ElastiCacheの前にオンプレの話

Slide 14

Slide 14 text

ElastiCacheの場合 ・ElastiCacheでmemcachedを使った場合 webサーバ memcached memcached memcached

Slide 15

Slide 15 text

ElastiCacheの場合 - AWS sdk - ノード追加したらアプリから自動追加される - マジ便利(๑•̀ㅁ•́๑)✧ - Traffic増えてもノード増やせば終わり - 管理 - EC2管理不要 - aws-cliや管理コンソールで操作できる

Slide 16

Slide 16 text

ElastiCacheの場合 - コスト - EC2に比べると少し高い - redisの場合は比較したので後で - sdkなしの場合 - アプリケーションでハンドリングしてない - 死んだサーバに向き続けるので延々死亡する(実 績あり！ｗ)

Slide 17

Slide 17 text

memcachedのまとめ memcachedは あんまり使ってないので よくわかりませんｗ

Slide 18

Slide 18 text

redisの話 - 弊社は3年くらい前からmemcachedよりもredisが多く使 われるようになりました - memcached自体はもっと軽い感じで使うことが多いです - redisではランキング(sort)を管理したり、セッション管理、 pubsub(chat関連)、イイね的な数のインクリメント - デク リメント、で利用していることが多いです - 少数ですが3.0系のredisクラスタの利用もあり

Slide 19

Slide 19 text

オンプレの場合 ・オンプレでredisを使った場合(初期構成) webサーバ redisマスター redis スレーブ redis スレーブ L B sentinel エイリアスIP 更新 参照 死活監視

Slide 20

Slide 20 text

オンプレ(初期構成)の問題 - エイリアスIP使用 - IPを付け替えに失敗したりする - VLANまたぎでarpingが必要になったり - フェイルオーバー用のスクリプトを自作して運 用する手間があった

Slide 21

Slide 21 text

オンプレの場合 ・オンプレでredisを使った場合(現在構成) webサーバ redisマスター + sentinel redis スレーブ +sentinel redis スレーブ +sentinel L B sentinel 更新 参照 死活監視 IPチェック

Slide 22

Slide 22 text

オンプレ(現在構成)の場合 - jedisとsentinel - マスターのIPが返ってくるのでそのIPをキャッシュし てマスターへ書き込みを行える - フェイルオーバー - タイムアウトで再度マスターIPを取得し直す - エイリアスIP不要

Slide 23

Slide 23 text

オンプレ(現在構成)の場合 - 高負荷時 - スレーブの台数増やしLBに追加 - レプリ管理 - スレーブ追加で自動的にsentinelが認識 - LB管理くらいで済む

Slide 24

Slide 24 text

オンプレの最大の障害 NW機器で障害！！！ プライベートクラウドの環境がはちゃめちゃ状態 ε≡≡ﾍ( ´Д`)ﾉ

Slide 25

Slide 25 text

オンプレの最大の障害 - sentinelが変な挙動をして - 親子孫ひ孫構成になる - エイリアスIPが 複数台に付いていたり＼(^o^)／

Slide 26

Slide 26 text

ElastiCacheの場合 ・ElastiCacheでredisを使った場合(現在構成) webサーバ redisマスター redis リードレプリカ redis リードレプリカ h a p r o x y 更新 参照

Slide 27

Slide 27 text

ElastiCacheの場合 ・ElastiCacheでredisを使った場合(現在構成) webサーバ redisマスター redis リードレプリカ redis リードレプリカ h a p r o x y 更新 参照

Slide 28

Slide 28 text

ElastiCacheの場合 - フェイルオーバー - sdk - dnsもちゃんと変わる - 監視とか変更作業不要 - ノードの管理 - aws-cli - 管理コンソール

Slide 29

Slide 29 text

ElastiCacheの問題 - ELBが使えない(EC2でも非推奨) - haproxyなどで参照を分散可 - haproxyのbackend管理が大変 - maxmemoryはスペックで固定 - bgsaveの周期ルールが変更不可 - golang対応はよ - golang対応してないのでredigoというライブラリを利用して いる

Slide 30

Slide 30 text

ElastiCacheの問題 - haproxyの問題に関して - Amazon ECSでHAProxyのDockerコンテナを各Taskに配置するのが なかなか良い件 - http://stormcat.hatenablog.com/entry/docker-haproxy-ecs

Slide 31

Slide 31 text

ElastiCacheの問題 - コンテナで済むので、構築の手間が省ける - 集約的にHAProxyを立てる場合、全体でどれくらい のリクエストを受けるかを見積って十分なキャパシティ のものを構築する必要がある - 各タスクに配置されるので基本的に冗長化とかを考え たりしなくて良い

Slide 32

Slide 32 text

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 現在

Slide 33

Slide 33 text

オンプレの場合 ・オンプレでredisを使った場合(現在構成) webサーバ redisマスター + sentinel redis スレーブ +sentinel redis スレーブ +sentinel L B sentinel 更新 参照 死活監視 IPチェック

Slide 34

Slide 34 text

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 現在

Slide 35

Slide 35 text

まとめ - ElastiCacheを利用することでメリットもある - EC2の管理コスト - フェイルオーバーなど対障害性 - レプリケーションを張るなどの作業コスト - マスターがどれかなどの管理コスト

Slide 36

Slide 36 text

まとめ - 構成によってコストの差が出るが大きくは変わ らない - まだ欲しい機能などもあるが、今のところ運用 していてそこまで困ったことがない

Slide 37

Slide 37 text

まとめ ElastiCache(・∀・)ｲｲﾈ!!

Slide 38

Slide 38 text

ありがとうございました