아키텍트2009. 12. 8. 10:48

Velocity 시나리오 (2)

두번째 시나리오: Velocity Session State Provider (세션 상태 제공자)
지마켓이나 옥션에서 구매할 물건을 선택한 후 장바구니에 담기 해보신 적 있으시죠? 클라이언트와 서버 사이에 세션이라는 것이 맺어져서 서로 통신을 하게 되는데, 여러대의 서버를 사용하고 있다면 어떤 물건을 선택했는지에 대한 정보가 저장되어 있어야 장바구니에서 사라지지 않게 되겠죠. 실제 상품이 결제까지 끝난 후 세션 상태를 지워주는 역할을 하게 됩니다.

세션의 상태 정보를 저장하는데 데이터베이스에서 제공하는 SQL Server Session Provider를 사용하곤 했을 겁니다. 
오늘 글에서는 Velocity Session State Provider와 SQL Server Session Provider를 사용하는 방식에 대해 비교 분석을 해보겠습니다.

그림1. 전자 상거래 애플리케이션 아키텍처


성능 테스트를 하기 위해 6대의 웹서버를 사용했습니다.

성능 테스트
. Database와 Velocity 버전의 Throughput 테스트
. Database와 Velocity 버전의 Scalability (확장성) 테스트
. Velocity 버전에는 고가용성 오버헤드, Failover에 대한 테스트를 병행했음

1) 확장성

그림2. 300KB 오브젝트로 측정한 Throughput

확장성을 측정하기 위해 6대의 서버가 사용되었는데, Latency는 0에서 조금씩 증가하는 형태로 진행됐음.

그림3. 확장성 그래프

재미있는 결과 값을 확인할 수 있습니다. 3개의 노드까지는 데이터베이스와 유사한 결과값을 보이다가 노드수가 증가하면 데이터베이스의 경우 throughput이 줄어드는 현상이 나타납니다. 왜 이럴까요? 웹서버가 수가 늘어나면 데이터베이스에 과부하가 발생할 수 있습니다. 웹서버에서의 요청이 처리되기 전에 또 다른 요청이 데이터베이스로 유입되면서 전체적인 성능이 저하되는 현상이라고 할 수 있습니다. 즉, 병목현상이 벌어지는 거죠. 다시 말하면 웹서버의 수가 많더라도 충분히 활용되지 못하는 것입니다.

2) 고가용성

고가용성을 on, off하는 것은 큰 차이가 나타나지 않는 것으로 나타났습니다.

그림4. HA(고가용성) on, off에 따른 Throughput과 Latency

3) Failover

. 6대의 웹서버 운영
. 한대의 Velocity 호스트 turn-off
. 애플리케이션이 정상 상태로 돌아올 때까지 대기
. 두번째 Velocity 호스트 turn-off
. 애플리케이션이 정상 상태로 돌아올 때까지 대기

캐시의 장애는 3가지로 구분됨: 프로세스 kill, 서비스 stop, Velocity 관리도구를 이용하여 캐시 호스트 stop
1. At ~4:30 첫번째 호스트 turn off
2. At ~9:30 두번째 호스트 turn off

그림5. 프로세스를 kill 했을 때의 Throughput, Latency

오늘의 테스트를 통해 다음과 같은 결론에 도달할 수 있습니다.

. Velocity는 순차적인 확장성을 제공합니다.
. Velocity는 저렴한 서버에서도 잘 구동되고, 세션 상태에 대해 확장성과 고가용성을 제공합니다.
. 데이터베이스는 웹서버의 수가 증가하면, 병목현상으로 인해 성능이 저하되는 현상이 발생할 수 있습니다.
   - Velocity를 통해 CPU, 디스크, 네트웍 관련 병목 현상을 제거할 수 있습니다.
   - 다시 말하면, Velocity는 데이터베이스의 부하를 두드러지게 줄여줍니다.

이 글은 Grid Network의 Velocity Benchmark White Paper를 기준으로 작성했습니다.

Posted by 조이트리
아키텍트2009. 12. 7. 18:48

Windows Server AppFabric은 확장성, 가용성 및 고성능 애플리케이션을 개발하는데 필요한 분산 메모리 캐싱 플랫폼을 제공합니다. 오늘은 Velocity에 대해서 정리해보려고 합니다.

캐시를 통하면 애플리케이션이 불필요하게 데이터 소스 (Database 등)에 연결하여 데이터를 가져올 필요가 없기 때문에 급격하게 성능이 향상 됩니다. 분산 캐싱은 캐시 클러스터를 통해 수요가 증가하더라도 복잡한 로브밸런싱을 구성하지 않고도 안정적인 성능을 제공 받게 됩니다. 확장성은 서버를 추가하기만 하면 얻을 수 있게 되는 간단한 개념으로 바뀝니다. 고가용성은 해당 데이터를 Velocity가 복사할 수 있도록 설정하면, 해당 클러스터로 연결된 모든 서버간에 고가용성을 얻게 되는 거죠. Velocity는 원격 네트웍에 있는 서버 간에도 설정될 수 있습니다.

이전 글에서, 현재까지 구성되는 클라우드 컴퓨팅은 인프라 클라우드, 즉 서버 운영에 대한 부분에 집중되어 있다고 말씀 드렸습니다. 하지만, 애플리케이션에 대한 확장성, 분산 캐싱, Fail-over 등이 이루어져야 진정한 의미의 클라우드 컴퓨팅 플랫폼이라고 할 수 있습니다. 인프라 Fabric, 즉 인프라 클라우드는 마이크로소프트의 Dynamic Data Center toolkit으로 구성하고, 애플리케이션 Fabric은 Windows Server AppFabric으로 구성하면 진정한 의미의 분산 클라우드 운영체제를 구성할 수 있게 될 것 같습니다. 자, 그럼 AppFabric의 Velocity에 대해 좀 더 자세히 알아보도록 하겠습니다. Velocity는 현재는 CTP(Community Technology Preview) 버전이고, CTP4가 최신 입니다.

Velocity를 어떻게 활용할 것인지에 대한 일반적인 시나리오를 몇 개 설정해봤습니다.
(Grid Dynamics가 벤치마크를 실시했습니다.)

1. 블로그 엔진 애플리케이션, 분산 캐싱
2. 전자상거래 웹사이트, 세션 상태 제공자 (Session State Provider)

Velocity 시나리오 (1)

블로그 엔진은 데이터를 많이 사용하는 웹 애플리케이션의 좋은 예제라고 할 수 있습니다. 친구 리스트 및 feeds, 게시글에 대한 아이템을 가져오기 위해 복잡한 데이터베이스 쿼리를 사용하게 됩니다. 또한, 같은 정보가 사이트 내의 여러 페이지에 보여지는 경우가 많죠. 결국 같은 정보를 여러 번 반복해서 가져오게 되는 거죠. 분산 캐싱을 이용하면 성능 향상을 볼 수 있는 이유 입니다.

 
그림1. 블로그 엔진 애플리케이션 아키텍처

두 개의 버전으로 테스트가 이루어졌습니다. 첫 번째, 데이터베이스만 사용. 두 번째, 데이터베이스에서 조회된 내용을 캐시에 저장함.

1) Throughput


그림2. Throughtput (Without Velocity, With Velocity)

그림3. Latency (Without Velocity, With Velocity)

2) 확장성

그림4. Scalability (Without Velocity, With Velocity)

작은 데이터 셋 때 이 정도의 결과값이었고, 큰 데이터 셋을 대상으로 했을 때 더 좋은 결과가 나왔습니다.

3. 고가용성

그림5. HA(High Availability)를 켰을 때와 껐을 때의 결과 값

큰 차이가 나지 않는다. 다만, HA를 켜지 않은 상황에서 2배 정도의 메모리를 더 사용하는 것으로 나타남

4) Failover


 
 그림6. 애플리케이션의 throughput - Failover 테스트                   

At 05:00에 Node1 제거
At 10:00에 Node2 제거
At 20:00에 Node1 삽입
At 30:00에 Node2 삽입

오늘은 여기까지 정리하겠습니다. 내일은 2번째, Session State Provider에 대해 적어보겠습니다.

이 글은 Grid Network의 Velocity Benchmark White Paper를 기준으로 작성했습니다.

Posted by 조이트리