Laravel 시니어 성능 최적화 면접
새 면접Q. Laravel 애플리케이션에서 피크 시간대에 'Too many connections' 에러가 발생하고 있습니다. 데이터베이스 커넥션 풀 관리 문제로 판단됩니다. MySQL의 max_connections 설정과 Laravel의 커넥션 관리 메커니즘을 설명하고, 롱 러닝 프로세스(Queue Worker, WebSocket 서버)와 웹 요청에서 각각 커넥션 누수를 방지하는 방법을 제시해주세요. 또한 커넥션 풀 크기를 결정하는 계산 공식과 모니터링 지표를 설명해주세요.
Laravel은 요청 종료 시 자동으로 커넥션을 반환하지만, 롱 러닝 프로세스에서는 명시적 관리가 필요합니다.
MySQL의 max_connections는 동시 접속 가능한 최대 연결 수를 제한하며, Laravel은 기본적으로 요청당 하나의 커넥션을 사용하고 요청 종료 시 자동 반환합니다. 그러나 Queue Worker 같은 롱 러닝 프로세스에서는 DB::reconnect()를 주기적으로 호출하거나 작업 처리 후 DB::disconnect()로 명시적 해제가 필요합니다. 커넥션 풀 크기는 '(웹 서버 워커 수 + Queue Worker 수) × 1.2' 정도로 설정하되, 너무 크면 메모리 낭비, 작으면 대기 시간 증가가 발생합니다. 모니터링은 'SHOW PROCESSLIST'로 활성 커넥션 수를 추적하고, Laravel Telescope나 slow query log로 장시간 점유하는 쿼리를 식별해야 합니다. 트랜잭션 미종료, 커서 미해제, 예외 처리 누락이 주요 누수 원인이므로 try-finally 블록으로 반드시 정리 코드를 실행해야 하며, Read Replica 분산으로 커넥션 부하를 분산할 수 있습니다.
- • 롱 러닝 프로세스에서 DB::reconnect() 또는 DB::disconnect() 명시적 호출
- • 커넥션 풀 크기 계산: (워커 수 + Queue Worker 수) × 여유 계수
- • SHOW PROCESSLIST와 slow query log로 커넥션 점유 모니터링
- • 트랜잭션 미종료와 예외 처리 누락이 주요 누수 원인
- • Read Replica 활용으로 커넥션 부하 분산
대규모 트래픽 서비스에서 Queue Worker 증설 시 데이터베이스 커넥션 한계에 도달해 전체 시스템 장애로 이어지는 것을 방지해야 합니다.
PgBouncer나 ProxySQL 같은 외부 커넥션 풀러를 도입할 때 Laravel 설정에서 어떤 점을 조정해야 하며, 트랜잭션 모드와 세션 모드의 차이는 무엇입니까?
Q. 수십만 명의 동시 접속자가 있는 Laravel 서비스에서 세션 저장소로 파일 시스템을 사용하다가 성능 문제가 발생했습니다. Redis, Memcached, Database 기반 세션 저장소의 성능 특성을 비교하고, 각각의 장단점과 적합한 사용 시나리오를 설명해주세요. 또한 세션 데이터 크기가 클 때 발생하는 문제와 최적화 방법, 그리고 세션 가비지 컬렉션 전략이 성능에 미치는 영향을 설명해주세요.
세션 저장소 선택은 읽기/쓰기 빈도, 데이터 크기, 만료 정책, 영속성 요구사항에 따라 달라집니다.
파일 시스템 세션은 동시 접속자가 많을 때 I/O 병목과 파일 락 경합으로 성능이 급격히 저하됩니다. Redis는 인메모리 저장으로 가장 빠르며 자동 만료(TTL) 기능이 있어 세션 관리에 최적이지만, 메모리 용량 제한과 영속성 설정에 주의해야 합니다. Memcached는 Redis보다 단순하고 메모리 효율적이지만 영속성이 없고 복잡한 데이터 구조를 지원하지 않습니다. Database 세션은 영속성이 보장되고 감사 추적이 가능하지만 읽기/쓰기 부하가 크므로 인덱스 최적화(user_id, last_activity)와 파티셔닝이 필수입니다. 세션 데이터 크기는 1KB 미만으로 유지하고, 큰 데이터는 별도 저장소에 저장 후 참조 키만 세션에 저장해야 합니다. 가비지 컬렉션은 lottery 방식 대신 별도 스케줄러로 off-peak 시간에 실행하고, Redis의 경우 maxmemory-policy를 volatile-lru로 설정해 자동 정리되도록 해야 합니다.
- • Redis: 인메모리 고속 처리, TTL 자동 만료, 메모리 용량 제한 고려
- • Database: 영속성과 감사 추적 가능, 인덱스 최적화와 파티셔닝 필수
- • 세션 데이터 1KB 미만 유지, 큰 데이터는 별도 저장소 활용
- • 가비지 컬렉션을 lottery 대신 스케줄러로 off-peak 시간 실행
- • Redis maxmemory-policy를 volatile-lru로 설정
대규모 이커머스 플랫폼에서 장바구니 정보를 세션에 저장할 때 성능과 영속성을 모두 확보해야 합니다.
멀티 리전 서비스에서 세션 데이터를 지역 간 동기화해야 할 때, Redis Cluster와 Redis Sentinel 중 어떤 것을 선택하시겠으며, 세션 스티키니스와 어떻게 조합하시겠습니까?
Q. Laravel Mix 또는 Vite를 사용하는 프로젝트에서 프론트엔드 에셋(CSS, JavaScript) 로딩 성능을 최적화해야 합니다. 번들 크기 분석, 코드 스플리팅, Tree Shaking, 압축 전략을 설명하고, Laravel의 mix() 또는 vite() 헬퍼와 CDN을 조합하여 에셋 전송 성능을 개선하는 방법을 제시해주세요. 또한 Critical CSS 추출과 지연 로딩 전략, 그리고 캐시 무효화를 위한 버전 관리 방법을 설명해주세요.
번들 크기 최소화, 병렬 다운로드, 캐시 활용이 핵심이며, Laravel 버전 해싱과 CDN 통합이 중요합니다.
Vite는 ES Module 기반으로 개발 시 빠른 HMR을 제공하고, 프로덕션 빌드 시 Rollup으로 최적화하며, webpack-bundle-analyzer 같은 도구로 번들 크기를 분석해 불필요한 의존성을 제거해야 합니다. 코드 스플리팅은 dynamic import()로 라우트별 청크를 분리하고, Tree Shaking은 ES Module과 sideEffects: false 설정으로 미사용 코드를 제거합니다. Gzip/Brotli 압축은 웹 서버 레벨에서 적용하고, Laravel의 mix() 또는 vite() 헬퍼는 자동으로 버전 해시를 추가해 캐시 무효화를 처리합니다. Critical CSS는 penthouse나 critical 패키지로 추출해 인라인 삽입하고, 나머지 CSS는 preload로 병렬 다운로드하며, JavaScript는 defer 또는 async 속성으로 렌더링 블로킹을 방지합니다. CDN 통합은 ASSET_URL 환경 변수로 설정하고, CloudFront나 Cloudflare에서 Cache-Control 헤더를 immutable로 설정해 재검증 요청을 제거해야 합니다.
- • webpack-bundle-analyzer로 번들 크기 분석 및 최적화
- • dynamic import()로 라우트별 코드 스플리팅
- • mix() 또는 vite() 헬퍼의 자동 버전 해싱 활용
- • Critical CSS 인라인 삽입과 나머지 CSS preload
- • ASSET_URL과 CDN 통합, Cache-Control: immutable 설정
모바일 사용자가 많은 서비스에서 초기 페이지 로딩 시간을 3초 이내로 단축해 이탈률을 낮춰야 합니다.
SPA 애플리케이션에서 초기 로딩 시간을 줄이기 위해 Server-Side Rendering을 Laravel과 통합할 때, Inertia.js와 직접 구현 방식의 성능 차이는 무엇입니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!