Попробовать
демоверсию
Бесплатная демоверсия позволяет ознакомиться со всеми возможностями нашего биллинга
+7 499 940-95-05

DoS своими силами: К чему приводит бесконтрольный рост таблиц в базе данных

Биллинг — сложная система, одним из важнейших компонентов которой является база данных. В ней содержится множество разнообразных таблиц, которые со временем разрастаются до больших размеров.

Для того, чтобы этот рост не замедлял работу базы, в Oracle, PostgreSQL и других СУБД существует эффективных механизм секционирования (partitioning) — однако его не всегда можно применять. К примеру, он отсутствует в относительно бюджетной редакции системы Oracle Standard Edition.

Исторически сложилось так, что в нашем биллинге для операторов связи "Гидра" мы не реализовывали собственный механизм секционирования, ограничившись созданием руководства для клиентов, в котором были описаны шаги для отслеживания роста таблиц и минимизации возможных проблем с быстродействием системы. Как выяснилось в дальнейшем, этого было явно недостаточно.

Предыстория

Биллинг "Гидра" используют операторы связи, а значит, одной из самых важных и крупных таблиц в базе является та, которая отвечает за хранение данных о PPP-сессиях и CDR абонентов провайдеров интернета или телефонии. В этой таблице хранятся данные о начале, завершении и времени ее последнего обновления, а также, информации об абоненте, инициировавшем ее, например, IP-адресе, с которого он установил соединение.

Чем больше в базе оператора связи абонентов, тем быстрее растет таблица с данными о сессиях. Самым простым решением в этой ситуации выглядит простое удаление старых записей время от времени. Однако по российскому законодательству провайдеры обязаны хранить данные о доступе абонентов в сеть, которые могут понадобиться правоохранительным органам, на протяжении трех лет. 

При разработке биллинга еще много лет назад мы учли этот момент и допустили, что объем таблицы с сессиями может достигать 15 млн строк. По достижению этой планки должен был запускаться скрипт выгрузки и архивации данных. 

Тем не менее, необходимость мониторинга размеров таблицы сохранялась — если совсем не обращать на это внимания, она могла вырасти и до значительно больших размеров. Что в конечном итоге и произошло у одного из наших клиентов.

Все плохо

По разным причинам специалисты этого провайдера не настроили мониторинг размера таблицы с сессиями и не подключили наш сервис мониторинга (специально для ленивых клиентов мы создали специальный инструмент, который способен собирать метрики работы системы и оповещать о возможных проблемах). 

Таблица росла, причем об этом не знала ни компания, в чьей базе все происходило, ни наша служба поддержки. В конечном итоге ее размер составил 36 млн строк, что более чем в два раза превысило максимальный лимит. 

У этого конкретного оператора абоненты попадали в сеть по VPN, а значит, им нужно было получить доступ к VPN-серверу, который уже по протоколу RADIUS обращался к базе данных.

В результате в день, когда в сети оператора случился всплеск активности абонентов вследствие перезагрзуки одного из магистральных коммутаторов, RADIUS-сервер биллинга не смог своевременно авторизовать нахлынувший поток абонентов. 
Произошло вот что — производительность выборок из таблицы сессий в определенный момент серьезно упала. Это привело к тому, что процесс авторизации абонентов не успевал завершиться в отведенное для этого время. В результате пользователи стали получать отказы доступа в сеть и повторно отправлять запросы на авторизацию, которые слились в настоящую лавину, захлестнувшую систему.

При таймауте обработки запроса VPN-сервер посылает еще пару запросов на авторизацию — и для их обработки опять необходимо прочитать данные из той самой огромной таблицы. И только после этого абонент увидит сообщение об отказе в доступе. Естественно, что получив такое сообщение, пользователь пытается установить соединение повторно, и все повторяется вновь. Таким образом возникла ситуация с настоящим DoS сервера RADIUS.

Что делать

Столкнувшись с серьезными проблемами авторизации собственных абонентов, провайдер обратился в нашу службу поддержки. Причину проблем удалось установить очень быстро — слишком уж большой была таблица с сессиями, кроме того в топе запросов по IOWAIT находились те самые запросы на чтение из таблицы сессий. Исправить сложившуюся ситуацию можно было единственным способом — очисткой строк таблицы в БД. При этом данные потерять было нельзя, так что их предварительно нужно было куда-то скопировать.

Поэтому му выгрузили записи в CSV-файлы, тем самым уменьшив объем таблицы. Чтобц пустить в сеть часть абонентов в процессе этих работ, был также активирован автономный режим работы RADIUS-сервера. Он заключается в использовании механизма кэширования — в кэше сохраняются данные о результате последней авторизации абонента, так, чтобы при потере связи с биллингом сервер мог провести авторизацию пользователей с использованием этих данных.

Механизм автономного режима на тот момент был довольно прост и имел свои недостатки — например, данные в кэше не находились в постоянной репликации с базой данных, поэтому в них могли быть расхождения. Это значит, что если пользователь последний раз авторизовался месяц назад, а затем не платил за интернет и должен был быть заблокирован, то при работе в автономном режиме на основе сохраненной записи месячной давности система его авторизует — или не авторизует того, кто имеет право на доступ, но был заблокирован в последнюю попытку соединения. Но в сложившейся ситуацией это было меньшее из зол.

В итоге, когда таблица с сессиями сократилась в размере до 30 млн строк, авторизация абонентов вновь заработала, и мы смогли отключить автономный режим работы RADIUS-сервера. 

Уроки

Эта история дала нам немало пищи для размышлений. Выяснилось, что мало просто выдать клиентам рекомендации или дать платную возможность мониторинга важных моментов — если в конечном итоге выполнение действий отдается на откуп клиенту, то стоит ожидать, что он не станет их осуществлять. Поэтому мы реализовали новые схемы мониторинга, которые позволяют нам самим отслеживать возникновение проблем в клиентских системах.

Теперь при обнаружении потенциально опасной ситуации, подобной описанное выше, создается заявка в службу поддержки «Латеры», с которой мы детально разбираемся. 

Кроме того, мы изменили и подход к организации работы с данными и процесса кэширования RADIUS-сервера. Все это вылилось в создание механима архивации в новой версии биллинга — он предусматривает архивирование данных постоянно растущих таблиц в отдельную схему Oracle. Этот процесс идет в фоновом режиме и не влияет на работу биллинга. Причем для клиента этот механизм работает таким образом, что при создании отчетов по сессиям, он получает одновременно данные из основных и таблиц из схемы с архивом, без «плясок с бубном».

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

 

Если описывать схему кратко, то каждый сервер доступа состоит из нескольких компонентов:

  • База данных с профилями абонентов и данными о потребленных услугах.
  • Наше приложение под кодовым названием HARD. Оно отвечает на HTTP-запросы, которые идут от следующего компонента.
  • FreeRADIUS — непосредственно сервер, реализующий стандартный AAA-протокол — RADIUS. Он непосредственно общается с абонентской сетью и переводит запросы из бинарного формата в обычный HTTP+JSON для HARD.

 

Базы данных всех AAA-серверов (это MongoDB) объединены в группу с одним основным узлом (master) и двумя подчиненными (slave). Все запросы из абонентской сети идут на один AAA-сервер, при этом необязательно и даже нежелательно, чтобы им был сервер с основной БД.

Если что-то пойдет не так, и один из компонентов откажет, то, абоненты не потеряют доступ к услугам. Скорее всего, они вообще ничего не заметят.

Кроме того, мы продолжаем следить за размером таблиц, в том числе отслеживаем объём таблицы сессий — никто не застрахован от роста данных в неархивный период.

На этом все, подписывайтесь на наш блог, чтобы не пропустить ничего интересного!

16.02.2016

Другие публикации

По определению консалтинговой компании Deloitte, текущий период в мировой экономике характеризуется неопределенностью. Поэтому бизнес во всем мире стремится к оптимизации и снижению издержек. Сегодня мы рассмотрим несколько способов, с помощью которых компании из разных стран экономят уже сейчас.
В новой версии Гидры мы по традиции продолжили работу над коммерческими возможностями биллинга. Встречайте контрактные тарифы! Другие мелкие улучшения упрощают интеграцию Гидры с внешними системами.
Компании из самых разных отраслей бизнеса сталкиваются с часто повторяющимися бизнес-процессами, связанными с обработкой заявок. В большинстве отраслей выполнение типовых работ и услуг — это сложный и разветвленный бизнес-процесс. Мы много размышляли об этих проблемах и создали инструмент, который каждая компания могла бы легко адаптировать под себя — новый продукт Гидра OMS
В одном из наших постов мы уже описывали ситуацию, в которой бесконтрольный рост таблиц в базе данных одной компании-пользователя нашей системы привел к настоящему DoS. Сегодня речь пойдет о еще одном интересном случае внезапного сбоя, который сделал «день смеха» 1 апреля этого года совсем не смешным для службы поддержки «Латеры».
В Instagram развертывание backend-кода (основная программно-аппаратная часть, с которой работают клиенты) происходит от 30 до 50 раз в день, каждый раз, когда инженеры подтверждают изменение оригинала. И, по большей части, без участия человека — сложно в это поверить, особенно учитывая масштабы соцсети, но факт остается фактом.
В этой заметке речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2.
Интересный материал о работе с JSON, и в частности, о применении ограничений опубликовал в своем блоге разработчик Магнус Хагандер (Magnus Hagander) — в нашем блоге мы решили представить его основные идеи.
Успешно завершили интеграцию биллинга Гидра с порталом NEXT TV.
В этой заметке мы рассказываем о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkušić) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки и делимся своим опытом.
Разработчики из американской компании Gaslight написали интересный материал о том, почему организация, известная своей любовью к Ruby и Ruby on Rails, решила инвестировать в освоение новых технологий — например, Clojure. Мы тоже работаем с этим языком программирования, поэтому решили выделить главные тезисы команды Gaslight в отдельный материал.
Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.
Немецкий журналист и хакер Ляйф Риге (Leif Ryge) написал для издания Ars Technica интересный материал о том, что современный подход к организации обновлений программного обеспечениях несет в себе серьезные риски информационной безопасности. Мы представляем вашему вниманию главные мысли этой заметки.
Инженер проекта Haleby.se написал материал, в котором рассказал о причинах выбора в качестве инструмента оркестрации Docker-контейнеров технологии Kubernetes. Мы представляем основные мысли этой заметки.
Адаптация заметки бывшего сотрудника Amazon про то, почему плохие продукты пользуются большим успехом, опубликованная в авторской колонке Дмитрия Копловича на Rusbase.
Инженер компании Akalak & Neo Technology Горка Садаковски (Gorka Sadakowski) написал интересный материал о том, как использование графовых баз данных может в режиме реального времени предотвращать мошенничество в сфере электронной коммерции. Мы представляем вашему вниманию основные мысли этой заметки.
Платежные протоколы уязвимы — об этом рассказали немецкие исследователи информационной безопасности на конференции Chaos Computing Club. Предлагаем вам адаптированный перевод их выступления.
Наша адаптация заметки разработчика и системного архитектора Михаэля Виттига о наиболее распространенных ошибках в использовании Amazon Web Services.
Наш адаптированный перевод заметки главного разработчика Azure Джеффа Уилкокса, о том, как более двух тысяч членов команды проекта переезжали на GitHub.
Представляем вашему вниманию адаптированный перевод одной из глав книги «Архитектура open-source-приложений», в которой описываются предпосылки появления, архитектура и организация работы популярного веб-сервера nginx.
Наш сегодняшний пост посвящен тому как мы писали софт для контроля работы удаленных сотрудников.
Сегодня мы расскажем про устройство системы подпольного банкинга Хавала, которая возникла еще в VIII веке и до сих пор пользуется большой популярности в странах Среднего Востока, Азии и Африки.
Мы уже рассказывали о том какие проблемы могут возникнуть у компании при саомостоятельной разработке сложных систем. Сегодня мы поговорим о том, как мы работали над повышением отказоустойчивости «Гидры».
Адаптированный перевод заметки главного инженера LinkedIn Джоша Клемма о процессе масштабирования инфраструктуры социальной сети.
Адаптированный перевод заметки инженера финансового стартапа Stripe о том, как его команда мигрировала огромное количество записей в базе данных.
По нашим оценкам, около половины российских операторов связи используют самописный (или переписанный до неузнаваемости простенький «покупной») софт. Сегодня мы поговорим о возможных минусах такого подхода.
Появились маркетинговые инструменты для сегментации абонентской базы, управления скидками и пакетными предложениями.
Подробнее читайте в блоге.
В новой версии мы полностью переработали механизм работы с услугами. Это сразу дало несколько серьезных улучшений, но полностью все заложенные в новой версии возможности будут раскрыты в следующих версиях.
В новой версии была полностью переработана система прав доступа. Новая система уникальна и позволяет реализовать самые смелые замыслы по разграничению доступа сотрудников к биллингу.

Начните знакомство с Гидрой прямо сейчас

Попробовать демоверсию Купить Гидру

Оформление демоверсии

Пожалуйста, укажите реальный email, на него придут данные для доступа в демо.
Все поля являются обязательными для заполнения.
.hydra-billing.com

Для вас будет развернута персональная облачная версия Гидры.
Нажимая кнопку "создать демоверсию" вы соглашаетесь с
Политикой обработки персональных данных.

Мы можем вам перезвонить

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Напишите нам!

Ваша компания

Услуги, которые вы предоставляете:

Нажимая кнопку "отправить" вы соглашаетесь с
Политикой обработки персональных данных.

Скачать буклет

Ваш адрес:

Хотите узнать больше?

Рассылка делается примерно раз в месяц. Мы обещаем бережно хранить ваш электронный адрес и никому его не выдавать даже под пытками.