동시접속자 20,000명 정도의 서버구성에 대해 조언구합니다.

Astronaut   
   조회 44526   추천 0    

인서트와 where 절에 의한 셀렉트가 주가되는 텍스트로만 구성된 사이트 입니다

nginx, php-fpm, mariadb + 캐쉬(멤캐쉬, 액셀, 젠드옵 등등) 한세트이며, HTTP 통신에 SSL 을 사용해야만 합니다.

php 프로그램 부하 수준은 한페이지당 보여지는 목록수가 150개정도 되는 게시판이라고 생각하면 될것 같습니다.

지금 생각으로 제온 1230, 32G 메모리, sata3 레이드.. 또는 DB 쪽만 삼성SSD.. 이런식으로 일반 PC 부품으로 저렴하게 구성하려고 합니다.

가상화로 웹서버 디비서버 나누고 앞단에 LVS 둬서 같은 사양 서버 2대로 동접 2만을 견딜 수 있을까요?

회선은 텍스트로만 구성된사이트라 많이는 필요 없을것 같습니다.

많은 동접자에 대한 경험이 전무해서 질문드립니다. ^^; 

이정도 사양으로 옵티마이징 하면 몇명까지 견딜지 감이 안접혀 대강의 숫자만이라도 알고 싶습니다.
짧은글 일수록 신중하게.
AKs 2014-01
동시접속자에 대한 명쾌한 답은 없습니다.
케이스바이케이스이기 때문에며, 실측후 사이징 해야 됩니다.
허름한 컴퓨터라도 하나 테스트머신으로 놓고 테스트 한 다음, 그 결과를 보고 사이징 하시는게 옳습니다.
     
황창석 2014-01
가장 확실한 방법이겠죠.. 개발 초기인데 대강의 하드웨어 요구사항만 알아도 안심이 될것 같아서 조급하게 질문글 올렸네요 ㅎㅎ  자본이 부족해서 IDC 들어갈 여력이 안되는지라 ㅠㅠ 답변 감사합니다!
회원K 2014-01
통상적으로 부하가 많이 걸리는 DB서버는 가상화 하지 않습니다.
disk access의 속도를 확실하게 보장할 수 없기 때문이고, CPU 부하고 상당하기 때문입니다.
동접 2만이라면, nginx에 무엇을 해도 기본적으로 DB서버와 웹서버를 분리해야 합니다.
그리고 웹서버단에서 가상화를 해서, 웹서버를 복수의 서버팜으로 만들어야 할 것이구요.
이때... DB서버는 더 높은 CPU, 다 강력한 ssd를 쓰고, 웹서버단은 그 것보다 조금 낮게 하면 됩니다.
     
황창석 2014-01
정말 고맙습니다. DB 단의 부하가 높을거라 생각은 했는데 가상화에서 디스크 액세스타임 낭비가 생기는군요. 게다가 말씀대로 하면 스케일링시 하드웨어 계산도 수월할것 같네요. 마리아 클러스터의 성능이 좋기를 기도해야 겠습니다. ㅎㅎ 보통 웹서버 가상화는 한피시에서 몇개를 해야 효율이 좋을까요?
          
회원K 2014-01
웹서버는 별로 부하가 안걸리고, 서버 1대당 처리용량이 os의 한계로 어느정도 제한적입니다.
E3급이라면 메모리 4-8G를 기준으로 서버 1개를 가상화 하면 되고 32G램이라면 4-5개 정도인데
램이 많이 들어갈 수 있는 5500 계열을 쓰는 것이 가성비는 더 나을 수 있습니다.

DB는 고속처리를 원하시면 클러스터링을 하지말고 single db로 대응하시고,
만일을 위해서 slave replication만 하시면 됩니다.

아파치 2.4.x 버젼이면 그렇게 nginx와 차이 나지 않습니다.
그래서 머리 아프게 nginx 안씁니다.

마지막으로 한마디 더 붙이면 동접 2만이면 text 베이스라고 해도 트래픽이
300mbps에서 1Gbps 가쁜하게 나옵니다.
회선비만 월 500만원 이상을 각오해야 하고 조금 더 나오면 월 천만원인데
E3 같은 저가형 서버로 가야하는지 생각해봐야 합니다.

회선비를 월 천만원 쓰면서, 서버를 100-200 정도 쓴다는 것은 아닌 것 같습니다.
               
황창석 2014-01
일단 초기엔 가정용 기가랜 2회선을 사용할까 합니다; 말씀하신대로 회선 비만 그렇게 나오니 도저히 감당이 안되서요.. 수직적 업그레이드 보단 수평적 업드레이드가 스케일링이 더 나을 것 같은데 DB 쪽 구성은 고민을 좀 더 해봐야 겠네요. nosql 쪽 경험이 없어서 디비를 바꾸면 개발기간이 길어질듯.. 웹서버는 뭐든 성능만 더 나오면 괜찮습니다 ㅎㅎ 아파치나 nginx 나 비슷하군요! 답변 감사합니다!!
AKs 2014-01
답변 드리고 나니 가상화 부분을 아예 못봤네요..
가상화는 CPU파워가 남아도는 상황에서 이것저것 하려고 하니까 하는거지 풀로드 걸어도 모자랄 상황에서의 해답은 아닙니다. (다른 이유는.. 어플리케이션이 멀티 CPU를 지원하지 못하기 때문에 여러대 만들어서 분산해야 하는 경우에도 좋은 해결 방법입니다.)
지금 황창석님의 상황에서는
1. 대충 PC하나에 DB와 웹을 얹어서 돌려보고
2. 사이징을 적절히 하는데.. 디비서버는 내가 할 수 있는 최상의 제품으로 구매하고
3. 웹서버는 저렴하게 구성해서 늘려나가는 방식이 효과적입니다.
이때 효과적인 웹서버의 부하분산을 위한 방법도 고려하셔야 합니다. L4를 사용하는것도 나쁜 방법은 아니지만, 게이트웨어(?) 목적의 서버를 하나 두고 최초의 접속은 모두 그 서버가 받은 뒤 부하가 적은 서버로 사용자를 보내는 것도 효과적인 방법 중 하나 입니다.
특히 DNS라운드로빈을 이용하는 방법은 사용자가 특정 서버로 몰리는 경향이 발생하기 때문에 추천하지 않습니다.
     
황창석 2014-01
항상 디비가 부담이군요. L4 가 너무 비싸서  LVS 로 대체하려고 합니다. 가상화는 스냅샷에 의한 백업 및 복구가 편해서 사용하려 했는데 라이센스 문제 + 성능상의 손실이 있으니 이것도 더 고민해 봐야 겠군요.. 일단은 말씀대로 최대한 빨리 개발완료하고 테스트 해봐야 겠습니다. 이러다 node.js, nosql 안썼다는 후회가 들까봐 불안하긴 한데 개발기간이 더 길어지니 그냥 다루던 툴로 고고씽해야 겠습니다. 답변 고맙습니다!
          
AKs 2014-01
LVS.... 정답일 수도 있고.. 아닐 수도 있지요..
DB부하가 큰 경우, H/W scale-up/out 방식으로는 답 안나옵니다. 2만명 정도가 Access할 정도면 2만회의 DB Access를 처리할 정도로 DB서버 스펙을 올릴 것이 아니라, 쿼리 유형을 정비하여 2만회의 DB Access를 수백회의 Access로 줄이도록 DB를 튜닝하시는게 더 도움이 됩니다. SNS처럼 Update가 전혀 없거나 거의 없는 경우, RDB가 아닌 다른 형태의 DBMS도 검토해 보시는게 좋습니다.

Where 조건절의 유형별로 Select Query의 I/O Load가 얼마나 걸리는지 실행계획 돌려보시고,
PK아닌 Column으로 join이나 where절 사용이 빈번하면 실행계획에 따라 적절한 인덱스 생성해주시고,
거래처리 목적의 단일 테이블이 대형인 경우, Insert와 가장 빈번한 유형의 Select에 적절하게 Partitioning 하시고,
Where 조건절 사용 목적이 Group by인 경우 table lock이 빈번한 것으로 파악되면, trigger를 걸어 다른 테이블에 원하는 형태의 데이터를 집계하는 등 별도 가공 테이블을 select 하시는 편이 좋습니다.

그리고, maria db는 mysql 에서 파생되기는 하였으나, 아직 oracle이나 ms-sql/mysql 처럼 대용량 transaction 처리에 대한 충분한 가용성이 입증된 DBMS는 아닙니다.
     
황창석 2014-01
말씀대로 NO SQL 을 진지하게 고민하고 있습니다. 그냥 RDBMS 를 쓰면 스케일아웃도 그렇고 튜닝이 더 어려워질것 같습니다. 여러 nosql 를 알아보고 있는데 네이버가 쓰는 레디스, HBASE, 다음이 적용한 카산드라.. 모두 수평적 확장은 용이한데, 데이터의 동시성문제가 있는 것도 있고, 레디스 같은 메모리 DB 의 경우 속도는 최강이나 메모리 보다 큰 데이터는 디스크 액세스로 성능이 저하되는등.. 모두 생소해서 뭘 선택해야 할지 머리가 지끈거립니다. 일단은 디자인 제외하고 익숙한 sql 디비로 빠르게 개발후 테스트결과 확장성과 성능이 비례 하지 않는다면 넘어갈 생각으로 가닥을 잡는중입니다. 답변 감사합니다!
AKs 2014-01
정적 컨텐츠가 많으면 reverse proxy도 생각해 보세요. 좋은 선택일 수도 있습니다.
     
황창석 2014-01
감사합니다. js, css 및 html 페이지를 reverse proxy 로 적용하면 좋겠군요. 보안이슈도 어느정도 방어 된다고 하니.. 구성의 복잡도는 올라가는군요 ㅠㅠ
회원K 2014-01
동접 2만이 걸리는 사이트의 DB Disk라면 싸구려(MLC/TLC) ssd로 6개월 버티기 쉽지 않을 것이고
가정용 회선이라도 지속적으로 100mbps 이상의 upload가 발생하면 차단될 수 있습니다.

가정용 회선의 의미는 통상적인 개인사용을 하라는 것이지, 집에서 서버를 돌리라는 것은 아닙니다.
     
황창석 2014-01
음.. 토렌트 돌리는 헤비업로더의 경우에도 차단이 되나요? 가정용 회선을 못쓰면 답이 없습니다;
          
박문형 2014-01
가정용회선도 전체를 놓고 보면 트래픽 요금을 내는 것인지라 헤비 업/다운은 차단되기 쉽습니다.

가장 중요한 것이 서버 구성보다 회선료 문제네요.
          
노리 2014-01
데이타 사용량이 많으면 업체에서는 그 지역에 라인이 문제 생기므로
1차로는 블랙 리스트 처리후
순단현상을 일으키는 업체도 종종 있습니다.

블랙리스트에 올른 1유저를 유지하느니
차라리 일반적으로 사용하는 사용자들을 위해서 이를 차단 하는게 답일 테닌까요.

가정용 회선은 기업용 회선이 아닙니다.

다 용도에 맞는 금액이 있는 이유기도 하죠.



사람들은 보통 이점을 망각합니다.
씬건 싼 이유가 있고
비싼건 비싼 이유가 있다는 것을......


ps.
참고로 딴 얘기긴 한데 요즘 kt가 가정용 회선도 기가라인 시작했다죠?
idc아직도 기가 회선 사용하는 사용잔 거의 없는데
뭔가 뒷 속내가 있는 상품 아닐까 생각해 봅니다.....
               
박문형 2014-01
1기가 회선 나온지는 몇년 되었습니다.(가정용이던 기업용이던)

아직 지원하는 곳이 적어서 문제고 한 가격하고 일반 공유기가 못버팁니다.
          
토렌트는 TCP/UDP 혼합에 Port도 random이라 단순 패턴으로는 검출 및 선택적 차단이 복잡합니다.
반면 WAS나 DB는 아시다시피 일정한 패턴으로 운영되니 쉽게 검출됩니다.
     
노리 2014-01
강윤호님이 정확히 찝어 주셨네요.

이런 얘기가 있더군요.
ssd를 쓸꺼냐 sas 15k를 쓸것이냐의 고민인데요.

속도라면 당연히 ssd가 더 빠르겠지만
사용 용도로 볼때
slc만이 답이나 가격적인 면에서.....

약간은 속도가 느리더라도
장기적인 유지비를 따진다면 sas가 답일듯...

물론 속도를 따진다면 ssd

하지만 ssd도 안정성을 위해 레이들 걸어버리면
컨트롤러가 아직 ssd용은 없죠?

이런 결과라면...

잘 생각하시고 결정하시기 바랍니다.



저도 data 영역부터 모든 하드를 ssd로 갈까 하다가
아직도 고민만 하고 있네요....

안정성이냐 속도냐..

하지만 작은 파일이 많이 생성 삭제 될꺼라면 아직 ssd는 답이 아닌듯 합니다.
이장원 2014-01
사이트 열자마자 동시접속자 2만명이 바로 생기나요? 그렇지 않다면 스케일 아웃이 가능하게 구조를 잡고 사용자가 늘어나면 서버를 확장해도 됩니다.
     
황창석 2014-01
아닙니다 ^^; 현재 저렴한 하드웨어로 스케일 아웃이 용이하도록 구성하는데 생각을 집중하고 있습니다. 감사합니다!
이장원 2014-01
Scale PHP on Ec2 to 30,000 Concurrent Users / Server

https://coderwall.com/p/__z9ia
김동수P 2014-01
집에서 서버 빡세게 굴리면 KT에서 실사 나오고, 실사 거부하면 회선 철거해갑니다.
(서브넷 구성 안하는 경우는 모르겠습니다.. 보통 서버 돌리게 되면 서브넷 구성이 필수불가결해서..)
U+ 오피스넷이 그런점에서는 좀 합리적이고 아주 저렴합니다.
     
회원K 2014-01
사무실에서 다운로드 좀 빡세게 받으면 바로 회선이 차단 되고
내가 접속했던 회사 사이트까지 스패밍 처리를 해버리더라구요.


QnA
제목Page 5158/5717
2014-05   5203743   정은준1
2015-12   1736330   백메가
2005-02   6737   이진관
2011-06   7820   정병곤임돠
2005-02   7338   김장원
2019-10   3025   여수I완스
2011-06   7121   아크백작
2005-02   7358   우승엽
2019-10   3962   향칼
2013-12   4867   오재호
2005-03   6403   이창섭
2016-06   7297   허인구마틴
2018-08   4451   으라차차차
2017-05   3593   neomouse
2005-03   6977   최원식
2018-08   3634   알선업체
2021-01   2599   꺄울
2022-08   1262   EYESSHOT
2007-12   5357   김재민
2015-04   3353   방o효o문
2015-04   7102   witbox
2005-03   11318   최완규