[SOAP] 인코딩이 웹서비스 퍼포먼스에 미치는 영향

[출처] [본문스크랩] SOAP 인코딩이 웹 서비스 퍼포먼스에 미치는 영향|작성자 독수리

다른 블러그에서 가져온 것들이 이미지가 깨져서 다시 올림

출처:http://www-128.ibm.com/developerworks/kr/webservices/library/ws-soapenc/

인코딩 스타일을 바꿔서 퍼포먼스 향상시키기

Frank Cohen
CEO, PushToTest
2003년 3월

소프트웨어 개발자들은 웹 서비스 시스템 구현에 많은 선택권을 갖고있다. 최근 조사에서, Frank Cohen은 SOAP 인코딩 스타일을 선택하면 시스템 확장성과 신뢰성에 영향을 미칠 수 있다는 것을 발견했다. 이 글에서 다양한 인코딩 방법들을 설명하고 퍼포먼스와 신뢰성의 장단점을 분석한다.

요즘은 소프트웨어 개발 툴, 애플리케이션 서버, 연결성 등 소프트웨어 개발자들에게 만은 선택권이 주어진다. 여러분이 무엇을 선택하든지 완성된 애플리케이션의 확장성과 신뢰성에 영향을 미친다. 특히 웹 서비스를 구현할 때 더욱 그렇다. 특정 클라이언트 환경의 SOAP 인코딩 스타일에 대한 최근 연구에서 한 SOAP 인코딩 스타일이 다른 것 보다 30 배나 향상된 퍼포먼스를 보였다. SOAP 인코딩 스타일, 웹 서비스 개발 툴, 애플리케이션 서버, 플랫폼 등의 퍼포먼스 영향력을 이해하면 시스템 퍼포먼스를 놀랍게 향상시킬 수 있다.

SOAP 인코딩 스타일
SOAP은 XML을 사용하여 소프트웨어 애플리케이션에 전송된 데이터를 마샬링한다. 대부분의 시간 동안 SOAP은 소프트웨어 객체들 간 데이터를 옮긴다. 하지만 SOAP 스팩은 레거시 시스템은 물론 현대적 객체 지향 시스템에 유용하도록 설계되었다. 따라서 SOAP은 한 개 이상의 인코딩 메소드를 정의하여 소프트웨어 객체의 데이터를 XML 포맷으로 변환한다. SOAP으로 인코딩된 데이터는 메시지의 바디에 패키지되어 호스트로 보내진다. 호스트는 XML로 포맷된 데이터를 소프트웨어 객체로 디코딩한다.

SOAP의 도입 이후, 세 개의 SOAP 인코딩 스타일이 유명해졌고 소프트웨어 벤더들과 기술 제공자들 사이에 구현되고 있다:

• SOAP Remote Procedure Call (RPC) 인코딩 : Section 5 encoding으로 알려져 있으며 SOAP 1.1 스팩에 정의되어 있다
• SOAP Remote Procedure Call Literal 인코딩 (SOAP RPC-literal): RPC 메소드를 사용하여 호출하지만 데이터 마샬링에는 XML (do-it-yourself)를 사용한다.
• SOAP d0cument-style encoding : message-style 또는 d0cument-literal 인코딩으로 알려져있다.

다른 인코딩 스타일이 있지만 소프트웨어 개발자들은 이들을 폭 넓게 채택하지는 않는다. 대게 표준에 부합하지 않기 때문이다. 예를 들어 Microsoft는 바이너리 파일 데이터를 인코딩하는 Direct Internet Message Exchange (DIME)를 프로모션 중이다. 이를 제외한 나머지는 SOAP with Attachments를 밀고있다. SOAP RPC 인코딩, RPC-literal, d0cument-style SOAP 인코딩은 소프트웨어 개발자들이 신뢰할 수 있는 인코딩 스타일로 급부상하고 있다.

SOAP 인코딩 스타일이 퍼포먼스에 미치는 영향을 논하기 전에 위 세 가지 스타일의 차이점을 이해해야 한다. SOAP RPC는 최고의 단순함을 제공하는 인코딩 스타일이다. 필요한 매개변수를 통해 원격 객체에 호출한다. SOAP 스택은 이 매개변수를 XML로 시리얼라이즈하고 데이터를 같은 전송을 사용하여 목적지로 옮기고 응답을 받아 이 응답을 다시 객체로 디시리얼라이즈 한 다음 결과를 호출 메소드에 리턴한다. SOAP RPC는 모든 인코딩과 디코딩을 핸들한다. 심지어 매우 복잡한 데이터 타입도 마찬가지다. 이를 원격 객체로 자동 바인딩한다.

XML 포맷으로 된 데이터가 있다고 생각해보자. SOAP RPC는 XML 데이터의 리터럴 인코딩을 하나의 필드로서 허용한다. 이것은 시리얼라이즈 되어서 웹 서비스 호스트로 보내진다. 이를 RPC-literal 인코딩이라고 한다. 단 하나의 매개변수(XML tree)가 있기 때문에 SOAP 스택은 하나의 값만 시리얼라이즈 하면된다. SOAP 스택은 전송 문제도 다루어서 원격 객체에 대한 요청을 받는다. 이 스택은 요청을 원격 객체로 바인딩하고 응답을 핸들한다.

SOAP d0cument-style 호출에서 SOAP 스택은 전체 XML 문서를 리턴 값을 요구하지 않고 서버에 보낸다. 메시지에는 원격 서비스에 적절한 모든 종류의 XML 데이터를 포함할 수 있다. SOAP d0cument-style 인코딩에서 개발자는 모든 것을 핸들한다. 전송 결정(예를 들어, HTTP, MQ, SMTP), SOAP envelope 바디의 마샬링/언마샬링, 필요한 데이터를 찾기위한 요청 및 응답에서의 XML 파싱등이 그것이다.

세 가지 인코딩 시스템을 비교했다. ( 그림 1).

그림 1. 당신에게 맞는 인코딩 스타일은?

SOAP RPC 인코딩은 소프트웨어 개발자들에게 가장 쉽다. 하지만 쉬운 것 만큼 확장성과 퍼포먼스 취약점도 수반된다. SOAP RPC-literal 인코딩에서 XML 파싱 핸들링이 포함되지만 SOAP 스택이 다뤄야하는 오버헤드도 요구된다. SOAP d0cument-literal 인코딩은 소프트웨어 개발자들에게 가장 어렵지만 비교적 적은 SOAP 오버헤드를 요구한다.

SOAP RPC가 쉬운 이유는? 이 인코딩 스타일을 이용해서 코드에 한번 퍼블릭 객체 메소드를 정의하면 된다. SOAP 스택은 이 요청 매개변수들을 객체들로 언마샬링하고 이들을 객체의 메소드 호출로 직접 전달한다. 다른 방법으로는 XML 트리를 통해 파싱하여 퍼블릭 메소드를 호출하기에 앞서 필요한 데이터 엘리먼트를 찾는다.

SOAP 인코딩 스타일. XML 데이터를 직접 파싱하는 것에 대해 논란이 있다. XML 트리의 데이터를 최고로 알고있기 때문에 코드는 그 데이터를 일반화된 SOAP 스택 코드 보다 효율적으로 파싱할 것이다. SOAP 인코딩 스타일로 확장성과 퍼포먼스를 측정할 때 이를 알게될 것이다.

간단한 객체 액세스에는 간단한 퍼포먼스 테스팅이 필요하다!
Elsevier는 과학, 기술, 의료 산업 분야의 주도적인 콘텐트 퍼블리셔이다. (참고자료). Elsevier의 차세대 콘텐트 퍼블리싱 플랫폼은 SOAP을 사용하여 애플리케이션 프로그래밍 인터페이스를 구현하는 것이다. Elsevier의 정보 관리자들은 SOAP 인코딩 스타일을 선택했을 때 확장성은 어느정도인지와 매일 수백만 개의 트랜잭션을 핸들할 수 있는지를 알아야 했다. 그들의 결정은 Elsevier가 새로운 인프라에 자본을 어떻게 투자할 것인지에 영향을 끼치게 된다. 이들 관리자들은 소프트웨어의 릴리스, 애플리케이션 서버 소프트웨어의 릴리스, 플랫폼의 변화 등이 확장성과 퍼포먼스에 어떻게 영향을 미치는지를 알아야 한다.

Elsevier는 내 오픈 소스 TestMaker 유틸리티(참고자료)에 기반한 테스트 환경을 구현하여 이러한 확장성 및 퍼포먼스 문제에 대한 답을 요구했다. 내가 제시한 Elsevier 테스트 환경(그림 2)에는 RPC, RPC-literal, d0cument-style SOAP 메시지를 핸들하고 다양한 애플리케이션 서버에서 설치되는 Test Web Service (TWS)가 포함되어 있다. 이 환경은 TWS의 확장성과 퍼포먼스를 검사하는 지능형 테스트 에이전트도 구비되어 있다.

그림 2. Elsevier 테스트 환경

TestMaker는 웹 서비스의 확장성, 퍼포먼스, 신뢰성을 검사한다. 소프트웨어 개발자, QA 분석가, IT 매니저는 TestMaker를 사용하여 지능형 테스트 에이전트를 구현한다. 이 에이전트는 웹 서비스가 원시 프로토콜(HTTP, HTTPS, SOAP, XML-RPC, SMTP, POP3, IMAP)을 사용하도록 유도한다. 여러 개의 지능형 테스트 에이전트를 구동하면 제품에 근접한 수준의 부하가 만들어지고 시스템의 확장성과 퍼포먼스를 검사할 수 있다.

SOAP 인코딩 확장성을 검사하는 것 외에도 Elsevier 테스트 환경은 Elsevier 시스템만의 벤치마크를 제공하여 다양한 애플리케이션 서버와 플랫폼간 퍼포먼스를 나타낸다. 예를 들어 TWS는 최근에 구현되어 IBM WebSphere Studio, BEA WebLogic, SunONE Application Server에서 구동중이다. ElectricMinds Glue, Apache Axis, Systinet WASP, 기타 애플리케이션 서버로의 포트도 간단할 것이다.

SOAP RPC, SOAP RPC-literal, SOAP d0cument-style 리퀘스트를 지원하는 TestMaker를 커스터마이징하고 이러한 인코딩 스타일로 리퀘스트에 응답하는 TWS를 구현하여 Elsevier 테스트 환경을 구현했다. TWS에 대한 리퀘스트에는 두 개의 매개변수가 있다. 첫 번째는 응답의 사이즈를 정하고 두 번째는 응답 전에 지연 값을 정의한다. TWS는 다섯 개의 응답 엘리먼트에 나타나는 랜덤의 알 수 없는 단어를 포함한 응답 문서를 만들어서 응답한다. TestMaker 테스트 에이전트는 Apache SOAP 라이브러리를 사용하여 TWS에 리퀘스트를 만든다. 테스트 에이전트는 TWS에 대한 컨커런트 리퀘스트의 수에서 응답의 페이로드 까지 다양하다. 테스트 에이전트는 범위가 정해진 로그 파일에 결과를 기록한다. 이는 탤리 스크립트에 의해 요약된다. 이 탤리 스크립트는 성공적인 트랜잭션의 지속시간을 세어 테스트가 수행하는 초당 트랜잭션의 수를 정한다. 전송의 부재 또는 SOAP 오류 같이 성공이 정의된다.

Sun Microsystems 지원으로 Sun Solaris E4500 서버(6 CPU & 4 GB RAM)에 테스트를 구동하였다. TWS는 기반 애플리케이션 서버가 제공하는 SOAP 스택을 사용한다. 예를 들어, WebSphere Studio는 Apache SOAP을 제공하고, BEA WebLogic은 고유의 구현을 제공하는데 이는 JAX-RPC API를 사용한다. 그리고 SunONE Application Server는 Java 1.4 JAX-RPC 라이브러리를 사용한다. 클라이언트 쪽에서, TestMaker는 Apache SOAP 라이브러리를 사용한다.

Elsevier 프로젝트에서 인코딩 스타일 선택이 웹 서비스의 확장성과 퍼포먼스에 상당히 영향을 끼치고 있음을 발견했다. SOAP 구현은 SOAP RPC 인코딩을 사용할 때 여지없이 확장성 문제를 드러낸다. 특히 페이로드 사이즈가 늘어날 때 그렇다. (그림 3).

그림 3. 페이로드 사이즈가 늘어날 때 확장성 문제가 눈에 띄게 나타난다.

그림 3에서 보듯 테스트 에이전트는 초당 294 트랜잭션을 기록했다. 테스트 에이전트가 응답 사이즈를 늘리면 초당 트랜잭션도 내려간다. 96,000 바이트의 SOAP RPC-encoded 데이터를 요청할 때, 에이전트는 초당 9.5 트랜잭션으로 측정되었다.

테스트 환경에서 SOAP d0cument-style 인코딩을 사용했을 때, 퍼포먼스는 훨씬 나아졌다. ( 그림 4).

그림 4. Document-style 인코딩: 늘어나는 페이로드 사이즈에도 비교적 안정적인 퍼포먼스를 보인다.

600 바이트의 d0cument-encoded 데이터일 때 테스트 에이전트는 469 TPS를 기록했다. SOAP RPC-encoded 리퀘스트는 같은 사이즈일 때 294 TPS를 기록했다. 게다가 테스트 에이전트가 응답 사이즈를 늘렸을 때 TPS 값은 급격히 떨어지지 안았다.

SOAP RPC-literal 인코딩을 사용했을 때 중간 정도의 결과를 보인다. (그림 5).

그림 5. SOAP RPC-literal

600 바이트의 SOAP RPC-literal 인코딩 데이터의 경우 테스트 에이전트는 422 TPS를 기록했다. . SOAP d0cument-style 리퀘스트에서 기록된 퍼포먼스와 거의 같다. SOAP RPC-literal 인코딩은 페이로드 사이즈가 늘어날 때에 SOAP RPC-encoded 퍼포먼스의 TPS 기능이 저하되지 않았다.

다양한 애플리케이션 서버들이 확장성과 퍼포먼스에서 어떻게 비교되는지가 궁금할 것이다. 내 경험에 비추어 볼 때, 모든 제품 환경마다 다르다. 따라서 이 글에서 비교를 하는 것 보다 테스트 환경을 다운로드하여 직접 자신의 제품 환경에서 시도하는 것이 더 낫다고 본다. (참고자료).

어떤 툴을 사용할 것인가?
SOAP 인코딩 스타일이 다양한 힘과 유연성을 제공하지만 상호운용성 문제도 야기시킨다. 자바 플랫폼 상의 대부분의 SOAP 툴들은 SOAP RPC 인코딩 스타일이다. 예를 들어, IBM WebSphere Studio Application Developer의 경우 디폴트 인코딩 스타일은 SOAP RPC로 설정되어 있다. 반면 .NET 개발 툴은 d0cument-style SOAP 호출을 기본으로 구현한다. 상호운용이 가능하지만 개발자들은 다양한 인코딩 스타일을 지혜롭게 선택해야 한다 .

소프트웨어 개발자들은 그들의 개발 툴과 환경에 유용한 결정을 내려야한다. SOAP 인코딩 스타일을 핸들링하는 각 툴을 이해하는 것이 신뢰성있는 고성능의 소프트웨어 프로젝트를 달성하는데 있어서 중요하다.

참고자료

• developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
• Web Services SOAP Encoding Performance kit.
• Elsevier 테스트 환경 무료 다운로드.
• "Reap the benefits of d0cument style Web services," by James McCarthy (developerWorks, June 2002).
• "Apache SOAP type mapping" (developerWorks, April 2002).
• Elsevier.
• WebSphere Studio Application Server