RSS구독하기:SUBSCRIBE TO RSS FEED
즐겨찾기추가:ADD FAVORITE
글쓰기:POST
관리자:ADMINISTRATOR
'php-fpm'에 해당되는 글 2
기술의 발전으로 인하여 저렴해지고 보다 성능은 뛰어나졌다.
요즘은 IaaS 같은 Cloud Service 들도 많기 때문에 비용적인 부담은 많이 줄어들었지만.

내가 가진 지갑도 홀~~~~~~~~~~쭉 하기 때문에 한정된 돈으로 싸게싸게 웹 서비스용 서버를
마련하기 위해서라면 어떻게 해야 할 까?

Cloud Service 를 쓰건 깡통을 사서 쓰건간에 큰 맥락에서 이해를 해주면 ...(땡큐 베리 감사 ..)

(여기서 Goal 은 Single box 를 굴린다는 전제하에 작성하는 것으로 한다.)


** 주의 **
본 글은 다분히 개인적 경험과 잡다구리한 지식을 기반으로 작성 되어음을 알려드립니다.
취사 선택에 주의를 요합니다.

보통 웹 서비스라고 하면 보통 다음과 같은 것들이 필요하다.



데이터 관리를 위한 DBMS
Server-Side language 를 위한 엔진(Engine)
Web Server


그리고 보통은


복잡하지 않은 DB 연산 , 다수의 Web application processors ...
매우 높은 CPU 연산 보단 매우 빈번한 I/O 를 사용하게 된다.


물론 이것은 사용하는 Web Application 에 따라서 달라질 가능성이 있지만 그것은 제껴 놓고 보자..


1. like a US beef .... (Cheap and delicious ...??)


(진짜 미국산 소고기가 그렇다는 것은 아니다...)

고성능 CPU 와 SSD 와 같은 장비를 샀으면 좋겠지만
그러하지 못하다면 어쩔수 없이 어떻게 써야 할지 고민이 될 것이다.
일단 우리가 이용하고자 하는 환경은
다수의 Application ( Web server + DB + Web Engine ...etc..) 이 동작하는 환경이 될 것이고.


각 Application 은 그다지 많은 CPU 성능을 요구하지는 않을 것이다.

이러한 환경에서는 고 클럭(Clock)  CPU 보다는
Core 수가 많은 혹은 HT 와 같이 Thread 성능을 늘릴수 있는 CPU 를 선택하는 것이 좋다.
고 클럭 Dual core CPU 보다는 조금 더 낮은 클럭의 Quad Core CPU 가
Multi Processes/Thread 에서는 좀 더 이득을 볼 수 있기 때문이다.


그리고 가급적이면 Main Memory 를 많이 꼽아라.
ECC 메모리가 아닌 이상 Memory 가격이 미친 듯 비싸지 않으니 많이 꼽아라 투자 한 만큼 돌아온다.


용량 대비 가격 면에서 SSD 는 현재 기준(2013. 10)  GB 당 1달러 (USD) 이상 된다.
일반용 SSD 임에도 불구 하고 말이다. 이는 고 용량 / Enterprise 급으로 넘어가게 되면 더 올라가게 된다.


그에 비하여 S-ATA 7200rpm HDD 의 경우 GB 당 0.05 달러 (USD) 정도 이니 약 20배 정도 차이가 난다.
HDD 도 사실 I/O 성능이 그다지 나쁘진 않는 편이다.
혹은 10K rpm 짜리 HDD 를 붙인다면 좀 더 나은 성능을 얻을 수 있겠다.

Disk I/O 가 매우 중요하다면 SSD 를 도입하되 데이터 영구 저장용으로 별도의 HDD 를 이용하는 것도 방법이다.
혹은 HDD+SDD Hybrid  방식의 디스크를 구매하는 것도 적절한 타협점이 될 수 있지 않을까?

그 외 NIC 나 Main board 와 같은 경우는 대부분 baseline 이상의 내구성을 보여주니
A/S 잘되는 녀석으로 고르면 된다.


2. 64 bit & Modern OS
64 bit 환경은 32 bit 시절 보다 향상된 연산능력과
광활한 어드레싱 (Addressing) 이 가능하게 만들기 때문에 보다 더 많은 메모리를 활용 할 수 있게 된다.


또한 몇몇 DBMS 의 경우 ( ex , MongoDB ) 에는 특정 필드의 데이터 타입의 한계가 다르기 때문에
앞으로 Web Application 개발을 감안한다면 굳이 32 bit 로 가야할 이유가 없을 것이다.


또한 epoll 이나 보다 향상된 File system ( ex, ext4 , zfs )  와 향상된 Scheduler 와 같이
내부적으로 최신 하드웨어에 맞는 최신 기술들이 적용되어있기 때문에
보다 효율적으로 하드웨어 자원을 활용 할 수 있게 된다.

그렇기 때문에 반드시! 최신 OS 는 항상 옳다고 봐야 한다.


3. Lightweight


Web 과 관련한 최신 기술들의 경향은 lightweight & Easy to use 라고 할 수 있다.
예전 LAPM 이라 불리웠던 Linux + Apache + PHP( 혹은 python , perl ) + MySQL 의 조합을 떠올리게 된다.


물론 이 모든 것들이 당시에는 가장 가볍게 저 비용으로 웹 서비스 환경을 구축하기 위한 조합이였다.


하지만 세월이 흐르면서 Lighttpd 나 Nginx 와 같이 성능은 월등히 뛰어나지만 시스템 자원을 적게 이용하는 경량 (light-weight) Web Server 들이 나왔고
FastCGI 나 PHP의 경우 PHP-FPM , WSGI 의 경우 Gunicorn 이나 uWSGI 와 같은 빠르지만 매우 가벼운 WSGI 모듈 과 같이 Web Server 에 의존적이던 형태에서 벗어나 보다 효율적으로 Web Engine (혹은 Web container )을 구동하기 위한 형태로 진화 해 왔다.

한발 더 나아가서 Node.JS 를 이용하여 아주 간단(?) 하게 Web Service 를 구축할 수 있는 방법도 생겼다.

이렇게 해서 실제 Web Application 을 효율적으로 처리하고 시스템 자원을 확보 하는 것이 필요하다.


4. Use more efficiently

2번 내용과 비슷한 맥락이 될 것이다. 최신 SW 기술은 항상 옳다.
예를 들자면 MySQL 의 경우 4.x 와 5.1 그리고 5.5+ 의 성능은 매우 차이가 크다.
MySQL 5.7 에 가서는 보다 빨라진 성능을 제공하기에 가급적 빨리 도입하는 것도 나쁘지 않은 선택이 될 수 있다.

MySQL project 에서 분리된 MariaDB 의 경우에는 MySQL 과 99% 호환이 되지만
MySQL Community Edition 에서 누락된 최신 기술들을 도입하여 보다 나은 성능을 보여준다.

물론 DBMS 특성상 최신 Engine 을 항상 도입하기에는 안전성의 문제로 인하여 쉽게 갈아타기 힘든 부분이 있기 마련이다.

하지만 적절한 시험(Testing) 을 통해서 빠른 시간내에 도입을 해보는 것도 방법이라고 할 수 있겠다.

또한 PHP 의 경우 기존의 mod_php 와 같이 Web Server 와 함께 동작하는 module 방식 보다는
독립적인 Process 형태의 FastCGI 나 PHP-FPM 과 같은 형태로 이용하게 되면
HTTP 요청(Request) 증가로 인한 Web Server 의  부하 와 상관 없이
PHP Application 의 요청에 따라 효율적으로 Process/resource 관리가 가능해질 수 있다.

특히 APC 를 이용하게 되는 경우 PHP-FPM 방식에서는 APC 데이터 영역을 공유하기 때문에
보다 효율적으로 메모리를 관리 할 수 있다.

혹은 호환성의 이슈가 있지만 Facebook 에서 이용하고 있는 HipHop VM (이하 HHVM ) 과 같은 것을 이용하게 되면
보다 빠르게 PHP Application 을 이용할 수 있게 된다.

Python 의 경우엔 mod_wsgi 보단 Gunicorn 이나 uWSGI 와 같은 고성능 Web Container 를 이용하는 편이 보다 나은 성능을 보장 할 수 있다.


I/O 성능을 극대화 하기 위해서 HDD 보단 Main Memory 를 활용하기 위해서
Redis 나 Memcached 와 같은 Engine 을 활용하게 되면 보다 빠른 I/O 성능을 뽑아 낼 수 있다.

여기에 tcmalloc 이나 jemalloc 과 같은 메모리 할당자를 이용하게 된다면 미묘하지만 성능상 잇점을 얻을 수 있고
메모리 사용량이 감소 되는 효과도 부수적으로 얻을 수도 있다.

하지만 이에 대해선 충분한 시험 후 적용하는 것이 좋다.

또한 Network 성능 향상을 위해서 epoll ,kqueue  혹은 IOCP 와 같은 library 를 활용 할 수 있는 솔루션을 선택하여
해당 library 를 이용할 수 있도록 하는 것이 좋다.


5. Configuration
이렇게 필요한 SW 들을 모두 완비를 하였다면
적절한 설정으로 해당 Application 들을 최적화 해야 할 필요가 있다.

하지만 적절한 설정 값 을 논하기엔 어려우니 큰 그림으로 보면서 이야기 하자면
기본적은 OS 와 관련된 parameter 들의 경우엔 현재 구비된 H/W 성능을 충분히 낼 수 있을 만큼의 조정이 필요하지만.

DBMS 나 Web Server / Container 와 같은 Application 은 적절하게 시스템 자원들을 활용 할 수 있도록 할당해줘야 한다.
보통 OS : DBMS : Web Container : Web Server 를 놓고 보자면 2: 5 :2:1 정도로 할 당해준다고 하면 얼추 잘 돌아갈 것이다.

물론 대략적으로 이야기 하지면 이렇다는 것이고.
DBMS 의 경우엔 CPU core 나 Memory 할당에 비중을 두고 설정을 하고 Main Memory 자원을 사용하는
Memcached 나 Redis 와 같은 DBMS 를 사용하게 되면 Memory 자원의 할당에 신경 써야 할 것이다.
Web Container(혹은 interpreter 와 같은 ) 의 경우엔 그 다음으로 CPU/Memory 자원을 할당한다.
그리고 Web Server 의 경우 비교적 적은 자원을 사용해도 무방 할 것이다.

하지만 FastCGI 를 사용한다 던지 Web Server 에 Plugin 등 을 사용한다던지 하면서
Memory 사용량이 급증 할 가능성이 있기 때문에 이에 따라 적절하게 설정을 변경해주는 것이 필요하다.




6. Keep eyes on ..
사용하다 보면 수 많은 변수들이 생기기 마련이다.
Application 이 변경 되면서 특정 자원을 제대로 사용하지 못한다거나 혹은 너무 과용하게 되서 다른 시스템에 영향을 미칠 수도 있다.

이런 일이 벌어졌을때 최악의 경우
DB 가 날라간다거나.
DB 가 소멸한다 거나..
DB 가 응답을 하지 않는 다거나...

하는 일이 벌어질 수도 있다.

또한 여기서는 언급이 되지 않았지만
보안적인 측면이나 혹은 시간이 지남에 따라 최신 기술들이 등장하기에
꾸준한 관심으로 시스템을 모니터링 해주면서 적절하게 그때 그때 최적화를 통하여
시스템을 유지하는 것이 최선이라고 할 수 있다.



Reference
http://www.php.net/manual/en/install.fpm.configuration.php

http://stackoverflow.com/questions/17141596/fastcgi-vs-php-fpm-using-nginx-web-server
http://php-fpm.org/about/
http://stackoverflow.com/questions/6330727/the-reason-why-mod-php-is-less-efficient-than-fastcgi-phpphp-fpm
http://stackoverflow.com/questions/1405656/apaches-mod-php-or-fastcgi-which-is-good-for-wordpress/1943706#1943706
https://github.com/facebook/hiphop-php/blob/master/hphp/doc/ir.specification
http://www.hhvm.com/blog/
http://www.canonware.com/jemalloc/
http://www.mysqlperformanceblog.com/2013/03/08/mysql-performance-impact-of-memory-allocators-part-2/
http://slashdot.org/topic/bi/mariadb-vs-mysql-a-comparison/
http://redis.io/
http://memcached.org/
http://nginx.org/
http://projects.unbit.it/uwsgi/
http://gunicorn.org/
http://nichol.as/benchmark-of-python-web-servers
http://www.kegel.com/c10k.html
http://www.slideshare.net/khanz2012/ijcse10-020562
2013/10/01 01:34 2013/10/01 01:34
이 글에는 트랙백을 보낼 수 없습니다
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다

셋방살이 중인 서버의 대 격변(?) 에 발 맞춰서
기존의 Apache + mod_php 와 낮은 버전의 MySQL 로 인하여 이래저레 못해왔던 것들을 던져 버리고

신흥 문물(?) 들을 받아들여 보고자 하였는데.

설치 환경은 아래와 같다.

  • CentOS 6.x ( x86_64 )
    • MySQL 5.5.x
    • PHP 5.3.x
      • APC
      • PHP-FPM
    • Nginx 1.4.x
    • Memcached 1.4.x

오랜 숙원 사업이였던 탈 i686 의 꿈을 이루고 이것저것 삽질을 시작 하였는데.

여기서 설치와 관련된 내용은 모두 Yum 을 이용하여 설치를 하였다.
다음 Yum repository 를 추가 해주면 간단히 해결 됨.

이때 각 Yum Repository 마다 동일한 패키지 명의 중복으로 피곤해지는 일들이 발생 된다면
yum-plugin-priorities 을 설치하시면 Repo 별로 우선순위를 지정해서 처리가 가능하니 깔끔하게 해결!


이렇게 모든 패키지가 설치가 완료가 된다면.

PHP-FPM + Nginx 가 원활하게 구동 할 수 있도록 설정을 해줘야 하는데.

/etc/nginx/nginx.conf

location ~ \.php$
{
    fastcgi_send_timeout  5m;
    fastcgi_read_timeout 5m;
    fastcgi_connect_timeout 5m;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}


여기에 Textcube 를 위한 URL redirection 을 추가 한다.
( c.f /documents/setup_nginx.txt 을 참조하시길 바란다 )

location /tc/  {
    set $rewrite_base '/tc';
    if (!-f $request_filename) {
            rewrite ^(thumbnail)/([0-9]+/.+)$ cache/$1/$2;
    }
    if ($request_filename ~* ^(cache)+/+(.+[^/])\.(cache|xml|txt|log)$) {
            return 403;
    }
    if (-d $request_filename) {
            rewrite ^(.+[^/])$ $1/;
    }
    rewrite  ^(.*)$ $rewrite_base/rewrite.php last;
}


/etc/php-fpm.d/www.conf

[www]

listen = 127.0.0.1:9000

listen.backlog = -1
listen.allowed_clients = 127.0.0.1

user = nginx
group = nginx

pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
request_terminate_timeout = 120s
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log
security.limit_extensions = .php .php3 .php4 .php5 .html
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on

/etc/php.d/memcache.ini
extension=memcache.so
memcache.default_port=11211

memcache.hash_function=crc32
memcache.hash_strategy=consistent
memcache.protocol=ascii
session.save_handler=memcache

session.save_path="tcp://127.0.0.1:11211?persistent=1&weight=1&timeout=1&retry_interval=15"



일단은 여기까지 설정을 마치고 PHP 가 정상적으로 구동되는지 확인을 한다.

정상적으로 동작을 한다면

Textcube 안정버전인 1.8.6 을 다운로드 받아서 설치를 하게 되는데
MySQL 5.5+ 에서의 호환 성을 위해 설치 전 미리 몇 가지 손을 좀 봐야 할 필요가 있다.

setup.php 의 1132 line. 의 TALBE 생성 시 'TYPE' 을 'ENGINE' 으로 바꿔 줘야 한다.
- $charset = 'TYPE=MyISAM DEFAULT CHARSET=utf8';
+ $charset = 'ENGINE=InnoDB DEFAULT CHARSET=utf8';


그리고 Textcube 를 설치를 진행 한다.

이때 Rewrite 관련 설정에 에러가 나는데 옵션을 끄고 진행 하더라도 무방하다.

여기까지는 Textcube 에서 제공하는 setup_nginx.txt 를 참조 하시면 좀 더 친절하게 안내 받을 수 있다.

여기서 한가지 고비가 오는데
Textcube 1.8.6 에서 PHP-APC 가 활성화 된 환경에서 Login 이 불가능하고 502 Error 를 뱉고
진행이 불가한 상황이 벌어지는데

PHP::Session class 와 session_write_close() 사이에 어떤 문제가 APC 모듈과 비 정상적인 동작을
일으켜서 생기는 문제라고 하는데

이때 PHP-APC 를 삭제 하거나 disable 하시면 되지만
왠지 아깝지 않은가? Textcube 때문에 APC 를 쓸 수가 없다니!!!!

이럴때 Texcube 가 설치된 디렉토리 아래의
./library/preprocessor.php 의 152번 째 줄 즈음에 다음 코드를 추가 한다.

+ register_shutdown_function("session_write_close");


이후엔 정상적으로 로그인이 가능해질 것이다.

Textcube 에 로그인 후 Memcache 를 활성화 시키기 위해서
"텍스트 큐브 관리" 메뉴로 이동한 뒤 "서비스 관리 > 서버" 메뉴에 진입을 한 뒤
"Memcached 사용" 메뉴에 Checkbox 에 Check 한 뒤 저장을 하게 된다면

보다 빠릿빠릿한 블로그를 이용 할 수 있게 된다.
2013/08/04 18:07 2013/08/04 18:07
이 글에는 트랙백을 보낼 수 없습니다
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다
Dot:Where is ......
byDot
Where is ......
전체 (176)
주절거림 (60)
윈도우벽지 (2)
Shoveling.. (9)
주워들은것들.. (48)
요집이 괜찮더라!! (0)
찍사놀이 (7)
관심꺼리~ (4)
«   2018/10   »
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
  1. 내 맘대로 보는 세상  2009
    맘에 안드는 Internet Explorer 업데이트 방침!
  2. 시리니  2008
    브라우저 업데이트, 작지만 큰 실천입니다.
  3. Dinosur와 KM의 Blog  2007
    저도 보통 사람
  1. 2018/07 (1)
  2. 2018/01 (11)
  3. 2017/12 (10)
  4. 2017/10 (1)
  5. 2017/05 (13)