-----------------------------------------------------------
Znn.com이라는 사이트를 만들고 레인보우 시스템을 적용.
레인보우 시스템의 효율성을 검증하기 위해
구현 하는데 걸리는 노력, 리소스 오버헤드, 어댑테이션 정도를 측정.
레인보우가 좋은 어댑테이션이라는 것을 증명하고,
좋은 벤치마크의 기준을 제시함.
-----------------------------------------------------------
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5069082서론
레인보우 시스템을 Znn.com에 적용해봤음.
세가지 측면에서 효율성을 평가: 1. 퀄리티 특성이 유지되는지, 런타임 오버헤드, 엔지니어링 effort
Znn.com을 만들고 다른 사람들도 사용할 수 있는 평가툴을 만들었음.
1. 소개
셀프 어댑티브에 관한 요구가 증가함. 그러나 구축하기가 매우 비쌈.
레인보우의 효율성을 두가지 방법으로 평가했음
(1) 레인보우가 퀄리티와 비지니스 목표를 만족하기 위해 얼마나 효율적인가?
(2) 레인보우를 이용하여 어댑테이션을 엔지니어링 하기 위해 얼마나 많은 노력이 필요한가?
평가를 위해 웹기반 시스템 Znn.com을 만들었음.
평가를 위해 툴도 개발했음
(1) Znn.com을 모니터링하고 변경을 일으키기 위해
(2) 레인보우에 플러그인 될 인터페이스를 제공하기 위해
(3) 문제를 일으킬 환경을 생산하기 위해
(4) Znn.com의 동작을 기록하기 위해
레인보우가 어댑테이션에 효율적임을 보여줄 수 있었음.
2. 관련 연구
생략
3. 레인보우 approach
레인보우는 비용 효율적인 셀프 어댑테이션을 위해 두가지 방법에 포커스를 둠.
- 엔지니어링 노력을 줄이고, 어댑테이션 지식을 명시적인 표현.
타겟 시스템, 실행 환경 을 모니터링 하고 아키텍쳐 모델 내에서 관찰에 반응,
개선을 위한 기회를 탐지, 어뎁테이션 코스를 결정, 변경을 실행(act)하기위한 프레임웍을 제공함
일반적이고, 재사용 가능한 인프라 스트럭쳐를 제공. 다양한 분야의 시스템에 적용할 수 있도록
명시적인 커스터마이제이션 포인트를 제공. 유용한 추상화를 제공.
어뎁테이션을 자동화하기위해 Stitch라는 언어를 제공함.
strategies, tactics, poerators와 같은 하이레벨 어뎁테이션 컨셉을 이용해 인간 어뎁테이션 지식을 표현함.
3.1 커스텀할 수 있는 셀프 어댑테이션 프레임웍
레인보우 프레임웍은 컴포넌트-and-커넥터 아키텍쳐를 사용
Translation Infrastructure – probes and gauges- 내에서 모니터링 매터니즘은 실행중인 타겟 시스템을
모니터링하고 Model Manager에 의해 관리되는 아키텍처 모델의 특성을 업데이트함.
Architecture Evaluator는 시스템이 허용 범위 안에서 운영되고 있는지 확인하기 위해 모델을 평가함.
Evaluator가 허용 범위를 벋어났다고 판단하면 Adaptation Manager가 어댑테이션 프로세스를 초기화.
Adaptation Manager가 현재 상태에 기반하여 적절한 전략을 선택.
Strategy Executor가 시스템 레벨 이펙터를 통해 전략을 실행.
레인보우는 다른 도메인에 커스텀이 가능함
커스텀 가능한 셀프 어댑테이션 프레임웍은 여러 장점을 가짐
- 재사용가능한 인프라 스트럭쳐 : 개발 비용 감소
- 모듈화된 어뎁테이션 정책 언어는 어댑테이션 concern을 분리된 것으로 고려할 수 있게 해줌.
레인보우 프레임웍은 자바로 만들어졌음. translation layer 아래의 엘리먼트들은 언어나 스크립트로 만들어졌지만
프로브와 이펙텨의 커뮤니케이션 프로토콜을 따름. 런타임에 레인보우 마스터는 Architectural-Layer
엘리먼트를 인스턴스화함. Rainbow Delegate가 플로브, 게이지, 이펙터를 관리하기 위해
시스템의 각 컴퓨팅 노드에 디플로이됨. 이벤트 버스는 Marster와 Delegate 사이의 통신을 조정해줌.
3.2 Znn.com 시스템
cnn.com과 같은 뉴스 웹사이트. N-tier를 만족하는 웹기반 클라이언트-서버 시스템임. 그림2 참조.
로드 밸런싱을 위해 로드 밸런서를 사용.
퀄리티 목표는 서버 풀의 비용을 특정 운영 예산내에서 유지하면서,
적절한 응답시간내에 사용자에게 뉴스 컨텐츠를 제공하는 것임.
때때로, 매우 유명한 이벤트때문에 Znn.com은 뉴스 리퀘스트가 급격히 증가하여 최대 풀 사이즈를 넘어버림.
이런 피크타임에는 문자 컨텐츠만 제공함.
한마디로 세가지 퀄리티 목표는 (a) 퍼포먼스, (b) 비용, (c) 컨텐츠 엄수임
퍼포먼스 분석은 응답시간, 서버 로드, 커넥션 대역폭을 모니터링.
비용 분석은 실행중인 서버의 갯수와 일치.
컨텐츠 엄수를 위해 풀 멀티미디어부터 텍스트까지 컨텐츠 범위의 레벨을 만들었음.(high, medium, low)
N-tier-client-server 아키텍쳐 스타일은 다음을 포함
• Types: ClientT, ServerT, ProxyT, HttpConnT
• Properties: ClientT.experRespTime, ServerT.cost /
load / fidelity, HttpConnT.bandwidth
• Operators: ServerT.activate() / .deactivate() / .setFidelity(level : int)
setFidelity() 함수는 컨텐츠 레벨을 설정함.
응답시간이 높으면, 목표 A는 예산내라면 Znn.com이 서버 풀 사이즈를 늘려야 한다고 제안.
예산밖이라면 Znn.com이 문자 모델로 전환. 응답시간이 낮으면 목표 C는 서버 풀사이즈를 낮춤.
예산이 많이 남으면 멀티미디어 모드로 변경.
이러한 방법으로 다양한 목표의 트레이드 오프를 만족시킴.
이러한 전략으로부터 네가지 어댑션 전략을 정의했음.
- SimpleReduceResponseTime : 응답시간이 길어지면 컨텐츠 피델리티를 한단계 낮춤.
- SmarterReduceResponseTime: 클라이언트가 많아지면, 서버를 추가함. 그 후 피델리티를 낮춤.
- ReduceOverallCost : 전체 서버 비용이 임계치를 넘으면, 코스트가 임계치 아래로 내려갈때까지 서버를 끔
- ImproveOverallFidelity : 평균 컨텐츠 피델리티가 임계치 아래로 떨어지면, 모든 서버의 피델리티를 두번까지 올림.
4. Znn.com 평가
레인보우의 효율성을 측정하는 것은 다음을 보여주는 것을 요구함
1. 레인보우-커스터마이제이션된 타겟 시스템은 전체적인 효율이 증가되도록 셀프 어댑션 된다.
2. 셀프 어댑테이션은 낮은 런타임 리소스 오버헤드를 유발한다.
3. 타겟 시스템에 레인보우를 적용하기 위해 필요한 노력은 처음부터 만드는 것보다 훨씬 더 적어야 한다.
4.1 Show that Znn.com Is Self-Adaptive
실험을 위해 웹사이트를 만들었음. “Slashdot-effect"를 Znn.com에 시험해볼 것임.
다섯대의 서버, 두대의 클라이언트, 한대가 밸런서.
라운드 로빈으로 로드 밸런싱 수행
“Slashdot-effect" 효과를 일으키는 workload를 디자인.
1. 1 minute of low activity, 6 unique visits/min 2. 5 minutes of sharp rise in requests, ramping up to 600 visits/min (+120 visits/min/min) 3. 18 minutes of peak in requests, sustained at 600 visits/min 4. 36 minutes of linear decrease, ramp down to 60 visits/min (-15 visits/min/min)
이를 JMeter로 구현하여 두대의 컴퓨터에 탑재. 레인보우 어댑션없이 돌아가도록하는 것돠
어댑션과 함께 돌아가도록 시험함.
매 시험마다 샘플수, 응답 지연, 리퀘스트 throughtput 등을 기록.
그림 4는 두 시험 결과를 보여주는 그래프임.
어댑테이션이 적용된 실험이 다른것보다 낮은 레이턴시와 높은 throughtput을 보여줌.
따라서 레인보우가 효율적이라는 것을 알 수 있음.
4.2 Show that Resource Overhead Is Low
리소스 오버헤드를 CPU 이용률로 측정. 2% 미만 사용. 매우 낮음
4.3 Show Low Customization Effort
적용하는데 93시간이 걸림. 커스터마이제이션 노력이 매우 적음.
처음부터 만드는것과 비교하기 위해 개발 태스크를 나눔 - 3개의 개발 태스크와 1개의 evolution 태스크.
: 도메인 분석, 모델 캡쳐, 디자인과 구현, 업데이트와 모디피케이션
각 태스트를 완료하는데 걸리는 시간을 측정
중략
결론적으로 5% 미만의 리소스 오베헤드가 발생함. 매우 낮은 수준임
생략..
