Комментарии 9
Selectel, а расскажите, как так получилось, что ВСЕ ваши IP-адреса (ASN 49505) находятся в чёрном списке UCEPROTECT-Level3 www.uceprotect.net/en/rblcheck.php?asn=49505 ? А большинство адресов - ещё и в других списках.
Производительность файлового хранилища оказывается в несколько раз ниже заявленных по вашим же тестам fio. Поддержка в лучших традициях отмораживается "у нас всё хорошо, мониторинг показывает твёрдо и чётко".
Если заказывать прокси на сайте https://proxyline.net/ то в 80% случаев это прокси, которые расположены на сервере компании Selectel. Так можно и в черный список РКН попасть легко.
Добрый день! На данный момент нас заделистили в UCEPROTECT на Level3 — мы в зеленом списке. Ранее мы действительно могли быть в черном списке, поскольку борьба со спамом, исходящим из нашей сети, не была проактивной. Мы ограничивали айпишникам 25 порт наружу только после их попадания в спам-листы, когда анализировали публичные листы постфактум.
С 1 апреля команда облачной платформы и NetOps Selectel реализовали систему проактивной борьбы со спамом. Мы сразу анализируем активность по 25 порту наружу от наших клиентов и блокируем возможность рассылать почту тем, у кого трафик превышает установленный порог, а скоринг (оценка доверия пользователю по ряду параметров) далек от идеала. Попадание айпишников в спам-листы — частая проблема провайдеров, мы стараемся максимально предупредить этот процесс. Например, в облаке у нас есть такой антиспам-сервис: https://habr.com/ru/company/selectel/blog/557400/.
По производительности файлового хранилища: напишите номер тикета в директ, пожалуйста, — разберемся.
Зачем обманывать-то? Всё легко проверяется: сети как были в blacklist'е, так и остались https://www.uceprotect.net/en/rblcheck.php?asn=49505 и https://www.uceprotect.net/en/rblcheck.php?asn=50340
Тикет про производительность ФХ 3208589
Ещё одна проблема обнаружилась недавно: бэкапы делаются в рандомные 8 часов вместо времени, указанного в настройках. По сути, такие бэкапы бесполезны. Тикет 3255196
И самое главное: найдите людей, которые способны в анализ и оптимизацию на алгоритмическом уровне.
Пример из практики: тяжелые запросы рекомендаций в БД с множеством условий и проверкой остатков, выполняются суммарно около 6 секунд на 3 запроса, это много - покупатели уходят не дождавшись ответа, минус продажи.
За несколько лет опытной командой разработки было сделано несколько попыток его оптимизации. Ни к чему не пришли, потому что запрос максимально оптимален в классическом понимании. Как показала практика, так оно и есть.
Проблема пришла в виде мелкой просьбы, в стиле "Тут долго работает, если можно сделайте, нет - нет" при решении другой проблемы. Время оплачено независимо от результата, так что есть простор для экспериментов, а эксперименты это интересно.
День ушел на анализ запроса. Все индексы есть, путь с индексами тупиковый, отбрасываем.
Разбив запрос на части, выяснилось: почти все время уходит на проверку остатков, сделать с ними ничего нельзя, данных очень много прогоняется, время справедливое.
Кешировать запрос нельзя: остатки зависят от условий, а условия от остатков, плюс сортировка - запрос имеет смысл только целиком.
Полный тупик, понятно почему от решения отказывались несколько лет: его реально нет.
Эмоции, первый порыв отказаться, сославшись на практику команды, которая доказала что решения нет, нужно смириться с проблемой. Так можно, в своем праве, но решено взять еще несколько дней на обдумывание, проблема интересна своей очевидной нерешаемостью.
Через несколько дней фоновых размышлений нащупан вариант: что если отделить тяжелый запрос от легкого? Это лишает смысла результат, но решает основную часть проблемы: время. Решение очевидное, но из-за фокусировки на запросе приходит не сразу. Решение бесполезное: без учета остатков смысла в запросе нет. Но обретает смысл, добавив опыт и экспертизу: да, отдельные запросы сами по себе бессмысленны, но переводят проблему в другую плоскость - теперь у нас два запроса с разными свойствами, и по отдельности они отлично кешируются. Чтобы получить результат достаточно найти общие элементы двух множеств, а это элементарно. Бонусом возможность задавать любые условия: условия дешевые по времени, а тяжелые остатки повторно запрашивать больше не нужно.
Результат: 6с->2c. Уже неплохо, но хотелось бы хотя бы 0.6-0.8с, чтобы покупатель гарантированно дождался результата.
Ранее при анализе выяснилось что запроса с остатками всего 3, они уникальны, но так как остатки можно кешировать за один запрос, повторно их не запрашиваем - остается 3 быстрых запроса без остатков и 1 тяжелый запрос остатков, все кешировано.
Результат: 0.6с, это отличный результат, задача решена.
Но при анализе также выяснилось, что можно быстро внедрить еще две простейшие оптимизации.
Во-первых из-за особенностей каталога можно хранить только 10% остатков без потери функционала, что уменьшит и ускорит кеш. Чей бы и нет? Делаем.
Результат: 0.2с, это уже шикарный результат.
Во-вторых выяснилось что данные отлично поддаются сжатию, и тесты показали что сжатие длится буквально 0.01с, а значит можно еще уменьшить и ускорить кеши. Делаем.
Результат: 0.07с, без комментариев, это уже далеко за пределами желаемого.
Итог: на входе долгий запрос, целых 6 секунд, многолетний ущерб продажам, фактически нерешаемая классическими способами проблема. На выходе 0.07 секунды. Цена вопроса - несколько дней работы одного подходящего человека. Человека, которому интересно щелкать нерешаемые проблемы и погружаться в систему глубже, чем это обычно делает рядовой разработчик. Человека, который набрал опыт и экспертизу конкретно на сложных и непонятных случаях.
В данном случае проблема ко мне попала случайно, но что если приложить такие навыки конкретно к сложным случаям? Полагаю это отдельная специализация уже: из коллег на такое способны буквально единицы.
Увидел название статьи и поспешил открыть, с надеждой почерпнуть что-то новое. Увы :)
Все-таки "инфраструктура" и "арендуемая виртуальная инфраструктура" - разные вещи. Я как ответственный за функционирование ЦОД был вынужден решать вопросы начиная от потребления электроэнергии (вычисление простаивающего оборудования, обесточивание, консолидация ресурсов в стойках/серверах/облачной инфраструктуре) и обеспечении охлаждения (btu, n+1, фильтра, фреон, обслуживание), ИТ-инфраструктуры (сервера, дисковые массивы, ленточные библиотеки и (внезапно!) сами ленточки, SAN-коммутаторы, роутеры-маршрутизаторы-коммутаторы, оптические каналы, DWDM) до лицензий (ОС, БД (внезапно в некоторых сценариях Postgres дороже чем Oracle), системы резервирования, виртуализация, смартнеты и т.д. и т.п.), необходимых для функционирования ЦОД.
А ведь есть еще и резервные мощности - резервные вводы, ДГУ, АВР, системы питания и их АКБ... Регламентные процедуры, запуск ДГУ без нагрузки и под нагрузкой, обслуживание каждые 100 моточасов, замеры емкости АКБ раз в неделю, вычисление АКБ с битыми банками и их замена...
А ЦОД-ов еще и не один а куча, плюс еще удаленные для обеспечения geo redundancy...
Квоты на ресурсы, говорите? Трафик между услугами? Плавающие IP-адреса?
Оптимизация инфраструктуры: снижаем счет за ресурсы без ущерба для бизнеса