내 웹사이트에서 얼마나 많은 트래픽을 처리할 수 있습니까?

웹 사이트의 성능과 용량을 명확하게 이해하는 것은 간단한 작업이 아닙니다. 실제로 접근 방법을 모르면 다소 힘든 과정이 될 수 있습니다. 이 상세 가이드는 사이트 트래픽 질문에 답하기 위해 확인해야 하는 측정항목을 단번에 확실하게 조사합니다.

WP 엔진에서는 웹 사이트 성능을 알고 있습니다. 1차원적인 캐치프레이즈 그 이상입니다. 실제로 우리 플랫폼에서 실행되는 사이트의 경우 성능을 클라우드 및 보안 솔루션의 측면과 관리형 WordPress 전문 지식을 결합하는 전략적 등식으로 봅니다.

그렇게 함으로써 능동적인 지원이 필요한 변수와 메트릭의 세탁 목록을 통해 여러 각도에서 접근해야 할 성능에 접근할 수 있습니다.

우리는 또한 이러한 노력을 그 자체로 하나의 제품으로 간주하며 결코 끝나지 않은 것으로 보고 있습니다. 우리는 플랫폼 전체에서 사이트 성능의 모든 구성 요소를 개선하기 위한 방법을 지속적으로 연구하고 있습니다. 이 "절대 만족하지 않는" 접근 방식을 취함으로써 WP Engine은 고객이 WordPress에서 가장 빠른 사이트를 구축하도록 도울 수 있으며 트래픽 급증에서 보안에 이르기까지 모든 상황에서 해당 사이트를 계속 실행하도록 도울 수 있습니다. 위협.

여기에서 TTFB(Time to First Byte)와 같은 속도 및 메트릭을 다루는 동안 다음 문서에서는 트래픽 메트릭과 일반적이지만 중요한 질문인 "내 사이트에서 얼마나 많은 트래픽을 처리할 수 있습니까?"에 대해 자세히 설명합니다.

질문의 틀을 잡습니다.

웹 사이트 용량, 즉 사이트가 주어진 순간에 처리할 수 있는 트래픽의 양은 전체 사이트 성능의 핵심 구성 요소이며 개발자가 인프라와 같은 것에 소비하는 시간은 물론 KPI에 직접적인 영향을 미칩니다. 자체 인프라를 사내에서 다시 관리). 즉, 사이트에서 처리할 수 있는 트래픽의 양을 측정하는 것은 사용자 유형과 사이트에서 받는 트래픽을 이해하는 것에서 시작됩니다.

먼저 인터넷의 맥락에서 동시 사용자의 정의를 살펴보겠습니다.

WP Engine에서 이 리소스는 WordPress 사이트입니다.

동시 사용자가 높은 수준의 메트릭이라는 점은 주목할 가치가 있습니다. 다음 몇 개의 섹션에서는 동시 사용자가 동시 요청에 대한 보다 세분화된 지표로 이어진다는 것을 배우게 됩니다. 이러한 요청은 모양과 크기가 다르기 때문에 캐시 가능성을 사용하여 사이트가 대규모로 수행되는 방식을 이해할 수 있습니다. 더 깊이 들어가면서 동시성과 캐시 가능성이 서로 어떻게 상호 작용하는지 살펴보겠습니다.

그렇다면 동시 사용자를 사용하여 환경의 용량을 이해하는 방법은 무엇입니까? 이에 대한 답을 찾기 전에 한 단계 더 나아가 오늘날 사용되는 가장 일반적인 지표 중 하나인 월별 트래픽을 살펴보겠습니다.

월간 트래픽 지표: 유용한가요?

일반적으로 그렇습니다. 월별 수치는 기본 트래픽 프로필(낮음, 보통 또는 높음)에 대한 이해를 제공합니다. 또한 이러한 지표는 마케팅 캠페인, 검색 엔진 순위 및 시장 조건을 비롯한 다양한 변수에 따라 월별 트래픽이 변경될 수 있으므로 잠재적인 추세, 패턴 및 계절성에 대한 통찰력을 제공합니다.

대부분의 사이트에서 정상적인 일일 트래픽은 상당히 안정적이고 예측 가능할 수 있습니다. 이 기본 트래픽을 호출할 수 있습니다. 그러나 반복적으로 트래픽 급증이 발생하는 일부 사이트는 기준선에 대해 걱정하지 않습니다. 그들은 콘서트 티켓을 판매하는 사이트나 제품 출시를 알리는 데 사용되는 사이트와 같이 비즈니스에 중요한 트래픽이 많은 이벤트에 더 관심이 있습니다. 이러한 이벤트가 가장 중요한 경우 프로덕션 환경에서 기본 트래픽뿐만 아니라 최대 트래픽 수준도 처리하는 것이 중요합니다.

이것은 월별 트래픽 번호가 도움이 되지 않는 곳입니다. 이 트래픽 수준에서 용량을 이해하기 위한 보다 신뢰할 수 있는 메트릭은 동시 사용자입니다.

사용자 측정항목에 대해 자세히 알아보세요.

동시 사용자로 이동하기 전에 디지털 분석 영역에서 메트릭의 계층 구조를 이해하는 것이 도움이 됩니다. 이를 설명하는 다이어그램은 다음과 같습니다.

• 사용자 또는 방문자는 처음으로 사이트에 들어오는 사용자를 설명하는 지표입니다. 일반적으로 고유한 사용자 ID로 정의됩니다. WP 엔진에서는 고유한 IP 주소로 정의되며 하루에 단일 고유 방문자로 계산됩니다. 동일한 사용자의 추가 방문은 고유 사용자 ID로 인식되므로 고유 사용자는 한 번만 계산됩니다.
• 세션 또는 방문은 사용자가 사이트에 참여한 기간을 나타냅니다. 세션은 사용자가 사이트를 처음 방문할 때 시작되고 사용자가 브라우저를 닫거나 쿠키를 지우거나 30분(Google Analytics의 기본 기간이며 사용자 정의할 수 있음) 동안 비활성 상태가 되는 세 가지 일이 발생할 때 종료됩니다. 단일 사용자는 하루 동안 여러 세션을 가질 수 있습니다.
• 적중은 사이트와 정의된 리소스 간의 상호 작용입니다. 디지털 분석 측면에서 이 지표는 Google Analytics로 전송되는 데이터로 정의됩니다. 이러한 히트는 가장 일반적으로 페이지 뷰입니다. WP 엔진 컨텍스트 내에서 적중은 프로덕션 환경에 대한 요청일 수 있습니다. 이러한 요청은 정적 자산(png, jpeg, pdf)처럼 캐시 가능하거나 데이터베이스 쓰기(등록, 게시물 게시, 제품 주문)와 같은 동적일 수 있습니다.

이러한 메트릭의 계층 구조를 기반으로 위에서 아래로 이동할 때 데이터가 덜 모호해지고 더 세분화됩니다. 동시에 이러한 메트릭이 성능에 미치는 영향을 이해하는 것이 더 명확해집니다.

요컨대, 월간 사용자 또는 방문자 수를 아는 것만으로는 충분하지 않습니다 .

Google 애널리틱스 활성 사용자는 어떻습니까?

Google Analytics 및 WP Engine이 측정항목을 캡처하고 정의하는 방식과 관련하여 종종 오해가 있습니다. 간단히 말해서 둘 다 서로 다른 목적으로 이 데이터를 추적합니다. Google Analytics는 주로 마케팅 및 전환 분석 도구입니다. 반대로 WP Engine은 인프라 계층에서 원시 리소스 활용도와 애플리케이션 계층에서 성능을 추적하는 관리형 플랫폼입니다. 방법론이 다르며 두 플랫폼 간에 불일치가 발생할 수 있습니다.

동시성과 관련하여 Google Analytics는 사이트에서 마케팅 캠페인의 효과를 모니터링하는 실시간 보고서를 제공합니다. 여기에는 현재 사이트의 활성 사용자 수가 포함됩니다.

"실시간"임에도 불구하고 이 메트릭은 주어진 시간에 사이트의 총 사용자 수를 동시에 측정하지 않습니다. 실시간 활성 사용자는 지난 5분 이내에 이벤트 또는 페이지 보기를 트리거한 고유한 사용자로 정의됩니다. 사용자가 5분 전에 사이트를 떠나면 Google은 계속해서 이를 활성 사용자로 계산합니다. 사용자가 사이트에 5분 이상 머무르면 사이트와 계속 상호 작용하더라도 더 이상 활성 사용자로 계산되지 않습니다.

이를 염두에 두고 Google의 활성 사용자는 사이트의 실제 동시 사용자 수보다 많을 수 있습니다. 흔하지 않은 경우에는 사용자 행동과 평균 세션 시간에 따라 지표가 실제 동시성보다 적을 수 있습니다.

Google 애널리틱스 활성 사용자를 신뢰할 수 있습니까? 항상 그렇듯이 데이터가 많을수록 좋습니다. 그러나 단독으로는 필요한 용량을 결정하지 않습니다.

동시 접속자 측정 방법 .

Google 애널리틱스가 동시 사용자에 대한 명확한 측정항목을 제공하지 않는다면 어떻게 할까요? 다음은 이 숫자를 결정하는 데 도움이 되는 두 가지 일반적인 방법입니다.

1. 동시 사용자를 계산합니다 .

Google 애널리틱스에서 가져온 데이터와 함께 이 공식을 사용하면 1초와 같은 매우 작은 시간 단위 내에 사이트의 활성 사용자 수를 계산할 수 있습니다.

[시간당 최대 세션 수 X 평균 세션 시간(초)] / 3600

시간별 세션이 가장 많은 경우 Google Analytics의 "잠재고객 개요" 보고서로 이동 —> 트래픽이 가장 많은 기간 찾기 —> 탭을 "시간별"로 변경 —> 그래프 위로 마우스를 가져가면 한 시간 동안 가장 많은 세션 수를 볼 수 있습니다.

평균 세션 시간의 경우 메트릭이 개요 대시보드 내에 표시됩니다. 그렇지 않은 경우 개요 탭 아래의 "측정항목 선택"으로 이동하여 기간을 표시합니다.

2. Google 애널리틱스 대안을 선택합니다 .

Google Analytics는 업계에서 가장 널리 사용되는 웹 분석 도구이지만 특정 요구 사항을 모두 충족하지는 못할 수 있습니다. 기존의 동시 사용자 정의에 더 부합하는 동시성을 측정할 수 있는 많은 분석 도구가 있습니다.

캐시 가능성은 어떻습니까?

그렇다면 동시 사용자는 유효한 성능 측정값입니까? 완전한 것은 아니고. 이 메트릭은 높은 수준에서 시나리오의 규모를 이해하는 데 도움이 되지만 더 깊은 통찰력을 제공하지는 않습니다.

즉, WordPress 사이트에 로그인한 사용자(구성원, 관리자, 편집자)와 로그인하지 않은 사용자의 차이를 이해하는 것이 도움이 됩니다. 이러한 사용자의 행동은 다양한 유형의 "조회" 또는 요청을 생성합니다. 사이트 성능을 가장 잘 나타냅니다(위의 이전 섹션에서 언급됨).

이를 확장하기 위해 다음과 같은 다양한 유형의 요청이 정적 또는 동적 형식으로 제공됩니다.

• 예를 들어 CSS, JS 및 이미지와 같은 정적 콘텐츠 (거의 변경되지 않는 파일)는 쉽게 캐시할 수 있습니다.
• 로그인 페이지, 장바구니, 멤버십 전용 영역과 같은 동적 콘텐츠는 방문하는 각 사람에게 고유한 것을 화면에 표시해야 하므로 캐시할 수 없습니다.

이것은 캐시 또는 임시 저장 영역에 데이터를 저장하는 프로세스를 나타내는 캐시 가능성 의 개념을 가져옵니다. 콘텐츠가 캐시되면 브라우저는 원래 서버가 아닌 캐시에서 검색하여 최종 사용자의 시간을 절약하고 네트워크에 추가 트래픽 부담을 줄입니다.

 위의 정적 대 동적 분류와 관련하여 더 많은 정적 콘텐츠가 있는 사이트는 더 높은 캐시 가능성 점수를 갖습니다. 반대로 동적 콘텐츠가 많은 사이트는 캐시 가능성 점수가 낮습니다.

WP Engine 사용자가 WordPress 사이트에 로그인하면 거의 완전히 캐시할 수 없는 동적 콘텐츠와 상호 작용합니다. 따라서 Varnish 및 CDN과 같은 프런트엔드 캐싱 계층을 우회합니다. 결과적으로 이러한 캐시할 수 없는 요청은 PHP 및 MySQL을 통해 백엔드에서 새로 처리해야 하므로 일반적으로 더 리소스 집약적입니다. 한편, 로그인이 필요하지 않은 사이트는 페이지의 요소에 따라 캐시 가능성이 다를 수 있습니다.

이 다이어그램은 정적 콘텐츠와 동적 콘텐츠를 제공하는 데 필요한 다양한 기술을 보여줍니다.

설명을 위해 "The Puppy Nursery"라는 강아지 입양 웹사이트가 있다고 가정해 보겠습니다. 사이트를 처음 방문하는 방문자는 갑자기 홈페이지에 있는 고품질 사진을 접하게 됩니다. 메뉴 위로 마우스를 가져간 후 각 동물에 대한 자세한 내용을 보려면 강아지 약력 페이지를 클릭하기로 결정합니다. 이 페이지는 대부분 정적이며 귀여운 강아지에 대한 설명과 사진이 있습니다. 이러한 페이지에는 대부분 정적 콘텐츠(캐시 가능)가 있으므로 이 특정 사용자 세션은 리소스를 많이 사용하지 않습니다.

이제 하루가 지나면 강아지를 입양할 생각으로 사이트를 다시 방문하기로 결정합니다. 지리적 위치에 가장 가까운 강아지 목록이 동적으로 팝업되는 등록 페이지를 클릭합니다. 강아지를 선택한 후 개인 연락처 정보가 포함된 양식을 작성하고 안전 포기에 동의하고 입양비를 위한 신용 카드 정보를 제공합니다. 제출을 누르면 "감사합니다" 페이지로 리디렉션됩니다. 이 특정 사용자 세션은 개인화된 팝업, 양식 제출 및 신용 카드 거래를 포함한 대화형 요소로 인해 더욱 역동적입니다. 결과적으로 자원 집약적입니다.

이 예에서 볼 수 있듯이 사용자 세션의 변동으로 인해 서버에 대한 요청 유형과 요청 수가 달라집니다. 이러한 요청은 동시 사용자 수보다 더 나은 용량 및 성능 지표입니다.

전반적으로 동시 로그인, 로그아웃 사용자 수 및 캐시 가능성은 사이트의 리소스 수요를 이해하는 데 도움이 됩니다.

다양한 유형의 사이트 .

분명히 모든 웹사이트는 고유하며 서로 다른 문제에 직면해 있습니다. 그러나 웹사이트의 기본 특성이 캐시 가능성을 알려준다는 것은 여전히 ​​사실입니다.

이 개념을 확장하면 일반적으로 더 정적이거나 동적인 다양한 유형의 사이트가 있습니다.

공전:

• 브로셔 사이트
• B2B 마케팅 사이트
• 비영리 단체
• 블로그(낮은 게시물 활동)
• 사용자 상호 작용이 매우 낮은 모든 사이트

동적:

• 전자 상거래 상점
• 회원 사이트
• 워드프레스 멀티사이트
• 학습 관리 시스템
• 사용자 상호 작용이 많은 모든 사이트(댓글, 등록, 주문 거래, 로그인 활동, 검색 쿼리)

참고: 이렇게 분류되어 있지만 WordPress 사이트에는 정적 요소와 동적 요소가 모두 있을 수 있습니다. 그렇기 때문에 캐시 가능성 점수를 볼 때 둘 사이의 비율을 이해하는 것이 중요합니다.

이제 이것을 트래픽으로 변환해 보겠습니다. 브로셔와 전자 상거래라는 두 가지 유형의 사이트가 있는 시나리오를 상상해 보십시오. 본질적으로 브로셔 사이트는 전자 상거래 상점보다 정적입니다. 각각 각 사이트의 캐시 가능성 점수는 90%와 20%라고 하겠습니다. 사이트가 WP 엔진에서 호스팅되는 경우 지원 팀에 문의하여 캐시 가능성 점수를 확인하십시오.

이 시나리오에서는 각 사이트의 WP Engine 플랫폼에서 Google Cloud 전용 솔루션을 사용하기로 결정했다고 가정해 보겠습니다. 솔루션이 정확히 동일하다고 가정하면 브로셔 사이트가 다운되기 전에 얼마나 많은 트래픽을 처리할 수 있습니까? 전자 상거래 사이트는 어떻습니까?

이제 아시다시피 대답은 상황에 따라 다릅니다. 일반적으로 전용 솔루션의 브로셔 사이트는 전자 상거래 사이트보다 훨씬 더 많은 월 방문자를 지원할 수 있습니다. 더 정적이고 캐시 가능합니다. 그것은 우리가 할 수 있는 비교적 안전한 가정입니다.

귀하의 사이트에서 처리할 수 있는 정확한 방문자 수를 아는 한, 이 질문을 더 작은 부분으로 나누어 전체적으로 접근하는 것이 좋습니다.

올바른 질문을 합니다 .

사이트에서 처리할 수 있는 트래픽 양을 결정하는 대신 더 유용한 질문은…

현실적인 높은 트래픽 시나리오에서 주어진 시간 동안 내 사이트에서 얼마나 많은 동시 사용자를 처리할 수 있습니까? 예를 들어 귀하의 사이트가 TV 쇼에 소개되고 20분 동안 1,000명의 동시 비로그인 사용자가 예상됩니다.]

이 사용자 중 로그인한 사용자와 로그아웃한 사용자는 몇 명입니까?

사이트는 얼마나 캐시 가능합니까?

이 최대 부하 동안 허용되는 응답 시간 수준, 분당 요청 수, 대기 시간 및 오류율은 얼마입니까?

비즈니스로 해석할 때 이러한 KPI가 충족되지 않으면 어떻게 됩니까?

수익에 어떤 영향을 미칠 수 있습니까?

부하 테스트를 입력합니다 .

이러한 질문에 답하려면 부하 테스트를 수행하여 실제 시나리오를 시뮬레이션하는 것이 좋습니다.

 부하 테스트는 시스템의 성능을 결정하기 위해 시스템에 요구하는 프로세스입니다.

페이지 성능 테스트(WP 엔진 고객이 사용 가능) 또는 속도 도구 테스트(모든 사람이 사용 가능)는 단일 방문을 기반으로 사이트의 속도를 측정하지만 이는 첫 번째 장에 불과합니다. 부하 테스트는 모든 것을 말해줍니다.

가장 일반적으로 동시 사용자 수가 많은 최대 트래픽을 시뮬레이션하기 위해 부하 테스트를 수행합니다. 즉, 단일 방문이 아닌 과부하 상태에서 사이트가 어떻게 작동합니까?

특히 사이트에 대한 환경의 용량을 진정으로 이해하기 위해 로드 테스트를 수행하면 모든 트래픽 수준에서 더 많은 확신을 얻을 수 있습니다.

다음은 도움이 되는 몇 가지 리소스입니다.

부하 테스트에 대한 자세한 내용은 이 백서를 참조하십시오.

페이지 캐시 가능성 개선에 대한 팁은 이 문서를 참조하십시오.

최종 생각 .

사이트에서 처리할 수 있는 트래픽의 양을 이해하는 것은 확실히 혼란스러울 수 있습니다. 대부분의 관리형 호스팅 제공업체는 솔루션에 대한 자체 기준과 최대 월간 방문자를 정의합니다. 사이트에는 고유한 특성 세트가 있으므로 이러한 수치를 신뢰하여 성능과 용량을 평가하는 것은 현실적이지 않습니다. 또한 월별 트래픽 수치는 짧은 시간 동안만 지속되는 이벤트를 포함하여 트래픽이 많은 이벤트를 사이트에서 처리하는 방법을 이해하는 데 도움이 되지 않습니다.

그렇기 때문에 이러한 추정 수치는 지침으로만 사용해야 합니다. 올바른 질문을 하고, 올바른 데이터를 평가하고, 필요한 경우 올바른 테스트를 수행하여 더 나은 정보에 입각한 결정을 내릴 수 있습니다.

마지막으로 트래픽은 성능 퍼즐의 한 부분일 뿐이며 솔루션과 플랫폼을 선택할 때 하나의 결정 요인일 뿐입니다. 다른 요인으로는 캐싱 계층, 데이터베이스 성능, 품질 및 인프라 설계, 고가용성 및 확장성이 있습니다.

모든 비즈니스에는 서로 다른 요구 사항이 있습니다. 기업 고객에게는 충족해야 할 중요한 비즈니스 및 기능적 요구 사항이 있습니다.

AWS Well-Architected 프레임워크의 기둥에 따르면 다음은 최우선 순위입니다.

• 운영 우수성: 시스템을 실행 및 모니터링하여 비즈니스 가치를 제공하고 지원 프로세스 및 절차를 지속적으로 개선하는 능력.
• 보안: 정보, 시스템 및 자산을 보호하는 동시에 위험 평가 및 완화 전략을 통해 비즈니스 가치를 제공하는 능력.
• 안정성: 인프라 또는 서비스 중단에서 복구하고, 수요를 충족하기 위해 컴퓨팅 리소스를 동적으로 확보하고, 구성 오류 또는 일시적인 네트워크 문제와 같은 중단을 완화하는 시스템의 기능입니다.
• 성능 효율성: 컴퓨팅 리소스를 효율적으로 사용하여 시스템 요구 사항을 충족하고 수요 변화 및 기술 발전에 따라 효율성을 유지하는 능력입니다.
• 비용 최적화: 시스템을 실행하여 최저 가격으로 비즈니스 가치를 제공하는 능력.

WP Engine은 이러한 기둥과 일치하는 산업 표준 관행을 따릅니다.

사이트에서 처리할 수 있는 트래픽 양에 대해 자세히 알고 싶으십니까? 여기를 클릭하여 WP Engine의 계획과 관리형 WordPress 호스팅 플랫폼을 활용할 때 고객이 볼 수 있는 이점에 대해 자세히 알아보십시오.