refirio.org

■サーバが重い・サーバに繋がらない 18

この度はお問い合わせ頂き、誠にありがとうございます。 >・突然、２日連続して再起動したのが気になるのですが、そちら側で、なにか原因的なものは判るでしょうか ご不便をお掛けし、申し訳ございません。 当該ノードが稼働している仮想サーバホストにおいて、断続的に短い時間の問題が生じていたことを確認致しました。 ElastiCache によって問題が検知され、ノードの置き換えが実施されましたが、いずれも短い時間の問題であったため、置き換えが完了する前にノードの正常性が戻っておりました。 対応としまして、お手数ではございますがノードの置き換えをご検討頂けないでしょうか。 当該ノードについては調査の上で対応を検討して参りますが、短い期間で何度も事象が発生しており、今後も同様の事象が発生する可能性がございます。 対応手順としては、クラスターにレプリカを追加し、プライマリへのフェイルオーバを行っていただけると、よろしいかと存じます。その他の手順としては、クラスターを削除して新規に作成する対応になってしまいますが、ご検討頂けますでしょうか。 以下、関連するドキュメントに説明や手順がございますので、ご案内いたします。後者については、テスト、との記載がございますが、実際にフェイルオーバさせることが可能でございますので、ご安心くださいませ。 - クラスターへのノードの追加 - Redis 用 Amazon ElastiCache https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/Clusters.AddNode.html - ダウンタイムの最小化: 自動フェイルオーバーでのマルチ AZ - Redis 用 Amazon ElastiCache https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/AutoFailover.html#auto-failover-te... >・当方ですが、Redisでセッション情報の管理を行っているため、こちらにアクセスできなくなるとサービスに支障が出るのですが、停止時間を短くするための構成はあるのでしょうか ベストプラクティスとしては、複数ノードによる自動フェイルオーバーの有効化をご案内させていただいております。 - 障害の軽減 - Redis 用 Amazon ElastiCache https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/red-ug/FaultTolerance.html#FaultTolerance... (抜粋) 障害の影響を最小限に抑える ノードの障害の影響を最小限に抑えるために、各シャードに複数のノードを実装して、複数のアベイラビリティーゾーンにノードを分散することをお勧めします。 Redis を実行している場合は、レプリケーショングループでマルチ AZ を有効にして、プライマリノードで障害が発生すると ElastiCache が自動的にレプリカにフェイルオーバーを実行するようにしておくことをお勧めします。 また、より新しいバージョンにおけるバグ修正やパフォーマンスの安定性から考え、新しいエンジンバージョンを使っていただくことも、あわせてお勧め致します。 >Redisのパラメータグループを確認したところ、timeoutの設定値が「0」になっていましたが、このあたりの影響もあるのでしょうか いいえ、今回の事象につきましては、コネクション数の多寡によって発生したものではございませんでした。 また、アプリケーションによってコネクションが正しくハンドリングされていれば、タイムアウトに関する設定について、考慮頂く必要は無いと認識しております。 以下は Redis 公式のドキュメントであり、AWS が提供する資料ではございませんが、参考情報としてご覧くださいませ。 - Redis Clients Handling - Redis https://redis.io/topics/clients (抜粋) - Mission critical applications where a bug in the client software may saturate the Redis server with idle connections, causing service disruption. 他にご不明な点がございましたらお問い合わせ頂ければ幸いです。 どうぞよろしくお願いいたします。