データ ストアとして redis のみを使用する大規模な Web アプリケーションをデプロイしています。私たちの redis マスターのベンチマークは、EC2 で毎秒約 8000 トランザクションであり、専用ハードウェアで規定されているベンチマークよりもはるかに少ないことに気付きました。
EC2 のような仮想マシンで Redis を実行するとパフォーマンスが低下することは理解していますが、EC2 の本番環境に Redis をデプロイした人から、redis を最大限に活用するために最も効果的であることがわかった EC2 セットアップについて、いくつかのヒントをいただければ幸いです。 .
ありがとう。
EC2 はおそらく、仮想化されたハードウェアで Redis を実行するのに最適な環境ではありませんが、人気のある環境であり、このプラットフォームで Redis を最大限に活用するために知っておくべき多くのポイントがあります。
私はhttp://redis.io/topics/benchmarksと http://redis.io/topics/latencyの作成者の 1 人であり、以下に示すトピックのほとんどをカバーしています。これは要点のみを要約したものです。
仮想化料金
これは EC2 に固有のものではありませんが、Redis は VM で実行すると (サポートされる最大スループットに関して) 大幅に遅くなります。これは、基本的な操作の事実によるものです。Redis は、クライアント接続 (memcached やその他の効率的なキー/値ストアなど) を処理するために必要な epoll/read/write システム コールにあまりオーバーヘッドを追加しません。通常、システム コールは VM でより高価であり、Redis アクティビティの重要な部分を占めています (特にベンチマークで)。そのような状況では、ベア メタルと比較して最大スループットが 50% 低下することは珍しくありません。
もちろん、ハイパーバイザーの品質にも依存します。EC2 では Xen を使用します。
良好な状態でのベンチマーク
特に EC2 のようなプラットフォームでは、ベンチマークは難しい場合があります。忘れがちなポイントの 1 つは、ベンチマーク クライアントとサーバーの両方を適切に構成することです。たとえば、Redis サーバーをターゲットにしている間は、CPU 不足のマイクロインスタンス (Amazon によって抑制される可能性が高い) で redis-benchmark を実行しないでください。優れた最大スループットを得るには、両方のマシンが等しく重要です。
実際、Redis のパフォーマンスを評価するには、次のことを行う必要があります。
複数の vCPU コアがあると仮定して、redis-benchmark をローカルで (サーバーと同じマシンで) 実行します。
QoS 設定がサーバー マシンと同等であるマシン上で、redis-benchmark をリモートで (別の VM から) 実行する
そのため、マシンとネットワークのパフォーマンスを評価および比較できます。
EC2 では、第 2 世代の M3 インスタンス (またはハイメモリまたはクラスター コンピューティング インスタンス) で最良の結果が得られるため、低速の準仮想化に依存する代わりに、HVM (ハードウェア仮想化) の利点を得ることができます。
フォークの問題
これは EC2 に固有のものではありませんが、Xen に固有のものです。Xen では、大きなプロセスの fork が非常に遅くなる可能性があります (kvm を使用した方が見栄えがします)。Redis の場合、永続化を使用する予定がある場合、これは大きな問題です。両方の永続化オプション (RDB または AOF) では、バックグラウンドの保存プロセスまたは再書き込みプロセスを fork して起動するメイン スレッドが必要です。
場合によっては、フォークのレイテンシーにより、Redis イベント ループが数秒間フリーズすることがあります。Redis インスタンスが管理するメモリが多いほど、レイテンシが長くなります。
EC2 では、必ず HVM 対応インスタンス (M3、ハイメモリ、クラスター) を使用してください。これにより、問題が軽減されます。
次に、大規模なメモリ要件があり、アプリケーションがそれを許容できる場合は、同じマシンでいくつかの小さな Redis インスタンスを実行し、データをシャーディングすることを検討してください。フォーク操作によるレイテンシーを許容レベルまで減らすことができます。
持続性設定
これは、(VM とベア メタルの両方で) Redis から優れたパフォーマンスを得るための重要なポイントです。そのため、 http://redis.io/topics/persistenceを注意深くお読みください。
RDB を使用する場合は、保存バックグラウンド プロセスがオフになると、メモリ コピー オン ライト メカニズムがページの複製を開始することに注意してください。そのため、Redis 自体に十分なメモリと、COW に対処するための余裕があることを確認する必要があります。追加メモリの量はワークロードによって異なります。インスタンスに書き込むほど、追加のメモリが必要になります。
ファイルの書き込みは (ファイルシステムのキャッシュのため) メモリも消費する可能性があることに注意してください。そのため、Redis のバックグラウンド保存中は、Redis メモリ、COW オーバーヘッド、およびダンプ ファイルのサイズを考慮する必要があります。
Redis サーバーを実行しているマシンは決してスワップしてはなりません。もしそうなら、結果は壊滅的です。他のいくつかのストアとは対照的に、Redis は仮想メモリ フレンドリーではありません。
Linux では、適切なシステム パラメータを設定してください: vm.overcommit_memory=1 および vm.swappiness=0 (または非常に低い値)。古いバージョンのカーネルは使用しないでください: それらは低い swappiness を強制するのが非常に苦手です (大きなファイルが書き込まれるとスワップが発生します)。
AOF を使用する場合は、fsync オプションを確認してください。これは、生のパフォーマンスと書き込み操作の耐久性のトレードオフです。選択を行い、戦略を定義する必要があります。
また、EC2 ストレージ オプションについても理解する必要があります。一部の VM では、一時ストレージと EBS のどちらかを選択できます。他のいくつかでは、EBS しかありません。
エフェメラル ストレージは一般的に高速であり、おそらく EBS よりも問題が少ないでしょうが、ディスク障害やホストの再起動などの場合にデータを簡単に失う可能性があります... RDB スナップショットをエフェメラル ストレージに置くことを想像できます。次に、パフォーマンスと堅牢性のトレードオフとして、結果のファイルを EBS ディレクトリにコピーします。
EBS はリモート ストレージです。VM に割り当てられた標準のネットワーク帯域幅を消費し、Redis の最大スループットに影響を与える可能性があります。EBS を使用する予定がある場合は、「EBS 最適化」オプションを選択して、標準ネットワークとストレージ リンクの間に QoS を確立することを検討してください。
最後に、EC2 を使用したパフォーマンスが要求されるインスタンスの非常に一般的なセットアップは、マスターで永続性を無効にし、スレーブ インスタンスでのみ有効にすることです。データの安全性はおそらく低くなりますが、マスターで発生する可能性のある多くのレイテンシの問題を防ぐことができます。