ამოცანების რიგები Valkey-ით: BullMQ, Celery, RQ და Laravel

ამოცანების რიგი ნელ სამუშაოს მოთხოვნიდან გააქვს: ვებ პროცესი წერს პატარა ჩანაწერს "გაგზავნე ეს წერილი" ან "შეცვალე ამ სურათის ზომა", მომხმარებელს მაშინვე უბრუნდება, ცალკე worker პროცესი კი ჩანაწერს იღებს და სამუშაოს ასრულებს. ამ ჩანაწერის შესანახად ყველაზე გავრცელებული ადგილი Valkey-ა, რადგან ყველა პოპულარული რიგის ბიბლიოთეკა - BullMQ Node-ზე, Celery და RQ Python-ზე, Laravel-ის რიგი PHP-ზე, Sidekiq Ruby-ზე - Redis-ის პროტოკოლზეა აგებული, Valkey კი მას უცვლელად საუბრობს.

ბიბლიოთეკები რთულ ნაწილებს კარგად აკეთებენ: განმეორებები, დაყოვნებები, backoff, dead letter-ები, პარალელურობა. რისი გაკეთებაც არ შეუძლიათ, ისაა, რომ დაგიცვან ქეშად დაკონფიგურირებული Valkey-სგან. რიგი სერვერზე, რომელიც მეხსიერების დეფიციტისას გასაღებებს აძევებს, ამოცანებს ჩუმად კარგავს, ხოლო რიგი სერვერზე, რომელიც დისკზე არ ინახავს, restart-ზე ყველა მომლოდინე ამოცანას კარგავს. ეს პოსტი თითოეულ ბიბლიოთეკას აყენებს, შემდეგ კი გადის სერვერის პარამეტრებს, მარცხის სცენარებს და ზომას, რაც რიგს სანდოს ხდის.

როდის არის რიგი სწორი ინსტრუმენტი#

რიგი თავის ადგილს იმსახურებს, როცა სამუშაო ნელია, შეიძლება ჩავარდეს და განმეორდეს, და არ სჭირდება დასრულება, სანამ მომხმარებელი პასუხს დაინახავს. ჩვეულებრივი კანდიდატები:

• ელფოსტის, SMS-ისა და push შეტყობინებების გაგზავნა.
• thumbnail-ების, PDF-ების, ექსპორტებისა და ანგარიშების გენერირება.
• მესამე მხარის API-ების გამოძახება, რომლებიც ნელია ან rate limit-ით შეზღუდულია.
• webhook-ები, რომლებსაც იღებ და გინდა მაშინვე დაადასტურო, შემდეგ კი დაამუშავო.
• დაგეგმილი და განმეორებადი სამუშაო: ღამის გასუფთავებები, დაიჯესტები, გადახდების ხელახლა ცდა.

ის არ არის სამუშაოსთვის, რომელსაც მომხმარებელი ელოდება. თუ შემდეგ გვერდს შედეგი სჭირდება, რიგი მხოლოდ დაყოვნებას და polling ციკლს ამატებს.

სანამ ამისთვის Valkey-ს დაამატებ, შეამოწმე, ხომ არ აკეთებს ამას უკვე შენი ბაზა. ცხრილი SELECT ... FOR UPDATE SKIP LOCKED-ით სწორი რიგია PostgreSQL-სა და MySQL 8-ში, და მას აქვს ერთი თვისება, რომელიც არცერთ Valkey რიგს არ აქვს: ამოცანის რიგში ჩადება და იმ მონაცემების commit, რამაც ის გამოიწვია, ერთ ტრანზაქციაში ხდება. ფონური ამოცანები პატარა სერვერზე ამ ვარიანტს გადის. Valkey იგებს, როცა ამოცანების მოცულობა მაღალია, როცა მომწიფებული ბიბლიოთეკის შესაძლებლობები გინდა საკუთარის დაწერის ნაცვლად, ან როცა Valkey უკვე გაქვს გაშვებული სესიებისა და ქეშისთვის.

სერვერის პარამეტრები, რომლებზეც რიგია დამოკიდებული#

Valkey სერვერზე სამი პარამეტრი წყვეტს, გადარჩება თუ არა ამოცანები. შეამოწმე ისინი კოდის დაწერამდე.

eviction არის ის, რაც ამოცანებს კარგავს. allkeys-lru-ის პირობებში სავსე Valkey ყველაზე დიდი ხნის გამოუყენებელ გასაღებებს შლის, ხოლო ამოცანა, რომელიც დაყოვნებულ ნაკრებში ყველაზე დიდხანს ელოდება, ზუსტად ასეთია. BullMQ ამას გაშვებისას ამოწმებს და გაფრთხილებას ლოგავს, როცა პოლიტიკა noeviction არ არის; დანარჩენები საერთოდ არ ამოწმებენ. noeviction-ით სავსე სერვერი ახალ ამოცანებს შეცდომით უარყოფს, რომელსაც შენი კოდი ხედავს და შეუძლია გაფრთხილება გამოსცეს. ეს ის ქცევაა, რაც გინდა: ხმაურიანი მარცხი ჩუმის ნაცვლად. Valkey-ს მეხსიერება და eviction პოლიტიკები პოლიტიკებს დეტალურად ფარავს.

$ valkey-cli -h 203.0.113.20 -p 6380 --askpass INFO memory | grep -E 'maxmemory|used_memory_human'$ valkey-cli -h 203.0.113.20 -p 6380 --askpass INFO persistence | grep -E 'aof_enabled|rdb_last'

თუ ერთი და იგივე Valkey ინახავს ქეშს, რომელმაც უნდა განდევნოს, და რიგს, რომელმაც არ უნდა, პატიოსანი პასუხი ორი ინსტანციაა. პატარა ინსტანცია რიგისთვის ნაკლები ღირს, ვიდრე დაკარგული ამოცანების debug-ი.

RE:NODE-ზე Valkey გეგმა დისკზე ინახავს როგორც AOF-ით, ისე snapshot-ებით, და პაროლით დაცული მოდის, ყოველი სერვერისთვის გენერირებული მონაცემებით. ის ცალკე სერვერად მუშაობს, რომელსაც საკუთარი ჰოსტითა და პორტით მიმართავ, ამიტომ worker-ები აპის გეგმაზე და ვებ პროცესი სხვაგან ყველა ერთსა და იმავე რიგს უკავშირდება.

BullMQ Node.js-ზე#

BullMQ Node-ის მიმდინარე რიგის ბიბლიოთეკაა, Bull-ის მემკვიდრე. ის ქვემოთ ioredis-ს იყენებს და ყოველ რიგს ინახავს გასაღებების ნაკრებად bull:<queue>: პრეფიქსით.

$ npm install bullmq

import { Queue } from "bullmq";export const connection = {  host: process.env.VALKEY_HOST,  port: Number(process.env.VALKEY_PORT),  password: process.env.VALKEY_PASSWORD,};export const emails = new Queue("emails", {  connection,  defaultJobOptions: {    attempts: 5,    backoff: { type: "exponential", delay: 10_000 },    removeOnComplete: { age: 3600, count: 1000 },    removeOnFail: { age: 7 * 24 * 3600 },  },});// in the web processawait emails.add("welcome", { userId: 42 }, { jobId: `welcome:42` });

import { Worker } from "bullmq";import { connection } from "./queue.js";const worker = new Worker("emails", async (job) => {  await sendWelcomeEmail(job.data.userId);}, { connection: { ...connection, maxRetriesPerRequest: null }, concurrency: 5 });worker.on("failed", (job, err) => console.error(job?.id, err.message));process.on("SIGTERM", async () => { await worker.close(); process.exit(0); });

ხაზები, რომლებსაც მნიშვნელობა აქვს:

• `maxRetriesPerRequest: null` worker-ის კავშირზე. BullMQ-ის worker-ები ბლოკირებად ბრძანებებს იყენებენ, რომლებიც უსასრულოდ ელოდებიან; ioredis განმეორებების ლიმიტით მათზე ხელს იღებს და worker-ს ამტვრევს. BullMQ ამას თვითონ აყენებს, როცა კავშირს ქმნის, და გაფრთხილებს, თუ სხვანაირად დაკონფიგურირებულ კლიენტს გადასცემ.
• `removeOnComplete` და `removeOnFail`. ნაგულისხმევად BullMQ ყოველ დასრულებულ ამოცანას ინახავს. დატვირთულ რიგზე ეს Valkey-ს გავსების ყველაზე გავრცელებული გზაა: არა მომლოდინე სამუშაო, არამედ ისტორია, რომელსაც არავინ კითხულობს. შეზღუდული ფანჯარა შეინახე.
• `jobId`. საკუთარი id რიგში ჩადებას იდემპოტენტურს ხდის: ამოცანის დამატება, რომლის id უკვე არსებობს, არაფერს აკეთებს. ასე აიცილებ მისასალმებელი წერილის ორჯერ გაგზავნას, როცა მოთხოვნა მეორდება.
• `worker.close()` `SIGTERM`-ზე. ის აჩერებს ახალი ამოცანების აღებას და ელოდება მიმდინარეებს, ამიტომ deploy ამოცანას შუა გზაზე არ წყვეტს. Graceful shutdown და health check-ები ხსნის, რატომ აქვს ამ სიგნალის handler-ს მნიშვნელობა ყველა პლატფორმაზე.

განმეორებადი ამოცანები - "ყოველ ღამე 03:00-ზე" - BullMQ-ის მიმდინარე ვერსიებში ჩაშენებულია job scheduler-ების სახით, ძველი კოდი კი add-ზე repeat ოფციას იყენებს. გამოიყენე ერთი და არა ორივე, და შეამოწმე დოკუმენტაცია იმ ვერსიისთვის, რომელიც გაქვს დაყენებული.

Celery და RQ Python-ზე#

Celery Valkey-ს იყენებს როგორც broker-ს (სადაც შეტყობინებები ელოდება) და სურვილისამებრ როგორც result backend-ს (სადაც დაბრუნებული მნიშვნელობები ინახება).

import osfrom celery import Celeryurl = os.environ["VALKEY_URL"]   # redis://:password@host:port/0app = Celery("shop", broker=url, backend=url.replace("/0", "/1"))app.conf.update(    task_acks_late=True,    worker_prefetch_multiplier=1,    task_reject_on_worker_lost=True,    result_expires=3600,    broker_transport_options={"visibility_timeout": 3600},)@app.task(bind=True, autoretry_for=(ConnectionError,), retry_backoff=True, max_retries=5)def send_welcome(self, user_id):    ...

$ celery -A tasks worker --loglevel=INFO --concurrency=4$ celery -A tasks beat --loglevel=INFO

პარამეტრი, რომელიც უნდა გაიგო, არის visibility_timeout. Redis-ის პროტოკოლის transport-ით worker-ის მიერ აღებული შეტყობინება არ იშლება; ის დამალულია, სანამ არ დადასტურდება. თუ worker-მა ის visibility timeout-ის განმავლობაში არ დაადასტურა - ნაგულისხმევად ერთი საათი - შეტყობინება ხელახლა მიეწოდება სხვა worker-ს. ამოცანა, რომელიც კანონიერად ამ timeout-ზე დიდხანს მუშაობს, ამიტომ ორჯერ, ან ბევრჯერ სრულდება. დააყენე timeout შენს ყველაზე გრძელ ამოცანაზე მეტი, და task_acks_late=True-ით ამოცანები მაინც ისე დაწერე, რომ ორჯერ გაშვება უსაფრთხო იყოს. result_expires იმავე მიზეზით არის მნიშვნელოვანი, რა მიზეზითაც BullMQ-ის removeOnComplete: შედეგები, რომლებსაც არასოდეს კითხულობ, გასაღებებად გროვდება.

RQ უფრო მარტივი არჩევანია, როცა Celery-ის routing, chord-ები და canvas არ გჭირდება.

from redis import Redisfrom rq import Queue, Retryq = Queue("default", connection=Redis.from_url(os.environ["VALKEY_URL"]))job = q.enqueue(send_welcome, 42, retry=Retry(max=3, interval=[10, 60, 300]), job_timeout=600)

$ rq worker --url "$VALKEY_URL" high default low

რიგების სახელები პრიორიტეტის მიხედვითაა ჩამოთვლილი: worker high-ს ცლის, სანამ default-ს შეხედავს. ჩავარდნილი ამოცანები მიდის ჩავარდნილი ამოცანების რეესტრში, რომლის შემოწმება და ხელახლა რიგში ჩადება შეგიძლია rq info-ით და RQ-ის dashboard-ით. დაგეგმილ ამოცანებს (enqueue_in, enqueue_at) სჭირდება worker, რომელიც --with-scheduler-ით არის გაშვებული.

Laravel-ის რიგები#

Laravel-ის რიგების სისტემას Valkey-ზე მუშაობისთვის მხოლოდ კონფიგურაცია სჭირდება.

QUEUE_CONNECTION=redisREDIS_HOST=203.0.113.20REDIS_PORT=6380REDIS_PASSWORD=a-long-generated-password

$ php artisan queue:work redis --queue=high,default --tries=3 --backoff=10 --max-time=3600

config/queue.php-ში redis კავშირს აქვს retry_after მნიშვნელობა, ნაგულისხმევად 90 წამი. ის იგივე როლს ასრულებს, რასაც Celery-ის visibility timeout: ამოცანა, რომელიც retry_after-ზე დიდხანსაა დაჯავშნილი, რიგში ბრუნდება. შენი ყველაზე გრძელი ამოცანის $timeout რამდენიმე წამით მოკლე უნდა იყოს retry_after-ზე, თორემ გრძელი ამოცანები ორჯერ სრულდება. Laravel-ის დოკუმენტაცია ამას პირდაპირ ამბობს, და ეს მაინც Laravel-ის რიგის ყველაზე გავრცელებული ხარვეზია.

--max-time worker-ს ერთი საათის შემდეგ სუფთად ასრულებინებს, რომ ის, რაც მას ზედამხედველობს, თავიდან გაუშვას, რაც ხანგრძლივი PHP პროცესების მეხსიერების გაჟონვას ზღუდავს. ყოველი deploy-ის შემდეგ გაუშვი php artisan queue:restart, რადგან გაშვებული worker ძველ კოდს მეხსიერებაში ინახავს. Laravel Horizon იმავე Redis-ის პროტოკოლის რიგებს dashboard-სა და ავტომატურ დაბალანსებას უმატებს. Laravel-ის deploy production-ში worker-ის ზედამხედველობას ფარავს.

განმეორებები, იდემპოტენტურობა და dead letter-ები#

ზემოთ ყოველი რიგი მიწოდებას ერთხელ მაინც ახორციელებს. worker-ს შეუძლია ამოცანა დაასრულოს და დადასტურებამდე მოკვდეს, და ამოცანა ისევ შესრულდება. დააპროექტე ამისთვის და არა მის წინააღმდეგ.

1. ამოცანები იდემპოტენტური გახადე. "მონიშნე ინვოისი 512 როგორც გადახდილი" უსაფრთხოდ მეორდება. "დაამატე 10 ბალანსს" - არა. შეინახე დამუშავების ნიშანი - ყველაზე ძლიერია ბაზის unique შეზღუდვა მოვლენის id-ზე - და ჯერ ის შეამოწმე.
2. payload-ში id-ები ჩადე და არა ობიექტები. ამოცანა, რომელიც მომხმარებლის მთელ ჩანაწერს ატარებს, მოძველებული მონაცემებით სრულდება, თუ ერთი საათი იცდის. ამოცანა, რომელიც userId: 42-ს ატარებს, მიმდინარე მდგომარეობას ტვირთავს.
3. გაიმეორე backoff-ით, შემდეგ გაჩერდი. ექსპონენციალური backoff დაახლოებით ხუთი მცდელობის ზღვრით დროებით მარცხებს უმკლავდება. ამოცანა, რომელიც ხუთჯერ ჩავარდა, მეექვსეზე არ გამოვა; მას ადამიანი სჭირდება.
4. ჩავარდნილი ამოცანები იქ შეინახე, სადაც ვინმე შეხედავს. BullMQ-ის failed ნაკრები, RQ-ის failed რეესტრი და Laravel-ის failed_jobs ცხრილი dead-letter რიგებია. გაფრთხილება მათ ზომაზე დააყენე და არა ცალკეულ მარცხებზე.
5. გაყავი ნელი და სწრაფი რიგები. თუ ღამის ექსპორტი და პაროლის აღდგენის წერილები ერთ რიგსა და ორ worker-ს იზიარებენ, ექსპორტი წერილებს ბლოკავს. სასწრაფო სამუშაოს საკუთარი რიგი და worker-ები მიეცი.

Valkey-ს ზომის შერჩევა რიგისთვის#

რიგის მეხსიერების მოხმარება არის დაგროვილი ამოცანები, პლუს ნებისმიერი ისტორია, რომელსაც ინახავ. ტიპური ამოცანის ჩანაწერი - payload, ოფციები, დროის ნიშნულები და ცოტა ბიბლიოთეკის აღრიცხვა - სადღაც რამდენიმე ასეულ ბაიტსა და რამდენიმე კილობაიტს შორისაა. 100,000 ამოცანის დაგროვება 2 KB-ად დაახლოებით 200 MB-ია, და სწორედ ამიტომ აქვს სტაბილურ ზომას ნაკლები მნიშვნელობა, ვიდრე ყველაზე ცუდ შემთხვევას: რა ხდება, როცა worker-ები ინციდენტის დროს ერთი საათით გათიშულია და ვებ პროცესი რიგში ჩადებას აგრძელებს.

ამოცანაში ფაილებს არასოდეს დებ. სურათი ატვირთე დისკზე ან object storage-ში და რიგში მისი გზა ჩადე. გაზომე შეფასების ნაცვლად: INFO memory ჯამისთვის, MEMORY USAGE ამოცანის გასაღების ნიმუშზე, და ბიბლიოთეკის საკუთარი მთვლელები (getJobCounts() BullMQ-ში, rq info, celery inspect).

Valkey-ზე რიგისთვის CPU იშვიათად არის შემზღუდველი; ერთი პატარა ინსტანცია წამში ათასობით ჩადებას უმკლავდება. worker-ებს სჭირდებათ საკუთარი CPU და მეხსიერება, რაზეც არ უნდა მუშაობდნენ.

რას უნდა ადევნო თვალი

რიგი ჯერ ნელა ფუჭდება, შემდეგ კი ერთბაშად, ამიტომ თვალი ადევნე რიცხვებს, რომლებიც პირველები იცვლება:

• დაგროვების ზომა - მომლოდინე ამოცანები თითო რიგზე. დაგროვება, რომელიც დღისით იზრდება და ღამით იცლება, ნორმალურია; ის, რომელიც მხოლოდ იზრდება, ნიშნავს, რომ worker-ები ვერ ასწრებენ.
• ყველაზე ძველი მომლოდინე ამოცანის ასაკი. უფრო სასარგებლოა, ვიდრე რაოდენობა: 10,000 ამოცანა, რომელთაგან თითოს მილიწამი სჭირდება, არაფერია, ათი ამოცანა, რომელიც ერთი საათია ელოდება, ინციდენტია.
• ჩავარდნილი ამოცანები საათში, გაფრთხილებით ზრდაზე და არა ცალკეულ მარცხებზე.
• Valkey-ს მეხსიერება მის ლიმიტთან მიმართებით, INFO memory-დან, გაფრთხილებით noeviction კედლამდე კარგა ხნით ადრე.
• დაკავშირებული კლიენტები, INFO clients-დან. worker-ების ფლოტი, რომელიც კავშირებს აჟონავს, სერვერის კლიენტების ლიმიტზე მთავრდება.

ყოველ ბიბლიოთეკას აქვს dashboard, რომელიც ამის უმეტესობას აჩვენებს - Bull Board ან Taskforce BullMQ-ისთვის, Flower Celery-სთვის, rq-dashboard RQ-ისთვის, Horizon Laravel-ისთვის - მაგრამ dashboard, რომელსაც არავინ უყურებს, მონიტორინგი არ არის. ის ორი-სამი რიცხვი, რომელსაც მნიშვნელობა აქვს, გაიტანე იქ, რაც უკვე გაფრთხილებს; მონიტორინგი, რომელიც რამეს გეუბნება მათ არჩევას ეხება.

worker-ებს ზედამხედველობაც სჭირდებათ. worker პროცესი, რომელიც სრულდება - დაუმუშავებელი exception, მეხსიერების ამოწურვით გაჩერება, deploy - ავტომატურად უნდა გადაიტვირთოს, თორემ რიგი ჩუმად წყვეტს დაცლას, სანამ ვებ პროცესი მასში დამატებას აგრძელებს. VDS-ზე ეს systemd unit-ია Restart=always-ით; ჰოსტინგის პანელზე - სერვერის საკუთარი restart-ის ქცევა. ნებისმიერ შემთხვევაში, ყოველი deploy-ის შემდეგ შეამოწმე, რომ worker-ები დაბრუნდნენ.

პრობლემების მოგვარება#

ამოცანები ქრება ისე, რომ არც სრულდება და არც ვარდება. eviction, ან restart შენახვის გარეშე. შეამოწმე evicted_keys INFO stats-ში და eviction პოლიტიკა.

ერთი და იგივე ამოცანა ორჯერ სრულდება. visibility timeout ან retry_after ამოცანაზე მოკლეა, ან worker დადასტურებამდე მოკვდა. გაზარდე timeout და ამოცანა იდემპოტენტური გახადე.

worker-ები ქსელის მცირე შეფერხების შემდეგ ამოცანების აღებას წყვეტენ. კავშირი გაწყდა და კლიენტმა ხელი აიღო. BullMQ-ში შეამოწმე maxRetriesPerRequest: null; სხვაგან დარწმუნდი, რომ worker ზედამხედველობის ქვეშაა და დასრულებისას თავიდან ეშვება.

Valkey-ს მეხსიერება სტაბილურად იზრდება დაგროვების გარეშე. დასრულებული ამოცანები და შედეგები სამუდამოდ ინახება. დააყენე removeOnComplete, result_expires ან მისი ეკვივალენტი, შემდეგ კი ძველებს ვადის გასვლის საშუალება მიეცი.

`OOM command not allowed when used memory > 'maxmemory'`. noeviction პოლიტიკა თავის საქმეს აკეთებს. რიგი სავსეა: worker-ები გათიშულია ან ძალიან ნელია, ან ისტორია ავსებს მეხსიერებას.

FAQ#

შეუძლია Valkey-ს RabbitMQ-ის ან Kafka-ს ჩანაცვლება?

ერთი აპლიკაციის ფონური ამოცანებისთვის - კი, და ნაკლები სამართავით. RabbitMQ უკეთესია ბევრ სერვისს შორის რთულ routing-ში, Kafka კი დიდი მოვლენების ლოგების ხელახლა გასაშვებად შენახვაში. თუ მათ შორის აპის ელფოსტისა და thumbnail-ების ამოცანებისთვის ირჩევ, Valkey რიგი პროპორციული არჩევანია.

მუშაობს BullMQ, Celery და RQ Valkey-თან უცვლელად?

ისინი Redis-ის პროტოკოლზე საუბრობენ და იყენებენ სტანდარტულ ბრძანებებს და Lua სკრიპტინგს, რომლებიც Valkey-ს აქვს რეალიზებული. უკავშირდები იგივე redis:// URL-ით და იგივე კლიენტის ბიბლიოთეკებით. live-ზე გასვლამდე შენი ვერსია შენს სერვერზე გამოცადე, როგორც ინფრასტრუქტურის ნებისმიერი ცვლილებისას.

უნდა იზიარებდნენ რიგი და ქეში ერთ Valkey-ს?

სჯობს არა. ქეშს განდევნის პოლიტიკა სჭირდება, რიგმა კი არასოდეს უნდა განდევნოს. ერთ ინსტანციაზე არჩევა მოგიწევს, და ნებისმიერი არჩევანი ერთ-ერთისთვის არასწორია. ორი პატარა ინსტანცია ამას წყვეტს.

რამდენი worker უნდა გავუშვა?

იმდენი, რომ პიკზე დაგროვება ნულთან ახლოს დარჩეს, და არა იმაზე მეტი, რასაც სამუშაო გამოიყენებს. I/O-ზე დამოკიდებული ამოცანებისთვის, როგორიცაა ელფოსტის გაგზავნა, ერთი პროცესი 5-დან 20-მდე პარალელურობით დიდ გზას ფარავს. CPU-ზე დამოკიდებული ამოცანებისთვის, როგორიცაა სურათების დამუშავება, ერთი worker თითო ბირთვზე.

რა ემართება დაგეგმილ ამოცანებს, თუ Valkey გადაიტვირთა?

ჩართული შენახვით ისინი დისკზეა და ყველაფერ დანარჩენთან ერთად იტვირთება; დაყოვნებული ამოცანა, რომლის დროც restart-ის განმავლობაში გავიდა, შესრულდება, როცა worker-ები ხელახლა დაუკავშირდებიან. შენახვის გარეშე ყოველი მომლოდინე და დაგეგმილი ამოცანა ქრება.