웹 서비스의 단점

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.  제안 및 의견 피드백

난이도 : 초급

Joe Clabby, 회장, North American Operations, Bloor Research

2002 년 7 월 01 일
2003 년 1 월 10 일 수정

Bloor Research - North America (Bloor NA)는 웹 서비스 아키텍쳐의 진화를 면밀히 관찰하면서 웹 서비스의 엔드 유저, 벤더 개발, 표준의 진화 등을 연구했다.

Overview

연구를 통해서 오늘날 존재하는 웹 서비스 아키텍쳐의 일곱 가지 단점들을 발견했다:

1. 보안/프라이버시
2. 메시징/라우팅
3. 서비스 품질/신뢰성
4. 트랜잭션 프로세싱
5. 관리
6. 퍼포먼스
7. 상호운용성

그러나 우리의 연구는 이러한 단점들 하나하나가 다양한 컨소시엄 또는 벤더에 의해 만들어진 제품이나 솔루션을 사용하여 다루어질 수 있다는 것을 시사하고 있다. 따라서 우리는 웹 서비스 아키텍쳐가 다양한 엔터프라이즈 컴퓨팅 환경에서 전개될 수 있고 또 전개되어야 함을 믿는다.

이를 증명하기 위해 Bloor NA는 최근 109 페이지 분량의 보고서인 Web Services Gotchas를 완성했다. Bloor NA는 이 보고서를 카피 당 수백 달러에 판매하는 대신 IBM에 배포권/웹 게시권을 팔았다. Bloor NA는 보고서를 판매하는 것보다 Web Services Gotchas가 Information Systems (IS) 커뮤니티에 더욱 광범위하게 배포될 것이라고 믿었고 결과적으로 많은 IS 바이어들이 웹 서비스의 한계(gotchas)와 관련 처방을 이해할 수 있게 될 것임을 믿었다. IS 커뮤니티에 이 같은 값진 서비스를 제공할 수 있도록 한 IBM에 감사를 전하는 바이다.

이 글은 전체 보고서를 간략하게 간추린 것이다.

위로

웹 서비스란 무엇인가?

이 보고서의 작성자와 독자들이 웹 서비스 아키텍쳐에 대한 공통 개념을 공유하는 것이 필요하기 때문에 Bloor NA는 웹 서비스 정의를 다시한번 내리는 바이다:

다음은 웹 서비스 아키텍쳐와 관련되어 있지만 공식적인 웹 서비스 표준은 아닌 것들이다:

• Universal Description, Discovery, and Integration (UDDI) : 레지스트리 표준 (UDDI.org)
• Extensible Markup Language (XML) -- 포맷/신택스를 표시하는 수단
• Hypertext Transport Protocol (HTTP) -- 인터넷 통신 프로토콜

자세히 보기

SOAP은 애플리케이션을 호출하는데 사용되는 원격 프로시져 호출 메소드이다.

WSDL은 애플리케이션들이 서로서로 "통신"하는 방식을 정의하는데 사용되는 템플릿/인터페이스이다.

UDDI는 UDDI.org에서 개발되는 레지스트리/디렉토리 표준이다. UDDI는 웹 서비스 레지스트리 표준이 되기를 고대하고 있다.

웹 서비스는 XML 데이터를 이동시킨다.(따라서 XML은 정보와 데이터를 포맷팅하는 진정한 언어/신택스 이다). 좀더 자세히 표현하자면 애플리케이션간 공유되는 콘텐트와 데이터를 설명하고 인간과 기계모두 읽을 수 있는 "메타-언어"로서 설명할 수 있다.

간단히 말해서 XML은 데이터와 콘텐트가 읽기 가능하고 동종/이종 애플리케이션 환경에서 조작될 수도 있는 일반적인 포맷으로 패키지될 수 있도록 한다. 이것은 편지와 같다. 모든 수신인들이 읽는 방법을 알고 있고 모든 엘리먼트는 자르기, 붙이기, 조작, 혼합, 매칭, 다른 문서로 재탄생, 데이터 프로세싱을 위한 폼으로 변환될 수 있다. XML은 콘텐트(보고서 또는 편지같은 작성된 정보) 또는 데이터(트랜잭션형 정보 또는 데이터베이스에서 나온 숫자) 정보를 수반할 수 있다.

또한 HTTP를 공식 웹 서비스 프로토콜로 포함시키지 않았다. 대신 HTTP는 일반적인 인터넷 통신 프로토콜이다. 웹 서비스와 다른 분산 컴퓨팅 아키텍쳐에서 사용되어 인터넷을 통해 데이터를 전송한다. 주의: 오늘날 대부분의 웹 서비스 SOAP 메시지들은 HTTP를 사용하여 보내진다. 하지만 SOAP은 전송 독립성이 있기 때문에 HTTP 외에도 기타 전송 프로토콜을 통해서도 사용되어 세션을 열고 데이터를 송수신 한다.

위로

웹 서비스는 어떻게 작동하는가?

웹 서비스는 크로스 플랫폼 p2p 통신을 조성하기 위해 설계된 분산 컴퓨팅 아키텍쳐이다. 그림 1 에서 서비스 "A" (요청자 애플리케이션)은 웹 서비스 프로그램형 인터페이스(SOAP)와 레지스트리(UDDI)를 사용하여 서비스 "B"의 위치를 찾는다. WSDL은 프로그램이 서로 통신하는데 필요한 매개변수를 찾아 내는 것을 도울 수도 그렇지 않을 수도 있다. 이 모든 태스크는 인터넷을 통해 발생한다(통신 프로토콜로서 HTTP가 사용된다).

출처: Bloor Research North America - 2002년 7월

위로

분산 컴퓨팅 아키텍쳐로서 웹 서비스의 특징

아마도 웹 서비스를 이해할 수 있는 가장 중요한 개념은 강결합(tightly coupled)과 약결합(loosely coupled) 애플리케이션의 개념일 것이다.(그림 2) 간단히 말해서 전통적인 분산 컴퓨팅 애플리케이션은 프로그래머가 애플리케이션에게 정보를 공유하고 협업을 수행하기 위해서 어디서 서로를 찾아야 하는가를 "지시하도록" 하는 것에 의존했다. 이러한 애플리케이션은 나름대로의 장점을 갖고있다. 이를 테면 각각의 애플케이션이 서로에 대해 알고 있다면 보안이 수월해진다. 그리고 협업 애플리케이션 모듈이 어디에 존재하는지 알기 때문에 고장난 애플리케이션을 픽스하기도 쉽다. 강결합 애플리케이션 개발 접근방식을 사용하면 서비스 품질, 보안, 프라이버시, 데이터 무결성, 복잡한 트랜잭션 프로세싱에 있어 특별한 보장을 받는다. 강결합 애플리케이션들은 그들이 사용하는 애플리케이션들의 위치를 알고 있다. 강결합 애플리케이션은 그들의 파트너 애플리케이션이 어떻게 작동하는지 알고 있다. 강결합 애플리케이션은 근본적으로 관리가 쉽다. 이 모든 이유로 인해(보안, 신뢰성, 서비스 보장) 강결합 접근방식은 엔터프라이즈 컴퓨팅을 주도해왔다.

출처: Bloor Research NA - 2002년 5월

이런 "경직성"에는 단점도 있다. 애플리케이션들은 서로를 어떻게 찾아야하는지에 대해 프로그래머에게 지시를 받아야한다. 또한 서로 어떻게 통신하는지에 대해서도 마찬가지이다. 게다가 장기적인 관리/수리가 필요하다. 프로그래머는 협업 애플리케이션간 커넥션과 관계를 정의하는데 많은 시간을 보내야하기 때문에 강결합 애플리케이션 구현은 종종 어렵고 까다롭다.

반면, 약결합 방식의 애플리케이션 디자인 및 관리도 이점을 갖고 있다. 약결합 애플리케이션을 구현은 더 간단하다. 개발자들은 협업 애플리케이션들을 어디서 찾아야하는지를 정의하고 그들이 통신하기 위한 규칙을 정의하는데 많은 시간을 들이지 않아도 되기 때문이다. 약결합 애플리케이션의 관리 또한 더 쉽다. 약결합 애플리케이션은 수준급의 유연성과 상호운용성을 제공한다. 이는 강결합의 크로스 플랫폼 p2p 통신 환경을 구현하는 전통적인 접근방식을 사용해서는 성취할 수 없는 것이다.

IS 바이어들이 약결합과 강결합의 비교에 비중을 두게 되면서 다음과 같은 결론에 이르게되었다:

• 강결합은 비교적 까다롭다.(하지만 근본적으로 신뢰성, 보안, 튜닝가능성이 높다).
• 약결합은 동적 검색과 이종의 크로스 플랫폼 간 상호운용성의 이점이 있다. (하지만 조직들은 보안, 신뢰성, 관리에 필요한 보완 소프트웨어를 찾아 통합해야한다).

여러분의 조직은 어떤 접근방식을 선택할 것인가? 해답은 이원적일 수 없다. 두 접근방식 모두 유효하고 타당하다. 하지만 어떤 애플리케이션은 강결합에 더 맞는다. 배치(batch) 지향 애플리케이션과 금융 트랜잭션 등이 해당된다 하지만 대출 같은 경우 약결합(메시지 지향 애플리케이션)에 맞는다. 각각의 접근방식은 장점을 갖고 있다. Bloor North America의 시각에서 보면 일단 웹 서비스 아키텍쳐가 성숙하고 복잡한 트랜잭션을 안전한 방식으로 처리할 수 있다면 이 아키텍쳐는 바로 Electronic Data Interchange and Common Object Request Broker 같은 전통적인 분산 컴퓨팅 아키텍쳐와 경합할 것이고 애플리케이션 구현 및 전개 접근방식을 주도할 것이다.

위로

웹 서비스의 개선점

웹 서비스는 근본적으로 약결합 애플리케이션들이 함께 작동하도록 하면서 실행되는 메시징 아키텍쳐이다. 하지만 단순히 XML 데이터를 포함하고 있는 메시지들을 분산된 시스템/OS/프로그램 언어(크로스 플랫폼)를 통해 전달하게하는 것으로 웹 서비스를 엔터프라이즈급의 분산 시스템 아키텍쳐라고 규정할 수는 없다. 웹 서비스가 엔터프라이즈 레벨에서 성공하기 위해서는 특정 단점 및 한계들도 다뤄져야한다. Bloor NA는 이 같은 단점들을 일곱 가지로 분석했다. 이 같은 분석은 컨소시엄, 벤더, 오픈 소스 커뮤니티 등의 다양한 표준화 노력 과정에서도 언급된 것이다. (그림 3)

출처: Bloor Research NA North America, 2002년 7월

개선을 위해 무엇이 필요한가?

간단히 말해 웹 서비스 아키텍쳐는 엔터프라이즈 레벨로 준비되기 위해서는 다음과 같은 부분에서 성장해야 한다.

• 보안/프라이버시 -- 웹 서비스 아키텍쳐의 보안을 두 가지 레벨로 구분했다:
  1. 네트워크 레벨 보안
  2. 콘텐트 레벨 보안

  네트워크 레벨에서, 이미 많은 엔터프라이즈에서 구현하고 있는 Secure Sockets Layer (SSL) 보안과 함께 "라인" 레벨에 있는 보안 방어 레이어를 볼 수 있다.

  콘텐트 보안 측면에서 W3C는 XML 콘텐트 보안에 중점을 두었다. 표준 권고안은 다음과 같다:

  • 개인적인 데이터와 문서를 기밀로서 보호한다.
  • 데이터/콘텐트가 발생하는 곳의 출처를 확인하고 기원에 대한 타당성 검사를 수행한다.
  • 권한이 있는 사용자에게만 특정 유형의 콘텐트를 제공한다.
  • 통신 엔터티들간 보내지는 데이터 및 콘텐트 무결성을 확인한다.
  • 부인 방지(non-repudiation).

  Bloor NA의 견지에서 보면 콘텐트 레벨에서 웹 서비스를 보안하려면 다양한 벤더나 오픈 소스 제품에 구현된 또는 엔터프라이즈 환경에서 적절하게 전개된- 위에 언급된 표준 권고안을 검토해야한다.

• 메시징/라우팅, 신뢰성/서비스 품질, 트랜잭션 프로세싱 -- 웹 서비스 애플리케이션은 다양한 서비스들을 요청, 제공, 수신하기 위해 많은 메시지를 이리저리 보내야한다. 따라서 효율적인 메시징/라우팅은 매우 중요하다. 트랜잭션 프로세싱과 메시지 감시에 신뢰성을 확보하기 위해서는 롤백 및 메시지 작성/메시지 트래킹에 많은 향상이 있어야한다.

• 관리능력 -- 분산 컴퓨팅 환경을 효율적이고 안전하게 운영하려면 시스템 관리자들은 시스템과 네트워크의 건강상태와 애플리케이션의 상태와 작동 패턴을 파악할 수 있는 프로그램, 툴, 유틸리티가 필요하다. 비록 프로그램/툴/유틸리티들은 전통적인 분산 컴퓨팅 환경에서 수 년 동안 존재했지만 약결합 애플리케이션이라는 좀더 복잡한 것에 합당한 프로그램/툴/유틸리티는 아직 없다.

• 퍼포먼스/튜닝 -- 트랜잭션 프로세싱과 네트워크/시스템/애플리케이션 관리와 마찬가지로 W3C는 분산 웹 서비스 애플리케이션과 서버용 튜닝 툴과 유틸리티 스팩을 만드는 것 보다는 프로토콜과 기반구조에 지속적으로 집중할 것이다.

  W3C Quality Assurance는 무엇보다도 다양한 웹 서비스와 XML 표준들이 조화롭게 작용하는 것에 중점을 두고 있다. 그 과정에서 Quality Assurance 실무 그룹들은 테스트 슈트와 툴들을 개발하여 함께 작동할 때 표준의 부하와 확장성 문제를 검사하고 있다. 이들 결과 중 일부는 공표되었다.

  문제점: 퍼포먼스/튜닝 툴과 유틸리티에 대한 공식 규약이 부족하다.

• 상호운용성 -- 크로스 플랫폼, p2p 통신용 아키텍쳐로서 완벽한 잠재성을 웹 서비스가 실현하려면 다양한 벤더들의 플랫폼과 웹 서비스 구현들 간 상호운용성이 보장되어야 한다. 그리고 상호운용성을 실현하는 일은 단기적인 문제가 아니다. 새로운 W3C 스팩과 권고안이 나오는 만큼 새로운 벤더들이 시장에 진입하면서 점점 더 많은 상호운용성 테스팅이 벤더와 제품들 간에 광범위하게 이루어져야 한다.

  Bloor NA의 전망대로라면 웹 서비스 상호운용성 테스팅은 수 백개의 제품들을 혼합해야 하기 때문에 장기간의 많은 노력이 필요하다. 따라서 기업이 지금 갖고 있는 제품은 물론 앞으로 구입하게 될 제품까지 노출시켜 웹 서비스 아키텍쳐를 사용하여 함께 작동할 수 있도록 해야한다.

위로

처방

이전 섹션에서 다룬 웹 서비스 문제점들에 대한 처방법에 대해 알아보자:

보안

엔터프라이즈 급의 보안을 설정하는 것은 강력한 보안 아키텍쳐와 최상의 보안 관례에 달려있다. W3C는 이러한 요소들이 안전한 컴퓨터 환경을 구현하는데 중요하다는 것을 깨달았다:

• 아키텍쳐(Architecture) -- 웹 서비스 아키텍쳐의 보안 프레임웍은 여섯 개의 요소들에 집중한다: 접근성, 인증, 권한, 기밀성, 무결성, 부인 방지.
• 제품(Products) -- 진화하는 벤더 솔루션을 관찰해 보면 벤더들이 일반적으로 웹 서비스 아키텍쳐 보안에 다음과 같은 접근방식을 취하고 있음을 나타낸다:
• 벤더들은 표준 권고안을 구현한다.
• 확장을 추가한다.

확장에는 보안, 비지니스 프로세스 관리, 애플리케이션 개발 환경, 포탈 서비스 등을 갖춘 메일/메시징 서버 장치들이 포함되어 있다. 예를들어 IBM Tivoli 제품들은 웹 서비스와 함께 작동하며 웹 서비스 아키텍쳐를 보강하고 중요한 임무를 수행하는 컴퓨터 환경에 맞춘 보안 및 관리능력 기능을 추가했다. McAfee와 Forum Systems 같은 벤더들은 인증, 권한, 부인 방지에 대한 웹 서비스 표준들에 메시지 핸들링 하드웨어 및 소프트웨어를 결합했다.

마지막으로 IBM, Microsoft, VeriSign은 웹 서비스 보안 문제 해결을 단축할 수단으로 WS-Security를 제안했다. 이 표준은 현재 OASIS (Organization for the Advancement of Structured Information Standards)가 검토중이다.

메시징/라우팅
W3C 내에 라우팅/메시징과 관련한 두 개의 연구가 진행되고 있다:

1. SOAP기반 envelope이 HTTP외 다른 프로토콜을 통해 실행될 수 있도록 하는 작업.
2. SOAP으로 one-way 메시징, two-way 메시징 (요청/응답 메시징), p2p 통신이 가능하도록 하는 작업.

IS 바이어들의 관점에서 보면, IS 실무자들은 메시지 핸들링을 줄일 방법을 모색해야한다. 웹 서비스는 본질적으로 메시지 중심이기 때문에 메시지 트래픽은 메인 애플리케이션 서버를 위험에 빠트릴 가능성이 있기 때문이다. IBM, HP, Sun, 기타 디자인 시스템 기업들은 웹 서비스 애플리케이션이 메인 애플리케이션 서버들을 안전하게 유지하도록 보장하는 것으로 메시지 프로세싱의 부하를 줄일 수 있다.

트랜잭션 프로세싱
웹 서비스 기반의 트랜잭션 핸들링은 매우 기초적인 일이다. 웹 서비스 아키텍쳐는 트랜잭션(모든 메시지)을 핸들할 수 있어야 한다. 하지만 웹 서비스는 트랜잭션 롤백이나 2 단계 커밋(two-phase commit) 핸들을 요하는 기술은 부족하다.

Bloor NA는 웹 서비스 트랜잭션 핸들링을 해결할 두 개의 방법을 찾았다:

1. 컨소시엄 활동 (OASIS, Open OBI, Rosettanet 등)
2. 벤더 활동(IBM과 다양한 트랜잭션 핸들링 제품, Sun, HP, BEA 같은 기업들의 트랜잭션 감시)

관리능력
약결합 환경에서 분산 애플리케이션을 어떻게 관리할 수 있는가? W3C 웹 사이트에서 관리 소프트웨어 또는 솔루션에 대한 연구는 표준 기관에서 관리능력 연구가 진행중이다 라는 소극적인 결과만 낳고있다. W3C 사이트에서 "핵심" 관리능력 요소만을 발견했다.

하지만 벤더 사이트를 조사했을때 다양한 웹 서비스 관리능력 답변들을 얻을 수 있었다. 벤더들은 애플리케이션 관리 소프트웨어 제품을 제공한다. 이는 분산 애플리케이션 관리에 알맞다. 많은 보안 관련 벤더들을 "Web services Gotchas" 보고서에 제시했다.

퍼포먼스/튜닝
웹 서비스 기반 애플리케이션의 전체 퍼포먼스에 영향을 끼치는 네 가지 요소들이 있다:

• 애플리케이션 디자인 -- 호출되어야 하는 협업 프로그램의 수, 웹 서비스 애플리케이션들의 통합력 수준, 애플리케이션 작성 능력 등이 최적의 퍼포먼스를 이룩하는데 중요한 역할을 한다.
• 오버헤드 -- 웹 서비스 애플리케이션은 메시지 전달을 중심으로 한다. 수 천개의 메시지들을 프로세스 해야하는 워크로드가 증가하면 기존 서버 아키텍쳐가 위험에 빠지게된다. 게다가 웹 서비스 아키텍쳐는 보안, 신뢰성, 기타 소프트웨어 패키지들로 더욱 향상되어야 하기 때문에 이로인한 추가 오버헤드가 발생한다. 따라서 웹 서비스를 안전하게 유지하고 증가하는 메시지 프로세싱 부하에도 안전할 수 있는 퍼포먼스 튜닝이 고려되어야 한다.
• 네트워크 특성 -- 웹 서비스를 얻기위해 만들어져야 할 홉(hop)의 수, 네트워크 속도/대역폭 특성 등 다양한 네트워크 사항들은 웹 서비스 애플리케이션의 전체 퍼포먼스에 중요한 역할을 한다.
• 시스템/스토리지 특성 -- 웹 서비스 애플리케이션을 보다 빠르게 처리하기 위해서는 시스템과 스토리지 서브시스템의 튜닝이 필요하다. 기본 목표는 시스템 "레이턴시"이다.

웹 서비스 퍼포먼스를 최적화 하기 위해서는 위에 열거한 모든 것이 검토되어야 하고 최적의 퍼포먼스에 맞춰 조절되어야 한다. 일부 벤더들은 퍼포먼스/튜닝 유틸리티 및 제품을 제공하고 있다.

상호운용성
크로스 벤더, 크로스 플랫폼 상호운용성을 모색하던 이전 아키텍쳐의 가장 큰 실패 중 하나는 그 많은 벤더들이 서로 호환되지 않은 방식으로 표준을 해석하고 구현했다는 점이다. 게다가 어떤 벤더들은 표준을 부분적으로 구현했다. 제 3의 조직들은 품질이 보증된 벤더 표준을 제공했지만 이 과정은 시간과 비용이 많이 들었다.

이 상황을 해결하기 위해 다양한 벤더들은 WS-I (Web Services Interoperability Organization)을 만들었다. 이는 벤더 구현들 간 상호운용성 테스팅 및 문제해결을 목적으로 한다.

상호운용성과 관련하여 고려해야 할 또 다른 문제는 다양한 벤더들이 레거시 애플리케이션, 커스텀 애플리케이션, 패키지 애플리케이션간 "어댑터" 또는 "커넥터"를 만들기 위해 사용했던 접근법이다. 이러한 어댑터들은 웹 서비스 WSDL 템플릿을 사용하여 변환되고 있다.

상호운용성 문제들은 WSDL 같은 웹 서비스 템플릿을 사용하는 새로운 소프트웨어 어댑터 개발과 벤더들의 상호운용성 테스트를 통해 해결 될 수 있다.

신뢰성/서비스 품질
웹 서비스 신뢰성은 다음의 두 가지 요소를 통해 문제들을 해결하고 있다:

1. 표준/컨소시엄 활동
2. 벤더

신뢰성과 서비스 품질과 관련된 W3C의 노력으로는 W3C "activity" for Electronic Commerce이 있다. 이 그룹은 처음에는 얼마만큼의 신뢰성을 성취할 수 있는가를 시험하는 일을 수행하였다. 이 그룹은 전자상거래 표준을 시도하고 설정하는 것이 얼마나 어려운 일인가를 깨닫게 되었다. 전자상거래에 대한 요구사항들은 산업마다 다르다. 따라서 전자상거래 연구 그룹은 신뢰성있는 트랜잭션을 달성하는 기반 기술을 정의하는데 초점을 옮겼다. 신뢰성 표준은 다른 표준 설정 이니셔티브의 후원을 받고 있다. XML Signature, XML Encryption, XML Protocol, Semantic Web, Privacy, Micropayment initiative 등이 그것이다.

필자소개

		Joe Clabby는 Bloor Research - North America의 회장이다

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로