QoS(Quality of Service)를 우리말로 직접 번역하면 ‘서비스의 질’이 된다. 이를 다시 말하면, 제공할 서비스를 여러 가지 방법으로 평가할 때 평가가 될 수 있는 질적인 요소라는 뜻이다. 그러므로 넓은 의미의 QoS에는 소프트웨어 개발에 있어 가장 흔히 언급하는 트랜잭션이나 보안과 같은 이슈도 포함된다. 그렇지만 일반적으로 QoS를 이야기할 때는 트랜잭션이나 보안을 제외한 나머지 이슈를 대상으로 한다. 트랜잭션이나 보안은 그 자체만으로 너무나 큰 이슈이기 때문이다.
QoS란 무엇인가
e-비즈니스가 발전할수록 QoS에서 정의하고 만족시켜야 하는 목표도 점점 더 발전해 나간다. QoS에 대한 정의는 어찌 보면 이러한 개념 확대와 맞물려 있는 경우가 많다. 웹으로 많은 것을 처리하는 현 단계에서 QoS를 이야기한다면 ‘회사의 웹 환경을 사용자가 얼마나 만족하는가’와 같이 사용자가 느끼는 만족도의 정도로 QoS를 광범위하게 정의할 수 있을 것이다.
이와는 반대로 리얼타임 분야에서 특정 기계의 QoS를 이야기한다면(멀티미디어 환경이나 하드웨어에 들어가는 임베디드 시스템의 경우에는 이런 부분이 더 중요하다), QoS는 소프트웨어 수행이 정확한 시간에, 시간 지체 없이, 정해진 형태로 이루어지는 정도로 정의할 수 있을 것이다.
어쨌든 최근에 가장 흔히 이용되는 웹 환경을 기준으로 QoS에 대해 접근하는 것을 이번 달 컬럼의 목표로 잡아보자. 이 경우 QoS라는 것은 근본적으로 서비스를 제공하는 제공자와 서비스를 이용하는 사용자 사이의 계약을 근거로 생각해야 한다.
일단 QoS의 목표가 정해지면, 이러한 목표를 만족시키기 위해 응답 시간이 빨라야 하고, 탐색은 쉬워야 하며, 언제나 접근이 가능해야 하는 것과 같은 여러 요소가 복합적으로 작용해 서비스의 질이 결정될 것이다. 일반적으로 QoS는 시스템의 가용성(availability)과 수행 성능(performance), 사용자 애플리케이션을 지원하는 네트워크 등을 이용해 측정할 수 있다.
IT 시스템에서의 높은 ‘질(quality)’이란 IT 리소스(필자는 IT 시스템을 위한 하드웨어, 소프트웨어 등을 포괄적으로 지칭하는 의미에서 IT 리소스라는 단어를 사용했다)가 일반적으로 사용 가능해야 하며 SLO(Service Level Objectives)에 명시한 반응 시간이 시스템을 구축한 사람과 고객들이 서로 동의할 수 있는 수준이 되어야 한다는 것이다. 디지털 경제를 추구하는 회사의 경우에는 서비스를 전달하는 인프라 구조가 최소한 SLA(Service Level Agreements)에 지정된 수준의 가용성과 수행성능을 보장해야 한다.
웹서비스 아키텍처와 QoS
웹서비스 아키텍처는 메시지 교환을 통해 여러 애플리케이션을 통합하는 방법을 제공한다. 엔터프라이즈 환경에서 여러 애플리케이션을 통합한다는 것은 구매와 관련한 주문이나 계약, 견적 요청과 같은 중요한 비즈니스 정보를 교환할 수 있다는 것을 의미한다. 이러한 주문, 계약, 견적 요청 등의 정보는 전송되는 기반 메시징 아키텍처에 신뢰성(reliability)이 요구되는 것은 매우 당연하다. 따라서 이러한 정보는 트랜잭션 처리가 가능해야 하며 보안도 무척 중요하다. 그 밖에도 가용성, 접근성, 수행성능과 같은 여러 이슈가 있을 것이다.
QoS의 구성 요소
QoS의 정의를 SLA와 SLO의 정신에 부합하도록 하는 것이 올바르지만, 실제로 컴퓨터 프로그래밍에서 QoS를 이야기할 때는 이러한 QoS에 도달하기 위한 여러 구성 요소를 중요시하게 된다. QoS의 구성 요소에는 여러 가지가 있지만 가장 흔히 언급되는 것으로는 가용성, 접근성, 수행 성능과 신뢰성 같은 것이 있다.
가용성
가용성은 서비스가 현재 존재하고 즉시 사용할 수 있는지에 대한 질적인 면을 의미한다. 즉, 서비스를 사용할 수 있다는 가능성을 나타내는 것이므로 이 값이 클수록 당장 서비스를 이용할 수 있고, 값이 작을수록 특정 시간에 사용하지 못할 가능성이 커진다. 가용성과 관련한 지표로 TTR(Time-To-Repair)과 같은 것이 흔히 이용되는데, TTR은 서비스를 사용할 수 없을 때, 서비스를 사용 가능하도록 복구하는 데 걸리는 시간을 말한다. 물론 이 값은 작을수록 좋다.
수행 성능
수행 성능은 수행 시간 등으로 측정할 수 있는 질적인 면으로 측정 기준으로는 처리량(throughput)과 대기 시간(latency)이 있다. 처리량은 지정된 시간 동안 처리할 수 있는 서비스 요청 수를, 대기 시간은 요청을 전송하고 요청에 대한 응답을 받을 때까지 걸리는 시간을 의미한다. 수행 성능의 지표인 처리량과 대기 시간의 경우, 프로그래밍을 할 때나 함수의 성능을 측정할 때도 흔히 사용된다. 보통 QoS를 말할 때 수행 성능과 관련해서는 처리량과 대기 시간이 가장 중요하다.
신뢰성
신뢰성은 서비스의 질을 유지할 수 있는 정도를 나타내는 질적인 면이다. 매달 또는 매년 발생하는 모든 종류의 서비스 실패(failure) 횟수가 웹서비스의 신뢰성을 측정하는 가장 좋은 잣대가 될 수 있다. 때로는 전송자와 수신자 사이에 메시지를 전송할 때 송수신되는 데이터를 확실하게 보장하는 것을 의미하기도 한다.
웹서비스에서 QoS를 지원하려면
웹서비스에 있어서 QoS는 아직 극복하지 못한 정복 대상 중 하나라고 할 수 있다. WSDL을 이용해 인터페이스를 정의할 때는 주로 서비스에 대한 문법적인 정의를 다루지만 기능적이지 않은 의미론(semantics)에 대해서는 아무 것도 지정하지 않는다. 그러므로 QoS를 지원하는 웹서비스를 위해서는 다음과 같은 항목을 만족시킬 정도의 새로운 QoS 언어가 필요하다.
◆ 원하는 대기시간
◆ 허용하는 최대 라운드트립(round-trip) 시간
프로그래머가 웹서비스 클라이언트를 개발할 때는 웹서비스의 QoS에 대한 특징을 알아야 한다. 이 경우에 가장 이상적인 것은 QoS를 처리할 수 있는 웹서비스 플랫폼이 서로 다른 QoS 요구와 다양한 컴퓨팅 리소스, 통신 종류 등을 모두 감안해 QoS를 지원하는 것이다. 이를 위해 서비스를 요구하는 쪽에서는 클라이언트가 요구하는 QoS를 기술해서 이를 서비스 제공자에 전달해야 하고, 서비스 제공자 쪽에서는 서버 객체가 제공하는 서비스의 QoS를 기술해야 할 것이다.
아직 표준화가 되어 있지는 않지만 이와 같이 서비스 제공자와 요구자가 모두 서로의 QoS 수준을 기술하게 되면, 그 다음에는 다음과 같은 단계를 거쳐 서비스 제공자와 요구자가 서로 바인딩하게 할 수 있을 것이다. 실제로 웹서비스 표준화와 관련하여 QoS와 관련된 논의는 여기에 기술하는 방식으로 진행되고 있다.
- 서비스 요구자는 웹서비스 인터페이스에 대한 참조를 지정함으로써 바인딩을 요청한다. 이 때 요청에는 필요로 하는 QoS 정보가 포함된다.
- QoS 중개자가 서비스 제공자를 UDDI에서 검색하고 QoS 협상(negotiation)을 시작한다.
- 웹서비스 QoS 중개자는 클라이언트가 요구하는 QoS와 서비스 제공자가 제공하는 QoS를 비교하고, 내부적인 정보를 이용해 동의된(agreed) QoS를 결정한다. 이러한 과정을 ‘QoS 협상’이라고 한다.
- QoS 협상이 성공적으로 끝나면 서비스 요구자와 서비스 제공자가 바인딩하게 되며 이 때부터 실제로 서비스를 실행할 수 있게 된다.
현재 상황에서는 웹서비스의 메시징 시스템과 전송 프로토콜의 한계 때문에 웹서비스에서 병목현상이 나타날 수 있다. 프로토콜은 잘 알다시피 HTTP와 SOAP인데 이 프로토콜을 변경하기는 현실적으로 어렵지만 한계에 대해서는 명확히 알아두는 것이 앞으로 이러한 문제를 대처할 때 크게 도움이 될 것이다.
HTTP
대역폭에 여유가 없는 경우에는 패킷을 그냥 버리게 된다. 전통적으로 많은 애플리케이션이 기본적으로 대역폭은 무한대고 대기 시간은 없는 것으로 간주하고 작성된다. 그리고 보통 동기화 메시징(synchronous messaging)을 이용하는데, 사실 동기화 메시징 자체는 문제될 것이 없지만 웹서비스처럼 인터넷을 통해 통신할 경우에 대기 시간이 오래 걸릴 때가 종종 있기 때문에 별로 바람직한 선택이라고 보기는 어렵다.
그렇지만 최근에 등장한 HTTPR(Reliable HTTP)이나 BEEP(Blocks Extensible Exchange Protocol), DIME(Direct Internet Message Encapsulation)과 같이 HTTP의 문제를 해결하려는 새로운 프로토콜이 광범위하게 채택되는 데는 다소 시간이 걸릴 것이다. 그러므로 애플리케이션을 디자인하는 사람은 이러한 대기 시간 등의 제한 요소와 가용성 등을 감안하고 디자인해야 한다.
원격 웹서비스에 의존하는 애플리케이션은 메시지 큐를 이용해 신뢰성을 높일 수 있다. 물론 이렇게 하면 반응 시간이 다소 길어지는 단점은 감수해야 한다. 그러므로 엔터프라이즈 환경에서 이용하는 애플리케이션이나 웹서비스는 JMS (Java Messaging Service)나 웹서비스 호출을 위한 IBM의 MQ 시리즈 등을 이용하는 것이 효과적일 수 있다. 앞으로는 CORBA의 이벤트 서비스나 통지 서비스와 같이 발행/구독 모델을 지원하는 여러 유틸리티 패키지가 웹서비스 호출에서 중요한 기능을 할 것으로 예상한다.
SOAP
SOAP은 현재 웹서비스에 대한 실제 표준 프로토콜이라고 할 수 있다. 그렇지만 수행성능이라는 면에서는 그다지 뛰어난 선택이라고 보기는 어려운데 그 이유는 다음과 같다.
◆ SOAP 엔빌로프를 SOAP 패킷에서 추출하는 데 시간이 많이 걸린다.
◆ SOAP 엔빌로프에 들어있는 XML 정보를 파싱하는 작업도 시간이 많이 걸린다.
◆ XML 데이터의 경우 최적화할 여지가 별로 없다.
◆ SOAP 인코딩 규칙은 모든 SOAP 메시지에 대한 데이터 타입 정보를 포함하도록 하고 있다.
◆ 바이너리 데이터를 XML에서 받아들일 수 있는 형태로 인코딩하는 것이 인코딩/디코딩하는 데 처리 시간을 더 들게 하고 데이터의 양도 증가시킨다.
이러한 이유로 SOAP은 수행성능이라는 면에서 그다지 좋은 평가를 받고 있지 못하고 있다. 현존하는 대부분의 XML 파서는 코드 크기나 처리 속도, 차지하는 메모리 양이라는 면에서 많은 문제를 안고 있는 것이 사실이다.
그러므로 일부 애플리케이션에서는 정형화된 XML 파서에서 여러 기능을 제거한 ‘가벼운 파서’를 구현하는 것이 훨씬 더 훌륭한 선택이 될 수 있다. 현재 대부분의 SOAP 구현이 DOM(Document Object Model)에 기반을 두고 있는데, 알려진 바와 같이 DOM 파서는 기본적으로 SAX 기반의 파서에 비해 처리 속도가 느리다. 그러므로 SAX 기반으로 SOAP을 구현하는 것이 처리 속도를 증가시키고, 메모리 요구사항도 줄일 수 있으며, 확장성이라는 면에서도 훨씬 유리하다.
SOAP은 XML을 이용하기 때문에 만약 SOAP 메시지를 압축할 수 있다면 네트워크 대역폭을 차지하는 문제점을 상당히 개선할 수 있을 것이다. 일반적으로 XML 데이터가 바이너리 데이터에 비해 평균적으로 400% 정도 크다는 보고가 있다. 이렇게 메시지의 크기가 증가하면 데이터 전송 시간이 길어지므로 수행성능에 악영향을 미치는 것은 당연하다. 이런 문제를 해결하기 위해 XML을 압축하는 여러 방안이 제시되고 있다. 물론 압축을 이용하면 CPU에 오버헤드가 더 많이 가해지는 것은 피할 수 없을 것이다.
그 밖의 요인
이 밖에도 웹서비스의 수행성능에 영향을 미치는 요인으로 다음과 같은 것들이 제시되고 있다.
◆ 웹 서버의 반응 시간과 가용성
◆ WAS에서의 EJB나 서블릿과 같은 애플리케이션의 수행 시간
◆ 백엔드 데이터베이스나 레거시 시스템의 수행성능
QoS 문제의 해결 방안
QoS 문제를 해결하기 위해서는 앞서 설명한 QoS에 영향을 미치는 여러 구성 요소에 대한 분석과 이를 해결하기 위한 여러 가지 시도를 하고, 이러한 시도가 실제로 구성 요소에 어떠한 영향을 미쳤는지를 면밀하게 모니터하는 작업 등이 필요할 것이다. 간단하게 웹서비스의 경우에 가용성과 신뢰성 부분을 어떻게 높일 수 있는 지에 대해서 생각해 보자.
가용성을 높여라
가용성을 높이기 위해서는 일반적으로 캐싱이나 로드 밸런싱 등의 기술을 이용한다. 캐싱이나 로드 밸런싱은 웹 서버 수준에서 제공할 수도 있고 웹 애플리케이션 서버 수준에서 제공할 수도 있을 것이다. 로드 밸런싱은 다양한 종류의 트래픽에 대한 권한 설정을 통해 각각의 요청이 적절한 비즈니스 우선순위에 따라 수행될 수 있도록 하면 더 좋을 것이다.
웹서비스 제공자는 요청 트래픽과 현재의 사용 현황, 그 결과로 요구되는 QoS 등을 감안해 시스템을 다시 모델링할 수 있다. 그리고 웹서비스 트래픽을 트래픽의 양과 서로 다른 애플리케이션 서비스 카테고리에 대한 트래픽, 서로 다른 소스에서 나온 트래픽 등으로 분류할 수도 있다. 이렇게 하면, 서비스 요구에 대한 QoS를 적절하게 맞춰갈 수도 있고, 웹 서버나 웹 애플리케이션 서버의 로드 밸런싱을 어떻게 가져갈 것인지에 대해서도 윤곽을 잡을 수 있다.
서비스 제공자는 서비스 유형과 고객에 따라 서로 다른 시스템 모델을 가져가야 할 것이다. 예를 들어, 멀티미디어 웹서비스의 경우에는 빠른 수행 성능을 최우선으로 고려해야 할 것이며, 그에 비해 인터넷 뱅킹 웹서비스는 보안과 트랜잭션 관리가 우선적으로 고려될 것이다.
신뢰성 제고
웹서비스의 경우 근본적으로 HTTP가 신뢰성에 문제가 많기 때문에 신뢰성을 높이기 위해서는 신뢰성 있는 메시징(reliable messaging)이 중요하다. 신뢰성 있는 메시징이란 메시지 전송자와 수신자 모두가 메시지를 실제로 전송하고 수신했는지를 아는 것을 말한다. 더 나아가서는 의도한 수신자에게 메시지를 단 한 번만 전송해야 하는 것을 말한다.
이러한 신뢰성 있는 메시징은 인터넷이라는 곳에서는 그다지 커다란 영향력을 발휘하지 못해 왔는데, 이는 인터넷이 신뢰성에 바탕을 두지 않고 설계됐기 때문이다. 웹 서버는 항상 동작할 수도 동작하지 않고 있을 수도 있으며, 프로토콜은 신뢰성 있는 메시징을 구성하는 메시지 식별자나 승인(acknow ledgement)과 같은 것을 전혀 염두에 두지 않고 설계됐다.
메시지 전송의 신뢰성을 확보하기 위해서는 수신 쪽에서는 수신한 메시지에 대해 승인 절차를 꼭 밟아야 하며, 송신 쪽에서는 전송한 메시지를 승인 메시지가 도착할 때까지 캐싱했다가 승인이 되지 않으면 재전송해야 한다. 기본적으로 현재 인터넷 시스템은 이러한 기술적인 기반에 근거하지 않고 있다. 그러므로 개발자들은 이러한 요구를 만족시키기 위한 새로운 프로토콜을 구현하고 새로운 기술을 만들어 낼 수밖에 없다.
신뢰성 있는 메시징이라는 것은 전혀 새로운 문제가 아니며 이미 많은 개발자들이 이 문제를 해결하기 위해 노력하고 있다. 그 결과 여러 기술이 이 문제를 구현하고 있는데 문제는 이들 사이에 상호운용성이나 표준화가 미흡하다는 것이다. 앞서도 간단히 언급한 바 있지만 현재 HTTPR, BEEP, DIME 등이 가장 유력한 후보로 거론되고 있다.
그 중에서도 IBM의 HTTPR이 새로운 신뢰성 있는 메시징 애플리케이션을 정의하지 않으면서도 HTTP에 기반을 둔 애플리케이션 중립적인 신뢰성 있는 메시징 프로토콜이기 때문에 가장 주목받고 있다.
메시징 에이전트가 HTTPR 프로토콜을 이용해 메시지를 저장소에 저장하고, 이를 이용해 애플리케이션이 신뢰성 있는 메시징을 할 수 있도록 보장한다. 사실 HTTPR의 경우 규격에 메시징 에이전트를 디자인하는 부분이나 저장과 관련해서 정해진 메커니즘은 없다. 그렇지만 안전하게 저장해야 할 상태 정보나 이들을 언제 저장해야 하는지에 대해서는 규정하고 있다.
서비스의 생명은 고객 만족
지금까지 QoS에 대해 몇 가지 화두를 이야기해 보았다. 아마도 아직도 QoS에 대한 막연한 개념이 머릿속을 떠돌고 있을지도 모르겠다. 그러한 독자들을 위해 한 마디만 하자면 ‘서비스의 생명은 고객 만족’이라는 말을 하고 싶다. 다시 말해, 개발자들이 만드는 여러 종류의 프로그램을 포함해서 웹 사이트 등의 역할은 광의로 해석하자면 이를 사용하는 고객들을 만족시키기 위한 것이 최종 목표다.
이런 측면에서 우리가 제공한 것은 서비스가 되는 것이며, 이러한 서비스의 질을 좌우하는 몇 가지 구성 요소를 진작시키는 것은 어찌 보면 우리에게 주어진 사명과도 같은 것이다.
웹서비스의 경우에도 QoS는 웹서비스 세상을 풍요롭게 하고 실제로 많은 사이트에 적용해서 꽃이 피고 열매가 열릴 수 있도록 도와주는 비료 역할을 하게 될 것이다. 앞서 설명한 가용성, 접근성, 수행성능과 신뢰성 등 여러 가지 QoS 구성 요소를 만족시키기 위한 표준 규격과 기술적인 시도가 앞으로도 지속적으로 진행될 것이다. @
