MySQL 사용시 sqlrelay 를 사용해야 되는가 ?

[SW기술] MySQL 사용시 sqlrelay 를 사용해야 되는가 ?  
 
 글쓴이   루리  날 짜 06-05-19 23:50  조 회 1774
 
 
APM 으로 사이트를 운영 또는 관리하시는 분들의 경우 어느정도 규모가 있는 곳의 경우 웹서버와 디비서버를 분리해서 사용하는 경우 많을 것 입니다.

특별히 쿼리가 복잡하고 비지니스적인 곳이 아닌 이상 게시판 구조가 많은 커뮤니티형이 커저버린 곳의 경우 시간이 지날수록 문제가 되는 경우가 디비쪽이 되는 것 같습니다.

사람이 많이 몰리게 되면 디비쪽 커넥션 에러가 나는 경우가 가장 자주 보게 되는 것 같은데요.

이런 상황에서 뭐 또 할 수 있는 것이 있는지 뒤지다 보면 접하게 되는 것이 디비 풀링인 것 같고 Mysql 에서 선택할 수 있는 것 중에 하나가 sqlrelay 인 것 같습니다.

제가 처음 sqlrelay를 접했을때 막연히 뭔가 좋아 지겠지라는 생각을 가지고 설정하고 테스트를 해봤습니다만 일반적인 벤치로는 직접 디비에 접속하는 것 보다 떨어지는 것으로 나왔습니다. 처음 테스트 했을때가 대략 1년 전정도 였던 것 같네요.

어제 한번 또 다시 테스트를 해봤습니다.

과연 Mysql을 사용하는 APM 시스템의 경우 sqlrelay 를 사용하는 것이 효과가 있는 것인지가 의문이 듭니다.

순수하게 디비 풀링 기능에 대한 부분입니다. 로드벨런싱이나 그런 부분은 커뮤니티형 사이트에서는 구현하기가 좀 힘들 것으로 생각이 되기 때문에 제외를 해야 될 것 같고요. 카운터나 그런 것들 때문에 업데이트가 매우많죠.

저같은 경우 전문적으로 배우거나 전공자가 아니라 사이트를 운영하다보니 제가 답답해서 직접 공부해 사이트를 운영중입니다.

이제 그나마 웹에서 주서 들은 것들은 다 쓰고 몇개 남지 않은 방법에 대해서 고민 중입니다.

어제 새벽에 시스템 점검한다고 사이트 다 내려놓고 sqlrelay 성능 시험을 했습니다. -_-;

내공이 짧아서 충분한 데이터를 뽑지 못해 공개는 못하겠네요. 몇가지 부분에 대해서 명확하지 않아서요. 내공이 짧아 충분한 분석이... 않됩니다.

아파치의 ab 명령으로 테스트 했을 경우에는 일단 성능은 떨어지는 것으로 나왔습니다.

웹서버-1 에서  ab 명령 으로 웹서버2 페이지 접속.
웹서버-2 에서 relay로 디비서버 접속.

인터넷을 뒤지다 보면 오라클의 경우 디비접속에 대한 손실이 크서 풀링 기능이 필요하다고 하던데요. 그에 비해서 Mysql 은 접속에 대한 오버해드가 매우 적다고 생각이 됩니다.

왠만한 접속으로는 거의 일반 파일 읽는 것과 차이가 없더군요.

이런 상황에서도 과연 쓰는 것이 효과가 있는 것인지 여러분들의 의견이 궁금합니다.

관련된 자료 보다도 실제 운영중 분들의 사용기가 더 부족한 것 같더군요.
 
 
 

 
   SC   06-05-21 00:06  
전에 컨넥션풀에 대한 이야기가 몇번 나왔었는데요.
그때마다 사람들은 대개 '맹목적인 신뢰'를 보여주는 경향이 있었습니다.
 
전에 컨넥션풀에 대한 이야기가 몇번 나왔었는데요.
그때마다 사람들은 대개 '맹목적인 신뢰'를 보여주는 경향이 있었습니다.
컨넥션풀을 위해서는 컨넥션풀 자체의 오버헤드도 계산에 넣어야 하는데, 그에 대해서는 별로 생각들을 못하더라구요.
특히나, 말씀하신 것처럼 mysql 은 접속에 부하도 작고, 속도도 무척 빠릅니다.
컨넥션풀이 아무리 오버헤드가 없어도, tcp 접속인 만큼 몇 ms 정도는 있게 마련입니다.
이런 상황에서는 , mysql 에서는 오히려 옥상옥 처럼 쓸모없는 부하만 될 가능성이 높다고 보여집니다.

말씀처럼 오라클이나... 그런 쪽은 '어쩔 수 없이 풀링을 해야하는 ' 상황이 되는 것으로 보이더군요.

정확한 것은 mysql, 오라클, 기타 db 에 대해 컨넥션 시간/부하를 측정후 db-pool  적용 여부를 결정해야 겠지만, 단순히 추정만 해도 님의 데이타와 비슷한 결과이리라 예상됩니다.
저는 항상 그렇게 말해왔는든데... 현실적인 데이타로 뒷받침이 되는 것 같아서 오히려 빙고 군요. ^^;
 
   루리   06-05-21 01:53  
일단 단순하게 성능으로는 높지는 않다고 보고 있고요.
그래서 어떤 다른 도음이 될 만한 부분이 뭐가 있을까 생각을 해봤습니다.

일단 풀링 기능으로 인해서 디비 접속 자체에 대한 부분이 안정화 되는 부분이 있을 것 같은데요.

쉽게 이야기 하자면 저 같은 경우 웹서버 4개에서 디비서버로 접속을 합니다.
디비 접속 에러가 나는 여러가지 중에 하나가 서버 하나가 과도한 부하를 먹어서 처리가 매우 늦어지는 경우가 있습니다.
그럴 경우 웹서버 한대가 디비접속을 모두 잡아벅고 그대로 누워버리는 경우가 있더군요.
처리를 빨리 못해주니 커넥션을 한서버에서 다 잡아먹고 그래서 웹서버 4대가 모두 디비 에러가 나버립니다.

커넥션 풀을 사용할 경우 각 서버에서 접속하는 커넥션 자체를 제한을 하기 때문에 위와 같은 경우라도 모든 서버가 커넥션 에러가 나는 경우는 없어지지 않을까 생각이 되는데요.
그리고 자료를 찾다보니 어떤 분이 쓰신 글에 Sqlrelay 가 부하를 잘 견딘다고 하더군요. 속도 자체는 늦어도 그래도 뻣지 않고 처리를 한다고요.
물론 설정에 따라 다른 부분이라고 생각이 되지만 영향이 좀 있지는 않을까 생각이 됩니다.

제가 ab 툴로 테스트 했을때 그냥 디비 접속때는 페이지 에러쪽에 다소 카운터가 올라 갔었습니다.

혹시 ab 툴로 테스트 할때 에러 페이지에 대한 정보는 어떻게 확인을 해야 되는지 아시는 분 있으신가요 ?

좀 정확하게 답이 나오면 제가 테스트 한 값도 올리고 싶은데요. 이거 ab 툴로 하다 보면 에러가 종종 뜨는데 무슨 에러 메세지였는지를 모르니 해석하기가 좀 그렇더군요. 
 
일단 단순하게 성능으로는 높지는 않다고 보고 있고요.
그래서 어떤 다른 도음이 될 만한 부분이 뭐가 있을까 생각을 해봤습니다.

일단 풀링 기능으로 인해서 디비 접속 자체에 대한 부분이 안정화 되는 부분이 있을 것 같은데요.

쉽게 이야기 하자면 저 같은 경우 웹서버 4개에서 디비서버로 접속을 합니다.
디비 접속 에러가 나는 여러가지 중에 하나가 서버 하나가 과도한 부하를 먹어서 처리가 매우 늦어지는 경우가 있습니다.
그럴 경우 웹서버 한대가 디비접속을 모두 잡아벅고 그대로 누워버리는 경우가 있더군요.
처리를 빨리 못해주니 커넥션을 한서버에서 다 잡아먹고 그래서 웹서버 4대가 모두 디비 에러가 나버립니다.

커넥션 풀을 사용할 경우 각 서버에서 접속하는 커넥션 자체를 제한을 하기 때문에 위와 같은 경우라도 모든 서버가 커넥션 에러가 나는 경우는 없어지지 않을까 생각이 되는데요.
그리고 자료를 찾다보니 어떤 분이 쓰신 글에 Sqlrelay 가 부하를 잘 견딘다고 하더군요. 속도 자체는 늦어도 그래도 뻣지 않고 처리를 한다고요.
물론 설정에 따라 다른 부분이라고 생각이 되지만 영향이 좀 있지는 않을까 생각이 됩니다.

제가 ab 툴로 테스트 했을때 그냥 디비 접속때는 페이지 에러쪽에 다소 카운터가 올라 갔었습니다.

혹시 ab 툴로 테스트 할때 에러 페이지에 대한 정보는 어떻게 확인을 해야 되는지 아시는 분 있으신가요 ?

좀 정확하게 답이 나오면 제가 테스트 한 값도 올리고 싶은데요. 이거 ab 툴로 하다 보면 에러가 종종 뜨는데 무슨 에러 메세지였는지를 모르니 해석하기가 좀 그렇더군요.
 
   초보대왕   06-05-21 02:37  
오라클 뿐만 아니라 그에 못지 않게 컨넥션 비용이 큰 MSSQL 도 가능하다면 커넥션 풀을 사용하는 것이 좋습니다. 이 경우 성능은 확실하게 좋습니다.  MYSQL 은 상대적으로 컨넥션 비용이 적어 컨넥션 풀을 사용할 것 까지는 없다고 해도 커넥션 풀을 사용하면 안정적인 면에서 높은 점수를 주어야겠지요. 따라서 MYSQL 이라 해도 접속자 수가 푹주하면 커넥션 풀을 사용하는 것이 바람직합니다.
그런데 sqlrelay 같은 커넥션 풀 라이브러리를 쓸 필요없이 FastCGI 를 쓸 것 같으면 이런 문제가 한꺼번에 해결됩니다. MYSQL 처럼 컨넥션 풀을 사용해야 하나 말아야 하나 하는 고민을 아예 할 필요가 없읍니다. FastCGI 에서는 코드 몇 줄 더 추가하면 컨넥션풀이 순식간에 구현이 되기 때문이죠. 좀 더 욕심을 내면 sqlrelay 보다 더 정교하게 할 수 있읍니다.
FastCGI 가 이렇게 강력한데 국내에서는 FastCGI 로 된 사이트가 전무한 실정입니다.
CGI 는 다소 있는데 말이죠 
 
오라클 뿐만 아니라 그에 못지 않게 컨넥션 비용이 큰 MSSQL 도 가능하다면 커넥션 풀을 사용하는 것이 좋습니다. 이 경우 성능은 확실하게 좋습니다.  MYSQL 은 상대적으로 컨넥션 비용이 적어 컨넥션 풀을 사용할 것 까지는 없다고 해도 커넥션 풀을 사용하면 안정적인 면에서 높은 점수를 주어야겠지요. 따라서 MYSQL 이라 해도 접속자 수가 푹주하면 커넥션 풀을 사용하는 것이 바람직합니다.
그런데 sqlrelay 같은 커넥션 풀 라이브러리를 쓸 필요없이 FastCGI 를 쓸 것 같으면 이런 문제가 한꺼번에 해결됩니다. MYSQL 처럼 컨넥션 풀을 사용해야 하나 말아야 하나 하는 고민을 아예 할 필요가 없읍니다. FastCGI 에서는 코드 몇 줄 더 추가하면 컨넥션풀이 순식간에 구현이 되기 때문이죠. 좀 더 욕심을 내면 sqlrelay 보다 더 정교하게 할 수 있읍니다.
FastCGI 가 이렇게 강력한데 국내에서는 FastCGI 로 된 사이트가 전무한 실정입니다.
CGI 는 다소 있는데 말이죠
 
   태미   06-05-21 13:58  
예 정말 국내에서는 FastCGI 에 대한 언급을 거의 찾을 수 없는 것이 안타깝습니다. 
 
예 정말 국내에서는 FastCGI 에 대한 언급을 거의 찾을 수 없는 것이 안타깝습니다.
 
   낭망백수   06-05-22 10:31  
초보대왕 // FastCGI 로 작성된 커넥션 모듈을 말씀하시는 건가요?
꾸벅~! 
 
초보대왕 // FastCGI 로 작성된 커넥션 모듈을 말씀하시는 건가요?
꾸벅~!
 
   Mineinandout   06-05-24 07:32  
대형 포탈에서도 APM하에서 db pool을 많이 사용하는지는 잘모르겠습니다..
제가아는 곳은 mysql에 대해 sqlrelay같은 db pooler를 전혀사용 하지 않습니다.
그만큼 mysql connection resource가 적게 들어가는 것도 있을테고 대부분 장비로 때우기 때문일지도
모릅니다.
전 지금 sqlrelay + oracle 땜시 무척 고생하고 있지만 mysql에서라면 속도보단 신뢰도를 위해 sqlrelay를
쓰게 될것 같습니다. 느려질망정 too many connection 보단 나은 경우 말이죠.
여담으로 php oci  + oracle 보단 sqlrelay + oracle은 많은 속도 향상이 있습니다.(ab테스트결과)
혹 0.37버전이신가요? 0.34이하와는 많은 성능차이를 보이더군요. 
 
대형 포탈에서도 APM하에서 db pool을 많이 사용하는지는 잘모르겠습니다..
제가아는 곳은 mysql에 대해 sqlrelay같은 db pooler를 전혀사용 하지 않습니다.
그만큼 mysql connection resource가 적게 들어가는 것도 있을테고 대부분 장비로 때우기 때문일지도
모릅니다.
전 지금 sqlrelay + oracle 땜시 무척 고생하고 있지만 mysql에서라면 속도보단 신뢰도를 위해 sqlrelay를
쓰게 될것 같습니다. 느려질망정 too many connection 보단 나은 경우 말이죠.
여담으로 php oci  + oracle 보단 sqlrelay + oracle은 많은 속도 향상이 있습니다.(ab테스트결과)
혹 0.37버전이신가요? 0.34이하와는 많은 성능차이를 보이더군요.
 
   루리   06-05-24 10:46  
테스트는 0.37 버전으로 했습니다. 크게 차이가 나지 않는다면 에러보다는 조금 느린 것이 좋겠죠.
테스트로는 그정도 선에서 만족하는 수 밖에는 없을 것 같네요.

테스트 하다 이상한 것을 발견했는데요.

mysql 5.0.21 버전에서 유닉스소켓이 아닌 네트웍으로 붙을 경우 속도 열하가 심하게 나네요. 특별히 세팅을 바꾼 것은 없고 그냥 얼마나 차이나는지 확인 해보려고 한 것인데 엄청나게 느려지네요. 4.x 대 버전은 그렇지 않은데요.

제 컴터 문제인지... 5.X 버전의 문제인지...