| [ CnUnix ] in KIDS 글 쓴 이(By): belami (__커피__) 날 짜 (Date): 2002년 3월 21일 목요일 오전 01시 35분 13초 제 목(Title): Re: RAW Socket TCP/IP 예제프로그램좀요~ 달랑 숫자 하나를 말씀드리니 좀 모호한 면이 없지 않은 것 같습니다. 세 가지 정도 말씀드리겠습니다. **** 우선 질문에 대한 답변부터 드리면요. Apache의 최대 개수 250은 적은 숫자가 아닙니다. 2000 ~ 3000 명 정도가 붙어도 300 ~ 400개의 아파치이면 충분할 정도로 250은 큰 숫자입니다. 이 숫자가 부족해지게 되는 것은 보통 KeepAliveTimeout 튜닝을 하지 않은 결과입니다. 그걸 줄여주는 튜닝을 하면 Apache 250개는 1천명 이하 규모의 기업에서는 모자랄 리 없습니다. Apache는 느린 WAN에서 최적화 한 값인 15를 쓰고 있죠. 안전빵을 위해서 아파치 개수를 400, 600으로 늘려주기도 하지만 그건 안전을 위해서지요... 미처 뒷쪽을 튜닝할 여유가 없다면 Apache라도 늘려서 접속 에러를 없애야지 어쩌겠어요. 수만 개의 연결에 대해서는 쫄 필요 없습니다. 그것은 사고가 일어난 경우를 얘기하는 것입니다. 그런 정도로 많은 TCP 엔트리가 서버에 존재하도록 놔두는 것은 어드민이 어찌해야 할지 몰라서 방치하는 '사고'입니다. 한 마디로 제대로 된 상황이 아닌 비정상적인 케이스입니다. 가장 피크시에도 서버당 많아도 수천 개의 TCP 연결 세션, 그것의 약 2~3배의 TCP 엔트리(TIME_WAIT 포함)를 유지하는 것이 적정 상한선입니다. 기계와 OS를 불문하고 이 정도가 한계선으로 생각해야 합니다. Solaris 같은 경우는 TCP 연결의 최대 개수가 기본 12만개인데 그걸 늘려주는 튜닝을 하기도 하는데 그런 것은 보통 tpmC를 측정할 때나 하는 튜닝이고, 보통은 거꾸로 엔트리의 수를 줄여주는 TIME_WAIT 줄이기 튜닝을 하는 것이 적절한 선택입니다. 그리고 님의 어플이 동시 30개를 버티느냐 동시 70개를 버티느냐는 중요한 지표가 아닙니다. 그보다는 단위 시간당 몇 개가 처리되느냐가 중요합니다. 즉 tpm 말이죠. 트랜잭션의 퍼포먼스가 낮아서 tpm이 낮으면 메모리와 CPU를 더 꽂아서라도 동시 트랜잭션 수를 늘려주어야 합니다. 그럴 때는 동시 트랜잭션의 수가 늘어나게 되지요. 요구되는 tpm을 만족시키기 위해 필요한 동시 트랜잭션의 수가 크다면 그건 안 좋은 상태이지요. 동시 db 트랜잭션 수를 많이 지원한다고 광고하는 회사는 '우리 프로그램 느려요'하고 광고하는 것과 같기 때문에 그런 얘기하는 회사는 없습니다. 도대체 몇 개의 DB 세션으로 하는 것이 적당한 것인가가 먼저 궁금하시다면, 경험적으로 시작하기 좋은 수치는 20 ~ 30입니다. 일단은 여기까지가 간단한 답변입니다. **** 왜 20 ~ 30 정도이면 충분한 정도인지를 말씀드리려면 실제 일어나는 상황에 대한 좀 장황한 얘기를 해야 하는데요. 필요한 tpm을 정의한 후 그것에 맞추어 시스템 설계를 하시면 됩니다. 필요한 tpm은 비즈니스 요구에서 나옵니다. 보통은 오전의 10분 정도의 순간 피크는 견디어 주어야 하기 때문에 오전 피크 10분에 도대체 몇 사람이나 일을 하고 있을 것인가를 세고, 시스템이 단위 시간당 몇 개의 트랜잭션을 처리할 수 있는지를 세어서 범위 안에 들어가는가를 살펴야죠. 일반 인터넷 사이트의 경우에는 등록 사용자의 1/50 이하가 로그인을 하여 사용하며, 기업의 인트라넷의 경우에는 10% ~ 50% 정도가 로그인을 하여 사용합니다. 피크시 로그인 사용자의 10 ~ 30% 정도가 concurrent 트랜잭션을 일으킵니다. 그래서 님의 시스템이 약 2 tps(120 tpm) 정도를 지원한다면 님의 시스템은 로그인 사용자 20 ~ 60명 정도의 규모에 알맞습니다. 기업 규모는 200 ~ 600명 정도의 건설회사에 알맞겠네요. (왜 건설회사냐면요.. 다들 나가서 일하고 실제 로그인 하는 사람은 별로 없는..) 지표를 가졌으므로 지원하려는 사용자 규모와 산업 특성을 알고 있으면 시스템이 얼마나 되는 tpm을 내야 하는지 알 수 있습니다. 대략 1000명짜리 건설회사를 감당하려면 미니멈 10 tps (600 tpm)는 내야 합니다. 대략 1000명짜리 은행을 감당하려면 미니멈 30~50 tps (1800 ~ 3000 tpm)정도 내야 합니다. 거꾸로 이야기하면 1000명짜리 건설회사는 100 ~ 500명 정도가 로그인을 하고 그 중 concurrent 클릭의 수는 동시 10명 ~ 50명 정도 된다는 얘기입니다. (물론 상황은 매 기업마다 다르므로 좀 더 넉넉한 수치를 가정하는 것이 안전합니다.) 장황하게 얘기했는데 여기에서 100이라는 숫자가 나옵니다. 이렇게 동시 클릭의 수는 10 ~ 50 정도밖에 되지 않으므로 그에 상응하는 정도의 동시 트랜잭션이 필요합니다. 그에 비해 상당히 큰 숫자인 100 정도를 설정해야 할 일은 드문 것입니다. 그런데 위에서 얘기한 100이라는 숫자는 1000명일 경우의 안전한 상한선의 예일 뿐이지 않는가라고 말씀하실 수도 있습니다만, 벤더별 통용되는 기계당 적정 로그인 사용자수의 규모는 800 ~ 1000명을 넘지 않습니다. 그래서 100이라는 숫자는 매우 충분하며, 대부분의 경우에 50개로 충분하고, 보통은 20~30개로도 충분하다고 얘기하는 것입니다. 사용자수가 그 기준을 넘어도 물론 동작은 하고 어떨 때는 충분한 것처럼 보이기도 합니다만, 곧 이런저런 병목이 멀티플로 나타납니다. cpu 해결하면 memory 부족, 그거 해결하면 disk 병목, 그거 해결하면 web server, ..., 이거저거 다 해결하고 나면 사용자들이 익숙해져서 더더 많이 사용해서 사용량이 늘어나서 병목 ... 앞 글에서도 얘기했지만 현재까지는 가장 빠른 disk 시스템인 raid 0 disk array를 쓰더라도 볼륨당 concurrent 액세스 수가 수십 정도밖에 안되기 때문에 3000 ~ 4000명이 붙어서 concurrent 트랜잭션을 수백개씩 일으켜봤자 기계만 뻗어버립니다. 이 쓰레드의 첫 글인 netstat 10만개 현상 비스무리 한 것이 나타나기 때문이죠. 기계당 2000명이 로그인 할 필요가 있다 해도 어쨌거나 동시 세션이 100개까지 필요한 것은 아니라는 말이죠. 일반 인터넷 사이트라면 그것의 5 ~ 10배 이상의 사용자 규모를 지원하는 것으로 보면 됩니다. 사용자 규모 대비 요구 tpm을 계산해야 하고, 시스템의 지원 가능 tpm을 측정해야 함을 말씀드렸습니다. 이제 문제가 단순해져서 몇 tpm을 지원하면 되는지만 알면 되고, 따라서 목표도 tpm을 올리는 것으로 할 수 있습니다. 이제 당장 Stress Test를 하러 가실 때 주의하실 점이 있습니다. Lab에서 테스트하는 것은 실제 상황을 반영하지 못하는 경우가 너무나도 많습니다. 실제 상황에서는 다양한 데이터에 액세스 하기 때문에 디스크/메모리 캐시 효율이 낮아지므로, Lab에서 목표 tpm을 만족시켰다고 실 가동 시스템에서 그럴 것이라고 가정하는 것은 바람직하지 않습니다. Stress Test라고 하는 것은 실제 상황을 매우 단순화한 형태이기 쉽기 때문이죠. **** 이제 마지막 단계는 어플의 최고 성능의 한계치는 어디일까를 추정해보는 것입니다. 내가 만든 어플의 성능이 테스트베드에서 10 tps가 나온다고 할 때 실제 가동할 기계에서는 얼마나 나오게 될지 궁금할 경우가 있을 것입니다. 그럴 때 사용할 수 있는 참조지표가 있습니다. 벤더마다 기계에 대한 tpmC 수치를 발표합니다. 이 tpmC는 '있을법한' 어플을 설계한 후 '있을법한' 사용자 액션을 적당히 비율로 정한 후 그런 액션을 골고루 서버로 날려서 20분간의 평균을 수치로 냅니다. (그런 어플은 tpmC에 정해져 있고, 비율도 정해져 있습니다.) 님의 어플의 tpm을 구하고 어플을 돌린 기계의 tpmC를 추정하고, 타겟 기계에서의 tpmC를 추정하면, 비례식으로 님 어플의 타겟 기계에서의 tpm을 추정할 수 있겠지요. tpmC를 추정하는 이유는... 보통 타겟 기계의 tpmC를 잘 모르는 경우가 많기 때문입니다. 기종별 최고 사양의 tpmC는 발표됩니다만... 그 구성이 너무 다양할 수 있으므로 모든 구성에 대한 tpmC 표는 구하기 어렵습니다. 그래도 기계 벤더에 물어보면 알려줍니다. 여기까지 읽으셨다면 ... 읽느라 고생하셨습니다. |