0

私は Amazon Web Services を使用しており、負荷分散と災害復旧のために適度なシステムをセットアップしようとしています。アプリケーションは PHP ベースで、フロント エンドに Zend Framework 2 (ZF2)、ローカルの memcached サーバー、および RDS を介した MySQL を使用します。すべてのサーバーは Amazon Linux を実行しています。

2 つの異なる AWS の「可用性ゾーン」で 2 つのサーバーを使用するようにエラスティック ロード バランサーを構成しようとしています。あるサーバーがシャットダウンして別のサーバーが引き継ぐことをシームレスに許可するには、共有 PHP セッションが必要です。そこで、ZF2 で PHP データベース セッションをセットアップしました。

一般に、AWS ゾーンが停止する可能性は、個々のサーバーまたはアプリケーション自体に致命的な問題が発生する可能性よりもかなり低いと思います。だから私は別のアプローチを検討しています：

  1. 同じアベイラビリティ ゾーン内のすべてのサーバー
  2. 別の AWS ElastiCache サーバー (基本的に memcached であり、ゾーン間で使用することはできません)
  3. キャッシュに格納された PHP セッション (memcached の組み込みサポート)
  4. 別のゾーンに 1 つの緊急サーバー – まれにゾーンが停止した場合、別のサーバーを使用するように DNS レコードを変更します。

これは、DR と負荷分散に対する適切な標準的なアプローチですか? ゾーンが停止した場合の DR ソリューションは好きではありませんが、ゾーンがそれほどダウンするのを見たことがありません。設計が簡素化されれば、おそらくそのレベルのリスクに対処できるでしょう。ロード バランサーがサーバーに重み付けできる場合は、1 つのゾーンにすべての重み付けを適用し、バックアップ サーバーの重み付けをはるかに低くします。

4

1 に答える 1

1

すべての PHP サーバーを同じ AZ に保持することと、それらを複数の AZ に分散することの利点は何でしょうか? 非常にわずかな (3 ～ 5 ミリ秒) レイテンシの改善を除いて、何も考えられません。マイナス面はほとんどないので、サーバーを複数の AZ に分散させてみませんか?

Elasticache memcached は依然として単一障害点です。Elasticache インスタンスが実行されている AZ に問題がある場合、セッションが失われます。Elasticache with Redis (マスター/スレーブをサポート) を使用するように切り替えて、キャッシュレイヤーのマルチ AZ を実現することもできます。

于 2014-06-16T16:43:32.353 に答える