Тестирование на масштабируемость в облачной среде

Тестирование на масштабируемость в облачной среде

Не так давно в Trend Micro задались целью выполнить тест масштабируемости одного из собственных продуктов (Trend Micro Deep Security). Скорый поверхностный расчет показал, что для выполнения этой задачи потребовалось бы 35 серверов Dell 710 с возможностью виртуализации. Найти столько доступных серверов – непростая задача для любой компании, а о том, чтобы купить столько серверов ради месячного тестирования, не могло быть и речи.



Поэтому было решено обратиться за помощью к облакам. Подходящим решением стала инфраструктура Amazon Web Services (AWS), с помощью которой удалось получить необходимое количество менее крупных ресурсов. (В данном случае небольшие экземпляры идеально подходили для моделирования крупной архитектуры «менеджер-агент», причем каждый экземпляр моделировал множество агентов).

Следует иметь в виду, что просто открыть учетную запись и сделать запрос на 1000 небольших экземпляров не удастся. Сотрудники Amazon связываются с клиентом по электронной почте, чтобы определить требуемое соотношение типов экземпляров, платформ, зон доступности и регионов, которые будут выгодны как вашему проекту, так и AWS. Сразу после определения конфигурации мы разработали необходимые инструменты быстрого увеличения или уменьшения масштаба нашей тестовой среды. К ним относились AMI (шаблоны) и инструменты, использовавшие интерфейсы прикладного программирования для обнаружения и мониторинга ресурсов.

Нас не миновали странности платформы AWS, такие как перекос временной диаграммы при активном использовании ресурсов ЦП, некорректная информация о ресурсах ЦП для небольших экземпляров в CloudWatch и неизбежные «войны цен» за точечные экземпляры. Из-за особого характера тестов не все шло по плану. Порой при увеличении масштаба возникали сообщения об ошибке от интерфейса прикладного программирования AWS с формулировкой «недостаточно ресурсов». Будет нелишним иметь запасные варианты на случай, когда нужный тип экземпляра или регион перегружены.

В процессе решения различных задач платформа AWS показала хорошие возможности поиска и быстрого решения проблем с масштабируемостью. Имея возможность быстро получить сотни виртуальных машин с одного AMI, мы могли увеличивать и уменьшать масштаб в зависимости от условий тестирования.

В итоге были достигнуты поставленные цели по масштабируемости и потрачено гораздо меньше средств.

PlayStation теперь требует подключение к интернету раз в 30 дней

Пользователи PlayStation 4 и PlayStation 5 заметили неприятное нововведение: цифровые копии игр теперь могут требовать подключения к интернету раз в 30 дней для проверки лицензии. Жалобы начали появляться в апреле 2026 года.

Владельцы консолей писали, что система просит подтвердить лицензию на игры из PS Store и подключиться к серверам Sony.

Сначала многие решили, что это ошибка, но служба поддержки PlayStation подтвердила: речь идёт о DRM-проверке, а не о случайном сбое.

Ограничение затрагивает цифровые игры и дополнения, купленные после марта 2026 года. Если консоль больше 30 дней не выходит в Сеть, игра может перестать запускаться до повторного подключения к интернету. После проверки доступ должен восстановиться.

Пользователям это, мягко говоря, не понравилось. Главная претензия, которую привёл NikTek в X, не столько в самом подключении к интернету, сколько в вопросе владения цифровыми покупками. Люди купили игру за свои деньги, но теперь фактически зависят от регулярной проверки на стороне Sony.

Критики считают, что консоль не должна блокировать доступ к уже купленным играм только потому, что пользователь долго был офлайн. Особенно это болезненно для тех, кто живёт с нестабильным интернетом, уезжает надолго или принципиально использует консоль без постоянного подключения.

Вокруг ситуации остаётся много вопросов: будет ли компания менять подход, исправлять его как ошибку или оставит 30-дневную проверку для новых цифровых покупок.

RSS: Новости на портале Anti-Malware.ru