Amazon Web Services ブログ
Amazon ElastiCache を Redis 向けに設定して可用性を高める
現在、Amazon ElastiCache という名前は、リアルタイムアプリケーションと同義に捉えられるようになりました。Redis の性能の高さ、シンプルさ、そして多様なデータ構造へのサポートは、非リレーショナルのキー値ストアとしては、最も人気のあるものの 1 つです。ビジネスに不可欠なリアルタイムのユースケースが Redis 上で増加する中で、可用性の保証は重要な課題となってきています。
高い可用性を実現するため、Redis 用 Amazon ElastiCache では Redis クラスターの設定をサポートし、すぐれたスケーラビリティと可用性を提供します。加えて Amazon ElastiCache では、自動フェイルオーバー機能を持つ複数のアベイラビリティゾーン (Multi-AZ) も提供しており、クラスターがゾーン間で 1 つ以上の複製を作る設定も可能です。主要ノード上で障害イベントが発生しても、Redis 用 Amazon ElastiCache では自動的に複製に対しフェイルオーバーが行われるので、高い可用性が保証されます。
最近、Redis 用 Amazon ElastiCache から、Redis アプリケーションのエンドツーエンドな可用性を向上させるための、いくつかの発表を行いました。
- 「Amazon ElastiCache for Redis で計画されたメンテナンス中のクラスター可用性が向上」は、自動フェイルオーバーを有効化したクラスターの、パッチ適用、更新、その他メインテナンス関連処理など、ノード置換が関係する作業中における可用性を高めるものです。Redis クラスター設定のセットアップには、Redis Cluster クライアントが使えます。これにより、予定したメインテナンスやノード置換も、書き込み中断をまったく生じずに完了します。非 Redis クラスター (非シャード) 設定では、DNS の更新時に最大で数秒間の短い書き込み中断が生じることがあります。
- 「Amazon ElastiCache for Redis がセルフサービスアップデートに対応開始」は、メインテナンスのための更新を開始するタイミングを制御することで、その作業の影響を最小化するものです。
- 「Amazon ElastiCache Redis にリーダーエンドポイントを開始」は、個別レプリカエンドポイントの変更点を管理する必要がなく、読込みトラフィックの接続を可能にするものです。これにより、アプリケーションが個別ノードエンドポイントの変更点を管理する必要性がなくなり、可用性を向上させます。この機能は、Redis クラスター設定に対しては、すでにRedis クラスタースマートクライアントで一般的に実現されています。
- 「Amazon ElastiCache for Redis で Redis 5.0.3 のサポートを追加、Redis コマンド名の変更が可能に」は、再起動の必要性や可用性への影響は一切ないまま、オンラインで Redis コマンド名の変更を可能にします。
これらの改善点と全体的な可用性から最大の効果を発揮させるため、ご自身の設定内容が最も高い性能が提供できるようになっているか再確認してください。次のセクションでは、Redis 用 Amazon ElastiCache クラスターや、Redis クライアントの設定に関する一連のベストプラクティスと共に、可用性向上のための一般的なアプリケーション向けヒント集をご紹介していきます。
Redis 用 Amazon ElastiCache の設定
Redis 用 Amazon ElastiCache の設定は、適切なノードタイプ、Redis 設定 (Redis および、非 Redis のクラスター) 、レプリカの数、および他のオプトイン機能を選択することで行います。まず最初に、ご自身の Redis 用 Amazon ElastiCache クラスター設定を確認してください。
- Multi-AZ で自動フェイルオーバーを有効にする: これは、プライマリーノードがレプリカに対し自動フェイルオーバーを行うことで、予定の有無に関係なくメインテナンスでのダウンタイムを、Multi-AZ が最小化することを可能にします。詳細については、「Multi-AZ で自動フェイルオーバーを有効にする」をご参照ください。
- 3 シャード Redis クラスター: これは、予定のあるなし両方の場合のフェイルオーバー時に高速のリカバリーを行うことで、最小限の 3 シャードの可用性を向上させるものです。
- アベイラビリティゾーン間で 2 つ以上のレプリカを設定する: 2 つのレプリカが存在することで、片方のレプリカでメインテナンスが行われているというシナリオで、読み取りのスケーラビリティおよび読み取りの可用性を向上させます。この機能は、シングルリーダーエンドポイントを使用しておらず、読み取りリクエストを読み取りレプリカのみへ向けるよう選択 (クライアント設定) している場合には重要です。
- Nitro システムベースのノードタイプを使用する: これらの (R5 と M5 を含めた) ノードタイプでは、進んだ Nitro システムからのメリットが得られます。その機能は、ベアメタルと強化されたネットワーク処理の双方から区別なく提供されます。また、Redis 用 Amazon ElastiCache には、これらのノード向けにさらに最適化された機能があります。その結果、レプリカ作成と同期の性能が向上し、全体の可用性が改善されることになります。詳細については、以前のブログ記事をご参照ください。
- 想定したトラフィックのピークを処理するため監視と適正サイズ化を行う: 重い負荷がかかると Redis のエンジンが反応しなくなり、可用性に影響を及ぼします。
BytesUsedForCacheは, メモリ使用量を表示するのに便利です。一方、ReplicationLagでは、書き込み速度を基にレプリカ作成の状況を表示します。これらのメトリクスは、クラスタースケーリングのトリガーに使用できます。監視とサイズ変更に関する詳細は、「Redis のメトリクス」「予約メモリの管理」「ノードサイズの選択」をご参照ください。 - メインテナンスと更新を 処理のピーク時に行わない: 書き込みの負荷を下げることでフェイルオーバーを容易にし、アプリケーションへの影響を最小にできます。
Redis クライアントの設定
Redis では、お好みに応じてクライアントを選択できる、柔軟性を持つ堅牢なエコシステムを提供しています。次の一覧は、ほとんどのクライアントで適用できる一般的なガイドを示しています。
- Redis クラスターのモード: クラスターアウェアな Redis クライアントを使用し、設定エンドポイントを使ってクラスターに接続します。これにより、クライアントがシャードおよびスロットのマッピングを、自動検出できるようになります。Redis クラスターモードでは、他にクラスターのリサイズのためにオンラインのリシャーディング (スケールインおよびアウト) も提供しており、予定されたメインテナンスとノード置換を、書き込み中断をまったく生じさせないで完了することができます。Redis クラスタークライアントはプライマリーとレプリカ両方のノードを検出し、クライアントで指定した読み取りおよび書き込みのトラフィックを適切に送出します。
- 非Redis クラスターモード: すべての書き込みトラフィックにプライマリーエンドポイントを使います。すべての設定変更およびフェイルオーバー時に、Amazon ElastiCache は、プライマリエンドポイントの DNS が、必ずプライマリノードをさすように変更します。読み込みエンドポイントを、すべての読みだしトラフィックに向けるAmazon ElastiCache では、レプリカが追加もしくは削除される際には必ず、読み込みエンドポイントにクラスターの変更点をアップデートさせます。個別ノードエンドポイントの使用も可能ですが、読み込みエンドポイントを使うことで、アプリケーションを各ノードエンドポイントの変更確認の処理から解放できます。つまり、プライマリエンドポイントは書き込みに、シングルリーダーエンドポイントは読み出しに使用するのが、最も有効です。
- ソケットタイムアウト:クライアントのソケットタイムアウトは、 (一部クライアントで標準的なデフォルト値 none ではなく ) 最低でも 1 秒間に設定します。タイムアウト値を低く設定しすぎると、負荷が高い時にサーバーが頻繁にタイムアウトを引き起こすことにつながります。この値を高く設定しすぎると、接続上の問題をアプリケーションが検知する時間が長くなります。
- DNS キャッシング: クライアントが DNS キャッシング機構を内臓している場合は、TTL を低く (5～10秒)することを推奨します。TTL をこれより高くすると、アプリケーションが所望のノードに接続しない危険性が生じます。また、「cache forever」のオプションも使わないようにします。
アプリケーションのベストプラクティス
Redis 用 Amazon ElastiCache クラスターおよび Redis クライアントの設定に加え、アプリケーションのロジックが、次のヒント集および一般的なベストプラクティスに沿っているか、確認することも有益です。
- LUA スクリプトを長時間実行させないようにする: Redis エンジンが応答しなくなり可用性に影響をおよぼします。LUA スクリプトの使用が必須である場合は、CPU 処理量のスパイクに合わせ適切なサイジングを行います。
- 削除より有効期限の使用を検討する: 計算上、削除ポリシーは有効期限よりコストがかかります。メモリ量への懸念を少なくするために、キー上で有効期限の使用を検討してください。
- コストのかかるコマンドを使用しない: KEYS のようなコストのかかるコマンドはパフォーマンスの低下をもたらし、クラスター上の管理された処理を妨害します。この代替手段としては、SCAN コマンドを使用します。これにより、リニア時間ではなく完全な一定時間での処理が行えます。同様に、Sorted Sets の大きなオブジェクトもしくは Hash のデータタイプでは、同期に問題を引き起こし、メインテナンスや更新といった管理された処理に影響をあたえることがあります。
コストのかかるコマンドを想定外に使用することを防ぐためには、Redis コマンド名の動的変更を検討してください。Amazon ElastiCache では、Redis コマンド名の変更を、クラスターがオンライン状態でも再起動をまったく必要とせずに実行できます。詳細については、「Redis 用 Amazon ElastiCache バージョン 5.0.3 (Enhanced)」をご参照ください。
まとめ
当社は、これらの新機能と改善項目を、お客様にご紹介できることを嬉しくおもっております。しかも、これはほんの第一歩です。当社では、システムのエンドツーエンドの可用性を、改善する努力を続けてまいります。ベストプラクティスなど、今後の更新にもご期待ください。Redis 用 Amazon ElastiCache の使用開始は、Amazon ElastiCache コンソールから行ってください。
著者について
Ruchita Arora は、Amazon ElastiCache のシニアプロダクトマネージャーで、本サービスのすべての側面について深く関わっています。彼女は、データベースの他に、ストレージ、エンタープライズアプリケーション開発、さらにテレコミュニケーション領域において、技術と製品管理に関するいくつもの仕事をしています。
Nirmal George Eapen は Amazon ElastiCache のソフトウェア開発エンジニアです。