redis serverのベストEC2セットアップ

Question

データストアとしてredisのみを使用する大規模Webアプリケーションを展開しています。私たちのレディスマスターのベンチマークはEC2の約8000トランザクション/秒であり、専用ハードウェアの規定されたベンチマークよりもはるかに少ないことに気付きました。

私は、EC2のような仮想マシンでRedisを実行するとパフォーマンスが低下することを理解していますが、EC2の実稼働環境にRedisを配備した人から、赤ちゃんのうちより多くの

ありがとうございました。

Answer 1

EC2はおそらく仮想化ハードウェアでRedisを実行するのに最適な環境ではありませんが、一般的なものです。このプラットフォームでRedisからベストを得るために知るべき点がいくつかあります。

私はhttp://redis.io/topics/benchmarksとhttp://redis.io/topics/latencyの著者の一人で、以下に示すほとんどのトピックをカバーしています。これは主なポイントの要約です。

仮想化トール

これはEC2に対して特異的ではないが、（サポートされる最大スループットの用語で）VM上で実行するときのRedisが著しく遅いです。これは基本的な操作のためですが、Redisは、memcachedや他の効率的なキー/バリューストアなどのクライアント接続を処理するために必要なepoll/read/writeシステムコールにオーバーヘッドをあまり加えません。システムコールは通常、VM上ではより高価で、Redisアクティビティ（特にベンチマーク）の重要な部分を占めています。この条件では、ベアメタルと比較して最大スループットの点で50％の減少が珍しいことではありません。

もちろん、ハイパーバイザーの品質によっても異なります。 EC2では、Xenが使用されます。良い条件

で

ベンチマークは、ベンチマークは、特にEC2のようなプラットフォーム上で、注意が必要です。よく忘れられる1つの点は、ベンチマーククライアントとサーバーの両方に対して適切な構成を確保することです。たとえば、Redisサーバーをターゲットにしている間、CPUが不足しているマイクロインスタンス（おそらくAmazonによって抑制される）上でredis-benchmarkを実行しないでください。両方のマシンが同じ最大スループットを得るために重要です。あなたは1つの仮想CPUコアよりも多くを持っていると仮定すると、（サーバーと同じマシン上で）ローカルに

• が実行Redisのベンチマーク：

  は実際には、Redisの性能を評価するために、あなたがする必要があります。

• 実行Redisのベンチマーク（別のVMからの）遠隔操作、QoSの設定

だから、あなたが評価し、マシンやネットワークのパフォーマンスを比較することができ、サーバ・マシンと同等であるマシン上で。

EC2では、より低速な準仮想化に頼るのではなく、HVM（ハードウェア仮想化）を利用できるように、第2世代のM3インスタンス（またはハイパフォーマンスコンピューティングまたはクラスタコンピューティングインスタンス）で最良の結果を得られます。

フォーク問題

これはEC2に特有のものではなく、Xenのに：大規模なプロセスをフォークすることはXenの上で本当に遅くなることがあります（それは、KVMで良く見えます）。 Redisの場合、これは永続性を使用する予定の場合、大きな問題です。永続性オプション（RDBまたはAOF）では、メインスレッドがフォークしてバックグラウンドの保存または再書き込みプロセスを起動する必要があります。

フォークレイテンシによって、Redisイベントループが数秒間フリーズすることがあります。 Redisインスタンスによって管理されるメモリが多いほど、レイテンシが増えます。

EC2では、必ずHVM対応インスタンス（M3、ハイメモリ、クラスタ）を使用してください。問題が緩和されます。

大きなメモリ要件があり、アプリケーションがそれを許容できる場合は、同じマシンで複数の小さなRedisインスタンスを実行し、データを分割することを検討してください。これは、フォーク動作による待ち時間を許容可能なレベルまで減少させることができる。

永続構成

これはRedisの（両方のVMおよびベアメタル上）から良好なパフォーマンスを得るために重要なポイントです。したがって、注意深く読む時間を取ってくださいhttp://redis.io/topics/persistence

RDBを使用している場合、メモリコピーオンライトメカニズムは、バックグラウンドプロセスの保存が中断されるとページの複製を開始することに注意してください。したがって、Redis自体に十分なメモリがあることと、COWに対処するための余裕があることを確認する必要があります。余分なメモリの量は作業負荷によって異なります。インスタンスに書くほど、余分なメモリが必要になります。

ファイルを書き込む際には（ファイルシステムのキャッシュのため）メモリを消費する可能性があるので、Redisバックグラウンドでの保存時にRedisメモリ、COWオーバーヘッド、およびダンプファイルのサイズを考慮する必要があります。

Redisサーバーを実行しているマシンは、決してスワップしてはなりません。そうした場合、結果は致命的なものになります。他の店舗とは異なり、Redisは仮想メモリに優しいものではありません。

Linuxの場合、vm.overcommit_memory = 1およびvm.swappiness = 0（または、とにかく非常に低い値）のシステムパラメータを設定してください。古いカーネルバージョンは使用しないでください。スワップが少なくて済みます（大きなファイルが書き込まれたときにスワップします）。

AOFを使用する場合は、fsyncオプションを確認してください。生の性能と書き込み操作の耐久性との間のトレードオフです。選択肢を作って戦略を定義する必要があります。

また、EC2ストレージオプションについても理解しておく必要があります。一部のVMでは、一時記憶域とEBSのどちらかを選択できます。他にもEBSしかありません。

エフェメラルストレージは一般的にEBSよりも問題は少なくなりますが、ディスク障害やホストの再起動などで簡単にデータを失う可能性があります。RDBスナップショットをエフェメラルストレージを使用して、パフォーマンスと堅牢性のトレードオフとして、結果のファイルをEBSディレクトリにコピーします。

EBSはリモートストレージです.VMに割り当てられた標準ネットワーク帯域幅を消費し、Redisの最大スループットに影響を与える可能性があります。 EBSを使用する予定の場合は、標準ネットワークとストレージリンク間にQoSを確立するために、「EBS最適化」オプションを選択することを検討してください。

最後に、EC2でパフォーマンスを要求するインスタンスの非常に一般的な設定は、マスターで永続性を無効にし、スレーブインスタンスでのみ有効にすることです。おそらくデータの安全性は低いですが、マスター上の潜在的な潜在的な問題の多くを防ぐかもしれません。