Laravel 미드레벨 배포·운영 기술면접
새 면접Q. Laravel 애플리케이션을 Docker 컨테이너로 배포할 때, 멀티 스테이지 빌드(Multi-stage Build)를 사용하는 이유와 장점을 설명해주세요. 특히 composer install --no-dev --optimize-autoloader 명령어를 빌드 단계에서 실행해야 하는 이유와, 프로덕션 이미지에서 제외해야 할 파일들(tests, .env.example 등)을 관리하는 .dockerignore 전략을 함께 설명해주세요.
빌드 단계와 런타임 단계를 분리하여 최종 이미지 크기를 줄이고 보안을 강화하는 관점에서 생각해보세요.
멀티 스테이지 빌드는 빌드에 필요한 도구와 런타임에 필요한 파일을 분리하여 최종 이미지 크기를 크게 줄입니다. composer install --no-dev는 개발 의존성을 제외하고 프로덕션에 필요한 패키지만 설치하며, --optimize-autoloader는 클래스맵을 최적화하여 오토로딩 성능을 향상시킵니다. .dockerignore에는 .git, tests, storage/logs, .env 등 불필요하거나 민감한 파일을 명시하여 빌드 컨텍스트를 최소화하고 보안을 강화합니다. 빌드 단계에서는 Node.js를 포함하여 프론트엔드 자산을 컴파일하고, 최종 단계에서는 PHP-FPM과 컴파일된 파일만 복사하여 경량 이미지를 생성합니다. 이를 통해 이미지 크기를 수백 MB에서 수십 MB로 줄이고 배포 속도를 향상시킬 수 있습니다.
- • 멀티 스테이지 빌드로 빌드 도구와 런타임 분리
- • composer --no-dev --optimize-autoloader로 프로덕션 최적화
- • .dockerignore로 불필요한 파일 제외 및 보안 강화
- • 최종 이미지 크기 최소화로 배포 속도 향상
컨테이너 이미지 크기가 1GB 이상일 때 멀티 스테이지 빌드를 적용하여 200MB 이하로 줄이고 배포 시간을 단축합니다.
Docker 이미지를 빌드할 때 레이어 캐싱을 최대한 활용하기 위해 Dockerfile의 명령어 순서를 어떻게 배치해야 할까요? 특히 composer.json과 package.json 복사 시점을 고려하여 설명해주세요.
Q. Laravel 애플리케이션을 Kubernetes 환경에서 무중단 배포할 때, Rolling Update 전략을 사용하면서 발생할 수 있는 문제점들을 설명해주세요. 특히 php artisan config:cache, php artisan route:cache 같은 최적화 명령어 실행 시점, Health Check(Readiness/Liveness Probe) 설정, 그리고 새 버전과 구 버전이 동시에 실행되는 상황에서 데이터베이스 마이그레이션을 안전하게 처리하는 전략을 포함하여 설명해주세요.
새 Pod이 트래픽을 받기 전에 준비 상태를 확인하고, 마이그레이션은 배포와 분리하여 처리하는 것이 핵심입니다.
Rolling Update 시 새 Pod이 완전히 준비되기 전에 트래픽을 받으면 502 에러가 발생할 수 있으므로, Readiness Probe를 /health 엔드포인트로 설정하여 config:cache와 route:cache 실행 후에만 트래픽을 받도록 해야 합니다. Liveness Probe는 애플리케이션이 정상 작동하는지 지속적으로 확인하여 문제 발생 시 자동으로 재시작합니다. 데이터베이스 마이그레이션은 배포 전에 별도의 Job으로 실행하거나, 구 버전과 호환되는 방식으로 단계적으로 적용해야 하며, 절대 Pod 시작 시 자동 실행하면 안 됩니다. PreStop Hook을 설정하여 Pod 종료 전 일정 시간 대기(grace period)하여 진행 중인 요청이 완료되도록 하고, maxSurge와 maxUnavailable 파라미터를 조정하여 배포 속도와 안정성의 균형을 맞춥니다. php artisan optimize 명령어는 컨테이너 빌드 시점이 아닌 배포 후 초기화 스크립트에서 실행하여 환경별 설정을 반영합니다.
- • Readiness Probe로 완전한 준비 상태 확인 후 트래픽 수신
- • 마이그레이션은 배포와 분리하여 사전 실행 또는 단계적 적용
- • PreStop Hook과 grace period로 진행 중인 요청 보호
- • 최적화 명령어는 초기화 스크립트에서 환경별로 실행
Kubernetes에서 Laravel API를 배포할 때 Readiness Probe 미설정으로 인한 502 에러를 방지하고 안정적인 무중단 배포를 구현합니다.
Blue-Green 배포와 Canary 배포 전략의 차이점을 설명하고, Laravel 애플리케이션에서 Canary 배포를 적용할 때 Feature Flag와 어떻게 연계할 수 있는지 설명해주세요.
Q. 프로덕션 환경에서 Laravel 애플리케이션의 성능 저하가 발생했습니다. 이를 신속하게 파악하고 대응하기 위한 모니터링 전략을 설계해야 합니다. APM(Application Performance Monitoring) 도구 선택 기준과 Laravel에서 New Relic 또는 Datadog 같은 APM을 연동하는 방법, 그리고 Slow Query 로깅, Queue Job 실패율, HTTP 응답 시간 등 핵심 메트릭을 수집하고 알림을 설정하는 전략을 설명해주세요. 또한 분산 환경에서 로그를 중앙화하기 위한 ELK Stack 또는 CloudWatch Logs 활용 방법도 포함해주세요.
애플리케이션 레벨 메트릭과 인프라 레벨 메트릭을 모두 수집하고, 로그는 구조화하여 중앙에서 검색 가능하게 만드는 것이 핵심입니다.
APM 도구는 트랜잭션 추적, 데이터베이스 쿼리 분석, 외부 API 호출 모니터링 기능을 제공하는지 확인하여 선택하며, Laravel에서는 ServiceProvider를 통해 미들웨어로 통합합니다. DB::listen()을 사용하여 일정 시간 이상 걸리는 Slow Query를 로깅하고, Laravel Horizon이나 Queue 메트릭을 통해 Job 실패율과 처리 시간을 모니터링합니다. HTTP 응답 시간은 미들웨어에서 측정하여 95 percentile, 99 percentile 값을 추적하고, 임계값 초과 시 Slack이나 PagerDuty로 즉시 알림을 발송합니다. 분산 환경에서는 각 서버의 로그를 Fluentd나 Logstash로 수집하여 Elasticsearch에 저장하고 Kibana로 시각화하거나, AWS 환경이라면 CloudWatch Logs로 중앙화합니다. 로그는 JSON 형식으로 구조화하여 request_id, user_id, endpoint 등 메타데이터를 포함시켜 추적과 분석을 용이하게 합니다.
- • APM으로 트랜잭션 추적 및 쿼리 성능 분석
- • Slow Query, Queue 실패율, 응답 시간 등 핵심 메트릭 모니터링
- • 임계값 기반 실시간 알림 설정
- • ELK Stack 또는 CloudWatch로 로그 중앙화 및 구조화
프로덕션에서 특정 API 엔드포인트의 응답 시간이 급증할 때 APM 대시보드에서 원인 쿼리를 즉시 파악하고 최적화합니다.
Laravel 애플리케이션에서 분산 추적(Distributed Tracing)을 구현하여 마이크로서비스 간 요청 흐름을 추적하려면 어떤 도구와 방법을 사용해야 할까요? OpenTelemetry나 Zipkin 같은 도구의 역할을 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!