[SA강좌] Part 3-7 소프트웨어 아키텍처 평가

소프트웨어 아키텍처 평가

시나리오 기반의 평가 방법

• 아키텍처 평가에 대한 참여자
  • 평가 팀
  • 프로젝트 의사결정자
  • 아키텍처 관련 당사자
• 아키텍처 평가의 결과물
• 아키텍처 평가 절차
  • 아키텍처 평가 절차를 소개한다.
  • 기능적, 비기능적 요구사항을 소개한다.
  • 아키텍처를 소개한다.
  • 브레인스토밍과 시나리오 선택
  • 아키텍처 분석
  • 결과 프레젠테이션

Prototype을 통한 평가 방법

Prototype을 구현하면서 원하는 기능을 구현할 수 있는지, 개발하는데 애로 사항은 없는지 판단한

성능 테스트 및 평가 방법

많은 프로젝트에서 성능을 프로젝트 마지막 단계에서만 고려한다. 결과적으로 프로젝트 마지막 단계에서 성능을 높이는데 실패하여 프로젝트가 지연되거나 위약금을 내게 된다. 따라서 프로젝트의 매 단계마다 기대되는 성능을 분석할 수 있는 방법이 필요하다. 이 절의 목적은 시스템의 성능을 예측할 수 있는 실용적인 전략을 제시하고 최적의 성능을 실현하기 위한 방안을 제시하는 것이다. 이 두 가지를 수행하기 위해서는 다음과 같은 활동들이 요구된다.

• 시스템의 성능에 영향을 미치는 핵임 요인을 찾는다.
• 시스템을 측정하고 workload를 이해한다.
• 실제 workload의 기본적인 특성을 반영한 workload 모델을 개발한다.
• 시스템의 성능을 정확하게 예측할 수 있는 모델을 개발한다.
• 이 모델을 사용하여 시스템의 성능을 예측하고 최적화한다.

성능 테스트 및 평가를 위해서 workload 모델, 성능 모델, 가용성 모델, 신뢰성 모델, 비용 모델을 사용한다. 프로젝트 초기에는 모델을 만들기 위해서 필요한 정보와 데이터들은 대략 추측하여 만들어질 뿐이다. 예를 들어 요구사항 분석단계에서는 상세한 workload 모델을 만들고 트랜잭션 처리를 위해 리소스를 어느 정도 사용해야 하는지 결정하기 어렵다. 그러나 프로젝트가 진행됨에 따라 더 많은 시스템 정보들을 모을 수 있고 모델에 대한 잘못된 가정을 수정할 수 있고 미래의 시스템 성능에 대해 신뢰할만한 예측을 내놓을 수 있다. 그러나 프로젝트가 진행될수록 상세한 모델들은 정확하기는 하지만 결과가 복잡하고 비용이 많이 든다.

성능 테스트 및 평가가 어떻게 진행되는지 보기 위해 콜 센터를 구현하기로 한 어떤 회사를 생각해 보자. 이 회사는 각 부서가 분산되어 있다. 새로운 콜 센터는 고객과 더 좋은 관계를 유지하고 품질 좋은 서비스를 제공하고 효율성과 성능을 개선하며 새로운 영업 기회를 창출하기 위해 개발된다. 개발 부서에서는 통합된 고객 관계 관리 시스템을 구현하기로 결정했다. 제안된 새로운 아키텍처는 전화 통합 소프트웨어로 구성되며 전화 서비스 요청은 어플리케이션으로 전달된다. 콜 센터는 전화, 팩스, 이 메일 등을 통한 고객의 주문 요청을 처리하는 기능을 가지고 있다.

요구사항 분석 단계에서 아키텍트는 시스템 아키텍처를 결정하고 이 시스템의 품질을 보장한 리소스를 결정한다. 아키텍트는 성능을 분석하는데 사용할 모델 초안을 만들려고 한다. 먼저 workload 모델을 생각해보자. 우선 시스템의 workload를 정의해야 한다. 시스템에는 관점에 따라 다양한 workload가 있을 것이다. 콜 센터에서 사용되는 workload는 콜 센터에 전화가 걸리는 비율이다. 어플리케이션 관점에서는 사용자 관점에서 보이는 모든 기능을 포함한다. 데이터베이스 관점에서 workload는 데이터베이스가 받는 쿼리이다. 네트워크의 workload는 패킷 사이즈의 분포와 패킷 도착 시간 등을 포함한 네트워크 트래픽의 특성이다.

Workflow에 대한 두 번째 이슈는 어느 정도로 상세하게 workload를 설명할 것인가 이다. 가장 추상적인 설명 방법은 사용자 관점에서 설명하는 것이다. 예를 들어 사용자가 호출한 함수를 사용하여 workload를 설명할 수 있다. 다른 한편 가장 구체적인 수준의 workload 묘사는 프로젝트가 진행되지 않으면 불가능하다.

이 프로젝트에서 모델에 포함되야 하는 모델은 throughput, response time, availability를 사용한다.

설계 단계에서 아키텍트는 다음과 같은 질문에 대해 답을 해야 한다. 응답 시간에 대한 요구사항을 만족하기 위한 시스템의 throughput은 무엇인가? 이 단계에서 아키텍트는 다음을 가정한다. 서비스의 수는 200개 정도이다. 가장 바쁜 시간에 서비스의 80%가 사용자의 호출에 동시에 응답한다.

사용자와 시스템이 상호작용 하는 방법은 sequence diagram을 사용하여 표현한다. 콜 센터 직원은 고객의 호출에 대해 전화를 받고 기능을 선택하고 시스템에 기능 실행을 요구하고 시스템이 응답하기를 기다리고 결과가 나타나기를 기다리고 고객과 대화하고 사용자의 호출을 중단하고 다른 고객의 호출을 기다린다. Think time은 함수 호출에 대한 응답 시간과 다음 함수 호출 사이의 시간이다. 이 단계에서 콜 센터 어플리케이션에 대한 아키텍트의 관점은 블랙 박스이며 다음 그림으로 표현된다.

그림 Ⅲ-37. 콜 센터에 대한 모델

아키텍트는 평균 think time은 30초(그림에서 Z로 표현됨), 동시 사용자(N)는 200* 0.8이며 시스템의 throughput은 X₀로 표현한다. 응답 시간 R이 1초를 넘지 않는다면 다음과 같이 표현된다.

R = N/X₀ – Z <= 1 sec.

따라서 throughput은 다음과 같다.

X₀ >= N/(Z+R) = N/(Z+1) = 5.16 functions/sec

따라서 초당 5.16 개의 기능이 동시에 실행된다.

시스템 개발 단계에서는 시스템의 다양한 컴포넌트가 구현된다. 이 단계에서 아키텍트는 고객이 요청한 각 기능이 평균 2.2 개의 쿼리 실행을 데이터베이스 서버에 요청한다고 가정한다. 데이터베이스를 구현하기 전에 개발자는 데이터베이스의 용량을 요구되는 성능을 만족시키기 위한 데이터베이스의 용량을 알아야 한다. 데이터베이스 서버와 시스템 서버의 throughput은 다음과 같다.

X_DB = V_DB r X₀

이 식에서 X_DB는 데이터베이스의 throughput이고 X₀는 시스템의 throughput이고 V_DB는 데이터베이스의 함수당 평균 방문 횟수이다. 시간당 쿼리 수로 표현되는 데이터베이스의 최소 throughput은 X₀>= 5.16 functions/sec이다. 각 시스템 함수가 데이터베이스 서버를 2.2 번 호출한다면 데이터베이스의 최소 throughput은

X_DB >= 2.2 r 5.16 = 11.32 transactions/sec

다음에 콜 센터를 통해 제공되는 서비스의 품질을 평가한다. 평균 응답 시간을 R_call이라 하면 응답 시간은 다음과 같이 구성된다.

R_call = R_Appl + R_LAN + R_DB

R_Appl, R_LAN, R_DB는 각각 어플리케이션, 네트워크, 데이터베이스 서버의 응답 시간을 가리킨다. 응답 시간은 1초를 넘을 수 없다. 운영 단계에서 시스템이 이 요구사항을 만족하는지를 계속 모니터링 한다. 피크 타임에서는 시스템이 평균 응답 시간을 벗어나고 응답 시간이 1초 이상이 된다. 관리자는 데이터베이스 서버를 교체하고 서버의 어떤 구성요소가 응답 시간을 느리게 하는데 책임이 있는지 알기를 원한다. 따라서 다음과 같은 질문에 답해야 한다. 쿼리당 평균 응답 시간은 얼마인가? 데이터베이스 서버의 평균 응답 시간은 얼마인가? CPU와 디스크의 사용률은 얼마인가?

데이터베이스는 한 개의 CPU와 두 개의 디스크로 구성되어 있다고 가정한다. 피크 타임에 데이터베이스 서버는 어플리케이션 서버로부터 시간당 57600개의 쿼리를 받는다. 콜 센터 어플리케이션에서 수집된 측정값을 통해 아키텍트는 다음과 같은 데이터를 얻는다. 각 쿼리는 CPU를 50msec동안 사용하고 디스크 1에는 네 번의 I/O를     발생시키고 디스크 2에는 두 번의 I/O를 발생시킨다. 각 I/O를 수행하는 데는 8 msec가 걸린다.

Throughput X₀는 평균 도착 비율 λ과 같다. 즉 57600/3600 = 16 query/sec이다. CPUdp eogks 서비스 요구 시간 D_CPU = 0.050 sec이다. 디스크 1, 2에 대한 서비스 요구 시간은 다음과 같다.

D_disk1 = V₁ r S_disk = 4 r 0.008 = 0.032 sec

D_disk2 = V₂ r S_disk = 2 r 0.008 = 0.016 sec

CPU와 디스크의 사용률은 U_CPU = D_CPU r X₀ = 0.05 r 16 = 80%, U_disk1 = D_disk1 r X₀ = 0.032 r 16 = 51.2%, U_disk2 = D_disk2 r X₀ = 0.016 r 16 = 25.6 % 이다.

CPU와 디스크의 resident time은 다음과 같다.

R'_CPU = D_CPU / 1 - U_CPU = 0.050/1-0.8 = 0.250 sec

R'_disk1 = D _disk1 / 1 – U_disk1 = 0.032/1-0.512 = 0.066 sec

R'_disk2 = D _disk2 / 1 – U_disk2 = 0.016/1-0.256 = 0.022 sec

총 응답 시간은 모든 residence time의 합니다. 따라서 R_DB = R'_CPU + R'_disk1 + R'_disk2 = 0.250 + 0.066 + 0.022 = 0.338 sec이다. CPU는 가장 많은 시간을 차지하기 때문에 CPU가 bottleneck이다. 서비스에 대한 부하가 늘어날 수록 CPU 사용률은 다른 디바이스가 한계에 도달하기 전에 100%에 도달할 것이다.

이상을 요약하여 성능을 측정하고 평가하는 단계를 정리하면 다음과 같다.

첫째, 시스템을 이해한다. 첫 번째 단계는 아키텍처를 이해하고 성능 측면에서 아키텍처를 평가한다.

둘째, workload를 결정한다. 이 단계에서는 workload를 구성하는 기본 컴포넌트를 식별한다. 이 단계의 결과로 다음과 같은 것이 만들어 진다. "workload는 이비지니스 트랜잭션, e-mail 메시지, 데이터 마이닝 요구사항으로 구성된다." 많은 사용자와 서버, 네트워크로 구성된 시스템의 성능은 workload에 의해 결정된다. 따라서 정확하게 workload를 식별하는 것이 중요하다. 한 시스템의 workload는 주어진 시간에 시스템이 동작하는 환경에서 시스템이 받는 모든 입력값의 집합이다. 예를 들어 시스템이 데이터베이스 서버일 경우는 그 workload는 주어진 시간에 서버가 처리하는 모든 트랜잭션이다.

셋째, 시스템을 측정하여 workload 파라메터를 얻는다. 세 번째 단계는 시스템을 측정하여 workload 모델의 매개변수를 얻는다. 측정은 성능 평가의 핵심 단계이다. 측정을 통해서만 시스템의 매개변수를 이해하고 시스템과 모델간의 연결 관계를 알 수 있다. 성능 측정은 주의 깊게 이루어져야 한다. 예를 들어 데이터베이스 서버를 10분 동안 관찰하여 100,000개의 트랜잭션을 완성하였다. 10분간의 데이터베이스의 workload는 100,000 트랜잭션이다. Workload에 대한 설명은 100,000 트랜잭션 각각에 대한 정보(도착 시간, 완료 시간, CPU 시간, I/O의 수)로 이루어진다.

넷째, 성능 모델을 개발한다. 네 번째 단계에서는 성능 모델을 개발한다. 성능 모델은 복잡한 시스템의 행동을 이해하기 위해 사용한다. 모델은 workload가 바뀌었거나 아키텍처가 바뀌었을 때 성능을 예측하기 위해 사용한다.

다섯째, 모델을 검증한다. 다섯 번째 단계에서는 모델을 검증하고 모델의 결과를 평가한다.이 단계는 성능과 workload 모델 둘 다에 적용된다. 성능 모델은 모델에 의해 계산된 성능 값이 실제 시스템에서 측정한 값과 일치하면 검증된 것으로 간주한다.

여섯째, workload를 예측한다. 대부분의 시스템은 개발하는 동안 변경된다. 시스템의 요구사항이 변경되면 workload도 변경된다. 요구사항이 늘어나거나 줄어든다.

 

 

• 시스템의 성능에 영향을 미치는 핵임 요인을 찾는다.
• 시스템을 측정하고 workload를 이해한다.
• 실제 workload의 기본적인 특성을 반영한 workload 모델을 개발한다.
• 시스템의 성능을 정확하게 예측할 수 있는 모델을 개발한다.
• 이 모델을 사용하여 시스템의 성능을 예측하고 최적화한다.

다음 그림은 시스템 개발 단계에 성능 테스트 및 평가 방법을 통합하는 방법을 보여준다.