Назад | Перейти на главную страницу

Как подписать конкретный экземпляр в приложении эластичного beanstalk на тему SNS?

Итак, у меня есть приложение эластичного бобового стебля с масштабируемым веб-уровнем, обслуживаемое ELB. Короче говоря, мне нужно иметь возможность подписать конкретный экземпляр на моем веб-уровне на тему SNS. Безопасно ли для меня использовать стандартный метод для получения IP-адреса экземпляра (как подробно описано в python здесь. Как я могу получить IP-адрес eth0 в Python?), А затем просто подписаться на тему SNS, используя этот IP-адрес в качестве подписчика http ?

Зачем? Хороший вопрос...

Моя модель данных состоит из множества объектов, многие из которых могут иметь присоединенный набор пользователей, которые могут захотеть наблюдать за этими объектами. Этот веб-уровень в моем приложении отвечает за обработку интерфейса сокета (с использованием socket.io) для клиентских приложений.

Когда пользователь создается в системе, это тоже тема SNS для пользователя, позволяющая отправлять уведомления этому пользователю, когда объект, в котором он заинтересован, изменяется. Как я планирую это настроить, клиентское приложение будет подключаться к EB через socket.io, после чего экземпляр сервера, к которому оно подключено, будет подписываться на тему SNS этого пользователя. Затем, когда интересный объект изменяется, уведомления будут публиковаться в связанных темах пользователя, тем самым уведомляя экземпляр сервера о том, что клиентское приложение имеет открытое соединение, которое затем может отправить сообщение через сокет.

Я считаю важным, чтобы был подписан конкретный экземпляр, а не внешний CNAME или IP-адрес веб-уровня, поскольку клиентское приложение подключено к конкретному экземпляру, и только этот экземпляр может отправлять сообщения через свой сокет. Подписка на балансировщик нагрузки будет бесполезной, поскольку уведомление может быть доставлено экземпляру, к которому пользователь не подключен.

Я считаю, что вопрос вверху - это все, что мне нужно, но я открыт для творческих решений, если мои рассуждения кажутся ошибочными ??

Эта архитектура не подходит для вашего случая использования.

  1. Создание темы в соцсети "на пользователя" не масштабируется,
  2. Для подписки на серверные экземпляры EC2 необходимо, чтобы у этих внутренних экземпляров EC2 были общедоступные конечные точки,
  3. По мере создания и прекращения работы экземпляров EC2 устаревшие подписки останутся и должны управляться / удаляться,
  4. Кроме того, привязка пользователя к конкретному экземпляру EC2 не будет работать, если этот экземпляр EC2 будет завершен (из-за уменьшения масштаба или другого сбоя).

Вместо этого попробуйте:

  1. Разрешите вашим клиентским соединениям подключаться к балансировщику нагрузки, который затем позволяет соединениям переходить от экземпляров EC2 по мере необходимости.
  2. Используйте другой механизм, например Redis pub / sub, для управления получением сообщений экземплярам EC2 и, следовательно, клиентам.