Octane·FrankenPHP 런타임

테넌트와 행위자 객체는 현재 호출 안에서만 사용하고 static property나 프로세스 singleton에 보관하지 마세요. 로컬 PHP 수정이 보이지 않으면 task app:reload 후 다시 요청하세요. 아래는 worker 수명주기이며 문맥 복원은 테넌트와 컨텍스트에서 다룹니다.

PHP worker 재사용

Nexia의 Laravel 호스트는 Laravel Octane과 FrankenPHP 위에서 실행됩니다. FrankenPHP가 현재 확정된 애플리케이션 서버이고, Octane은 Laravel을 worker에 한 번 올린 뒤 request와 task를 전달하고 다음 작업을 위해 프레임워크를 정리하는 통합 계층입니다.

요청마다 PHP 애플리케이션을 처음부터 시작하는 방식과 달리, 한 worker가 여러 요청을 연속해서 처리할 수 있습니다. 미리 준비한 코드와 서비스는 재사용할 수 있지만, 요청 하나에만 속해야 하는 상태는 작업이 끝날 때 반드시 버리거나 다시 해석해야 합니다.

실행 계층의 역할

코드 변경과 worker 재시작

개발용 watch 목록에는 Core와 config, route, 로컬 App SDK, App Package 소스가 포함됩니다. 해당 파일이 바뀌면 보통 개발 worker를 다시 시작합니다. 실행 중인 web worker가 이전 코드를 계속 제공하면 task app:reload를 실행한 뒤 브라우저를 새로고침하세요. 이 명령은 Octane app 컨테이너만 재시작하고 healthy 상태까지 기다리는 확정적인 로컬 폴백입니다.

운영 배포에서도 새 코드나 cache된 설정을 적용한 뒤 worker 재시작이 필요합니다. 파일이 바뀌었다는 이유만으로 이미 떠 있는 worker가 새 릴리스를 알아차리지는 않습니다.

HTTP와 큐의 컨텍스트

Octane은 Nexia 테넌시를 정의하지 않습니다. lifecycle hook을 제공할 뿐, 요청마다 Tenant와 인증된 사용자를 확립하고 안전하게 정리하는 책임은 Core가 소유합니다.

Queue worker는 별도의 장기 실행 프로세스라는 점도 구분해야 합니다. 컨텍스트 복원과 해제라는 원칙은 같지만 octane:frankenphp가 Redis/Horizon worker까지 직접 감시하지는 않습니다. HTTP와 queue는 한 배포 모델 안에 있으면서도 서로 다른 worker lifecycle을 가집니다.

한 worker에서 두 테넌트 처리

한 worker가 두 요청을 연속 처리한다고 가정합니다. 첫 요청은 테넌트 A에서 Workshop 레코드를 열고, 바로 다음 요청은 테넌트 B에서 들어옵니다. 프레임워크는 다음 request를 준비하고, 테넌트 middleware는 B를 식별하며, Core는 B의 행위자와 권한 상태를 해석합니다. Workshop App은 현재 테넌트 연결을 통해 조회하므로 B가 볼 수 있는 레코드만 반환합니다.

반대로 App이 A의 모델을 static property에 저장했다면 Octane은 그 객체를 다음 요청까지 살려 둘 수 있습니다. 올바른 구현은 지속되어야 할 사실을 테넌트 저장소에 기록하고, 명시적 계약에는 식별자를 전달하며, request-bound 객체는 현재 테넌트와 행위자가 확립된 뒤에 해석합니다. 일정 요청 수마다 worker를 재시작하는 설정은 방어적인 운영 장치일 뿐, 컨텍스트 누수를 고치는 방법은 아닙니다.

함께 읽기

• 테넌트와 컨텍스트 — HTTP와 비동기 작업이 반드시 확립해야 하는 실행 상태입니다.
• App 라이프사이클 — 호스트 안에서 App이 발견되고 설치되는 과정을 따라갑니다.
• 이벤트와 비동기 작업 처리하기 — HTTP 요청 밖에서 컨텍스트를 복원하는 방법입니다.
• App 개발 환경 준비 — 지원 호스트와 로컬 패키지 작업 공간을 실행합니다.