EC2 やその他のクラウド コンピューティング インフラストラクチャで Web 層または db 層の自動スケーリングを試した人がいるかどうか知りたいです。理論的には可能に思えますが、実際の制限がどのようなものか/多分興味があります。
ありがとう!
EC2 やその他のクラウド コンピューティング インフラストラクチャで Web 層または db 層の自動スケーリングを試した人がいるかどうか知りたいです。理論的には可能に思えますが、実際の制限がどのようなものか/多分興味があります。
ありがとう!
自動スケーリングも検討し始めています。
最初の候補となるアプローチは、Amazon の ELB (Elastic Load Balancer) と Cloud Front を使用することです。ただし、トラフィックは Web サービスです。発信者は頻繁に 100-Continue http メッセージを送信しますが、ELB はそのメッセージを理解できません。いつ修正されるかについて、Amazon からはまだ何の連絡もありません。また、Amazon フォーラムには、ELB が重い負荷を処理しないという苦情が多数あります。
LigHTTPD 1.5 は、インスタンスが機能していないことを検出してローテーションから透過的に取り除き、ロード バランサーを再起動せずに動的に再構成できるという点で、有望な部分的なソリューションのように見えます。
商用ソリューションも多数あります。おそらく、Right Scale を見ていきます。
これは答えというよりは質問ですが、私は自分自身で自動スケーリングの実験を始めようとしています (ほとんどの場合、Amazon CloudFront 機能を使用します)。インスタンスの起動時間が要因になると考えています。新しい EC2 インスタンスの起動には 5 ~ 20 分かかる場合があることに気付きました。そのため、負荷が増加したときにすぐに容量を追加できるわけではありません。アイドル状態のインスタンスを 1 つ以上実行して、増加した負荷に対応できるようにする必要があるようです。
後期追加:
SimpleDB も検討してください...これにより、DB のスケーリング側が排除されます。
自動スケーリングのために、独自のスクリプトをロールしてサーバーを監視、起動、およびプロビジョニングしました。はい、プロセス全体に約 7 分かかります。新しいサーバーがいつ必要になるかを推測するために少し予測分析を行い、そうでない場合は分類します。総費用: ~10 セント。
また、Scalr は商用ソリューションとして有望に見えます (まだ使用していません)。
チャド