문서요약 - 분산 시스템을 위한 테스트 아키텍쳐 by Walter

제목: 분산 시스템을 위한 테스트 아키텍쳐(Test Architectures for Distributed Systems - State of the Art and Beyond)

저자: T. Walter 외 2인, 스위스

문서유형: 연구소 기술문서(총 26페이지)

 

프로토콜 적합성 테스팅에 중점을 둔 CTMF의 테스트 아키텍쳐를 확장하여 분산 시스템의 적합성/상호운용성/성능 테스팅을 지원하는 포괄적인 테스트 아키텍쳐를 제안한 자료

---

분산 프로세싱 시스템

• 메모리를 공유하지는 않지만 통신 네트워크 상으로 메시지를 전송함으로써 서로 협업하는 다수의 자치적인 프로세싱 요소로 구성된 물리적 아키텍쳐를 활용
• 개별 컴포넌트들이 여러 다른 장소에 위치하므로 컴포넌트들 간의 통신에 있어 지연이나 실패가 발생할 수 있는 환경에서 정보 프로세싱이 이루어짐
• 중앙집중식(centralized) 시스템에 비하여 자원을 공유할 수 있고, 동적 확장이 가능하며, 가용성과 성능 향상이 용이 하다는 장점이 있다.
• 대개 이질적인 구성요소로 구성됨(예, 상호연결된 네트워크, 운영체제, 미들웨어 플랫폼, 개별 컴포넌트 개발에 사용된 프로그래밍 언어 등)
• 개방형 분산 시스템(open distributed systems)의 목표는 이런 이질성(heterogeneity)에 구애 받지 않고 분산 환경의 어디에서든 분산 시스템의 컴포넌트로 접근이 가능하도록 하는 것이다.

분산 프로세싱 시스템의 표준 프레임워크

분산 프로세싱 시스템의 급속한 성장으로 표준화된 프레임워크가 필요해졌으며, 대표적으로 아래와 같은 것들이 있다.

• RM-ODP(ISO/ITU-T Reference Model for Open Distributed Systems, 1991): 5가지 다른 관점(엔터프라이즈, 정보, 컴퓨테이션, 엔지니어링, 기술)에 기반한 포괄적 객체 지향 아키텍쳐를 기술한 프레임워크. 이 프레임워크는 ODP 시스템을 지원하는데 필요한 기능을 정의하고 분산 투명성 달성을 위한 ODP 기능 사용 방법을 제시한다.
• CORBA(OMG Common Object Request Broker Architecture, 1995): 분산 환경에서 객체들의 투명한 상호작용을 지원하는 분산 컴퓨팅 및 메카니즘을 위한 객체 지향 프레임워크를 제공. 이 아키텍쳐의 기본(basis)은 ORB(object request broker)이다.
• TINA(Telecommunication Information Networking Architecture, 1998): 미래 전자통신 네트워크를 위한 프레임워크 제공을 목표로 함. 아키텍쳐의 커널은 RM-ODP의 컴퓨테이션 및 엔지니어링 모델 개념을 차용한 DPE(distributed processing environment)이다. TINA DPE의 기본은 CORBA ORB이다.
• DCE(Open Group’s Distributed Computing Environment, 1992): 분산 프로세싱 시스템을 위해 통신 네트워크 및 미들웨어 플랫폼에 독립적인 플랫폼을 제공. 클라이언트 서버 아키텍쳐를 기반으로 하며 객체 지향 기술을 지원하지 않는다. 

적합성(Conformance)

• ‘적합성’은 분산 프로세싱 시스템의 다양한 컴포넌트의 호환성(compatibility), 상호운용성(interoperability), 이식성(portability)을 보장하기 위한 주요 개념이다. 따라서 적합성 테스팅(conformance testing)은 분산 프로세싱 시스템의 컴포넌트들이 상호연동(interwork) 할 수 있는지를 체크하는 주요 도구이다.
• ODP에서는 적합성을 명세와 구현 간의 관계(relationship)로 정의한다. 즉, 명세의 특정 요구사항이 구현에 의해 충족되면 관계가 유지되는 것으로 간주한다. ODP는 구현이 테스트되어야 하는 지점인 ‘적합성 지점(conformance points)’을 식별한다. ODP에서 적합성 테스팅은 분산 시스템의 관점 모델(viewpoint models)에 의해 주어진 모든 요구사항을 테스트 하는 것을 의미한다.
• CORBA에서 적합성은 CORBA 아키텍쳐의 인터페이스를 나타내는 ‘순응 지점(compliance points)’에 의해 정의된다. ORB 간의 상호운용성을 향상시키기 위해 ORB 상호운용성 아키텍쳐(GIOP, IIOP, ESIOP)의 순응 지점에 강조를 둔다.
• TINA 프레임워크에는 현재 적합성에 대한 명백한 정의가 없지만 적합성을 정의하는 기준으로 ‘참조 포인트(reference points)’를 사용하려는 작업이 진행 중이다.
• DCE에서 적합성은 시스템 명세와 그 적합성 테스트 스위트(conformance test suites)를 기반으로 한다. 구현이 이 적합성 테스트를 통과해야만 DCE에 부합하는 것으로 인정된다.

CTMF(Conformance Testing Methodology and Framework)

• OSI(Open Systems Interconnection) 참조 모델을 따르는 통신 프로토콜 및 서비스의 테스트를 위해 정의된 CTMF(ISO IS-9646, 1995)는 가장 성공적인 적합성 테스팅 표준임
• CTMF는 테스트 케이스 명세를 위한 여러 테스트 아키텍쳐를 정의. 예) 추상적 테스트 방법(abstract test methods), TTCN(Tree and Tabular Combined Notation)
• CTMF 테스트 아키텍쳐가 OSI 적합성 테스팅 영역 외에서도 성공적으로 사용되기는 했지만(예, ATM 프로토콜 테스팅) CTMF가 다른 타입의 테스팅(예, 실시간, 성능)이나 신규 아키텍쳐와 프레임워크(예, ODP, CORBA, TINA, DCE)를 기반으로 한 애플리케이션에는 적합하지 않다는 것이 일반적인 인식임

 

à 따라서 본 논문은 적합성 외의 테스팅 타입과 오늘날 사용되는 신규 분산 프레임워크에도 적용할 수 있는 분산 시스템 테스트 아키텍쳐를 제안하고자 함

현재의 분산 시스템 테스트 아키텍쳐

<문서에 CTMF 표준의 적합성 테스팅 아키텍쳐에 대한 설명이 나오지만 이 부분 요약은 생략>

CTMF 테스트 아키텍쳐를 기반으로 한 현재의 상호운용성, 성능, QoS 테스트 아키텍쳐를 살펴보면 아래와 같다.

1) 상호운용성 테스팅(Interoperability Testing)

• 하나의 구현과 다른 구현과의 상호운용성 정도를 평가. 즉, 특정 구현이 동일한 타입의(또는 다른 타입의) 또 다른 구현과 통신할 수 있는지를 체킹한다.
• 상호운용성 테스팅이 표준화되지는 않았지만 두세 개의 제안과 가이드라인이 존재함. OSI 환경에서 상호운용 테스팅 방법으로 수동적 테스팅(passive testing)과 능동적 테스팅(active testing)이 있다. 능동적 테스팅은 통제된 에러 생성 및 통신에 대한 상세한 관측을 허용하는 반면 수동적 테스팅은 단지 유효한 동작만을 테스팅 하는 것이 차이점이다.
• OSI 상호운용성 테스팅은 테스트할 프로토콜 엔터티의 ‘참조 구현(a reference implementation: RI)’을 사용하여 수행된다. 정의 상 RI의 동작은 항상 정확하며, IUT와 RI가 상호작용(interwork) 못하는 경우는 IUT의 에러 때문이다.
• 아래 그림은 수동적 상호운용성 테스트 시스템 아키텍쳐를 보여준다. 두 개의 구현이 상호연결 되었으며 통제 및 관측은 두 개의 UT에 의해 수행된다. 

[수동적 상호운용성 테스팅 아키텍쳐]

• 현실에서는 대개의 경우 가용한 RI가 존재하지 않으므로 대신 두 개의 IUT가 사용되고 이 IUT들간의 통신이 모니터되거나 에뮬레이션 된다. 아래 그림은 이런 경우의 테스트 구성(test configuration)을 보여준다.

[상호운용성 테스트 아키텍쳐 예]

2) 성능 테스팅(Performance Testing)

• 정상 및 과부하 상황에서의 네트워크 컴포넌트의 성능을 테스트 하는 것이 주된 목표
• 여러 다른 패러미터 세팅 범위에 대한 네트워크 컴포넌트의 성능 레벨을 식별하고, 컴포넌트의 측정된 성능을 평가한다.
• 성능 테스트 스위트는 측정되어야 할 성능 특징(performance characteristics)과 측정 실행 방법에 대한 절차(procedures)를 정확하게 기술한다. 또한 네트워크 컴포넌트의 구성, 기저 네트워크의 구성, 네트워크 부하(load) 특징 등을 포함한 성능 테스트 구성(performance test configuration)을 기술한다.
• 테스트 대상 네트워크 컴포넌트의 특징에 따라 다른 타입의 성능 테스트 구성이 정의된다. 아래 그림은 통신 프로토콜을 위한 성능 테스트 구성의 예이다. 그림에서 PE(Tested Protocol Entity)는 테스트 대상인 프로토콜 엔터티를 나타냄
• 전방 테스트 컴포넌트 FT(Foreground test components)는 테스트 대상 네트워크의 통제 및 관측 지점을 구현한다. UFT(Foreground Tester for Emulated Protocol User)는 에뮬레이션된 프로토콜 사용자를 나타내고, LFT(Foreground Tester for Emulated Peer-to-Peer Protocol Entity)는 에뮬레이션된 동등 계층 프로토콜 엔터티를 나타낸다.
• 후방 테스트 컴포넌트 BT(Background test components)는 테스트 대상 네트워크 컴포넌트에 로드하기 위한 연속적인 데이터 스트림을 생성한다. BT는 테스트 대상 네트워크를 직접적으로 통제 또는 관측하지 않고 대신 네트워크를 정상 및 과부하 상황에 빠트려서 간접적으로 테스트 대상 네트워크에 영향을 준다.
• 모니터 컴포넌트(M)는 성능 테스트 동안 실제 네트워크 로드를 모니터 하기 위해 사용된다.

[통신 프로토콜을 위한 성능 테스트 구성 예]

3) Quality-of-Service Testing

• QoS(Quality-of-service)는 네트워크의 통신 엔터티 간의 연결(connection)을 특징짓는 패러미터 집합을 나타낸다. QoS 패러미터는 주로 성능과 신뢰성에 관계됨 예) 처리량, 지연, 지터, 에러율, 실패 가능성
• QoS 패러미터는 연결의 셋업 시에 서비스 사용자와 서비스 제공자 간에 협상되며, 협상된 QoS 패러미터는 연결이 살아 있는 동안 유지되어야 한다. 협상된 QoS 패러미터 유지를 책임져야 할 주된 주체는 서비스 제공자이다.
• QoS 시멘틱은 어떻게 QoS 패러미터가 협상되는지 그리고 협상된 QoS 패러미터가 어떻게 처리되는지 그 절차를 정의한다. 또한 QoS 패러미터 위반을 어떻게 처리할지도 정의한다.
• QoS 테스팅은 QoS 유지보수(maintenance)를 수행하는 프로토콜 구현의 동작을 평가하는 것을 의미한다. 하지만 구현의 동작을 직접적으로 통제 및 관측할 필요는 없으며 테스터(테스트 시스템)가 명세된 동작을 협의된 QoS 시멘틱에 따라 최종적으로 관측할 수 있으면 충분하다.
• 아래 그림은 QoS 테스팅을 위한 테스팅 아키텍쳐를 나타낸다. 소극적 상호운용성 테스팅 아키텍쳐와 유사하지만 차이점은 QoS 테스팅에서는 IUT가 분산되어 있다.
• 일부 QoS 패러미터 테스트는(예, 에러율 테스트, 지연 테스트) 네트워크의 적극적인 관여를 요구하므로 이를 위해 네트워크가 구성가능(configurable) 해야 한다. 즉, 테스팅 아키텍쳐가 구성 정보(configuration information) 교환을 위해 테스터와 네트워크간의 통신 링크를 제공한다.

[QoS 테스팅 아키텍쳐]

분산 시스템 테스트 아키텍쳐에 대한 요구사항

오늘날의 분산 시스템은 아래 그림처럼 크게 세 계층으로 나뉜다. 최상단의 애플리케이션 레벨은 잘 정의된 인터페이스를 통해 상호작용하는 오브젝트로 구성되며, 그 아래의 미들웨어 플랫폼은 다양한 분산 투명성(예, 엑세스 투명성, 위치 투명성)을 제공하여 분산 애플리케이션의 구현을 지원한다. 미들웨어 플랫폼의 예로는 OMG CORBA, OSF DCE 등이 있다. 다양한 네트워크 노드와 엔드시스템을 가진 최하단의 통신 네트워크는 미들웨어 플랫폼에게 전송 서비스(transmission services)를 제공한다. 

[분산 시스템 아키텍쳐의 단순화된 뷰]

신규 프레임워크를 기반으로 한 이런 분산 시스템을 테스팅 하는데 있어 요구사항은 아래와 같다.

• 분산된 테스트 컴포넌트를 동기화할 수 있는 수단을 가진 분산 테스팅 아키텍쳐의 개발
• 동적으로 구성 가능하고(configurable) 확장 가능한(scalable) 테스트 아키텍쳐 지원
• 여러 통신 시나리오(유니캐스트, 멀티캐스트, 브로드캐스트)를 위한 테스트 구성(test configurations)을 표현할 수 있는 능력
• 내부 컴포넌트와 인터페이스에 접근하는 그레이박스(grey-box) 테스팅 사용 가능성
• 분산 시스템의 실시간/성능/QoS 테스팅 지원
• 필수적인 상호운용성 측면에 중점을 둔 상호운용성 테스팅 지원
• 분산 시스템 개발에 사용되는 객체 지향 기술에 부합하는 테스트 방법론 개발
• 관리/모니터링/측정 시스템을 활용하는 테스트 아키텍쳐
• 분산 시스템의 전개 이전(pre-deployment) 단계, 전개(deployment) 단계, 사용(usage) 단계에서의 테스팅을 지원하는 방법
• 분산 시스템의 복잡성을 다루기 위한 효율적인 테스팅 방법

제안된 분산 시스템 테스트 아키텍쳐

본 논문은 위에 나열된 분산 시스템의 테스팅 아키텍쳐에 대한 요구사항을 충족시키는 포괄적인 테스트 시스템 아키텍쳐를 제안한다(포괄적이라는 것은 제안된 아키텍쳐의 기본 컴포넌트들을 테스트 할 특정 애플리케이션에 맞게 적절히 조합/구성 가능함을 의미). 제안된 포괄적 테스트 아키텍쳐는 아래와 같은 여러 컴포넌트 타입의 여러 개의 인스턴스로 구성된다.

• IUT(implementation under test): 테스트 할 분산 애플리케이션의 구현(하드웨어 또는 소프트웨어의 한 조각). IUT는 CL을 통해 직접적으로 또는 IC를 통해 간접적으로 관측 및 통제된다. 아래 그림 예는 3개의 IUT를 포함(IUT1, IUT2, IUT3)
• IC(interface component): IUT와 인터페이스 하는데 필요한 컴포넌트. 예) IUT가 임베디드된 애플리케이션 또는 IUT 하단의 기저 서비스(underlying services). 아래 그림에서는 2개의 IC가 존재함. IC ComService는 3개의 IUT 간의 통신 서비스를 제공하고, IC UInterface는 IUT1으로의 인터페이스를 기술한다.
• TC(test component): 타 TC와 협업하거나 IUT를 통제 및 관측 함으로써 테스트 판정에 기여하는 컴포넌트. 단 한 개만 존재하는 MTC(Main Test Component)는 테스트 런을 시작하고 종료시키며, 또 다른 TC 타입인 ITC(implicit TC)는 TC가 존재함을 나타내지만 테스트 아키텍쳐의 타 컴포넌트와 어떻게 통신할지는 명세하지 않은 것이다. 아래 예는 총 4개의 TC를 포함: 1개의 MTC(MasterTC), 1개의 ITC(ITCexample), 2개의 일반 TC(TCcreate, TCmonitor). TCcreate에서 괄호 안 숫자 3은 테스트 런 중에 생성 가능한 최대 인스턴스 수를 나타냄
• CC(controlled component): 테스트 판정에 기여하지 않지만 SUT 고유의 데이터를 TC 또는 SUT로 제공하는 컴포넌트. 테스트 케이스 고유의 환경을 셋업 하거나 테스트 실행 통제를 위해 사용됨. 예) 부하 생성기, 에뮬레이터, 시뮬레이터. 아래 예에 포함된 2개의 CC(Traffic1, Traffic2)는 IC ComService를 위한 백그라운드 로드를 생성 및 관리한다.
• CoP(communication point): 테스트 아키텍쳐에서 통신이 관측/통제/모니터 될 수 있는 지점을 나타냄(CTMF의 PCO에 상응함). 동일한 CoP에서 여러 개의 통신 흐름에 접근하는 것이 허용된다. 단순화를 위해 CoP에 할당된 특별한 시멘틱이 없으며(CTMF의 PCO는 FIFO 큐 시멘틱을 가짐), 통신 시멘틱은 CL에게 주어진다. 아래 예에서는 8개 CoP가 사용됨(CoP1, CoP2, ..., CoP8)
• CL(communication link): 가능한 통신과 통신 유형(동기식/비동기식, 일방향/양방향)을 기술하는 수단. IUT, IC, TC, CC는 CL을 사용하여 CoP와 연결됨. 아래 예에서는 18개의 CL이 존재함. 예를 들어, MasterTC로부터 Traffic1과 Traffic2로의 비동기식 일방향 통신은 CoP1을 통한 CL1, CL2, CL3를 사용하여 실현됨. 이 통신은 CC를 시작하고 멈추는 데에만 사용된다. MasterTC와 UInterface 간의 양방향 비동기식 통신은 CL4와 CL5을 사용하여 기술됨. IUT3와 TCcreate 간의 양방향 동기식 통신은 CoP5를 통한 CL6와 CL7을 사용하여 정의됨. CL8은 통신 모니터를 허용하는(즉, CoP에서 청취를 하는) 수동적(passive) CL이다. 즉, TCmonitor가 IUT3와 ComService 간의 통신을 모니터 함
• SUT(system under test): 다수의 IC와 다수의 IUT의 조합. CTMF에서는 다수의 IC와 하나의 IUT를 합쳐서 SUT라 부르지만 제안된 아키텍쳐에서는 하나의 SUT에 여러 개의 IUT가 포함될 수 있음

[포괄적 테스트 아키텍쳐 모델]