Что не так с Asterisk Realtime и как с этим жить

Не так давно я опубликовал пост, в комментариях к которому было высказано мнение, что у астериска есть некоторые проблемы с механизмом realtime. Так вот, на данный момент, вынужден согласиться с этим утверждением, более чем полностью. Как следствие, встал на путь разочарования asterisk'ом как платформой-"конструктором". Почему и как это произошло и при чём тут tarantool, а самое главное, что со всем этим можно сделать? Давайте разбираться под катом.

Да-да, и обезьяны падают с деревьев

Но как так, имея большой опыт в интеграции asterisk'а как voip-платформы, опыт в разработке CTI-приложений, в конце концов, в обработке и сопровождении большого объёма транзитного voip-трафика, кастомным биллингом, отчетной системой и статистикой, узнаю о таких смешных проблемах realtime-механизма в asterisk с определённой долей удивления.

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

Вот типичный usecase: куча пиров запиханных в базу, и под большим количеством астер начинает течь. Буквально совсем недавно мне довелось наблюдать такую картину: астериск, рабочая лошадка, ~5K пиров и все в базе, диалплан простой как три копейки – в общем, классика. Со временем астер начинает подтекать со следующими симптомами:

• Первым отваливается сам стек sip;

• Операции по сбросу либо не приводят ни к чему, либо подвешивают систему в целом;

• Всё, что есть на данный момент, кое-как ворочается, новые коннекты/звонки отбиваются с отсылкой к памяти.

Но нужно отдать должное, что при такой организации лошадка кряхтела, стонала и скрипела, но отрабатывала свой "световой" день. Забегая вперёд, скажу, что с идентичной конфигурацией и с последним астериском лошадка иногда отказывалась даже выходить из загона, кто бы что ни говорил.

И вот тут начинается мучительный процесс поиска виновника торжества. Как так? Рядом же legacy-площадка с ~10K пиров и на более старой версии, но с организацией хранения пиров по старинке: один пир – один конфиг-файл. Всё летает – не шевелится еле-еле, а прям летает: отзывчивый reload, память не течёт, есть даже своего рода аналог realtime API под конфиг-организацию. Почему так?

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

Чем такого лечить, проще нового сделать

Становится очевидным, что в данном конкретном случае проблемы кроются в backend'е движка базы в связке с realtime-организацией – что-то они делают не так и не то, и от этого астериску впоследствии становится плохо. Но, к сожалению, на реализацию движка мы повлиять не можем – sorcery немного исправляет положение, но всё равно не то пальто. Варианты типа поменять СУБД не рассматриваются в виду наличия сложного/запутанного background'а.

Так все же, что мы можем сделать, что бы механизм realtime астериска немного схуднул? Из толпы доносятся голоса: «Напиши нужный тебе модуль работы с СУБД с той логикой и поведением, которое тебе нужно, заоптимизированный по самые уши». «Спасибо, не дождетёсь», – отвечу я. Как представлю этот кошмар с последующими обновлениями, сопровождением, а как итог – возможный форк. Нет, хватит, этого я уже наелся. Так что держим мысль в голове: никакого hardcode, используем по максимуму возможности платформы.

А что, собственно, нам может предложить платформа для решения поставленной задачи?

Выбор не так велик:

• ODBC: UnixODBC-подсистема, поддерживает множество разных БД.

• MySQL: нативная поддержка MySQL.

• PostgreSQL: нативная поддержка PostgreSQL.

• SQLite/SQLite3: быстрый/родной движок для небольших БД.

• LDAP: поддержка LDAP-директорий.

• cURL: поддержка HTTP-запросов в веб-приложения и связанные с ними БД.

ODBC/MySQL/Postgres/SQLite – проблема в командной игре механизма realtime и базы, меняя шило на мыло, фундаментальных проблем не исправить.
LDAP – ну тоже, такое себе решение, переписывать backend под LDAP. Люди меня не поймут – особенно те, кто будет это переписывать.

Так что, остаётся cURL?

Я художник, я так вижу

Собственно, что в этом такого? Разворачиваем "умный" кэш перед основной базой и организовываем доступ к нему поверх HTTP-запросов. Backend остается в первозданном состоянии, разработчики/сопровождающие довольны, и всё работает в прозрачном режиме – и волки сыты, и овцы целы.

А производительность? Хм, ну давайте прикинем. Реализация движка работы с базой – не две строчки кода, реляционная модель может нести слишком много накладных расходов. А если посмотреть реализацию cURL, скажем, в 11-й версии (по моему мнению, это последняя версия с оптимальным соотношением "цены" и "качества"), то мы увидим интерполяцию в вызов функции CURL диалплана. И что же нам это даёт? Прежде всего, надежду, что сломается первым "лифт", а не "лестница". Стоимость вызова HTTP-запроса в разы меньше диалога движка с базой. Но это не точно ​.

Ну, хорошо, уговорили – кэш так кэш. Что будем использовать? Redis с nginx'ом? Неее, это не наш метод, мы заюзаем tarantool как "умный" кэш и сервер приложений в одном флаконе. Тем более, давно уже интегрирую решения на базе tarantool с asterisk'ом.

Из описания Backend cURL and Realtime берём на реализацию всего два метода: single и update – вопросы установки/сборки рассматривать тут не будем, так как в более или менее популярных дистрибутивах всё необходимое есть из коробки.

Ловкость рук и никакого мошенства

Для начала прописываем cURL backend в extconfig.conf. Затем определяемся с форматом кэша – для этого берём и проецируем структуру таблицы пиров на lua-таблицу под будущую базу:

; extconfig.conf

[settings]
...
sippeers => curl,http://127.0.0.1:65535
...

-- format.lua

local frommap = function(format,...)
 local peer = ...

 return type(peer) == 'table' and (function(p)
  local out = {}

  for k,v in ipairs(format) do
   out[k] = p[v['name']] or box.NULL
  end

  return out
 end)(peer) or {peer or box.NULL}
end


return setmetatable({
 { name = 'name', type = 'string' },
 { name = 'port', type = 'integer', is_nullable=true },
 { name = 'host', type = 'string', is_nullable=true },
 { name = 'ipaddr', type = 'string', is_nullable=true },

 ...

 { name = 'dynamic', type = 'string', is_nullable=true },
 { name = 'path', type = 'string', is_nullable=true },
 { name = 'supportpath', type = 'string', is_nullable=true }
},{__call = frommap})

Функция frommap – рудимент, досталась в наследство со времён tarantool 1.7.x, тогда ещё не было (или я плохо искал) нативной реализации frommap. По привычке таскаю её по версиям, да и по моим замерам эта реализация отрабатывает побыстрее, чем нативная в текущем tarantool LTS.

Следующим шагом будет перенос текущей таблицы пиров в lua-таблицу (ассоциативный массив). Можно конечно и select'ами надёргать при первом старте, но, мне кажется, так получится быстрее. Вооружаемся vim'ом, select'им нужную таблицу в файл, запускаем макрос и вуаля – ассоциативный массив в файле peers.lua.

Осталось продумать доставку всего этого добра до астериска. Для старта/теста вполне подойдет модуль http для tarantool'а, но, естественно, стоит озаботиться об идеологически правильном nginx'е, на будущее.

-- routes.lua

local utils = require('http.utils')

-- Маршрут обработки обновления regserver/useragent/fullcontact/regseconds/lastms/etc
-- Запрос приходит в виде /update?name=....
-- Параметры запроса в POST useragent=user%20agent%20v1.x.x&fullcontact=test%20user&regseconds=5&lastms=0
local update = function(req)
 local keys = {}
 local who = req:query_param() or {}
 local what = req:post_param() or {}

 if who['name'] then
  for k,v in pairs(format(what)) do
   if v ~= box.NULL then
    -- заполняем таблицу форматов для update
    keys[#keys+1] = {'=',k,format[k]['type'] ~= 'integer' and v or tonumber(v)}
   end
  end
  -- собственно обновление записи
  box.space.sippeers:update(who['name'],keys)

  return req:render{ status = 200 , text = '1\n'}
 end
 
 -- default
 return {
  status = 400,
  headers = { ['content-type'] = 'text/plain' },
 }
end

-- заглушка, реализация запросов на основе LIKE не нужна
local multi = function(req)
 return {
  status = 400,
  headers = { ['content-type'] = 'text/plain' },
 }
end

-- поиск пира по primary ключу[name] или составному[port/host/ipaddr/callbackextension] secondary
local single = function(req)
 local who
 local out = {}
 local what = req:post_param() or {}

 if what['name'] then
  -- выборка по primary ключу
  who = box.space.sippeers:select(what.name)[1] or {}
 else -- по secondary
  local skip = 0
  local keys = {}
  -- получаем части составного ключа
  local parts = box.space.sippeers.index.secondary.parts

  -- формируем таблицу с пропусками(если есть) составных, в виде: {5060,_,_,'7XXXXXXXXXX'}
  for k,v in ipairs(parts) do
   table.insert(keys,k,(function(p)
    if p then
     return p
    end
    skip = skip + 1 return _
   end)(what[format[v['fieldno']]['name']]))
  end
  -- проверяем на {_,_,_,_} с последующим запросом
  who = (#parts > skip) and box.space.sippeers.index.secondary:like(keys,1)[1] or {}
 end

 for _,v in ipairs(format) do
  -- формируем таблицу ответа
  table.insert(out,who[v['name']] and ('%s=%s'):format(utils.uri_escape(v['name']),utils.uri_escape(who[v['name']])))
 end

 if #out~=0 then
  -- отдаем ответ в виде: host=dynamic&secret=password&fromdomain=domain
  return req:render{text = table.concat(out,'&')}
 end

 -- default
 return {
  status = 400,
  headers = { ['content-type'] = 'text/plain' },
 }
end

-- reload маршрутов/сервера без остановки tarantool'а
if server and server['is_run'] and restart then
 server:stop()
 server:start()
end

return {
 multi = multi,
 update = update,
 single = single,
}

Надеюсь, из комментариев в листинге всё понятно, разве что маршрут multi – есть у меня такое предположение, что именно multi в интерпретации realtime-db срывает "башню" астеру. На это указывает ещё тот факт, что в прайм-тайм из, скажем, 5-и reload один да и подвесит систему. Лично моё мнение – в том виде, в котором используется multi, он не особо пригоден. Но отработку, скажем, register-учёток по callbackextension реализовать можно. Именно этим и хорош cURL-подход – мы буквально на коленке можем кастомизировать поведение как нам угодно.

Теперь немного подправим init.lua и запустим сервис.

#!/usr/bin/env tarantool

-- init.lua

-- будущие маршруты
local routes = {}

-- server & router модули http
local server = require('http.server').new('127.0.0.1', 65535)
local router = require('http.router').new({charset = "utf8"})

-- формат нашего кэша
local format = require('format')

-- переподгружает маршруты, если передать параметр true, перегрузит http.server
function reload_routes(...)
 routes = setfenv(loadfile('routes.lua'),setmetatable(
  {
   server = server,
   format = format,
   restart = ...
  },{__index = _G}))()
end

-- указываем, что за маршрутизацию будет отвечать router объект
server:set_router(router)

-- подгружаем наши маршруты как chunk
reload_routes()

-- добавляем наши маршруты в router
for _,path in ipairs({'multi','single','update'}) do
 router:route({path = ("/%s"):format(path)},function(...)
  return type(routes[path]) == 'function' and routes[path](...) or false
 end)
end

-- магия tarantool'а
box.cfg{}

-- LIKE функция поиска по составному ключу
box.schema.index_mt['like'] = function(...)
 local test
 local code = {}
 local result = {}
 local index, pattern, count = ...

 pattern = type(pattern) ~= 'table' and {pattern} or pattern
 -- формируем условия
 for k,v in pairs(pattern) do
   code[#code+1] = v and (" match(str(t[%d]),'%s') "):format(index.parts[k]['fieldno'],v)
 end
 -- прелести кодогенерации
 test = setfenv(load(([[
   local t = ...
   if %s then
    return insert(result,t) or true
   end
 ]]):format(table.concat(#code>0 and code or {'true'},'and'))),{
  str = tostring,
  result = result,
  match = string.match,
  insert = table.insert
 })
 -- выборка с учетом limit
 for _,t in index:pairs(_,{iterator = 'GE'}) do
  if test(t) then
   if count then
    if count > 1 then
     count=count-1
    else
     break
    end
   end
  end
 end

 return result
end

-- инициализация ключей
box.once('sippeers',function()
 local peers = require('peers')

 box.schema.space.create('sippeers',{format = format})
 box.space.sippeers:create_index('primary',
  { type = 'TREE', parts = {1, 'string'}})
 box.space.sippeers:create_index('secondary',
  { type = 'TREE', unique = false, parts = {
    {'port','integer'},
    {'host','string'},
    {'ipaddr','string'},
    {'callbackextension','string'}
  }})
 -- первичное заполнение
 for _, peer in ipairs(peers) do
  box.space.sippeers:insert(format(peer))
 end
end)
-- запускаем сервер приложений
server:start()
-- парадный вход :)
require('console').start()

Оно живое и светится

Сама затея, в моем понимании, поначалу была бесперспективной, воспринималась и реализовывалась как дополнение к решению на основе выноса регистраций на внешний сервер. Но, по мере внедрения, пришло осознание, что пациент скорее жив, чем мёртв. Realtime реально "похудел", и это заметно – возможно, утечки памяти просто размазались по времени (тесты/время покажут). Но, по факту, при такой организации астериск перестал течь, и это не может не радовать. Плюсом в копилку поимели новый уровень кастомизации sip-стека платформы.

За кадром остались телодвижения связанные с консистентностью данных в кэше и базе. Так как эта реализация узкоспецифическая, то рассматривать её в рамках данной статьи я не вижу особого смысла – кто как хочет, тот так и хохочет. Вопросы репликаций, масштабирования тоже достаточно тривиальны, на habr'e обсуждались уже много раз. По всем остальным вопросам добро пожаловать в комментарии.