Laravel Octane
번역일: 2026년 6월 27일
Laravel Octane
소개
Laravel Octane은 FrankenPHP, Open Swoole, Swoole, RoadRunner 같은 고성능 애플리케이션 서버를 활용하여 Laravel 애플리케이션의 성능을 획기적으로 향상시킵니다. Octane은 애플리케이션을 딱 한 번 부팅한 뒤 메모리에 상주시키고, 이후 들어오는 요청을 매우 빠른 속도로 처리합니다.
일반적인 PHP-FPM 방식은 요청마다 PHP 프로세스를 새로 실행하지만, Octane은 서버를 메모리에 유지하므로 부팅 비용 없이 요청을 처리할 수 있습니다.
설치
Composer로 Octane을 설치합니다:
composer require laravel/octane설치 후 octane:install Artisan 명령으로 Octane 설정 파일을 생성합니다:
php artisan octane:install서버 사전 요구사항
WARNING
Laravel Octane은 PHP 8.1 이상이 필요합니다.
FrankenPHP
FrankenPHP는 Go로 작성된 PHP 애플리케이션 서버로, Early Hints, Brotli 압축, Zstandard 압축 등 최신 웹 기능을 지원합니다. Octane 설치 시 FrankenPHP를 서버로 선택하면 FrankenPHP 바이너리를 자동으로 다운로드하여 설치합니다.
Laravel Sail에서 FrankenPHP 사용
Laravel Sail로 개발하는 경우 다음 명령으로 Octane과 FrankenPHP를 설치합니다:
./vendor/bin/sail up./vendor/bin/sail composer require laravel/octane이후 octane:install 명령으로 FrankenPHP 바이너리를 설치합니다:
./vendor/bin/sail artisan octane:install --server=frankenphp그 다음 docker-compose.yml 파일의 laravel.test 서비스 정의에 SUPERVISOR_PHP_COMMAND 환경 변수를 추가합니다. 이 변수는 Sail이 기본 PHP 개발 서버 대신 Octane으로 애플리케이션을 서빙할 때 사용할 명령을 지정합니다:
services: laravel.test: environment: SUPERVISOR_PHP_COMMAND: "/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan octane:start --server=frankenphp --host=0.0.0.0 --admin-port=2019 --port='${APP_PORT:-80}'" # XDG_CONFIG_HOME: /var/www/html/config # XDG_DATA_HOME: /var/www/html/data #HTTPS, HTTP/2, HTTP/3을 활성화하려면 다음과 같이 설정합니다:
services: laravel.test: ports: - '${APP_PORT:-80}:80' - '${VITE_PORT:-5173}:${VITE_PORT:-5173}' - '443:443' # - '443:443/udp' # environment: SUPERVISOR_PHP_COMMAND: "/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan octane:start --host=localhost --port=443 --admin-port=2019 --https" # XDG_CONFIG_HOME: /var/www/html/config # XDG_DATA_HOME: /var/www/html/data #FrankenPHP Sail 애플리케이션에는 https://localhost로 접속하는 것을 권장합니다. https://127.0.0.1은 추가 설정이 필요하며 권장되지 않습니다.
Docker로 FrankenPHP 사용
FrankenPHP 공식 Docker 이미지를 사용하면 정적 설치 방식보다 성능이 향상되고 추가 PHP 확장 모듈도 사용할 수 있습니다. 또한 Windows처럼 FrankenPHP가 기본적으로 지원하지 않는 플랫폼에서도 실행할 수 있습니다. 공식 Docker 이미지는 로컬 개발과 프로덕션 환경 모두에 적합합니다.
아래 Dockerfile을 FrankenPHP 기반 Laravel 애플리케이션의 컨테이너화 시작점으로 활용할 수 있습니다:
FROM dunglas/frankenphp
RUN install-php-extensions \
pcntl
# 필요한 PHP 확장 모듈을 여기에 추가하세요...
COPY . /app
ENTRYPOINT ["php", "artisan", "octane:frankenphp"]개발 시에는 다음 Docker Compose 파일을 사용할 수 있습니다:
# compose.yaml
services:
frankenphp:
build:
context: .
entrypoint: php artisan octane:frankenphp --workers=1 --max-requests=1
ports:
- "8000:8000"
volumes:
- .:/appphp artisan octane:start 명령에 --log-level 옵션을 명시적으로 전달하면, Octane은 FrankenPHP의 네이티브 로거를 사용하며 별도 설정이 없을 경우 구조화된 JSON 로그를 출력합니다.
Docker에서 FrankenPHP를 실행하는 더 자세한 내용은 FrankenPHP 공식 문서를 참고하세요.
RoadRunner
RoadRunner는 Go로 빌드된 RoadRunner 바이너리를 기반으로 동작합니다. RoadRunner 기반 Octane 서버를 처음 시작할 때 Octane이 RoadRunner 바이너리 다운로드 및 설치를 제안합니다.
Laravel Sail에서 RoadRunner 사용
Laravel Sail로 개발하는 경우 다음 명령으로 Octane과 RoadRunner를 설치합니다:
./vendor/bin/sail up./vendor/bin/sail composer require laravel/octane spiral/roadrunner-cli spiral/roadrunner-http이후 Sail 셸을 열고 rr 실행 파일로 최신 Linux 빌드의 RoadRunner 바이너리를 가져옵니다:
./vendor/bin/sail shell# Sail 셸 내부에서..../vendor/bin/rr get-binary그 다음 docker-compose.yml 파일의 laravel.test 서비스 정의에 SUPERVISOR_PHP_COMMAND 환경 변수를 추가합니다:
services: laravel.test: environment: SUPERVISOR_PHP_COMMAND: "/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan octane:start --server=roadrunner --host=0.0.0.0 --rpc-port=6001 --port='${APP_PORT:-80}'" #마지막으로 rr 바이너리에 실행 권한을 부여하고 Sail 이미지를 빌드합니다:
chmod +x ./rr./vendor/bin/sail build --no-cacheSwoole
Swoole 애플리케이션 서버를 사용하려면 Swoole PHP 확장 모듈이 필요합니다. 일반적으로 PECL로 설치할 수 있습니다:
pecl install swooleOpen Swoole
Open Swoole을 사용하려면 Open Swoole PHP 확장 모듈을 설치해야 합니다:
pecl install openswooleOpen Swoole을 사용해도 동시 작업, 틱, 인터벌 등 Swoole이 제공하는 동일한 기능을 모두 사용할 수 있습니다.
Laravel Sail에서 Swoole 사용
WARNING
Sail로 Octane 애플리케이션을 서빙하기 전에 최신 버전의 Laravel Sail을 사용하고 있는지 확인하고, 애플리케이션 루트 디렉터리에서 ./vendor/bin/sail build --no-cache를 실행하세요.
Laravel Sail을 사용하여 Swoole 기반 Octane 애플리케이션을 개발할 수 있습니다. Sail에는 기본적으로 Swoole 확장 모듈이 포함되어 있습니다. 다만 docker-compose.yml 파일을 수정해야 합니다.
docker-compose.yml 파일의 laravel.test 서비스 정의에 SUPERVISOR_PHP_COMMAND 환경 변수를 추가합니다:
services: laravel.test: environment: SUPERVISOR_PHP_COMMAND: "/usr/bin/php -d variables_order=EGPCS /var/www/html/artisan octane:start --server=swoole --host=0.0.0.0 --port='${APP_PORT:-80}'" #마지막으로 Sail 이미지를 빌드합니다:
./vendor/bin/sail build --no-cacheSwoole 설정
Swoole은 필요에 따라 octane 설정 파일에 추가할 수 있는 몇 가지 옵션을 지원합니다. 자주 변경할 필요가 없으므로 기본 설정 파일에는 포함되어 있지 않습니다:
'swoole' => [
'options' => [
'log_file' => storage_path('logs/swoole_http.log'),
'package_max_length' => 10 * 1024 * 1024,
],
],애플리케이션 서빙
octane:start Artisan 명령으로 Octane 서버를 시작합니다. 기본적으로 octane 설정 파일의 server 옵션에 지정된 서버를 사용합니다:
php artisan octane:start기본적으로 포트 8000에서 서버가 시작되므로 http://localhost:8000으로 애플리케이션에 접속할 수 있습니다.
HTTPS로 서빙하기
기본적으로 Octane을 통해 실행되는 애플리케이션은 http://로 시작하는 링크를 생성합니다. HTTPS로 서빙할 때는 config/octane.php에서 사용되는 OCTANE_HTTPS 환경 변수를 true로 설정하면 됩니다. 이 값이 true이면 Octane이 Laravel에게 모든 생성 링크에 https:// 접두사를 붙이도록 지시합니다:
'https' => env('OCTANE_HTTPS', false),Nginx를 통한 서빙
NOTE
서버 설정을 직접 관리하기가 어렵다면 Laravel Forge를 활용해 보세요. Forge는 견고한 Laravel Octane 애플리케이션 운영에 필요한 다양한 서비스 설정을 자동으로 처리해 줍니다.
프로덕션 환경에서는 Nginx나 Apache 같은 전통적인 웹 서버 뒤에 Octane 애플리케이션을 배치하는 것을 권장합니다. 이렇게 하면 이미지, CSS 파일 같은 정적 에셋은 웹 서버가 직접 처리하고, SSL 인증서 종료도 웹 서버에서 담당할 수 있습니다.
아래 Nginx 설정 예시는 정적 에셋을 직접 서빙하고, 그 외 요청은 포트 8000에서 실행 중인 Octane 서버로 프록시합니다:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 80;
listen [::]:80;
server_name domain.com;
server_tokens off;
root /home/forge/domain.com/public;
index index.php;
charset utf-8;
location /index.php {
try_files /not_exists @octane;
}
location / {
try_files $uri $uri/ @octane;
}
location = /favicon.ico { access_log off; log_not_found off; }
location = /robots.txt { access_log off; log_not_found off; }
access_log off;
error_log /var/log/nginx/domain.com-error.log error;
error_page 404 /index.php;
location @octane {
set $suffix "";
if ($uri = /index.php) {
set $suffix ?$query_string;
}
proxy_http_version 1.1;
proxy_set_header Host $http_host;
proxy_set_header Scheme $scheme;
proxy_set_header SERVER_PORT $server_port;
proxy_set_header REMOTE_ADDR $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_pass http://127.0.0.1:8000$suffix;
}
}파일 변경 감지
Octane 서버가 시작될 때 애플리케이션이 메모리에 한 번 로드되기 때문에, 이후 파일을 변경해도 브라우저를 새로 고침하는 것만으로는 변경사항이 반영되지 않습니다. 예를 들어 routes/web.php에 새로운 라우트를 추가해도 서버를 재시작하기 전까지는 적용되지 않습니다. 편의를 위해 --watch 플래그를 사용하면 파일이 변경될 때마다 Octane이 자동으로 서버를 재시작합니다:
php artisan octane:start --watch이 기능을 사용하기 전에 로컬 개발 환경에 Node가 설치되어 있어야 하며, 프로젝트에 Chokidar 파일 감지 라이브러리도 설치해야 합니다:
npm install --save-dev chokidar감지할 디렉터리와 파일은 config/octane.php의 watch 설정 옵션으로 지정할 수 있습니다.
워커 수 지정
기본적으로 Octane은 서버의 CPU 코어 수만큼 요청 처리 워커를 시작합니다. 이 워커들이 들어오는 HTTP 요청을 처리합니다. octane:start 명령 실행 시 --workers 옵션으로 워커 수를 직접 지정할 수 있습니다:
php artisan octane:start --workers=4Swoole 애플리케이션 서버를 사용하는 경우 "태스크 워커" 수도 지정할 수 있습니다:
php artisan octane:start --workers=4 --task-workers=6최대 요청 수 지정
메모리 누수를 방지하기 위해 Octane은 워커가 500개의 요청을 처리하면 자동으로 재시작합니다. --max-requests 옵션으로 이 값을 조정할 수 있습니다:
php artisan octane:start --max-requests=250워커 재시작
octane:reload 명령으로 Octane 서버의 애플리케이션 워커를 안전하게 재시작할 수 있습니다. 배포 후 새로 배포된 코드가 메모리에 로드되도록 이 명령을 실행하는 것이 일반적입니다:
php artisan octane:reload서버 중지
octane:stop Artisan 명령으로 Octane 서버를 중지합니다:
php artisan octane:stop서버 상태 확인
octane:status Artisan 명령으로 Octane 서버의 현재 상태를 확인할 수 있습니다:
php artisan octane:status의존성 주입과 Octane
Octane은 애플리케이션을 한 번 부팅한 뒤 메모리에 유지하며 요청을 처리하기 때문에, 애플리케이션을 개발할 때 주의해야 할 사항이 있습니다. 예를 들어 서비스 프로바이더의 register와 boot 메서드는 워커가 최초 부팅될 때 딱 한 번만 실행되고, 이후 요청에서는 동일한 애플리케이션 인스턴스가 재사용됩니다.
따라서 애플리케이션 서비스 컨테이너나 Request 인스턴스를 객체의 생성자에 주입할 때는 각별히 주의해야 합니다. 이렇게 하면 이후 요청에서 해당 객체가 오래된(stale) 컨테이너나 Request를 참조하게 될 수 있습니다.
Octane은 요청 간 프레임워크 자체의 상태는 자동으로 초기화하지만, 애플리케이션 코드에서 만든 전역 상태는 자동으로 초기화하지 않습니다. 따라서 Octane 친화적인 방식으로 애플리케이션을 구성해야 합니다. 아래에서 주로 문제가 되는 상황들을 살펴보겠습니다.
컨테이너 주입
일반적으로 애플리케이션 서비스 컨테이너나 HTTP Request 인스턴스를 다른 객체의 생성자에 주입하는 것은 피해야 합니다. 예를 들어 다음 바인딩은 싱글톤으로 등록된 객체에 전체 애플리케이션 서비스 컨테이너를 주입합니다:
use App\Service;
use Illuminate\Contracts\Foundation\Application;
/**
* 애플리케이션 서비스를 등록합니다.
*/
public function register(): void
{
$this->app->singleton(Service::class, function (Application $app) {
return new Service($app);
});
}이 예시에서 Service 인스턴스가 애플리케이션 부팅 중에 해석(resolve)되면, 그 시점의 컨테이너가 서비스에 주입됩니다. 이후 요청에서도 동일한 컨테이너가 Service 인스턴스에 유지되므로, 나중에 추가된 바인딩을 참조하지 못할 수 있습니다.
해결 방법은 싱글톤 등록을 피하거나, 항상 현재 컨테이너 인스턴스를 반환하는 클로저를 주입하는 것입니다:
use App\Service;
use Illuminate\Container\Container;
use Illuminate\Contracts\Foundation\Application;
$this->app->bind(Service::class, function (Application $app) {
return new Service($app);
});
$this->app->singleton(Service::class, function () {
return new Service(fn () => Container::getInstance());
});전역 app 헬퍼와 Container::getInstance() 메서드는 항상 최신 애플리케이션 컨테이너를 반환하므로 안전하게 사용할 수 있습니다.
Request 주입
마찬가지로, HTTP Request 인스턴스를 다른 객체의 생성자에 주입하는 것도 피해야 합니다. 아래 예시는 싱글톤으로 등록된 객체에 전체 Request 인스턴스를 주입합니다:
use App\Service;
use Illuminate\Contracts\Foundation\Application;
/**
* 애플리케이션 서비스를 등록합니다.
*/
public function register(): void
{
$this->app->singleton(Service::class, function (Application $app) {
return new Service($app['request']);
});
}이 경우 Service 인스턴스가 부팅 중에 해석되면 최초의 Request가 주입되고, 이후 모든 요청에서도 이 오래된 Request가 유지됩니다. 따라서 헤더, 입력값, 쿼리 스트링 등 모든 요청 데이터가 잘못된 값을 반환하게 됩니다.
해결 방법으로는 싱글톤 등록을 피하거나, 현재 Request를 항상 반환하는 클로저를 주입하거나, 가장 권장하는 방법으로 필요한 요청 데이터를 런타임에 메서드 인수로 직접 전달하는 것입니다:
use App\Service;
use Illuminate\Contracts\Foundation\Application;
$this->app->bind(Service::class, function (Application $app) {
return new Service($app['request']);
});
$this->app->singleton(Service::class, function (Application $app) {
return new Service(fn () => $app['request']);
});
// 또는 필요한 데이터만 메서드에 직접 전달...
$service->method($request->input('name'));전역 request 헬퍼는 항상 현재 처리 중인 Request를 반환하므로 애플리케이션 어디에서나 안전하게 사용할 수 있습니다.
WARNING
컨트롤러 메서드나 라우트 클로저에서 Illuminate\Http\Request를 타입 힌트로 선언하는 것은 안전하며 권장되는 방법입니다.
설정 저장소 주입
설정 저장소 인스턴스 역시 다른 객체의 생성자에 주입하는 것은 피하는 것이 좋습니다. 예를 들어 다음 바인딩은 싱글톤으로 등록된 객체에 설정 저장소를 주입합니다:
use App\Service;
use Illuminate\Contracts\Foundation\Application;
/**
* 애플리케이션 서비스를 등록합니다.
*/
public function register(): void
{
$this->app->singleton(Service::class, function (Application $app) {
return new Service($app->make('config'));
});
}이 경우 요청 간 설정값이 변경되더라도 서비스는 최초에 주입된 저장소 인스턴스를 계속 참조하므로 새로운 값을 반영하지 못합니다.
해결 방법으로는 싱글톤 등록을 피하거나, 항상 최신 설정 저장소를 반환하는 클로저를 주입하는 것입니다:
use App\Service;
use Illuminate\Container\Container;
use Illuminate\Contracts\Foundation\Application;
$this->app->bind(Service::class, function (Application $app) {
return new Service($app->make('config'));
});
$this->app->singleton(Service::class, function () {
return new Service(fn () => Container::getInstance()->make('config'));
});전역 config 헬퍼는 항상 최신 설정 저장소를 반환하므로 안전하게 사용할 수 있습니다.
메모리 누수 관리
Octane은 요청 간 애플리케이션을 메모리에 유지하기 때문에, 정적(static) 배열에 데이터를 계속 추가하면 메모리 누수가 발생합니다. 예를 들어 아래 컨트롤러는 매 요청마다 정적 $data 배열에 데이터를 추가하여 메모리 누수를 일으킵니다:
use App\Service;
use Illuminate\Http\Request;
use Illuminate\Support\Str;
/**
* 들어오는 요청을 처리합니다.
*/
public function index(Request $request): array
{
Service::$data[] = Str::random(10);
return [
// ...
];
}애플리케이션을 개발할 때는 이런 유형의 메모리 누수가 발생하지 않도록 각별히 주의해야 합니다. 로컬 개발 중에 애플리케이션의 메모리 사용량을 모니터링하여 새로운 메모리 누수가 생기지 않는지 확인하는 것을 권장합니다.
동시 작업
WARNING
이 기능은 Swoole이 필요합니다.
Swoole을 사용할 때 Octane의 concurrently 메서드를 통해 경량 백그라운드 태스크로 작업을 동시에 실행할 수 있습니다. PHP 배열 구조 분해와 함께 사용하면 각 작업의 결과를 편리하게 받을 수 있습니다:
use App\Models\User;
use App\Models\Server;
use Laravel\Octane\Facades\Octane;
[$users, $servers] = Octane::concurrently([
fn () => User::all(),
fn () => Server::all(),
]);Octane의 동시 작업은 Swoole의 "태스크 워커"를 활용하며, 들어오는 요청과는 완전히 별개의 프로세스에서 실행됩니다. 동시 작업을 처리할 태스크 워커 수는 octane:start 명령의 --task-workers 옵션으로 지정합니다:
php artisan octane:start --workers=4 --task-workers=6concurrently 메서드 호출 시 Swoole 태스크 시스템의 제한으로 인해 1024개 이상의 태스크를 전달하지 않도록 주의하세요.
틱과 인터벌
WARNING
이 기능은 Swoole이 필요합니다.
Swoole을 사용할 때 지정한 초마다 실행되는 "틱(tick)" 작업을 등록할 수 있습니다. tick 메서드로 틱 콜백을 등록하며, 첫 번째 인수는 틱의 이름(문자열), 두 번째 인수는 지정된 간격으로 호출될 callable입니다.
아래 예시는 10초마다 실행되는 클로저를 등록합니다. tick 메서드는 일반적으로 서비스 프로바이더의 boot 메서드 안에서 호출합니다:
Octane::tick('simple-ticker', fn () => ray('Ticking...'))
->seconds(10);immediate 메서드를 사용하면 Octane 서버가 처음 시작될 때 즉시 틱 콜백을 호출하고, 이후 N초마다 반복 실행합니다:
Octane::tick('simple-ticker', fn () => ray('Ticking...'))
->seconds(10)
->immediate();Octane 캐시
WARNING
이 기능은 Swoole이 필요합니다.
Swoole을 사용할 때 초당 최대 200만 회의 읽기/쓰기 속도를 제공하는 Octane 캐시 드라이버를 활용할 수 있습니다. 극단적인 캐시 읽기/쓰기 성능이 필요한 애플리케이션에 탁월한 선택입니다.
이 캐시 드라이버는 Swoole 테이블을 기반으로 동작합니다. 캐시에 저장된 데이터는 서버의 모든 워커에서 접근할 수 있습니다. 단, 서버가 재시작되면 캐시 데이터는 모두 초기화됩니다:
Cache::store('octane')->put('framework', 'Laravel', 30);NOTE
Octane 캐시에 저장 가능한 최대 항목 수는 애플리케이션의 octane 설정 파일에서 정의할 수 있습니다.
캐시 인터벌
Laravel 캐시 시스템의 일반적인 메서드 외에도, Octane 캐시 드라이버는 인터벌 기반 캐시를 지원합니다. 이 캐시는 지정된 간격으로 자동으로 갱신되며, 서비스 프로바이더의 boot 메서드에서 등록해야 합니다. 아래 예시의 캐시는 5초마다 갱신됩니다:
use Illuminate\Support\Str;
Cache::store('octane')->interval('random', function () {
return Str::random(10);
}, seconds: 5);테이블
WARNING
이 기능은 Swoole이 필요합니다.
Swoole을 사용할 때 임의의 Swoole 테이블을 직접 정의하고 사용할 수 있습니다. Swoole 테이블은 극도로 높은 성능 처리량을 제공하며, 저장된 데이터는 서버의 모든 워커에서 접근할 수 있습니다. 단, 서버가 재시작되면 데이터는 모두 사라집니다.
테이블은 octane 설정 파일의 tables 배열에 정의합니다. 최대 1,000개의 행을 허용하는 예시 테이블이 기본으로 설정되어 있습니다. 문자열 컬럼의 최대 크기는 아래와 같이 컬럼 타입 뒤에 크기를 지정하여 설정할 수 있습니다:
'tables' => [
'example:1000' => [
'name' => 'string:1000',
'votes' => 'int',
],
],테이블에 접근하려면 Octane::table 메서드를 사용합니다:
use Laravel\Octane\Facades\Octane;
Octane::table('example')->set('uuid', [
'name' => 'Nuno Maduro',
'votes' => 1000,
]);
return Octane::table('example')->get('uuid');WARNING
Swoole 테이블에서 지원하는 컬럼 타입은 string, int, float입니다.