この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Amazon ElastiCache Redis の各パラメータについてまとめてみた
おはようございます､加藤です｡Amazon ElastiCacheのRedisを利用する際に､どのように設計・設定すれば良いのかをまとめてみました｡
Redisとは
RedisはOSSのインメモリ型キーバリューストアです｡
ちなみに名称はREmote DIctionary Server の略語です｡
Redisを扱うのが初めての方はまず下記のリンク先を読むことをおすすめします｡
Redis とは? - Amazon ElastiCache（キャッシュ管理・操作）| AWS
ElastiCache for Redisとは
AWSによって提供されるマネージドなRedisです｡Redisを使用してる既存のアプリケーションならばほとんど変更なしに移行することが可能です｡
- キャッシュノードの障害の自動検出と復旧。
- 障害が発生したプライマリクラスターの、レプリケーションをサポートする Redis クラスター内のリードレプリカへの自動フェイルオーバーを備えたマルチ AZ。
- Redis (クラスターモードが有効) では、最大 15 個のシャード間でのデータの分割がサポートされています。
- Redis バージョン 3.2.6 は、認証での伝送中と保管時の暗号化をサポートするので、HIPAA に準拠したアプリケーションを作成できます。
- 耐障害性向上のためのノードとクラスターのアベイラビリティーゾーンの柔軟な配置。
- さらに、他の AWS のサービス (Amazon EC2、Amazon CloudWatch、AWS CloudTrail、Amazon SNS など) とも連携した、安全でパフォーマンスの高い管理対象インメモリキャッシュソリューション。
Redis 用 Amazon ElastiCache とは - Redis 用 Amazon ElastiCache
いきなりですが､まずは下記の図を頭に入れておいてください｡ElastiCache for Redisを構成する場合は､この4パターンのいずれかになります｡それぞれの用途についてはこれから説明していきます｡
括弧内の表記はAPI/CLIで操作する場合の名称です､反対に括弧外はコンソールの場合です｡
やってみた
ElastiCache Redis の作成
- Amazon ElastiCache コンソソールを開きます
- メニューから Redis を選択します
- 作成をクリックすることで Redis の作成を開始できます
ElastiCache Management Console
クラスター・シャード
クラスターエンジンの選択
Redisの設定
※枠部分はクラスターモード有効の場合のみ表示されます
クラスターモードを有効化することでデータのパーティション化ができます｡この為､書き込みもシャーディングが行える様になります｡
クラスターモードが有効の場合は1〜15個のシャードを構成できます｡(書き込みを最大15分割できます)
正確にはクラスターモードが有効/無効というのは厳密にはキャッシュエンジンが異なるということです｡クラスターモードが有効であったとしてもシャード数が1ならば書き込みのシャーディングは行われません｡
シャード数の変更はダウンタイム無しのオンラインで行う事が可能ですが､クラスターモードは作成後変更できません｡再作成する必要があります｡
クラスターモードを使用するメリットを考えてみましょう｡
- シャード数の増減でオンラインかつ柔軟にスケールイン・アウトができる
- 書き込み負荷に対してスケールアウト(分散)で対応できる
- 読み込み負荷に対してより多くスケールアウトで対応できる
- シャード当りのリードレプリカは最大5個
- クラスターモード有効の場合は最大5*15=75個(同一のReplicationは5個まで)
- クラスターモード無効の場合は最大5*1 = 5個
- Redisに障害が発生した際にオリジンへのアクセス負荷を抑えたい1
クラスターモードを使用する場合の注意事項は下記の通りです｡
- サポートされるのはRedis 3.2 以降のみ
- ノードタイプ(インスタンスタイプ・サイズ)変更のダウンタイムが比較的長い・手間がかかる2
- スナップショット経由で再作成する
- エンドポイントが変更になりアプリケーションの対応が必要
- マルチAZ自動フェイルオーバーの設定が強制される
- 後述する Append-only file による永続化が行えない
- 任意のレプリカを 手動で昇格させることができない
- 手動フェイルオーバーは行えるが昇格対象のレプリカを指定できない
クラスター作成後の変更画面
レプリケーション
シャード当り0〜5個のレプリカを作成することができます｡レプリカはプライマリから非同期書き込みでレプリケーションされる､読み込み専用のノードです｡
レプリケーション数の変更はダウンタイム無しのオンラインで行う事が可能です｡
自動フェイルオーバーが有効な場合はプライマリに障害が発生するとフェイルオーバー動作でレプリカがプライマリに昇格します｡その後プライマリはレプリカとして､再作成され昇格済みの新プライマリから再同期されます｡
レプリケーションのメリットは下記の通りです｡
- レプリカ数の増減でオンラインかつ柔軟にスケールイン・アウトができる
- 読み込み負荷に対して有効な対応がとれる
- HotStandbyとして動作し可用性が向上する
プライマリに障害が発生した場合はレプリカがプライマリに昇格します｡レプリケーションは非同期で行われます。その為、プライマリがレプリカにフェイルオーバーすると、遅延の為に少量のデータが失われる可能性があります。
エンジンバージョン
ここは利用するアプリケーションの要件を確認し､設定しましょう｡
クラスターモードを有効にする場合はRedis 3.2 以降である必要があるので注意してください｡
ポート
デフォルトで6379です｡基本的には変更する必要はありませんが､何らかの理由がある場合は変更してください｡
パラメータグループ
こちらもアプリケーションの要件を確認し､設定しましょう｡
Append-only file(AOF)
Redisにはデータ永続化の手段として Append-only file という機能があります｡
これは､サーバーが受け付けたすべての書き込みコマンドを記録し､起動時にログをリプレイし、元のデータを再構成してくれます｡
これを設定したい場合はパラメータグループで設定します｡ただし下記の公式ドキュメントで､ データ消失に備えたい場合は､AOFではなくマルチAZのレプリカ構成を選択することを推奨されています｡
ElastiCache for Redis では原則AOFの利用は避けたほうが良いでしょう｡
Redis AOF 使用時のディスク容量不足の問題の緩和 - Redis 用 Amazon ElastiCache
ノードタイプ
ノードタイプ一覧です｡
| キャッシュノードタイプ | vCPU | メモリ (GiB) | ネットワークパフォーマンス |
|---|---|---|---|
| cache.t2.micro | 1 | 0.555 | 低～中 |
| cache.t2.small | 1 | 1.55 | 低～中 |
| cache.t2.medium | 2 | 3.22 | 低～中 |
| cache.m3.medium | 1 | 2.78 | 中 |
| cache.m3.large | 2 | 6.05 | 中 |
| cache.m3.xlarge | 4 | 13.3 | 高 |
| cache.m3.2xlarge | 8 | 27.9 | 高 |
| cache.m4.large | 2 | 6.42 | 中 |
| cache.m4.xlarge | 4 | 14.28 | 高 |
| cache.m4.2xlarge | 8 | 29.70 | 高 |
| cache.m4.4xlarge | 16 | 60.78 | 高 |
| cache.m4.10xlarge | 40 | 154.64 | 10 ギガビット |
| cache.r3.large | 2 | 13.5 | 中 |
| cache.r3.xlarge | 4 | 28.4 | 中 |
| cache.r3.2xlarge | 8 | 58.2 | 高 |
| cache.r3.4xlarge | 16 | 118 | 高 |
| cache.r3.8xlarge | 32 | 237 | 10 ギガビット |
| cache.r4.large | 2 | 12.3 | 最大 10 ギガビット |
| cache.r4.xlarge | 4 | 25.05 | 最大 10 ギガビット |
| cache.r4.2xlarge | 8 | 50.47 | 最大 10 ギガビット |
| cache.r4.4xlarge | 16 | 101.38 | 最大 10 ギガビット |
| cache.r4.8xlarge | 32 | 203.26 | 10 ギガビvット |
| cache.r4.16xlarge | 64 | 407 | 25 ギガビット |
ノードタイプの変更はクラスターモード有効・無効ともにダウンタイムありのオフラインで行う必要があります｡有効の場合は手動バックアップを作成し､それを経由して新規作成する必要があります｡無効の場合は再起動を伴います､この再起動は即時かメンテナンスウィンドウ中で行うか選択ができます｡
自動フェイルオーバーを備えたマルチAZ
通常､メンテナンスや、プライマリノードまたはAZ障害などが発生すると､プライマリノードを再作成します｡この間、ダウンタイムが発生します。
自動フェイルオーバーを備えたマルチAZ を有効にしておくと、プライマリノードに障害が発生した場合､プライマリーノードの役割はリードレプリカの1つにフェイルオーバー(レプリカの昇格)されます｡
新しいプライマリノードを作成してプロビジョニングする必要がないので、ダウンタイムが最小限になります。この障害検出とレプリカの昇格により、昇格が完了したらすぐに新しいプライマリへの書き込みを再開できます。通常、フェイルオーバーの完了までには数分しかかかりません。
実際のシチュエーションをあげて自動フェイルオーバーの動作を説明します｡
プライマリノードにのみ障害が発生した場合
- プライマリーノードの障害を検知しオフラインに移行する
- レプリケーションの遅延が最短(最も最新のデータが記録されている)の使用可能なリードレプリカがプライマリノードに昇格する
- プライマリエンドポイントの解決先が昇格されたレプリカのDNS名に書き換わる
- 元プライマリーノードが存在したAZにリードレプリカが起動し新プライマリーノードと同期する
リードエンドポイント(各リードレプリカのエンドポイント)変更はアプリケーションに通知されません｡アプリケーション側で変更が必要です｡
ダウンタイムの最小化: 自動フェイルオーバーでのマルチ AZ - Redis 用 Amazon ElastiCache
プライマリノードといくつかのリードレプリカで障害が発生した場合
- プライマリノードとリードレプリカの障害を検知し､オフラインに移行する
- レプリケーションの遅延が最短の使用可能なリードレプリカがプライマリノードに昇格する
- プライマリエンドポイントの解決先が昇格されたレプリカのDNS名に書き換わる
- 障害が発生したノードが存在したAZにリードレプリカが起動し新プライマリーノードと同期する
リードエンドポイント(各リードレプリカのエンドポイント)変更はアプリケーションに通知されません｡アプリケーション側で変更が必要です｡
クラスター全体に障害が発生した場合
- プライマリノードとリードレプリカの障害を検知し､オフラインに移行する
- プライマリノードを再作成し起動する
- 障害が発生したノードが存在したAZにリードレプリカが起動し新プライマリーノードと同期する
クラスター全体に障害が発生した為、データが失われます
全てのエンドポイントは変更されません､アプリケーション側で変更する必要はありません｡
個人的な感想
Elasticache for Redis についてブログドリブンで勉強してみました｡
基本的にクラスターモード有効でシャード1レプリカ2〜3ぐらいで作成して､負荷に応じてシャード,レプリカスケールアウトすれば良さそう｡この場合はノードサイズの変更ができないことに注意する｡
完全永続性を要求する使用はせず､必要ならばアプリケーション側でRDSやDynamoDBへ保存する様に実装した方が良いと思いました､非同期レプリケーションなのでフェイルオーバー時に多少のデータロストは考慮しなくてはいけません｡これは､耐障害を考慮しなくて良いということではありません､ Redisが使用不可 = オリジンのアクセス負荷が上がる なので､障害の影響が最小限に抑えられる設計は必要です｡
本当はサイジングについても書きたかったのですが､その為にはRedisについてもっと深い知識が必要だと気づき今回は断念しました｡
以上です!
16
