실제로 원아웃, 원인 방식에 대한 장점을 찾을 수 없었습니다. 간단히 말해, 이 접근 방식의 문제점은 사용자가 이커머스 웹사이트 방문자인 경우 웹서버가 특정 시점의 동시 사용자 수를 알 수 없다는 것입니다. 이는 정말 심각한 문제입니다. 그 이유는 다음과 같습니다.
이 글의 뒷부분에서는 요금 기반 가상 객실을 사용하여 사이트를 보호하는 방법도 설명합니다.
실제로 원아웃, 원인 방식에 대한 장점을 찾을 수 없었습니다. 간단히 말해, 이 접근 방식의 문제점은 사용자가 이커머스 웹사이트 방문자인 경우 웹서버가 특정 시점의 동시 사용자 수를 알 수 없다는 것입니다. 이는 정말 심각한 문제입니다. 그 이유는 다음과 같습니다.
이 글의 뒷부분에서는 요금 기반 가상 객실을 사용하여 사이트를 보호하는 방법도 설명합니다.
일반적으로 이커머스 서버는 최대 동시 사용자 수를 지원하도록 프로비저닝되며, 이러한 방식으로 부하가 정의되는 경우가 많습니다. 이러한 접근 방식을 사용하여 웹사이트의 대기열을 실행하는 데는 문제가 있는데, 이 문제는 요금으로 해결합니다.
방문자는 브라우저가 각 웹 페이지를 로드하는 동안에만 웹서버를 실제로 사용하기 때문에 문제가 발생합니다.
예를 들어 이커머스 사이트에서 티켓을 판매한다고 가정해 보겠습니다. 방문자 여정의 시작부터 방문자 여정의 끝(사용자 세션)까지 방문자에게는 다음과 같은 6개의 페이지가 있습니다.
전체 거래 프로세스는 평균 5분이 소요됩니다.
예를 들어 매분 100명의 방문자가 티켓을 구매하기 위해 도착하고 프로세스를 완료하는 데 걸리는 평균 시간이 5분이라고 가정해 보겠습니다. 특정 시점에 500명이 동시에 트랜잭션 프로세스를 진행 중이며 서버는 500명의 동시 사용자를 지원할 수 있도록 프로비저닝되어야 합니다.
새 방문자가 홈페이지에 도착할 때마다 증가하고 방문자가 트랜잭션을 완료할 때마다 감소하는 동시 사용자 카운터를 생성하여 단일 서버가 한 번에 처리하는 사용자 수를 알 수 있다고 생각할 수 있지만 이 방법은 작동하지 않습니다.
모든 방문자가 거래를 완료하는 것은 아니기 때문에 효과가 없습니다. 사람들은 마음이 바뀌거나 주의가 산만해지거나 잠시 자리를 비웠다가 나중에 다시 돌아올 수 있습니다. 웹서버는 브라우저가 페이지를 로딩할 때만 방문자와 상호 작용하기 때문에 웹서버는 이런 일이 언제 발생했는지, 누구에게 발생했는지 알 방법이 없습니다.
대신 방문자가 더 이상 트랜잭션 프로세스의 일부가 아닌지 확인하기 위해 단일 서버는 해당 방문자로부터 더 이상 페이지 요청이 도착하지 않는지 기다린 다음 해당 방문자의 세션을 시간 초과해야 합니다. 일부 방문자는 트랜잭션을 완료하는 데 다른 방문자보다 훨씬 오래 걸리므로 시간 초과를 항상 평균 트랜잭션 시간보다 훨씬 길게 설정해야 합니다(예: 이 예제에서는 20분).
이러한 방식으로 방문자 세션이 시간 초과될 때마다 개념적 동시 사용자 카운터를 감소시키는 기능을 추가할 수도 있지만, 이렇게 하면 결과가 매우 좋지 않습니다.
매분 도착하는 100명의 방문자 중 10%가 거래를 완료하지 않는 경우, 거래를 완료한 방문자는 평균 5분 동안 활성 상태이고 완료하지 않은 방문자는 항상 최소 20분 동안 활성 상태로 간주됩니다(실제로 여러 세션을 고려할 때는 세션 시간 초과에 평균 세션 기간을 더한 값이 더 높습니다).
즉, 90 * 5 + 10 * 20 = 650이며, 서버는 실제로는 덜 바쁘지만 동시 사용자 수가 650명이라고 보고합니다!
또한, 동시 접속자 중 10 * 20 = 200명 정도는 실제로 사이트를 사용하지 않고 시간 초과 중이며, 이는 보고된 동시 접속자의 30%가 넘는 수치로, 거래를 완료하지 못한 방문자는 10%에 불과합니다.
이제 동시 사용자 카운터로 제어되는 이 웹사이트에 대기열을 추가하고 싶다고 가정해 보겠습니다. 사이트가 수용 인원에 도달하면 대기열의 맨 앞에 있는 사람은 카운터가 감소할 때만 사이트로 전달됩니다. 이를 원아웃-원인 대기열이라고 합니다. 이렇게 되면 30%의 경우 대기열 맨 앞에 있는 사람이 거래를 완료하지 않을 사람이 거래를 완료하지 않을 때까지 기다리게 됩니다.
또한 카운터를 생성 및 실행하고 해당 정보를 대기열 시스템과 공유하는 웹사이트에는 추가적인 기술 통합 작업과 부하가 발생합니다. 공유 또는 카운팅 메커니즘이 다운되거나 중단되면 대기열이 중단됩니다. 더 큰 문제는 단일 서버가 너무 바빠서 대기열 서버에 다음 사람이 들어올 수 있도록 대기열 서버를 업데이트할 수 없는 경우 대기열도 중단된다는 것입니다.
이 모든 문제는 대기열 앞쪽에서 방문자를 일정하고 고정된 속도(이 경우 분당 100명)로 전송하면 쉽고 간단하게 해결할 수 있습니다.
이렇게 하면 실제 동시 사용자 수를 측정할 필요도 없고, 티켓팅 웹사이트와 복잡하게 통합할 필요도 없으며, 대기열이 정체될 위험도 없습니다.
이것이 바로 2004년에 바쁜 웹사이트를 위한 요금 기반 가상 대기실을 발명하고 특허를 받은 이유입니다.
‘훌륭해요!!! Queue-Fair는 매우 잘 작동했고 지원도 매우 훌륭했습니다. Queue-Fair는 많은 사람들이 프로젝트에 액세스하는 문제를 해결해 주었고 서버 충돌을 방지해 주었습니다. 앞으로의 프로젝트에서도 Queue-Fair를 계속 사용할 계획입니다. Queue-Fair 감사합니다!!!’
‘훌륭한 도구가 저희 가게를 구했어요. 고객 서비스도 매우 훌륭합니다. Queue-Fair는 바쁜 티켓 판매 시 서버 포화 문제를 해결해 줍니다. 설정이 쉬웠고 도구의 효율성도 마음에 들었습니다.’
‘커뮤니케이션이 정말 원활했고 모든 것이 잘 작동했습니다. 캠페인은 성공적이었고 서버는 항상 정상적으로 작동했습니다! 기술적인 측면과 고객 측면 모두에서 모두 효과가 있었고 긍정적인 피드백을 받았습니다. Queue-Fair에 문의해 보시길 추천합니다! 문제에 대한 해결책을 찾게 되어 기쁩니다.’
‘비용 대비 높은 가치와 사용하기 쉽고 매우 좋은 제품, 구현 및 사용이 쉽습니다. 다양한 웹사이트와 페이지에 적용할 수 있으며 고객 서비스도 매우 훌륭합니다. 중요한 티켓팅 이벤트가 시작되는 동안 웹사이트에 스트레스를 주지 않도록 대기실을 관리합니다. 추천합니다!’
‘인기 극장 공연의 티켓을 한꺼번에 구매하려는 사람들이 한꺼번에 몰리자, Queue-Fair는 서버를 보호하기 위해 완전히 브랜드화된 가상 대기실을 마련했습니다. 이 서비스를 찾게 되어 매우 기쁩 니다. 전체 컨셉과 유연성이 매우 마음에 듭니다. 감사합니다, Queue-Fair!’
‘꼭 필요한 기능이었어요! 피드백이 정말 좋았고 Queue-Fair는 우리가 필요로 하는 방식으로 작동했습니다. 대규모 티켓 판매에 수천 명이 새로 고침을 누르는 경우 안전망이 필요합니다! 데이터베이스 문제나 화난 고객을 처리하는 데 드는 비용에 비해 Queue-Fair를 사용하는 데 드는 비용이 훨씬 저렴합니다. 저희는 정말 만족하고 있습니다!’
‘한 번에 많은 사람들이 웹사이트를 방문하는 인기 있는 이벤트가 있습니다. Queue-Fair는 이를 관리하고 문제를 해결하는 데 도움이 됩니다. 설정 중 지원과 사용 편의성이 가장 마음에 들었습니다. 다른 대기열 제공업체에 비해 뛰어난 지원을 제공하는 훌륭한 대안이기 때문에 Queue-Fair를 추천합니다.’
‘그냥 작동합니다! 올해 들어 가장 수월한 런칭이었어요. 주요 제품 4종이 매진되었고 예상보다 20% 더 많은 수익을 올렸습니다. 대기열 시스템 덕분에 사람들은 쇼핑할 시간이 더 길어졌다고 느끼면서 다른 품목을 장바구니에 추가했습니다. 출시 과정을 실시간으로 지켜보면서 향후 제품 출시에 대한 중요한 인사이트도 얻었습니다.’
‘성공!!! 어제는 너무 순조롭게 진행되어 고객이 울었습니다. 말 그대로요. 정말 환상적인 경험이었습니다. 놀라운 지원. 최종 사용자에게 탁월한 경험을 제공한 놀라운 제품. 사용자가 가상 대기실로 들어와서 사이트로 이동하여 성공적으로 구매하는 과정을 Queue-Fair 대시보드에서 지켜보면서 제 고객은 감격했습니다.’
‘블랙 프라이데이를 위한 솔루션이 필요했습니다! Queue-Fair는 저렴한 가격과 우수한 고객 서비스를 제공하면서 이번 행사에 필요한 솔루션을 기꺼이 제공했습니다. 저희는 개인화된 대기 페이지 룸과 입장 요금을 모두 저희의 필요에 맞게 설정할 수 있었습니다. 주머니를 비우지 않는 맞춤형 솔루션이 필요하다면 Queue-Fair를 추천합니다 !’
‘수요가 많은 이벤트 출시에서 모든 스트레스를 덜어줍니다. 매우 세심한 지원팀과 함께 매우 쉽게 구성하고 설정할 수 있습니다. 스트레스가 없는 것 외에도 실제로 더 빨리 매진되었습니다. 포장지에 적힌 대로 정확하게 작동합니다. 솔루션은 완벽하게 작동했습니다.’
‘최고의 대기실, 구현하기 매우 쉽고, 매우 유용합니다!!! 이 시스템은 매우 잘 작동하고 있습니다 - 향후 이벤트에 다시 사용할 예정이며, 서비스가 마음에 듭니다! 모든 사용자가 가상 대기실에 머물 수 있기 때문에 서버의 부하를 분산시킬 수 있으므로이 도구를 선택한 것은 좋은 선택이었습니다. 모든 것이 훌륭했습니다!’
웹 서버가 처리하는 동시 사용자 수와 트랜잭션 흐름의 첫 페이지부터 주문 확인 페이지까지 평균 트랜잭션 시간 또는 방문 기간을 알고 있다면 다음과 같이 리틀의 법칙을 사용하여 이를 사용자 수를 기간으로 나누어 대기열 비율로 변환할 수 있습니다:
대기열 비율 = 동시 사용자 수 / 트랜잭션 시간
Queue-Fair는 사용자가 지정한 비율로 웹사이트 방문자를 전달합니다. 업계에서 가장 정확한 대기열 AI를 통해 1분마다 원하는 방문자 수를 보장하고, 차례가 불렸을 때 참석하지 않은 사람이나 늦게 돌아오는 사람을 자동으로 고려합니다.
이것이 동시 사용자 수로 어떻게 해석될까요? 물론 사이트에 접속하는 모든 방문자가 거래를 완료하는 데 정확한 평균 거래 시간이 걸리지는 않지만, 큰 수의 법칙으로 인해 Queue-Fair를 사용하면 매우 안정적인 동시 사용자 수를 확보할 수 있습니다.
예를 들어 분당 방문자 대기열 비율이 100명이라고 가정해 보겠습니다. 당사는 매분마다 100명의 방문자를 꾸준히 사이트로 보내드리며, 이는 당사가 하는 일이고 놀라울 정도로 잘하는 일입니다. 또한 사람들이 평균(평균) 5분 동안 웹사이트를 이용하고, 그 중 70%가 대기열을 통과한 순간부터 마지막 페이지 요청(거래 완료 여부)을 하는 순간까지 4~6분 정도 걸린다고 가정해 보겠습니다. 이는 평균의 양쪽 표준편차 1분입니다. 통계적으로 말하자면, 5분 30초가 걸리는 방문자 한 명당 4분 30초가 걸리는 방문자가 있다는 뜻이며, 여러 세션에 걸친 개별 방문 시간의 이러한 차이는 어떤 방식으로든 많은 방문자를 계산할 때 서로 상쇄되는 경향이 있습니다. 큰 수의 법칙에 따르면 이러한 상쇄 현상은 참여 인원이 많을수록 점점 더 정확해집니다.
정확히 얼마나 정확한가요? 약간의 통계를 통해 이 문제를 해결할 수 있습니다. 여기에는 5 * 100 = 500이라는 큰 숫자의 표본 크기가 있습니다. 즉, 얼마나 많은 사람들을 조사하고 있는지 알 수 있습니다. 즉, 평균 표준 오차에 대한 통계 공식에 따라 거래 시간에 대한 평균 표준 오차는 1(표준 편차, 1분)을 표본 크기의 제곱근(즉, 500의 제곱근)으로 나누면 거래 시간에 대한 평균 표준 오차는 0.044분 또는 2.7초에 불과하며 이는 1% 미만이라는 것을 의미합니다.
즉, 대기열 비율이 100이고 개별 방문자당 트랜잭션 시간이 5분 내외인 경우 사이트의 동시 사용자 수는 70% 정도인 495~505명으로 예상되므로 비율 기반 대기열을 사용하면 원하는 대로 웹 서버에 매우 안정적인 부하를 제공할 수 있다는 계산이 나옵니다.
하지만 수학이 정확할까요? 예를 들어, 우리가 즐겁게 제곱근을 구하는 표본 크기가 동시 사용자 수를 계산할 때마다(즉, 특정 시점에) 항상 정확히 500이 되는 것은 아니며, 정규(가우스) 분포를 사용하면 실제로는 발생하지 않는 음의 거래 시간이 나올 수도 있습니다. 따라서 방문자 단위, 초 단위 시뮬레이터를 사용하여 이러한 종류의 계산을 확인하기 위해 측정한 결과, 위의 수치를 사용하면 70%의 경우 493~507명의 방문자를 예상해야 한다는 것을 알 수 있으므로 수학이 상당히 잘 맞습니다! 또한 데이터를 측정하면 사이트의 동시 사용자 수가 최소 95% 이상 500 ± 15명임을 알 수 있습니다.
이는 웹 서버가 사이트를 사용하는 사람들의 수를 측정할 수 있는 정확도보다 더 안정적일 것입니다! 더 좋은 점은 방문자의 평균 트랜잭션 시간이나 표준 편차를 모르더라도 이러한 수학적 수치는 알고 있든 모르든 존재하며, 어쨌든 안정적인 부하를 얻을 수 있다는 것입니다.
결론은 Queue-Fair가 원하는 분당 방문자 수를 거의 완벽하게 정확하게 제공하므로 사이트의 동시 사용자 수가 매우 안정 적이며, 사용자가 완전히 제어할 수 있는 안정적인 웹 서버 부하를 제공합니다.
만세!
그리고 이제 경고입니다. 사이트의 동시 사용자 수와 서버 부하의 안정성은 가상 대기실 제공업체가 매분 원하는 방문자 수를 얼마나 정확하게 전송하는지에 따라 크게 달라지므로 가상 대기실 플랫폼을 선택할 때 이 점이 핵심 요소라는 점에 유의할 필요가 있습니다. 당사는 세계에서 가장 정확한 가상 대기실을 제공하기 때문에 서버의 과부하를 가장 잘 막아주는 업체는 Queue-Fair뿐입니다.
서버가 처리할 수 있는 동시 사용자 수 또는 트랜잭션 시간을 모른다면 어떻게 해야 하나요? 병목 현상이 발생할 가능성이 높은 페이지(일반적으로 '지금 구매' 버튼을 클릭한 결과 페이지)를 살펴볼 수 있습니다. Google 애널리틱스를 사용하여 해당 페이지의 월간 순 방문자 수를 찾거나 월간 주문 수를 계산합니다. 이를 30 * 24 * 60 = 43,200으로 나누면 대략 한 달에 걸리는 시간(분)입니다. 이는 한 달 동안의 분당 평균 방문자 수입니다. 여기에 3을 곱합니다. 이는 업무 시간 동안의 분당 평균 방문자 수(대략)입니다. 이를 두 배로 늘립니다. 이 수치가 대기열 비율에 사용하기에 안전한 수치일 것입니다.
예를 들어 한 달에 100,000건의 주문을 처리한다고 가정하면 '지금 구매' 버튼을 100,000번 클릭하는 것입니다. 100,000 / 43,200 = 분당 2.31건의 주문입니다. 이러한 주문의 대부분은 낮에 발생하고 밤에는 서버가 한산할 것으로 예상되므로 여기에 3을 곱하면 업무 시간 동안 서버가 얼마나 바쁜지 대략적으로 추정할 수 있는 분당 7건의 주문이 됩니다. 결과 수치가 50 미만인 경우: 수요에 최고점과 최저점이 있으므로 피크 시간대에 서버가 눈에 띄게 느려지지 않는다면 여기에 2를 곱하여 분당 14명의 활성 사용자를 계산합니다. 수치가 50을 초과하는 경우: 분 단위의 최고점과 최저점은 상대적으로 작아지므로 이 수치를 두 배로 늘리는 것은 안전하지 않습니다. 이 수치는 대기열 비율을 시작하기에 안전한 수치이며 안전하게 관리할 수 있는 초당 요청 수에 해당하며, 시스템이 해당 비율로도 최종 사용자 성능에 대응할 수 있다고 판단되면 언제든지 이 수치를 늘릴 수 있습니다.
주문에 타임스탬프가 있는 경우 최근 한 달 동안 1분 동안 받은 최대 주문을 확인할 수도 있지만, 서버 속도 저하로 인해 이 1분 동안 얼마나 많은 주문이 감소했는지 알 수 없으므로 주의해서 사용하세요.
이 글의 나머지 부분에서는 대기열 비율을 계산하는 몇 가지 다른 방법에 대해 설명합니다.
일반적으로 사용되는 '동시 사용자'에 대한 정의는 두 가지 이상이라는 점에 유의할 필요가 있습니다.
저희는 ' 한 번에 트랜잭션 흐름에 참여하는 사람의 수 '라는 정의를 사용합니다. 대기열 비율을 설정하기 위해 알아야 할 핵심 숫자입니다. 현재 얼마나 많은 사용자가 사이트를 보고 있는지 알 수 있습니다. 동시 세션 수는 일반적으로 동시 연결 수나 동시 사용자 수보다 다소 많은데, 이는 일부 세션이 시간 초과 중이므로 평균 세션 시간이 길어지기 때문입니다.
이를 웹 서버가 한 번에 처리하는 HTTP 요청의 수 인 동시 요청 수와 대조해 보세요. 많은 기술자들이 동시 사용자 수를 말할 때 동시 요청 수를 의미하기 때문에 매우 혼란스러울 수 있습니다.
그런 다음 동시 연결(또는 네트워크 인터페이스 카드의 동일한 서버 포트에 대한 동시 TCP 연결)은 서버 포트 또는 백엔드 서비스에서 한 번에 열려 있는 TCP/IP 소켓의 수입니다. 페이지 요청을 할 때 브라우저는 페이지에서 추가 요청이 있거나 사용자가 다른 페이지로 이동할 경우를 대비하여 기본적으로 연결을 열어 둡니다. 이렇게 하면 새 TCP/IP 연결을 열기 위한 초당 요청 횟수가 줄어들어 서버 프로세스가 더 효율적으로 처리됩니다. 이러한 동시 연결에 대한 시간 제한은 브라우저에 따라 60초에서 절대 닫히지 않는 것까지 다양합니다. 일정 시간 동안 활동이 없으면 서버가 자동으로 연결을 닫을 수도 있습니다. Linux 웹서버에서는 다음 명령을 사용하여 동일한 서버 포트에 대한 동시 연결 수를 확인할 수 있습니다: netstat -aenp | grep ":80 \|:443 " | wc -l
궁금한 점이 있으면 시도해 보세요. 다시 말하지만, 어떤 사람들은 이것을 "동시 사용자"라고 부르기도 하는데, 실제로는 동시 연결을 의미합니다.
실제로 호스팅 제공업체에 웹 서버가 처리하는 최대 동시 사용자 수(최대 트래픽 양)를 알려달라고 요청하면 평균 트랜잭션 시간, 트랜잭션 흐름의 페이지 수 또는 웹 서버가 처리하는 동시 사용자 수를 알려줄 수 있는 기타 정보를 모른다는 단순한 이유로 동시 세션, 동시 요청 또는 동시 연결에 대한 수치를 알려줄 것입니다. 이러한 숫자는 모두 다른 값을 갖습니다.
호스팅 제공업체나 기술팀에 최대 트래픽 수준에 대한 정보를 요청하는 경우 동시 사용자, 동시 세션, 동시 요청 또는 동시 연결을 의미하는 것인지 명확히 하는 것이 매우 중요합니다.
그 이유는 다음과 같습니다. 각 페이지는 단일 HTTP 요청이지만 브라우저가 페이지를 표시하는 데 사용하는 웹 애플리케이션에서 가져온 모든 이미지, 스크립트 및 기타 파일도 HTTP 요청입니다.
기술팀으로부터 서버가 500명의 동시 사용자를 지원한다고 들었지만 실제로는 500명의 동시 요청을 의미한다고 가정해 봅시다. 트랜잭션 시간이 5분이므로 위의 공식을 사용하여 사이트에서 분당 100명의 방문자를 지원할 수 있다고 가정합니다.
할 수 있나요? 아니요.
사람들이 트랜잭션 흐름을 진행할 때 실제로는 각 페이지가 로드되는 동안에만 서버에 요청을 하게 됩니다. 이는 서버가 처리할 수 있는 초당 트래픽 양이나 활성 사용자 수에 영향을 미칩니다. 5분의 트랜잭션 시간 중 일반 사용자에게는 몇 초에 불과합니다. 따라서 500개의 동시 요청은 훨씬 더 많은 동시 사용자를 처리할 수 있다는 의미라고 생각할 수 있지만, 이는 잘못된 생각일 수 있습니다. 이제 트래픽 양이나 총 활성 사용자 수로 웹사이트 용량을 이해하는 것이 얼마나 복잡한 일인지 알 수 있을까요?
최대 총 동시 요청 수에서 최대 동시 사용자 수를 계산하려면 다음 사항도 알아야 합니다.
1)과 2)는 이미 알고 계실 것입니다. 이 예에서는 6페이지와 5분입니다. 트랜잭션을 수행하는 동안 표시되는 페이지 수를 쉽게 계산할 수 있습니다. 평균 트랜잭션 시간을 모르는 경우 Google 애널리틱스에서 알려주거나 웹 서버 로그를 확인할 수 있습니다.
3) 및 4)의 경우 Firefox 브라우저가 도움이 될 수 있습니다. 사이트의 페이지를 마우스 오른쪽 버튼으로 클릭하고 요소 검사 및 네트워크 탭을 선택합니다. 그런 다음 CTRL-SHIFT-R을 눌러 페이지를 완전히 새로 고칩니다. 목록에서 페이지의 모든 요소에 대한 네트워크 로드 시간을 확인할 수 있습니다. 전송된 열에서 전송 크기를 확인할 수 있는지 확인해야 합니다. 그렇지 않으면 캐시에서 파일이 제공되어 계산이 엉망이 될 수 있기 때문입니다. 일부 스크립트 및 기타 리소스가 사이트가 아닌 다른 서버에서 제공된 것으로 표시될 수 있으므로 왼쪽의 필터 상자에 사이트의 도메인 이름을 입력할 수 있습니다. 기간 열을 보려면 열 헤더를 마우스 오른쪽 버튼으로 클릭하고 팝업 메뉴에서 타이밍 -> 기간을 선택합니다. 화면이 다음과 같이 표시됩니다:
이 페이지의 Firefox 네트워크 탭에 queue-fair.com의 요청 기간 및 횟수가 표시됩니다.
페이지 표시에 사용되는 파일은 여러 사이트에서 가져올 수 있으므로 왼쪽 상단의 필터를 사용하여 내 사이트의 파일만 표시할 수도 있지만 , 다른 사이트의 파일이 페이지 로드 속도 저하 또는 병목 현상의 원인이 아닌 것이 확실한 경우에만 사용할 수 있습니다.
Firefox는 디스플레이 왼쪽 하단에 요청 수를 계산하여 이 한 페이지에 대해서만 36개의 HTTP 요청을 표시합니다.
트랜잭션 흐름의 모든 페이지에 대해 이 작업을 수행해야 합니다. 총계를 세고 페이지 수로 나누어 각 페이지의 평균 HTTP 요청 수(목록의 3번)를 구합니다. 이제 각 HTML 페이지의 하위 요청 수가 웹 서버가 처리할 수 있는 트래픽의 양을 결정하는 핵심 요소인 이유를 알 수 있습니다.
4)의 경우 지속 시간 열을 살펴보고 모든 페이지에 대한 모든 HTTP 요청의 평균을 찾아야 합니다. 확실하지 않은 경우 0.5초라고 가정하세요. 어차피 여기에는 불확실성이 많이 있습니다(아래 참조).
몇 가지 수치를 예로 들어보겠습니다. 이미 예제 서버 프로세스 흐름에 6개의 동적 페이지가 있고(1), 평균 트랜잭션 시간은 5분(2)이라고 말씀드렸습니다. 3)의 경우 페이지당 36개의 HTTP 요청이 있고, 각 HTTP 요청에 대한 서버 처리 시간은 4)의 경우 0.5초라고 가정해 봅시다.
이 수치를 사용하면 500개의 동시 요청을 처리할 수 있는 서버는 500 / (0.5초) = 초당 1000개의 HTTP 요청을 처리할 수 있으며, 이는 완전히 최대치인 경우 분당 60,000개의 HTTP 요청을 처리할 수 있습니다.
5분의 트랜잭션 시간 동안 5 * 60,000 = 300,000개의 HTTP 요청을 처리할 수 있습니다. 엄청나게 많죠?
하지만 각 방문자에 대해 각각 평균 36개의 HTTP 요청이 있는 6개의 페이지가 있으므로 6 * 36 = 216개의 요청이 발생합니다.
따라서 이론적으로 300,000 HTTP 요청 용량은 300,000 / 216 = 1,389명의 동시 사용자를 처리할 수 있습니다.
잘됐네요! 대기열 비율이 100밖에 안 될 줄 알았는데 1,389/5분 = 분당 방문자 수 278명이므로 대기열 비율이 더 높아질 수 있습니다!
글쎄요, 아마도 아닐 겁니다. 우선, 위의 계산에서 가정한 것처럼 방문자가 정확히 0.5초 간격으로 깔끔하게 요청을 보내지는 않습니다. 더 중요한 것은 사이트가 바쁘지 않을 때 입력 데이터를 측정했다는 것입니다. 가비지 인, 가비지 아웃.
사이트가 사용량이 많으면 서버가 요청을 처리하는 데 시간이 더 오래 걸리며, 다른 사이트에서도 사용량이 많을 때 페이지를 기다리는 시간이 길어지는 것을 경험했을 것입니다. 이렇게 하면 서버가 단일 HTTP 요청을 처리하는 데 걸리는 평균 시간이 증가하여 (4) 최대 처리량이 감소합니다. 따라서 분당 방문자 수 278명을 절반으로 줄이세요. 그런 다음 다시 절반으로 줄이세요. 현실적으로 최대 로드 시 분당 약 70명의 신규 방문자가 발생하게 될 것입니다.
캐싱을 사용하면 방문자의 브라우저가 모든 페이지에 대해 모든 요청을 할 필요가 없으므로 서버에 필요한 리소스가 줄어들고 서버가 처리할 수 있는 분당 신규 방문자 수가 늘어날 수 있습니다. 여러 서버에 부하를 분산하는 부하 분산 장치를 사용하고 동적 페이지 대신 정적 콘텐츠를 제공하면 각 서버에 필요한 리소스가 줄어들기 때문에 서버 처리 속도가 빨라질 수 있습니다.
또한 일부 페이지는 다른 페이지보다 제작 및 제공에 필요한 리소스가 적기 때문에 모든 페이지가 완료되는 데 동일한 시간이 걸리지 않습니다. 데이터베이스 검색, 검색 쿼리 및 업데이트에 가장 오랜 시간이 걸리므로 신용카드 세부 정보가 처리되고 주문이 저장되기를 기다리거나 주문 가능 여부가 확인되기를 기다리면서 사람들이 쌓이는 프로세스 어딘가에 병목 현상이 발생할 수 있습니다. 모든 트랜잭션 흐름에는 가장 느린 단계가 있으므로 항상 어딘가에 병목 현상이 발생하며, 웹 서버가 처리할 수 있는 동시 사용자 수에 대한 질문에는 항상 최대값이 존재하며 여러 가지 제한이 있을 수 있습니다. 이 경우 대기열 비율을 충분히 낮게 설정하여 서버가 프로세스의 가장 느린 단계에서 동시에 충분한 사용자를 처리할 수 있는 CPU 시간 용량을 확보하여 사용자가 한꺼번에 몰리지 않도록 하는 것이 좋습니다. 그렇지 않으면 웹서버가 말 그대로 멈출 수 있습니다.
저희의 경험에 따르면, 첫 번째 판매를 시작할 때 모두가 서버의 대용량 트래픽 처리 능력을 과대평가합니다.
여러분.
느리거나 트래픽이 폭주하는 동안 평균 세션 시간과 최종 사용자 성능을 정확하게 파악하는 것은 쉬운 일이 아닙니다. 가장 좋은 방법은 '가짜' 고객이 실제로 주문 프로세스를 진행하면서 실제와 똑같이 로드 테스트를 진행하고, 로드 테스트 시 실제와 동일한 순서로 동일한 HTTP 요청을 하고, 페이지 간에 동일한 대기 시간을 두고, 가상 방문자 수를 늘리면서 프로세서 부하, IO 처리량 및 응답 시간을 주시하면서 적절한 로드 테스트를 실행하는 것입니다. 이를 위해 Apache JMeter를 사용할 수 있지만(부하가 적거나 속도가 느린 시스템에서는 K6도 좋습니다), 어떤 도구를 사용하든 모든 사용자의 행동을 정확히 모방하는 데는 시간이 많이 걸리고 까다롭습니다(특히 캐싱이 복잡할 경우). 그렇더라도 최대 수치를 절반으로 줄이세요.
그렇지 않은 경우에는 주의해서 사용하세요.
Queue-Fair 포털을 사용하여 언제든지 Queue-Fair 대기열의 대기열 비율을 쉽게 변경할 수 있습니다. 분당 방문자 수 10명 또는 평상시의 거래 속도에서 시작하여 티켓이 판매된 후 잠시 동안 어떻게 진행되는지 살펴본 다음, 프로세서 부하가 낮고 SQL 데이터베이스가 정상이며 무엇보다도 페이지가 응답하는 경우 CTRL-SHIFT-R을 누르면 20% 이하로 올린 후 잠시 기다렸다가 반복하세요. 이 '로드 밸런싱' 중에 필요한 실제 속도를 곧 찾을 수 있을 것이며(우리가 한 일을 보셨나요?), 고객 경험 관점에서 보면 대기열에 있는 고객의 예상 대기 시간이 줄어들고 예상 대기 시간이 짧아지는 응답 시간을 보고 모두가 만족하기 때문에 대기열 속도를 높이는 것이 좋습니다.
대기열 비율을 너무 높게 설정했다가 낮춰야 하는 상황에 처하는 것은 피해야 하는데, 이는 1) 사이트를 사용하는 사람들이 느린 페이지 로딩을 경험하고 2) 예상 대기 시간이 증가한다는 것을 의미하기 때문입니다. 대기열에 있는 모든 사람들이 한숨을 쉬게 될 것입니다!
주문 프로세스의 어딘가에 병목 현상이 발생할 수 있으며, 모든 거래에는 가장 느린 단계가 있기 때문에 여러 세션이 쌓이게 됩니다. 티켓 판매를 시작한 지 얼마 되지 않아 서버 프로세서 부하가 최대치에 훨씬 못 미치는 것을 확인하고 속도를 높이는 것은 원치 않는 일입니다. 방문자가 '지금 구매' 버튼까지 도달하지 않았을 수도 있습니다. SQL 데이터베이스에서 대기열 비율과 같거나 비슷한 비율로 새 주문이 보고될 때까지 기다린 다음 측정 및 응답성 테스트를 수행합니다. 속도를 높일 때마다 추가 방문자가 병목 현상에 도달하는 데 동일한 시간이 걸리므로 해당 시간이 경과할 때까지는 새로운 속도에서 서버의 성능을 정확하게 평가할 수 없다는 점을 기억하세요.
대기열이 열리면 대기열 비율을 점진적으로 높이는 것이 가장 좋은 방법에 대해 이미 설명했습니다. 서버에 시스템 충돌 없이 초과할 수 없는 한계가 있다는 것을 알고 있고 그 한계가 무엇인지 알고 있을 수도 있지만, 부하가 이 한계에 가까워질 때 보통 몇 가지 오류나 경고 또는 프로세서 부하가 80%를 초과하는 등 별다른 징후가 없다는 것을 모를 수도 있습니다.
웹 서비스에 장애가 발생하면 매우 빠르게 '스냅'되거나 멈추는 경향이 있습니다. 이는 일반적으로 시스템이 더 이상 요청이 들어오는 대로 빠르게 처리할 수 없게 되면 내부 처리 대기열이 쌓이기 때문입니다. 그러면 시스템은 요청뿐만 아니라 내부 대기열을 처리, 관리, 저장하는 작업을 수행해야 하며, 이 때문에 서버가 한계에 다다르게 됩니다. 아주 빠르게요. 이러한 상황이 발생하면 서버가 잠시 동안 오류 페이지로 응답할 수 있지만, 이를 본 방문자가 즉시 새로 고침을 눌러 부하가 가중되므로 도움이 되지 않습니다.
그 전이라도 방문자가 페이지를 보는 데 약 1초 이상 걸리면 새로 고침을 누릅니다. 방문자가 새로 고침을 누르면 웹서버는 방문자가 더 이상 원본 요청에 대한 응답을 기다리지 않는다는 사실을 알지 못합니다. 원본 요청과 새로 고침 요청이 모두 수신되면 웹서버는 두 요청을 모두 처리합니다. 즉, 웹서버의 업무가 늘어나고 모든 방문자의 응답 속도가 느려지며 새로 고침을 누르는 사람이 많아져 웹서버가 오류 응답을 보내기도 전에 중단되는 악순환이 반복됩니다.
따라서 서버를 필요 이상으로 무리하게 사용하지 마세요. CPU 시간 용량의 마지막 20%를 사용하는 것은 일반적으로 위험을 감수할 가치가 없습니다. Queue-Fair 포털에 표시되는 대기열 크기(차트의 노란색 대기 그림과 선)가 분 단위로 감소하거나 더 느리게 증가하고 있고 표시된 대기 시간이 50분 이하인 경우, 주문을 충분히 빠르게 처리하고 있으며 결국 대기열이 비워지고 대기열 페이지 표시가 자동으로 중지되므로 사용자가 아무것도 할 필요도 없고 상사에게 너무 세게 밀어 부쳐서 깨졌다고 말할 필요도 없습니다. 대기열 앞쪽의 속도가 분당 참가 수(두 가지 모두 Queue-Fair 포털에 표시됨)보다 빠르면 결국에는 도달하게 되며, 전환점은 일반적으로 각 이벤트가 시작되고 최소 몇 분 후입니다. 한정 수량 제품을 판매하는 경우 전환 시점에 도달하기 전에 매진될 가능성이 높습니다.
좋은 소식은 실수로 대기열 비율을 너무 높게 설정하여 서버가 멈춘 경우 서버가 방문자를 다시 처리할 준비가 될 때까지 대기열을 보류 모드로 설정하면 빠르게 복구할 수 있다는 것입니다. 대기 모드에서는 대기열에 있는 사람들에게 온라인 이벤트 전에 디자인할 수 있는 특별한 대기 페이지가 표시됩니다. 대기열이 대기 중일 때는 대기열 앞쪽에서는 아무도 통과할 수 없지만, 새로운 인터넷 방문자는 대기열 뒤쪽에서 대기열에 합류하여 차단이 해제되면 공정하게 대기할 수 있으며, 이는 Queue-Fair가 사이트를 수요로부터 보호하므로 매우 빠르게 이루어집니다. 대기 페이지를 업데이트하여 방문자에게 대기열이 다시 열릴 것으로 예상되는 시간을 알려주면 대기열 비율을 매우 낮게 설정할 수 있는 우수한 사용자 환경을 제공하며, 이미 수십만 명이 대기열에 있는 경우에도 포털 페이지 편집기를 사용하여 쉽게 수행할 수 있습니다. 대기 모드에서는 시스템이 스냅에서 복구되는 동안 필요한 경우 Queue-Fair의 고유한 Admit One 버튼으로 한 번에 한 명씩 통과시킬 수도 있습니다.
따라서 이벤트 진행 중에 서버를 잠시 쉬어야 하는 경우 보류 페이지를 사용하면 서버를 더 빠르게 복구하여 부팅할 수 있습니다.
이 글에서는 비율 기반 대기열이 항상 필요한 이유와 필요한 비율을 계산하는 두 가지 방법을 설명했지만, 전체 트랜잭션 흐름에 대해 완전하고 정확한 가상 방문자 부하 테스트를 수행하지 않았고 이에 대해 매우 확신하지 않는 한 조언은 항상 동일합니다:
한정 수량 제품을 판매하는 경우에는 7단계에 신경 쓸 필요가 없습니다.
이는 시스템이 지원할 수 있는 실제 최대 대기열 비율을 모르는 첫 번째 대기열에 대한 것입니다. 이후 대기열의 경우 시스템이 실제로 처리할 수 있는 대기열 비율을 측정한 후에는 동일한 수치를 다시 사용할 수 있지만, 시스템에 변경 사항이 없는 경우에만 가능합니다. 실제로는 시스템이 계속 개발 및 수정 중일 수 있으며 최근 변경 사항이 최대 대기열 비율에 어떤 영향을 미쳤는지 모를 수 있으므로 이전 측정 수치의 절반에서 시작하여 위의 과정을 반복하는 것은 어떨까요?
이것이 바로 Queue-Fair를 사용하여 온세일을 멋지고 안전하게 만드는 방법이며, 항상 후회하는 것보다 안전한 것이 낫다는 것을 기억하세요.
2024 The Fair Queue People Ltd. - 모든 권리 보유.
Orderly 큐 솔루션 제품군의 일부입니다. - OrderlyQ - OrderlyStats - WeQ4U