사이트 단위로 php fpm pool 분리 고민 #10
Description
현재 방식
php 버전 당 기본 www pool 만 제공중.
장점
- nginx 설정에서 사이트간 php 버전 전환이 용이함.
- 구성이 단순하므로 수동 설치 용이
- 사용량이 적은 사이트가 많은 서버일 경우 메모리 절약에 유리함.
단점
- 단점: 같은 pool 을 사용하므로, php ini 설정을 사이트 단위로 구분할 수 없음.
- nginx 단에서 fastcgi 설정으로 제어하는 형태는 이미 2개 이상 사이트에서 문제가 발견되어 도입 불가한 것으로 판명됨
개선 방식
- 사이트 단위로 php fpm pool 이 생성됨.
[site1]
;listen = 127.0.0.1:9053
listen = /var/run/php-fpm/site1.sock
php_admin_value[upload_tmp_dir] = /home/site1/tmp
php_admin_value[session.save_path] = /home/site1/session
php_admin_value[open_basedir] = /home/site1
php_admin_value[error_log] = /home/site1/logs/php-fpm-error.log
장점
- 사이트 단위로 open_basedir 제어하여, 1개 사이트 해킹시에도 해당 계정 디렉토리를 벗어날 수 없음
- 에러 로그 등을
- 부하가 높은 사이트와 그렇지 않은 사이트의 php-fpm 프로세스 수를 구분하여 제어 가하고, PHP 부하가 높은 사이트를 프로세스의 pool 이름(site1 ..>)으로 쉽게 파악 가능.
단점
- 초기 셋팅시 복잡도 증가
- php 버전 전환시 pool 설정 자체를 다른 버전으로 옮겨야 하므로, 수작업이 필요할 것으로 예상.
- 현재 0.9.9 버전과 구조가 많이 달라지므로, 신규 변경과 이미 설치된 서버의 호환성 유지에 적지 않은 고민 필요.
- php-fpm pool 단위로 프로세스가 실행되어, 사이트수 증가시 메모리 자원 사용률이 높아짐. 다만 실 서버에서는 기본 메모리가 4~8GB에 달하고, 메모리 가격이 매우 저렴한 점을 고려하면, 효용성으로 커버 가능할 것으로 예상. 가상 머신 512 ram 에서 쾌적하게 돌아가야 하는 등의 제약은 실 업무와 거리가 멀기 때문에 고려하지 않도록 함.
2.0 에서 고려할 것인지 고민 필요...