기술의 발전으로 인하여 저렴해지고 보다 성능은 뛰어나졌다.
요즘은 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

없는 살림 쪼개 쓸려다 보니 이래저레 붙이고 있는데.


서버 사양이 낮은 만큼 Load 도 별로 안걸리는 서버이지만
MySQL 5.5 에 jemalloc 을 붙여서 조큼은 빠릿빠릿하게 돌아주길 바라면서...

jemalloc 의 설치는 매우 쉽게 된 다..

EPEL Yum repo 에 이미 들어가 있기 때문에 간단히 yum command 로 설치가 가능하다.




이렇게 설치가 완료 되면

mysql 구동 하기전에 libjemalloc.so 을 로딩하도록 해줘야 한다.

그러기 위해서 간단히



해주면 된다.

이때 libjemalloc.so 파일의 위치를 넣어주면 된다.


그리고 MySQL 을 재 시작 해주면 된다.



그리고 재 시작 된 뒤에
제대로 로딩이 되었는지 확인하면  끗.





참고

• jemalloc ( http://www.canonware.com/jemalloc/ )
  
  KTH Blog ( http://dev.kthcorp.com/2011/05/12/last-free-lunch-facebooks-memory-allocator-jemalloc/ )
  Memory allocators: MySQL performance improvements in Percona Server 5.5.30-30.2

MySQL 성능을 죽이는 15가지 방법이라는 아주 재미있는 내용의 프리젠테이션...

MySQL 을 기반으로 한 다양한 웹 서비스들을 만들어가고 또 운영되는데 있어서
항상 MySQL 이라서 느려...MySQL 이니까 이 정도도 감지덕지... 라고 하지 말고
제대로 알고 제대로 쓸 수 있도록 해보자.
#2. Not using EXPLAIN
EXPLAIN 은 입력된 SQL 문장을 해석하여 옵티마이져의 실행 계획을 보여주는 명령어 이다.
입력된 SQL 을 해석한 뒤 테이블의 데이터/인덱스 등을 판단하여 어떻게 실행 할지 보여주게 되는데.

Extra 컬럼에 "Using Index" 라고 나온다면 제대로 돌아 가고 있다 라고 봐도 거~~의~~ 무방하다.

특히 MySQL 5.0 이전 버전에서는 단 하나의 Index 만을 이용 할 수 있었는데.
MySQL 5.0+ 버전에서는 Index Merge optimization 을 통해서 좀더 향상된 속도를 얻을 수 있다.
이는 곧 인덱스 수립 계획에도 큰 도움이 된다. ( 슬라이드 Page 13 참조 )


#3. Choosing the wrong date types
Index ( 혹은 데이터) 는 가급적이면 단일블럭(Single Block) 안에 들어갈 수 있게 하는 것이 좋다.
기본적으로 DBMS 는 데이터가 늘어가면서 I/O 가 많이 일어나고 그리고 성능에 매우 민감하게 영향을 미치게 된다.
특히 디스크 처럼 매우 느린장치(CPU 연산 과정에서 보자면  HDD 는 아직 한참 멀었다.)에 접근 횟수를 줄일 수 있다면 당연히 느려진다는 것이다.

반대로 말하자면 데이터를 가져올때 횟수를 최소화 할 수 있다면 곧 속도향상을 얻을 수 있다라는 이야기.

그렇기 때문에 Index (혹은 데이터) 를 저장함에 있어서 가급적이면 최소한의 컬럼을 유지하는 것이 I/O 횟수를 줄이는데 유리하다.
슬라이드에서는 IP 정보를 저장할때 Varchar 형을 사용하거나 UNSIGNED INT 형을 사용 하는 2가지 경우를 가지고 이야기를 한다.

일반적으로 Varchar 형을 이용하여 저장하는 경우가 많은데. INET_ATON()/INET_NTOA() 함수를 이용하여 변환하여 INT 형에 저장 할 수 있게 되는데.
저장하는 데이터 크기도 줄이고 또한 Index range scan 을 통한 성능 향상도 꾀 할 수 있다는 장점이 있다.

슬라이드에서는 설명하고 있지 않지만 굳이 음수형으로 데이터를 저장할 필요가 없다면 UNSIGNED INT 와 같이 선언을 하게 되면 SIGNED INT로 선언했을 때 보다 약 2배 가량 속도 향상을 얻을 수도 있다고 한다.
그러니 *반드시* 필요한 데이터형의 크기를 잘 정해서 설계하는 것이 중요하다.

#4. Using persistent connection in PHP
MySQL 연결 시간(Connection Time) 을 줄이기 위해 영구적인 연결(Persistent Connection) 을 이용하는 경우가 있다.

하지만 영구적인 연결(Persistent Connection) 인 경우 자원을 공유하지 않은 구조로 인하여
Apache 프로세서가 Zombie 상태에 빠지게 되면 그대로 자원을 낭비하게 된다.

애초에 MySQL 은 수명이 짧고 경량형 으로 디자인 되어있어서 Connection Time 은 Oracle 이나 PostgreSQL 에 비해서 10~100배 가량 빠르다고 하니 pconnon_* 계열 에 목 매지 맙시다.

#5. Using a heavy DB abstraction layer
이식성(Portability) 때문에  ADODB , MDB2  혹은 PearDB 같은 무거운(Heavy) 추상화 라이브러리(abstraction Library) 를 쓰는데
그것 보단 PDO 같은 경량형 라이브러리를 이용하는 것이 좋다.  거기에 Scale-out 을 위한 부분도 추가해주 면 좋다.

#6. Not understanding storage engines
MySQL 에서는 매우 다양한 DB Engine 을 가지고 있는데 각 Engine 의 특성에 따라서
장 단점이 있는데 이에 대한 이해를 통해 적절한 Storage Engine 을 활용하면 보다 나은 성능을 발 휘 할 수 있다.

반대로 그러한 이해가 없이 사용하면 오히려 성능저하의 원인이 되기도 한다.

예를 들어 웹 로그 기록 같이 한번 입력하면 변경은 이루어지지 않고 고속의 INSERT 성능이 필요한 경우엔 Archive Engine 을 쓰는 것이 낫다 더욱이 압축 효율 또한 우수하여 ( MyISAM 대비 6~8배 ) 디스크 관리에도 유리하다.

반대로 주간 베스트 와 같이 크지는 않지만 빠른 입출력이 필요한 경우 Memory Engine 을 사용하면 Disk based Engine 에 비하여
획기적으로 빠른 성능을 제공 할 수 있다.

이처럼 적절한 Engine 을 활용 하는 것이 보다 나은 성능을 보장해준다.
다시 한번 말하지만 InnoDB 는 어디에도 붙일 수 있지만 성능을 보장해주는 것은 아니다.


#7. Not understanding index layouts
INDEX 선정과 Storage Engine 을 선탁하는데 매우 중요한 부분이다.
모든 Engine 들 은 Data 와 Index 를 메모리(Memory) 와 디스크 ( Disk ) 에 저장 한다.

Clustered 방식은 Primary Key 를 기준으로 정렬된 Data 묶음 단위로 디스크에 저장을 하고
Non-Clustered 는 그렇지 않다.

Non-Clustered 의 경우에는 큰 영향은 없지만.
Clustered 의 경우 데이터를 검색 할 경우 Primary key 를 보고 실제 데이터로 이동하여 데이터를 검색 하기 때문에
데이터 조회시 가급적 PK 를 이용하여 데이터를 검색하는 것이 좋다.

그리고 Clustered  방식에서 생성되는 모든 Second Index 는 PK 를 참조하여 만드므로 PK 는 최대한 작게 만들어주는 것이 좋다.

#8. Not understanding how the query cache works
사용하는 Application 의 Read/Write 비율을 이해한 상황에서
CPU 사용율과 읽기 성능을 적절하게 조율해야 한다.

Query Cache 를 늘린다고 성능이 무작정 증가하지도 않는다.

Cache 검증하는데 매우 투박한 검증방식 을 채용했는데
이유는 Cache 된 데이터를 찾아서 저장하는데 너무 많은 CPU 자원을 사용을 방지 하기 위해서 이다.

이는 SELECT 할 때 Table 에 어떠한 변화가 생긴 경우 모든 Cache 정보들은 유효하지 않게 된다는 것이다.
결국 Table 에 매번 변화가 생길 경우 매번 Cache 갱신을 하게 되고
Query Cache 의 효율이 떨어지게 되는 것이다.

그래서 자주 업데이트 되는 컬럼들을 분리 할 필요가 있다.

#9. Using stored procedures improperly
모든 RDBMS 는 Connection thread 별로 컴파일(Compiled)된 Stored Procedure 의 실행 계획을 유지하게 되는데

이것은 PHP 로 만든 페이지에서 요청을 보내서 SP 를 이용하여 데이터를 가져온다면
매번 컴파일을 거친다는 것이고 이것은 매우 큰 낭비라는 것이다(7~8% 정도)

특별히 매우 복잡하고 요쳥 빈도수가 많지 않은 작업이거나...
한번에 매우 많은 횟수의 Query 를 요청하는 경우가 아니라면....말이다.

그냥 Prepared Statements 를 써라...

#10. Operating on an indexed column with a function
Index Column 을 펑션으로 변환해서 사용하게 되면 Index 를 사용할 수 없게 된다.
그러니 있는 그대로 Index Column 을 사용 할 수 있도록 하는 것이 중요하다.

#11. Having missing or useless indexes
Index 는 SELECT 할때 검색 속도 향상에 매우 도움이 크다.

하지만 사용하지 않는(혹은 빈도 수가 매우 적은) Index 는 INSERT/UPDATE/DELETE 할때 매우 부담이 된다.
필요 없는 Index 는 반드시 삭제해주는 것이 좋다.

혹시 대량의 데이터를 입력이 필요 할 경우 경우에 따라서는 INDEX 를 삭제한 뒤
입력을 완료하고 인덱스를 생성하는 것이 나을 것이다.

#12. Not being a join-fu master
최대한 단순하게
복잡한 SQL 문을 쪼개서 데이터 묶음(Sets)으로 생각하라.

반복된 작업(Subquery,loop) 가 아닌 데이터 묶음(Join)으로 생각 해야 한다.
데이터의 묶음으로 처리하기 때문에 보다 나은 성능을 얻을 수 있다.

( 46~48p 를 반드시 참조하라!)

#13. Not accounting for deep scans
정렬된 데이터(ordered set)에서 매우 깊숙한(Deep scan) 곳에 데이터의 일부를 가져오는 것은 비용이 매우 많이 든다.

보통 게시판의 Paging 을 하면서 LIMIT 를 이용하게 되는데

페이지 넘버가 커지면 커질 수록 느려지는 경험을 해봤을 것이다.

이유는  LIMIT 를 이용하여 목록을 가져 오는 경우
1. 데이터를 정렬하고
2. 검색에 필요한 위치(offset) 을 지정해서 목록을 가져 온다.

여기서 데이터를 가져오는 위치(offset) 이 크면 클 수록 그 만큼 scan 을 하는 비용이

Full scan 비용에 근접하게 된다.
이를 피하기 위해선 해당 정렬된 데이터(Ordered set)의 크기를 줄여서 가져오는 것이 보다 나은 성능을 보장 할 수 있다.

#14. Doing SELECT COUNT(*) without WHERE on an InnoDB table
InnoDB 는 SELECT count(*) 로 Table 전체 Row 개 수를 가져오는 작업은 매우 퍼포먼스가 느린 작업이다.


InnoDB 내부적으로 매우 복잡(?) 한 구조로 인하여 생긴 문제인데 ( MyISAM 에서는....괜찮았다...)

필요하다면 별도의 테이블을 생성하여 Table 마다 Trigger 를 작성하여 Table Row count 를 관리하도록 하는 것도 방법이 되겠다.

#15. Not profiling or benchmarking
시스템 성능의 Bottleneck 을 항상 관찰하고(Profiling)
어플리케이션의 성능이 어느정도 까지 버틸 수 있는지 얼만큼의 부하를 견딜 수 있는지 테스트(Benchmark) 해볼 필요가 있다.

(54~56p 참조)

#16. Not using AUTO_INCREMENT
MySQL 에서 AUTO_INCREMENT 는 매우 PK 에 최적화 되어있다.

복합적으로 진행 되는 매우 많은 INSERT 에도 고성능으로 처리가 가능하다.
(Lockless reading and appending)

#17. Not using ON DUPLICATE KEY UPDATE
Application 에서 해당 Row 가 존재하는지 보고 Update or INSERT 를 결정하는 경우가 있는데
DB Connection 을 오가면서 소모되는 비용을 줄 일 수 있다. ( 약 5~6% 정도 )
물론 많은 양의 데이터가 와도 가능하다.

http://joinfu.com/presentations/kill-mysql-performance/kill-mysql-performance.pdf
http://ppassa.wordpress.com/2011/05/15/mysql-optimization-with-indexing/