Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS Black Belt Tech シリーズ 2015 - Amazon ElastiCache

14,461 views

Published on

AWS Blackbelt 2015年8月19日 Amazon ElastiCache の資料です。今後の予定は以下をご覧ください。
http://aws.amazon.com/jp/about-aws/events/#webinar

Published in: Technology

AWS Black Belt Tech シリーズ 2015 - Amazon ElastiCache

  1. 1. Amazon ElastiCache AWS Black Belt Tech Webinar 2015 アマゾンデータサービスジャパン株式会社 ソリューションアーキテクト 成田 俊 2015/08/19
  2. 2. Agenda • 1.Amazon ElastiCache とは ? – ElastiCache 概要 – メモリキャッシング 概要 – Memcached、Redis 概要 • 2.前回(2015年1月)のWebinar以降のアップデート • 2015年 1月 – ElastiCache GovCloud(US)、Frankfult(EU)リージョン対応 • 2015年 2月 – Redis Cost allocation tags対応 • 2015年 3月 – Redis 2.8.19対応 • 2015年 7月 – Redis 2.8.21対応、Memcached Auto Discovery PHP 5.6対応 • 3. ユースケース、システムアーキテクチャ、注意点 • 4. 価格、まとめ
  3. 3. 1.Amazon ElastiCache とは ?
  4. 4. Amazon ElastiCacheの位置づけ • データ・ストアの特性に応じた使い分け Amazon DynamoDB Amazon RDS Amazon ElastiCache Amazon Redshift SQL NoSQL• 低レンテンシ • インメモリ • 3拠点間での レプリケーション • SSDに永続化 • トランザク ション処理 • 汎用技術 • 集計・分析処理 • 大容量データ
  5. 5. Amazon ElastiCacheとは • 構築 – キャッシュクラスタを数クリックで起動 – EC2、RDSと同様、初期費用無し、時間単位の従量課金 • 移行 – 2種類のエンジン(memcached, redis)をサポート – 既存アプリケーションの変更不要 • 運用 – 可用性を向上させる機能 – モニタリング、自動障害検出、復旧、拡張、パッチ管理 機能を提供 • セキュリティ – セキュリティグループ、VPC対応 メモリ内キャッシュをマネージドで提供するサービス →キャッシュに読み込まれたオブジェクトを保存し、性能負荷を軽減する
  6. 6. Memcached/Redis on EC2 との差異 • 導入  ノード用インスタンスのOSセットアップ 不要  memecached/ Redisのインストール・セットアップ 不要  複数キャッシュノードへのコンフィグファイル配布・同期不要  Management Console/CLI/APIから数分で起動・ノード追加 • 運用  監視・高可用性の作り込み不要  ノードリカバリ、パッチ適用 自動  Firewallの用意、詳細設定不要 • AWS独自の用語・概念  セキュリティ関連  クラスタ関連
  7. 7. メモリキャッシングとは • 目的 – アプリを高速化する手法の一つ – 消えても良いデータを格納してDBアクセス・負荷を低減 – メモリにキャッシュしたデータを再利用し 低遅延化・負荷低減 • 用途 – クエリ結果を再利用 (DBサーバの負荷低減、高速化) – 揮発性の高いデータを格納 (セッション情報管理) – 複雑な計算結果・二次データを再利用 (APPサーバの負荷軽減)
  8. 8. Web+DBアプリとメモリキャッシュ • 典型的な構成 App RDBMS 1. クライアントからのリクエスト 2. Appサーバが、DBサーバに問い合わせ 3. DBサーバが結果を戻す 4. Appサーバがレスポンスをクライアントに返す
  9. 9. Web+DBアプリとメモリキャッシュ • トラフィックが増えると App RDBMS 5. Appサーバ,DBサーバをスケール 6. 効果・効率・コスト的な面、DBをスケールさせる難易度は? ⇒ RDBをスケール“アウト”させるのは難しい。 App RDBMS
  10. 10. Web+DBアプリとメモリキャッシュ • DB負荷を軽減するためにキャッシュにデータを 載せる – アプリケーション側で、DBとキャッシュを使い分ける App RDBMS App キャッシュ
  11. 11. Web+DBアプリとメモリキャッシュ • データ参照時の操作 キャッシュ App RDBMS ■キーを検索軸に属性データがキャッシュにあるか? 取得して完了 ②なければDBへクエリ クエリ結果を取得 DBにクエリを実行した場合、 クエリ結果をキャッシュ 繰り返し ⇒(Point)キャッシュに最新結果が反映される ①あればキャッシュへ
  12. 12. Web+DBアプリとメモリキャッシュ • 更新時の操作 App 常にDBにInsert / Update 繰り返し その結果をオブジェクト書き込み キャッシュ RDBMS ⇒(Point)キャッシュには最新結果が反映される ※Appダウンでネガティブキャッシュが残る場合があるので先にキャッシュDELETEする、 TTLをつけるなど要件に合わせて対応が必要 ■キーを検索軸に属性データをキャッシュに配置する
  13. 13. Webアプリとメモリキャッシュ(セッション) • 共有キャッシュとして使った構成  複数のAppサーバで共有するセッション用メモリ空間を実現  多くの言語やフレームワークが対応済み  セッションレプリケーションやロードバランサに依存しない構 成が可能 App App キャッシュL B ■セッションIDのキーを検索軸に属性データを参照
  14. 14. Memcachedとは? • インメモリ key-value ストアキャッシュサーバ  2003年にDanga Interactiveが開発(BSDライセンス)  ブログサービス「Live Journal」の負荷対策用に作られたもの  多くのサイトで採用 (YouTube, Wikipedia, mixi, etc. ) • 特徴  KVSのデファクトスタンダードプロトコル • Key-valueのシンプルなデータ構造 • Telnetでも操作可能 • パフォーマンス向上を重視  主要機能のみのシンプルな機能 • アクセス制御などのセキュリティ機能無し • マスタノード、シャーディング、レプリケーションなどの機構無し – データ削除は明示的、期限、LRU(LeastRecentlyUsed)の3方式
  15. 15. Amazon ElastiCache for memcached • 特徴 – 対応バージョン 1.4.5、1.4.14 (2015.8.19現在) – memcached プロトコル準拠 – Cache Clusterという論理グループに、Cache Nodeを複数台起動 – Cluster Group 全体に • Configration Endpoint(各Node EndpointのCNAMEエントリ) • Cache Node単体にNode Endpoint の2種類のアクセス用のエンドポイントがある – バックアップ機能(Snapshot)は持たない CacheCluster A CacheCluster B Configration Endpoint Configration Endpoint Node Endpoint Node Endpoint Node Endpoint Node Endpoint
  16. 16. Auto Discovery for memcached • 従来のクライアント側の設定 – Cache Clusterの全エンドポイントを接続先として設定する。 • Auto Discoveryクライアント(Java, PHP,.NET) – Cache ClusterのConfiguration Endpointを接続先として設定すると、 全エンドポイントを自動取得・設定し、接続する。 – Configuration Endpointは、Cache Clusterの ロードバランサー( Proxy) ではなく、 あくまでも自動検知情報をEndpointで検知するだけである点に注意。 http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/AutoDiscovery.html CacheCluster Configuration Endpoint xxx.cfg.apne1.cache.amazonaws.com xxx.0001.apne1.cache.amazonaws.com xxx.0002.apne1.cache.amazonaws.com App 通常のクライアントライブラリ App Auto Discovery クライアントライブラリ • 確認コマンド ・Memchached 1.4.14以上 >Config get cluster ・Memchached 1.4.14未満 >get AmazonElastiCache:cluster
  17. 17. Memcached アクセス用のClient Libraryの提供 • Auto Discovery 用には専用のライブラリがAWSから提供 https://code.google.com/p/memc ached/wiki/Clients Auto Discovery用Client Libray通常アクセス用Client Library ・AWS Management Consoleから取得可能 ・PHP、Java、.NET に対応(New!PHP5.6) ・Memcached サイトからダウンロード することが可能 ・PHP、Java、.NET、C、C++、 Ruby、Python、Perl、他に対応
  18. 18. CloudWatchによるmemcached の監視 • 監視項目 – http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGu ide/CacheMetrics.Memcached.html • 主に監視する項目 – CPUUtilization (CPU使用率) – Evictions ( キャッシュメモリ不足によるキャッシュアウト発生回数) – SwapUsage – メモリ使用量 – CurrConnections – http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGu ide/CacheMetrics.WhichShouldIMonitor.html
  19. 19. CloudWatchによるmemcached の監視 • プロセスのメモリ使用量 – memcachedはBytesUsedForCacheItemが現在の使用量を示す。 こちらを用いて使用可能なメモリ量を計算していただく方法。 例1)Memcached(cache.t2.micro)でBytesUsedForCacheItemの値が200MB であった場合 max_cache_memory 555MB - 200MB = 333MBが残り使用可能なメモリ量 – ノードタイプごとのメモリ最大値は下記ドキュメントに記載されておりますのでご 確認ください。 ・Memcached のノードタイプ固有のパラメータ(max_cache_memory) http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/C acheParameterGroups.Memcached.html#CacheParameterGroups.Memcache d.NodeSpecific
  20. 20. Redisとは? • In-memory Key-Value Store • 高機能なデータ構造、データ操作 – List, Set, Sorted Set, Hash • 永続化機構 – Snapshot, Append only File • 冗長化機構 – Replication • Pub/Sub機能 • Lua scripting http://redis.io/
  21. 21. ElastiCache for Redis • 特徴 – 対応バージョン: 2.6.13、2.8.6、2.8.19、2.8.21 (2015.8.19現在) – 複数のCluster Group から構成されるReplication Group を構成し複数ノードで同期が取れる – S3上のスナップショット(RDB)プリロード機能でElastiCache 上へのデータ移行も容易 – Multi-AZ配置での自動フェイルオーバーにも対応 – Snapshotベースでのバックアップリスト機能にも対応 – Redisの特徴をほぼサポート • Lua Scripting • Pub/Sub • Append Only File • HyperLogLog(2.8.19以降), ZRANGEBYLEX, ZLEXCOUNT, ZREMRANGEBYLEX. • 対応しない機能 – CONFIG, SLAVEOFなど一部コマンドのみ無効 – パスワード (アクセス制御はセキュリティグループにて実施)
  22. 22. リードレプリカ (Replication) • 以下の用途に利用可能 – 耐障害性向上(ただし、非同期レプリケーション) – Read性能のスケーリング • 構成 – Replication Group内に、マスター1台、レプリカ 最大5台 – Replica of Replica は未対応 http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Replication.html http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/ManagingReplication.html Availability Zone - a Availability Zone - b CacheCluster CacheCluster CacheCluster Replication Group
  23. 23. リードレプリカを複数のアベイラビリティゾーンにデプロイ可能 – 同一AZのリードレプリカを参照し高速なデータ取得が可能に – プライマリノード側のAZ障害時のデータ保全が可能に アベイラビリティゾーンをまたいだReplication構成 Availability Zone - a Availability Zone - b 非同期レプリケーション 東京リージョン SET GET SET GET App App
  24. 24. リードレプリカをプライマリに昇格可能 昇格は数分が必要 – ダウンが発生するため、クライント側でエラーハンドリングは必要 – アプリ修正不要(プライマリのendpointが変わらない) リードレプリカ昇格 ① ① unlink ② SYNC ③ DNS change
  25. 25. RDBデータのプリロード • 既存のRedisからのElastiCacheへのデータ移行に – 既存のRedisで取得したRDBファイルをS3に保存 – キャッシュノード起動時に S3上のRDBファイルを読み込み • 注意点 – RDBファイルのバージョン互換性を確認 – 保存したS3に対して、ElastiCacheが参照可能なパーミッションが必要 – キャッシュノードタイプがサポートするメモリサイズを超えるRDBは読み込み不可。 (起動時にエラーが発生) Redis Redis on EC2 S3 RDB copy ElastiCache for Redis http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/ManagingCache Clusters.html#ManagingCacheClusters.SeedingRedis
  26. 26. S3からスナップショットをプリロード • プライマリノード起動時にS3パスを指定 (例: mybacket/path/data.rdb) データのプリロード設定手順
  27. 27. slaveof Redis EC2 S3 RDB copy • EC2上のRedisをslaveとして マスタに接続可能 • EC2上のRedis slave側でRDBファイルをS3へバックアップして おくことで、クラスタ起動時にS3からプリロード可能 プリロードの応用: バックアップ&リストア http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/ManagingCacheCluste rs.html#ManagingCacheClusters.RedisSnapshots http://redis.io/topics/persistence restore
  28. 28. Append-Only Files(AOF)について • AOFとは – Redisの機能で受信した全コマンド(操作)をローカルストレージ上のAOFに追記 – キャッシュノードreboot時にキャッシュデータの復元が可能 • メンテナンス時のreboot時にデータを保持可能 • デフォルトでは off – パラメータグループで appendonly をyesに変更し有効化 – cache.t1.microは未対応( appendonly=yesでも無視される) • 注意点 – ノード障害によるノード入れ替えが発生した場合はAOFが喪失する – データ保全のためには最低1台のリードレプリカ構成を推奨 – 耐障害性という観点からMAZを利用した構成を推奨 http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/CacheParameterGroup s.Redis.html#CacheParameterGroups.Redis.AOF
  29. 29. • AOFとは – Redisの機能で受信した全コマンド(操作)をローカルストレージ上のAOFに追記 – キャッシュノードreboot時にキャッシュデータの復元が可能 • メンテナンス時のreboot時にデータを保持可能 • デフォルトでは off – パラメータグループで appendonly をyesに変更し有効化 – cache.t1.microは未対応( appendonly=yesでも無視される) • 注意点 – ノード障害によるノード入れ替えが発生した場合はAOFが喪失する – データ保全のためには最低1台のリードレプリカ構成を推奨 – 耐障害性という観点からMAZを利用した構成を推奨
  30. 30. CloudWatchによるRedis の監視 • 主に監視する項目 – CPUUtilization (CPU使用率) – Evictions ( キャッシュメモリ不足によるキャッシュアウト発生回数) – CurrConnections – Replica Lag ( レプリケーション遅延) – メモリ使用量 • CPU 使用率を監視する際の注意点 – Redisは シングルスレッドなので、1コアで動作 – cache.m1.xlarge(4コア)だと、 25% (100% / 4) が最大値となる – Alert設定時には、上記点に注意する – http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/ CacheMetrics.WhichShouldIMonitor.html http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/CacheMetrics.html
  31. 31. CloudWatchによるRedis の監視 • プロセスのメモリ使用量 – RedisはBytesUsedForCacheが現在の使用量を示す。 こちらを用いて使用可能なメモリ量を計算していただく方法。 Redis(cache.t2.micro)でBytesUsedForCacheの値が200MBであった場合 maxmemory 約560MB - 200MB = 360MBが残り使用可能なメモリ量 – ノードタイプごとのメモリ最大値は下記ドキュメントに記載されておりますのでご 確認ください。 ・Redis のノードタイプ固有のパラメータ(maxmemory) http://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/UserGuide/C acheParameterGroups.Redis.html#CacheParameterGroups.Redis.NodeSpecifi c
  32. 32. CloudWatchによるRedis の監視 • swapUsage – Redis の BGSAVE の挙動により、 メモリの多くを使い、かつ書き込み が多いユースケースではswapが発 生して問題になる可能性があります。 メモリに関するパラメータで回避で きるため、詳しくはドキュメントの ベストプラクティスをご覧ください – http://docs.aws.amazon.com/ja _jp/AmazonElastiCache/latest/U serGuide/BestPractices.html
  33. 33. CloudWatchによるRedis の監視 • セッション数の確認 http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/CacheMetrics.html
  34. 34. 2.前回Webinar(2015年1月)からのアップデート
  35. 35. アップデート一覧 • 2015年 1月 – ElastiCache GovCloud(US)、Frankfult(EU)リージョン対応 • 2015年 2月 – Redis Cost allocation tags対応 • 2015年 3月 – Redis 2.8.19対応 • 2015年 7月 – Redis 2.8.21対応、Memcached Auto Discovery PHP 5.6対応
  36. 36. Redis Cost allocation tags コスト割り当てタグの管理で Redisが対応
  37. 37. PHP 5.6対応 • Auto Discovery Client for PHP 5.6
  38. 38. Redis 2.8.19、2.8.21対応によるコマンド追加 • Redis 2.8.19対応により、2.8.6以降で追加された機能が利用可能に。 – HyperLogLog:PFCOUNT、PFADD、PFMERGEの追加 – ZRANGEBYLEX、ZLEXCOUNT、ZREMRANGEBYLEXの追加 – ROLE、BITPOS、COMMANDの追加
  39. 39. HyperLogLog HyperLogLogはセット内 のユニークな要素数を効率 的で高速に近似することが 出来るコンパクト(各Key 毎に12KB)なRedisのデー タ・タイプです。(カー ディナリティと呼ばれてい るものです)。 推定値(0.81パーセントの 標準誤差で)を取得するこ とが可能。 Example PFADD redis> PFADD hll a b c d e f g (integer) 1 ※hllというkeyが変更されたの で1が戻り値 Example PFCOUNT redis> PFCOUNT hll (integer) 7 redis> ※a,b,c,d,e,f,gという7種類の値 が存在するので戻り値が7 Example PFMERGE redis> PFADD hll1 foo bar zap a (integer) 1 redis> PFADD hll2 a b c foo (integer) 1 redis> PFMERGE hll3 hll1 hll2 OK redis> PFCOUNT hll3 (integer) 6 ※hll1とhll2をマージしたhll3 というkeyを作成し合算した 値でPFCOUNTを実行。計6 種類あるので戻り値が6
  40. 40. ZRANGEBYLEX、ZLEXCOUNT、ZREMRANGEBYLEX Sorted Set型で • ZRANGEBYLEX (範囲指定探索) • ZLEXCOUNT (範囲指定カウント) • ZREMRANGEBYLEX (範囲指定削除) が使用可能。 Example ZREMRANGEBYLEX redis> ZADD myzset 0 aaaa 0 b 0 c 0 d 0 e (integer) 5 redis> ZADD myzset 0 foo 0 zap 0 zip 0 ALPHA 0 alpha (integer) 5 redis> ZRANGE myzset 0 -1 1) "ALPHA" 2) "aaaa" 3) "alpha" 4) "b" 5) "c" 6) "d" 7) "e" 8) "foo" 9) "zap" 10) "zip" redis> ZREMRANGEBYLEX myzset [alpha [omega (integer) 6 redis> ZRANGE myzset 0 -1 1) "ALPHA" 2) "aaaa" 3) "zap" 4) "zip" redis> Example ZLEXCOUNT redis> ZADD myzset 0 a 0 b 0 c 0 d 0 e (integer) 5 redis> ZADD myzset 0 f 0 g (integer) 2 redis> ZLEXCOUNT myzset - + (integer) 7 redis> ZLEXCOUNT myzset [b [f (integer) 5 redis> Example ZRANGEBYLEX redis> ZADD myzset 0 a 0 b 0 c 0 d 0 e 0 f 0 g (integer) 7 redis> ZRANGEBYLEX myzset - [c 1) "a" 2) "b" 3) "c" redis> ZRANGEBYLEX myzset - (c 1) "a" 2) "b" redis> ZRANGEBYLEX myzset [aaa (g 1) "b" 2) "c" 3) "d" 4) "e" 5) "f" redis>
  41. 41. バージョン追加とインスタンスタイプ スタンダード – 現行世代 cache.t2.micro cache.t2.small cache.t2.medium cache.m3.medium cache.m3.large cache.m3.xlarge cache.m3.2xlarge メモリの最適化 – 現行世代 cache.r3.large cache.r3.xlarge cache.r3.2xlarge cache.r3.4xlarge cache.r3.8xlarge • バージョンの追加 – Redis 2.8.19、2.8.21がサポート。 • インスタンスタイプ – EC2、RDS同様に新世代への移行を推奨 – T1、T2ではAOF、マルチAZ、バックアッ プ・復元が利用不可。 スタンダード – 前の世代 cache.m1.small cache.m1.medium cache.m1.large cache.m1.xlarge メモリの最適化 – 前の世代 cache.m2.xlarge cache.m2.2xlarge cache.m2.4xlarge 新世代 旧世代
  42. 42. 3.ユースケース、注意点、システム構成例
  43. 43. ユースケース • memcached , redis – データキャッシュ – セッションストア • redis – 分散カウンター (atomic counter) – リアルタイム・メトリック (bitmaps) – キュー (lists) – メッセージング (pub/sub) – リーダーボード,スコアランキング (sorted sets) Client 1 subscribe deliver msg Client 2 subscribe deliver msg Channels / Patterns Client 参照 更新
  44. 44. 2015年8月時点でのElastiCache利用上の注意点 2015年8月時点での注意点 • VPC内に起動した場合、VPC外からアク セスできない。 - Endpoint がPublic Facing対応していな いため。 • IAMでキャッシュノードのリソース 制御できない - ARN(Amazon Resource Name)が無いため。 更新 Action 参照 Action のみ
  45. 45. メモリキャッシュを利用する際の注意点 • システムの性質を考える – 一般的なWebシステムは、参照:更新≒9:1 – 更新クエリの割合が大きいシステムでは効果薄 – キャッシュミス時のペナルティ対策(定期更新等) – キャッシュ喪失時の対策も織り込む • キャッシュするデータの性質を考えてキャッシュする  有効期限の短いデータは不向き  参照頻度の低いデータは、メモリ効率が悪い • トランザクション・コヒーレンシを考える  一貫性が必要なデータは、慎重に設計・実装する  DBより古いキャッシュを使わない工夫
  46. 46. キャッシュのSPOF(単一障害点)について • 単一キャッシュノード構成の課題 – 障害時のデータ喪失による影響は少ない(はず)  ただしDBが過負荷になり、システムスローダウンやダウンも  キャッシュ容量増強のためにはスケールアップ(容易ではない) App RDBMS App キャッシュ
  47. 47. キャッシュのクラスタ化(Consistent Hashing) • Consistent Hashingの特徴 – Appサーバ側でConsistent Hashingアルゴリズムで振り分ける  ノード障害時のキャッシュ喪失が限定的  ノード追加で総キャッシュ容量を増やしやすい  ノード数変更時のリバランスコストが限定的 キャッシュ キャッシュ ノードリスト CHアルゴリズム ライブラリ APPサーバ
  48. 48. キャッシュのクラスタリングの方法 • クライアントライブラリでの実装 – PHPなどで使うlibmemcachedは標準でdistribution アルゴリズム実装済み • サードパーティソフトでの実装:Twemproxy – Twitter社が開発したMemcached/Redis用のproxy – 複数サーバーのシャーディング (consistent hashing) – キャッシュサーバーの接続管理 – 一部未サポートのコマンドもあり • 参考  Consistent hashing - Wikipedia, the free encyclopedia  http://en.wikipedia.org/wiki/Consistent_hashing  memcachedを知り尽くす:第4回 memcachedの分散アルゴリズム|gihyo.jp … 技術評論 社  http://gihyo.jp/dev/feature/01/memcached/0004?page=3  Partitioning: how to split data among multiple Redis instances.  http://redis.io/topics/partitioning
  49. 49. Twemproxyの構成例 TwemproxyがSPOFとならないように、各アプリサーバ上Twemproxyを起動し、 アプリケーションはローカルホストのtwemproxyにアクセスする App + Twemproxy App + Twemproxy memcached RG1 App + Twemproxy App + Twemproxy RG2 Redis
  50. 50. 同一リージョン内のAZを跨いだクラスタ対応 • AZを跨いでクラスタを構成する事が可能 Availability Zone - a Availability Zone - b Cache Cluster Memcached Redis Nodeを複数選択し、 Availability Zone(s) で「Specify Zones」を選択 し、各Zoneに配置する ノード数を指定する。 Read Replicaを選択し、 デフォルトでAZを指定 できるため、Primaryと Read Replicaを任意の AZに配置する。
  51. 51. ElastiCache Redis バックアップリストア機能 • ElastiCache Redis が Snapshot機能によるバックアップリストア機能に対応 (キャシュサービスは障害時にデータが消失するため、要件次第でバックアップが必要) • Snapshot取得時はRedisで内部的にBGSAVEを行っているため、 性能懸念がある場合はRead Replicaから取得を推奨 Redis Master Redis Read Redis Read Snapshot取得 挿入 更新 参照 削除 参照 参照 性能 劣化 データ変更はMaster ノードしかできないため、 負荷をあげない Read Replica はCluster内で 増やせるため、 スケールアウトが可能Replication Group A × Masterから Snapshotは 取得しない Snapshot Replication Group B Redis Master Redis Read 別のReplication Groupに別途に起動 することも可能
  52. 52. ElastiCache Redis バックアップリストア手順 手動バックアップ手順自動バックアップ手順 「Cache Clusters」か「Snapshot」のどちらかから実施Clusters全体に対して、「Create」 若しくは「Modify」で設定。 自動バックアップを 「Yes」で有効化する。 ・対象(Read Replica)を指定。 ・バックアップ保存期間を指定。(最大35日) ・バックアップ期間を指定(1日1回) • Snapshot取得は、自動でも手動でも可能。
  53. 53. ElastiCache Redis Multi-AZ自動フェイルオーバー機能 Redis Master Redis Read Redis Read • ElastiCache Redis のMaster Nodaが障害時に自動フェイルオーバする機能 • フェイルオーバは同じReplication Group内の別AZにRead ReplicaがMasterに昇格し実現 Redis Read Redis Read Redis Read Availability A Availability B Replication Group =Cache Subnet Group Redis Read Redis Read Redis Read Redis Master Redis Read Availability A Availability B Replication Group =Cache Subnet Group Group内でAZ が別のRead Replicaが Master昇格 挿入 更新 参照 削除 挿入 更新 参照 削除
  54. 54. ElastiCache Redis Multi-AZ自動フェイルオーバー設定 Replication を有効に したうえ、Multi-AZを 有効にする。 複数のAZがあるVPC Subnet が指定されている Cache Subnet Groupを指 定する。 Primary とは別のAZに指定さ れているRead Replicaがフェ イルオーバ先の候補になる。
  55. 55. 自動ファイルオーバ無効時の障害時の挙動 リードレプリカあり リードレプリカなし 障害 プライマリ障害 ノード全面障害 挙動 1. キャッシュイベントをSNSで通知を受取る 2. 再起動を試みる 3. 再起動失敗した場合、フェイルオーバーが必要 4. FO後プライマリDNS自動切替 1. キャッシュイベントをSNSで通知を受取る 2. 新しいノードを立ち上げ 3. DNS切替 影響 • フェイルオーバー完了まで書込不可 • それまでの一定の時間(秒単位)RR読込不可 キャッシュデータロスト 対策 • SNS通知を設定する • クライント/アプリでエラーハンドリング(retry, DBから取得など) • SNS通知を設定する • キャッシュ喪失時の対策も織り込む プライマリ障害 ノード全面障害
  56. 56. 4.価格、まとめ
  57. 57. 価格 • オンデマンド キャッシュノード – 初期費用無し、時間単位の従量課金モデル – MemcachedとRedisでどちらも料金は変わらず http://aws.amazon.com/jp/elasticache/pricing/ http://aws.amazon.com/jp/elasticache/reserved-cache-nodes/ • リザーブド キャッシュノード – 予約金を支払うことで時間当たり価格を割引(最大 70%節減) – EC2と違いアベイラビリティゾーンの指定が不要 時間あたりの料金(東京リージョン) ※2015年8月18日現在 cache.t2.micro $0.026 cache.t2.small $0.052 cache.t2.medium $0.104 cache.m3.medium $0.120 cache.m3.large $0.240 cache.m3.xlarge $0.485 cache.m3.2xlarge $0.965 cache.r3.large $0.273 cache.r3.xlarge $0.546 cache.r3.2xlarge $1.092 cache.r3.4xlarge $2.184 cache.r3.8xlarge $4.368 • バックアップストレージ – Redis向け機能 – 各クラスタに対して1つのSnapshotは無料 – 2つ以上のSnapshotから毎月 0.085 USD/GBが課金 • AZ間データ転送量 – ElastiCache間の通信は課金対象外 – EC2とElastiCache間でAZを超える場合 0.01 USD/GB が課金
  58. 58. Amazon ElastiCache のまとめ • 構築・運用が非常に容易で、Multi-AZ構成の高可用性機能にも対応 Memcached セッションキャッシュ分散 Redis Pub/Sub連携 App+ Twemproxy Availability Zone : A Availability Zone : B App+ Twemproxy Cache Cluster Master Slave App+ Twemproxy Availability Zone : A Availability Zone : B App+ Twemproxy Replication GroupMaster Read App+ Twemproxy App+ Twemproxy
  59. 59. 参考資料 • Amazon ElastiCache Document http://aws.amazon.com/jp/documentation/elasticache/ • Amazon ElastiCache FAQ http://aws.amazon.com/jp/elasticache/faqs/ • Amazon ElastiCache Pricing http://aws.amazon.com/jp/elasticache/pricing/ • Memcached http://memcached.org/ • Redis http://redis.io/
  60. 60. Q&A
  61. 61. Webinar資料の配置場所 • AWS クラウドサービス活用資料集 – http://aws.amazon.com/jp/aws-jp-introduction/
  62. 62. 公式Twitter/Facebook AWSの最新情報をお届けします @awscloud_jp 検索 最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを 日々更新しています! もしくは http://on.fb.me/1vR8yWm
  63. 63. ご参加ありがとうございました。

×