1 개요[ | ]
- 라라벨 Queues
- Laravel 큐
https://laravel.com/docs/11.x/queues
2 소개[ | ]
웹 애플리케이션을 구축하는 동안, CSV 파일을 파싱하고 저장하는 것과 같이 일반적인 웹 요청 동안 처리하기에는 시간이 너무 오래 걸리는 작업이 있을 수 있습니다. 다행히도, Laravel을 사용하면 이러한 작업을 백그라운드에서 처리할 수 있는 큐된 작업을 쉽게 만들 수 있습니다. 시간이 많이 소요되는 작업을 큐로 옮김으로써 애플리케이션이 웹 요청에 신속하게 응답하고 더 나은 사용자 경험을 제공할 수 있습니다.
Laravel 큐는 Amazon SQS, Redis, 또는 관계형 데이터베이스와 같은 다양한 큐 백엔드에서 통일된 큐 API를 제공합니다.
Laravel의 큐 설정 옵션은 애플리케이션의 config/queue.php 설정 파일에 저장됩니다. 이 파일에서 프레임워크에 포함된 데이터베이스, Amazon SQS, Redis, Beanstalkd 드라이버와 동기 드라이버(로컬 개발 중에 사용하기 위해 즉시 작업 실행)를 포함함 각 큐 드라이버의 연결 설정을 찾을 수 있습니다. 큐에 추가된 작업을 폐기하는 null 큐 드라이버도 포함되어 있습니다.
Note
Laravel은 이제 Redis 기반 큐를 위한 아름다운 대시보드 및 설정 시스템인 Horizon을 제공합니다. 자세한 내용은 전체 Horizon 문서를 참조하십시오.
2.1 연결 vs 큐[ | ]
Laravel 큐 작업을 시작하기 전에 "연결(connections)"과 "큐(queues)"의 차이를 이해하는 것이 중요합니다. config/queue.php 설정 파일에는 connections 설정 배열이 있습니다. 이 옵션은 Amazon SQS, Beanstalk 또는 Redis와 같은 백엔드 큐 서비스에 대한 연결을 정의합니다. 그러나 주어진 큐 연결에는 여러 개의 "queues"가 있을 수 있으며, 이는 다른 작업이 대기 중인 스택이나 파일로 생각할 수 있습니다.
각 연결 설정 예제에는 queue 속성이 포함되어 있습니다. 이 속성은 주어진 연결에 작업이 전송될 때 기본적으로 전송되는 큐를 정의합니다. 즉, 작업을 명시적으로 어느 큐로 전송할지 정의하지 않고 작업을 전송하면, 그 작업은 연결 설정의 queue 속성에 정의된 큐에 배치됩니다:
use App\Jobs\ProcessPodcast;
// 이 작업은 기본 연결의 기본 큐로 전송됩니다.
ProcessPodcast::dispatch();
// 이 작업은 기본 연결의 "emails" 큐로 전송됩니다.
ProcessPodcast::dispatch()->onQueue('emails');
어떤 애플리케이션은 여러 큐에 작업을 푸시할 필요가 없고, 하나의 간단한 큐를 사용하는 것이 더 나을 수도 있습니다. 그러나 여러 큐에 작업을 푸시하는 것은 작업을 처리하는 우선순위를 지정하거나 세분화하려는 애플리케이션에 특히 유용할 수 있습니다. Laravel 큐 워커는 어떤 큐를 우선적으로 처리할지 지정할 수 있기 때문입니다. 예를 들어, high 큐에 작업을 푸시하면 높은 처리 우선순위를 부여하는 작업자를 실행할 수 있습니다:
php artisan queue:work --queue=high,default
2.2 드라이버 노트와 전제조건[ | ]
- 데이터베이스
database 큐 드라이버를 사용하려면, 작업을 보유할 데이터베이스 테이블이 필요합니다. 일반적으로 이것은 Laravel의 기본 0001_01_01_000002_create_jobs_table.php 데이터베이스 마이그레이션에 포함되어 있습니다. 그러나 애플리케이션에 이 마이그레이션이 포함되어 있지 않은 경우, make:queue-table Artisan 명령어를 사용하여 이를 생성할 수 있습니다:
php artisan make:queue-table
php artisan migrate
- Redis
redis 큐 드라이버를 사용하려면 config/database.php 설정 파일에서 Redis 데이터베이스 연결을 구성해야 합니다.
Warning
Redis 옵션 중
serializer와compression은redis큐 드라이버에서 지원되지 않습니다.
- Redis 클러스터
Redis 큐 연결에 Redis 클러스터를 사용하는 경우 큐 이름에 키 해시 태그를 포함해야 합니다. 이는 주어진 큐의 모든 Redis 키가 동일한 해시 슬롯에 배치되도록 보장하기 위해 필요합니다:
'redis' => [
'driver' => 'redis',
'connection' => env('REDIS_QUEUE_CONNECTION', 'default'),
'queue' => env('REDIS_QUEUE', '{default}'),
'retry_after' => env('REDIS_QUEUE_RETRY_AFTER', 90),
'block_for' => null,
'after_commit' => false,
],
- 차단
Redis 큐를 사용할 때 block_for 설정 옵션을 사용하여 작업이 사용가능해질 때까지 드라이버가 대기할 시간을 지정할 수 있습니다. 이를 통해 워커 루프를 반복하고 Redis 데이터베이스를 다시 폴링하는 것보다 더 효율적으로 할 수 있습니다. 예를 들어, 이 값을 5로 설정하면 드라이버가 작업이 사용가능해질 때까지 5초 동안 차단해야 함을 나타냅니다:
'redis' => [
'driver' => 'redis',
'connection' => env('REDIS_QUEUE_CONNECTION', 'default'),
'queue' => env('REDIS_QUEUE', 'default'),
'retry_after' => env('REDIS_QUEUE_RETRY_AFTER', 90),
'block_for' => 5,
'after_commit' => false,
],
Warning
block_for를0으로 설정하면 큐 워커가 작업이 사용가능해질 때까지 무기한 차단됩니다. 이렇게 하면 다음 작업이 처리될 때까지SIGTERM과 같은 신호가 처리되지 않습니다.
- 기타 드라이버 전제조건
다음 큐 드라이버에는 아래와 같은 의존성이 필요합니다. 이러한 의존성은 Composer 패키지 관리자를 통해 설치할 수 있습니다:
- Amazon SQS:
aws/aws-sdk-php ~3.0 - Beanstalkd:
pda/pheanstalk ~5.0 - Redis:
predis/predis ~2.0또는 phpredis PHP 확장
3 작업 생성하기[ | ]
3.1 작업 클래스 생성하기[ | ]
기본적으로 애플리케이션의 모든 큐 작업(queueable job)은 app/Jobs 디렉토리에 저장됩니다. app/Jobs 디렉토리가 존재하지 않으면 make:job Artisan 명령어를 실행할 때 자동으로 생성됩니다:
php artisan make:job ProcessPodcast
생성된 클래스는 Illuminate\Contracts\Queue\ShouldQueue 인터페이스를 구현하여 Laravel에게 해당 작업이 비동기적으로 실행되도록 큐에 푸시되어야 함을 알립니다.
Note
작업 스텁(Job stub)은 스텁 퍼블리싱(stub publishing)를 사용하여 커스터마이징할 수 있습니다.
3.2 클래스 구조[ | ]
작업(job) 클래스는 매우 간단하며, 일반적으로 큐에서 작업이 처리될 때 호출되는 handle 메소드만 포함합니다. 시작하기 위해, 팟캐스트 게시 서비스를 관리하고 업로드된 팟캐스트 파일을 게시하기 전에 처리해야 하는 예제 작업 클래스를 살펴보겠습니다.
<?php
namespace App\Jobs;
use App\Models\Podcast;
use App\Services\AudioProcessor;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
class ProcessPodcast implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
/**
* 새로운 작업 인스턴스를 생성합니다.
*/
public function __construct(
public Podcast $podcast,
) {}
/**
* 작업을 실행합니다.
*/
public function handle(AudioProcessor $processor): void
{
// 업로드된 팟캐스트를 처리합니다...
}
}
이 예제에서, 엘로퀀트 모델을 큐 작업의 생성자에 직접 전달할 수 있다는 점에 주목하세요. 작업에서 사용하는 SerializesModels 트레이트 덕분에, 엘로퀀트 모델과 그에 연결된 관계들이 작업이 처리될 때 우아하게 직렬화되고 역직렬화됩니다.
큐 작업의 생성자가 엘로퀀트 모델을 받는 경우, 모델의 식별자만 큐에 직렬화됩니다. 작업이 실제로 처리될 때, 큐 시스템은 데이터베이스에서 전체 모델 인스턴스와 그에 연결된 관계들을 자동으로 다시 가져옵니다. 이러한 모델 직렬화 접근 방식은 큐 드라이버에 보내지는 작업 페이로드를 훨씬 더 작게 만들어 줍니다.
handle메소드 의존성 주입
handle 메소드는 큐에서 작업이 처리될 때 호출됩니다. 작업의 handle 메소드에 의존성을 타입 힌트로 지정할 수 있다는 점에 주목하세요. Laravel 서비스 컨테이너는 이러한 의존성을 자동으로 주입합니다.
컨테이너가 handle 메소드에 의존성을 주입하는 방식을 완전히 제어하고 싶다면, 컨테이너의 bindMethod 메소드를 사용할 수 있습니다. bindMethod 메소드는 작업과 컨테이너를 받는 콜백을 인자로 받습니다. 콜백 내에서 handle 메소드를 원하는 방식으로 호출할 수 있습니다. 일반적으로, 이 메소드는 App\Providers\AppServiceProvider 서비스 제공자의 boot 메소드에서 호출해야 합니다:
use App\Jobs\ProcessPodcast;
use App\Services\AudioProcessor;
use Illuminate\Contracts\Foundation\Application;
$this->app->bindMethod([ProcessPodcast::class, 'handle'], function (ProcessPodcast $job, Application $app) {
return $job->handle($app->make(AudioProcessor::class));
});
Warning
이미지 컨텐츠와 같은 바이너리 데이터를 큐 작업에 전달하려면,
base64_encode함수로 인코딩해야 합니다. 그렇지 않으면 작업이 큐에 올려질 때 JSON으로 올바르게 직렬화되지 않을 수 있습니다.
- 큐 관계
모든 로드된 Eloquent 모델 관계는 작업이 큐에 들어갈 때 직렬화되기 때문에 직렬화된 작업 문자열이 매우 커질 수 있습니다. 또한, 작업이 역직렬화되고 모델 관계가 데이터베이스에서 다시 가져올 때, 관계가 전체적으로 가져오게 됩니다. 작업 큐 처리동안 모델이 직렬화되기 전에 적용된 이전 관계 제약조건은 작업이 역직렬화될 때 적용되지 않습니다. 따라서 주어진 관계의 부분집합을 작업하고 싶다면, 큐에 있는 작업 내에서 해당 관계를 다시 제약해야 합니다.
또는, 관계가 직렬화되지 않도록 하려면 속성 값을 설정할 때 모델의 withoutRelations 메소드를 호출할 수 있습니다. 이 메소드는 로드된 관계 없이 모델 인스턴스를 반환합니다:
/**
* 새로운 작업 인스턴스를 생성합니다.
*/
public function __construct(Podcast $podcast)
{
$this->podcast = $podcast->withoutRelations();
}
PHP 생성자 속성 프로모션을 사용하고 Eloquent 모델이 관계를 직렬화하지 않도록 표시하려는 경우, WithoutRelations 속성을 사용할 수 있습니다:
use Illuminate\Queue\Attributes\WithoutRelations;
/**
* 새로운 작업 인스턴스를 생성합니다.
*/
public function __construct(
#[WithoutRelations]
public Podcast $podcast
) {
}
작업이 단일 모델 대신 Eloquent 모델의 컬렉션 또는 배열을 받는 경우, 해당 콜렉션 내의 모델은 작업이 역직렬화되고 실행될 때 관계가 복원되지 않습니다. 이는 많은 수의 모델을 다루는 작업에서 과도한 리소스 사용을 방지하기 위함입니다.
3.3 고유 작업[ | ]
Warning
고유 작업(unique job)은 잠금(lock) 기능을 지원하는 캐시 드라이버가 필요합니다. 현재
memcached,redis,dynamodb,database,file,array캐시 드라이버는 원자적 잠금을 지원합니다. 또한, 고유 잠금 제약조건은 배치 내 작업에는 적용되지 않습니다.
특정 작업의 인스턴스가 한 번에 하나만 큐에 있어야 하는 경우가 있습니다. 이를 위해 작업 클래스에 ShouldBeUnique 인터페이스를 구현할 수 있습니다. 이 인터페이스를 구현해도 추가 메소드를 정의할 필요는 없습니다:
<?php
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Contracts\Queue\ShouldBeUnique;
class UpdateSearchIndex implements ShouldQueue, ShouldBeUnique
{
...
}
위 예시에서 UpdateSearchIndex 작업은 고유합니다. 따라서 작업이 큐에 있는 다른 인스턴스가 아직 처리되지 않은 경우, 작업이 디스패치되지 않습니다.
특정 키를 정의하여 작업을 고유하게 하거나, 작업이 더 이상 고유하지 않도록 하는 타임아웃을 지정하고 싶을 때가 있습니다. 이를 위해 작업 클래스에서 uniqueId와 uniqueFor 속성 또는 메소드를 정의할 수 있습니다:
<?php
use App\Models\Product;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Contracts\Queue\ShouldBeUnique;
class UpdateSearchIndex implements ShouldQueue, ShouldBeUnique
{
/**
* 제품 인스턴스.
*
* @var \App\Product
*/
public $product;
/**
* 작업의 고유 잠금이 해제되는 시간(초).
*
* @var int
*/
public $uniqueFor = 3600;
/**
* 작업의 고유 ID를 얻습니다.
*/
public function uniqueId(): string
{
return $this->product->id;
}
}
위 예시에서 UpdateSearchIndex 작업은 제품 ID로 고유합니다. 따라서 동일한 제품 ID로 작업을 새로 디스패치하면 기존 작업이 완료될 때까지 무시됩니다. 또한, 기존 작업이 1시간 내에 처리되지 않으면 고유 잠금이 해제되어 동일한 고유 키를 가진 다른 작업이 큐에 디스패치될 수 있습니다.
Warning
애플리케이션이 여러 웹 서버 또는 컨테이너에서 작업을 디스패치하는 경우, 모든 서버가 동일한 중앙 캐시 서버와 통신하도록 해야 Laravel이 작업이 고유한지 정확하게 판단할 수 있습니다.
- 처리 시작까지 작업을 고유하게 유지하기
기본적으로 고유 작업은 작업이 처리 완료되거나 모든 재시도 시도가 실패한 후 "잠금 해제(unlocked)"됩니다. 그러나 작업이 처리되기 직전에 잠금을 해제하고 싶은 경우가 있을 수 있습니다. 이를 위해 작업이 ShouldBeUnique 계약 대신 ShouldBeUniqueUntilProcessing 계약을 구현해야 합니다:
<?php
use App\Models\Product;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Contracts\Queue\ShouldBeUniqueUntilProcessing;
class UpdateSearchIndex implements ShouldQueue, ShouldBeUniqueUntilProcessing
{
// ...
}
- 고유 작업 잠금
백그라운드에서 ShouldBeUnique 작업이 디스패치될 때 Laravel은 uniqueId 키로 잠금을 시도합니다. 잠금을 획득하지 못하면 작업이 디스패치되지 않습니다. 이 잠금은 작업이 완료되거나 모든 재시도가 실패할 때 해제됩니다. 기본적으로 Laravel은 기본 캐시 드라이버를 사용하여 이 잠금을 획득합니다. 그러나 다른 드라이버를 사용하여 잠금을 획득하고 싶다면 uniqueVia 메소드를 정의하여 사용할 캐시 드라이버를 반환할 수 있습니다:
use Illuminate\Contracts\Cache\Repository;
use Illuminate\Support\Facades\Cache;
class UpdateSearchIndex implements ShouldQueue, ShouldBeUnique
{
...
/**
* 고유 작업 잠금을 위한 캐시 드라이버를 얻습니다.
*/
public function uniqueVia(): Repository
{
return Cache::driver('redis');
}
}
Note
동시 처리 제한만 필요하다면,
WithoutOverlapping작업 미들웨어를 사용하세요.
3.4 암호화된 작업[ | ]
Laravel은 작업 데이터의 프라이버시와 무결성을 보장하기 위해 암호화를 사용할 수 있게 해줍니다. 시작하려면 단순히 ShouldBeEncrypted 인터페이스를 작업 클래스에 추가하면 됩니다. 이 인터페이스가 클래스에 추가되면 Laravel은 작업을 큐에 넣기 전에 자동으로 암호화합니다:
<?php
use Illuminate\Contracts\Queue\ShouldBeEncrypted;
use Illuminate\Contracts\Queue\ShouldQueue;
class UpdateSearchIndex implements ShouldQueue, ShouldBeEncrypted
{
// ...
}
4 작업 미들웨어[ | ]
작업 미들웨어를 사용하면 큐 작업의 실행 주위에 커스텀 로직을 래핑할 수 있어 작업 자체의 보일러플레이트 코드를 줄일 수 있습니다. 예를 들어, Laravel의 Redis 레이트 리미팅 기능을 활용하여 5초마다 하나의 작업만 처리하도록 하는 다음의 handle 메소드를 살펴보십시오:
use Illuminate\Support\Facades\Redis;
/**
* 작업을 실행합니다.
*/
public function handle(): void
{
Redis::throttle('key')->block(0)->allow(1)->every(5)->then(function () {
info('잠금 획득...');
// 작업 처리...
}, function () {
// 잠금을 획득하지 못했습니다...
return $this->release(5);
});
}
이 코드는 유효하지만, handle 메소드의 구현이 Redis 레이트 리미팅 로직으로 인해 복잡해집니다. 또한, 이 레이트 리미팅 로직은 레이트 리미팅을 적용하려는 다른 작업에도 중복해야 합니다.
handle 메소드에서 레이트 리미팅을 설정하는 대신, 레이트 리미팅을 처리하는 작업 미들웨어를 정의할 수 있습니다. Laravel에는 작업 미들웨어의 기본 위치가 없으므로 애플리케이션의 어디에나 작업 미들웨어를 배치할 수 있습니다. 이 예제에서는 app/Jobs/Middleware 디렉토리에 미들웨어를 배치합니다:
<?php
namespace App\Jobs\Middleware;
use Closure;
use Illuminate\Support\Facades\Redis;
class RateLimited
{
/**
* 큐 작업을 처리합니다.
*
* @param \Closure(object): void $next
*/
public function handle(object $job, Closure $next): void
{
Redis::throttle('key')
->block(0)->allow(1)->every(5)
->then(function () use ($job, $next) {
// 잠금 획득...
$next($job);
}, function () use ($job) {
// 잠금을 획득하지 못했습니다...
$job->release(5);
});
}
}
보다시피, 라우트 미들웨어와 마찬가지로 작업 미들웨어는 처리 중인 작업과 작업 처리를 계속하기 위해 호출해야 하는 콜백을 받습니다.
작업 미들웨어를 생성한 후, 이를 작업에 붙이려면 작업의 middleware 메소드에서 반환해야 합니다. 이 메소드는 make:job Artisan 명령어로 스캐폴드된 작업에는 존재하지 않으므로 작업 클래스에 수동으로 추가해야 합니다:
use App\Jobs\Middleware\RateLimited;
/**
* 작업이 통과해야 하는 미들웨어를 가져옵니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [new RateLimited];
}
Note
작업 미들웨어는 큐가능 이벤트 리스너, 메일가능, 알림에도 할당할 수 있습니다.
4.1 레이트 제한[ | ]
우리가 직접 레이트 제한 작업 미들웨어를 작성하는 방법을 시연했지만, Laravel에는 작업을 레이트 제한하는 데 사용할 수 있는 레이트 제한 미들웨어가 포함되어 있습니다. 라우트 레이트 제한기와 마찬가지로 작업 레이트 제한기는 RateLimiter 파사드의 for 메소드를 사용하여 정의됩니다.
예를 들어, 사용자가 데이터를 한 시간에 한 번 백업할 수 있도록 하고, 프리미엄 고객에게는 이러한 제한을 적용하지 않으려 할 수 있습니다. 이를 위해 AppServiceProvider의 boot 메소드에서 RateLimiter를 정의할 수 있습니다:
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;
/**
* 모든 애플리케이션 서비스를 부트스트랩합니다.
*/
public function boot(): void
{
RateLimiter::for('backups', function (object $job) {
return $job->user->vipCustomer()
? Limit::none()
: Limit::perHour(1)->by($job->user->id);
});
}
위의 예제에서는 시간당 레이트 제한을 정의했지만, perMinute 메소드를 사용하여 분 단위로 레이트 제한을 쉽게 정의할 수 있습니다. 또한, by 메소드에 원하는 값을 전달할 수 있으며, 이 값은 주로 고객별로 레이트 제한을 구분하는 데 사용됩니다:
return Limit::perMinute(50)->by($job->user->id);
레이트 제한을 정의한 후에는 Illuminate\Queue\Middleware\RateLimited 미들웨어를 사용하여 작업에 레이트 제한기를 연결할 수 있습니다. 작업이 레이트 제한을 초과할 때마다 이 미들웨어는 적절한 지연을 두고 작업을 큐로 다시 릴리스합니다.
use Illuminate\Queue\Middleware\RateLimited;
/**
* 작업이 통과해야 하는 미들웨어를 얻습니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [new RateLimited('backups')];
}
레이트 제한된 작업을 큐로 다시 릴리스하면 작업의 총 시도 횟수가 계속 증가합니다. 따라서 작업 클래스의 tries 및 maxExceptions 속성을 조정하고 싶을 수 있습니다. 또는 retryUntil 메소드를 사용하여 작업이 더 이상 시도되지 않아야 하는 시간을 정의할 수 있습니다.
작업이 레이트 제한된 경우 다시 시도하지 않으려면 dontRelease 메소드를 사용할 수 있습니다:
/**
* 작업이 통과해야 하는 미들웨어를 가져옵니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [(new RateLimited('backups'))->dontRelease()];
}
Note
Redis를 사용하는 경우, Redis에 파인튜닝되어 기본 레이트 제한 미들웨어보다 효율적인
Illuminate\Queue\Middleware\RateLimitedWithRedis미들웨어를 사용할 수 있습니다.
4.2 작업 중첩 방지[ | ]
Laravel은 임의의 키를 기반으로 작업 중첩을 방지할 수 있는 Illuminate\Queue\Middleware\WithoutOverlapping 미들웨어를 포함하고 있습니다. 이는 큐에 있는 작업이 동시에 동일한 리소스를 수정하는 것을 방지할 때 유용합니다. 예를 들어, 사용자의 신용 점수를 업데이트하는 큐 작업이 있고 동일한 사용자 ID에 대해 작업이 중첩되지 않도록 하려면 다음과 같이 작업의 미들웨어 메소드에서 WithoutOverlapping 미들웨어를 반환하면 됩니다:
use Illuminate\Queue\Middleware\WithoutOverlapping;
/**
* 작업이 거쳐야 하는 미들웨어를 얻습니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [new WithoutOverlapping($this->user->id)];
}
같은 유형의 중첩된 작업은 큐로 다시 돌아가게 됩니다. 또한, 릴리스된 작업이 다시 시도되기 전까지 경과해야 하는 시간을 지정할 수도 있습니다:
/**
* 작업이 거쳐야 하는 미들웨어를 얻습니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [(new WithoutOverlapping($this->order->id))->releaseAfter(60)];
}
중첩된 작업이 즉시 삭제되도록 하고, 다시 시도되지 않게 하려면 dontRelease 메소드를 사용할 수 있습니다:
/**
* 작업이 거쳐야 하는 미들웨어를 얻습니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [(new WithoutOverlapping($this->order->id))->dontRelease()];
}
WithoutOverlapping 미들웨어는 Laravel의 원자적 잠금 기능을 통해 작동합니다. 때로는 작업이 예기치 않게 실패하거나 시간 초과되어 잠금이 해제되지 않을 수 있습니다. 따라서 expireAfter 메소드를 사용하여 잠금 만료 시간을 명시적으로 정의할 수 있습니다. 예를 들어, 아래 예제에서는 작업이 처리되기 시작한 후 3분 후에 WithoutOverlapping 잠금을 해제하도록 Laravel에 지시합니다:
use Illuminate\Queue\Middleware\WithoutOverlapping;
/**
* 작업이 거쳐야 하는 미들웨어를 얻습니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [(new WithoutOverlapping($this->order->id))->expireAfter(180)];
}
Warning
WithoutOverlapping미들웨어는 잠금(lock)을 지원하는 캐시 드라이버가 필요합니다. 현재memcached,redis,dynamodb, database,file,array캐시 드라이버가 원자적 잠금을 지원합니다.
- 작업 클래스 간의 잠금 키 공유
기본적으로, WithoutOverlapping 미들웨어는 동일한 클래스의 중첩 작업만 방지합니다. 따라서 두 개의 다른 작업 클래스가 동일한 잠금 키를 사용하더라도 중첩을 방지할 수 없습니다. 그러나 shared 메소드를 사용하여 Laravel에 작업 클래스 간에 키를 적용하도록 지시할 수 있습니다.
use Illuminate\Queue\Middleware\WithoutOverlapping;
class ProviderIsDown
{
// ...
public function middleware(): array
{
return [
(new WithoutOverlapping("status:{$this->provider}"))->shared(),
];
}
}
class ProviderIsUp
{
// ...
public function middleware(): array
{
return [
(new WithoutOverlapping("status:{$this->provider}"))->shared(),
];
}
}
4.3 예외 쓰로틀링[ | ]
Laravel은 예외를 쓰로틀링할 수 있는 Illuminate\Queue\Middleware\ThrottlesExceptions 미들웨어를 포함하고 있습니다. 이 미들웨어는 주어진 횟수만큼 예외가 발생하면 모든 추가적인 시도는 지정된 시간 간격이 지날 때까지 지연됩니다. 이는 불안정한 서드파티 서비스와 상호작용하는 작업에 특히 유용합니다.
예를 들어, 서드파티 API와 상호작용하는 큐 작업이 예외를 발생시키기 시작한다고 가정해 봅시다. 예외를 쓰로틀링하려면 작업의 middleware 메소드에서 ThrottlesExceptions 미들웨어를 반환할 수 있습니다. 일반적으로 이 미들웨어는 시간 기반 시도를 구현하는 작업과 함께 사용해야 합니다:
use DateTime;
use Illuminate\Queue\Middleware\ThrottlesExceptions;
/**
* 작업이 통과해야 하는 미들웨어를 가져옵니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [new ThrottlesExceptions(10, 5)];
}
/**
* 작업이 타임아웃될 시점을 결정합니다.
*/
public function retryUntil(): DateTime
{
return now()->addMinutes(5);
}
미들웨어가 받는 첫 번째 인자는 작업이 제한되기 전에 던질 수 있는 예외의 수이고, 두 번째 인자는 작업이 다시 시도되기 전에 경과해야 하는 시간(분)입니다. 위의 코드 예제에서 작업이 5분 내에 10개의 예외를 던지면, 다시 시도하기 전에 5분을 기다립니다.
작업이 예외를 던졌지만 예외 임계값에 도달하지 않은 경우, 작업은 일반적으로 즉시 재시도됩니다. 그러나 미들웨어를 작업에 첨부할 때 backoff 메소드를 호출하여 그러한 작업이 지연될 시간을 지정할 수 있습니다:
use Illuminate\Queue\Middleware\ThrottlesExceptions;
/**
* 작업이 통과해야 하는 미들웨어를 가져옵니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [(new ThrottlesExceptions(10, 5))->backoff(5)];
}
내부적으로 이 미들웨어는 Laravel의 캐시 시스템을 사용하여 레이트 제한을 구현하며, 작업의 클래스 이름을 캐시 "키"로 사용합니다. 작업에 미들웨어를 첨부할 때 by 메소드를 호출하여 이 키를 재정의할 수 있습니다. 이는 동일한 서드파티 서비스와 상호작용하는 여러 작업이 공통의 쓰로틀링 "버킷"을 공유하도록 하려는 경우에 유용할 수 있습니다:
use Illuminate\Queue\Middleware\ThrottlesExceptions;
/**
* 작업이 통과해야 하는 미들웨어를 가져옵니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [(new ThrottlesExceptions(10, 10))->by('key')];
}
기본적으로 이 미들웨어는 모든 예외를 쓰로틀링합니다. 작업에 미들웨어를 첨부할 때 when 메소드를 호출하여 이 동작을 수정할 수 있습니다. 제공된 클로저가 true를 반환할 때만 예외가 쓰로틀링됩니다:
use Illuminate\Http\Client\HttpClientException;
use Illuminate\Queue\Middleware\ThrottlesExceptions;
/**
* 작업이 통과해야 하는 미들웨어를 가져옵니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [(new ThrottlesExceptions(10, 10))->when(
fn (Throwable $throwable) => $throwable instanceof HttpClientException
)];
}
쓰로틀링된 예외를 애플리케이션의 예외 핸들러에게 보고하려면, 작업에 미들웨어를 첨부할 때 report 메소드를 호출할 수 있습니다. 선택적으로, report 메소드에 클로저를 제공하여 주어진 클로저가 true를 반환할 때만 예외가 보고되도록 할 수 있습니다:
use Illuminate\Http\Client.HttpClientException;
use Illuminate\Queue\Middleware\ThrottlesExceptions;
/**
* 작업이 통과해야 하는 미들웨어를 가져옵니다.
*
* @return array<int, object>
*/
public function middleware(): array
{
return [(new ThrottlesExceptions(10, 10))->report(
fn (Throwable $throwable) => $throwable instanceof HttpClientException
)];
}
Note
Redis를 사용하는 경우, Redis에 파인튜닝되어 기본 예외 쓰로틀링 미들웨어보다 효율적인
Illuminate\Queue\Middleware\ThrottlesExceptionsWithRedis미들웨어를 사용할 수 있습니다.
5 작업 디스패치[ | ]
일단 작업 클래스를 작성한 후, 해당 작업의 dispatch 메소드를 사용하여 작업을 디스패치할 수 있습니다. dispatch 메소드에 전달된 인수는 작업의 생성자에 전달됩니다:
<?php
namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
class PodcastController extends Controller
{
/**
* 새로운 팟캐스트를 저장합니다.
*/
public function store(Request $request): RedirectResponse
{
$podcast = Podcast::create(/* ... */);
// ...
ProcessPodcast::dispatch($podcast);
return redirect('/podcasts');
}
}
작업을 조건부로 디스패치하려면, dispatchIf와 dispatchUnless 메소드를 사용할 수 있습니다:
ProcessPodcast::dispatchIf($accountActive, $podcast);
ProcessPodcast::dispatchUnless($accountSuspended, $podcast);
새 Laravel 애플리케이션에서, 기본 큐 드라이버는 sync 드라이버입니다. 이 드라이버는 작업을 현재 요청의 포어그라운드에서 동기적으로 실행하므로, 로컬 개발 중에 편리합니다. 작업을 백그라운드에서 처리하기 위해 실제로 큐잉을 시작하려면, 애플리케이션의 config/queue.php 설정 파일에서 다른 큐 드라이버를 지정할 수 있습니다.
5.1 지연된 디스패치[ | ]
큐 워커가 작업을 즉시 처리할 수 없도록 지정하려면, 작업을 디스패치할 때 delay 메소드를 사용할 수 있습니다. 예를 들어, 작업이 디스패칭된 후 10분이 지나야 처리할 수 있도록 지정하려면 다음과 같이 합니다:
<?php
namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
class PodcastController extends Controller
{
/**
* 새 팟캐스트를 저장합니다.
*/
public function store(Request $request): RedirectResponse
{
$podcast = Podcast::create(/* ... */);
// ...
ProcessPodcast::dispatch($podcast)
->delay(now()->addMinutes(10));
return redirect('/podcasts');
}
}
Warning
Amazon SQS 큐 서비스는 최대 지연 시간이 15분입니다.
5.2 동기식 디스패치[ | ]
작업을 즉시 (동기식으로) 디스패치하고 싶다면, dispatchSync 메소드를 사용할 수 있습니다. 이 메소드를 사용할 때, 작업은 큐에 추가되지 않고 현재 프로세스 내에서 즉시 실행됩니다:
namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
class PodcastController extends Controller
{
/**
* 새로운 팟캐스트를 저장합니다.
*/
public function store(Request $request): RedirectResponse
{
$podcast = Podcast::create(/* ... */);
// 팟캐스트 생성...
ProcessPodcast::dispatchSync($podcast);
return redirect('/podcasts');
}
}
5.3 작업 & 데이터베이스 트랜잭션[ | ]
데이터베이스 트랜잭션 내에서 작업을 디스패치하는 것은 완벽하게 가능하지만, 작업이 실제로 성공적으로 실행될 수 있도록 주의해야 합니다. 트랜잭션 내에서 작업을 디스패치할 때, 작업이 워커에 의해 처리되는 시점에 부모 트랜잭션이 커밋되기 전일 수 있습니다. 이 경우, 데이터베이스 트랜잭션 동안 모델이나 데이터베이스 레코드에 대해 수행한 업데이트가 아직 데이터베이스에 반영되지 않을 수 있습니다. 또한, 트랜잭션 내에서 생성된 모델이나 데이터베이스 레코드가 데이터베이스에 존재하지 않을 수 있습니다.
다행히도, Laravel은 이 문제를 해결하기 위한 여러 방법을 제공합니다. 먼저, 큐 연결 설정 배열에서 after_commit 연결 옵션을 세팅할 수 있습니다:
'redis' => [
'driver' => 'redis',
// ...
'after_commit' => true,
],
after_commit 옵션이 true이면, 데이터베이스 트랜잭션 내에서 작업을 디스패치할 수 있습니다. 하지만, Laravel은 부모 데이터베이스 트랜잭션이 커밋될 때까지 실제로 잡을 디스패치하지 않습니다. 물론, 현재 열려 있는 데이터베이스 트랜잭션이 없으면 작업은 즉시 디스패치됩니다.
트랜잭션 도중 예외가 발생하여 트랜잭션이 롤백되면, 해당 트랜잭션 동안 디스패치된 작업은 삭제됩니다.
Note
after_commit설정 옵션을true로 세팅하면, 큐에 넣은 이벤트 리스너, 메일러블, 알림 및 브로드캐스트 이벤트도 모든 열린 데이터베이스 트랜잭션이 커밋된 후에 디스패치됩니다.
- 커밋 디스패치 동작을 인라인으로 지정하기
after_commit 큐 연결 설정 옵션을 true로 설정하지 않은 경우에도, 특정 작업이 모든 열린 데이터베이스 트랜잭션이 커밋된 후에 디스패치되도록 지정할 수 있습니다. 이를 위해 디스패치 작업에 afterCommit 메소드를 체인할 수 있습니다:
use App\Jobs\ProcessPodcast;
ProcessPodcast::dispatch($podcast)->afterCommit();
마찬가지로, after_commit 설정 옵션이 true로 설정된 경우에도, 특정 작업이 열린 데이터베이스 트랜잭션이 커밋되기를 기다리지 않고 즉시 디스패치되도록 지정할 수 있습니다:
ProcessPodcast::dispatch($podcast)->beforeCommit();
5.4 작업 체이닝[ | ]
작업 체이닝은 주 작업이 성공적으로 실행된 후 순차적으로 실행되어야 하는 큐에 있는 작업 목록을 지정할 수 있게 해줍니다. 체인에 있는 작업 중 하나가 실패하면 나머지 작업은 실행되지 않습니다. 큐에 있는 작업 체인을 실행하려면 Bus 파사드에서 제공하는 chain 메소드를 사용할 수 있습니다. Laravel의 커맨드 버스는 큐 작업 디스패칭 위에 구축된 하위 수준 컴포넌트입니다:
use App\Jobs\OptimizePodcast;
use App\Jobs\ProcessPodcast;
use App\Jobs\ReleasePodcast;
use Illuminate\Support\Facades\Bus;
Bus::chain([
new ProcessPodcast,
new OptimizePodcast,
new ReleasePodcast,
])->dispatch();
작업 클래스 인스턴스를 체이닝하는 것 외에도 클로저를 체이닝할 수도 있습니다:
Bus::chain([
new ProcessPodcast,
new OptimizePodcast,
function () {
Podcast::update(/* ... */);
},
])->dispatch();
Warning
작업 내에서
$this->delete()메소드를 사용하여 작업을 삭제해도 체이닝된 작업이 처리되는 것을 막을 수는 없습니다. 체인에 있는 작업이 실패해야만 체인이 실행을 멈춥니다.
- 연결 및 큐 체인
체인 작업들에 사용할 연결과 큐를 지정하려면, onConnection과 onQueue 메소드를 사용할 수 있습니다. 이러한 메소드는 큐 작업에 명시적으로 다른 연결/큐가 지정되지 않는 한 사용해야 하는 큐 연결 및 큐 이름을 지정합니다:
Bus::chain([
new ProcessPodcast,
new OptimizePodcast,
new ReleasePodcast,
])->onConnection('redis')->onQueue('podcasts')->dispatch();
- 체인에 작업 추가
때로는, 체인의 다른 작업 내에서 기존 작업 체인에 작업을 앞이나 뒤에 추가해야 할 수 있습니다. 이는 prependToChain과 appendToChain 메소드를 사용하여 수행할 수 있습니다:
/**
* 작업을 실행합니다.
*/
public function handle(): void
{
// ...
// 현재 체인에 앞에 추가하여 현재 작업 직후에 실행...
$this->prependToChain(new TranscribePodcast);
// 현재 체인에 뒤에 추가하여 체인의 끝에서 실행...
$this->appendToChain(new TranscribePodcast);
}
- 체인 실패
작업을 체이닝할 때, 체인의 작업 중 하나가 실패할 경우 호출해야 하는 클로저를 catch 메소드를 사용하여 지정할 수 있습니다. 주어진 콜백은 작업 실패를 초래한 Throwable 인스턴스를 받습니다:
use Illuminate\Support\Facades\Bus;
use Throwable;
Bus::chain([
new ProcessPodcast,
new OptimizePodcast,
new ReleasePodcast,
])->catch(function (Throwable $e) {
// 체인 내의 작업이 실패했습니다...
})->dispatch();
Warning
체인 콜백은 직렬화되어 나중에 Laravel 큐에 의해 실행되므로, 체인 콜백 내에서
$this변수를 사용해서는 안 됩니다.
5.5 큐 연결 커스터마이징[ | ]
- 특정 큐에 작업을 디스패치하기
작업을 다른 큐로 푸시함으로써 큐 작업을 "카테고리화"하고, 다양한 큐에 할당하는 워커의 수를 우선적으로 조정할 수 있습니다. 이는 큐 설정 파일에 정의된 다른 큐 "연결"로 작업을 푸시하는 것이 아니라, 단일 연결 내에서 특정 큐로 작업을 푸시하는 것을 의미합니다. 작업을 특정 큐에 지정하려면 작업을 디스패치할 때 onQueue 메소드를 사용합니다:
<?php
namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
class PodcastController extends Controller
{
/**
* 새로운 팟캐스트 저장.
*/
public function store(Request $request): RedirectResponse
{
$podcast = Podcast::create(/* ... */);
// 팟캐스트 생성...
ProcessPodcast::dispatch($podcast)->onQueue('processing');
return redirect('/podcasts');
}
}
또는 작업의 생성자 내에서 onQueue 메소드를 호출하여 작업의 큐를 지정할 수 있습니다:
<?php
namespace App\Jobs;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
class ProcessPodcast implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
/**
* 새 작업 인스턴스 생성.
*/
public function __construct()
{
$this->onQueue('processing');
}
}
- 특정 연결로 디스패치하기
애플리케이션이 여러 큐 연결과 상호작용하는 경우, onConnection 메소드를 사용하여 작업을 푸시할 연결을 지정할 수 있습니다:
<?php
namespace App\Http\Controllers;
use App\Http\Controllers\Controller;
use App\Jobs\ProcessPodcast;
use App\Models\Podcast;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
class PodcastController extends Controller
{
/**
* 새로운 팟캐스트 저장.
*/
public function store(Request $request): RedirectResponse
{
$podcast = Podcast::create(/* ... */);
// 팟캐스트 생성...
ProcessPodcast::dispatch($podcast)->onConnection('sqs');
return redirect('/podcasts');
}
}
작업에 대해 연결과 큐를 함께 지정하려면 onConnection과 onQueue 메소드를 체인으로 연결하여 사용합니다:
ProcessPodcast::dispatch($podcast)
->onConnection('sqs')
->onQueue('processing');
또는 작업의 생성자 내에서 onConnection 메소드를 호출하여 작업의 연결을 지정할 수 있습니다:
<?php
namespace App\Jobs;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
class ProcessPodcast implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
/**
* 새 작업 인스턴스 생성.
*/
public function __construct()
{
$this->onConnection('sqs');
}
}
5.6 최대 작업 시도횟수 / 타임아웃 값 지정[ | ]
- 최대 시도횟수
큐에 있는 작업이 오류를 발생시키면, 무한정으로 재시도하는 것을 원하지 않을 것입니다. 따라서 Laravel은 작업이 시도하는 횟수 또는 시간을 지정하는 다양한 방법을 제공합니다.
작업을 시도할 최대 횟수를 지정하는 한 가지 방법은 Artisan 명령줄의 --tries 스위치를 사용하는 것입니다. 이는 워커가 처리하는 모든 작업에 적용되며, 작업이 시도될 최대 횟수를 지정하지 않은 경우에만 적용됩니다:
php artisan queue:work --tries=3
작업이 최대 시도 횟수를 초과하면 "실패한" 작업으로 간주됩니다. 실패한 작업 처리에 대한 자세한 내용은 실패한 작업 문서를 참조하세요. queue:work 명령어에 --tries=0을 제공하면, 작업은 무한정으로 재시도됩니다.
작업 클래스 자체에 작업이 시도될 최대 횟수를 정의함으로써 보다 세밀한 제어를 할 수 있습니다. 작업 클래스에 최대 시도 횟수를 지정하면 명령줄에서 제공된 --tries 값보다 우선합니다:
<?php
namespace App\Jobs;
class ProcessPodcast implements ShouldQueue
{
/**
* 작업이 시도될 최대 횟수
*
* @var int
*/
public $tries = 5;
}
특정 작업의 최대 시도 횟수를 동적으로 제어하려면 작업 클래스에 tries 메소드를 정의할 수 있습니다:
/**
* 작업이 시도될 횟수를 결정합니다.
*/
public function tries(): int
{
return 5;
}
- 시간 기반 시도
작업이 실패하기 전에 시도될 횟수를 정의하는 대신, 작업이 더 이상 시도되지 않아야 하는 시간을 정의할 수 있습니다. 이를 통해 주어진 시간 내에 작업을 여러 번 시도할 수 있습니다. 작업 클래스에 retryUntil 메소드를 추가하여 작업이 더 이상 시도되지 않아야 하는 시간을 정의할 수 있습니다. 이 메소드는 DateTime 인스턴스를 반환해야 합니다:
use DateTime;
/**
* 작업이 타임아웃되는 시간을 결정합니다.
*/
public function retryUntil(): DateTime
{
return now()->addMinutes(10);
}
Note
큐에 있는 이벤트 리스너에서도
tries속성이나retryUntil메소드를 정의할 수 있습니다.
- 최대 예외 수
때로는 작업을 여러 번 시도하지만, 일정 횟수의 처리되지 않은 예외로 인한 재시도가 발생하면(release 메소드에 의해 릴리스되는 것과는 반대임) 실패하도록 설정하고자 할 수 있습니다. 이를 위해 작업 클래스에 maxExceptions 속성을 정의할 수 있습니다:
<?php
namespace App\Jobs;
use Illuminate\Support\Facades\Redis;
class ProcessPodcast implements ShouldQueue
{
/**
* 작업이 시도될 최대 횟수
*
* @var int
*/
public $tries = 25;
/**
* 실패하기 전에 허용할 최대 처리되지 않은 예외의 수
*
* @var int
*/
public $maxExceptions = 3;
/**
* 작업을 실행합니다.
*/
public function handle(): void
{
Redis::throttle('key')->allow(10)->every(60)->then(function () {
// 잠금이 획득됨, 팟캐스트를 처리합니다...
}, function () {
// 잠금을 획득할 수 없음...
return $this->release(10);
});
}
}
이 예제에서, 작업이 Redis 잠금을 획득할 수 없는 경우 10초 동안 릴리스되며 최대 25회까지 재시도됩니다. 그러나 작업은 세 번의 처리되지 않은 예외가 발생하면 실패합니다.
- 타임아웃
작업이 대략적으로 얼마나 걸릴지 예상할 수 있는 경우가 많습니다. 이러한 이유로 Laravel은 타임아웃 값을 지정할 수 있게 합니다. 기본 타임아웃 값은 60초입니다. 작업이 지정된 타임아웃 값을 더 오래 처리하는 경우, 작업을 처리하는 워커는 오류와 함께 종료됩니다. 일반적으로 워커는 서버에 구성된 프로세스 매니저에 의해 자동으로 재시작됩니다.
작업이 실행될 수 있는 최대 시간을 Artisan 명령줄에서 --timeout 스위치를 사용하여 지정할 수 있습니다:
php artisan queue:work --timeout=30
작업이 지속적으로 타임아웃되어 최대 시도 횟수를 초과하면, 해당 작업은 실패로 마킹됩니다.
작업 클래스 자체에 작업이 실행될 최대 시간을 정의할 수도 있습니다. 작업 클래스에 타임아웃이 지정되면, 명령줄에 지정된 타임아웃보다 우선합니다:
<?php
namespace App\Jobs;
class ProcessPodcast implements ShouldQueue
{
/**
* 작업이 타임아웃되기 전에 실행될 수 있는 최대 시간(초)
*
* @var int
*/
public $timeout = 120;
}
때로는 소켓이나 외부 HTTP 연결과 같은 IO 차단 프로세스는 지정한 타임아웃을 준수하지 않을 수 있습니다. 따라서, 이러한 기능을 사용할 때는 해당 API를 통해 타임아웃을 지정하려고 해야 합니다. 예를 들어, Guzzle을 사용할 때는 항상 연결 및 요청 타임아웃 값을 지정해야 합니다.
Warning
작업 타임아웃을 지정하려면
pcntlPHP 확장이 설치되어 있어야 합니다. 또한, 작업의 "timeout(타임아웃)" 값은 항상 "retry after(이후 재시도)" 값보다 작아야 합니다. 그렇지 않으면, 작업이 실제로 완료되거나 타임아웃되기 전에 다시 시도될 수 있습니다.
- 타임아웃 시 실패로 처리하기
타임아웃 시 작업이 실패로 마킹되게 하려면, 작업 클래스에 $failOnTimeout 속성을 정의할 수 있습니다:
/**
* 작업이 타임아웃 시 실패로 마킹할지 여부를 나타냅니다.
*
* @var bool
*/
public $failOnTimeout = true;
이렇게 설정하면 작업이 타임아웃될 때 실패로 마킹됩니다.
5.7 오류 핸들링[ | ]
작업이 처리되는 동안 예외가 발생하면, 작업은 자동으로 큐에 다시 릴리스되어 다시 시도할 수 있습니다. 작업은 애플리케이션에서 허용하는 최대 시도 횟수에 도달할 때까지 계속 릴리스됩니다. 최대 시도 횟수는 queue:work Artisan 명령어에서 --tries 스위치를 사용하여 정의됩니다. 또는 최대 시도 횟수는 작업 클래스 자체에 정의될 수도 있습니다. 큐 워커를 실행하는 방법에 대한 자세한 정보는 아래에서 확인할 수 있습니다.
- 작업을 수동으로 릴리스하기
가끔은 작업을 나중에 다시 시도할 수 있도록 수동으로 큐에 다시 릴리스하고 싶을 때가 있습니다. 이는 release 메소드를 호출하여 수행할 수 있습니다:
/**
* 작업을 실행합니다.
*/
public function handle(): void
{
// ...
$this->release();
}
기본적으로 release 메소드는 작업을 즉시 처리할 수 있도록 큐에 다시 릴리스합니다. 그러나 정수나 날짜 인스턴스를 release 메소드에 전달하여 일정 시간이 경과한 후에 작업이 처리 가능하도록 지시할 수 있습니다:
$this->release(10);
$this->release(now()->addSeconds(10));
- 작업을 수동으로 실패 처리하기
때로는 작업을 수동으로 "실패"로 마킹해야 할 때가 있습니다. 이를 위해 fail 메소드를 호출할 수 있습니다:
/**
* 작업을 실행합니다.
*/
public function handle(): void
{
// ...
$this->fail();
}
예외를 캐치하여 작업을 실패로 마킹하려면 예외를 fail 메소드에 전달할 수 있습니다. 또는 편의를 위해 문자열 오류 메시지를 전달하면 해당 메시지가 예외로 변환됩니다:
$this->fail($exception);
$this->fail('Something went wrong.');
Note
실패한 작업에 대한 자세한 정보는, 작업 실패 처리하기에 대한 문서를 참조하십시오.
6 작업 배치[ | ]
Laravel의 작업 배치 기능을 사용하면 일련의 작업을 쉽게 실행하고 작업 배치가 완료되었을 때 어떤 작업을 수행할 수 있습니다. 시작하기 전에, 작업 배치의 완료 비율과 같은 메타 정보를 포함하는 테이블을 만들기 위해 데이터베이스 마이그레이션을 생성해야 합니다. 이 마이그레이션은 make:queue-batches-table Artisan 명령어를 사용하여 생성할 수 있습니다:
php artisan make:queue-batches-table
php artisan migrate
6.1 배치가능 작업 정의하기[ | ]
배처가능 작업을 정의하려면 일반적인 큐가능 작업을 생성해야 하지만, 작업 클래스에 Illuminate\Bus\Batchable 트레이트를 추가해야 합니다. 이 트레이트는 작업이 실행 중인 현재 배치를 조회하는 데 사용할 수 있는 batch 메소드에 대한 접근을 제공합니다:
<?php
namespace App\Jobs;
use Illuminate\Bus\Batchable;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
class ImportCsv implements ShouldQueue
{
use Batchable, Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
/**
* 작업을 실행합니다.
*/
public function handle(): void
{
if ($this->batch()->cancelled()) {
// 배치가 취소되었는지 확인...
return;
}
// CSV 파일의 일부를 가져옵니다...
}
}
6.2 배치 디스패치하기[ | ]
작업 배치를 디스패치하려면 Bus 파사드의 batch 메소드를 사용해야 합니다. 배치처리는 완료 콜백과 결합할 때 주로 유용하므로 then, catch, finally 메소드를 사용하여 배치에 대한 완료 콜백을 정의할 수 있습니다. 이러한 콜백 각각은 호출될 때 Illuminate\Bus\Batch 인스턴스를 받습니다. 이 예제에서는 각 작업이 CSV 파일에서 주어진 수의 행을 처리하는 작업 배치를 큐에 넣는다고 가정합니다.
use App\Jobs\ImportCsv;
use Illuminate\Bus\Batch;
use Illuminate\Support\Facades\Bus;
use Throwable;
$batch = Bus::batch([
new ImportCsv(1, 100),
new ImportCsv(101, 200),
new ImportCsv(201, 300),
new ImportCsv(301, 400),
new ImportCsv(401, 500),
])->before(function (Batch $batch) {
// 배치가 생성되었지만 아직 작업이 추가되지 않았습니다...
})->progress(function (Batch $batch) {
// 하나의 작업이 성공적으로 완료되었습니다...
})->then(function (Batch $batch) {
// 모든 작업이 성공적으로 완료되었습니다...
})->catch(function (Batch $batch, Throwable $e) {
// 첫 번째 배치 작업 실패가 감지되었습니다...
})->finally(function (Batch $batch) {
// 배치 실행이 완료되었습니다...
})->dispatch();
return $batch->id;
배치가 디스패치된 후에 해당 배치의 정보를 담은 Laravel 커맨드 버스를 쿼리하기 위해 $batch->id 속성을 통해 액세스할 수 있는 배치 ID를 사용할 수 있습니다.
Warning
배치 콜백은 직렬화되고 나중에 Laravel 큐에 의해 실행되므로 콜백 내에서
$this변수를 사용해서는 안 됩니다. 또한 배치 작업이 데이터베이스 트랜잭션 내에서 래핑되므로 암시적 커밋을 트리거하는 데이터베이스 문은 작업 내에서 실행해서는 안 됩니다.
- 배치 명명하기
Laravel Horizon 및 Laravel Telescope와 같은 도구는 배치에 이름을 지정하면 더 사용자 친화적인 디버그 정보를 제공할 수 있습니다. 배치에 원하는 이름을 지정하려면 배치를 정의할 때 name 메소드를 호출하면 됩니다:
$batch = Bus::batch([
// ...
])->then(function (Batch $batch) {
// 모든 작업이 성공적으로 완료되었습니다...
})->name('Import CSV')->dispatch();
- 배치 연결 및 큐
배치 작업에 사용될 연결 및 큐를 지정하려면 onConnection 및 onQueue 메소드를 사용할 수 있습니다. 모든 배치 작업은 동일한 연결 및 큐 내에서 실행되어야 합니다:
$batch = Bus::batch([
// ...
])->then(function (Batch $batch) {
// 모든 작업이 성공적으로 완료되었습니다...
})->onConnection('redis')->onQueue('imports')->dispatch();
6.3 체인과 배치[ | ]
체인 작업 세트를 배치 내에서 정의할 수 있으며, 체인 작업을 배열 내에 배치함으로써 가능합니다. 예를 들어, 두 개의 작업 체인을 병렬로 실행하고 두 작업 체인이 모두 처리된 후 콜백을 실행할 수 있습니다:
use App\Jobs\ReleasePodcast;
use App\Jobs\SendPodcastReleaseNotification;
use Illuminate\Bus\Batch;
use Illuminate\Support\Facades\Bus;
Bus::batch([
[
new ReleasePodcast(1),
new SendPodcastReleaseNotification(1),
],
[
new ReleasePodcast(2),
new SendPodcastReleaseNotification(2),
],
])->then(function (Batch $batch) {
// ...
})->dispatch();
반대로, 체인 내에서 배치 작업을 실행할 수도 있습니다. 예를 들어, 여러 팟캐스트를 릴리스하는 배치 작업을 먼저 실행한 후 릴리스 알림을 보내는 배치 작업을 실행할 수 있습니다:
use App\Jobs\FlushPodcastCache;
use App\Jobs\ReleasePodcast;
use App\Jobs\SendPodcastReleaseNotification;
use Illuminate\Support\Facades\Bus;
Bus::chain([
new FlushPodcastCache,
Bus::batch([
new ReleasePodcast(1),
new ReleasePodcast(2),
]),
Bus::batch([
new SendPodcastReleaseNotification(1),
new SendPodcastReleaseNotification(2),
]),
])->dispatch();
6.4 배치에 작업 추가[ | ]
때로는 배치 작업 내에서 추가 작업을 배치에 추가하는 것이 유용할 수 있습니다. 이 패턴은 웹 요청 중에 디스패치하는 데 너무 많은 시간이 걸릴 수 있는 수천 개의 작업을 배치해야 할 때 유용합니다. 대신, 초기 "로더" 작업 배치를 디스패치하여 배치를 더 많은 작업으로 채우고자 할 수 있습니다:
$batch = Bus::batch([
new LoadImportBatch,
new LoadImportBatch,
new LoadImportBatch,
])->then(function (Batch $batch) {
// 모든 작업이 성공적으로 완료되었습니다...
})->name('Import Contacts')->dispatch();
이 예제에서는 LoadImportBatch 작업을 사용하여 배치를 추가 작업으로 채웁니다. 이를 위해, 작업의 batch 메소드를 통해 접근할 수 있는 배치 인스턴스에서 add 메소드를 사용할 수 있습니다:
use App\Jobs\ImportContacts;
use Illuminate\Support\Collection;
/**
* 작업을 실행합니다.
*/
public function handle(): void
{
if ($this->batch()->cancelled()) {
return;
}
$this->batch()->add(Collection::times(1000, function () {
return new ImportContacts;
}));
}
Warning
같은 배치에 속하는 작업 내에서만 배치에 작업을 추가할 수 있습니다.
6.5 배치 조사[ | ]
Illuminate\Bus\Batch 인스턴스는 배치 완료 콜백에 제공되며, 주어진 일련의 작업을 검사하고 상호작용하는 데 도움이 되는 다양한 속성과 메소드를 가지고 있습니다:
// 배치의 UUID...
$batch->id;
// 배치의 이름(해당되는 경우)...
$batch->name;
// 배치에 할당된 작업 수...
$batch->totalJobs;
// 큐에서 처리되지 않은 작업 수...
$batch->pendingJobs;
// 실패한 작업 수...
$batch->failedJobs;
// 현재까지 처리된 작업 수...
$batch->processedJobs();
// 배치의 완료 비율(0-100)...
$batch->progress();
// 배치 실행이 완료되었는지 여부...
$batch->finished();
// 배치 실행 취소...
$batch->cancel();
// 배치가 취소되었는지 여부...
$batch->cancelled();
- 라우트에서 배치 반환
모든 Illuminate\Bus\Batch 인스턴스는 JSON 직렬화가 가능하므로, 애플리케이션의 라우트에서 이를 직접 반환하여 완료 진행 상황을 포함한 배치에 대한 정보를 포함하는 JSON 페이로드를 검색할 수 있습니다. 이를 통해 애플리케이션의 UI에서 배치 완료 진행 상황을 표시하는 것이 편리해집니다.
배치 ID로 배치를 검색하려면, Bus 파사드의 findBatch 메소드를 사용할 수 있습니다:
use Illuminate\Support\Facades\Bus;
use Illuminate\Support\Facades\Route;
Route::get('/batch/{batchId}', function (string $batchId) {
return Bus::findBatch($batchId);
});
위의 예제는 특정 배치 ID로 배치를 검색하여 JSON 형식으로 반환하는 라우트를 정의합니다.
6.6 배치 취소[ | ]
때로는 특정 배치의 실행을 취소해야 할 수도 있습니다. 이는 Illuminate\Bus\Batch 인스턴스의 cancel 메소드를 호출하여 수행할 수 있습니다:
/**
* 작업을 실행합니다.
*/
public function handle(): void
{
if ($this->user->exceedsImportLimit()) {
return $this->batch()->cancel();
}
if ($this->batch()->cancelled()) {
return;
}
}
이전 예제에서 알 수 있듯이, 배치된 작업은 일반적으로 실행을 계속하기 전에 해당 배치가 취소되었는지 여부를 확인해야 합니다. 그러나 편의를 위해, 대신 SkipIfBatchCancelled 미들웨어를 작업에 할당할 수 있습니다. 이 미들웨어의 이름이 나타내듯이, 이는 Laravel에게 해당 배치가 취소된 경우 작업을 처리하지 않도록 지시할 것입니다:
use Illuminate\Queue\Middleware\SkipIfBatchCancelled;
/**
* 작업이 거쳐야 할 미들웨어를 가져옵니다.
*/
public function middleware(): array
{
return [new SkipIfBatchCancelled];
}
6.7 배치 실패[ | ]
배치 작업이 실패하면, 할당된 catch 콜백(있는 경우)이 호출됩니다. 이 콜백은 배치 내에서 처음 실패한 작업에 대해서만 호출됩니다.
- 실패 허용
배치 내의 작업이 실패하면, Laravel은 자동으로 배치를 "취소됨"으로 마킹합니다. 원한다면, 작업 실패 시 배치를 자동으로 취소되지 않도록 이 동작을 비활성화할 수 있습니다. 이는 배치를 디스패치하는 동안 allowFailures 메소드를 호출하여 수행할 수 있습니다:
$batch = Bus::batch([
// ...
])->then(function (Batch $batch) {
// 모든 작업이 성공적으로 완료되었습니다...
})->allowFailures()->dispatch();
- 실패한 배치 작업 재시도
편의를 위해, Laravel은 주어진 배치의 실패한 모든 작업을 쉽게 재시도할 수 있는 queue:retry-batch Artisan 명령어를 제공합니다. queue:retry-batch명령어는 재시도할 실패한 작업의 배치 UUID를 인수로 받습니다:
php artisan queue:retry-batch 32dbc76c-4f82-4749-b610-a639fe0099b5
6.8 배치 정리[ | ]
적절히 정리를 하지 않으면 job_batches 테이블에 기록이 매우 빠르게 축적될 수 있습니다. 이를 완화하기 위해 queue:prune-batches Artisan 명령어를 매일 실행하도록 예약해야 합니다:
use Illuminate\Support\Facades\Schedule;
Schedule::command('queue:prune-batches')->daily();
기본적으로 24시간 이상 지난 모든 완료된 배치가 정리됩니다. 명령어를 호출할 때 hours 옵션을 사용하여 배치 데이터를 유지할 기간을 지정할 수 있습니다. 예를 들어, 다음 명령어는 완료된 지 48시간이 지난 모든 배치를 삭제합니다:
use Illuminate\Support\Facades\Schedule;
Schedule::command('queue:prune-batches --hours=48')->daily();
때로는 job_batches 테이블에는 작업이 실패하고 다시 시도되지 않아 성공적으로 완료되지 않은 배치의 기록이 축적될 수 있습니다. queue:prune-batches 명령어에 unfinished 옵션을 사용하여 이러한 미완성 배치 기록을 정리하도록 지시할 수 있습니다:
use Illuminate\Support\Facades\Schedule;
Schedule::command('queue:prune-batches --hours=48 --unfinished=72')->daily();
마찬가지로 job_batches 테이블에는 취소된 배치의 기록이 축적될 수도 있습니다. queue:prune-batches 명령어에 cancelled 옵션을 사용하여 이러한 취소된 배치 기록을 정리하도록 지시할 수 있습니다:
use Illuminate\Support\Facades\Schedule;
Schedule::command('queue:prune-batches --hours=48 --cancelled=72')->daily();
6.9 배치를 DynamoDB에 저장하기[ | ]
Laravel은 관계형 데이터베이스 대신 DynamoDB에 배치 메타 정보를 저장하는 기능도 제공합니다. 그러나 모든 배치 레코드를 저장할 DynamoDB 테이블을 수동으로 생성해야 합니다.
일반적으로 이 테이블의 이름은 job_batches이어야 하지만, 애플리케이션의 queue 설정 파일 내의 queue.batching.table 설정 값에 따라 테이블 이름을 지정해야 합니다.
- DynamoDB 배치 테이블 설정
job_batches 테이블에는 문자열 기본 파티션 키 application과 문자열 기본 정렬 키 id가 있어야 합니다. 키의 application 부분에는 애플리케이션의 설정 파일에서 정의된 name 설정 값으로 설정된 애플리케이션 이름이 포함됩니다. 애플리케이션 이름이 DynamoDB 테이블의 키의 일부이므로 여러 Laravel 애플리케이션의 작업 배치를 동일한 테이블에 저장할 수 있습니다.
또한, 자동 배치 정리를 활용하려면 테이블에 ttl 속성을 정의할 수 있습니다.
- DynamoDB 설정
다음으로, Laravel 애플리케이션이 Amazon DynamoDB와 통신할 수 있도록 AWS SDK를 설치합니다:
composer require aws/aws-sdk-php
그런 다음, queue.batching.driver 설정 옵션의 값을 dynamodb로 설정합니다. 또한, batching 설정 배열 내에 key, secret, region 설정 옵션을 정의해야 합니다. 이러한 옵션은 AWS 인증에 사용됩니다. dynamodb 드라이버를 사용할 때는 queue.batching.database 설정 옵션이 필요하지 않습니다:
'batching' => [
'driver' => env('QUEUE_FAILED_DRIVER', 'dynamodb'),
'key' => env('AWS_ACCESS_KEY_ID'),
'secret' => env('AWS_SECRET_ACCESS_KEY'),
'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
'table' => 'job_batches',
],
- DynamoDB에서 배치 정리
DynamoDB를 사용하여 작업 배치 정보를 저장할 때, 관계형 데이터베이스에 저장된 배치를 정리하는 일반적인 명령은 작동하지 않습니다. 대신, DynamoDB의 네이티브 TTL 기능을 활용하여 오래된 배치의 레코드를 자동으로 제거할 수 있습니다.
DynamoDB 테이블을 ttl 속성으로 정의했다면, Laravel이 배치 레코드를 정리하는 방법을 지시하는 설정 파라미터를 정의할 수 있습니다. queue.batching.ttl_attribute 설정 값은 TTL을 보유하는 속성의 이름을 정의하고, queue.batching.ttl 설정 값은 레코드가 마지막으로 업데이트된 후 삭제될 수 있는 시간을 초 단위로 정의합니다:
'batching' => [
'driver' => env('QUEUE_FAILED_DRIVER', 'dynamodb'),
'key' => env('AWS_ACCESS_KEY_ID'),
'secret' => env('AWS_SECRET_ACCESS_KEY'),
'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
'table' => 'job_batches',
'ttl_attribute' => 'ttl',
'ttl' => 60 * 60 * 24 * 7, // 7일...
],
7 큐잉 클로저[ | ]
작업 클래스를 큐에 디스패치하는 대신, 클로저를 디스패치할 수도 있습니다. 이는 현재 요청 사이클 외부에서 실행되어야 하는 간단하고 빠른 작업에 매우 유용합니다. 클로저를 큐에 디스패치할 때, 클로저의 코드 내용은 전송 중 수정되지 않도록 암호학적으로 서명됩니다:
$podcast = App\Podcast::find(1);
dispatch(function () use ($podcast) {
$podcast->publish();
});
큐잉된 클로저가 큐에 설정된 모든 재시도 후에도 성공적으로 완료되지 않았을 경우 실행되어야 하는 클로저를 제공하려면 catch 메소드를 사용할 수 있습니다:
use Throwable;
dispatch(function () use ($podcast) {
$podcast->publish();
})->catch(function (Throwable $e) {
// 이 작업이 실패했습니다...
});
Warning
catch콜백은 직렬화되어 나중에 Laravel 큐에 의해 실행되므로,catch콜백 내에서$this변수를 사용해서는 안 됩니다.
8 큐 워커 구동[ | ]
8.1 queue:work 명령어[ | ]
Laravel에는 큐에 작업이 추가되면 새로운 작업을 처리하는 큐 워커를 시작하는 Artisan 명령어가 포함되어 있습니다. 큐 워커를 실행하려면 queue:work Artisan 명령어를 사용하십시오. queue:work 명령어가 시작되면 수동으로 중지하거나 터미널을 닫을 때까지 계속 실행됩니다:
php artisan queue:work
Note
queue:work프로세스를 백그라운드에서 영구적으로 실행하려면 Supervisor와 같은 프로세스 모니터를 사용하여 큐 워커가 중지되지 않도록 해야 합니다.
처리된 작업 ID가 명령어 출력에 포함되도록 하려면 queue:work 명령어를 호출할 때 -v 플래그를 포함할 수 있습니다:
php artisan queue:work -v
큐 워커는 장기 실행 프로세스로, 부팅된 애플리케이션 상태를 메모리에 저장합니다. 따라서 시작된 후에는 코드베이스의 변경사항을 인식하지 못합니다. 배포 과정 중에는 큐 워커를 재시작해야 합니다. 또한, 애플리케이션에 의해 생성되거나 수정된 모든 정적 상태는 작업 간에 자동으로 재설정되지 않음을 기억하십시오.
또한, queue:listen 명령어를 실행할 수도 있습니다. queue:listen 명령어를 사용할 때는 업데이트된 코드를 다시 로드하거나 애플리케이션 상태를 재설정하기 위해 워커를 수동으로 재시작할 필요가 없지만, 이 명령어는 queue:work 명령어보다 훨씬 비효율적입니다:
php artisan queue:listen
- 여러 큐 워커 실행
큐에 여러 워커를 할당하여 작업을 동시에 처리하려면 단순히 여러 queue:work 프로세스를 시작하면 됩니다. 이는 로컬에서 터미널의 여러 탭을 통해 또는 프로덕션에서 프로세스 매니저의 설정 세팅을 사용하여 수행할 수 있습니다. Supervisor를 사용할 때는 numprocs 설정 값을 사용할 수 있습니다.
- 연결과 큐 지정
워커가 사용할 큐 연결을 지정할 수도 있습니다. work 명령어에 전달된 연결 이름은 config/queue.php 설정 파일에 정의된 연결 중 하나에 해당해야 합니다:
php artisan queue:work redis
기본적으로, queue:work 명령어는 주어진 연결에서 기본 큐의 작업만 처리합니다. 그러나 주어진 연결에서 특정 큐만 처리하도록 큐 워커를 커스터마이즈할 수 있습니다. 예를 들어, 모든 이메일이 redis 큐 연결의 emails 큐에서 처리되는 경우, 해당 큐만 처리하는 워커를 시작하려면 다음 명령어를 실행하십시오:
php artisan queue:work redis --queue=emails
- 지정된 작업 수 처리
--once 옵션을 사용하여 워커가 큐에서 단일 작업만 처리하도록 지시할 수 있습니다:
php artisan queue:work --once
--max-jobs 옵션은 워커에게 주어진 수의 작업을 처리한 후 종료하도록 지시할 수 있습니다. 이 옵션은 Supervisor와 결합하여 작업자가 주어진 수의 작업을 처리한 후 자동으로 재시작되도록 하여 메모리 누수를 방지하는 데 유용합니다:
php artisan queue:work --max-jobs=1000
- 모든 큐 작업을 처리한 후 종료
--stop-when-empty 옵션은 워커에게 모든 작업을 처리한 후 정상적으로 종료하도록 지시할 수 있습니다. 이 옵션은 Docker 컨테이너 내에서 Laravel 큐를 처리할 때 큐가 비워지면 컨테이너를 종료하고자 할 때 유용합니다:
php artisan queue:work --stop-when-empty
- 지정된 시간 동안 작업 처리
--max-time 옵션은 워커에게 주어진 시간(초) 동안 작업을 처리한 후 종료하도록 지시할 수 있습니다. 이 옵션은 Supervisor와 결합하여 워커가 일정 시간 동안 작업을 처리한 후 자동으로 재시작되도록 하여 메모리 누수를 방지하는 데 유용합니다:
# 한 시간 동안 작업을 처리한 후 종료...
php artisan queue:work --max-time=3600
- 워커 슬립 기간
작업 큐에 사용가능한 작업이 있을 때 워커는 작업 사이에 지연 없이 계속 작업을 처리합니다. 그러나 sleep 옵션은 사용가능한 작업이 없을 때 워커가 "잠자기"할 시간을 초 단위로 결정합니다. 물론 잠자는 동안 워커는 새로운 작업을 처리하지 않습니다:
php artisan queue:work --sleep=3
- 유지관리 모드와 큐
애플리케이션이 유지관리 모드일 때는 큐 작업이 처리되지 않습니다. 애플리케이션이 유지관리 모드에서 벗어나면 작업이 정상적으로 처리됩니다.
유지관리 모드가 활성화되어 있어도 작업자가 작업을 처리하도록 강제하려면 --force 옵션을 사용할 수 있습니다:
php artisan queue:work --force
- 리소스 고려사항
데몬 큐 워커는 각 작업을 처리하기 전에 프레임워크를 "재부팅"하지 않습니다. 따라서 각 작업이 완료된 후에는 무거운 리소스를 해제해야 합니다. 예를 들어, GD 라이브러리를 사용하여 이미지 조작을 수행하는 경우, 이미지를 처리한 후 imagedestroy를 사용하여 메모리를 해제해야 합니다.
8.2 큐 우선수위[ | ]
때로는 큐를 처리하는 방법에 우선순위를 두고자 할 수 있습니다. 예를 들어, config/queue.php 설정 파일에서 redis 연결의 기본 큐를 low로 설정할 수 있습니다. 하지만 가끔씩 높은 우선순위 큐에 작업을 추가하고 싶을 때는 다음과 같이 할 수 있습니다:
dispatch((new Job)->onQueue('high'));
high 큐 작업이 모두 처리된 후 low 큐 작업을 계속 처리하도록 하는 워커를 시작하려면, work 명령어에 쉼표로 구분된 큐 이름 목록을 전달합니다:
php artisan queue:work --queue=high,low
8.3 큐 워커와 배포[ | ]
큐 워커는 오래 실행되는 프로세스이므로, 재시작하지 않으면 코드 변경사항을 인지하지 못합니다. 따라서 큐 워커를 사용하는 애플리케이션을 배포하는 가장 간단한 방법은 배포 과정에서 워커를 재시작하는 것입니다. queue:restart 명령어를 실행하여 모든 워커를 우아하게 재시작할 수 있습니다:
php artisan queue:restart
이 명령어는 현재 작업을 처리하는 중인 모든 큐 워커에게 작업을 잃지 않도록 처리 후 우아하게 종료하도록 지시합니다. queue:restart 명령어가 실행되면 큐 워커는 종료되므로, Supervisor와 같은 프로세스 매니저를 실행하여 큐 워커를 자동으로 재시작해야 합니다.
Note
큐는 재시작 신호를 저장하기 위해 캐시를 사용하므로, 이 기능을 사용하기 전에 애플리케이션에 적절한 캐시 드라이버가 구성되어 있는지 확인해야 합니다.
8.4 작업 만료와 타임아웃[ | ]
- 작업 만료
config/queue.php 설정 파일에서 각 큐 연결은 retry_after 옵션을 정의합니다. 이 옵션은 큐 연결이 처리 중인 작업을 다시 시도하기 전에 기다려야 하는 시간을 초 단위로 지정합니다. 예를 들어, retry_after 값이 90으로 세팅되어 있으면 작업이 90초 동안 처리 중이지만 완료되거나 삭제되지 않은 경우 작업이 큐로 다시 반환됩니다. 일반적으로 retry_after 값은 작업이 완료되는 데 합리적으로 걸리는 최대 시간을 초 단위로 설정해야 합니다.
Warning
Amazon SQS는
retry_after값을 포함하지 않는 유일한 큐 연결입니다. SQS는 AWS 콘솔에서 관리되는 기본 가시성 타임아웃(Default Visibility Timeout)을 기반으로 작업을 재시도합니다.
- 워커 타임아웃
queue:work Artisan 명령어는 --timeout 옵션을 제공합니다. 기본적으로 --timeout 값은 60초입니다. 작업이 그 값으로 지정된 초보다 오래 처리 중인 경우, 작업을 처리 중인 워커는 오류와 함께 종료됩니다. 일반적으로 워커는 서버에 설정된 프로세스 매니저에 의해 자동으로 다시 시작됩니다:
php artisan queue:work --timeout=60
retry_after 설정 옵션과 --timeout CLI 옵션은 다르지만, 작업이 손실되지 않고 한 번만 성공적으로 처리되도록 함께 작동합니다.
Warning
--timeout값은 항상retry_after설정 값보다 몇 초 짧아야 합니다. 이렇게 하면 동결된 작업을 처리하는 워커가 작업이 다시 시도되기 전에 항상 종료됩니다.--timeout옵션이retry_after설정 값보다 길면 작업이 두 번 처리될 수 있습니다.
9 Supervisor 설정[ | ]
프로덕션 환경에서 queue:work 프로세스를 지속적으로 실행하기 위해 프로세스 모니터링이 필요합니다. queue:work 프로세스는 워커 타임아웃 초과, queue:restart 명령어 실행 등의 다양한 이유로 중지될 수 있습니다. 이를 위해 프로세스 모니터를 설정하여 queue:work 프로세스가 종료될 때 이를 감지하고 자동으로 재시작할 수 있도록 해야 합니다. 또한, 프로세스 모니터를 사용하면 동시에 실행할 queue:work 프로세스의 수를 지정할 수 있습니다. Linux 환경에서 일반적으로 사용하는 프로세스 모니터인 Supervisor의 설정 방법을 아래 문서에서 설명하겠습니다.
- Supervisor 설치
Supervisor는 Linux 운영체제를 위한 프로세스 모니터로, 실패 시 queue:work 프로세스를 자동으로 재시작합니다. Ubuntu에 Supervisor를 설치하려면 다음 명령어를 사용할 수 있습니다:
sudo apt-get install supervisor
Note
Supervisor의 설정 및 관리를 직접하는 것이 부담스러울 경우, Laravel Forge를 사용하여 프로덕션 Laravel 프로젝트에 Supervisor를 자동으로 설치하고 설정할 수 있습니다.
- Supervisor 설정
Supervisor 설정 파일은 일반적으로 /etc/supervisor/conf.d 디렉토리에 저장됩니다. 이 디렉토리 내에서 프로세스 모니터링 방법을 지시하는 여러 개의 설정 파일을 생성할 수 있습니다. 예를 들어, queue:work 프로세스를 시작하고 모니터링하는 laravel-worker.conf 파일을 생성해 보겠습니다:
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /home/forge/app.com/artisan queue:work sqs --sleep=3 --tries=3 --max-time=3600
autostart=true
autorestart=true
stopasgroup=true
killasgroup=true
user=forge
numprocs=8
redirect_stderr=true
stdout_logfile=/home/forge/app.com/worker.log
stopwaitsecs=3600
이 예제에서 numprocs 지시어는 Supervisor에게 8개의 queue:work 프로세스를 실행하고 모두 모니터링하도록 지시하며, 실패 시 자동으로 재시작합니다. 설정의 command 지시어는 원하는 큐 연결 및 워커 옵션에 맞게 변경해야 합니다.
Warning
stopwaitsecs값은 가장 오래 실행되는 작업의 시간보다 크게 설정해야 합니다. 그렇지 않으면 Supervisor가 작업이 완료되기 전에 작업을 종료시킬 수 있습니다.
- Supervisor 시작
설정 파일을 생성한 후, Supervisor 설정을 업데이트하고 프로세스를 시작하려면 다음 명령어를 사용합니다:
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start "laravel-worker:*"
Supervisor에 대한 자세한 내용은 Supervisor 문서를 참조하세요.
10 실패한 작업 처리하기[ | ]
때로 큐에 있는 작업이 실패할 수 있습니다. 걱정하지 마세요, 계획대로 되지 않는 경우도 있으니까요! Laravel은 작업이 시도되어야 하는 최대 횟수를 지정하는 편리한 방법을 제공합니다. 비동기 작업이 이 시도 횟수를 초과하면 해당 작업은 failed_jobs 데이터베이스 테이블에 삽입됩니다. 동기적으로 실행되는 작업이 실패하면 이 테이블에 저장되지 않으며 예외가 즉시 애플리케이션에 의해 처리됩니다.
새로운 Laravel 애플리케이션에는 보통 failed_jobs 테이블을 생성하는 마이그레이션이 이미 포함되어 있습니다. 그러나 애플리케이션에 이 테이블을 위한 마이그레이션이 포함되어 있지 않은 경우, make:queue-failed-table 명령어를 사용하여 마이그레이션을 생성할 수 있습니다:
php artisan make:queue-failed-table
php artisan migrate
큐 워커 프로세스를 실행할 때, --tries 스위치를 사용하여 작업이 시도되어야 하는 최대 횟수를 지정할 수 있습니다. --tries 옵션에 값을 지정하지 않으면 작업은 한 번만 시도되거나 작업 클래스의 $tries 속성에 지정된 만큼 시도됩니다:
php artisan queue:work redis --tries=3
--backoff 옵션을 사용하면 예외가 발생한 작업을 다시 시도하기 전에 Laravel이 몇 초 동안 대기해야 하는지 지정할 수 있습니다. 기본적으로 작업은 다시 시도하기 위해 즉시 큐에 다시 넣어집니다:
php artisan queue:work redis --tries=3 --backoff=3
예외가 발생한 작업을 다시 시도하기 전에 Laravel이 몇 초 동안 대기해야 하는지를 작업별로 설정하려면, 작업 클래스에 backoff 속성을 정의하면 됩니다:
/**
* 작업을 다시 시도하기 전에 대기할 초 수.
*
* @var int
*/
public $backoff = 3;
작업의 backoff 시간을 결정하는 데 더 복잡한 로직이 필요한 경우, 작업 클래스에 backoff 메소드를 정의할 수 있습니다:
/**
* 작업을 다시 시도하기 전에 대기할 초 수를 계산합니다.
*/
public function backoff(): int
{
return 3;
}
backoff 메소드에서 배열 형태의 backoff 값을 반환하여 "지수형(exponential)" 백오프를 쉽게 설정할 수 있습니다. 이 예제에서는 첫 번째 재시도에 1초, 두 번째 재시도에 5초, 세 번째 재시도에 10초, 이후 남은 시도 횟수에 대해 각 재시도마다 10초의 대기시간이 적용됩니다:
/**
* 작업을 다시 시도하기 전에 대기할 초 수를 계산합니다.
*
* @return array<int, int>
*/
public function backoff(): array
{
return [1, 5, 10];
}
10.1 실패한 작업 정리[ | ]
특정 작업이 실패할 경우, 사용자에게 경보를 보내거나 작업이 부분적으로 완료된 경우 이를 되돌리고 싶을 수 있습니다. 이를 위해 작업 클래스에 failed 메소드를 정의할 수 있습니다. 작업이 실패하게 된 원인이 된 Throwable 인스턴스가 failed 메소드에 전달됩니다:
<?php
namespace App\Jobs;
use App\Models\Podcast;
use App\Services\AudioProcessor;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Throwable;
class ProcessPodcast implements ShouldQueue
{
use InteractsWithQueue, Queueable, SerializesModels;
/**
* 새로운 작업 인스턴스를 생성합니다.
*/
public function __construct(
public Podcast $podcast,
) {}
/**
* 작업을 실행합니다.
*/
public function handle(AudioProcessor $processor): void
{
// 업로드된 팟캐스트를 처리합니다...
}
/**
* 작업 실패를 처리합니다.
*/
public function failed(?Throwable $exception): void
{
// 사용자에게 실패 알림을 보냅니다, 등등...
}
}
Warning
failed메소드를 호출하기 전에 작업의 새 인스턴스가 생성되기 때문에handle메소드 내에서 발생한 클래스 속성 변경사항은 모두 사라지게 됩니다.
10.2 실패한 작업 재시도[ | ]
10.3 누락된 모델 무시하기[ | ]
Eloquent 모델을 작업에 주입할 때, 모델은 큐에 배치되기 전에 자동으로 직렬화되고, 작업이 처리될 때 데이터베이스에서 다시 조회됩니다. 그러나 작업이 처리되기 전에 모델이 삭제되었다면, 작업이 ModelNotFoundException으로 실패할 수 있습니다.
편의를 위해, 작업에서 deleteWhenMissingModels 속성을 true로 설정하여 모델이 없는 작업을 자동으로 삭제하도록 선택할 수 있습니다. 이 속성을 true로 설정하면, Laravel은 예외를 발생시키지 않고 조용히 작업을 폐기합니다:
/**
* 모델이 더 이상 존재하지 않으면 작업을 삭제합니다.
*
* @var bool
*/
public $deleteWhenMissingModels = true;
10.4 실패한 작업 정리[ | ]
애플리케이션의 failed_jobs 테이블에 있는 기록을 삭제하려면, queue:prune-failed Artisan 명령어를 실행하면 됩니다:
php artisan queue:prune-failed
기본적으로 24시간 이상 된 모든 실패한 작업 기록이 삭제됩니다. 명령어에 --hours 옵션을 넣으면, 마지막 N 시간 내에 삽입된 실패한 작업 기록만 유지됩니다. 예를 들어, 다음 명령어는 48시간 이상 된 모든 실패한 작업 기록을 삭제합니다:
php artisan queue:prune-failed --hours=48
10.5 실패한 작업을 DynamoDB에 저장하기[ | ]
Laravel은 관계형 데이터베이스 테이블 대신 DynamoDB에 실패한 작업 기록을 저장하는 기능도 제공합니다. 다만 실패한 작업 기록을 저장할 DynamoDB 테이블은 수동으로 생성해야 합니다. 일반적으로 이 테이블의 이름은 failed_jobs인데, 애플리케이션의 큐 설정 파일 내의 queue.failed.table 설정 값에 따라 테이블 이름을 지정해야 합니다.
failed_jobs 테이블은 application이라는 문자열 기본 파티션 키와 uuid라는 문자열 기본 정렬 키를 가져야 합니다. application 키에는 애플리케이션의 app 설정 파일에 정의된 name 설정 값이 포함됩니다. 애플리케이션 이름이 DynamoDB 테이블 키의 일부이기 때문에 여러 Laravel 애플리케이션의 실패한 작업을 동일한 테이블에 저장할 수 있습니다.
또한, Laravel 애플리케이션이 Amazon DynamoDB와 통신할 수 있도록 AWS SDK를 설치해야 합니다:
composer require aws/aws-sdk-php
다음으로, queue.failed.driver 설정 옵션의 값을 dynamodb로 설정합니다. 또한, 실패한 작업 설정 배열 내에서 key, secret, region 설정 옵션을 정의해야 합니다. 이 옵션들은 AWS 인증에 사용됩니다. dynamodb 드라이버를 사용할 때는 queue.failed.database 설정 옵션이 필요하지 않습니다:
'failed' => [
'driver' => env('QUEUE_FAILED_DRIVER', 'dynamodb'),
'key' => env('AWS_ACCESS_KEY_ID'),
'secret' => env('AWS_SECRET_ACCESS_KEY'),
'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
'table' => 'failed_jobs',
],
10.6 실패한 작업 저장 비활성화하기[ | ]
Laravel에서 실패한 작업을 저장하지 않고 삭제하도록 설정하려면 queue.failed.driver 설정 옵션의 값을 null로 설정하면 됩니다. 일반적으로 이는 QUEUE_FAILED_DRIVER 환경변수를 통해 수행할 수 있습니다:
QUEUE_FAILED_DRIVER=null
10.7 실패한 작업 이벤트[ | ]
이벤트 리스너를 등록하여 작업이 실패할 때 호출되도록 하려면, Queue 파사드의 failing 메소드를 사용할 수 있습니다. 예를 들어, Laravel에 포함된 AppServiceProvider의 boot 메소드에서 이 이벤트에 클로저를 붙일 수 있습니다:
<?php
namespace App\Providers;
use Illuminate\Support\Facades\Queue;
use Illuminate\Support\ServiceProvider;
use Illuminate\Queue\Events\JobFailed;
class AppServiceProvider extends ServiceProvider
{
/**
* 애플리케이션 서비스를 등록합니다.
*/
public function register(): void
{
// ...
}
/**
* 애플리케이션 서비스를 부트스트랩합니다.
*/
public function boot(): void
{
Queue::failing(function (JobFailed $event) {
// $event->connectionName
// $event->job
// $event->exception
});
}
}
이 코드는 작업이 실패할 때 특정 작업을 수행하기 위해 이벤트 리스너를 설정합니다. Queue::failing 메소드는 JobFailed 이벤트가 발생했을 때 호출될 클로저를 등록합니다. 이 클로저 내부에서 $event->connectionName, $event->job, $event->exception 등을 사용하여 작업 실패에 대한 정보를 얻을 수 있습니다.
11 큐에서 작업 클리어[ | ]
Note
Horizon을 사용할 때는
queue:clear명령어 대신horizon:clear명령어를 사용하여 큐에서 작업을 클리어해야 합니다.
기본 연결의 기본 큐에서 모든 작업을 삭제하려면 queue:clear Artisan 명령어를 사용할 수 있습니다:
php artisan queue:clear
특정 연결 및 큐에서 작업을 삭제하려면 connection 인수와 queue 옵션을 넣을 수 있습니다:
php artisan queue:clear redis --queue=emails
Warning
큐에서 작업을 클리어하는 기능은 SQS, Redis, 데이터베이스 큐 드라이버에만 사용할 수 있습니다. 또한 SQS 메시지 삭제 프로세스는 최대 60초가 걸리므로, 큐를 지운 후 60초 이내에 SQS 큐로 전송된 작업도 함께 삭제될 수 있습니다.
12 큐 모니터링[ | ]
큐가 갑작스럽게 많은 작업을 받으면 과부하가 발생하여 작업완료 대기시간이 길어질 수 있습니다. Laravel은 큐 작업 수가 지정된 임계값을 초과할 때 경고를 보낼 수 있습니다.
그러려면, queue:monitor 명령어를 매 분마다 실행하도록 스케줄링해야 합니다. 이 명령어는 모니터링하려는 큐 이름과 원하는 작업 수 임계값을 인수로 받습니다:
php artisan queue:monitor redis:default,redis:deployments --max=100
이 명령어를 스케줄링하는 것만으로는 큐 과부하 상태를 경고하는 알림이 트리거되지 않습니다. 명령어가 작업 수가 임계값을 초과한 큐를 발견하면 Illuminate\Queue\Events\QueueBusy 이벤트가 디스패치됩니다. 이 이벤트를 애플리케이션의 AppServiceProvider에서 수신하여 알림을 보내도록 설정할 수 있습니다:
use App\Notifications\QueueHasLongWaitTime;
use Illuminate\Queue\Events\QueueBusy;
use Illuminate\Support\Facades\Event;
use Illuminate\Support\Facades\Notification;
/**
* 애플리케이션 서비스를 부트스트랩합니다.
*/
public function boot(): void
{
Event::listen(function (QueueBusy $event) {
Notification::route('mail', 'dev@example.com')
->notify(new QueueHasLongWaitTime(
$event->connection,
$event->queue,
$event->size
));
});
}
위 코드를 통해 큐 작업 수가 지정된 임계값을 초과할 경우 알림이 전송됩니다.
13 테스트[ | ]
코드를 테스트할 때, 작업을 실제로 실행하지 않도록 Laravel에 지시할 수 있습니다. 이는 작업의 코드는 직접 테스트할 수 있으며, 작업을 디스패치하는 코드를 별도로 테스트할 수 있기 때문입니다. 작업 자체를 테스트하려면 작업 인스턴스를 생성하고 테스트에서 handle 메소드를 직접 호출하면 됩니다.
Queue 파사드의 fake 메소드를 사용하여 실제로 작업이 큐에 푸시되지 않도록 할 수 있습니다. Queue 파사드의 fake 메소드를 호출한 후, 애플리케이션이 큐에 작업을 푸시하려고 시도했는지 확인할 수 있습니다:
use App\Jobs\AnotherJob;
use App\Jobs\FinalJob;
use App\Jobs\ShipOrder;
use Illuminate\Support\Facades\Queue;
test('orders can be shipped', function () {
Queue::fake();
// 주문 배송 수행...
// 작업이 푸시되지 않았는지 확인...
Queue::assertNothingPushed();
// 특정 큐에 작업이 푸시되었는지 확인...
Queue::assertPushedOn('queue-name', ShipOrder::class);
// 작업이 두 번 푸시되었는지 확인...
Queue::assertPushed(ShipOrder::class, 2);
// 작업이 푸시되지 않았는지 확인...
Queue::assertNotPushed(AnotherJob::class);
// 클로저가 큐에 푸시되었는지 확인...
Queue::assertClosurePushed();
// 총 푸시된 작업 수 확인...
Queue::assertCount(3);
});
assertPushed 또는 assertNotPushed 메소드에 클로저를 전달하여 주어진 "진리 테스트"를 통과한 작업이 푸시되었는지 확인할 수 있습니다. 최소 하나의 작업이 주어진 진리 테스트를 통과했다면 그 어썰션은 성공으로 평가됩니다:
Queue::assertPushed(function (ShipOrder $job) use ($order) {
return $job->order->id === $order->id;
});
13.1 작업 일부 페이킹[ | ]
다른 작업들은 정상적으로 실행하고 특정 작업만 페이크로 만들고 싶다면, 페이크로 만들 작업의 클래스 이름을 fake 메소드에 전달할 수 있습니다:
test('orders can be shipped', function () {
Queue::fake([
ShipOrder::class,
]);
// 주문 배송 수행...
// 작업이 두 번 푸시되었는지 확인...
Queue::assertPushed(ShipOrder::class, 2);
});
지정된 작업을 제외한 모든 작업을 페이크로 만들려면 except 메소드를 사용할 수 있습니다:
Queue::fake()->except([
ShipOrder::class,
]);
13.2 작업 체인 테스트[ | ]
Bus 파사드의 assertBatched 메소드는 작업 배치(batch of jobs)가 디스패치되었는지 확인(assert)하는 데 사용할 수 있습니다. assertBatched 메소드에 제공된 클로저는 Illuminate\Bus\PendingBatch 인스턴스를 받으며, 이 인스턴스를 사용하여 배치 내의 작업(job)을 검사할 수 있습니다:
use Illuminate\Bus\PendingBatch;
use Illuminate\Support\Facades\Bus;
Bus::fake();
// ...
Bus::assertBatched(function (PendingBatch $batch) {
return $batch->name == 'import-csv' &&
$batch->jobs->count() === 10;
});
assertBatchCount 메소드를 사용하여 특정 수의 배치가 디스패치되었는지 확인(assert)할 수 있습니다:
Bus::assertBatchCount(3);
assertNothingBatched 메소드를 사용하여 아무 배치도 디스패치되지 않았는지 확인(assert)할 수 있습니다:
Bus::assertNothingBatched();
13.2.1 작업 / 배치 테스트[ | ]
또한, 개별 작업이 기본 배치와 상호작용하는 방식을 테스트해야 할 때가 있습니다. 예를 들어, 작업이 해당 배치의 추가 처리를 취소했는지 테스트해야 할 수 있습니다. 이를 수행하기 위해 withFakeBatch 메소드를 통해 작업에 페이크(fake) 배치를 할당해야 합니다. withFakeBatch 메소드는 작업 인스턴스와 페이크 배치를 포함하는 튜플을 반환합니다.
[$job, $batch] = (new ShipOrder)->withFakeBatch();
$job->handle();
$this->assertTrue($batch->cancelled());
$this->assertEmpty($batch->added);
13.3 작업 / 큐 상호작용 테스트[ | ]
때로는, 대기 중인 작업이 다시 큐에 자신을 릴리스하는지 테스트해야 할 때가 있습니다. 또는 작업이 자신을 삭제했는지 테스트해야 할 수도 있습니다. 이러한 큐 상호작용을 테스트하려면 작업을 인스턴스화하고 withFakeQueueInteractions 메소드를 호출할 수 있습니다.
작업의 큐 상호작용이 페이크로 설정되면, 작업에서 handle 메소드를 호출할 수 있습니다. 작업을 호출한 후에는 assertReleased, assertDeleted, assertFailed 메소드를 사용하여 작업의 큐 상호작용에 대한 어썰션을 할 수 있습니다.
use App\Jobs\ProcessPodcast;
$job = (new ProcessPodcast)->withFakeQueueInteractions();
$job->handle();
$job->assertReleased(delay: 30);
$job->assertDeleted();
$job->assertFailed();
14 작업 이벤트[ | ]
Queue 파사드의 before와 after 메소드를 사용하여 큐에 등록된 작업이 처리되기 전이나 후에 실행할 콜백을 지정할 수 있습니다. 이러한 콜백은 추가 로깅을 수행하거나 대시보드를 위한 통계를 증가시키는 좋은 기회입니다. 일반적으로 이러한 메소드는 서비스 제공자의 boot 메소드에서 호출해야 합니다. 예를 들어, Laravel에 포함된 AppServiceProvider를 사용할 수 있습니다:
<?php
namespace App\Providers;
use Illuminate\Support\Facades\Queue;
use Illuminate\Support\ServiceProvider;
use Illuminate\Queue\Events\JobProcessed;
use Illuminate\Queue\Events\JobProcessing;
class AppServiceProvider extends ServiceProvider
{
/**
* 애플리케이션 서비스 등록.
*/
public function register(): void
{
// ...
}
/**
* 애플리케이션 서비스 부트스트랩.
*/
public function boot(): void
{
Queue::before(function (JobProcessing $event) {
// $event->connectionName
// $event->job
// $event->job->payload()
});
Queue::after(function (JobProcessed $event) {
// $event->connectionName
// $event->job
// $event->job->payload()
});
}
}
Queue 파사드의 looping 메소드를 사용하여 워커가 큐에서 작업을 가져오려고 시도하기 전에 실행되는 콜백을 지정할 수 있습니다. 예를 들어, 이전에 실패한 작업이 남긴 트랜잭션을 롤백하기 위해 클로저를 등록할 수 있습니다:
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Queue;
Queue::looping(function () {
while (DB::transactionLevel() > 0) {
DB::rollBack();
}
});
-
{{comment.page_title}} ―{{comment.name}}