PHP 시니어 기술면접
새 면접Q. MySQL에서 InnoDB의 Buffer Pool 동작 원리와 메모리 구조를 설명하고, innodb_buffer_pool_size 설정이 시스템 성능에 미치는 영향을 설명해주세요. 또한 대규모 트래픽 환경에서 Buffer Pool의 히트율(hit ratio)을 모니터링하고 최적화하는 전략과 Multiple Buffer Pool Instances를 사용하는 이유를 실무 관점에서 설명해주세요.
InnoDB Buffer Pool은 디스크 I/O를 최소화하기 위해 데이터 페이지와 인덱스를 메모리에 캐싱하는 핵심 구조입니다. LRU(Least Recently Used) 알고리즘을 변형한 방식으로 동작하며, Young과 Old 서브리스트로 나뉘어 Full Table Scan 시 유용한 데이터가 밀려나는 것을 방지합니다. innodb_buffer_pool_size는 일반적으로 전체 메모리의 70-80%로 설정하며, 너무 크면 OS 페이지 캐시와 경합하고 너무 작으면 디스크 I/O가 증가합니다. Multiple Buffer Pool Instances는 동시성을 높이기 위해 내부 뮤텍스 경합을 줄이며, 일반적으로 1GB당 1개 인스턴스를 권장합니다. 히트율은 SHOW ENGINE INNODB STATUS로 모니터링하며 99% 이상 유지가 목표입니다.
- • LRU 변형 알고리즘과 Young/Old 서브리스트 구조
- • 전체 메모리의 70-80% 할당 권장, OS와의 메모리 경합 고려
- • Multiple Instances로 뮤텍스 경합 감소 및 동시성 향상
- • 히트율 모니터링과 Adaptive Hash Index의 역할
Buffer Pool Warm-up 전략과 서버 재시작 시 캐시를 빠르게 복구하는 방법은 무엇인가요?
Q. PHP의 Copy-on-Write(COW) 메커니즘의 동작 원리를 설명하고, zval 구조체와 Reference Counting이 메모리 관리에서 어떤 역할을 하는지 설명해주세요. 또한 배열이나 객체를 함수에 전달할 때 값 복사가 발생하는 시점과 참조 전달(&)을 사용할 때의 성능 차이, 그리고 PHP 7 이후 zval 구조 변경이 성능에 미친 영향을 실무 관점에서 설명해주세요.
Copy-on-Write는 변수 할당 시 실제 데이터를 복사하지 않고 포인터만 복사하며, 수정이 발생할 때만 실제 복사를 수행하는 메모리 최적화 기법입니다. zval은 PHP 변수의 컨테이너 구조체로 타입과 값, 참조 카운트를 저장하며, 참조 카운트가 0이 되면 메모리가 해제됩니다. 함수에 배열을 전달할 때는 COW로 인해 즉시 복사되지 않지만, 함수 내부에서 수정하면 그 시점에 복사가 발생합니다. PHP 7에서는 zval 크기를 16바이트로 줄이고 힙 할당 대신 스택 할당을 사용하여 메모리 사용량을 절반으로 줄였습니다. 참조 전달(&)은 COW를 무력화시켜 오히려 성능 저하를 일으킬 수 있으므로 신중하게 사용해야 합니다.
- • COW는 수정 시점까지 실제 복사를 지연시키는 최적화 기법
- • zval의 Reference Counting으로 자동 메모리 관리
- • PHP 7의 zval 구조 개선으로 메모리 사용량 50% 감소
- • 참조 전달은 COW를 무력화시켜 오히려 성능 저하 가능
PHP 8.1에서 도입된 Fiber와 기존 Generator의 차이점, 그리고 비동기 처리에서의 활용 방안은 무엇인가요?
Q. 대규모 전자상거래 시스템에서 재고 관리를 위한 데이터베이스 설계와 동시성 제어 전략을 설명해주세요. 특히 플래시 세일처럼 순간적으로 대량의 주문이 발생하는 상황에서 재고 차감의 정확성과 성능을 모두 보장하기 위한 아키텍처 설계(Redis를 활용한 사전 검증, 메시지 큐를 통한 비동기 처리, 데이터베이스 트랜잭션 최소화)를 제시하고, 각 계층에서 발생할 수 있는 문제점과 해결 방법을 실무 관점에서 설명해주세요.
재고 관리는 3단계 검증 구조로 설계합니다. 첫째, Redis에 재고를 미리 로드하고 DECR 명령으로 원자적 차감을 수행하여 빠른 사전 검증을 합니다. 둘째, 검증 통과한 주문은 메시지 큐(RabbitMQ/Kafka)에 적재하여 트래픽 스파이크를 흡수하고 비동기 처리합니다. 셋째, 워커가 메시지를 소비하며 데이터베이스에서 SELECT FOR UPDATE로 최종 재고 차감을 수행합니다. Redis와 DB 간 불일치는 주기적인 동기화와 보상 트랜잭션으로 해결하며, Redis 장애 시에는 Circuit Breaker 패턴으로 DB로 직접 처리합니다. 재고 음수 방지를 위해 DB에 CHECK 제약조건을 추가하고, 멱등성 보장을 위해 주문 ID 기반 중복 처리 검증을 구현합니다.
- • Redis DECR로 빠른 사전 검증 및 트래픽 제어
- • 메시지 큐로 트래픽 스파이크 흡수 및 비동기 처리
- • DB SELECT FOR UPDATE로 최종 정합성 보장
- • Redis-DB 동기화, 보상 트랜잭션, 멱등성 처리
재고가 여러 창고에 분산되어 있을 때 최적의 창고를 선택하고 재고를 할당하는 알고리즘은 어떻게 설계하시겠습니까?
Q. PHP 프레임워크에서 Middleware 패턴과 Decorator 패턴의 관계를 설명하고, PSR-15(HTTP Server Request Handlers)의 RequestHandlerInterface와 MiddlewareInterface가 어떻게 표준화된 미들웨어 체인을 구현하는지 설명해주세요. 또한 미들�웨어 순서가 중요한 이유와 CORS, Authentication, Rate Limiting 미들웨어의 권장 배치 순서 및 그 이유를 실무 관점에서 설명해주세요.
Middleware 패턴은 Decorator 패턴의 체인 형태 구현으로, 요청과 응답을 감싸는 여러 레이어를 구성합니다. PSR-15는 RequestHandlerInterface의 handle() 메서드와 MiddlewareInterface의 process() 메서드를 정의하여 미들웨어가 다음 핸들러를 호출하는 표준 인터페이스를 제공합니다. 미들웨어 순서는 실행 흐름에 영향을 미치므로 중요하며, 일반적으로 CORS -> Rate Limiting -> Authentication -> Authorization 순서로 배치합니다. CORS를 최우선으로 배치하는 이유는 Preflight 요청을 빠르게 처리하기 위함이며, Rate Limiting은 인증 전에 배치하여 무차별 인증 시도를 차단합니다. Authentication 후 Authorization을 배치하여 인증된 사용자의 권한을 검증합니다.
- • Middleware는 Decorator 패턴의 체인 형태 구현
- • PSR-15로 표준화된 RequestHandler와 Middleware 인터페이스
- • CORS -> Rate Limiting -> Authentication -> Authorization 순서 권장
- • 순서 결정 시 성능, 보안, 논리적 흐름 고려
미들웨어에서 예외가 발생했을 때 이를 처리하는 전략과 Global Exception Handler와의 관계는 어떻게 설계하시겠습니까?
Q. PHP 애플리케이션에서 Session 저장소로 File, Memcached, Redis를 사용할 때 각각의 장단점과 성능 특성을 비교하고, 대규모 분산 환경에서 Session Clustering 전략을 설명해주세요. 또한 Sticky Session과 Session Replication의 차이점, JWT를 활용한 Stateless 인증으로 전환할 때의 트레이드오프, 그리고 Session Hijacking과 Fixation 공격을 방어하는 방법을 실무 관점에서 설명해주세요.
File 기반 세션은 단일 서버에서는 간단하지만 분산 환경에서는 공유 스토리지가 필요하고 I/O 병목이 발생합니다. Memcached는 빠르지만 데이터 영속성이 없어 재시작 시 세션이 손실되며, Redis는 영속성과 복제를 지원하여 프로덕션 환경에 적합합니다. Sticky Session은 로드밸런서가 사용자를 특정 서버로 고정하여 세션 공유가 불필요하지만 서버 장애 시 세션 손실이 발생합니다. Session Replication은 모든 서버에 세션을 복제하여 장애 대응력은 높지만 네트워크 오버헤드가 큽니다. JWT는 서버 상태 저장이 불필요하지만 토큰 크기가 크고 즉시 무효화가 어렵습니다. Session Hijacking 방어는 session_regenerate_id()로 ID 재생성, HTTPS 사용, HttpOnly/Secure 쿠키 플래그 설정으로 구현하며, Fixation 공격은 로그인 성공 시 세션 ID를 재생성하여 방어합니다.
- • Redis가 영속성과 복제로 분산 환경에 가장 적합
- • Sticky Session vs Session Replication의 트레이드오프
- • JWT는 Stateless하지만 즉시 무효화 불가능
- • session_regenerate_id()와 보안 쿠키 플래그로 공격 방어
마이크로서비스 환경에서 여러 서비스 간 인증 정보를 공유하기 위한 SSO(Single Sign-On) 아키텍처는 어떻게 설계하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!