PHP 시니어 CS 기초 기술면접
새 면접Q. TCP의 3-way handshake와 4-way handshake 과정을 설명하고, TIME_WAIT 상태가 필요한 이유와 이 상태가 대규모 트래픽 처리 시스템에서 발생시킬 수 있는 문제점 및 해결 방법을 설명해주세요.
3-way handshake는 SYN, SYN-ACK, ACK 순서로 연결을 수립하며, 4-way handshake는 FIN, ACK, FIN, ACK 순서로 연결을 종료합니다. TIME_WAIT 상태는 지연된 패킷이 새 연결에 영향을 주지 않도록 2MSL 동안 유지되며, 이는 포트 고갈 문제를 유발할 수 있습니다. 대규모 시스템에서는 tcp_tw_reuse, tcp_tw_recycle 커널 파라미터 조정, connection pooling, 로드밸런서 활용, ephemeral port 범위 확장 등으로 해결합니다. PHP 애플리케이션에서는 persistent connection과 keep-alive를 적절히 활용하여 불필요한 연결 생성을 줄여야 합니다.
- • TIME_WAIT는 지연된 패킷 처리와 정상적인 연결 종료를 보장하기 위해 2MSL 동안 유지됨
- • 대규모 시스템에서 TIME_WAIT 상태의 소켓이 과도하게 쌓이면 포트 고갈 문제 발생
- • tcp_tw_reuse 활성화, connection pooling, ephemeral port 범위 확장으로 해결
- • 애플리케이션 레벨에서 persistent connection 활용으로 연결 재사용
PHP-FPM 환경에서 데이터베이스 connection pooling을 구현할 때 persistent connection의 장단점과 주의사항은 무엇인가요?
Q. B-Tree와 B+Tree의 구조적 차이점을 설명하고, MySQL InnoDB가 인덱스 구조로 B+Tree를 선택한 이유와 이것이 범위 검색(range query) 성능에 미치는 영향을 설명해주세요.
B-Tree는 모든 노드에 데이터를 저장하지만, B+Tree는 리프 노드에만 데이터를 저장하고 내부 노드는 키만 저장합니다. B+Tree의 리프 노드는 연결 리스트로 구성되어 순차 접근이 효율적이며, 내부 노드가 더 많은 키를 저장할 수 있어 트리 높이가 낮아집니다. 이로 인해 범위 검색 시 리프 노드만 순회하면 되고, 디스크 I/O가 줄어들어 성능이 향상됩니다. MySQL에서 WHERE 절의 범위 조건이나 ORDER BY 절 처리가 효율적으로 동작하는 이유입니다.
- • B+Tree는 리프 노드에만 데이터 저장, 내부 노드는 인덱스 역할만 수행
- • 리프 노드가 연결 리스트로 구성되어 순차 접근과 범위 검색에 유리
- • 내부 노드의 fanout이 커져 트리 높이가 낮아지고 디스크 I/O 감소
- • MySQL의 커버링 인덱스와 인덱스 스캔 최적화의 기반 구조
복합 인덱스(composite index)를 설계할 때 컬럼 순서가 중요한 이유를 B+Tree 구조와 연관지어 설명해주세요.
Q. 데드락(Deadlock)의 4가지 필요조건을 설명하고, PHP 애플리케이션에서 데이터베이스 트랜잭션 레벨에서 발생하는 데드락을 예방하거나 해결하기 위한 전략을 실무 관점에서 설명해주세요.
데드락의 4가지 필요조건은 상호배제(Mutual Exclusion), 점유와 대기(Hold and Wait), 비선점(No Preemption), 순환대기(Circular Wait)입니다. 데이터베이스 레벨에서는 일관된 락 획득 순서 유지, 트랜잭션 크기 최소화, 적절한 인덱스로 락 범위 축소, 타임아웃 설정으로 예방합니다. 발생 시에는 재시도 로직 구현, 격리 수준 조정(READ COMMITTED 사용), SELECT FOR UPDATE 사용 최소화로 대응합니다. PHP에서는 트랜잭션 시작 전 필요한 데이터를 미리 조회하고, 복잡한 비즈니스 로직은 트랜잭션 밖에서 처리하는 것이 중요합니다.
- • 4가지 필요조건: 상호배제, 점유와 대기, 비선점, 순환대기
- • 일관된 락 획득 순서, 트랜잭션 크기 최소화, 인덱스 최적화로 예방
- • 타임아웃과 재시도 로직으로 데드락 발생 시 복구
- • 트랜잭션 범위를 최소화하고 비즈니스 로직은 트랜잭션 외부에서 처리
MySQL의 InnoDB 스토리지 엔진에서 갭 락(Gap Lock)과 넥스트 키 락(Next-Key Lock)이 데드락 발생에 어떤 영향을 미치는지 설명해주세요.
Q. 해시 테이블의 충돌 해결 방법인 체이닝(Chaining)과 개방 주소법(Open Addressing)의 차이점을 설명하고, PHP의 내부 배열 구현에서 사용하는 방식과 이것이 배열 성능에 미치는 영향을 설명해주세요.
체이닝은 충돌 시 연결 리스트로 데이터를 저장하고, 개방 주소법은 다른 빈 슬롯을 찾아 저장합니다. PHP는 체이닝 방식을 사용하며, 각 버킷에 연결 리스트로 요소를 저장합니다. 로드 팩터가 일정 수준을 초과하면 자동으로 리해싱을 수행하여 성능을 유지합니다. PHP 배열은 해시 테이블과 이중 연결 리스트의 하이브리드 구조로, 순서 보장과 O(1) 접근을 동시에 제공하지만, 메모리 오버헤드가 있습니다. 대용량 데이터 처리 시 SplFixedArray나 전용 자료구조 사용을 고려해야 합니다.
- • 체이닝은 연결 리스트 사용, 개방 주소법은 빈 슬롯 탐색
- • PHP는 체이닝 방식을 사용하며 자동 리해싱으로 성능 유지
- • PHP 배열은 해시 테이블 + 이중 연결 리스트 하이브리드 구조
- • 순서 보장과 빠른 접근을 제공하지만 메모리 오버헤드 존재
PHP 배열의 메모리 사용량이 큰 이유와 대용량 데이터 처리 시 Generator나 Iterator를 사용하는 것이 유리한 상황을 설명해주세요.
Q. MVCC(Multi-Version Concurrency Control)의 동작 원리를 설명하고, MySQL InnoDB의 Undo Log와 Read View의 역할, 그리고 장시간 실행되는 트랜잭션이 시스템 성능에 미치는 영향과 해결 방법을 설명해주세요.
MVCC는 각 트랜잭션이 데이터의 특정 버전을 읽도록 하여 읽기와 쓰기 작업이 서로 블로킹하지 않도록 합니다. Undo Log는 이전 버전 데이터를 저장하고, Read View는 트랜잭션 시작 시점의 스냅샷을 결정합니다. 장시간 실행되는 트랜잭션은 Undo Log를 계속 유지시켜 디스크 공간을 소모하고, 다른 트랜잭션의 퍼지(purge) 작업을 지연시켜 성능을 저하시킵니다. 해결 방법은 트랜잭션을 작게 분할하고, 읽기 전용 작업은 READ COMMITTED 격리 수준 사용, 배치 작업은 청크 단위로 커밋하는 것입니다. PHP에서는 대용량 데이터 처리 시 Queue나 Batch 작업으로 분산 처리해야 합니다.
- • MVCC는 데이터 버전 관리로 읽기-쓰기 동시성 제공
- • Undo Log는 이전 버전 보관, Read View는 일관된 읽기 스냅샷 제공
- • 장시간 트랜잭션은 Undo Log 축적과 퍼지 지연으로 성능 저하
- • 트랜잭션 분할, 격리 수준 조정, 청크 단위 커밋으로 해결
MySQL의 REPEATABLE READ와 READ COMMITTED 격리 수준에서 팬텀 리드(Phantom Read) 발생 여부와 넥스트 키 락의 관계를 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!