2

TL;DR - セッション ストレージ用の単純なキャッシュ クラスター (memcache または redis を使用) は、アプリのサーバー (つまり、nginx および php と共に) または独自の個別の ec2 インスタンス (elasticache またはカスタマイズされた ec2 インスタンスなど) に存在する必要がありますか?

現在、Amazon OpsWorks を使用してウェブアプリのインフラストラクチャをセットアップしています。私は、独自の ec2 インスタンスとしてではなく、アプリ層自体にインストールされた memcache インスタンスを介してセッション キャッシュを実装することに傾いています。例えば：

                 [ Load Balancer ]
                /        |        \
[ App Layer 1 ] – [ App Layer 2 ] – [ App Layer 3 ]  * /w memcache or redis

対。

                 [ Load Balancer ]
               /         |         \
[ App Layer 1 ]   [ App Layer 2 ]   [ App Layer 3 ]
               \         |         /
                [ Cache Server(s) ]   * ElastiCache or custom ec2 /w memcache or redis

ここでの長所と短所は何ですか？私には後者の解決策は不必要に思えますが、非常に大きなセッション キャッシュを持つトラフィックの多い Web サイトでこれが必要になる可能性があることは理解できます。

nginx/php アプリ サーバー スタックと一緒に redis や Elasticache を実行したくない理由はありますか? おそらく、自動スケーリングまたはパフォーマンスの監視がより難しくなりますか?

4

2 に答える 2

2

最初のソリューションの 2 つの主な欠点は次のとおりです。

  • セッションの粘着性を余儀なくされます。
  • アプリとキャッシュのスケーリング イベントを結合しています。

これらはあなたの場合は問題にならないかもしれませんが、長期的には問題を複雑にする傾向があるため、一般的に可能な限り避けるようにしています.

于 2014-04-06T07:25:44.963 に答える
1

アプリ サーバーにキャッシュを配置する主な理由は、コストの問題です。これは、Web サーバーまたはアプリ サーバーと同じサーバーに DB を配置しないのと同じ考え方です。

小規模なアプリケーションを使用している場合、おそらく同じマシンですべてのリソースを圧迫できますが、あらゆるタイプの障害 (および「すべてが失敗する」) から回復する能力があると、データが失われるか、データの一部が失われます。一部のユーザーのサービスがダウンしています。

十分なアプリ サーバーがあれば、サーバーあたりのキャッシュ クラスターのコストは小さくなります。

アーキテクチャの観点から、スケールと高可用性が重要な場合は、複雑なコンポーネントをいくつか使用するよりも、より小さなコンポーネントを使用する必要があります。

たとえば、より多くのユーザーがいるためにフリートに別のアプリ サーバーを追加する場合、このサーバーにインストールするソフトウェア コンポーネントが少なく、サーバーが既に以前のユーザーにサービスを提供できるため、サーバーを追加する方が高速です。彼らのセッションは一元的に保存されます。アプリ サーバーを削除する場合 (またはアプリ サーバーを失った場合)、そのサーバーによってサービスを提供されていたユーザーは、セッション/ステータスがキャッシュ クラスターに保存されるため、他のサーバーに簡単に移行できます。

于 2014-04-06T08:12:52.783 に答える