ElastiCacheについてメモ
メモ。
redisのほうが高機能ですね。
■全般
EC2上にmemcachedを構築するより、セットアップが楽、高可用性、
CloudWacth使用可なので便利。
RDSと同様、OSにログインは出来ない。
最近M3のインスタンスタイプが提供された。現在はmemcachedしか対応していない。
memcachedとredisだと、同じインスタンスタイプでも使えるメモリ量が異なる。
(redisのうほうが少ない)
コネクション数やキャッシュが溢れたなどはCloudWactchで見れる。(+SNSも)
VPC対応済み。VPC環境だとPublicIPは付与されない。
memcachedは認証の仕組みがない。(redisはある)
EC2-ClassicはCacheSG、VPCは通常通りVPC SGとなる。
パッチ適用時は再起動を伴うこともある。
ElastiCacheが停止するとDBへの負荷が上がる可能性があるので留意した設計にする。
（L7ヘルスチェックやSNS通知など）
基本的にはパラメータは変更する必要はない。
INもOUTもデータ転送での料金は発生しない。異なるAZ間は$0.01/GBかかる。
リザーブド、オンデマンドあり。EC2の場合はAZまで選ぶがElastiCacheは不要。
キャッシュエンジン指定は必要。
■memcahedエンジン
認証などのセキュリティ機能なし、レプリなどもなし。
CaccheClusterは、AZ跨げない。
AutoDiscovery for memcachedは、ConfigurationEndPointに接続するので、キャッシュノード
を意識する必要はない。
ただし、AWSが配布している専用ライブラリが必要、ライブラリはキャッシュノードの
接続情報を返すだけ。（なので、更新はキャッシュノード指定と推測される）
Evictions（キャッシュアウト回数）、SwapUsageが発生しだしたらスケールアップ、アウト
を検討する。
■redisエンジン
高機能なデータ構造、レプリあり。
S3上にスナップショット(RDB)を置いてロードができる。ElastiCache起動時にバケット名
など指定。ただし、データ移行元と移行先のElastiCacheのメモリ量に気をつけること。
CONFIG、SLAVEOFFコマンドは使えない。
パスワード設定は出来ないので、SGで担保する。
レプリは非同期、リードレプリカとなる。
AZを跨いでレプリ構成が組める。（AZ1:マスター、レプリカ、AZ2:レプリカなど）
レプリカをマスターに昇格することは可能。数分間ダウンは発生する。Endpointは引き継がれるのでアプリ側は接続先を意識する必要なし。
リードレプリカなし構成でノード障害が発生すると、データはロストする。
リードレプリカあり構成でプライマリ障害が発生すると、書き込みは不可、F/O直前までの
データは保全。
本家のSentinel(HA)と機能は異なる。
AOFを有効にすると、受信したコマンドをローカルストレージのAOFに記録されるので、
reboot時に復元可能。
ノード障害時は復元できないことがある？
Redisはシングルスレッドで動作するので1コア。4コアの場合、100%/4 で見る。
■その他
キャッシュノードはクラッシュ時は自動で復旧する？？
→ memcachedは自動復旧。redisも同じ。ただしredisのレプリ時は挙動が違う。
キャッシュのバックアップをS3に保存すること可能？
→ redisは自力で可能。今後リリース予定あり。
だいぶ書き殴りました・・・
以上です。
