Всем привет! Меня зовут Антон Огородников, и с начала этого года я руковожу отделом онлайн-разработки в «Магните». Не успел я заонбордиться, как столкнулся с настоящим коллапсом — массовым лог-аутом пользователей из приложения лояльности «Магнит: акции и скидки». Клиентов разлогинивало в самые неподходящие моменты: например, на кассе во время оплаты товаров. Оценка приложения в сторах упала до 2 баллов, капали негативные комментарии.
В этой статье я расскажу, как мы искали причину разлогинов и как сумели побороть проблему.
Кардиограмма разлогинов
Старая версия мобильного приложения лояльности «Магнита» появилось до моего прихода в компанию еще в 2020 году. Оно предоставляло клиентам скидки лояльности, но его проектировали без собственного бэкенда.
Интеграция телефона клиента происходила через CRM, при этом авторизация была односторонней — только клиентская.
При регистрации в приложении пользователь отражался в базе CRM, где ему присваивался логин и пароль. После авторизации он мог совершать действия в приложении, а компания видела регистрацию этих действий в CRM. Такая авторизация занимала время и не всегда корректно отрабатывала на вход, поэтому оценка приложения колебалась от 1 и до 2,5 баллов.
Летом было решено провести апгрейд приложения. Архитектурно за интерфейсом в телефоне разработали бэкенд magnit-API, под ним собрали три элемента:
Keycloak — open-source сервис авторизации, написанный на Java;
Redis — хранилище или key value storage;
CRM, название которой мы сохраним в тайне. Это платный enterprise-сервис для программ лояльности, хранения информации о клиентах и их операциях.
Архитектуру бэкенда выстроили, но пользователей продолжало выкидывать из приложения. После множества тестов и проверок стало ясно, что причина крылась в двойной авторизации между API и CRM. Она оставалась как в связке между телефоном и magnit-API по логину и паролю на базе Keycloak, так и между телефоном и CRM на базе бэкенда по логину и паролю клиента.
Таким образом, клиент заходил в приложение, вводил логин и пароль, которые падали на бэкенд. Оттуда они направлялись в CRM для создания токена авторизации, который хранился в Redis.
Итак, проблема была в неудачно построенной архитектуре. Стоит сказать, что на момент разработки приложения сделать по-другому было практически невозможно. API в CRM был только по логину и паролю.
Можно задать логичный вопрос «А зачем вообще была нужна CRM?» Все просто — в компании ее использовали с 2018 года, и в ней хранили информацию о клиентах. Это покупки, баллы лояльности и транзакции. Поэтому проще было привязать авторизацию сразу к ней.
Новое приложение, новые трудности
В конце 2020 года «Магнит» выпустил новую версию приложения, и проблема разлогинов временно исчезла. Но уже через месяц все началось по новой — около 7 000 пользователей в день выбрасывало из приложения.
Я предположил, что проблема кроется в короткой жизни токенов в CRM. Тогда она составляла 30 дней без возможности пролонгирования. Не важно, как часто клиент пользовался приложением: он проходил авторизацию один раз и получал связку токенов на 30 дней. Спустя это время срок жизни токена подходил к концу, и клиента разлогинивало. CRM не предусматривала возможность пролонгирования токенов.
Тогда мы взялись за CRM. Проблему решил наш CIO Валентин. Он связался с представителями сервиса, объяснил наш запрос и контекст ситуации. Договорились, что разработчики CRM создадут для нас специальное обновление, продлевающее жизнь токенам. Казалось бы, загадку разгадали, проблему решили.
Однако через месяц ситуация стала ещё хуже. В начале марта показатель разлогинов вырос до 115 000 в сутки. Это был настоящий апокалипсис — выкидывало каждого четвертого пользователя. Это и недовольные клиенты, и финансовые затраты: например, на повторные sms-авторизации. Реагировать надо было срочно.
Выход из шторма
Я начал анализировать ситуацию: смотрел код на бэкенде и на мобилке, снифал трафик между ними, смотрел, как хранятся токены. Чтобы откопать причину проблемы, нужно было полностью воспроизвести ситуацию, в которой она появлялась. Затем надо было отдебажить решение, устранить в нем проблему и внедрить новую версию в прод.
Озарение пришло в конце марта, когда я работал с хранилищем. Я удалял токен — и меня разлогинивало. Я портил код — и меня снова выкидывало. И тут я понял, что… Но давайте по порядку.
Все под подозрением
Однажды я копался в админке Keycloak и заметил, что время жизни офлайн-токена составляет 20 дней. Если за этот период пользователь заходил в приложение, то токен автоматически пролонгировался.
Мы поправили ситуацию: увеличили продолжительность жизни офлайн-токена до 90 дней. Решение казалось простым: пользователя не будет выкидывать на уровне Keycloak, если он хотя бы раз в 90 дней использует приложение.
Поскольку мы получали токены клиента из CRM и отправляли их на хранение в Redis, в теории они могли удаляться из него по TTL. Тогда мы подняли их TTL в Redis также до 90 дней.
Схему построили так:
клиент приходит и авторизуется;
мы выдаем ему токен Keycloak на 90 дней;
получаем токен в CRM на 90 дней;
кладем токены в Redis на 90 дней.
Казалось, что схема правильная, и всё должно заработать без проблем. Но что-то опять пошло не так.
Следующее предположение было таким: мы неправильно интерпретируем ошибки CRM. Мы обрабатывали любую неизвестную ошибку из предположения, что у клиента «протух» токен. В связке magnit-API — CRM мы получали новый токен на 90 дней, а точнее два — access на 2-3 дня и refresh на 90 дней. После смерти access мы шли в CRM с живым refresh, чтобы получить новую связку. Проблема оказалась в самом подходе.
Мы начали внимательнее обрабатывать ошибки в CRM и сбрасывать токены только в том случае, если получали специальный код с конкретным телом.
Так в чем была проблема?
Процесс авторизации в приложении был выстроен так:
Клиент в первый раз заходит в приложение, логинится;
Получает токены Keycloak и CRM — access / refresh;
Мы записываем их в Redis. Когда access «протухает», мы идем из нашего бэкенда в Redis, забираем связку, с refresh идем в CRM;
Запрашиваем новую связку access/refresh, получаем ее и кладем обратно в Redis. Но когда мы это делаем, мы не продлеваем время жизни токенов.
И тут меня обдало холодным потом - это была детская ошибка.
Офлайн-токен жил 20 дней, и клиента стабильно выкидывало по истечении этого срока. И не важно, какие были ошибки — время жизни ключа access/refresh в Redis не обновлялось. Когда мы подняли время жизни офлайн-токена до 90 дней, ситуация наконец-то выровнялась.
Так, с 85 000 лог-аутов в день в конце марта мы вернулись к показателю в 5 000 уже в середине апреля. На этом мы не остановились — взялись за улучшение в CRM-системе.
В июле разработчики CRM выкатили для нас новую авторизацию b2b. Теперь между клиентской базой и Magnit-API есть только один токен, по которому мы обращаемся к CRM. Мы можем совершать с его помощью любые действия по всем клиентам.
Также мы отказались от хранения в Redis. У нас есть своя авторизация в телефоне на базе Keycloak и отдельная авторизация между нашим бэкендом и CRM. Количество пользователей нашего приложения выросло на 300 000 и достигло отметки в 800 000 (DAU).
В день только 0,001% от них теряет авторизацию. Эти разлогины происходят, если клиент заходит в приложение реже одного раза в 90 дней. По нашей бизнес-логике клиент может использовать приложение, если у него активна хотя бы одна карта лояльности. Примерно 1% пользователей продолжает сталкиваться с проблемой. Так происходит, когда у клиента нет ни одной активной виртуальной карты, либо она заблокирована.
Никогда такого не было, и вот опять
Keycloak — это open-source продукт. В России мы не нашли коммьюнити, которое бы помогло нам решить вопрос с клиентскими авторизациями на долгий период времени с большим количеством пользователей. Большинство коллег по цеху используют Keycloak как внутренний корпоративный инструмент.
Я нашел только один русскоязычный Telegram-канал, где можно задать вопрос и обсудить проблемы с такими же разработчиками, как я сам. Еще есть платная поддержка от RedHat. Нам она не подошла, потому что они не дают поддержку «голого» Keycloak, а дополняют его разными фичами.
Сейчас у нас в Keycloak порядка 10 млн клиентов и 15 млн сессий. Нам понадобился не один месяц, чтобы настроить сервис авторизации под нашу нагрузку. Сейчас он потребляет 50 ГБ памяти, и этот объем растет каждую неделю.
В июле 2021 года, после релиза новой версии приложения, мы начали получать новые регистрации. Плюс это совпало с маркетинговой кампанией «Обратно в школу». Прирост пользователей приложения составил 15%, что привело к новым проблемам с Keycloak.
В июле примерно раз в неделю нам приходилось перезапускать Keycloak. В ночь с субботы на воскресенье за 40 минут он прогревал в памяти все токены. Постепенно данных становилось все больше, 40 минут растягивались на несколько часов, а перезапуски требовались уже каждый день. Мы начали выдавать ему дополнительные CPU, но он продолжал падать.
В августе 2021 года Keycloak начал падать уже по несколько раз в день. Вместе с ним падали и авторизации.
Мы думали, что после старта съедался весь CPU. Выдавали ему еще, но Keycloak продолжал падать. Тогда мы дали ему больше процессорной памяти, но он ее просто не потреблял.
Здесь важно помнить, что Keycloak это все-таки java-машина, а она может ограничивать себя по потреблению памяти системы. Мы нашли настройку Xmx, которая отвечает за максимальное количество памяти для java-машины в Keycloak. Когда все пофиксили, то CPU упала, а память начала расти:
Помехи фрода
Борьба с фродом в программах лояльности «Магнита» — важная тема как для нас, так и для наших клиентов. Начать нужно с точного определения: что именно мы считаем недобросовестными действиями. Мы считаем мошенниками тех, кто методом перебора номеров карт или логинов и паролей пытается получить доступ к программаме лояльности, чтобы воспользоваться баллами, специальным предложениями. Чаще всего их крадут, чтобы перепродать.
Причем тут мошенники, если мы уже нашли проблему в неудачно выстроенной архитектуре приложения? Фактор фрода есть всегда. Когда все возможные изменения настроек применены, а небольшое количество пользователей все еще выбрасывает из их аккаунтов, это сбивает разработчиков с толку. Мы не понимали, где реальная проблема с авторизацией, а где попытка фрода. Мошенники постоянно создавали нам шум, из-за чего решение проблемы оттягивалось.
Для примера, у фродеров есть метод «password spraying». Это перебор паролей не отдельно для каждого логина, а сразу для нескольких сотен учетных записей. Так как многие пользователи используют пароли по типу «123…», а у приложения раньше стоял лимит в 5 попыток ввода пароля до блокировки аккаунта, то мошенники с легкостью воровали учетные записи. Соответственно, пользователей разлогинивало, а наш Keycloak грузился еще больше.
Конечно, фрод и методы борьбы с ним в нашем приложении заслуживают отдельной статьи. Скажу только, что этой задачей занималась и продолжает это делать команда информационной защиты «Магнита». Отделив проблемы с Keycloack от попыток воспользоваться данными со стороны мошенников, мы продвинулись в борьбе с лог-аутами вперед.
Как выглядит архитектура приложения сейчас?
Итак, в нашей схеме есть телефон, magnit-API, Keycloak и CRM с b2b-токеном. Начиная с июля этого года авторизация производится по номеру телефона. Выдача логина разделена на два этапа: аутентификацию и авторизацию.
Аутентификация происходит на уровне Keycloak. Мы отправляем одноразовый код клиенту, выдаем ему токен access/refresh. Дальше авторизуем — проверяем, есть ли этот пользователь в CRM. Если не найден, то ведем его на регистрацию. Если есть, то запускаем его в приложение.
Redis из схемы мы исключили, так как теперь у CRM один серверный токен.
Как обойти грабли авторизации
С января по март 2021 года мы перекопали весь код приложения, пофиксили все возможное и невозможное и перестроили архитектуру.
За это время мы выяснили, что информации о Keycloak в открытых источниках почти нет. Поэтому я собрал несколько полезных выводов из собственного расследования проблемы лог-аутов:
Не стоит использовать Keycloak в качестве инструмента SSO для b2c-продукта. Такие решения лучше писать самим с помощью готовых инструментов. Оптимальная схема: команда авторизации пишет свой сервис на основе библиотек, используя любой язык программирования и реляционку. А обычный jwt access/refresh токен хранит в базе данных и оптимизирует запрос под свои нужды.
Нужно разделять логин на аутентификацию и авторизацию с самого начала. Если аутентификация и авторизация объединены, проблему сложно идентифицировать. Именно поэтому мы не сразу поняли, в чем дело — это пользователь неправильно ввел код или у него проблемы с правами в его программе лояльности. До июля 2021 года в предыдущей версии приложения было две кнопки — для входа и для регистрации. Это приводило к тому, что пользователи не понимали, на какую кнопку нужно нажимать. Заставлять клиента напрягаться — точно не наш выбор.
Авторизация, как и любая другая фича, должна покрываться метриками. Да и само приложение должно проектироваться с фокусом на мониторинг возможных проблем. Если бы мы видели, что у нас каждые 20 дней пропадают ключи из Redis, мы могли сэкономить множество времени. Нужно мониторить запросы и статусы ответов, четко понимать, какой запрос клиента приводит к разлогину, смотреть на состояние активных истекающих сессий, количество созданных сессий и другие параметры.
Кто еще сталкивался с проблемой разлогинов пользователей? Поделитесь своим опытом, расскажите, как настраивали память, CPU и авторизацию токен-exchange?
Комментарии (73)
NickSin
28.10.2021 17:36А почему магнит до сих пор не сделает нормальных экспорт qr-кода в wallet? Он у вас динамически меняется и поэтому через какое-то время карта в кошельке становится не актуальна. Зачем тогда вообще делать это - не понимаю. Может поясните?
arxell Автор
28.10.2021 20:13На добавление бонусов карта в wallet актуальна, на списание надо пользоваться приложением, тк там есть особенности связанные с фродом и ИБ
SiteCenter
29.10.2021 10:02А почему бы для списания бонусов не использовать геолокацию из приложения (сопоставлять её с конкретным магазином) и, если ваша система не уверена, что код показывает владелец карты (например если геолокация заблокирована) - отправлять уведомление с кодом, который нужно продиктовать на кассе? Ведь таким образом в большинстве случаем будет достаточно показать Wallet, а при попытке списать баллы по чужой карте система потребует код, который придет владельцу, заодно человек будет в курсе, что кто-то пытается списать бонусы без его ведома (и в таком случае можно предлагать создать новую карту с сохранением бонусов, например написав «Похоже кто-то пытается воспользоваться вашей картой, если это не вы - нажмите обновить карту»). Сразу и фроду конец, и клиенты чувствуют заботу
arxell Автор
01.11.2021 20:57Cписание бонусов уходит глубоко во внутрь нашей CRM системы, которая для нас black box и там не все так просто как кажется на 1й взгляд
yri066
28.10.2021 20:13+2В приложении не хватает поиска товаров и было бы классно узнать стоимость товара отсканировав штрихкод, т.к. в магазине у дома полная неразбериха с ценниками которую не могут решить продолжительное время.
arxell Автор
29.10.2021 08:34сканер штрифкодов классная фича, она у нас находится в backlog'е
Grad02
01.11.2021 09:11Вы не ответили на главную часть вопроса: не хватает поиска товара. А ещё не хватает поиска конкретного товара по магазинам города. Вот приспичило супруге подарить конфкиы Merci, а мне пришлось 4 магазина объездить в поисках этих конфет. Понятно, что товар могут купить перед вашим носом, но всё же. Леруа же показывает, а значит функция вполне работает.
И кстати, вам бы и в леруа наладить разлогирование????
arxell Автор
01.11.2021 09:12Согласен, что с поиском товара в конкретном магазине и среди всех магазинов еще надо работать. C этим, к сожалению, есть ряд проблем.
Arioch
18.11.2021 18:42Я вам больше скажу, не хватает поиска товара ВНУТРИ магазина.
Вот пришёл я в новый магазин, или даже старый, но там гений-мерчандайзер опять полки передвинул. КУДА мне идти за условным пакетиком сливок, который я увидел в тележке проходящего мимо покупателя? Пусть телефон меня "за руку" отведёт к этой полке, используя хоть b4le маячки, хоть распечатанные и наклеенные на стену QR-коды.---
@arxellи ещё, для сканера штрихкодов - требуется сеть, то есть интернет. То есть деньги и качество связи. Например в подвальных "Перекрёстках" с этим жжжжжж. Они, правда, пытаются это решить, видимо. Во всяком случае в их программе появилась функция "авторизация по Wi-Fi", но чтобы она работала - такого я не видел. Хотя казалось бы, чего проще-то? на входе в магаз QR-Code с настройками Wi-Fi, после чего программа лезет на фиксированный TCP-адрес (DNS может браться не из DHCP, а быть прибитым к какому-нибудь OpenDNS) и выясняет, в каком она магазе. А по Wi-Fi быстро и бесплатно сверяется с локальной БД магаза, чем по всей России зачем-то лезть через центральный мега-сервер. Но... завязка в программе у X5RG есть, а реально не работает. Это дважды бесит, что в программе у них и касса встроенная, чем париться в очереди - ткнул кнопочку в телефоне и на выход - а фиг вам...
Grad02
18.11.2021 19:02Так мерчендайзер специально полочки передвинул. Это прям в их азбуке прописано, что нужно периодически менять товары с полками, чтобы вы обходили ВЕСЬ магазин в поисках сливок и попутно набрали полную корзину незапланированных товаров. Так что, сомневаюсь, что организуют навигацию внутри одного магазина. Внутри торгового центра -да.
mysless
28.10.2021 21:07+3Использование спецификации oauth2 с пониманием этой спецификации и осознанной настройкой токенов, на протяжении всего их жизненного цикла, сильно облегчило бы вам жизнь с самого начала.
А так прошли неплохой путь повышения инженерной культуры в конкретном продукте. Главное, не останавливаться на достигнутом)
Sergey-S-Kovalev
29.10.2021 08:28+1А проблему с тем что пароль было невозможно восстановить уже починили? СМС в принципе не приходили.
Мне пришлось просто удалить с телефонов всех возрастных родственников приложение с год назад, что бы оно им на глаза не попадалось, поскольку их разлогонило, а обратно зайти не удавалось. Номер зарегистрирован, а пароль не восстановить, не говоря уже про сомнительное решение с указанием даты рождения при восстановлении.
mSnus
29.10.2021 11:04-1В России мы не нашли коммьюнити, которое бы помогло нам ...
Я нашел только один русскоязычный Telegram-канал ...
Простите, а зачем вам именно русскоязычные ресурсы? У вас нет в команде людей, которые знают (технический) английский?
Tekill
29.10.2021 13:57+2Искали ресурсы, где есть располагающая для общения аудитория. Заметил, что в русскоязычный канал иногда захаживают иностранцы и никто им не отказывает в ответе.
artebel
29.10.2021 19:26-1Вы сделали самое главное в приложении. В отличии от приложения для КБ, сделали функцию экспорта карточки в Wallet, а не заставили пользователей использовать карту только из приложения. Большое спасибо
arxell Автор
01.11.2021 09:10Спасибо! Пока сделали лишь mvp, в apple/google wallet'ах можно еще много чего сделать.
artebel
29.10.2021 20:57+2Когда появится баг баунти программа у Магнита, такая же, как у Азбуки Вкуса?
arxell Автор
01.11.2021 09:09Можно ссылку что за программа?
artebel
01.11.2021 11:06arxell Автор
01.11.2021 19:49-2что-то страшно)
artebel
01.11.2021 19:51По-моему, это хороший вариант получать фидбек об уязвимостях, мотивация не эксплуатировать их на вашем приложении, а получать за это денежку в правовом поле
pyrk2142
06.11.2021 04:18+4Субъективно, никогда не стоит рекомендовать кому-то завести Bug Bounty, если у них нет понимания, зачем им это нужно. Иначе будет, как у похожих компаний, когда у них нет инженерной культуры, чтобы понимать ценность посылаемых проблем, но при этом энергии менеджмента хватает, чтобы каждую проблему превращать в задачу по сохранению денег для менеджмента.
Hardoman
30.10.2021 23:18С одной стороны молодцы, что проделали такую работу.
С другой - это максимально дурная практика использовать фреймворки, API и вообще решения, которые не имеют поддержки и уж тем более подробной документации и большого комьюнити. Откуда вообще любовь у отечественных разработчиков использовать такие поделки?!
arxell Автор
01.11.2021 09:08C вашим мнение согласен, но если речь про keycloak, то мне он достался от аутсорсеров.
Hardoman
01.11.2021 19:57Уверен, что вы прекрасно знакомы с такими понятиями как technical debt и brownfield. И что с ними надо бороться, и чем раньше, тем лучше, а не тянуть лямку.
arxell Автор
01.11.2021 20:55сейчас как раз строим roadmap развития нашей системы авторизации и отказа от keycloak в сторону чего-то самописного на основе ory/fosite
random1st
01.11.2021 19:39А что, вы знаете много альтернатив keycloak? На самом деле поддержка у него вполне себе есть - слыхали про RedHat?
arxell Автор
01.11.2021 19:48redhat предоставляет свой keycloak
"Нам она не подошла, потому что они не дают поддержку «голого» Keycloak, а дополняют его разными фичами."
Сейчас мы смотрим в сторону ory/hydra, а также в сторону ory/fositerandom1st
01.11.2021 20:13а можно немножко больше раскрыть тему? Очень интересно - никогда не встречал вот прямо такой причины отказа.
Tekill
02.11.2021 10:56Раскрою немного наши мысли, почему мы начали смотреть другое решение:
- RedHat дает по сути другой продукт на базе keycloak с другой инфраструктурной начинкой - у нас итак Java решение размывало стек технологий, а тут стало бы еще больше
- Хороший такой vendor-lock в части технологий, поддержки, инфраструктуры. Авторизация для нас ключевой цифровой сервис, от которого нам нужна гибкость и возможность изменения быстрее того, что предлагает поставщик
- Все же RH-SSO и Keycloak больше относятся к системам класса Workforce IAM со всеми вытекающими особенностями. Для авторизации клиентов подходит больше Customer IAM, который по функциональности во многом схож, но имеет свои доп плюшки в виде интеграций с CRM, сервисом само регистрации, расширенными правилами политики безопасности, cloud ready архитектурой
Color
04.11.2021 00:11Расскажите, почему ory?
Тоже на него поглядывал, но интересует взгляд в разрезе системы с большой нагрузкой и/или кубовыми интеграциями.
vsb
04.11.2021 21:00Keycloak это самый популярный в мире (по крайней мере из open source) продукт из этого сегмента. Обычно любовь как раз к своим посконным велосипедам (грешен, каюсь).
kalyaka
02.11.2021 11:29Кроме разлогинивания приложения есть еще проблема. В моем локальном гипере "магнит семейный" плохо работает мобильный интеренет, и телефон на кассе регулярно сваливается с LTE на Edge. И когда в это время открываешь приложение для показа QR-кода, вместо кода можно бесконечно наблюдать заставку "Скрепыши3 Пора скрепышарить на всю!". И ее не закрыть, не скрыть.
arxell Автор
02.11.2021 15:21Да есть такая проблема. Сейчас думаем как показывать карту на добавление баллов без интернета, также вы можете добавить карту в wallet и показывать его.
Hardoman
04.11.2021 21:37Тестируете скорость соединения до сервера, и если оно ниже допустимого, просто показываете карту, отключив просо и рекламу
arxell Автор
02.11.2021 15:22прямо сейчас есть небольшой хак =)
включите режим полета и попадете в приложение
Carburn
05.11.2021 00:00+1Здесь важно помнить, что Keycloak это все-таки java-машина, а она может ограничивать себя по потреблению памяти системы. Мы нашли настройку Xmx, которая отвечает за максимальное количество памяти для java-машины в Keycloak. Когда все пофиксили, то CPU упала, а память начала расти:
Почему в логах не посмотрели причину падения?
pyrk2142
06.11.2021 04:40+1ИМХО, причина очень простая и грустная: IT многих крупных компаний зависит от того, может ли оно нанять толпу кодеров, которые будут издавать Buzz Word или нет.
115 тысяч человек разлогинивает в сутки, но при этом мониторинг не реагирует на это? А после обновления всего 7 тысяч странных событий в сутки, но мониторинг все еще не реагирует? Потенциально, это куча срабатываний, которые надо разбирать, но этим занимается IT, которое не до конца понимает по логам, почему это вообще происходит? А если это серьезные случаи мошенничества? Где сквозные логи и отслеживание проблем?
С другой стороны, я крайне уважаю Магнит за то, что они рассказывают о внутренней кухне, о реальных проблемах, а на о том, с чем как будто сталкиваются компании, которые работают с огромным количеством клиентов.arxell Автор
06.11.2021 10:03сейчас есть и метрики и трейсы и сквозные логи на основе того же trace_id
тогда не было ничего =(
Tirex
05.11.2021 17:40Если все таки решитесь остаться на keycloak, обновитесь на 15-ую версию. Там добавили наконец то "lazy start", значительно поможет со временем старта.
arxell Автор
06.11.2021 10:04да, но так вот сходу обновиться с 12й до 15й у нас не получается
в этот процесс надо закапывать кучу ресурсов devops
Tirex
06.11.2021 10:13Ну можно что быстрее будет разработчику разобраться, не исключено. Если перегрузка кейлока сильно влияет на время простоя.
Ну и там не все так страшно.
ettychel
24.11.2021 22:04Даааа, проблемка с переходом на новую версию есть, сам недавно перешёл с 6-ой на 15-ую, а мечтал перейти с 6-ой, ещё когда была 8-ая))
Но вот проблемка была у них с БД из коробки (H2 БД), а точнее с версией адаптера и вот только недавно решил таки проблемку и переехал)
В остальном мигрировать на новую версию проще чем кажется на первый взгляд, а я вот вообще не DevOps и делаю это сам, ну и масштабы у меня не такие огромные)
И да, 15 версия очень вкусная получилась)
edst_land_ru
06.11.2021 16:06У меня было такое - кассир просила обновить мое мобильное приложение, без этого не могла списать бонусы. Однажды я обновил приложение, стоя в очереди в кассе, прям перед покупкой, но это не помогло ))
Еще немного напрягает необходимость помнить код с задней стороны карты, и необходимость уведомлять кассира о своем желании купить товары за бонусы до того, как она начнет их (товары) считать.
Может, технологии Тандера уже ушли вперед, просто я давно в их магазинах не был.
marliotto
08.11.2021 18:03+1@arxell огромная просьба не блокируйте интерфейс при запуске приложения и ожидания ответа от сервера. Объясню почему. В магазинах где я живу, часто связь на уровне edge и практически не работает. Я стою на кассе, запускаю приложение, и смотрю на заставку, жду пока приложение поймет, что до сервера не достучаться с таким уровнем связи, а это пустая трата времени и задержка очереди в магазине. В итоге перед запуском приложения перевожу телефон в режим полета и тогда приложение шустро запускается.
Nordbloud
09.11.2021 10:181) редис почему именно он. Внутри кейклоака есть встроенный infinispan и Действительно при больших нагрузках кэш надо выносить, но почему именно редис. и где кэш хранится сейчас?
2) "Мы нашли настройку Xmx, которая отвечает за максимальное количество памяти для java-машины в Keycloak." После всех махинаций с редисом огромными затратами по железу и даже настроенную связку с вашей CRM вы не ограничивали джаву машину?
3) "Так как многие пользователи используют пароли по типу «123…»" на уровне кейклоака разрешенный реджекс паролей разве не ограничили?
4) не слово не сказано как кластеризуете. мониторинг? какие метрики собираете. Используете jmx_exporter или keycloak-metrics-spi.
А так видно, что проделана огромная работа по улучшению сервиса авторизации, но статья кажется не полной.arxell Автор
09.11.2021 10:301) не понял про редис и причем тут кейклок
2) она была ограничена 16гб и казалось , что все хорошо ведь выедала она только 14
3) пароли хранились в CRM
4) используем keycloak-metrics-spi
mkll
10.11.2021 08:31Давно точу зубы на ваше приложение. Красивое, в целом удобное, но! Это же не приложение — это 5 приложений, объединенных одним таббаром. Каждая вкладка независима от других, сама себе на уме, "всё свое ношу с собой, ни с кем не делюсь".
Нет, я понимаю, что такой подход как раз в духе современных веяний — модульность, независимость, loosely coupling, но как-то за всем этим забывают о том, что приложение предназначено для того, чтобы пользователям удобно было, а не для того, чтобы разрабы добавляли строчки в перечень освоенных скиллов и рассказывали потом на конференциях, как они мужественно внедряли VIPER.
Вот смотрите, предположим, юзер тапает по иконке, но приложение не запускается, а выходит из фона (потому что недавно оно уже запускалось). Мы на первой вкладке делаем pull-to-refresh, видим обновленный баланс бонусов и баланс Magnit Pay. Идем на последнюю вкладку — там цифры старые. Почему? А потому. Надо и там pull-to-refresh. Информация двух вкладок пересекается, легко и просто добывается с бэкенда вообще одним запросом, но нет — юзер должен сделать два. Ваш бэкенд должен обработать тоже два. Вы целую статью написали о том, как много у вас пользователей, как велика нагрузка на бэкенд — странно, что обрабатывать вдвое больше запросов в таких условиях не считается у вас непозволительной роскошью. Т.е. тут все в проигрыше — и вы, и пользователи. Зачем так делать?
Баланс Magnit Pay тоже добывается дважды, независимо, на двух разных вкладках.
Когда приложение возвращается из фона — данные не обновляются. Почему? Почему вообще считается приемлемым показывать пользователям левые, не соответствующие действительности, устаревшие данные? Почему считается нормой врать пользователю в интерфейсе? Потому что так делает фэйсбук и прочие? Да не надо перенимать у грандов плохие практики, надо хорошие перенимать.
Знаете, к чему приводит необновление данных? К тому, что я перестаю им доверять, и даже если они актуальны, принудительно обновляю их на всякий случай. Чтоб быть уверенным хотя бы на 99%. Т.е. разработчики намеревались получить вдвое меньше запросов, а получили вдвое больше. Ожидания vs реальность.
Выше писали про сложности с показом бонусной карты, если интернет плохой. Простите, я правильно понял, что карту приложение не хранит локально, а каждый раз дергает с бэкенда? Карта — это такая сущность, которая обновляется раз в несколько месяцев, если вообще обновляется — зачем каждый раз ходить за ней на бэкенд? Ну а блокировка интерфейса при старте — до момента, когда с сервера загрузится контент для первой вкладки — это вообще что-то за гранью, это, архитектурно, какая-то студенческая поделка, а не приложение федеральной торговой сети. Как такое вообще могло уйти в прод.
Am1GO
16.11.2021 12:55О, помню-помню как мы в своё время запускали первую версию МПМ на томкатах за двумя балансерами tengine между ними - это ведь был бекэнд первой публичной аппы Тандера в маркетах. А ещё примерно в это же время хоронили первую версию интернет-магазина на ATG+Endeca, к которой планировался-планировался в дальнейшем личный кабинет покупателя с бонусной системой, да так и не выпланировался.
До сих пор диву даюсь пошто ИМ закопали - в итоге уже вы его и бонусную систему всё-равно запустили, да только одними из последних в крупном российском ритейле, а мвидео до сих пор на Oracle Commerce живёт и в ус не дует.
arxell Автор
16.11.2021 12:56ритейл сложная штука, сложно внедрять что-то новое, у моего отдела к счастью есть такая возможность
hrensgory
18.11.2021 17:23+1Странная статья.
"Однажды, копаясь в админке ...", "Мы нашли настройку Xmx..." Странно что не упомянута проблема поиска выхода из vi )))
Инженеры-то у вас есть вообще в команде, знающие или способные разобраться в протоколе oauth/openid-connect, ну или которые знают что такое вообще application server. По статье такое впечатление что в "Магните" сплошной молодой, дружный коллектив и google-driven-development.
Извините.
Gengenid
Разве это называется не password spraying?
arxell Автор
Да, вы правы. Это техническая опечатка :)