Cloud 기반 대용량 부하분산 모델.html

Cloud 기반 대용량 부하분산 모델

Cloud 기반 대용량 부하분산 모델

Summary

최근 기업 IT환경의 Cloud로 전환이 활발히 진행되고 있고, 특히 e-Commerce시스템의 Cloud 환경으로 전환은 더욱 빠르게 진행되고 있다. 이와 같은 대용량 시스템의 전환에 따라 Cloud 기반의 대용량 데이터를 효과적으로 처리하기 위한 요구도 증가하고 있다. Cloud환경에서 대용량 데이터 처리를 위한 접근방법은 기존의 정적 인프라 중심과 차이가 있다. 이미 알고 있듯이 Cloud는 ‘고객-사용자 또는 개발자-이 어플리케이션 시스템을 개발하고자 할때, 손쉽게 사용할 수 있는 인프라’ 라는 특성으로 인해, 별도른 인프라의 지식이 없는 개발자가 쉽게 접게 어플리케이션을 개발할 수 있는 환경을 제공한다. 그러나 소규모의 어플리케이션 단위가 아니라 기업의 대규모 IT 시스템을 Cloud로 전환할 경우, 트랜잭션이 유입되는 웹부터 데이터를 처리하기 위한 데이터베이스에 이르기까지 여러가지 기술을 동반한 복잡한 아키텍처가 필요하기 때문에 전통적인 기술과 차별화된 Cloud 기반의 부하처리 아키텍처 설계 접근방법을 설명하고자 한다.

1. The Challenge

Cloud 기반의 인프라 설계는 정적인 리소스를 예측하는 전통적인 방식과 다른 접근이 필요하다. 예를 들어 전통적인 대용량 데이터베이스를 설계할 경우, 데이터베이스는 사용자의 부하가 집중되는 영역이며 집중된 부하에 대응하는 안정적인 서비스를 위해 자원을 집중하고 집중된 자원의 가용성을 확보하기 위한 방식으로 접근했다. 그러나, Cloud환경에서는 대량 부하를 특정자원에 집중되지 않토록 다양한 장치를 마련하여 부하를 분산하는 방향으로 설계하는 것이 전통적인 방식과의 큰 차이점이라 할수있다. 즉, Cloud 데이터베이스에 부하가 집중되지 않고 부하를 최소화하기위한 사용자의 부하를 분산하는 방식의 접근이 필요하다. 이는 Cloud 컴퓨팅의 ‘자원(데이터 센터, 물리적 서버 등)을 손쉽게 사용할 수 있고, 탄력적으로 구성하여 비용을 절감할 수 있다’는 특징으로 가능하다.
즉, 기존의 On-Premise기업 IT환경은 최대의 부하에 대비하여 자원을 집중하고 평소에 사용되는 자원사용량을 상회하는 Peak치의 자원을 확보하고 비즈니스 목표치에 적합한 IT 인프라 투자 효과를 산정하는 것이 중요했다. 부하를 분산하기 위해 데이터센터를 새로 구축할 수는 없고, 물리적 서버를 무한정(부하 최대치)로 산정하는 것 또한 효율적인 구성이 아니므로 선택하기 어려운 옵션이다. 반면에 Cloud 환경에서는 최소의 자원을 확보한 후, 비즈니스의 변화추이에 맞추어 IT인프라를 손쉽게 변경할 수 있고, 점진적으로 최적화할 수 있다. 이러한 연유로 개발자는 비즈니스 중심의 어플리케이션에 집중할 수 있고, IT 인프라 자원에 관심을 분산할 필요가 없어졌다.

그러나, 기업의 대규모 IT 시스템을 새롭게 구축하는 경우 또는, 기업에 기존에 사용하고 있는 수백대의 IT 시스템을 Cloud 환경으로 전환하는 경우는 소규모의 시스템처럼 비즈니스에만 집중하기 힘들수 있다. 대규모의 시스템일수록 IT 투자효과에 민감하고, 여전히 미래에 사용할 IT 자원 예측은 필요하다. 기존에 사용하고 있는 인프라, 미들웨어, 솔루션 등 Cloud Service로 전환하기 힘든 자원이 존재할수 있고, 미래의 Cloud 컴퓨팅 자원에서 사용될 라이선스의 규모 산정또한 필요하다. Cloud 환경임에도 불구하고, 복잡한 레이어 구성에 대한 예측과 도입해야할 인프라의 규모를 판단해야 할 경우가 많을 수 있다.물론 모든 자원을 IaaS, PaaS, SaaS 서비스로 전환하는 것처럼 모든 자원을 Cloud 서비스로 활용하는 이상적인 방식을 채택한다면 이런 어려움을 해결할 수 있을수도 있을 것이나, 기업내 어플리케이션 변경 영향도/개발자의 새로운 기술 습득/기업의 표준화 정책 등으로 일시에 대전환이 발생하기 어려운 것이 현실일 것이다.

이에 본 문서에서는 대규모 IT 시스템을 Cloud환경에 적용시 부하분산 모델을 정의하는 방법과 이에 따른 Cloud 컴퓨팅의 자원 사용량을 예측하는 방법을 제시하고자 한다. 본 문서에서 제시하는 방식은 인프라 관점에서 각 레이어 별로 부하를 분산하는 방법을 개념적인 모델을 설명하고, 이해를 돕기위해 예시적인 솔루션과 인프라 사이징 방법을 제시하고자 한다.

2. Cloud기반 대용량 부하분산 개요

Cloud 기반의 대용량 부하분산을 위해서는 워크로드의 분석에 따라 워크로드 특성 별로 경유하는 레이어, 인프라를 분산하여 부하가 한곳에 집중되지 않도록 하는 것이다.

일반적으로 대규모의 웹 어플리케이션에서 발생되는 워크로드와 트랜잭션 유형을 간단히 분류하면 사용자의 정보나 상품정보를 조회하기위한 읽기(Read, 조회용) 트랜잭션과 사용자의 정보를 변경하거나 구매쓰기(CUD, 생성/변경/삭제)로 나누어 볼수 있다. 프로젝트 경험을 통한 일반적인 트랜잭션 유형을 보면 80%가 조회용이고, 나머지가 생성/변경/삭제로 분석될 수 있다.

대량으로 발생하는 트랜잭션은 그림과 같이 Back-end서버, 특히 데이터베이스와 통신을 함으로써 모든 레이어를 경유하게 되어 부하를 증가시키므로, 이런 트랜잭션을 최대한 줄임으로써 서버의 부하를 경감할 필요가 있다. 데이터를 생성/변경/삭제하는 트랜잭션은 원천 데이터베이스 단일접점에서 발생하여야 데이터 일관성이 유지되므로, 발생되는 트랜잭션의 대다수를 차지하는 조회 트랜잭션을 데이터베이스를 통하지 않고 데이터베이스 앞단에서 처리하도록 하는 것이 부하경감에 유리하다. Cloud 시스템에서는 이러한 조회 트랜잭션을 데이터베이스가 아닌 다른 레이어로 분산시키키도록 부하분산 모델을 정의하는 것이 핵심이다.

Cloud 기반 부하분산 모델
enter image description here

그림은 각 레이어를 통해 사용자의 부하를 분산하는것에 대해 설명하고 있다. 가능한 다양한 레이어를 두어 사용자 채널로부터 유입되는 부하를 분산해야하며, 분산을 위해 동적확장(Scale-out)과 읽기 데이터와 쓰기 데이터를 분산하여 특정 한 곳에 데이터가 집중되지않도록 설계를 해야한다.

① Content Delivery Network: 사용자에게 가장 가까운 위치에서 정적 컨텐츠를 제공하여, 서버와 사용자 사이의 물리적 거리를 줄여 웹 페이지 콘텐츠 로드 속도를 향상할 술 있다. 정적컨텐트(CSS/JS파일 및 사용자 업로드 이미지, 동영상)을 최전방에 배치하여 서버와의 통신 부하를 분산할 수 있다.

② Dual Zone: 가용존(Available zone)으로 Cloud Service Provider에 따라 용어가 조금씩 다르지만 데이터센터와 동일하다. 다중(Multi) 데이터센터를 통해 상시 서비스함으로써 사용자 부하가 센터의 개수만큼 분산된다. 또한 이를 통해 서비스의 가용성을 향상시킬 수 있다. 서비스의 일관성, 단일 데이터를 일관성있게 제공하기 위해 데이터베이스 아키텍처의 고려사항을 유발한다.

③ Web/WAS 확장성: 단일 Zone으로 유입된 트랜잭션의 부하는 Cloud 센터내 계획된 자원을 통해 부하의 양에 따라 인스턴스를 확장하여 부하에 대응한다.

④ Cache: 사용자의 조회가 많은 읽기(조회) 데이터를 저장하여, 데이터베이스로의 읽기 트랜잭션 부하를 분산한다. 사용자가 많이 읽는 데이터(Hit ratio이 높은)를 준비하는 것이 중요하다.

⑤ 데이터베이스: 데이터베이스는 읽기와 쓰기 전용 데이터베이스를 분리하여 부하를 분산하고, 다중(Dual) 센터 간 동일한 데이터를 제공하는 아키텍처를 통해 가용성을 확보해야한다.

(1) CDN

CDN (Contents Delivery Network)은 이미지나 동영상 같은 정적인 컨텐츠(javascript, css)들을 서비스 할경우, 서비스를 제공하는 서버가 존재하는 데이타 센터에서 서비스를 할때, 네트워크 latency와 다수의 홉(Hop)을 경유하여 성능이 저하될 수 있다. 이러한 오리진(서비스를 제공하는 실제 데이터) 정적 컨텐츠를 클라이언트와 가까운 데이터 센터(Edge server)에 동기화하여 사용자에게 바르게 컨텐츠를 제공하는 서비스이다.

CSS와 JavaScript, 이미지와 같이 공통으로 호출되는 리소스는 한 번 업로드되면 잘 변하지 않는다. 대용량 Enterprise의 경우, 이런 정적인 컨텐츠는 실제 크기에 비해 사용자의 수만큼의 네트워크 트래픽과 서버의 부하를 발생시킨다. 단 만명 사용자를 가정하여도, 1M의 이미지는 10G의 트래픽을 유발할 수 있다. 이러한 컨텐트를 CDN에 배치하면 네트워크와 서버의 부하를 절감할수 있다.

일반적으로 CMS(Conetents Management System)를 통해 생성된 이미지와 동영상 Origin 데이터와 데이터 동기화와 컨텐츠의 라이프사이클 관리가 중요하다. 대표적인 서비스 제공벤더는 Akamai가 있으며(IBM Cloud를 통해서 사용 가능함), 국내는 NBP 등의 벤더가 서비스를 제공한다. 서비스의 범위(글로벌 서비스를 준비해야한다면 글로벌 벤더를 선택) 와 벤더에 따라 데이터의 동기화 방식과 주기를 고려하여 라이프사이클 관리 배치할 컨텐츠 선정이 필요하다.

(2) Web/WAS

Web/WAS 레이어는 사용자의 트래픽증가에 Scale Out으로 대응한다. 인스턴스 별로 가용성을 위해 이중화로 두대씩 구성하고, Scale Out을 위해 업무 별 기본 인스턴스를 최소로 구성하는 것이 자원의 효율적인 관리에 유리하다. Web 서버는 2Core, WAS는 4Core 정도로 구성하여 Scale Out에 따른 자원을 점진적으로 증가하여 자원 사용을 최적화 해야한다. 일반적으로 인스턴스를 확장하는 방식은 인스턴스의 CPU 사용률 기준, 네트워크의 부하 기준으로 Auto-Scale 정책을 제공하하므로 사전 테스트를 통해 정책을 수립할 수 있다.

(3) 캐시(Cache)

캐시는 데이터나 값을 특정 저장공간에 미리 복사해 놓고 오리진 데이터베이스 (DB)에서 데이터를 복제하는 임시 저장소를 의미한다. 사용자의 요청이 데이터에 접근할 때의 시간을 절약하거나 데이터의 연산에 따른 성능저하의 경우 그리고 많은 사용자가 빈번하게 조회하는 데이터를 저장하는데 사용한다. 사용자의 문의가 빈번한 데이터를 캐시에 저장해 놓으면 데이터베이스의 부하를 분산 할뿐 아니라 요청마다 연산을 할 필요없어 빠른 사용자 응답을 할 수 있다. 뿐만 아니라 본 시나리오의 경우처럼, 읽기(Read) 데이터를 분산하는 효과가 크다. 그러므로 캐시 데이터의 정확도(Hit ratio), 즉 사용자에 의해서 자주 요청되는 데이터를 선정하여 캐시에 저장하는 것이 부하를 분산하는 효과가 크다.

일반적으로 특정사이트에서 발생하는 Top 10 트랜잭션이 모든 회사내 트랜잭션의 80%를 차지한다. 이런 트랜잭션을 분석하여 트랜잭션 내 중복되어 요청되는 데이턴를 캐시 데이터로 활용하면 캐시의 용량은 최소화하면서 Hit ratio을 향상시킬 수 있다. 일반화할수 없지만 보통 공통 코드성 데이터로 상품정보, 일내에 변하지 않는 고객 및조직정보등이 해당된다. 빈번히 데이터가 변경되는 데이터일 경우, 데이터의 선정에 더욱 많은 고려사항이 있어 주의할 필요가 있다. (데이터 선정 및 데이터의 변경주기에 따른 원데이터와 동기화 방법 등)상용 서비스를 하는 대형 e-Commerce의 경우 이런 Hit ratio이 80~85%를 기록하고 있다. 이 부분은 어플리케이션 및 데이터 영역에서의 고려이므로 데이터선정 및 관리 방식에대해서 본 문서에서는 논하지 않는다.

어플리케이션은 데이터베이스에서 데이터를 조회하기 전에 무조건 캐쉬에서 데이터를 읽고 없을 경우에만 데이테베이스에서 조회할때, Hit ratio 85%로 가정하고 Top 10 트랜잭션이 전체 Transaction의 80%로 Cover한다고 가정하면 10만건의 데이터 조회 트랜잭션 중, 68%인 6.8만건(10만 X0.85X0.8)을 캐시에서 커버하고, 32%만 데이터베이스에 도달하게 된다. 이같이 읽기(Read) 부하를 분산하여, 데이터베이스는 약간의 읽기와 쓰기(Create/update/delete)부하만 대응함으로 데이터베이스 부하를 크게 줄일수 있다.

이 같은 캐시는 Memcached, Redis 등 오픈소스 솔루션이 있으나, 다양한 데이터 구조과 분산 아키텍처아키텍처를 지원하는 장점이 있는 Redis를 기준으로 아키텍처 구성에 대해서 논한다.

센터내의 트랜잭션을 처리하고 가용성을 확보하기 위한 캐시 클러스터 구성은 가용성과 확장성을 고려하여 설계하여여 한다. Redis 클러스터는 단일 장애점(Single point of failure)이 없는 토폴로지구성한다. 클러스터 내 모든 노드가 클러스터 구성 정보(슬롯 할당 정보)를 가지고 있습니다. 클라이언트는 어느 노드든지 접속해서 클러스터 구성 정보를 가져올수 있고, 클러스터 정보에 따라 Master 노드의 리스트를 제공받아 Master 노드에 접속하여 데이터를 처리한다.

가용성을 위한 Redis 분산 아키텍처

enter image description here

  • Master 간 데이터 샤딩되고 샤드간 데이터 분산은 솔루션내에서 자동으로 처리되어 부하를 분산.
  • 각 Master는 Slave로 데이터 복제되며, MAster 장애 시 Slave가 자동으로 마스터로 승격
  • 과반수 이상의 노드가 다운되지 않는다면 일부 노드가 다운되어도 다른 노드에 영향을 주지 않으므로 가용성을 확보.
  • 최소 3개(권장 6개)의 Master로 구성이 필요하며, Master 당 Slave 구성하여(권장 Master 당 2 Slave) 가용성 확보.

Redis Cluster 초기 구성 및 확장방법

  • Redis 클러스터는 수평확장(Scale Out)에 의한 저장공간과 처리용량을 확장할 수 있으며, 3개이상의 마스터노드 구성을 통해 가용성을 확보할 수있다. 테스트를 통해 초기 구성 후, 메모리 임계와 CPU 임계에 의해 단계별로 확장한다
  • 기본구성은 노드별로 4 Core CPU, 대상데이터 측정에 따른 Memor로 구성하고, 클러스터 구성은 3개의 Master와 6개의 Slave로 초기 구성후, Memory와 CPU의 임계에 따라 3개 단위로 확장한다. (3개의 노드별로 증가해야 가용성과 장애대응에 유리함)
  • 프로세스 별 메모리 사용량 변화와 캐시의 응답속도 변화(CPU 임계 확인)에 따라 노드증가를 고려함. CPU의 경우, single 프로세스 처리이므로 Core수 증가보다 Scale Out 전략이 성능을 향상함에 유리.

(4) 데이터베이스

데이터베이스는 데이터의 저장공간으로 일반적으로 트랜잭션이 집중되는 영역인다. 앞서 언급했듯이 Scale up 전략의 일환으로 집중된 부하에 대해 안정적인 서비스를 위해 자원을 집중하고 집중된 자원의 가용성을 확보하기 위한 방식에서 Cloud 데이터베이스에 부하가 집중되지 않고 부하를 최소화하기위한 사용자의 부하를 분산하는 방식으로 설계해야 한다.

본 Cloud 모델에서는 캐시를 통해 읽기(Read) 트랜잭션 분산 대응하도록 설계하고 데이터베이스는 쓰기(CUD) 트랜잭션 처리와 캐시에서 처리하지 못한 읽기(Read) 트랜잭션을 대응해야 한다.

데이터베이스는 데이터무결성을 보장한 단일(Unique)한 데이터를 고객에게 제공해야하므로 분리된 데이터센터에 각 클러스트를 구성하지 않고, Dual 센터내의 데이터베이스 인스턴스를 포함하는 단일 클러스터(Global Cluster)를 구성해야한다. 뿐만 아니라, Cloud의 인스턴스는 성능과 용량은 무한정 크게 키울수 없고(트랜잭션의 최대치를 예상하여 인스턴스 용량을 최대로 산정하는 Scale uP 전략과 달리), 항상 Scale out 전략을 고려하여 최소의 리소스를 구성하고 인스턴스를 확장하는 전략을 취해야한다. 이를 위해, 센터간 데이터베이의 이중화를 통해 가용성을 향상하는 방법 및 읽기(Read)와 쓰기(CUD)트랜잭션을 분리대응하기위한 데이터베이스 단일 클러스터 구성을 설명한다.

오픈 RDBMS 솔루션 Maria와 PostgreSQL, MySQL 등이 시장에서 통용되고 있으나, 복제방식 또한 전통적인 HW중심의 Shared disk 방식과 Enterprise 사이드의 Shared noting 구조의 방식 중 MHA(Mysql High Availability)와 MMM(Multi Master replication Manager), Galera 방식이 있다. 본 문서는. 이중화와 복제방식의 컨셉위주로 설명을 하므로 국내 대표 e-Commerce에서 채택이 증가하는 MySQL기으로 컨셉을 이해를 돕기위해 MMM 클러스터 구성을 기반으로 설명하고, MMM 및 MHA와 Galera 등 솔루션 자체에 대한 동작방식을 별도로 언급하지 않는다.

MMM(Multi Master replication Manager) 사용방식은 데이터베이스를 Multi-Master의 구조로 구성하여 Master간 양방향 복제로 구성한다. 또한 데이터베이스를 read/write DB와 read DB로 운영을 분리하고, Read/write DB 장애 시 MMM 서버가 DB가 이를 감지하여 Failover하는 방식이다. 이 구성에 따라 Master를 Active, Standby로 Multi로 구성하여 가용성을 확보하고, Read와 Write 로 트랜잭션을 분산하는 구조를 기본으로 구성할 수 있다.

MySQL 클러스터 (MMM 방식)

enter image description here

  • Master는 Active와 Stand-by로 구성되고, 마스터간 실시간 복제
  • Stand-by Master는 평소에는 읽기용으로 사용되며 Active Master 장애 시 Active로 승격되어 읽기모드가 해제, vip 할당이 자동으로 진행.
  • Slave(Replica)는 Active Master로 부터 단방향으로 데이터를 복제하여 동기화 하고, 읽기용으로 사용.

Cloud 기반 부하분산 컨셉에 적용하여 캐시와 DB 클러스터 구성 및 데이터 흐름을 정의하면 다음 그림과 같다.

캐시 및 DB Cluster 구성과 데이터 흐름
enter image description here

  • 센터내 구성된 캐시 클러스터를 통해 읽기 트랜잭션의 분산
  • 업무구성에 따라 읽기 용도의 Slave 데이터베이스를 활용함. 업무의 부하에 따라 단독으로 읽기 전용 데이터베이스를 제공하여 영향도를 최소화 할 수 있음.
  • Stand-by 마스터 데이터베이스 역시 읽기 데이터베이스로 활용.
  • 양 센터의 쓰기 트랜잭션은 유일하게 존재하는 Active Master만 활용함.

3. To-Be 부하 시나리오와 용량산정 시뮬레이션

지금까지 Cloud 기반의 부하분산의 모델과 레이어별 아키텍처에 대해서 살펴보았다. 컨셉을 기반으로 실제 업무에서 적용하기위한 부하분산 모델 수립 절차와 모델을 수립하고 용량산정 시뮬레이션을 검토해 보자.

(1) 사용자 부하분산 모델 수립 절차

우선 고객의 현재 워크로드 현황과 비즈니스 요구사항을 수립해야한다. 이 단계의 접근 방법은 전통적인 절차와 동일하며, 주요 비기능에 관련된 현황과 비즈니스의 요구사항 및 목표치를 수집하고 분석한다. 특히 용량에 필요한 데이터인 Application Type, User 수, 초당 처리건수, 어플리케이션 복잡성, Peak time의 PV, UV, TPS 등을 수립하고 활용해야 한다.
대부분의 Cloud 서비스 프로바이드(CSP)들이 제공하는 컴퓨팅 자원은 단위 자원의 정확한 스펙을 제공하지 않는다. 이는 자원 가상화기술로 인해 자원이 추상화 되어 표준화 되기 힘든 점과 Cloud의 사상(사용하고 필요한 만큼 확장하는 방식)에 기인한다. 다만 우리의 목적인 Enterprise 환경의 용량산정과 부하모델을 검증을 위한 단위 컴퓨팅 자원 정보(Base Line, 예. vCPU 당 처리 tpmC)를 구하는 단위부하기준수립 Task가 부하모델 검증단계에 필요하다.

사용자 부하모델 수립 절차

enter image description here

1. 사용자 부하분석
수집된 현황 및 비즈니스 요구사 인터뷰를 통해 To-Be의 예상 TPS와 동시 접속자를 정의한다. 주요 수집항목은 앞서 언급한 각 레이어 별로 정의해야될 항목을 고려하여 정의한다. 주요 수집 항목으로

  • As-Is 부하 및 구성현황: As-Is TPS, 동접자, 장애현황, 가용성 구성현황 및 시스템 사용현황 등 To-Be의 부하를 구하기 위한 기본자료와 HW수준의 기술정보를 수집.
  • As-Is 워크로드 분석결과: 시/일/월/년 간 워크로드 변화, 어플리케이션 복잡도, 데이터베이스의 크기, 시스템 사용 현황 등 워크로드의 최대치와 최소치의 편차를 구할 수 있는 정보를 수집. 워크로드 복잡도와 데이터베이스의 크기를 구하여 To-Be 부하량을 조정할 자료를 수집한다.
  • CDN과 캐시의 메모리 용량 측정을 위한 기본자료로 활용을 위한 정적 컨텐츠 및 동적 컨텐츠의 양과 트랜잭션 특성(조회/CUD) 데이터의 크기
  • 비즈니스 목표: 비즈니스 성장 목표와 향후 이벤트 계획으로 비즈니스 성장에 따른 가중치를 정의하여 To-Be 목표부하 보정시 활용함.

2. Cloud 기반 부하모델 설계
향후에 사용될 레이어를 포함하는 Cloud 기반 부하분산 모델을 정의하고 레이어 별 아키텍처와 레이어별 컴퓨팅 자원의 Sizing을 위한 To-Be 레이어 별 부하를 정의하여, To-Be에 사용할 Cloud 컴퓨팅 자원을 활용하여 컴퓨팅 단위 자원을 배치한다.

  • To-Be Cloud 컴퓨팅 자원의 vCPU당 처리성능을 정의한다. 이를 위한 기준 성능 정의를 위한 단위 컴퓨팅 자원의 워크로드 별 테스트를 통해 사이트 별 기준값을 정의한다.( 일반적으로 Public Cloud 제공자(IBM, Azure, AWS 등)은 공식적인 vCore를 제공하지 않으므로 사전에 워크로드의 이후 검증 작업이 필요할 수도 있다
  • To-Be 부하 목표치(TPS, 동접자, 사용자, 워크로드)를 기반으로 To-Be Web/WAS/DB 각 예상 WEB/WAS의 Ops와 tpmC 수준까지 산정한다.
  • As-Is의 On-Premise 시스템을 워크로드를 기준으로 Cloud 상의 부하를 변환하는 것을 전제로 정의한다.
  • 전통적인 방식의 정보통신 기술협회(TTA) “정보시스템 하드웨어 규모산정 지침”을 활용하여 As-Is TPS와 동접자를 기준으로 To-Be 워크로드에 대해서 변환정의하는 것이 유용하다.
  • 부하분산 모델에 따라 레이어 별 아키텍처를 정의하고 산정된 용량에 따라 컴퓨팅 자원을 배치한다.

3. 부하모델 검증

  • 모델의 정합성을 검증하기 위한 단위부하 테스트와 통합 부하테스트를 실행한다.

(2) Cloud 기반 부하분산 시나리오

사용자 부하분산 모델 수립 전에 전체적인 컨셉에 따라, 각 레이어 별로 데이터의 흐름을 설명하고, 유입되는 트랜잭션 량의 변화 시나리오를 정의한다.

enter image description here

① 전체 사용자 부하가 채널을 통해서 유입(초기 트랜잭션량은100%, CDN에서 분산된 이후의 데이터 기준)

② Dual Center를 통해 서비스를 제공하는 것으로 가정할 때, ZoneA와 Zone B로 트랜잭션이 분산 유입되므로, 하나의 Zone에 서 받는 트랜잭션은 50%로 분산처리된다. (Zone 별 50% 트랜잭션이 유입)

③ Scale-out/in 작업 구간으로 Web/WAS에서는 CSP에서 제공하는 자동 혹은 계획된 Scale작업을 통해 서버의 수평확장을 통해 트랜잭션을 유입되는 트랜잭션을 다수의 서버에서 분산처리한다.

④ 조회용 트랜잭션의 대부분을 캐시가 처리함. 캐시 데이터의 정확성(Hit ratio)을 85%, 전체 조회 트랜잭션의 80%을 캐시에서 대응한다고 할 때 각 센터로 유입된 전체 트랜잭션 중 27.2%(40%X85%X80%)의 읽기 데이터를 캐시에서 처리한다.(다수의 프로젝트에서 워크로드를 분석경험으로 보면, Hit ratio 85%를 목표하는것이 적절하다. Top 10 트랜잭션 분석을 통해 조회 트랜잭션의 80%를 캐시가 대응한다는 가정이다. 참고로, 캐시에 등록되는 데이터를 선정하는 것이 어플리케이션 및 데이터 아키텍처에서 중요한 작업이 된다. 이를 위해 기업내 발생하는 트랜잭션 분석 등을 통해 캐시테이터를 선정작업이 선행되어야 한다. 캐시데이터 선정은 어플리케이션과 데이터 분석을 통해서 선정해야하며 본 문서는 가정으로 기술한다.)

⑤ 캐시에서 처리된 읽기 트랜잭션외 12%의 읽기 트랜잭션과 쓰기 트랜잭션 10%만 데이터베이스를 통해서 처리하여 데이터베이스의 부하를 최소화할수 있다.

이와 같이, 초기에 100만건의 트랜잭션이 발생하더라도, 부하분산모델을 통해 최종으로 데이터베이스의 트랜잭션은 읽기 8만건, 쓰기 10만건으로 데이터베이스의 부하를 경감시킬수 있으며 대신 센터분리와 web/WAS의 스케일아웃, 그리고 캐시를 통한 부하를 분산하여 안정적이고 지속가능한 서비스를 구현할 수 있다. 결과적으로 레이어 별, 서버 별 부하를 감당하기 위한 컴퓨팅 자원을 배치하고, 검증단계를 통해 보완할 수 있다.

(3) 레이어별 용량산정 시뮬레이션

이 장에서는 이러한 부하분산 모델을 기반으로 실제 부하분산 모델을 수립하고 서버 용량산정을 시뮬레이션 방법을 기술한다.

As-Is 부하현황 정보
아래의 표와 같이 As-Is 분석과 요구사항을 수집한다.
enter image description here

레이어 별 부하 산정 시뮬레이션
부하분산 모델에 따라 레이어 별로 레이어 별로 부하를 tpmC 단위로 산정한다.
enter image description here

용량산정 결과
레이어 별 Replica 구성과 클러스터 구성 및 센터 구성을 고려하여 단위 컴퓨팅 자원의 용량을 산정하고 배치한다.
enter image description here