AKAMAI 백서

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드

목차

이커머스 웹 및 모바일 자산 테스트 시작 ..................................................................................... 1

이커머스 기업이 직면한 대표적인 성능 문제 ............................................................................... 2

시작하기: 성능 테스트 체크리스트 .............................................................................................. 2

이커머스 업계의 주요 비즈니스 지표 .......................................................................................... 3

빠른 속도의 기준 ......................................................................................................................... 3

테스팅 팀 구성원 선정 기준 ......................................................................................................... 4

테스트할 때 주목해야 할 사항 ..................................................................................................... 5

성능 테스트의 유형 ...................................................................................................................... 6

운영 환경에서의 테스트와 연구소 내 테스트 비교 ...................................................................... 6

성능 연구소에서 테스트 수행 ...................................................................................................... 7

운영 환경에서 테스트 수행 .......................................................................................................... 8

보안 및 성능 테스트 ................................................................................................................... 10

부록 A: The Akamai Performance Test Methodology ............................................................ 11

부록 B: CloudTest 성능 데이터 Q&A ......................................................................................... 12

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 1

이커머스 웹 및 모바일 자산 테스트 시작치열한 이커머스 산업에서 경쟁하는 이커머스 기업들은 수많은 문제에 직면해 있습니다. 이들

기업은 흥미롭고 매력적인 쇼핑 경험은 당연히 제공해야 함은 물론, 이러한 경험을 안정적이고

빠르게 제공해야 합니다.

온라인 쇼핑객의 절반 가량이 로딩에 2초 이상 걸리는 페이지를 이탈하는 것으로 조사되

었습니다. 기존의 오프라인 매장 환경에서는 현재의 매장에서 빠져나와 다른 매장이 있는 곳으로

직접 이동해야 했습니다. 그러나 웹상에서는 클릭 몇 번이면 쉽게 경쟁사 웹페이지로 이동할 수

있습니다.

페이지 로딩 속도 개선은 전환율과 매출 증가로 직결되는 검증된 전략입니다.

Walmart.com의 경우 로딩 시간이 1초 단축될 경우 전환

율이 2% 증가했습니다. Staples.com은 평균 로딩 속도를

1초 단축한 결과 전환율이 무려 10% 증가했습니다.

사이트가 느리거나 다운되면 고객 유지에 장기적인 타격을 줍니다.

사이트 장애와 속도 저하의 영향을 받는 지표는 매출

뿐만이 아닙니다. Akamai는 장애와 속도 저하가 각각

이커머스 사이트의 이탈률에 어떤 영향을 미치는지를

연구했는데 그 결과는 상당히 놀라웠습니다. 다운된 적이

있는 사이트의 평균 영구 이탈률은 9%였고, 속도가 느린

사이트의 평균 영구 이탈률은 28%를 기록했습니다.

운영 환경에서의 테스트 수행은 온라인 애플리케이션의 성능이 예상대로 발휘되도록 보장하는 유일한 방법입니다.

운영 인프라에 대한 외부 테스트는 실제 환경에서의 역량과 성능을 제대로 파악하는 데 가장 효과적인 방법입니다.

그렇다고 해서 연구소 환경에서 수행하는 테스트가 필요 없다거나 이 테스트로 얻는 이점이 없다는 의미는 아닙니다.

두 가지 테스트 유형 사이의 연속성을 유지하는 것이 중요합니다.

어떻게 해야 기업의 온라인 쇼핑몰 사이트가 탁월한 쇼핑 경험을 제공하고 특정 시즌, 이벤트, 프로모션 시에 발생하는

트래픽 폭주를 처리할 수 있도록 보장할 수 있을까요? 그리고 웹사이트의 성공은 어떻게 측정해야 할까요?

이 가이드에서는 다음 질문의 해답은 물론 다음과 같은 사안에 대한 답도 찾을 수 있습니다.

• 이커머스 기업이 직면한 대표적인 성능 문제

• 성능 테스트 체크리스트에 포함되어야 하는 사항

• 이커머스 업계의 주요 비즈니스 지표

• 테스팅 팀 구성원 선정 기준

• 수행해야 할 테스트의 유형

• 테스트할 때 주목해야 할 사항

• 연구소에서 테스트해야 하는 이유 운영 환경에서 테스트해야 하는 이유

그럼, 이제 본론으로 들어가 보겠습니다.

44%온라인 트랜잭션 속도가 느릴 경우 트랜잭션이 제대로 이루어졌는지 확신이 서지 않는다고 응답한 사용자의 비율

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 2

이커머스 기업이 직면한 대표적인 성능 문제온라인 쇼핑몰은 오프라인 매장과 유사한 경험을 제공하기 위해 노력합니다. 쇼핑객들은 오프라인 매장에 들러 제품을

직접 보고, 만져보고, 사용해 본 후에 구매 여부를 결정하는 데 익숙해져 있기 때문입니다.

웹에서는 매장과 동일한 수준의 상호 작용을 제공할 수는 없지만, 비디오, 추천 엔진, 사용자 리뷰, 다양한 각도에서

제품을 촬영한 고해상도 이미지, 의류를 가상으로 입어 볼 수 있는 도구 등 다양한 기능에 힘입어 이커머스 웹사이트는

과거보다 훨씬 다채로운 쇼핑 경험을 제공합니다.

물론 브랜드를 온라인으로 전달하는 데에 따른 과제도 있습니다. 스타일시트와 맞춤형 글씨체 사용해 브랜드를

효과적으로 표현할 수는 있겠지만 이러한 기능은 사이트의 성능과 가용성에 영향을 줄 수 있다는 점이 문제입니다.

특정 디자인 목표를 캡처하는 데 사용되는 고용량 콘텐츠와 성능 간의 균형을 유지하기는 매우 어렵습니다.

또한 결제 처리, 승인, 재고 검사 등을 위한 백엔드 시스템 또한 성능 문제를 더욱 가중시킬 수 있습니다.

그리고 사용자 리뷰부터 사용자 정의 글꼴, 결제 처리에 이르는 이러한 기능 중 상당수가 써드파티에 의해 제작 및

호스팅되고 있습니다. 이러한 콘텐츠는 사이트에 기능이나 정보를 추가로 제공하겠지만 그만큼 트래픽과 복잡성을 한

차원 더 가중시키기 때문에 관리하기가 매우 어렵습니다.

이러한 모든 콘텐츠의 영향을 제대로 이해하는 것이야말로 사이트 성능을 전반적으로 관리하는 데 매우 중요합니다.

시작하기: 성능 테스트 체크리스트성능을 성공적으로 활용하려면 테스트 전략을 성공적으로 수립해야 합니다. 이를 위해서는 가장 먼저 사용자가

이커머스 사이트에서 어떻게 상호 작용하는지를 이해해야 합니다.

예를 들어, 다음 정보는 테스트 참여 전략을 정의하는 데 매우 중요합니다.

• 사이트 방문자가 따르는 주요 비즈니스 프로세스(흐름)

• 사용자가 평균적으로 사이트에 머무르는 시간

• 구매를 완료하는 사용자와 구경만 하고 구매하지 않는 사용자의 평균 비율

• 이탈률 및 사용자 이탈이 발생하는 프로세스 내의 단계

• 시간당 평균 및 최대 동시 사용자 수

• 분/시간당 평균 및 최대 페이지 조회 수

• 분/시간당 평균 및 최대 주문 수

• 특정 이벤트(예: 블랙 프라이데이, 사이버 먼데이) 시 위 지표의 트래픽 패턴 차이

• 사이트 트래픽을 발생시키는 국가의 지리적 분포

• 모바일 디바이스에서 발생하는 트래픽 비율, 디바이스 유형, 사용자 흐름의 차이, 위 지표의 영향

• CDN이 사용될 경우 CDN에서 제공되는 콘텐츠 비율

이러한 정보는 성공적인 성능 테스트 전략을 정의하고 테스트의 설계 및 실행 방법을 구체화하는 데 도움을 줍니다.

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 3

이커머스 업계의 주요 비즈니스 지표 이커머스 사이트에는 다음과 같이 사이트의 성능 측정을 돕는 특정 KPI(핵심 성과 지표)가 있습니다.

• 분당 주문 수 — 이커머스 사이트에서 특정 기간 동안 완료된 거래 수는 대단히 중요한 표준 KPI입니다. 주문은

매출로 직결됩니다.

• 시간 또는 분당 페이지 조회 수 — 고객은 사이트를 효율적으로 사용할 수 있을 때만 주문을 완료합니다. 사용자가

검색, 비교, 트랜잭션할 때 웹 콘텐츠를 적시에 제공하는 일은 이커머스 사이트에 매우 중요합니다.

• 시간당 세션 수 — 세션은 사이트와 트랜잭션하는 개인 사용자 또는 시스템을 나타냅니다. 이러한 사용자가

트랜잭션하는 기간 동안 세션을 만들고 유지할 수 있는 환경을 유지하는 일이 중요합니다.

• 오류 — 당연한 말이기는 하지만, 전체 오류율과 발생하는 오류 유형을 추적하는 일도 중요합니다. 오류라고 해서

모두 동일한 것은 아닙니다.

• 평균 응답 시간 — 페이지와 페이지 자산을 제공한 평균 시간을 이해하는 것은 잠재적인 병목 현상을 파악하기

위해 중요합니다. 또한 이 지표는 이커머스 사이트의 유용성을 측정하는 수많은 고객을 위한 기반이기도 합니다.

• 90 백분위수 응답 시간 — 이 정보가 있으면 응답 시간을 더욱 상세히 파악할 수 있습니다. 90 백분위수는 가장

느린 10%의 응답 시간을 제거합니다. 그 결과 시간제한(평균 120초)을 없애고 90%의 사용자에 대한 솔직한

응답을 확인할 수 있습니다.

빠른 속도의 기준:우수한 사이트 성능을 원하는 이커머스 기업의 평균 응답 시간은 3초 미만이었고, 90 백분위수 응답 시간은 2.75초

미만이었습니다.

사이트가 최고의 성능을 발휘하기를 원하는 이커머스 기업은 ‘속도가 빠르다’는 말이 실제로 얼마나 빠른 속도를

의미하는 것인지 알아야 합니다.

페이지 유형마다 각각의 사용자의 기대가 다르다는 사실을 감안해야 합니다. 예를 들어, 사이트를 둘러보고 있는

사용자는 사이트가 초고속으로 응답하기를 기대하지만, 최종 결제 단계에서는 시간이 약간 걸릴 것이라 예상하는 것이

일반적입니다.

이커머스 사이트가 150–200%의 예상 트래픽 폭주에 대한 테스트를 수행하면서 목표 수준의 성능을 유지할 수 있다면

이 이커머스 기업은 어떤 마케팅 이벤트나 성수기 시즌에도 확실하게 대비할 수 있습니다.

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 4

테스팅 팀 구성원 선정 기준테스트를 제대로 수행하려면 적합한 인력을 투입해야 합니다.

올바른 인력으로 팀을 구성하면 테스트를 훨씬 더 생산적으로 진행할 수 있습니다. 올바른 팀을 배치하면 문제가

발생해도 문제를 빠르게 처리하고 실행 가능한 인텔리전스가 제공될 때 이에 대한 결정을 신속하게 내릴 수 있습니다.

회사와 직원의 규모, 사이트의 규모, 테스트의 복잡성, 사이트 내 써드파티 애플리케이션 배포 또는 사이트 개발의

아웃소싱 여부, 인프라를 위해 관리형 서비스 사업자 사용 등의 다양한 요소가 테스트에 투입할 인력의 규모를

결정하는 데 영향을 줍니다.

한두 명의 인력이 테스트 전반을 처리하는 경우도 있지만, 사이트의 전면적인 재구축, 성수기 시즌을 대비하기 위한

인기 사이트 테스트 등의 작업에 대해서는, 아키텍트부터 인프라의 특정 요소를 책임지는 개인 기여자에 이르기까지

다양한 역할을 담당하는 여러 명의 인력으로 구성되어야 합니다.

테스트 전략의 일환으로 짚고 넘어가야 할 업무는 다음과 같이 다양합니다.

• 조율 — 모든 주요 관계자들과 함께 테스트 활동을 조율합니다. 여기에는 애플리케이션 엔지니어링 팀, 운영 팀,

벤더, 써드파티 인터넷 연결 서비스, 비즈니스 및 고위 임원이 모두 포함됩니다.

• 소통 — 비즈니스 및 엔지니어링 임원에게 테스트 결과, 문제, 문제 해결 방안, 전반적인 전략에 대한 진척 상황을

보고합니다.

• 전략 — 애플리케이션, KPI(핵심 성과 지표), 용량 계획, 모니터링 지원 범위 및 소프트웨어 개발 라이프 사이클의

성능 관리 단계로 이어지는 개별 테스트 계획을 포함한 전반적인 전략을 정의합니다.

• 아키텍처 — 신규 프로젝트에 기존 애플리케이션의 업그레이드에 참조할 고성능 애플리케이션 및 인프라

아키텍처 생성과 관련된 모범 사례를 제공합니다.

• 테스트 생성 — 비즈니스 프로세스 정의를 실행 가능한 테스트로 전환하여 용량 계획을 토대로 개별 성능 테스트

업무를 세분화하고 최신 테스트 사례 라이브러리를 꾸준히 유지관리합니다.

• 테스트 실행 — 성능 연구소와 운영 환경에서 성능 테스트를 지속적으로 실시하고 테스트 결과를 도출합니다.

• 분석 — 모든 환경에서 테스트 결과를 검토하고 이전 테스트와 비교하여 성능을 분석합니다. 수립된 성공 기준을

위반하는 사항, KPI를 준수하지 않는 임계값, 이전의 기준 테스트에서 파생된 값을 모두 파악합니다.

• 진단 — 발생하는 병목 현상 또는 성능 문제의 근본 원인을 분석합니다. 도메인 지식과 프로파일러, 메모리 유출

탐지기 같은 특수 도구와 모니터링 도구를 사용하여 문제가 있는 영역을 탐지해 냅니다.

• 튜닝 — 튜닝 업무에는 모범 사례와 튜닝 권장 사항을 적용하고 애플리케이션 또는 인프라에서 성능 또는 용량

개선을 위해 최적화 가능한 부분을 분리하는 업무가 포함됩니다.

• 측정 — 전반적인 전략에 대한 활동과 진척 상황을 분석하고, 모든 전략적 또는 전술적 활동을 최적화하기 위한

프로세스 개선 권장 사항을 수립합니다.

한 사람이 이러한 모든 업무를 담당하는 소기업에서는 테스트 전략, 생성, 실행 및 분석 업무에 대해 Akamai의 도움을

받을 수 있습니다.

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 5

이러한 역할의 일부 또는 전부를 아웃소싱하면 전문 기업의 전문성을 활용하고, 고객사는 더욱 집중해야 하는 부분에

역량을 집중하고 비용을 절감할 수 있습니다.

일반적으로는 여러 개인과 직책이 이러한 업무를 함께 수행합니다. 예를 들어, 프로젝트 매니저, 성능 엔지니어 및/또는

전문가가 있으면 기술 리드가 필요 없어지기 때문에 이 사람은 전체 프로세스에서 다른 업무를 지원할 수 있습니다.

아래는 일반적인 역할/직책과 담당하는 업무들을 설명한 것입니다.

• 프로젝트 매니저 — 조율, 소통

• 기술 리드 — 조율, 통신, 전략, 아키텍처, 분석, 진단, 튜닝, 측정

• 아키텍트 — 인프라 아키텍처, 앱 아키텍처

• 성능 엔지니어 — 전략 개발, 아키텍처, 분석, 진단, 튜닝, 측정

• 테스트 엔지니어 — 테스트 생성, 실행, 분석

• 전문가 — 진단, 튜닝

테스트할 때 주목해야 할 사항이커머스 사이트의 속도에 영향을 미치는 요소를 이해하면 테스트 업무의 초점을 잡을 수 있습니다.

수많은 이커머스 사이트는 매우 복잡하며, 무수한 구성 요소와 애플리케이션 계층으로 이루어져 있습니다. 각 구성

요소를 이해하고 서로 어떻게 상호 작용하는지를 이해하는 것이 중요합니다.

다음은 테스트를 수행하는 동안 집중해야 할 일반적인 부분입니다.

• 애플리케이션 문제 — 완벽한 코드란 존재하지 않습니다. 비효율적인 코드, 동기화 문제, 가비지 수집, 메모리

유출, 애플리케이션 데드락(dead lock)이 발생했는지 유심히 살펴봐야 합니다.

• 데이터베이스 성능 — 데이터베이스 성능은 가장 핵심에 속합니다. 잠김, 경합, 색인 누락, 비효율적인 쿼리,

메모리 관리, 연결 관리, 관리되지 않는 데이터 증가가 발생했는지 유심히 살펴보십시오.

• 구성 설정 — 기본 설정이 최적화 상태인 경우는 거의 없습니다. 각 환경 간의 차이를 파악해 아키텍처 내 다양한

디바이스의 튜닝 옵션과 모범 사례를 이해합니다.

• 부하 분산 — 하드웨어를 효율적으로 사용합니다. 최적화되지 않은 알고리즘과 제대로 사용되지 않는 기능과

역량을 유심히 살펴봐야 합니다.

• 연결성 — 통신은 매우 중요합니다. 시스템이 최소한의 지연으로 통신할 수 있는지, 방화벽의 용량이 충분한지,

시스템이 모바일 네트워크에 최적화되었는지, DNS 라우팅이 올바른지, CDN 캐싱이 최적화되었는지 확인해야

합니다.

• 대역폭 — 웹사이트가 문제 없이 열리는지 확인해야 합니다. 제공되는 대역폭이 모든 트래픽을 수용하기에

충분한지 확인하십시오. 페이지를 구성하는 콘텐츠를 검토합니다. 고용량 콘텐츠는 데이터와 대역폭 요구 사항이

매우 높습니다. 사이트가 모바일 디바이스를 포함해 다양한 연결 유형/속도를 지원할 수 있는지 확인하십시오.

• 아키텍처 — 성능에 맞는 웹사이트를 설계해 보십시오. 불균형한 계층, 어울리지 않는 기술 조합, 확장할 수 없는

경로가 있는지 확인하십시오.

• 써드파티 서비스 — 웹사이트가 아무리 빠르더라도 느린 페이지가 하나라도 있으면 전체 사이트 속도는 가장 느린

페이지로 맞춰집니다. 분석 및 추적 기능, 결제 시스템, 수집된 콘텐츠, 소셜 네트워크, CDN 등이 사이트의 속도를

떨어뜨리고 있지는 않은지 확인해야 합니다.

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 6

성능 테스트의 유형어떤 테스트를 수행해야 하는지를 알아야 할 때가 많습니다.

테스트 수행 옵션에는 기준, 응력, 트래픽 폭주, 지속성, 장애 복구 등 여러 가지가 있습니다. 이커머스 기업에는 이러한

모든 옵션이 중요합니다.

기준이커머스 기업은 '평균적인 부하’ 상태에서 허용 가능한 성능에 대한 기준을 마련해야 합니다. 최근 6개월에 대한

분석을 수행하고 하루 중 트래픽이 가장 많은 시간을 추려내 이것을 시간당 페이지 조회 수와 분당 주문 수에 대한 평균

부하 값으로 사용하는 것이 좋습니다.

스트레스유통업체는 스트레스 테스트를 수행하여 장시간 부하가 집중되더라도 사이트의 성능이 저하되지 않도록 해야 합니다.

스트레스 테스트를 수행하지 않으면 메모리 유출이나 잘못된 가비지 수집으로 성능 문제가 발생해도 이를 파악하지

못하는 경우가 많습니다. 예상 트래픽 폭주를 150–200%로 설정한 상태에서 스트레스 테스트를 수행하는 것을

권장하니다.

트래픽 폭주(Spike)트래픽 폭주 테스트는 사용자 수가 급격히 증가하는 현상을 테스트하는 것이며, 유통업체에 필수적인 테스트입니다.

유통업체들은 깜짝 세일, 블랙 프라이데이, 사이버 먼데이, 발렌타인데이 등의 다양한 이벤트를 여는데, 이 기간 동안

사이트에는 막대한 트래픽 폭주가 발생합니다. 따라서 그러한 이벤트 기간 동안 웹사이트의 성능 저하로 인해 쇼핑객이

이탈하거나 주문을 포기하는 경우가 발생하지 않도록 해야 합니다. 예상 트래픽 폭주를 200%로 설정한 상태에서

트래픽 폭주 테스트를 수행하는 것이 좋습니다.

지속성지속성 테스트는 스트레스 테스트와 그 규모 면에서 차이가 있습니다. 스트레스 테스트가 페이지 조회 수와

주문 건수가 매우 많은 상태에서 이루어지는 반면 지속성 테스트는 장기간 동안 상대적으로 더 적은 부하를

시뮬레이션합니다. 이러한 테스트는 장시간에 걸쳐 성능 저하가 발생할 수 있는 추가적인 영역을 파악할 수 있다는

점에서 매우 중요한 의미를 갖습니다. 일괄 작업, 데이터베이스 백업, 캐시 새로 고침 등의 작업을 예약하여 반복

실행되게 할 수 있습니다. 장시에 걸쳐 지속성 테스트를 수행하면 이러한 유형의 이벤트가 성능에 미치는 영향을

파악할 수 있습니다.

장애 복구대부분의 유통업체에는 장애 발생 시 적절하게 대처하는 재해 복구 또는 장애 복구 서버가 있습니다. 다량의 트래픽이

발생하는 기간 동안 하드웨어 장애가 발생하면 백업 하드웨어가 이를 알아서 감지하고 처리할 수 있을까요? 장애 복구

테스트를 수행하지 않고서는 절대로 알 수 없습니다.

초기 테스트에서는 단순히 사이트의 성능 특성을 이해하는 것을 목표로 하는 경우가 많습니다. 이러한 테스트에서는

트래픽 증가 속도가 상대적으로 느리고 좀 더 조직적으로 나타나는 경향이 있습니다.

이러한 기준이 정해지고 사이트의 처리 성능을 어느 정도 파악한 후에는 테스트를 최대한 현실적으로 수행하는 것이

중요합니다. 여기에는 현실적인 사용자 수준과 증가 속도가 포함됩니다. 전년도 분석 결과를 검토하는 것도 사용자

증가 수준을 예측하는 데 도움이 됩니다.

절대로 테스트를 편법으로 수행해서는 안 됩니다. 대기 시간을 변경하거나 테스트의 주요 구성 요소를 삭제하지 않아야

합니다. 이러한 정보를 변경하거나 제거하면 결과가 왜곡되고 테스트의 실효성이 떨어지기 때문입니다.

운영 환경에서의 테스트와 연구소 내 테스트 비교성공적인 테스트를 위해서는 효과적인 이커머스 테스트 전략이 필요합니다. 전략 구현을 위해 팀을 적절히 배치하면

성공적으로 테스트를 수행할 수 있습니다. 성공적인 테스트를 수행하려면 운영 환경에서 테스트할 때의 장점과 성능

연구소에서 테스트할 때의 장점을 제대로 이해해야 합니다.

다양한 유형의 테스트를 다양한 환경에서 수행하는 것은 이커머스 사이트의 아키텍처에 발생할 수 있는 복잡한 병목

현상을 감지하고 해결하기 위해 매우 중요합니다.

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 7

운영 테스트가 필수 요소인 환경에서 엔드투엔드 테스트 계획 구축

네트워크 및 운영

출시 및 배치

단계

및 팀

SCALE OF TEST

개발 및 테스트

테스트 연구소 단계 운영 환경(100%+++)

느린 페이지

메모리 유출

가비지 수집

기본 설정

느린 써드파티 플러그인

최대 소켓 수 초과

자동 확장 실패

부하 분산 장치 설정

다른 앱과 충돌

네트워크 대역폭

네트워크 설정

시스템 간 지연

메소드 수준 튜닝

비효율적인 데이터베이스 쿼리

데이터베이스 스레드 수

부적절한 서버 리소스

검색 용어 제한

고르지 않은 글로벌 지연 시간 문제

웹 서버의 불균형

방화벽 최대 용량

DNS 라우팅

CDN 파일 배치

테스트 규모

위 그림은 최적의 성능을 실현하기 위해 연구소와 운영 환경에서 수행되는 각 유형의 테스트가 어떤 특정 문제를

감지하는 데 도움이 되는지를 보여줍니다.

성능 연구소에서 테스트 수행연구소에서 계속 진행되는 성능 테스트를 통해 애플리케이션 엔지니어링 팀은 시간 경과에 따른 성능을 평가하고

치명적인 성능 버그가 운영 환경에 도달하기 전에 감지·차단할 수 있습니다.

또한 연구소는 운영 환경과 일반 빌드 주기 밖에서 변경을 적용하기 전에 성능 회귀를 위한 성능 테스트 코드와 설정

변경사항을 미리 테스트해 볼 수 있다는 장점이 있습니다. 여기에는 페이지의 빠른 버그 픽스, 성능 저하를 야기할 수

있는 사소한 설정 변경 등이 포함됩니다. 테스트를 거의 또는 아예 행하지 않고 이러한 유형의 변경을 적용하여 추후

성능 문제가 발생하는 경우가 많습니다.

또한 연구소에서 테스트를 수행하면 사용자에 영향을 줄 수도 있다는 걱정 없이 시스템을 중단할 수 있습니다.

이커머스 사이트가 장애 발생 시에 어떻게 대응하고 복구하는지를 이해하는 것이 중요합니다. 운영 중인 사이트가

중단되기를 원하는 사람은 없을 것입니다.

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 8

Akamai CloudTest Methodology는 트래픽 폭주에도 온라인 애플리케이션이 작동할 수 있도록 하는 일련의 경량 프로세스가 포함된 소프트웨어 QA 성능 테스트 전략입니다.

Akamai CloudTest Methodology

전략 구현 실행 측정

정의 인력 정의 분석

통합 프로세스 디자인

테스트

점검

조정

운영 환경에서 테스트 수행사이트 성능에 대한 신뢰를 쌓으려면 해당 사이트를 실제 환경에서 테스트해야 합니다.

언제든 사이트에 접속하는 사용자 수가 폭증할 수 있기 때문에 스테이징 환경이나 성능 연구소에서 운영 환경을 복제할

수 있는 기업은 극히 드뭅니다. 운영 환경에서 테스트를 수행하면 실제 환경에서의 역량과 성능을 제대로 파악하는 데

가장 효과적인 방법입니다. 그리고 온라인 애플리케이션의 성능이 예상대로 발휘되도록 하기 위한 유일한 방법입니다.

예전부터 테스트는 연구소 내 여러 대의 서버에 대해 수행되는 앱 테스트가 운영 환경에 가해지는 막대한 부하도

지원할 수 있다는 가정을 전제로 이루어져 왔습니다. 그러나 적절한 테스트를 행하지 않으면 이러한 가정은 예기치

못한 장벽에 부딪힐 수 있습니다.

운영 환경에서 테스트해야만 탐지할 수 있는 문제도 있습니다

연구소 테스트로는 탐지가 불가능한 문제의 대표적인 예는 다음과 같습니다.

• 연구소에서 수행할 수 없는 일괄 작업(로그 회전, 백업 등) 또는 성능에 영향을 주는 다른 온라인 시스템의 영향

• 알고리즘 설정 오류 같은 부하 분산 장치의 성능 문제

• 스위치에 1GB 대신 100MB로 잘못 설정하거나 라우팅 문제 등의 네트워크 설정 문제

• 대역폭 제한

• 트래픽 폭증 시 ‘버스트 불가’로 설정된 데이터 파이프

• 애플리케이션 버블 내외부에서 시스템 간 지연

• 잘못 설정된 애플리케이션 서버 또는 웹 서버

• 새 콘텐츠를 서비스하도록 설정되지 않은 CDN

• 데이터베이스 크기에 따라 성능이 현격히 차이 나는 문제

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 9

CDN(콘텐츠 전송 네트워크)

대다수의 테스트 연구소가 CDN을 인프라의 일부로 두지 않고 있습니다. 따라서 운영 환경에서 테스트하지 않고서는

CDN이 성능에 미치는 영향을 테스트하는 것이 불가능합니다.

유통업체가 운영 환경에서 테스트를 수행하면 CDN의 캐싱/부하 분산 기능을 완전히 테스트할 수 있습니다. 이것은

운영 환경의 실제 성능을 이해하는 데 꼭 필요한 부분입니다.

운영 환경 내 테스트를 준비할 때에는 CDN 사업자가 이러한 프로세스 초반에 참여하여 운영 테스트를 수행하는 동안

CDN 사업자의 지원을 받는 것이 무엇보다도 중요합니다. (Akamai는 CDN 자산을 포함하는 테스트에 대한 일련의 모범

사례를 확립했습니다.)

2천 개 이상의 스토어를 보유하고 매출액 수십억 달러 규모의 유통업체에 근무하는 성능 전문 엔지니어인 한 Akamai

고객이 CDN을 운영 테스트의 핵심 부분으로 도입할지를 고려하고 있습니다.

“운영 환경에서 테스트를 수행할 때, 우리는 보통 Akamai 캐싱 기능을 설정해 놓습니다. 이것은 오리진(메인 사이트)에

도달하는 요청 수에 관한 테스트와 해당 페이지가 Akamai와 오리진 중 어디에서 서비스를 받는지에 따른 응답 시간

테스트에 분명히 영향을 줍니다. 연구소에서는 Akamai를 포함시키지 않을 가능성이 높습니다. 다시 말해, 운영

테스트에 CDN을 포함시키지 않으면 회사의 운영 성능을 제대로 파악할 수 없습니다.”

써드파티 콘텐츠

많은 이커머스 사이트는 써드파티 제공업체를 사용해 사이트 콘텐츠를 전체적으로 개선합니다. 따라서 테스트 전략을

구상할 때 성능에 영향을 미칠 수 있는 이러한 써드파티 제공업체를 고려하는 것이 중요합니다.

반면 통상적으로 Google Analytics나 Omniture 지표 같은 도메인을 테스트의 일부로 포함시키지는 않을 것입니다. 허위

트랜잭션으로 서비스 또는 사이트의 성능이 저하되거나 중단되는 것을 원치 않기 때문입니다.

써드파티 사업자를 프로세스 초기에 포함시키면 이들의 지원을 확실하게 받을 수 있다는 장점이 있습니다. 프로세스

내에서 측정 대상이 되기를 원할 수도 있습니다. 결국 안정적이고 강력한 성능의 사이트를 구축하는 것이 공통의

목표이기 때문입니다.

라이브 고객에 대한 잠재적 영향

운영 환경 내 테스트는 해당 환경에 라이브 사용자가 있을 때 수행할 수도 있고 없을 때 수행할 수도 있습니다. (참고:

Akamai CloudTest를 사용해 운영 환경에서 테스트하는 고객의 대부분은 라이브 환경에서 테스트를 수행합니다.)

이것이 가능하기는 하지만 항상 실행할 수 있는 것은 아닙니다. 유지 관리를 하거나 페이지 접속을 차단하는 리스크를

무릅써야 하고 기존의 사용자 세션이 완료될 때까지 기다려야 하기 때문입니다. 현실에서는 이 방법은 거의 사용되지

않습니다. 올바른 툴과 방법이 있다면, 가장 극단적인 상황이 아닌 이상 사이트에 사용자가 활동 중인 상태에서

테스트를 수행할 수 있기 때문입니다.

한 Akamai 고객은 “테스트를 안 할 경우 발생하는 비용은 라이브 고객에게 미치는 잠재적인 영향보다 훨씬 크다”고

설명합니다.

올바른 접근 방식을 채택하면 테스트하는 동안에도 매출을 계속해서 늘릴 수 있습니다. 트래픽이 적은 기간 동안

라이브 환경을 분할하여 하위 환경에 대한 테스트를 각각 수행할 수도 있을 것이고, 데이터 센터 한 곳에 대한 테스트를

수행하는 동안 라이브 사용자를 다른 데이터 센터로 우회시키는 것도 한 방법일 것입니다.

일반적으로 부하 분산 장치에는 별도의 IP 주소가 설정되고 서버가 라이브 풀에서 테스트 풀로 이동 배치됩니다. 경우에

따라 다른 공유 구성 요소에 대한 설정 변경이 필요할 수 있습니다. 그러나 이 방법은 하드웨어가 추가로 필요하고

유지 관리 오버헤드가 발생하기 때문에 비용이 더 많이 듭니다. 또한 실제 운영 환경 설정에서 약간의 변화를 주기

때문에 다소 안정적이지 않을 수 있으며 실제 규모로 테스트할 수 없습니다. 그럼에도 불구하고 이 방법은 연구소에서

수행하는 단순 테스트에 비해서는 현실에 가까운 테스트입니다.

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 10

성공적인 라이브 테스트를 위한 세 가지 요건

1. 실시간 분석라이브 고객이 있는 상태에서 대규모 테스트를 수행하기 위한 첫 번째 요건은 테스트 도구에 실시간 분석 기능을

갖추는 것입니다. 사이트 성능에 관해 초 단위로 업데이트되는 정보를 사용하여 사이트에 성능 저하가 발생하기

시작하는지 또는 아예 응답하지 않는지를 신속하게 확인할 수 있습니다.

2. 고성능 ‘킬스위치(kill switch)’실행 중인 성능 테스트에서는 부하를 즉시 중단할 수 있는 ‘중지’ 또는 ‘중단’ 버튼이 반드시 필요합니다. 이 기능을

사용하면 대역폭, 동시 연결, 사용 중인 스레드 및 그 외 전형적인 병목 구간이 정상 상태로 떨어집니다.

3. 체계적인 내부 모니터링 관행끝으로, 테스트 솔루션과 통합된 바람직한 모니터링 업무 방식이 내부에 마련되어 있으면 라이브 사용자의 영향으로

인해 테스트를 중지해야 하는 일이 발생하지 않습니다. CPU 활용률, 최고 사용량, 가비지 수집, 부하 분산 장치 또는

방화벽의 연결 횟수 등을 실시간으로 확인할 수 있어 일상적인 테스트로 인해 이러한 임계값에 대한 위반을 미연에

방지할 수 있습니다.

보안 및 성능 테스트문제가 발생하기 전까지는 잘못된 부분을 알아차리지 못하는 것이 바로 보안입니다. 일상에서 쉽게 접하는 뉴스는

고객의 데이터를 안전하고 확실하게 보호하고 있는 우수 기업의 사례가 아니라, 고객 정보 유출이 발생한 기업에 관한

이야기입니다.

데이터 보안은 성능 테스트를 수행할 때 고민하는 주요 과제 중 하나입니다. 기업들은 자사의 데이터가 기업 방화벽

외부로 나가는 것을 원치 않습니다.

성능 테스트 솔루션은 다음과 같은 요건을 충족해야 합니다.

• 비즈니스와 보안 요건에 따라 가상 데이터를 생성하거나 스크러빙된 데이터를 사용

• 보고, 분석, 진단 목적으로 주요 HTTP/HTTPS 지표와 통계 데이터만을 캡처

• 데이터의 안전을 보장하는 엄격한 보안 정책을 적용

반면 다음 사항은 절대로 수행해서는 안 됩니다.

• 데이터나 애플리케이션을 내보낼 것을 요청

• 테스트 서버 또는 결과 데이터베이스의 응답 콘텐츠를 저장

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 11

부록 A: Akamai Performance Test Methodology

Akamai의 방법론은 여러 장소에서 다양한 테스트를 수행하는 것은 '백사장에서 바늘 찾기'와 다를 바가 없음을

강조합니다.

Akamai CloudTest Methodology

Akamai Performance Test Methodology는 트래픽 폭주에도 온라인 애플리케이션이 작동할 수 있도록 하며, 소프트웨어

개발 라이프 사이클에 포함될 수 있는 일련의 경량 프로세스가 포함된 소프트웨어 QA 성능 테스트 전략입니다. 이

방법에는 고객이 사용하는 운영 인프라 테스트를 위한 프로세스와 방화벽 내부의 연구소 환경에서의 애플리케이션

테스트 수행이 포함됩니다.

클라우드 테스트는 효율적인 클라우드의 장점을 테스트 웹 애플리케이션과 사이트에 활용합니다. Akamai 고객은

Amazon Web Services와 Rackspace 같은 기업이 제공하는 서비스와 인프라를 사용하여 부하 및 성능 테스트 비용을

절감하고 사이트의 실제 트래픽을 더욱 정확하게 재현할 수 있습니다. CloudTest는 방화벽 뒤에 완전히 배치하거나

온프레미스와 클라우드 기반 설정을 조합하여 배치할 수 있는 분산형 아키텍처입니다.

다년간 축적한 클라우드 환경 내 테스트 경험을 바탕으로 하는 Akamai의 이러한 방법은 기존의 모범 사례와 검증된

성능 테스트 방법을 활용함으로써 기존의 접근 방식을 확장하여 다음과 같은 새로운 기회를 포착하고 과제를 해결해

줍니다. 구체적인 내용은 다음과 같습니다.

• 연구소 환경 내 테스트와 운영 환경 내 라이브 웹 기반 애플리케이션 테스트를 모두 수행

• 사용자 수백 명부터 수백만 명에 이르는 정상 트래픽 수준과 트래픽 폭주 상황 모두에 클라우드를 활용하여 테스트

수행

• 민첩한 성능 테스트를 현실적인 대안으로 만듦으로써 개발 주기 시간 단축의 요구에 부합

• 가장 정확하게 재현된 현실적인 트래픽에 여러 지역으로 분산된 부하를 발생시킴

• 연구소 환경과 운영 환경에 대해 내·외부 부하를 발생시켜 가장 효율적이고 효과적인 결과 도출

• 성능 인텔리전스를 실시간으로 분석하여 문제를 조속히 해결

전략과 계획

Akamai의 성능 엔지니어링 접근 방식은 관련 개별 테스트 계획이 마련된 우산 전략(umbrella strategy)입니다.

테스트 계획을 전체적인 보기로 배포하여 핵심 매출 창출 애플리케이션의 성능이 예상대로 발휘될 것이라는 확신을

심어줍니다.

그 결과 사이트의 진화까지 반영하는 지속적인 성능 엔지니어링 전략이 구축됩니다.

여기에는 휴가철 또는 연말연시 준비와 같은 개별 목표 다수의 테스트 계획, 주요 아키텍처 변경, 주요 코드 릴리스

등이 포함됩니다.

체계적인 전략과 명확한 테스트 계획이 마련되면 비즈니스 및 엔지니어링 리더는 운영할 준비를 확실히 했다고 확신할

수 있습니다. 이 방법을 사용하면 애플리케이션의 성능을 더욱 심층적으로 파악할 수 있습니다.

규정된 목표를 달성하기 위해 테스트 계획 내에서 반복 프로세스를 사용하면 테스트되는 애플리케이션을 꾸준히

개선할 수 있습니다.

테스트 정의에서 시작해 실행 가능한 인텔리전스 결과를 획득하는 것으로 마무리할 수 있습니다.

테스트 계획 수립 프로세스의 1단계는 정의 단계입니다. 이 단계에서는 사이트 전체에 대한 테스트 흐름 정의,

모니터링할 지표 수립, 테스트를 위한 성공 기준에 대한 동의가 이루어집니다. 설계 단계에서는 사용자 시나리오를

작성하고 테스트 매개 변수를 설정합니다. 다양한 사용자가 애플리케이션의 여러 부분을 실행하는 사용자 조합, 가상

사용자 타겟, 진입 시간 등이 모델링됩니다.

테스트 단계에서는 테스트를 실행하고 평가에 사용할 데이터를 수집합니다.

끝으로, 테스트 실행의 일부로 이루어질 수도 있는 평가 단계에서는 테스트를 실행하면서 수집된 데이터를 사용하여

실행 가능한 인텔리전스를 도출합니다.

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 12

부록 B: CloudTest 성능 데이터 Q&A

성능 데이터란 무엇입니까?

매우 다양한 종류의 성능 데이터가 성능 테스트의 일부로 활용됩니다. 성능 데이터는 마스터 데이터, 사용자가 생성한

데이터, 외부 데이터의 3가지로 크게 나뉩니다. 마스터 데이터는 일반적으로 고객의 데이터베이스에 존재하며

비즈니스를 수행하는 데 필요한 데이터입니다(사용자 이름, 암호 등). 사용자가 생성한 데이터란 애플리케이션에서

편집 가능한 필드에 사용자가 입력한 모든 정보를 말합니다(새로운 이메일 주소, 새로운 주소 등). 외부 데이터란

애플리케이션을 실행하면서 발생하는 데이터입니다(확인 번호, 세션 ID 등).

테스트 중에는 어떤 데이터가 사용됩니까?

필요한 데이터는 테스트되는 애플리케이션과 비즈니스 프로세스에 따라 달라집니다. 예를 들어, 정적 사이트에는

요청 수행을 위해 사이트의 접속 정보 외에는 별다른 성능 데이터가 필요하지 않지만, 좀 더 복잡한 애플리케이션에는

위에서 설명한 세 가지 유형의 성능 데이터 모두가 필요할 수 있습니다.

응답 데이터가 수신되면 어떻게 됩니까?

부하 테스트 동안에는 객과 관련된 모든 응답 데이터는 CloudTest 서버에서 무시됩니다. 이 응답 데이터와 관련된 성능

데이터만 유지됩니다(응답 시간, 오류 등). 또한 앞서 설명한 것처럼 CloudTest 서버는 각 테스트 이후 삭제되는 임시

인스턴스로, 성능 지표만이 결과 데이터베이스에 기록됩니다. 그러나 스크립트 생성 및 디버깅이 이루어지는 동안에는

모든 고객과 외부 데이터가 CloudTest 서버에 저장됩니다. 스크립트 생성에 사용된 데이터는 스크립트 생성이 완료되면

삭제하여 Akamai 서버에 남아 있는 고객 데이터가 없도록 할 수 있습니다.

데이터에 관한 정보를 캡처하는 로그 파일 또는 기타 지표는 어떻게 처리됩니까?

Akamai는 부하 테스트를 수행하는 동안 고객 데이터에 관한 정보를 캡처하는 로그 파일이나 기타 지표를 저장하지

않습니다. 그러나 방금 설명한 것처럼 스크립트를 생성할 때에는 이 유형의 데이터를 저장합니다.

어떤 데이터가 CloudTest 서버로 반환됩니까?

부하 테스트 동안에는 HTTP 응답 코드, 쿠키, 세션 ID 같은 주요 외부 데이터만 저장됩니다. 모든 데이터는 CloudTest

서버로 파싱을 위해 반환되며, 모든 Akamai 서버에서 완전히 삭제됩니다.

스크러빙된 데이터와 가상 데이터의 차이점은 무엇입니까?

스크러빙된 데이터는 고객 데이터베이스에 위치하며 프로세스를 이미 거친 데이터이므로 실제 고객 데이터가 전혀

포함되지 않습니다. 실제 고객 데이터에서 생성 및 변환된 데이터라고 생각하시면 됩니다. 가상 데이터는 고객의 운영

데이터베이스를 정확하게 재현하기 위해 처음부터 새로 생성한 데이터입니다.

가상 데이터는 어떻게 생성합니까?

Akamai는 귀사의 애플리케이션 팀과 긴밀한 협력을 통해 널리 확산되는 재현 데이터를 생성합니다. 또한 데이터는

비즈니스 프로세스를 겨냥하기 위해 생성되기도 하며, 테스트 확장 시 함께 확장할 수도 있습니다.

테스트가 종료되면 데이터는 어떻게 됩니까?

테스트가 종료되면 CloudTest 서버에는 수행한 테스트와 관련된 성능 지표 데이터만 저장되며, 기업 데이터는 완전히

삭제됩니다.

테스트 데이터는 클라우드에 어떻게 저장됩니까?

Akamai가 실행한 테스트의 경우, 테스트 결과가 클라우드에 저장됩니다. 테스트 결과는 Linux 서버에 기록되나, 이

서버는 테스트 이벤트 종료 시 제거됩니다. 이러한 서버는 테스트 세션 또는 결과 분석이 이루어지는 동안에만 사용

가능합니다. 대부분의 경우, 결과 데이터는 EBS(Elastic Block Store)의 EC2 내 관계형 데이터베이스에 저장됩니다. 이

데이터는 Akamai 직원에게만 공개됩니다.

커머스 웹사이트 및 앱 성능 테스트에 대한 가이드 13

Akamai는 Apple, Target, Etsy, Microsoft를 비롯한 많은 기업의 웹 및 모바일 애플리케이션에 대한

무중단 테스트, 모니터링, 최적화 작업을 지원하고 있습니다.

귀사도 도와드리겠습니다.

지금 CloudTest를 사용해 보세요!

Akamai는 신뢰도가 높은 세계 최대 규모의 클라우드 전송 플랫폼을 기반으로 고객이 사용하는 장소와 디바이스에 상관없이 안전하고 쾌적한 디지털 경험을 손쉽게 제공할 수

있도록 지원합니다. 전세계적으로 촘촘하게 분산 배치된 Akamai의 플랫폼은 130개 국가의 20만 대의 서버로 구성되어 있으며 고객에게 우수한 성능을 제공하고 보안 위협을

방어합니다. 웹·모바일 성능 향상, 클라우드 보안, 기업 접속, 비디오 전송 솔루션으로 구성된 Akamai의 솔루션은 우수한 고객 서비스와 24시간 연중무휴 모니터링 서비스를

제공합니다. 대표적인 금융 기관, 이커머스 기업, 미디어·엔터테인먼트 사업자, 정부 기관이 Akamai를 신뢰하는 이유를 알아보려면 Akamai 홈페이지(www.akamai.com) 또는

블로그(blogs.akamai.com)를 방문하거나 Twitter에서 @Akamai를 팔로우하십시오. 전 세계 Akamai 연락처 정보는 www.akamai.com/locations에서 확인할 수 있습니다. Akamai

코리아는 서울시 강남구 강남대로 382 메리츠타워 21층에 위치해 있으며 대표전화는 02-2193-7200입니다. 2017년 7월 발행

클라우드에서 테스트 결과 데이터를 삭제할 수 있습니까?

예. 고객이 요청할 경우 결과 데이터는 클라우드에서 삭제될 수 있습니다. 요청이 발생하면 결과 보고서가 완료된 후에

결과 데이터가 삭제됩니다. 이때 삭제되는 결과 데이터는 영구적으로 삭제됩니다. 즉, 삭제된 결과의 백업이 없습니다.

결과 데이터를 삭제하면 이전 또는 향후 테스트와의 결과 비교가 불가능하다는 점에 유의하십시오. 결과가 삭제된

이후에 결과를 비교하려면 결과 보고서를 참조하는 방법밖에 없습니다.

클라우드에서 테스트 결과를 오프사이트 스토리지로 내보낼 수 있습니까?

예. 모든 결과는 XML 형식으로 내보낼 수 있습니다. 결과는 클라우드에서 내보내 고객이 정의한 위치로 저장할 수

있습니다. 테스트 기간과 테스트 관련 성능 데이터의 분량에 따라 클라우드에서 데이터를 내보내 안전한 위치로

이전하는 데 24-48시간이 걸릴 수 있습니다. 이전이 완료된 이후에는 원할 경우 클라우드에서 해당 데이터를 삭제할 수

있습니다.