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

I>>Я — читал. У тебя со чтением проблемы, как мы выяснили в соседнем треде. Да, живых денег не дают, просто ресурсы нахаляву, что напрямую трансформируется в деньги.
C>Ага. Ну вот смотрим SQS SLA. Упс. А его нету.
А оно есть, хотя канечна аптайм они не гарантируют. Зато гарантируют доставку принятого сообщения:

Q: Does Amazon SQS guarantee delivery of messages?

Standard queues provide at-least-once delivery, which means that each message is delivered at least once.

FIFO queues provide exactly-once processing, which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue.

А вот млекософт дает полноценный sla на свой azure service bus.

C>Ну ладно, смотрим EC2: https://aws.amazon.com/ru/ec2/sla/ — аж 30% скидки на целый МЕСЯЦ (!!!) в случае доступности менее чем в 99% (простой в 7 часов). Зверские, по-настоящему зверские, санкции.
Это всего лишь говорит о том, что всех все устраивает. Это бизнес и ничего более. Как только в амазон начнет регулярно фейлить sla и это начнет приводить к существенным убыткам — юизнсе мигрирует в ажур или куда там еще. Как только это станет трендом? акции амазона пойдут вниз(или не будут показывать прогнозируемого роста), акционеры вставят пистон CEO, он начнет исправлять ситуацию тем или иным способом(улучшать каечтсво, снижать цену, увеличивать штрафные санкции...) как то так оно и работает.

C>Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.
А с чего ты взял что убытки будут многомиллионными? Как считал? Под какую нагрузку/какой бизнес?

C>Я в недоумении оглянулся на систему мониторинга, которую я написал и которая следит более за тысячами показателей в каждом из 19 регионов, которые мы поддерживаем.
C>Чем мониторинг должен помочь?
Если твой мониторинг для твоего супер нагурженного/всегда доступного решения не умеет автоматически запускать disaster recovery procedure при детектировании того что все упало, то я в недоумении.

C>Ты понимаешь такое понятие — "очередь сообщений"? Туда запихиваются сообщения. Клиент не читает очередь, он туда пишет. Максимум очереди могут дедуплицировать сообщения по уникальному ID.
Таки у тебя определенные проблемы с чтением. Не будет дубликатов — очередь не будет распухать, существующие сообщения не будут "протухать".
Далее, кто мешает клиенту по таймеру читать из специального ендойнта текущую загрузку системы и изменять величину отклика(время показа окошка please wait) клиенту чтобы тот не так сильно дергался и при полной жопе показывать окошко "попробуйте через 10 минут".

C>Но в данном случае это не поможет, так как при замедлении обработчика, он не будет справляться с нормальным потоком сообщений, которые вполне себе уникальны.
Еще как поможет, разгребет потихоньку если поток ограничить кака я описал выше.

C>Если нужна гарантированная доставка, то я могу почти на 100% сказать, что сообщения используются неправильно.
Я тебе еще раз повторяю, все зависит от контекста. 99.99% бекенд сервисов написаны в десятки(если и сотни) раз менее стабильными, доступными, надежными чем тот же sqs. Переписывать их заново с нужным уровнем надежности банально слишкеом дорого и никому нафик не надо. Но гарантировать доставку сообщений с вероятность в 99.9+ задешево — мечта бизнеса. Вот тут очереди/сервис басы решают.

I>>Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что.
C>Нет. Я говорю о том, что полностью пролетала распределённая модель, в которой часть состояния хранится в виде сообщений (т.е. потому и требуется гарантированная доставка).
Любой асинхронный сетевой выхов(те не требующий ответа о завершении операции) — по сути распределенная модель, часть состояния которой хранится в виде сообщений(с).

C>Сами по себе асинхронные системы вполне себе нормально живут. Но даже там их лучше применять только для некритичных по времени вещей.
Наконец то хоть какие то проблески понимания что "а у людей может быть и не такие задачи как у меня"

I>>Позволь спросить твой текущий тайтл. Просто интересно, насколько адекватный ресурс манагмент в амазоне.
C>Principal engineer.
Тоесть "прокачанный сеньор". Адекватно, в своей специализации ты прокачался, но по сторонам смотреть пока еще не очень научился.

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

I>>Я — читал. У тебя со чтением проблемы, как мы выяснили в соседнем треде. Да, живых денег не дают, просто ресурсы нахаляву, что напрямую трансформируется в деньги.
C>Ага. Ну вот смотрим SQS SLA. Упс. А его нету.
А оно есть, хотя канечна аптайм они не гарантируют. Зато гарантируют доставку принятого сообщения:

Q: Does Amazon SQS guarantee delivery of messages?

Standard queues provide at-least-once delivery, which means that each message is delivered at least once.

FIFO queues provide exactly-once processing, which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue.

А вот мелкософт дает полноценный sla на свой azure service bus.

C>Ну ладно, смотрим EC2: https://aws.amazon.com/ru/ec2/sla/ — аж 30% скидки на целый МЕСЯЦ (!!!) в случае доступности менее чем в 99% (простой в 7 часов). Зверские, по-настоящему зверские, санкции.
Это всего лишь говорит о том, что всех все устраивает. Это бизнес и ничего более. Как только в амазон начнет регулярно фейлить sla и это начнет приводить к существенным убыткам клиентов — бизнес мигрирует в ажур или куда там еще. Как только это станет трендом, акции амазона пойдут вниз(или не будут показывать прогнозируемого роста), акционеры вставят пистон CEO, он начнет исправлять ситуацию тем или иным способом(улучшать качество, снижать цену, увеличивать штрафные санкции за даунтайм...) как то так оно и работает.

C>Я видел соглашения со всякими Tibco и Oracle, и там всё примерно аналогично. В случае, если упадёт система сообщений, на которой висит весь бизнес организации, они дадут покупателям конфетку и воздушный шарик для компенсации возможно многомиллионных убытков.
А с чего ты взял что убытки будут многомиллионными? Как считал? Под какую нагрузку/какой бизнес?

C>Я в недоумении оглянулся на систему мониторинга, которую я написал и которая следит более за тысячами показателей в каждом из 19 регионов, которые мы поддерживаем.
C>Чем мониторинг должен помочь?
Если твой мониторинг для твоего супер нагруженного/всегда доступного решения не умеет автоматически запускать disaster recovery procedure при детектировании того что все упало, то я в недоумении.

C>Ты понимаешь такое понятие — "очередь сообщений"? Туда запихиваются сообщения. Клиент не читает очередь, он туда пишет. Максимум очереди могут дедуплицировать сообщения по уникальному ID.
Таки у тебя определенные проблемы с чтением. Не будет дубликатов — очередь не будет распухать, существующие сообщения не будут "протухать".
Далее, кто мешает клиенту по таймеру читать из специального ендойнта текущую загрузку системы и изменять величину отклика(время показа окошка please wait) клиенту чтобы тот не так сильно дергался и при полной жопе показывать окошко "попробуйте через 10 минут".

C>Но в данном случае это не поможет, так как при замедлении обработчика, он не будет справляться с нормальным потоком сообщений, которые вполне себе уникальны.
Еще как поможет, разгребет потихоньку если входной поток ограничить как я описал выше.

C>Если нужна гарантированная доставка, то я могу почти на 100% сказать, что сообщения используются неправильно.
Я тебе еще раз повторяю, все зависит от контекста. 99.99% бекенд сервисов написаны в десятки(если и сотни) раз менее стабильными, доступными, надежными чем тот же sqs. Переписывать их заново с нужным уровнем надежности банально слишкеом дорого и никому нафик не надо. Но гарантировать доставку сообщений с вероятность в 99.9+ задешево — мечта бизнеса. Вот тут очереди/сервис басы решают.

I>>Ты сейчас говоришь, что асинхронная модель программирования в распределенной системе не пригодна ни на что.
C>Нет. Я говорю о том, что полностью пролетала распределённая модель, в которой часть состояния хранится в виде сообщений (т.е. потому и требуется гарантированная доставка).
Любой асинхронный сетевой выхов(те не требующий ответа о завершении операции) — по сути распределенная модель, часть состояния которой хранится в виде сообщений(с).

C>Сами по себе асинхронные системы вполне себе нормально живут. Но даже там их лучше применять только для некритичных по времени вещей.
Наконец то хоть какие то проблески понимания что "а у людей может быть и не такие задачи как у меня"

I>>Позволь спросить твой текущий тайтл. Просто интересно, насколько адекватный ресурс манагмент в амазоне.
C>Principal engineer.
Тоесть "прокачанный сеньор". Адекватно, в своей специализации ты прокачался, но по сторонам смотреть пока еще не очень научился, а может тебе оно и не сильно нужно.