페이퍼요약 - 웹애플리케이션의 성능, 확장성, 신뢰성 이슈 by Iyer

제목: 웹애플리케이션의 성능, 확장성, 신뢰성 이슈(Performance, scalability and reliability issues in web applications)

저자: Lakshmi S. Iyer 외 2인, 미국

문서유형: 저널페이퍼(총 16페이지), 2005년

 

 

멀티티어 웹 기반 애플리케이션의 성능/확장성/신뢰성 테스팅 전략을 기술한 자료

 

---

 

웹 기반 시스템의 성능(performance), 확장성(scalability), 신뢰성(reliability)

• 인터넷의 성장으로 웹 기반 멀티티어 애플리케이션이 기하급수적으로 증가함
• 사용자 수가 증가함에 따라 통신/전산 서비스 수행을 위한 시스템의 부하(load)도 증가
• 증가하는 부하를 시스템이 감당할 수 있는지가 제대로 테스트 되지 않은 경우 사용자는 반응 시간의 현저한 저하를 경험하게 되고 이는 고객의 웹사이트 선택에 영향을 줌
• 아래 표는 Empirix(2004년)가 수집한 저조한 웹 성능에 대한 정보

웹 문제가 있는 위치	비중(%)
네트워크	20
웹 서버	10
데이터베이스 서버	30
애플리케이션 서버	40

[웹 성능 문제의 원천지]

• 멀티티어 웹 기반 시스템에서 성능 문제는 적절한 성능 테스팅의 결핍으로 인해 야기됨. 따라서 본 논문은 멀티티어 웹 기반 애플리케이션을 위한 아래 그림 같은 성능/확장성/신뢰성(PSR) 테스팅 전략을 제안함

[PSR 테스팅 전략]

 

PSR 테스팅 계획(Planning)

어떤 성능 테스팅 프로세스이든 목표는 생산 환경(production environment)을 시뮬레이션 하는데 있음. PSR 테스팅의 계획 단계 스텝은 아래와 같다.

 

1) 비즈니스 워크플로우 식별(Identifying business workflow)

• 제품의 사용을 대표하는 주요 워크플로우를 식별. 최종사용자 측면과 관리자 측면 양쪽 모두를 포함해야 함  
  예를 들어, 온라인장터의 최종사용자 워크플로우(end-user workflow)는 아래 같은 것들이 있음
     i) 로그인 – 제품 검색 – 카트(cart)에 추가 – 제품 주문 – 로그오프
     ii) 등록 – 로그인 – 제품 검색 – 로그오프
     iii) 로그인 – 지불 승인 – 로그오프
  관리자 워크플로우(administrative workflow)의 예로는 아래를 들 수 있음
     i) 로그인 – 카달로그에 신제품 추가 – 로그오프
     ii) 로그인 – 사용자 프로파일을 편집/유지보수 – 로그오프
     iii) 로그인 – 제품 가격 변경 – 로그오프
• 최종사용자 입력 정보는 효율적인 테스팅을 위한 시나리오 우선순위 부여에 도움이 됨
• 일단 코드 동결(변경 불가)이 되면 이 시나리오들이 자동화될 수 있고 그 정확성(correctness)도 확인될 수 있음
• 이 프로세스의 파생 작업은 선별된 시나리오를 시뮬레이션하는데 필수적인 데이터를 식별하는 것임. 자동화 노력이 적절한 데이터가 최종 결정되기 전에 시작될 수 있기는 하지만 차후 데이터 불일치로 인한 변경이나 재작성이 필요해 질 수도 있음

 

2) 필수 데이터 정의 및 생성(Defining and creating necessary data)

• 테스팅을 위해 선별된 비즈니스 시나리오의 관련 데이터를 생성하는 활동. 제품의 고객 베이스(customer base) 대부분을 커버하기 위해 데이터 크기를 소규모, 중간규모, 대규모로 분류하는 것이 도움이 됨
• 비즈니스 워크플로우를 커버하기 위한 기본 콘텐츠를 생성하고, 소규모/중간규모/대규모 데이터 셋에 필요한 볼륨을 구축해 나감. 대개 기본 데이터 콘텐츠는 기능 테스팅에 사용될 수 있고, 더 큰 것은 시스템/통합/PSR 테스팅에 사용될 수 있다.
• 위 온라인장터 예의 경우 샘플 데이터 크기가 아래와 같을 수 있다.
  - 소규모: 사용자 수(1,000), 데이터베이스 항목(100K), 각 제품의 가격 수(5), 제품 카테고리 수(100)
  - 중간규모: 사용자 수(10,000), 데이터베이스 항목(1M), 각 제품의 가격 수(5), 제품 카테고리 수(1,000)
  - 대규모: 사용자 수(50,000), 데이터베이스 항목(5M), 각 제품의 가격 수(5), 제품 카테고리 수(5,000)
• 자동화에는 워크플로우의 시뮬레이션을 허용하는 ‘Record and play 도구’의 사용이 권장됨(예, 머큐리의 로드러너). 자동 스크립트가 데이터에 독립적으로 구축되지 않는 한 적절한 데이터가 가용하지 않은 동안 테스트 할 비즈니스 워크플로우를 자동화하는 것은 별 가치가 없다. 따라서 자동 테스팅의 스크립트(또는 수작업 테스팅의 프로시져)를 시작하기 전에 관련 데이터 셋을 식별하고 생성하는 것이 바람직한 관행이다.
• 관심 워크플로우의 레코딩이 이루어진 후에는 스크립트가 동일 제품 버전이 돌아가는 어떤 시스템 셋업에서든 재생되도록 패러미터화(parameterized) 될 수도 있다. 

 

3) 시스템 구성 식별(Identifying system configurations)

• 제품을 구현하는데 적합한 하나 또는 여러 시스템 구성을 정의하는 일은 제품의 능력(capabilities)을 결정하는 첫 스텝이다.
• 제품 아키텍트와 제품 관리자의 협의를 통해 제품의 논리적 구성(logical configuration)이 도출되고, 이에 따른 여러 다른 물리적 구성이 다양한 조합을 통해 가능하다.

 

4) 머신 요구사항 식별(Identifying machine requirements)

• 아래 그림 같은 멀티티어 웹 기반 애플리케이션에서 각 티어가 각기 다른 용량을 가진 다른 타입의 머신을 필요로 할 수 있음. 예를 들어, 데이터베이스 머신은 더 많은 메모리, 프로세서 수, 하드 디스크 공간을 필요로 하고, 두 번째 티어는 메모리 집약적이고 데이터베이스로부터 많은 데이터를 캐시할 수 있어야 하며, 세 번째 티어는 프로세서 집약적이고 모든 클라이언트 리퀘스트를 처리한다. 따라서 머신 요구사항은 각 티어에 맞게 그리고 사전에 결정된 머신 용량(capacity)에 맞게 계획되어야 한다.
• 생산 시스템이 대개 고용량의 고성능 머신을 가진다는 점을 염두에 두면서 PSR 테스팅을 위한 머신 특징(machine characteristics)이 주의 깊게 계획되어야 한다. 예를 들어, 166MHz 프로세서와 128MB RAM의 데스크탑 컴퓨터는 웹 생산 시스템에 적합하지 않으며 따라서 성능 측정을 위한 후보가 되어서는 안 된다.
• 의존성 요인(dependency factors)을 파악하기 위해 성능 메트릭이 여러 다른 타입의 머신에서 수집되는 것이 이상적이다.
• 동시성 테스팅과 신뢰성 테스팅을 위해서는 머신이 고성능일 필요는 없지만 시스템 구성으로 인한 동시성 이슈가 드러날 수 있도록 적어도 듀얼 프로세서를 가져야 한다.
• 단일프로세서 머신을 택할지 멀티프로세서 머신을 택할지는 제품 설계(즉, 멀티쓰레딩을 지원하는지 여부)에 의존적이다.

[웹 기반 애플리케이션을 위한 멀티티어 구성]

 

 

PSR 테스팅 실행(execution)

1) 동시성 테스팅(Concurrency testing)

• 머신 CPU 파워의 최대 50%를 활용하는 낮은 최종사용자 부하 하에서 개별 워크플로우를 테스트 함. 제품의 출시 준비가 되었는지 분석하는 첫 단계임
• 복수 사용자(리퀘스트)가 하나 또는 여러 모듈을 통해 동시적인 호출을 하는 것을 테스팅
• 다양한 부하 조건 하에서 여러 다른 타입의 최종사용자 리퀘스트를 시스템이 감당하는 능력에 대한 정보를 생성한다.
• 이 테스팅 단계의 목표는 i) 단일 프로세서 머신 상의 멀티유저 시뮬레이션, ii) 멀티프로세스 머신 상의 멀티유저 시뮬레이션, iii) 멀티서버 구성 상의 멀티유저 시뮬레이션을 커버해야 한다.
• 이 단계 동안 ‘동시성(concurrency)’은 프로세서 수나 서버/사용자 수에 제한되지 않고 제품의 여러 다른 모듈의 동시적인 사용/실행도 포함한다. 후자는 전자와는 다른 이유로(예, 설계의 차이, 최종사용자 기능의 차이) 시스템에 다른 부하를 부과한다.
• 이 단계에서 드러날 수 있는 잠재적인 문제로
  i) 코드의 데드락,
  ii) 프로세스 집약적인 코드 섹션,
  iii) 동시성 하의 메모리 사용,
  iv) 데이터 소스(주로 데이터베이스)와의 데이터 I/O 동기화 문제,
  v) 멀티서버 셋업에서 제품 구성 관련 이슈,
  vi) 시스템/서브시스템을 위해 문서화될 필요가 있는 필수 세팅 등이 있다.

 

2) 신뢰성 테스팅(Reliability testing)

• 실제 생산 환경과 유사한 조건에서 최종사용자 액션(end-user actions)을 통해 적용되는 지속적인 스트레스와 부하를 제품이 감당 할 수 있는지를 확인
• 이 분석 단계를 통해 모니터되어야 하는 잠재적인 문제 영역으로 메모리 소비, CPU 활용, 성능(응답시간, 처리량, 각 워크플로우의 사이클 타임 등에 의해 측정됨)이 있다.
• 이 분석은 ‘각 워크플로우의 신뢰성(실 사용의 부분 집합)’과 ‘집단적인 워크플로우 집합의 신뢰성(제품의 실 사용을 시뮬레이션)’의 2단계로 구분하여 구현될 수 있다.
• 이 테스팅 단계는 아래 기준을 충족해야 성공으로 간주된다.
  - 로그 파일에 예외사항(exceptions) 없음
  - 애플리케이션 및 서브렛 엔진 로그 파일에 에러 메시지 없음
  - 데드락이나 메모리 누출이 없음
  - 데이터 크기로 인한 성능 병목(performance bottlenecks)이 없음
  - 주어진 부하 조건 하에서 시작(startup) 이후 2시간 이상 동안 안정적으로 시스템이 운행됨. 또한 초당 서비스되는 리퀘스트 총 수에 의해 측정된 시스템 처리량, 워크플로우의 사이클 타임, 프로세스의 쓰레드 수, 프로세스의 가상 메모리 활용 등이 10% 이상 변하지 않음

 

3) 성능/확장성/능력 분석(Performance, scalability and capacity analysis)

• 여러 다른 부하 조건 하에서 제품 성능을 측정하고; 머신 리소스(머신 상의 프로세서 수, 머신 수)를 조절하면서 시스템 상의 제품 성능을 측정하고; 성능 및 확장성 테스팅에 더하여 볼륨 및 스트레스 테스팅도 커버한다.
• 성능은 다양한 부하 조건 하에서 시스템의 최종사용자 반응성(end-user responsiveness)으로 정의될 수 있다. 생산 시스템 단위의 능력(capacity)은 초당 리퀘스트 수(requests per second: RPS), 페이지당 리퀘스트 수(requests per page), 액티브 사용자 수(number of active users)를 모니터링 함으로써 결정될 수 있다.
• 이런 시스템 특징들을 측정하는 일은 통제된 환경에서 수행되어야 하며 아래 패러미터는 수락가능한 시스템 성능의 한계(threshold)를 식별하는데 도움을 준다.
  - 대기/지연 시간(Latency): 하나의 리퀘스트를 클라이언트에 서비스하기까지 왕복 시간(round trip time). 대개 B-B 시나리오의 10MB LAN 커넥션 상에서 측정됨
  - 생산 시스템 단위당 RPS: 리퀘스트는 서비스되는 단일 HTTP 리퀘스트임(웹 서버의 경우). 1초에 처리되는 총 리퀘스트 수를 의미하는 이 패러미터는 머신당 처리량(throughput)을 가장 잘 나타낸다.
• RPS와 Latency는 특정 시점에 시스템을 액티브하게 사용하는 사용자 수에 의존한다. 수락가능한 성능 한계는 종종 특정 배경의 비즈니스 시나리오에서 허용된 대기 시간(latency)을 통해 정의된다(위 예의 온라인장터의 경우 산업 표준으로 여겨지는 통상적인 대기 시간은 2초). 하지만 이것은 시스템에 따라 크게 달라질 수 있으므로 수락가능한 한계(acceptable limits)가 성능/능력 테스트 수행 사전에 설정되어야 한다.

 

아래 절차는 여러 다른 타입의 부하 하에서 시스템의 동작을 이해하는데 도움이 되는 방법이다.

①     5명의 사용자로 시작하여 주어진 비즈니스 워크플로우 조합에 대한 최종사용자 대기 시간(end-user latency)을 측정한다.

②     사용자 수를 2배로 하며 4회 내지 5회 테스트를 반복하거나(즉, 5명, 10명, 20명, 40명, 80명 등) 또는 수락가능한 대기 시간 한계를 넘어설 때까지 테스트를 반복한다(둘 중 더 늦게 일어나는 쪽으로 진행)

③     생산 시스템의 또 다른 단위를 추가하고 시뮬레이션된 사용자 수를 두 배로 한다(10명, 20명, 40명, 80명, 160명 등). 마찬가지로 대기 시간 한계에 도달했을 때 멈추거나 또는 최대 능력(max capacity)을 결정하기 위해 대기 시간의 두 배가 될 때까지 계속한다.

④     생산 시스템 단위를 4개로 확장하면서 위 프로세스를 계속하고 그 결과를 표로 작성한다.

⑤     멀티티어 셋업에서는 중간 티어의 능력(capacity)이 해당 티어에 위치한 머신의 프로세서에 부과된 부하에 의해 추정될 수 있다. 대개 중간 티어의 능력은 최고 부하(peak loading) 조건을 감안하여 머신의 프로세서의 평균 80% 활용으로 제한된다.

⑥     이 프로세스 동안 성능 병목은 비즈니스 워크플로우의 트랜잭션 목록과 테스트 사이클(즉, 3시간 동안 실행되는 10명의 사용자 테스트)의 평균 대기 시간을 평가함으로써 모니터 될 수 있다.

⑦     시나리오의 평균 대기 시간이 한계치 이하이더라도 조건에 대한 예외(exceptions)를 보이는 트랜잭션은 잠재적인 설계 이슈를 식별하기 위해 분석되어야 한다.

⑧     일단 테스트 결과가 표로 작성되면 조사 대상 구성의 확장성(scalability)을 판단하는데 아래 분석이 도움이 된다.
- 단위당 반응시간 확장성(response time scalability per unit)
- 대기 시간(latency) vs. 단위당 사용자 수(number of users per unit)
- 단위당 처리량 확장성(throughput scalability per unit)
- RPS vs. 단위당 사용자 수(number of users per unit)
- 능력 확장성(capacity scalability) – 처리량(throughput)
- RPS vs. 단위당 부하(단위 수를 다르게 하면서 – 1, 2, 3, 4, 5)
- 능력 확장성(capacity scalability) – 대기 시간(latency)
-능력 한계치의 사용자 수(그리고 2ⅹ) vs. 단위 수(number of units)