【アップデート】Amazon ElastiCache for Valkey がデータ耐久性をサポートしました
ウィスキー、シガー、パイプをこよなく愛する大栗です。
Amazon ElastiCache for Valkey がデータ耐久性（Durability）をサポートしました。マイクロ秒の読み取りレイテンシを保ちながらデータ喪失を防げるようになり、キャッシュだけでなく永続的なデータストアとしても ElastiCache を使えるようになります。
ElastiCache の耐久性とは
これまで ElastiCache は、その名のとおりインメモリのキャッシュとして利用するのが基本でした。高速な反面、ノード障害などでデータが失われる可能性があるため、永続化したいデータは別のデータストアに持つのが定石でした。
今回サポートされた耐久性機能では、Multi-AZ トランザクションログにデータを永続化することで、インフラ障害時にもデータを保護できるようになります。このログによってデータベースの復旧と再起動が可能になります。読み取りレイテンシはマイクロ秒のまま維持されるため、キャッシュとしての速さを犠牲にせずにデータストアとしての信頼性を得られるのがポイントです。
AWS は本機能の想定ユースケースとして、以下のようなデータ喪失が許容されない用途を挙げています。
- RAGのナレッジベース
- AI エージェントの長期メモリ
- ワークフローの状態管理
- 決済のトークン化
- リアルタイム在庫管理
2 種類の耐久性オプション
耐久性には、書き込みの永続化タイミングが異なる 2 種類のオプションが用意されています。クラスター作成時にどちらかを選択します。
| 項目 | 同期書き込み（Synchronous） | 非同期書き込み（Asynchronous） |
|---|---|---|
| 読み取りレイテンシ | マイクロ秒 | マイクロ秒 |
| 書き込みレイテンシ | 1 桁ミリ秒 | マイクロ秒 |
| データ損失保証 | ゼロデータロス | 障害時に最大10秒分が失われる可能性 |
| 永続化のタイミング | クライアントへ応答する前に 少なくとも2つの AZ のトランザクショナルログへ永続化 | クライアントへ応答した後に非同期で永続化 |
| 追加コスト | あり（標準のノード時間料金の 18%） | なし |
データ喪失を一切許容できないワークロードには同期書き込みが、そうでない場合は非同期書き込みが推奨されています。同期書き込みは書き込みレイテンシがマイクロ秒から 1 桁ミリ秒に増えるものの、その代わりにゼロデータロスを実現できる、というトレードオフになっています。
非同期書き込みには一点注意があります。プライマリノードが Multi-AZ トランザクショナルログへ10秒以上書き込みを永続化できない状態になると、永続化能力が回復するまで 以降の書き込みコマンドを拒否 します。データの取りこぼしを最小限に抑えるための安全装置と理解しておくとよいでしょう。
整合性
耐久性オプションによって一貫性の挙動が変わるため、ここは正しく押さえておきたいところです。
| 観点 | 同期書き込み | 非同期書き込み |
|---|---|---|
| プライマリの読み取り | 強整合性 | 通常時は強整合性 |
| フェイルオーバーをまたいだ強整合 | 保持される | 保持されない（最大10秒分が失われる可能性） |
| レプリカの読み取り | 結果整合性 | 結果整合性 |
同期書き込みでは、書き込みが成功した時点でトランザクショナルログに永続化されているため、プライマリノードは強整合性です。プライマリへの読み取りは常に直前までの全ての成功した書き込みを反映した最新データを返し、この強整合性はプライマリのフェイルオーバーをまたいでも維持されます。一方、レプリカノード（READONLY コマンド）は結果整合性で、最新の書き込みが反映されていない場合があります。レプリカラグのメトリクスは CloudWatch に発行されます。なお、単一レプリカからの読み取りは逐次一貫性であり、書き込みはプライマリで実行された順序どおりに各レプリカへ反映されます。
非同期書き込みは、通常は同期書き込みと強整合性を提供しますが、書き込みがログへ永続化される前にクライアントへレスポンスを返すため、フェイルオーバーをまたいだ強整合性は保証されません。障害時には確認済み書き込みのうち最大10秒分が失われる可能性があり、フェイルオーバー後の新しいプライマリへの読み取りに、それまで確認済みだった書き込みが反映されないことがあります。強整合性が必要なワークロードに非同期書き込みは推奨されていません。
パフォーマンス
AWSでは valkey-benchmark を使用してベンチマークを行っています。各クラスターは、r7g.4xlarge で 1 つのプライマリノードと 1 つのリードレプリカで構成されて、耐久性無し、同期書き込み、非同期書き込みの各パターンを 50K TPS と 100K TPS の負荷を与えています。
全体として Read のレイテンシはマイクロ秒単位となっています。10K TPS の高負荷時には同期書き込みの場合に Read レイテンシが高くなっていますがマイクロ秒のレベルです。Write は耐久性無し、非同期書き込みともにマイクロ秒単位のレイテンシで、同期書き込みは 1 桁ミリ秒のレイテンシになっています。
| ワークロード (80% read, 20% write) | ElastiCache オプション | ノードタイプ | Read P50 | Read P90 | Write P50 | Write P90 |
|---|---|---|---|---|---|---|
| 50K TPS | 耐久性無し | r7g.4xlarge | 260 µs | 301 µs | 147 µs | 185 µs |
| 50K TPS | 非同期書き込み | r7g.4xlarge | 245 µs | 289 µs | 112 µs | 152 µs |
| 50K TPS | 同期書き込み | r7g.4xlarge | 245 µs | 288 µs | 2.15 ms | 2.36 ms |
| 100K TPS | 耐久性無し | r7g.4xlarge | 263 µs | 301 µs | 160 µs | 196 µs |
| 100K TPS | 非同期書き込み | r7g.4xlarge | 245 µs | 286 µs | 128 µs | 158 µs |
| 100K TPS | 同期書き込み | r7g.4xlarge | 879 µs | 992 µs | 2.72 ms | 3.12 ms |
料金
非同期書き込みは追加コストなしで利用できます。同期書き込みには標準のノード時間料金の 18% の追加コストが発生します。
制限事項
利用にあたっての制限事項が複数あります。設計時に確認しておきましょう。
- Valkey 9.0 以降でサポートされています。
- インスタンスタイプは R7g、R6g、M7g、M6g、C7gn ファミリーがサポートされています。
- クラスター作成時のみ有効化可能。作成後に同期/非同期の切り替えは可能。一度有効にした耐久性を無効化できません。既存の耐久性が無効のクラスターへの後付けも不可。
- ElastiCache Serverlessでは、耐久性はサポートされていません。
- Global Datastore、Outposts、Local Zones、データ階層化はサポートされていません。
- プライマリノードあたり最大 100 MiBps の書き込みスループットをサポートします。
- クラスターモードが無効なクラスターはサポートされていません。
- マルチ AZ を有効にしてシャードごとに少なくとも 1 個のレプリカを設定する必要があります。
- 保存時暗号化が必須で自動的に有効化されます。またクラスター作成時に転送時暗号化が有効化されている必要があります。
- セルフホストの Valkey / Redis OSS から耐久性クラスターへのオンライン移行はサポートされていません。
- 耐久性が有効かつ検索インデックスを構成している場合、トランザクショナルログの性能維持のため、インデックス対象キーへの書き込みコマンドがスロットリングされることがあります。
- スロットリング時は拒否されるのではなく遅延します。
やってみる
実際にマネジメントコンソールから耐久性を有効にしたクラスターを作成してみます。ここでは耐久性の設定に関わる箇所を中心にコンソール操作の流れをご紹介します。
Valkey caches のコンソールで Create cache をクリックします。
Settings の Configuration で Engine に Valkey を、Deployment option で Node-base cluster を、Creatin method で Cluster cache を選択します。
Cluster mode は Enables を選択して Name に任意の名称を記述します。
Location は AWS Cloud で、Multi-AZ で Enable にチェックを入れます。
Engine version で 9.0 を、Node type は R7g、R6g、M7g、M6g、C7gn ファミリーのノードを選択します。ここでは cache.r7g.large を選択しました。
Data durability で Advanced を選択して、Durability options で耐久性を選択します。ここでは Synchronous writes （同期書き込み）を選択しました。Replicas per shard で 1 以上を選択します。ここでは 2 を選択しました。
ネットワークに関する設定を行います。
配置に関する設定を行い Next をクリックします。
Encryption at rest で Enable を有効にして、Encryption at transit で Enable を有効にします。
アクセス管理とセキュリティグループを設定します。
バックアップを設定します。
メンテナンスを設定します。
ログを設定します。ここではスローログとエンジンログを CloudWatch Logs へ出力しています。
必要に応じてタグを設定して Next をクリックします。
数分待つとクラスターが起動します。
耐久性が同期書き込みになっています。
起動したクラスターは耐久性について同期書き込みか非同期書き込みかの選択のみ可能です。
さいごに
ElastiCache の耐久性サポートにより、これまで高速だがデータは消える可能性のあるキャッシュという位置づけだった ElastiCache を、マイクロ秒の読み取りレイテンシを保ったままデータストアとしても使えるようになりました。同期書き込みでデータ損失無しを取るか、非同期書き込みで速度とコストを取るかをワークロードに応じて選べる柔軟さも嬉しいです。
一方で、クラスター作成時にしか有効化できず後から無効化できないこと、Cluster Mode Disabled や Serverless が非対応であることなど、設計時に押さえておくべき制限もあります。新規にクラスターを設計する段階で、耐久性を使うかどうかをあらかじめ決めておくのがよさそうです。
AI エージェントのメモリや RAG の知識ベースといった、低レイテンシと耐久性の両方が求められる用途が増えている中で、まさに時代に合ったアップデートだと思います。データ損失がないため、クリティカルな要件にも適用可能になるので適切なワークロードがあれば、ドンドン使って行きたいですね。
