[レポート] Amazon ElastiCache Deep Dive: インメモリデータストアのデザインパターン #reinvent
はじめに
福岡のyoshihitohです。re:Invent 2018のセッション「[REPEAT 1] ElastiCache Deep Dive: Design Patterns for In-Memory Data Stores」についてレポートします。
セッション情報
セッション名
DAT302 - [REPEAT 1] ElastiCache Deep Dive: Design Patterns for In-Memory Data Stores
スピーカー
- Michael Labib - Principal Solutions Architect, AWS
概要
原文の引用です。
In this session, we provide a behind the scenes peek to learn about the design and architecture of Amazon ElastiCache. See common design patterns with our Redis and Memcached offerings and how customers use them for in-memory data processing to reduce latency and improve application throughput. We review ElastiCache best practices, design patterns, and anti-patterns.
以降がセッション内容です。
Amazon ElastiCache Deep Dive: インメモリデータストアのデザインパターン
アジェンダ
- 最新情報
- Amazon ElastiCache Deep Dive
- Redisの一般的なアーキテクチャパターン
- キャッシュ戦略
- ベストプラクティス
データのカテゴリと一般的なユースケース
- リレーショナル
- 参照整合性
- ACIDトランザクション
- スキーマベースの書き込み
- キー・バリュー
- 低レイテンシ
- 高スループットなキー検索
- 高速なデータ追加
- ドキュメント
- 属性値にもとづいてドキュメントをインデクシング・ソート
- イン・メモリ
- マイクロ秒単位のレイテンシ
- キーベースのクエリ
- 特殊化したデータ構造
- グラフ
- データ間の関連を高速に作成・案内
RedisとMemcachedの最新情報
Redis 5.0
- Redis Stream
- SortedSets now have LIST capabilities (POP and BLOCK)
- HyperLogLogs has an optimized algorithm
- Speed Improvements (Jemalloc additions, etc.)
- Active Defragmentation
- Added In-line HELP command for redis-cli
- Native TLS Integration Redis (ElastiCache)
- More at https://aws.amazon.com/redis/Whats_New_Redis5
Memocached 1.5.10
- Automated Slab reblancing
- LRU crawler to background-reclaim memory
- Faster hash table lookups with murmur3 algorithm
Review: Redis5以前のタイムシリーズ
- SortedSet: Unixtimeをスコアとして使う
- 値(メッセージ)はユニークであること
- スコアは変更できる (mutable)
- List: ブロッキングキュー
- メッセージをリカバリできない
- ファンアウトできない
- Pub/Sub
- 永続化できない
- 失敗したクライアントをリカバリできない
Redis5: Redis Stream
Amazon ElastiCacheのアップグレード方法
- Redis Clusterを新しいエンジンにアップグレードする
- 手動での変更・アプリケーションの変更は不要
- ElastiCache for Redis Version 3.2以上が対象
New: Amazon ElastiCache最適化インスタンス M5・R5
- インメモリの容量が9,5TiBまでスケールアップできる
- AWS Nitro System、専用ハードウェアと軽量ハイパーバイザでベアメタルと遜色ないパフォーマンスを提供
- Intel Xenonのカスタムプロセッサー、AVX-512対応で最大3.1GHz
New: 250ノードサポート
9.5TiBで足りない場合!
- 例1
- 想定: プライマリとレプリカでそれぞれ125シャード = 250node
- 想定: R5.24xlarge (635.61GiB)
- クラスタメモリ: 635.61GiB * 125 = 80TiB = ~88TB
- 例2
- 想定: プライマリのみで250シャード = 250node
- 想定: R5.24xlarge (635.61GiB)
- クラスタメモリ: 635.61GiB * 250 = 159TiB = 170TB
Coming Soon
- マルチコアノードのパフォーマンスブースト
- さらなる最適化でスループットを著しくブーストする
- コマンド名変更をサポート
- コマンドをリネーム可能に
- パッチ適用
- アップデートが起きたときの挙動を柔軟に
Redisの概要
- 高速
- ほとんどのコマンドが1ミリ秒以下
- インメモリのキーバリューストア
- オープンソース
- パワフル
- 200種類ぐらいのコマンド
- Luaスクリプト対応
- Geospatial
- Pub/Sub
- 学びやすい
- 高可用性
- レプリケーション
- 様々なデータ型
- アトミック操作
- バックアップ/リストア
- スナップショット化できる
Redisの自前管理は難しい
- 管理が大変
- ハードウェアの準備
- ソフトウェアのパッチ適用
- セットアップ
- 設定
- バックアップ
- 高可用性を保証しにくい
- Redisが落ちるとアプリケーションのパフォーマンスが低下する
- スケールさせにくい
- オンラインでのスケールはエラーを起こしやすい
- レプリケーションのパフォーマンス監視が必要
- 高価
- 人件費
- プロセス
- ハードウェア
- ソフトウェア
Amazon ElastiCache for Redisの紹介
- 究極のパフォーマンス
- インメモリデータストア
- ミリ秒以下のレスポンスのキャッシュ
- フルマネージド
- AWSが以下を管理
- ハードウェア
- ソフトウェアのセットアップ
- 設定
- 監視
- AWSが以下を管理
- 簡単にスケールする
- レプリカ
- シャーディングで書き込み性能・メモリ容量増加
- 信頼性
- マルチAZ
- ディープモニタリング
- 自動フェイルオーバー
- セキュアかつコンプライアンス準拠
- Amazon VPC
- HIPPA
- PCI
- FedRAMP
- 暗号化 (保存時・通信時)
- 認証
- Redis互換
- Redis5サポート
- Redisクライアント互換
Redisのユースケース
- キャッシュ
- リアルタイム分析
- ゲームのランキング
- Geospatial
- メディアストリーム
- セッションストア
- チャットアプリ
- メッセージキュー
- 機械学習
Redisクラスタモードが無効な場合 (垂直スケール)
Redisクラスタモード (水平スケール)
Redisクラスタモードの比較
クラスタモードが有効な場合のフェイルオーバー
ダウンタイム無し - オンラインリシャーディング (スケールアウト)
ダウンタイム無し - オンラインリシャーディング (スケールイン)
Amazon CloudWatchアラーム契機のリシャーディング
キャッシュ
リアルタイム: センチメント分析
リアルタイム: AWS IoT Core
リアルタイム: Amazon Kinesisのフィルタリング
モバイル
レート制限
グラフ&検索
キャッシュパターン
遅延読み込み
ResultSetをハッシュ化
Amazon S3 - Redis Write Back
Redisのmax-memoryポリシー
クラスタサイズのベストプラクティス
- ストレージ
- 必要なメモリ量に加えて25%リザーブしておく
- データ増加に備えて10%リザーブしておく (任意)
- EvictionポリシーとTTLで最適化する
- CloudWatchアラームで最大メモリサイズに到達する前にスケールアップ/スケールアウトする
- コスト効率のためメモリ最適化インスタンスを使う (R5も対応してる)
- 必要なメモリ量に加えて25%リザーブしておく
- パフォーマンス
- Redis Benchmark toolで各操作のベンチマークをとる
- リードIOPSが必要な場合
- レプリカを追加
- ライトIOPSが必要な場合
- シャードを追加 (スケールアウト)
- ネットワークIOが必要な場合
- ネットワーク最適化インスタンスを使う
- スケールアウトする
- リードIOPSが必要な場合
- 一括リード/ライトはパイプライン化する
- データ構造のコマンド実行時はBig(O)問題を考える
- Redis Benchmark toolで各操作のベンチマークをとる
- クラスタ独立性
- ワークロード・実行環境に必要な独立性の種類を明確にする
- 独立性なし: $
- 目的ごとに独立: $$$
- フル独立: $$$
- ワークロード・実行環境に必要な独立性の種類を明確にする
おわりに
私のプロジェクトでもElastiCacheを使用していますが、決まった使い方しかしていなかったので他の使い方を知れてよかったです!メモリストアの特性を活かして課題を解決できるように活用していきたいですね。