|
홈페이지 : http://www.openphp.com
. http://www.openpython.com
안녕 하세요? 조성준 입니다.
작년말에 쓸쓸해서 정리하던 강좌고 오늘 올리면서 몇군데 고쳤습니다. 신버전이 나와서리 ^^
* 본문서는 본인이 이해하고 스스로 독학으로 인해 오역과 오탈등이 많습니다 ^^ 잘못된 부분은 지적을 부탁드립니다. *
DB Connect Pool이라는 것은 아래 링크를 통해 개념파악정도는 하실수 있으실겁니다.
http://www.openphp.com/board/board_center?Type=View&tb_name=board_php_study&id=50&start=0&id_no=16&search=&andor=&word=
DB Connect Pool의 이점은 간단히 애기하면, PHP의 경우처럼 각 페이지 업무처리할때마다
디비연결 -> 인증처리 -> 쿼리등 각종작업 -> Free Reult등 마무리 작업 -> 디비 종료
위와 같은 수순을 기본적으로 처리되게 됩니다. 이 경우 디비연결과 인증처리 , 디비 종료에서 시스템의 리소스(CPU,RAM사용률)
를 많이 차지하게되며, 만약에 10,000명의 접속자가 어떤 페이지를 접속했을때 PHP에서 PostgreSQL로 저런 작업을
수행할때 CPU와 RAM을 매우 바쁘게 일을 시키게 됩니다.
이런경우 대처방법은 SQL Link방식인 pconnect이지만 연결 종료를 제대로 하지않거나 처리 미숙으로 인해 쓸모없는
연결로 DB Many Connection이라는 메세지를 받아 곤욕 스러울때가 있습니다.
대안을 아니지요. PHP의 운영방식이 웹서버의 모듈이며, 웹서버에서 역시 prefork방식이고 Muti-Thread방식이라고 하더라도
직접적인 연관을 띄지못해 JSP나 ASP같이 Client Language단에서 DB Connect 정보에대한 공유나 제어가 불가능합니다.
사실 불가능한건 아니지만 많은 시간을 들여서 안정화해야 한다는 단점이 있습니다.
만약에 디비연결과 인증 , 디비 종료단계를 어떤 누군가가 제어해준다면?. 최대한 적은 리소스를 통해
DB의 성능을 극대화하고 최대한 리소스를 절약할수 있다면?
이런 역활을 하는것인 DB Connect Pooler입니다. 상용디비에는 기본적인 기능은 수행하는 Middle Ware가 자체적으로 있거나
훌륭한 상용 Middle Ware가 판매되고 있지만 Open Source에서는 많지도 않고 불편한점도 많기는 하지만
Free라는 단서에 우리는 만족해야 한다.
- pgpool for PostgreSQL -
pgfoundry : http://pgfoundry.org/projects/pginstaller/
광고 : 일본 아마존 PostgreSQL !코너에 기사도 내고 , Japan Economy IT Pro에 기사도 나고,PC Web,PostgreSQL 완벽공략 개정4판에도 실렸다네요
pgpool이 일본서 만들어 지기도 했고 국내에서는 사용자가 드물지만 일본서는 PostgreSQL 이용이 상당히 활발합니다.
FreeBSd도 일본서는 활발하지만 국내는 그리 높은 위상을 실감하지 못하는지라.음 아쉬울뿐입니다.
개발자들에게 자기시간과 자기개발의 여력이 지원된다면 충분히 못지 않거나 더 낳은 개발이 가능할텐데
어서 국내 IT인력들의 근무여건이 개선되어야 할텐데 너무 아쉬운 대목입니다.
pgpool은 pgfoundry에 상위랭크되어 있는 이미 잘알려진 PostgreSQL용 DB Connect Pooler이지만 현재 국내 소개자료를 뒤져도
않보이더군요. pgpool은 일본에서 개발되었고 현재 이 문서 작성시점까지 2.4 release가 발표된 상황이며,
PostgreSQL 7.4 부터 도입괸 V3 Protocol와 기존의 하위버전의 V2 , V1 Protocol까지 지원을 합니다.
다만 7.1의 경우 소스에서 한줄 수정이 필요로 합니다.
* pgpool 장점들 *
1. 기존의 프로그램에 수정을 할필요는 전혀 없다.
다른 DB Connect Pool은 자신만의 전용 API를 써야만 하기때문에 기존 서비스에 도입하기에 많이 꺼려지기도합니다.
일부에서는 기존 프로그램의 변경이 없는것도있지만 일부 지원이 않되는 문제도 있기는합니다.
다만 아쉬운점은 pgpool에 대한 정보를 구하는 api나 쿼리문법이 없어 아쉽기는하지만 아직 초기버전이니 앞으로 풀어낼것이라고 본다.
2. prefork방식으로 운영되어 안전성이 높고 빠른 응답시간이 제공된다.
prefork방식의 안정성은 process 구조상 당연히 얻어지는 부분이다. 하지만 Muti-Thread를 지원한다면,
더 적은 리소스를 차지할수 있지만 Muti-Thread는 부모 프로세스의 오동작등으로 인한 전체 다운이라는
중대한 문제가 발생할수 있기는 하다. prefork가 copy to write라 메모리를 좀 차지하는건 어쩔수없지만.
생각보다는 프로그램의 크기가 작아 티?도 나지 않는당
설정 부분에서 보면 아시겠지만 정해진 수만큼 미리 prefork하기때문에 응답속도는 빠른다.
또한. 디비서버와 실제 디비 어플리케이션 서버간의 거리가 멀경우 pgpool에서 미리 디비와 연결을 해주기때문에
연결/인증/종료 Network Trasaction발생에 필요한 Time을 거의 없애기에 접속단계에서 빠른 속도 체감이 가능해진다.
3. PostgreSQL의 동싱접속제한
이건 당연히 생기는 기능이지다. DB Connect Pool은 PostgreSQL에 미리 디비연결을 해두기때문에
따로 pgpool에서 설정을 하여 제어할수 있다. 만약에 PostgreSQL 동시접속을 100명을 두고
기존방식대로 유지한상태 즉 apache에서 최대 500명으로 셋팅하고 php에서 PostgreSQL Dedicate로 연결할때
100명 넘게 접속하면, 디비는 어머나 나살리 라고 에러를 토설하고 장렬히 접속자를 무시한다 ^^
이때는 pgpool에서 90명정도를 두고 나머지 10명의 여유분을 시스템에서 도는 프로그램이나 batch작업용 Process용으로
두어 디비에 부하를 줄여주는 일거양득?의 효과를 보는 샘이 된다.
4. FailOver (1번 디비가 죽었을때 2번 백업디비로 자동 연결)
이경우는 메인 디비서버와 백업 디비 서버를 운영할때 유용한 기능으로. 메인디비서버와 연결을 계속하다가.
메인이 죽어 버리는 사태가 발생하면 자동으로 백업 디비로 연결을 하게 된다.
postgresql의 간단한 mirror tool인 dbmirror나 Slony-I,rsync등 다양한 방법으로 백업 디비 서버를 둔상태에서 유용하다.
pgpool기능중에 약하고 제약이 많지만 replication기능과 병행도 가능하다.
pgpool에서는 자동연결이되나 디비 어플리케션과는 연결이 중단되므로 재 연결이 필요하기는 하다.
차후버전에는 Client에 대한 자동연결이 될듯..^.~ 않되면 말구^^
4. Replication (다중 디비 동기화?)
간단히 애기해서 디비서버가 독립적인 하드웨어 여러대가 있을때 이 디비들간의 미러링을 해준다고 보면된다.
하지만 pgpool은 2대까지만 지원된다고 한다. 또한 뒤에서 설명하겠지만 제약점과 아직은 실제쓰기에는 좀 그렇다는
말이 나와서 아직은 실 서비스에서는 쓰지마시고, PostgreSQL Contrib에 있는 dbmirror,Slony-I나 다른방법을 사용하기를
권장하고 싶네요... 제약이나 개발진의 묘한 여운의 아직 쓰긴 이르다는 표현이 있어...
이 기능에 대해 계속 연구와 개발중인것으로 보안 차후 버전에서는 어능정도 완벽하게 될것같다.
5. Load Sharing
replication기능이 On되었을때 지원되는 기능으로 select 즉 결과를 얻기위한 Query시에 양쪽 디비 서버를 통해
로드를 분산해주는 기능입니다. 중요한 것은 select부분에 디비에 update,delete,drop같은 데이타 변조명령이나
함수,프로시저등이 있을때는 불가능 합니다. 역시 replication기능이 안정화와 업그레이드가 될때
사용하심이 낳을듯 하나 단순쿼리등 제약점 내에서 서비스하는 거라면 추천드립니다.
이 기능을 On했다고 해서 select 쿼리에 대해 로드공유를 하는건아니면, 따로 회피시키는 방법있습니다. 그건 뒤에성..
위 테스트는 P4 2.4GHz x2/1GB RAM/80GB IDE 7200rpm , Red Hat 9/PostgreSQL 7.4.3(shared_buffers=2048) , pgbench -S -c 1...128 -t 10000
로 테스트 했다고 합니다. 대략 2배의 성능 향상이 있다네요. 뭐 디비서버를 두대로 했으니 어찌보면 당연한 결과.^^
위와 같이 다양한 장점이 있으며, 위 자료는 원문자료를 인용하고 개인적인 내용을 덛붙였습니다.
원문에서도 그렇듯. DB Connect Pooler의 장점위주보다는 여타 다른 DB Connect Pooler에 비해라는 전재자 붙는데^^.,...ㅋㅋ
* pgpool 단점들 *
1. Over Head
이경우는 문서에서는 어쩔수없는 DB Application Program과 Database Server와 Dedicate Connect가 아닌 이상 생기는
어쩔수없는 현상이다. 다만. Local에서 DB Connect Pool이용이나 초고속 네트웍 망에서라든지에서 직접 연결보다는
다소 연결에 거치는 단계에서 오버헤드가 발생하지만. DB Connect Pooler에 어쩔수없는 것이긴합니다.
만약에 pgpool이 Query Cache기능이 생기면 어느정도 커버될듯
대충 이런 상황이죠. 한서버에 디비서버와 디비어플리케이션이 같이 동작할때에서 단순 연결을 기준으로 보면,
검색에서는 2% 정도 , 갱신에서는 17% 정도라지만 상황에 따라 그때그때 달라용 ^^~ 미친소.
이건 단순 연결과 1 user등으로 볼때지만 우리의 목적은 연결/인증/종료등의 어버헤드와 제어 디비서버의 부하감소
연격지 디비 서버 연결 시간등의 장점이 있으므로 이정도는 충분이 커버된다고 보여집니다.
2. 모든 libpq 프로토콜의 지원을 아직
replication On 모드시 trust, clear text password이외의 인증 방식
replication Off 모드시 trust, clear text password, crypt, md5이외의 인증 방식
pg_hda.conf를 통한 접근 제어가 지원이 되지 않습니다. pgpool과 PostgreSQL과의 연결상의 제어는 pg_hda.conf에서 당삼됩니다.
pg_hda.conf를 통한 접근 제어가 않되다보니 다소 위험하긴하지만 대부분 디비서버의 인증보다는
Kernel Level의 Packet Filter를 통해 ip를 제어하는것이 제일 효과적이다.
서버에 이미 접속된 상태에서 접근제어를 DB Server에서 하는것보다는 불필요한 연결요청 Traffice을 줄일수 있으니
크게 문제될 부분은 아닌것같3
3.template1 , regsession의 이름의 디비에 대해서는 connect pool대상에서 제외됨.
문제될건없습니다. 실제 서비스에서는 각각의 디비 명으로 따로 생성해서 하지만 test나 시스템쪽 디비에 테이블 만들어
사용하는 예는 없으니...
4. 일시적 메모리 테이블와 prepare 의 자동처리 불가
잠시 쿼리정도를 디비의 메모리나 temp파일을 이용해서 넣어두는 구분 create temp 또는 create template는
기존에서는 디비 종료시 알아서 지워주어 개발자의 타이핑을 줄여주었지만 아직 pgpool은 pgpool과 DB Application과의
종료시 이런 작업을 자동화 하지않아 일일시 종료할때 지원주어야 하는 번거러움이 있기는 합니다.
DB Application을 잘못짜서 drop temp 전에 종료되면 디비서버에 해당 테이블이 남아 있게 되는 경우가 발생하는
이부분역시 버전업에 포함된듯. 또한 prepare로 작성된 plan역시 지워지지 않습니다.
해결방법은 create temp시 on commit drop 을 주어 자동삭제 하게 하고, prepare로 작성된 plan에 대해서는
deallocate명령으로 삭제를 해주고 종료하셔야 합니다... 음. 쬐금은 일을 늘었습니다.
5. replication 기능 사용시 문제점
다른서바간의 oid,serial,current_time등과 같이 시스템 의존적인 부분에서 정확한 동기화 처리가 아직 미비해서
기대하기 힘들부분이라 이는 완벽동기화라는 것을 하기에는 아직 무리가 있어 보이네요. 감안하거나
다른방법을 이용하시는 편이 좋을듯. 고로 아직은 pgpool의 replication은 실서비스 도입에 다소 생각을 해야 한다는것을
애기합니다.
* 주의 *
PostgreSQL 7.1 이하버전 사용자가 pgpool 2.0 release 이상을 사용시
pgpool 2.0은 PostgreSQL 7.4 부터 도입된 V3 Protocol을 지원하면서 그 이전 버전의 V2 Protocol로 전송되는 데이타에 대해
V3로 변환하면 처리하게 되면서 다소 기존 버전사용자의 경우 소스에서 한줄을 고쳐 주셔야 됩니다. 다행이 한줄이니..^^
pgpool 소스를 풀어 보시면 pool.h 파일이 있습니다 C Header파일인데 여기서
#undef NO_RESET_ALL 을 #define NO_RESET_ALL 바꾸어야 합니다 지금 pgpool 2.4의 소스에는 없는거보니 자동 패취된듯.
pgpool을 옛버전을 쓰실분은 있고 postgreSQL 7.1 이하시면 고쳐 주셔야 할듯.
* 현재 개발진에서 테스트한 시스템환경 *
- Vine Linux 2.6r4 (kernel 2.4.22-0vl2.12)/PostgreSQL 7.4.3
- Vine Linux 2.6r4 (kernel 2.4.22-0vl2.12)/PostgreSQL 7.4.2
- Vine Linux 2.6r4 (kernel 2.4.22-0vl2.12)/PostgreSQL 7.3.6
- Vine Linux 2.6r3 (kernel 2.4.22-0vl2.8)/PostgreSQL 7.4.2
- Vine Linux 2.6r3 (kernel 2.4.22-0vl2.8)/PostgreSQL 7.3.6
- Vine Linux 2.6CR (kernel 2.4.20-0vl29.1)/PostgreSQL 7.4.1
- Vine Linux 2.6CR (kernel 2.4.20-0vl29.1)/PostgreSQL 7.3.4
- RedHat Linux 9.0 (kernel 2.4.20)/PostgreSQL 7.3.6
- RedHat Linux 8.0 (kernel 2.4.18-14)/PostgreSQL 7.3.2
- OpenBSD 3.5
- FreeBSD 5.2.1-RELEASE(AMD64)/PostgreSQL 7.4.3
- FreeBSD 5.2.1-RELEASE(i386)/PostgreSQL 7.3
- FreeBSD 4.7-RELEASE/PostgreSQL 7.2.4
- FreeBSD 4.2-RELEASE/PostgreSQL 7.3.2
- Sparc/Solaris8/PostgreSQL 7.3
- Sparc/Solaris8/PostgreSQL 7.4.3
현재 제가 테스트 중인 FreeBSD 4.10 + PostgreSQL 8.0 (GCC2.9) 와 RedHat Enterprise 3(Cent 3.3) + PostgreSQL 8.0(gcc3.4)에서도
잘 동작하고 아직 에러 로그는 없어 보입니다. ^^ 좀다 두고봐야 겠지만.
- 참고-
Replication 기능에 대한 문제점과 셋팅 법등은 따로 페이지를 말련하고 가능하면 테스트 환경을 두고 직접해보겠습니다.
본 게시물에서는 지면 하례를 하지 않으니 관심있으신분은 알려주시면 저와 함께 해보아요 ~
하지만 현재 문서로 보아도 제안이나 제약등이 많고 개발진도 dbmirror나 Slony-I,rsync등을 덛붙여쓰라고 하니
큰 기대를 하지 못할듯. 하지만 이렇게 좋은 프로그램 만들것 만으로 감사...
동생시간되면 일어 메일하나 써달라고 해야 겠군요 ^^.
- pgpool Install -
pgpool은 매우 간단하고 소스도 적어 길게 쓰고 싶어도 못쓸뿐더라 옵션도 단초롭습니다.
다운로드 1 : http://www2b.biglobe.ne.jp/~caco/pgpool/pgpool-2.4.tar.gz
다운로드 2 : http://pgfoundry.org/projects/pgpool/
홈페이지 1 : [url]pgpool.projects.postgresql.org/[/url]
홈페이지 1 : http://pgfoundry.org/projects/pgpool/
다운받아 풀어 보시면 아시겠지만 2.4 기준으로 644kb 밖에않된답니다.
소스를 풀어 보아도. 소스가 빈약해보이지만. 일단 자체 API를 쓰지않는 것만으로도 맘에 들기때문에 여러분의 의심을 버리싶시요. 믿으라~
1. configuration
별다른 옵션을 필요없으나 몇가지만 알려드리겠습니다.
--prefix=
내가 원하는 위치로 설치하게 한다. 저의경우는 라이브러리를 제외하고는 따로 위치레 설치하는 버릇이 있어서리.
make uninstall을 지원하면 삭제나 이런게 편하긴하지만 하두 빈곤한 서버 환경에서들 작업한적이 많아
설치후 소스 삭제를 단행하기에 ^^.. 뭐 다양한 이유가 있지만. 이곳저곳에 들어 있는걸 싫어해서
--enable-dependency-tracking 또는 --disable-dependency-tracking
컴파일시 의존성 검사를 하는느냐 마냐입니다. enable하면 체크에 시간이 좀 걸리고 disable하면 후딱 처리되지만
소스가 적어 Kernel처럼 엄창난 시간이 아닌이상 enable하고 컴파일하시는게 안정성에서는 좋겠죠. ^^ 미신이야~ 버려~
--with-pgsql=
반드시. 하지만 PostgreSQL 설치를 rpm으로 하셨거나 PostgreSQL Lib Rpm을 까셨거나 (postgresql-devel이나 pg-devel)을
그런경우는 않하셔도 기본위치 /usr/lib /usr/include에서 찾지만 저같이 prefix로 특정 파티션에 설치하는 등의 경우는
위치를 정해주세요. 간혹 RedHat같이 또는 Port같이 연결된 라이브러리때문에 나도 모르게 아니 make install라고
딴청부릴때 몰래 PostgreSQL Devel이 깔릴경우가 있습니다.
이럴때 따로 깐 PostgreSQL은 8인데 몰래? 살림 꾸린 녀석이 버전이 낳으면 문제 소지가 있으니
따로 설치하신분은 꼭하싶시요.
./configure --prefix=/database/pgpool --with-pgsql=/database/postgres --enable-dependency-tracking
따로 특이하게 할게 없답니다. 그냥 술술 넣어 갑니다.
(나름대로 Optimize Level은 6까지 주고 CPU 종류 맞춰주고 gcc 3.4로 설치했는데 문제는 아직 없는듯.)
make ; make install
이제 알아서 잘~~~~~ 설치 됩니다. 시간은 640k의 작은듯한 코드는 후다닥.!!
(잡설 : 386dx난 486sx에서 Kernel 컴파일 해보신기억이 있나요. 미칩니다...^^)
설치후 cd /database/pgpool 로 해서 해당 디렉에 가보면 상당히 단촐합니다 bin과 etc뿐. man page도 않보이공 ^^
하지만 소스의 README를 보시면 모든게 다있습니다 ^^
(README.jp 가 있더군요. 음. 언젠가는 실력좋은 분이 번역해서 README.kr 이 들어 있기를 바라면 ...)
자 이제 셋팅해보아요~ 셋팅은 다음 게시물로 ...
* 역시나 엉망진창 강좌군요. 독한으로 보고한거라 틀린것도 많고 쌩뚱 맞게 엄한 애기도 있으니 오역을 바로 댓글로 신고 요망 *
|
