주워들은것들.. 2013/10/01 01:34
기술의 발전으로 인하여 저렴해지고 보다 성능은 뛰어나졌다.
요즘은 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
요즘은 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
이 글에는 트랙백을 보낼 수 없습니다
0