Здравствуйте, itslave, Вы писали:

C>>Но вот тут случается затыка — в VPC кончились свободные адреса и машины умирают сразу после запуска. Или в ASG у Амазаона что-то сломалось. Ну и может быть и просто нет свободной мощности и ASG выкидывает Insufficient Capacity Error.
I>Ага. И атомная бомба упала на датацентр. И абсолютно все решения надо делать с учетом этих маловероятных событий.
Именно так. Вот недавно такая бомба упала на датацентр одной крупной компании — при чистке пола случайно нажали на рубильник и отключили питание для всего датацентра. Упс.

Для того, чтобы рассуждать об SLA и надёжных системах, надо сначала усвоить, что ломается вообще ВСЁ. Например, если речь идёт об autoscaling'е, то он так периодически сбоит: http://status.aws.amazon.com/rss/autoscaling-us-east-1.rss

C>>Существующие машины не способны справиться с потоком запросов, а frontend продолжает их слать. Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает. Вскоре ни один клиент frontend'а не может получить результаты вовремя, пока backend обрабатывает уже заведомо ненужные сообщения.
I>Circuit breaker можно заимплементить по разному.
Ну так как? Я привёл сценарий стандартного отказа системы сообщений, когда она делает только хуже.

C>>Как делать правильно? Очень просто: иметь небольшой оперативный запас в мощности и делать обработку так, что при повышении нагрузки время обработки плавно росло. При превышении нагрузки — активно делать load shedding, выдавая клиентам frontend'а ошибки.
I>Это не единствено возможный подход. Идентифицировать что бекенд не спрпвляется и начать рещать клиентов можно разнвми способами, выбор кокретного зависит от конкретных требований.
Вот я уже "выбор кокретного зависит от конкретных требований" слышу в который раз. КАК КОНКРЕТНО решить эту проблему с системами сообщений, например SQS?

C>>Ну то есть, проблема не решается нормально.
I>Еще раз. Единственный критерий нормальности решения проблемы — это соотвествия результаьа спецификации. Все. Точка.
Да-да. И в спецификации, конечно, написано: "Можно ломаться и терять данные, если клиенты делают слишком много запросов". Если у вас там такие спецификации, то могу только посочувствовать.

В реальном мире, нормальность решения определяется исключительно практикой использования.

C>>Какая очередь может делать throttling отправляющей стороны? Это нельзя делать в SQS или ApacheMQ.
I>А не надо этого делать в предложенном мной подходе.
Ну тогда прошу описать каким образом будет решаться проблема с перегрузкой в моём сценарии.

Здравствуйте, itslave, Вы писали:

C>>Но вот тут случается затыка — в VPC кончились свободные адреса и машины умирают сразу после запуска. Или в ASG у Амазаона что-то сломалось. Ну и может быть и просто нет свободной мощности и ASG выкидывает Insufficient Capacity Error.
I>Ага. И атомная бомба упала на датацентр. И абсолютно все решения надо делать с учетом этих маловероятных событий.
Именно так. Вот недавно такая бомба упала на датацентр одной крупной компании — при чистке пола случайно нажали на рубильник и отключили питание для всего датацентра. Упс.

Для того, чтобы рассуждать об SLA и надёжных системах, надо сначала усвоить, что ломается вообще ВСЁ. Например, если речь идёт об autoscaling'е, то он так периодически сбоит: http://status.aws.amazon.com/rss/autoscaling-us-east-1.rss

C>>Существующие машины не способны справиться с потоком запросов, а frontend продолжает их слать. Отставание backend'а продолжает нарастать. Клиенты frontend'а паникуют, повторяя операции всё чаще. Отставание нарастает. Вскоре ни один клиент frontend'а не может получить результаты вовремя, пока backend обрабатывает уже заведомо ненужные сообщения.
I>Circuit breaker можно заимплементить по разному.
Ну так как? Я привёл сценарий стандартного отказа системы сообщений, когда она делает только хуже.

C>>Как делать правильно? Очень просто: иметь небольшой оперативный запас в мощности и делать обработку так, что при повышении нагрузки время обработки плавно росло. При превышении нагрузки — активно делать load shedding, выдавая клиентам frontend'а ошибки.
I>Это не единствено возможный подход. Идентифицировать что бекенд не спрпвляется и начать рещать клиентов можно разнвми способами, выбор кокретного зависит от конкретных требований.
Вот я уже "выбор кокретного зависит от конкретных требований" слышу в который раз. КАК КОНКРЕТНО решить эту проблему с системами сообщений, например SQS?

C>>Ну то есть, проблема не решается нормально.
I>Еще раз. Единственный критерий нормальности решения проблемы — это соотвествия результаьа спецификации. Все. Точка.
Да-да. И в спецификации, конечно, написано: "Можно ломаться и терять данные, если клиенты делают слишком много запросов". Если у вас там такие спецификации, то могу только посочувствовать.

В реальном мире, нормальность решения определяется исключительно практикой использования.

C>>Какая очередь может делать throttling отправляющей стороны? Это нельзя делать в SQS или ApacheMQ.
I>А не надо этого делать в предложенном мной подходе.
Ну тогда прошу описать каким образом будет решаться проблема с перегрузкой в моём сценарии.

C>>Примерно так и есть.
I>вопросов больше не имею
Основной метод продажи этих Tibco выглядит так: продажник приходит и говорит, что если клиент купит Tibco/Oracle/whatever, то у него магически увеличится член число девяток надёжности. При этом в контракте прописаны зверские штрафные санкции за нарушения этого — возврат абонентской платы за последний месяц.