Ұзақ құрал шақыруларына lease пен heartbeat не үшін қажет?

Ұзақ орындалатын құрал шақыруын базада running күйі тұрғаны үшін ғана тірі деп санауға болмайды. Бұл күй тез арада пайдасыз дерекке айналады: воркер құлап қалуы, желіде тұрып қалуы, рантайм кідірісіне түсуі немесе сыртқы API-ден жауап алып, нәтижені сақтап үлгермеуі мүмкін. Воркерге тапсырманы орындау құқығын уақытша беріп, оның осы құқықты тұрақты түрде растайтын схемасы керек.

Lease пен heartbeat екі түрлі мәселені шешеді. Lease екінші воркердің жұмысты тым ерте алып кетуіне жол бермейді. Heartbeat қысқа lease-ке қалыпты ұзақ операциядан өтуге мүмкіндік береді. Бірақ олардың ешқайсысы жеке өзі exactly-once орындалуын қамтамасыз етпейді. Қауіпсіз жанама әсерлер үшін идемпотенттілік пен fencing token қажет.

Бұл агенттік жүйелерде анық көрінеді. Модель іздеу, браузер, ERP, OCR, есеп жасау немесе ішкі API шақыруы мүмкін. Бір tool call бірнеше секундта аяқталса, екіншісі сыртқы сервисті бірнеше минут күтуі ықтимал. Мұндай кезекте тұрақты таймаутты дұрыс таңдау дерлік мүмкін емес: тым қысқа таймаут параллель дубликаттар жасайды, ал тым ұзақ таймаут командаға анық өлі тапсырманың қайта қолжетімді болуын күтуге мәжбүр етеді.

Lease уақытша құқық береді, сәттілікке уәде бермейді

Lease дегеніміз нақты бір воркердің тапсырманы белгілі бір уақытқа дейін орындай алатынын көрсететін жазба. Осы уақыт өткен соң тапсырманы қайтадан алуға болады. Воркер тапсырманы мәңгі иеленбейді және тек owner_id мәнінің болуы оған абсолютті эксклюзивтілік бермейді.

Кемінде мына бес өрісті сақтаған пайдалы:

create table tool_jobs (
  id uuid primary key,
  state text not null check (state in ('queued', 'running', 'succeeded', 'failed')),
  owner_id text,
  lease_until timestamptz,
  fencing_token bigint not null default 0,
  heartbeat_at timestamptz,
  attempt integer not null default 0,
  idempotency_key text not null unique,
  payload jsonb not null,
  result jsonb,
  error jsonb
);

owner_id қазір lease кімде екенін көрсетеді. lease_until бұл құқықтың қашан тоқтайтынын көрсетеді. fencing_token ескі процесс тым кеш оянғанда, ескі иені жаңасынан ажыратады. heartbeat_at бақылау мен тексеруге қажет, бірақ қайта алудың жалғыз өлшемі болмауы тиіс.

Lease пен күйді араластырмаңыз. running жұмыс істеу ниеті мен ағымдағы күйді сипаттайды. Lease иелену құқығын сипаттайды. Тапсырма running күйінде қала отырып, бұрынғы иесі құқығынан айырылып, жаңа иесі пайдалы жұмысты әлі бастамаған болуы мүмкін. Иелікті беру кезінде мұндай қысқа күй қалыпты.

etcd құжаттамасы бұл идеяны тікелей түсіндіреді: кластер TTL ішінде keepalive алмаса, lease аяқталады. etcd-де бұл сақтау примитиві, сіздің бизнес тапсырмаңызды өңдеуге арналған дайын протокол емес. Құқық мерзімі аяқталғаннан кейін воркерге не істеуге болатынын және жанама әсерді қабылдаушы ескі иені жаңасынан қалай ажырататынын бәрібір өзіңіз шешуіңіз керек.

running күйі тірі шақыру мен тұрып қалған шақыруды ажыратпайды

Қалыпты ақау өте қарапайым көрінеді. W1 воркері «үзінді көшірмені ал, өрістерді шығар да, оларды келісу жүйесіне жібер» деген тапсырманы алады. Ол state = 'running' орнатады, сыртқы сервисті шақырады да HTTP кітапханасында тұрып қалады: байланыс ресми түрде жабылмаған, клиент таймауты берілмеген немесе DNS сұрауы күтілгеннен ұзақ орындалады.

Он минуттан кейін базада әлі де running тұр. Жоспарлаушы жұмыстың орындалып жатқанын, провайдер жағында аяқталғанын немесе W1 процесін оркестратор әлдеқашан тоқтатқанын білмейді. Егер команда қолмен араласқанға дейін қайталауға тыйым салса, кезек жұмыс істеуін тоқтатады. Ал егер күйдің жасына қарай қайталаса, екінші шақыру іске қосылып, қос төлем, қос хат немесе бір жазбаның екі рет жаңартылуы пайда болады.

Heartbeat пайдалы прогресті өлшемейді. Ол тарлау сұраққа жауап береді: воркер әлі тірі ме, координатормен байланысы бар ма және тапсырмаға деген құқығын ұстап тұр ма. Бұл айырмашылық маңызды.

Мысалы, браузер құралы heartbeat жіберіп тұрып, модальды терезені шексіз күтуі мүмкін. Heartbeat бойынша мұндай операция тұрып қалған жоқ, бірақ өнім үшін ол жарамсыз. Сондықтан екі бөлек бақылау қажет:

• иелену қауіпсіздігі үшін lease пен heartbeat;
• орындалу сапасы үшін кезең ұзақтығының лимиті мен құрал таймауты.

Бұл сигналдарды араластырсаңыз, автоматтандыру нашар жұмыс істейді. Ол баяу, бірақ орындалып жатқан операцияларды қайталайды немесе нәтиже беруді әлдеқашан тоқтатқан тапсырмадағы lease-ті шексіз ұстап тұрады.

Тапсырманы алу атомарлы болуы керек

Воркер алдымен бос тапсырманы оқып, кейін оны бөлек жаңартпауы тиіс. Осы сұраулардың арасында басқа воркер дәл сол күйді көре алады. Lease құқығын бір транзакциямен беріп, уақытты контейнер сағатынан емес, база жағынан тексеру керек.

Төменде PostgreSQL үшін тапсырманы алу мысалы берілген. Ол күтіп тұрған немесе мерзімі өтіп кеткен бір тапсырманы таңдап, транзакция кезінде бұғаттайды, иесін белгілейді, lease мерзімін жылжытады және fencing token мәнін арттырады.

with candidate as (
  select id
  from tool_jobs
  where state = 'queued'
     or (state = 'running' and lease_until < now())
  order by id
  for update skip locked
  limit 1
)
update tool_jobs j
set state = 'running',
    owner_id = :worker_id,
    lease_until = now() + interval '90 seconds',
    heartbeat_at = now(),
    fencing_token = fencing_token + 1,
    attempt = attempt + 1
from candidate
where j.id = candidate.id
returning j.id, j.payload, j.fencing_token, j.lease_until;

Әдеттегі нәтиже мынадай болады:

id: 8f1b7c3d-...
fencing_token: 42
lease_until: 2026-07-23T21:14:30Z

for update skip locked бұл жерде сиқырлы немесе әмбебап рецепт емес. Бірнеше воркер бір кестеден оқып, бөлек брокер қажет болмаған кезде ол пайдалы. Бірақ бұл пайдаланушы бойынша параллельділікті шектеуді, нақты құралға арналған лимитті немесе басымдықтарды алмастырмайды. Соған қарамастан, алғашқы жаңартуға дейін он воркердің бір queued жолын таңдап алуынан туатын жарысты жояды.

lease_until < :client_now сияқты шартта қолданба уақытын пайдаланбаңыз. Контейнер сағаттары бір-бірінен ауытқиды, виртуалды машиналар уақытты күрт түзетуі мүмкін, ал воркердің бірі кідірістен кейін ескі уақытпен жұмыс істеуі ықтимал. Базаның now() мәні үлестірілген жүйені мінсіз етпейді, бірақ шешім қабылдаудың бірыңғай уақытын беретін бір арбитрді қамтамасыз етеді.

Heartbeat lease-ті тек ағымдағы иесіне ұзарта алады

Heartbeat «тапсырманы тірі қыл» деген команда емес. Бұл шартты ұзарту: база сұраудың ағымдағы иеден келгенін және оның мерзімі әлі аяқталмағанын тексеруі тиіс. Мұны жасамасаңыз, ескі воркер әлдеқашан басқаға берілген тапсырманы қайта тірілте алады.

Ұзарту сұрауы мынадай болуы керек:

update tool_jobs
set lease_until = now() + interval '90 seconds',
    heartbeat_at = now()
where id = :job_id
  and state = 'running'
  and owner_id = :worker_id
  and fencing_token = :fencing_token
  and lease_until > now()
returning lease_until;

Жауаптағы нөл жол «сұрауды тағы бір рет қайтала» дегенді білдірмейді. Бұл воркердің енді иесі емес екенін білдіреді. Себептері бірнешеу болуы мүмкін: lease аяқталды, басқа воркер тапсырманы алып қойды, оператор оны тоқтатты немесе сәтсіздік саясаты бойынша біреу күйін өзгертті. Нөл нәтиже алғаннан кейін воркер сыртқы әлемді өзгертуі мүмкін әрекеттерді тоқтатуы керек.

Циклдің псевдокоды мынадай:

job = claim(worker_id)
start heartbeat every 30 seconds

run tool with a bounded client timeout

on each heartbeat:
  if extend(job.id, worker_id, job.fencing_token) returns no row:
    cancel tool if the client supports cancellation
    mark local execution as lease_lost
    do not commit a success result

on tool completion:
  stop heartbeat
  commit result only if the same token still owns the job

Heartbeat-ті құрал шақыруын орындайтын ағынның ішіне орналастырмаңыз. Шақыру event loop-ты бұғаттауы, жалғыз ағынды басып алуы немесе native кітапханада тұрып қалуы мүмкін. Бөлек рантайм тапсырмасы, бөлек ағын немесе бөлек бақылау процесі әдетте сенімдірек. Бірақ бұл контроллер негізгі орындаушы аяқталған немесе жергілікті бақылауға қолжетімсіз болған кезде lease-ті ойланбастан ұзарта бермеуі тиіс.

Amazon SQS құжаттамасы ұзақтығы алдын ала белгісіз жұмыс үшін дәл осы қағиданы ұсынады: бастапқыда қысқа visibility орнатып, consumer жұмыс істеп тұрған кезде оны мерзімді түрде ұзарту. Онда қысқа visibility бірінші consumer аяқталғанға дейін дубликат тудыруы мүмкін, ал тым ұзақ visibility ақаудан кейінгі қайталауды кешіктіретіні де көрсетілген.

Интервалдар әдемі санға емес, уақыт қорына қарай таңдалады

«90 секундтық lease, 30 секунд сайын heartbeat» схемасы алғашқы іске қосу үшін жиі жарайды, бірақ бұл ереже емес. Воркер heartbeat-тің бір сәтсіз жіберілуіне, базаның қысқа істен шығуына және рантаймның қалыпты кідірісіне төтеп бере алатындай ұзақтық таңдаңыз.

Практикалық модель мынадай:

• L - lease мерзімі;
• H - heartbeat кезеңі;
• J - желідегі джиттерге, процесс кідірістеріне және база жүктемесіне арналған қор;
• R - қатарынан өткізіп алуға дайын heartbeat саны.

L > R × H + J болуы керек. Heartbeat 30 секунд сайын келіп, бір жіберілмеген хабарды өткізіп алуды жоспарласаңыз және 20 секунд қор есептесеңіз, 90 секундтық lease орынды буфер береді. Сол схемадағы 35 секундтық lease қалыпты кідірістің өзі әлі жұмыс істеп тұрған воркердің құқығын алып қоюы мүмкін екенін білдіреді.

Lease-ті мерзім бітуіне бір секунд қалғанда ұзартуға тырыспаңыз. Сұрауларды үнемдейтіндей көрінген бұл тәсіл кідіріс алғаш өскенде бұзылады. Алдын ала ұзартыңыз, яғни heartbeat-тің кемінде бір толық интервалы мен сәтсіз сұрауға арналған қор қалғанда әрекет етіңіз.

Жұмыс кластарын бөліңіз. Бірнеше секундта аяқталатын классификатор шақыруы есеп жүйесінен файл экспорттайтын операциямен бірдей lease ұстамауы керек. lease_duration мәнін тапсырма түрінде сақтауға немесе claim операциясына беруге болады, бірақ TTL-ді модельге тікелей таңдауға мүмкіндік бермеңіз. Модель қателесуі мүмкін, кейде пайдаланушының нұсқауымен мағынасыз ұзақ жұмысқа кірісуі де ықтимал.

SQS-те visibility timeout ұзартудың тағы бір жағымсыз шегі бар: максимум 12 сағат алғашқы хабарламаны алған сәттен бастап есептеледі, кейінгі ұзартулар бұл есепті қайта бастамайды. Бұл нақты сервистің шектеуі, бірақ қорытынды кез келген архитектураға пайдалы: шексіз ұзартылатын тапсырма әдетте сақталатын кезеңдер тізбегіне айналуы керек.

Lease жоғалса, құрал сәтті жауап берсе де жұмысты тоқтату керек

Ең қауіпті сәт воркер құлаған кезде емес, ескі воркер қайта оянғанда келеді. W1 41 token-імен lease алды да, провайдерге сұрау жіберді. Кейін W1 мен база арасындағы желі үзілді. Heartbeat өтпеді, lease аяқталды. W2 тапсырманы алып, 42 token алды да, оны қайта орындады.

Осыдан кейін W1 кешігіп келген сәтті жауапты алды. Егер ол мынадай қарапайым сұрауды орындаса:

update tool_jobs
set state = 'succeeded', result = :result
where id = :job_id;

жаңа иенің нәтижесін қайта жазып тастайды. W1 сыртқы жүйеде екінші төлем жіберсе немесе өтінімді растаса, жағдай одан да қауіпті. Кестедегі күй жіберіліп қойған сұрауды тоқтата алмайды.

Финалдық жазба шартты болуы тиіс:

update tool_jobs
set state = 'succeeded',
    result = :result,
    lease_until = null
where id = :job_id
  and state = 'running'
  and owner_id = :worker_id
  and fencing_token = :fencing_token
  and lease_until > now();

Жаңарту ешбір жол қайтармаса, нәтижені қабылданды деп жариялауға болмайды. Оны тексеру үшін техникалық журналға сақтаңыз, бірақ пайдаланушыға көрсетпеңіз және бизнес-процестің күйі ретінде қолданбаңыз.

Осы жерде fencing token пайда болады. owner_id жалғыз қорғаныс ретінде жарамайды: бір воркер қайта іске қосылғаннан кейін сол логикалық атты алуы мүмкін, ал ескі желілік байланыс жұмысын жалғастыра алады. Монотонды өсетін token әр lease беруді иелену ретімен байланыстырады. Маңызды жанама әсерді қабылдаушы соңғы қабылданған token мәнін сақтап, одан кішісін қабылдамауы керек.

Мысалы, төлемді есептен шығару сервисі X-Execution-Fence: 42 тақырыбын қабылдайды. Егер 42 token-і бар команда бұрын қабылданса, 41 token-і бар команда дұрыс аутентификациядан өтсе де күйді өзгерте алмайды. Бұл сыртқы API-ді автоматты түрде идемпотентті етпейді, бірақ «ескі иесі жаңадан кейін жазып жіберді» деген қателер класын жояды.

Идемпотенттілік lease шеше алмайтын мәселені жабады

Lease жұмыс басталғанға дейін және жұмыс кезінде бәсекелестікті басқарады. Бірақ базаға жетіп қойған HTTP сұрауын сыртқы сервистен кері қайтара алмайды. Желі жауапты сыртқы қабылдаушы әрекетті орындағаннан кейін үзілуі мүмкін. Воркер таймаут көреді де, сұрауды қайталау керек пе екенін білмейді.

Сондықтан жанама әсері бар әр операцияға идемпотентті кілт қажет. Әр әрекетке жаңа UUID жасамаңыз. Операцияның мағынасына байланған тұрақты кілт қолданыңыз, мысалы payment:{invoice_id}:capture немесе ticket:{job_id}:create.

Сыртқы құралға жіберілетін сұрау мынадай болуы мүмкін:

{
  "operation": "create_case",
  "idempotency_key": "tool-job:8f1b7c3d:create_case",
  "execution_fence": 42,
  "input": {
    "customer_id": "c-1048",
    "summary": "Проверить расхождение в счете"
  }
}

Қабылдаушы бір idempotency_key екінші рет келгенде бұрынғы нәтижені қайтаруы керек. Егер fencing token-ді қолдаса, сол нысан үшін соңғы қабылданған мәннен кіші token-і бар сұрауды да қабылдамауы тиіс. Бұл механизмдер бірге жұмыс істейді:

• идемпотентті кілт қайта жіберілген бірдей командадан қорғайды;
• fencing token жаңа командадан кейін келген ескі командадан қорғайды;
• lease екі әрекеттің бір уақытта басталу ықтималдығын азайтады.

«Retry қосыңыз» деген танымал кеңес толық емес. Идемпотенттіліксіз retry қымбат дубликаттың ықтималдығын арттырады. Тапсырма мерзімін шектемей retry жасау шексіз жүктеме тудырады. Қателерді ажыратпай retry валидация қателерін уақытша желі ақауларындай табанды түрде қайталайды.

Тек оқуға арналған құралдарда қауіп төмен, бірақ дубликаттар онда да зиян. Олар API лимитін жұмсайды, әртүрлі уақыттағы деректерді қайтаруы мүмкін және модельді келісілмеген көрініске сүйеніп жауап құруға мәжбүр етеді. Агенттік контурда бұл «модель галлюцинация жасап тұр» сияқты көрінеді, ал шын себеп көбіне бір тапсырманың синхрондалмаған екі орындалуы болады.

Heartbeat қателерін кәдімгі желі қатесі деп қарауға болмайды

Бір heartbeat өтпей қалса, воркер әлі де иесі болуы мүмкін. Ал lease-тің ұзартылғанын білмесе, жағдай екіұшты болады. Сұрау базаға жетіп, жауап жоғалуы ықтимал. Қауіпсіз реакция қалған уақыт пен операция түріне байланысты.

Мен қолданатын қарапайым ереже мынадай: воркер lease-ті консервативті дедлайнға дейін растай алмаса, жаңа сыртқы әрекеттерді бастамайды. Қоры бар кезде heartbeat-ті қайта күте алады, бірақ құқықтың соңғы секундында тізбектің келесі кезеңін бастамауы керек.

Қателерді үш топқа бөлген пайдалы:

• База жолдың жаңартылмағанын қайтарды. Lease жоғалды, жұмысты тоқтату керек.
• База қолжетімсіз немесе жауап келмеді. Иелік ету белгісіз, жаңа қайтарылмайтын қадам жасауға болмайды.
• Сыртқы құрал жауап бермеді. Иелік ету сақталуы мүмкін, бірақ сыртқы әрекеттің нәтижесі белгісіз, сондықтан идемпотентті қайталау немесе операция күйін сұрау қажет.

«Иелік ету белгісіз» күйін автоматты retry артына жасыруға тырысады. Олай жасамаңыз. Оны job_id, token, соңғы расталған lease уақыты және сыртқы сұрау идентификаторымен бөлек оқиға ретінде журналға жазыңыз. Пайдаланушыдан екі өтінім келгенін көріп, оларды кім жасағанын оператор түнгі сағат 02:00-де анықтауға тырысқанда дәл осы өрістер қажет болады.

Мерзімі біткен тапсырманы бірден қайталау міндетті емес. Егер оның әрекет саны таусылса, түзетілмейтін қатесі болса немесе тоқтатылған сессияға тиесілі болса, жоспарлаушы оны түсінікті терминалдық күйге ауыстыруы керек. Retry саясаты жоқ кезек қолмен істелетін жұмысты бір тізімнен екіншісіне ғана ауыстырады.

Бақылау тек тапсырма санын емес, иелікті көрсетуі керек

running jobs графигінің пайдасы аз. Ол базада осы күйі бар жолдардың санын көрсетеді, бірақ олардың қайсысы жұмысты шынымен ұстап тұрғанын және lease қашан аяқталатынын айтпайды.

Метрикалардың ең аз жиынына соңғы сәтті heartbeat жасы, lease-тің қалған уақыты, мерзімі біткен lease саны, ұзарту сәтсіздіктері және қайта алынған тапсырмалар саны кіреді. Оларды құрал түрі, модель және сыртқы провайдер бойынша бөліңіз. Әйтпесе браузер құралындағы таймауттар іздеудің қалыпты қысқа шақыруларымен араласып кетеді.

Бір орындалу журналында кемінде мынадай оқиғалар болуы керек:

job_claimed job=8f1b... token=42 lease_until=21:14:30Z
heartbeat_ok job=8f1b... token=42 lease_until=21:15:00Z
tool_request_started job=8f1b... request=ext-791
heartbeat_lost job=8f1b... token=42 reason=zero_rows
result_rejected job=8f1b... token=42

Бұл оқиғаларға толық промпттарды, құжаттарды және құрал жауаптарын әдепкі бойынша жазбаңыз. LLM қосымшаларында журнал оңайша персонал деректерінің тағы бір қоймасына айналады. Техникалық идентификаторлар, payload хэші, құрал класы, ұзақтық және қате коды жеткілікті. Толық мазмұнды нақты қажеттілік пен сақтау саясаты болғанда ғана сақтаңыз.

AI Router модель шақыруларына арналған бірыңғай OpenAI-үйлесімді қабат ретінде ыңғайлы болуы мүмкін, бірақ lease оркестрация контурыңызда, кезек пен tool call күйіне жақын жерде қалуы керек. Модель шлюзі воркердің төлемді қайта жіберуге немесе өтінімді өзгертуге құқығы бар-жоғын шешпеуі тиіс.

Ұзақ агенттік жұмысты сақталатын кезеңдерге бөлген дұрыс

Lease-ті бірнеше сағат бойы ұзартып тұратын бір үлкен tool call бірінші ақауға дейін қарапайым көрінеді. Ақаудан кейін құралдың не істеп қойғанын, аралық файлдың қайда жатқанын және жұмысты қауіпсіз жалғастыруға болатынын білмейсіз.

Тексерілетін нәтиже пайда болатын жерден жұмысты бөліңіз. Мысалы, есеп дайындау процесін бастапқы деректерді алу, қалыпқа келтірілген жиынды сақтау, нобай жасау, тексеруге жіберу және жариялау кезеңдеріне бөлуге болады. Әр кезеңнің өз idempotency key-і, нәтижесі және жаңа lease-і болады. Кезеңдер арасында жүйе тоқтаса да, не істелгені туралы түсінік жоғалмайды.

Бөлу үшін ғана бөлмеңіз. Егер кезең 200 миллисекундқа созылып, жеке жанама әсері болмаса, жаңа тапсырма сенімділіктен гөрі көбірек күрделілік қосады. Шекара операция ұзақ күтетін, сыртқы әлемге шығатын, қайталауы қымбат немесе адам тексеруін қажет ететін жерде керек.

LLM-агентінде жоспарлау мен орындауды бөлу әсіресе пайдалы. Модель әрекеттер тізбегін ұсына алады, бірақ диспетчер рұқсат етілген құрал түрі, уақыт лимиті, идемпотентті кілт және retry саясаты бар бөлек тапсырмалар жасауы керек. Сонда бір шақырудағы lease жоғалуы бүкіл агенттік іске қосылуды түсініксіз күйге түсірмейді.

Продакшнға дейін бір жағымсыз тест жасаңыз. W1 тапсырманы алып, сыртқы сұрауды жіберсін. Содан кейін оның базаға қатынасын тоқтатып, lease аяқталғанша күтіңіз, W2-ге сол жұмысты алғызыңыз да, содан кейін ғана W1 желісін қайтарыңыз. W1 lease-ті ұзарта алмайтынын, нәтиже жаза алмайтынын және екінші қайтарылмайтын әсер жасамайтынын тексеріңіз. Бұл тест өтпесе, heartbeat тек көңіл жұбататын журналдар салып тұрғаны.