❗️«О Rate Limiting в РЭМД»
_
Около 2ух лет назад с повышением нагрузки и подключением всех субъектов к работе с РЭМД было выявлена необходимость организации Rate Limiting для защиты федеральной системы от различного рода DDOS-атак, к примеру: после неправильного обновления ИС поставщика начинает отправлять один и тот же запрос игнорируя сообщения от РЭМД, что приводило к катастрофической перегрузке и деградации системы (к примеру «нормальный поток от ИС – 5 тысяч сообщений, что то произошло в ИС и за сутки отправляет 600 тысяч сообщений…».
Долгое время лимитирование существовало незаметно для большинства поставщиков и срабатывало крайне редко, однако динамика работы растет и ограничение стало срабатывать чаще.
❓Как это работает:
Лимит установлен между ИПС и РЭМД, т.е. защитный лимит единый, при превышении заданного кол-ва сообщений в минуту, на все запросы в течение этой минуты уходит ответ о достижении лимита.
Ранее формируемое сообщение не соответствовало формату ожидаемому ИПС, что приводило к появлению у вас в логах сообщений подобного формата: «GW-007, faultstring: Неверный формат SOAP-сообщения ответа поставщика (unmarshalling): The element type "hr" must be terminated by the matching end-tag "</hr>".»
Подобная формулировка и получение её от ИПС приводило к разного рода непониманиям.
В текущий момент формат сообщения был исправлен и в пиковые часы, когда достигается лимит вы можете получать код ошибки «RATE_LIMIT» и рекомендацию «Достигнут защитный лимит, просьба повторить через минуту или позже»
Схема с общим лимитом неплохо защищает сам РЭМД, однако является не справедливой, так как всего 1 информационная система, которая сбоит может потреблять весь лимит, как итоге регистраций нет, все получают "отбойники".
Для устранения данной несправедливости прорабатывается и уже находится в тестировании лимитирование запросов на уровне отдельных информационных систем.
Что нужно обеспечить с вашей стороны:
уметь балансировать отправку запросов в РЭМД исходя из индивидуального лимита (запросов на регистрации, поисковых, на получение ЭМД, мета документов и т.п.). К примеру – обеспечить плавную отправку запросов на регистрацию, исключить пакетные подписания, которые за собой влекут всплеск отправок, сервисные запросы (поиск, получение метаописания, извлечений той или иной информации) выполнять по возможности в ночные часы. Особенно обращаю внимание на всплеск отправки документов после выполнения технологических работ.
О включении отдельных ограничений, их размере вы будете оповещены дополнительно.
Подробнее о технологии, как она работает можно почитать по ключевой фразе «leaky bucket algorithm»
_
Около 2ух лет назад с повышением нагрузки и подключением всех субъектов к работе с РЭМД было выявлена необходимость организации Rate Limiting для защиты федеральной системы от различного рода DDOS-атак, к примеру: после неправильного обновления ИС поставщика начинает отправлять один и тот же запрос игнорируя сообщения от РЭМД, что приводило к катастрофической перегрузке и деградации системы (к примеру «нормальный поток от ИС – 5 тысяч сообщений, что то произошло в ИС и за сутки отправляет 600 тысяч сообщений…».
Долгое время лимитирование существовало незаметно для большинства поставщиков и срабатывало крайне редко, однако динамика работы растет и ограничение стало срабатывать чаще.
❓Как это работает:
Лимит установлен между ИПС и РЭМД, т.е. защитный лимит единый, при превышении заданного кол-ва сообщений в минуту, на все запросы в течение этой минуты уходит ответ о достижении лимита.
Ранее формируемое сообщение не соответствовало формату ожидаемому ИПС, что приводило к появлению у вас в логах сообщений подобного формата: «GW-007, faultstring: Неверный формат SOAP-сообщения ответа поставщика (unmarshalling): The element type "hr" must be terminated by the matching end-tag "</hr>".»
Подобная формулировка и получение её от ИПС приводило к разного рода непониманиям.
В текущий момент формат сообщения был исправлен и в пиковые часы, когда достигается лимит вы можете получать код ошибки «RATE_LIMIT» и рекомендацию «Достигнут защитный лимит, просьба повторить через минуту или позже»
Схема с общим лимитом неплохо защищает сам РЭМД, однако является не справедливой, так как всего 1 информационная система, которая сбоит может потреблять весь лимит, как итоге регистраций нет, все получают "отбойники".
Для устранения данной несправедливости прорабатывается и уже находится в тестировании лимитирование запросов на уровне отдельных информационных систем.
Что нужно обеспечить с вашей стороны:
уметь балансировать отправку запросов в РЭМД исходя из индивидуального лимита (запросов на регистрации, поисковых, на получение ЭМД, мета документов и т.п.). К примеру – обеспечить плавную отправку запросов на регистрацию, исключить пакетные подписания, которые за собой влекут всплеск отправок, сервисные запросы (поиск, получение метаописания, извлечений той или иной информации) выполнять по возможности в ночные часы. Особенно обращаю внимание на всплеск отправки документов после выполнения технологических работ.
О включении отдельных ограничений, их размере вы будете оповещены дополнительно.
Подробнее о технологии, как она работает можно почитать по ключевой фразе «leaky bucket algorithm»