0

ELB の背後にある一連の自動スケーリング インスタンスで、膨大な数のオーディオ ファイルをトランスコードする必要があります。トランスコーディング スクリプトのコアは、Node.Js と FFMPEG に基づいています。利用者が我慢できないから行列ができない！CPU 100% の問題を回避するために、各インスタンスのトランスコーディングの数を制御する必要があります。

私の質問:

A-各インスタンスへの接続数を制御する ELB のポリシーを定義する方法はありますか? そうでない場合、各インスタンスの平均 CPU 使用率を制御し、レベルをトリガーした後に新しいものを追加するパラメータはありますか? (私はこのスライドを見つけましたが、完全ではありません) 新しいインスタンスをオンザフライで追加する場合、新しいインスタンスがユーザーにサービスを提供するために 100% 動作するのにどれくらいの時間がかかりますか (つまり、自動スケーリングには長い待ち時間がありますか?)

B-同じトランスコーディング ソリューションを実現する別の代替アーキテクチャはありますか? （この回答に現在のアイデアを図面として含めました）。Transcoding.com のようなサード パーティのソリューションは使用できません。ネイティブ ソリューションが必要です。

C-各インスタンスに node.js を使用し、ソケットによってユーザー ブラウザに進行状況を表示します。ブラウザ側から定期的に ajax リクエストを node.js 側に送信して、進行状況の情報を取得します。このメカニズムにはスティッキー セッションの問題がありますか?

ありがとうございます。

4

2 に答える 2

1

AWSSDKを使用することをお勧めします。通常は、C＃、Rubyなどの公式のものの1つを使用します。node.jsを使用しているため、githubでこのSDKを使用して、インスタンス接続プールなどを監視、調整、作成してみてください。

https://github.com/awssum/awssum

AWS2JSもあります

https://github.com/SaltwaterC/aws2js

于 2012-11-09T23:53:30.903 に答える
1

If your scaling needs to take place in response to individual requests on the server (i.e. a single request would require X number of machines to execute in desired timeframe), then autoscaling is probably not going to be the answer for you, as you will have delay as the new instances become active. You will also potentially have much higher cost to run service in such manner as you could scale up and time a number of times in response to individual request, charging you for one hour minimum for each instance that is started.

If however you are concerned with autoscaling, to for example, increase your fleet 50% during peak times when you get request volume spikes (i.e. you already have many servers serving many requests, but you just need to keep latency down during peak hours by adding more instances), then autoscaling should probably work just fine for you.

There are any number of triggers you can configure to control scaling events in such a case.

ELB does support session affinity ("sticky" sessions).

于 2012-11-10T01:08:50.840 に答える