HTML5 웹소켓이 필요한 5가지 경우

HTML5 웹소켓이 필요한 5가지 경우

Posted : 2012-03-29

원문출처 : http://kaazingcorp.cachefly.net/com/file/Kaazing-WP-5_Signs_You_Need_HTML5_WebSockets_Oct_2010.pdf

번역 : 미래웹기술연구소

 

 

 

카징 백서

 

HTML5 웹 소켓은 흥미로운 실시간 상호작용 웹앱을 신속하고 견고히 만드는 데에 도움을 주는 새로운 중요 기술이다. 물론, HTML5 웹 소켓은 상당히 훌륭한 기술이기는 하다. 하지만, 이 새로운 기술이 여러분에게 적합한 것인가?

 

이 문서에서는 HTML5 웹 소켓을 사용하는 5가지 유형의 웹앱에 대해 알아보기로 하겠다. 시나리오에서, 카징의 웹소켓 게이트웨이가 어느 시점에서 도움이 되는지도 보여주도록 하겠다.

 

5가지 경우 

1. 애플리케이션에서 데이터가 양 방향으로 전송되어야 한다.

2. 수 많은 병행 사용자에 따라 애플리케이션의 확장성이 보장되어야 한다.

3. 애프리케이션이 TCP 기반 프로토콜을 브라우저에 까지 확장해야 한다.

4. 애플리케이션 개발자가 쉽게 사용할 수 있는 API가 필요하다.

5. 애플리케이션이 인터넷이나 클라우드에서 SOA를 확장해야 한다.

 

1. 애플리케이션에서 데이터가 양 방향으로 전송되어야 한다

 

인터넷이라는 개념이 처음 생겼을 당시, 문서 검색(retrieval)에 초점을 맞추었었다. 사용자는 URL을 요청하고 서버는 객체(예를 들어, 웹 페이지 또는 이미지 파일)를 전달했다.

 

하지만, 지금의 인터넷은 우리를 찾아 온다. 서버는 사용자에게 전하고 싶은 것이 있으면, 알려준다 (예를 들어, 주식 현황 또는 친구로부터 온 문자). 안타깝게도, 인터넷의 아키텍쳐 때문에, 여전히 클라이언트는 반이중방식 (요청/응답) HTTP를 사용하여 통신을 시작해야만 한다. 맞춤법 검사나 검색어 자동 완성과 같은 작업을 위해, 비교적 정적인(static) 애플리케이션도 클라이언트와 서버간의 비동기적인 통신 방법이 필요하다.

그림 1 : HTTP의 반이중 방식 특성으로 클라이언트가 백엔드(back-end) 서버스에 직접 접속하지 못한다. 애플리케이션 서버가 능동적으로 브라우저와 백엔드 간의 모든 메시지를 변환(translation), 해석(interpretation)하며 새로운 포맷(reformatting)한다.

 

반이중 방식 HTTP 상에서 전이중 방식 통신을 가능케 하려는 노력으로, 개발자들이 두 연결(connections)을 사용하는 다양한 방법과 기술을 고안해 왔다: 한 연결은 다운스트림을 위한 것이고 다른 하나는 업스트림을 위한 것이다. 이 중 많은 기술들이, 서버가 푸시(push)를 할 수 있도록, 폴링(polling)이나 롱폴링(long-pollilng)을 사용한다. 그러나 두 연결을 유지 보수하고 조율하는 일에는 상당한 자원 소비 오버헤드(overhead)와 복잡성이 발생한다. 간단히 말해, HTTP는 애초에 실시간, 전이중 방식 통신을 위해 설계된 것이 아니었다.

 

하지만, HTML5 웹 소켓이 인터넷을 위한 전이중 방식 통신 모델을 제공한다. 그리고 이로 인해, 예전의 방법론들이 초래하는 오버헤드 발생 없이 전혀 새로운 애플리케이션 모델 개발이 가능해 졌다. 클라이언트와 서버 사이에서 전이중 비동기 방식 통신이 가능한 웹 앱을 개발하고 싶다면, HTML5 웹 소켓이 필요하다.

그림 2: HTML5웹 소켓은 인터넷을 위한 전이중 방식 통신 모델을 제공한다. 따라서, 브라우저가 TCP 기반 백엔드 서비스와 직접 통신 할 수 있으며, TCP 기반 프로토콜을 인터넷에 맞게 변환하는 복잡한 서버측 로직(login)이 필요없게 되었다.

 

카징 웹소켓 게이트웨이는 브라우저나 데스크톱과 같은 엔드 노드와 서버간에 낮은 지연 시간과, 전이중 방식 통신을 요구하는 웹앱의 구축을 위한 플랫폼이다. 카징   웹소켓 게이트웨이는 고유 웹 소켓 프로토콜을 지원한다. 하지만, 웹   카징 라이브러리 또한 모든 가능한 브라우저 기능들을 활용하여, 웹 소켓을 지원하지 않는 오래된 브라우저에서   웹소켓 기능을 에뮬레이션한다. 클라이언트와 중간 장치의 최신 프로토콜에 대한 지원 여부에 상관없이, 카징 웹소켓 케이트웨이는 최상의 연결을 사용한다.

 

2. 수 많은 병행 사용자에 따라 애플리케이션의 확장성이 보장되어야 한다.

 

수 많은 병행 사용자를 위한 웹앱을 개발한다면, 자원 경쟁을 피할 수 없을 것이다. 모든 사용자들이 백엔드 애플리케이션에 연결을 하려 하기 때문이다. 연결의 수립과 해체와 더불어, 일반적으로 각 연결은 크기가 큰 HTTP 요청/응답 프로토콜의 오버헤드를 수반한다.

 

HTTP 요청/응답 모델은 상당한 양의 오버헤드를 겪는다. 서버로부터 크기가 큰 문서를 검색할(retrieving) 경우, 몇 백 바이트의 HTTP 헤더 오버헤드는 큰 문제가 되지 않는다. 그러나, 클라이언트에게 보내진 각 메시지가 몇 바이트에 불과하다면, 어떤 일이 발생할지 생각해 보자. 예를 들어, 길이가 20문자(characters) 정도인 주가 현황 정보가 있다고 하자. 전송되는 데이터의 대부분이 불필요한 HTTP 헤더 오버헤드(단 하나의 주가 현황 정보 당 최대 2000 바이트)이다. 이로 인해 비효율적인 통신이 발생한다.

 

HTML5 웹 소켓은 클라이언트와 서버간의 새롭고 훨씬 더 효율적인 통신 방법을 구체적으로 명시하고 있다. 이 방법은 애플리케이션에 부담을 덜 주며, 기저(underlying) 네트워크 인프라가 더욱 쉽게 처리할 수 있다. 수백의 HTTP 헤더 바이트를 2 웹소켓 프레임 바이트로 대체하면, 그림 3에서 불 수 있듯이 불필요한 네트워크 처리용량(throughput)을 상당히 줄일 수 있다 (최대 1000:1). 또한, 웹 소켓은 연속적으로 폴링을 하지 않기 때문에, 지연 시간 또한 상당히 줄어 든다. 이 사실이 무엇을 의미하냐면, 단 하나의 웹소켓 서버가 수 많은 사용자를 한번에 수용하여, TCO(total cost of ownership)를 크게 줄일 수 있다는 것이다.

 

HTML5 웹 소켓은 브라우저에서 전이중 연결을 시뮬레이션하는 기존의 복잡한 기술 보다 극적으로 향상된 기술이다. HTML5 명세화의 리더인 이안 힉슨Ian Hickson은 다음과 같이 말했다.

 

“데이터의 크기를 2 바이트로 줄일 수 있다는 것…… 그리고 네트워크 지연 시간을 0.15초에서 0.05초로 줄일 수 있다는 것은 굉장한 일이다. 사실, 이 두 가지만으로도 웹 소켓은 구글에게 충분히 흥미로운 기술이 된다.”

 

그림 3: 폴링하는 카밋(Comet)과 에이잭스 솔루션(파란색) 사이에서의 HTTP 오버헤드와 관련된 불필요한 네트워크 처리용량과 웹소켓 솔루션(주황색)과의 비교가 3 가지 유스케이스에 나타나 있다: 1초 간 1,000, 10,000 그리고 100,000 병행 클라이언트. 100,000 유스 케이스에서는, 불필요한 네트워크 처리용량이 665 Mbps와 1.5 Kbps이다 (수가 적을수록 좋다는 것을 알고 있으리라 믿는다!)

 

카징 웹소켓 게이트웨이는 SEDA(Staged Event-Driven   Architecture)에 기반하고 있다. 그리고, 보다   강력한 자바 네트워킹 기능을 위한 자바NIO (New I/O)를 활용하고 있다. 예를 들어, 요청   당 단일 스레드를 할당하는 것이 아니라, 서버가 최적의 성능을 위해 스레드를 공유한다. 이로 인해, 카징 플랫폼으로 극히 낮은 메시지 지연 시간에 병행   통신의 다양한 병렬 수준을 얻을 수 있다.

 

 

3. 애프리케이션이 TCP 기반 프로토콜을 브라우저에 까지 확장해야 한다.

 

많은 웹 애플리케이션들이 백엔드 서비스에서 제공하는 정보에 엔드 유저(end user)를 연결할 필요가 있다. 이 서비스들은 전통적인(legacy) 시스템에서 제공되거나, API와 여러 프로토콜(TIBCO, EMS, JMS, RMDS, AMQP, XMPP, Stomp)을 이용하여 엔터프라이즈 메시지 버스(Enterprise Message Bus)를 통하여 전송된다.

 

어떤 애플리케이션들은 여러 하부시스템(subsystem)으로 구성되어 있으며, 각각 다른 애플리케이션 프로토콜을 사용하고 있다. 예를 들면, 어떤 하부시스템은 재고 품목의 변화하는 가격에 대기(listening)하고 반응(responding)하는 발행/구독(publish/subscribe) 프로그래밍 모델을 필요로 하는 반면, 또 다른 하부 시스템은 컬럼 기반 영속성 엔진(column-based persistence engine)으로부터 푸시된(pushed) 많은 양의 데이터베이스 이벤트를 받는다. 또한, 동시에 다른 하부시스템은 채팅(chat)과 채팅방(chat room)을 활성화 해야 한다.

 

웹 소켓을 사용하면, 애플리케이션에서 더 이상 각 하부시스템을 독립적으로 실행하는 방법(silo-ed solution)을 사용하지 않아도 된다. 브라우저에 데이터를 푸시하거나, CPU와 네트워크를 집중적으로 활용하는 폴링을 사용하여 발행/구독을 시뮬레이션할 필요가 없어 졌다. 웹소켓 트래픽이 표준 HTTP포트(80,443)상에서 지나갈 수 있게 되면서, W3C 와 IETF 표준 단체에서 HTML5 웹 소켓으로 인터넷상에서 전이중 방식 네트워크 통신을 사용할 수 있는 좋은 방법(elegant way)을 제공하였다. 이제 전이중 방식 통신을 위해 기업 방화벽에서 추가적으로 포트를 열 필요가 없게 된 것이다.

그림 4: HTML5 웹 소켓은 단일 소켓을 통하여 운용되는 전이중방식 통신 채널을 정의한다. 이로 인해, 웹 페이지와 다른 클라이언트가 인터넷 상에서 원거리 호스트와 양방향(two-way)통신을 할 수 있게 되었다. 이 그림에서는, 카징 웹소켓 게이트웨이가 매끄럽게 TCP 기반 프로토콜을 인터넷에 맞게 확장하는 것을 볼 수 있다.

 

카징 웹소켓 게이트웨이는 환경설정과 설치가 용이하다. 일단 배포되면, 게이트웨이가 다양한 주요 프로토콜들을 투명하고 효율적으로 지원한다. 예를   들면, 카징 웹소켓 게이트웨이는 XMPP/Jabber, IRC,   TIBCO JMS, Stomp, AMQP, RMDS 그리고 여타 프로토콜들을 다양한 클라이언트 기술(자바스크립트, 어도비 플레스,   MS 실버라이트, 자바/JavaFX)로 지원한다. 친숙한 클라이언트 기술로 백엔드 서비스와 통신하기   위해, 개발자들은 친숙한 API를 사용하여 고유 메서드(mothod)를 호출한다. 이러한 방법으로 클라이언트에게 백엔드   통신을 제공해야 하는 프로젝트의 연구와 개발 시간이 단축된다.

 

4. 애플리케이션 개발자가 쉽게 사용할 수 있는 API가 필요하다.

 

굉장히 흥미롭고 사용성이 높은 애플리케이션을 제공하기 위해, 개발자들은 리치(rich) 클라이언트 플랫폼(Adobe Flex (Flash), Microsoft Silverlight, Java/JavaFx, and JavaScript )에 의존한다. 그러나, 웹 상에서 이 리치 클라이언트를 실시간 데이터에 연결하는 것은 상당히 어려운 일일 수 있다. 따라서, 개발자들은 종종 클라이언트 측과 서버 측 통신 라이브러리를 만들어야만 할 때가 있다; 다시 말해, HTTP의 고유한 한계를 극복하기 위한 개발에 쓸데없이 시간을 낭비하는 것이다.

 

신뢰할 수 있는 양방향 통신 프로토콜을 만들고, 애플리케이션 서버를 백엔드 시스템에 연결하는 데에 얼마나 많은 시간과 노력이 소요되는지 생각해 보자. 이 프로토콜 위에 구축된 애플리케이션을 테스팅하고 안정성을 위해 유지관리 하는 일은 쉽지 않다. 왜냐하면, 기업에서 독점(proprietary)하고 있는 프로토콜에서 문제를 정확히 찾아내는 것은 더욱 어렵기 때문이다. 게다가, 이러한 작업은 애플리케이션에 국한 되어 있기 때문에, 프로토콜을 재사용하는 일도 쉽지가 않다.

그림 5: 카징 웹소켓 게이트웨이는 TCP 기반 프로토콜을 지원할 뿐만 아니라, 다양한 클라이언트 기술(Adobe Flex (Flash), Microsoft Silverlight and .net, JavaScript, and Java/JavaFx) 또한 지원한다.

 

HTML5 웹 소켓은 개발의 시작점이 되는 단일 표준 인터페이스를 제공한다. 이는 개발자들이 통신 프로토콜을 구축하고 테스트하는 데에 소요되는 시간을 줄이고, 최고의 클라이언트 측 경험을 디자인하는 데에 투자할 수 있는 시간이 늘어남을 의미한다. HTML5 웹 소켓으로 인해 빠르고 안전한 양방향 애플리케이션을 만들기 위해 엔지니어들이 해야하는 맞춤(custom) 개발 작업이 더 이상 필요 없게 되었다.

 

카징 웹소켓   게이트웨이는 다양한   리치 인터넷 애플리케이션(Rich Internet Application)과 클라이언트 측 프레임워크(자바스크립트 포함)와 작동하기 때문에, 개발자는 자신이 선택한 플랫폼에서 개발할 수 있다. 이 클라이언트   측 기술에는 어도비 플렉스(플래시), MS 실버라이트, 자바/JavaFX, 자바스크립트 등이 있다. 카징 웹소켓 게이트웨이는 PHP와 구글 웹 툴킷과의 통합을 지원한다. 개발팀에서 친숙한 프레임워크의 언어나 패러다임을 사용하면서도, 대중적인   클라이언트를 위해 사전 구축된 (pre-built) 라이브러리로 다양한 백엔드 서버에 연결하는 일이   용이하다.

 

5. 애플리케이션이 인터넷이나 클라우드에서 SOA를 확장해야 한다.

 

기업(enterprise) 서비스 지향 아키텍쳐(Service-Oriented Architecture) 또는 SOA 제품은 내부 기업 네트워크 상에서 효과적이다. 하지만, 이제 고성능 분산 소프트웨어를 방화벽과 프락시 서버에 통과시키고 인터넷 상에 배포해야만 한다. 요구가 많은 소비자와 경영진을 위한 웹 인프라의 모든 장점을 활용할 수 있기 때문이다.

 

웹 소켓으로, 애플리케이션은 인터넷상에서 표준화된 양방향 연결을 열 수가 있다. 개발자들은 이 연결을 활용하여 방화벽 안쪽에 있는 SOA로부터 고성능 기업 서비스 버스Enterprise Service Bus)와 같은 외부 SOA로, 또는 클라우드 환경에서 웹 기반 공급망(Supply Chain)으로 메시지를 연장할(extend) 수 있다.

HTML5 웹 소켓은 더 효율적이어서, 더 적은 인프라로 웹소켓 애플리케이션은 더 많은 병행 사용자들과 더 큰 메시지 용량을 처리할 수 있다. 요구되는 서버의 수가 적기 때문에, 용량 문제(capacity constraints)를 처리해야 하는 애플리케이션에 적합하다. 그러나, 이러한 점이 더 빛을 발하는 곳은 공용과 사설 클라우드와 같은 주문식(on-demand) 컴퓨팅 환경이다. 클라우드 컴퓨팅 환경에서, 수용능력(capacity)은 신축적이다. 사용자는 사용한 만큼 요금을 지불하기 때문이다.

 

전통적으로, 증가하는 요구에 대한 처리 방법에는 두 가지가 있다. 첫 번째는, 더 큰 장비를 구매하고, 메모리를 추가 하는 등 수직적으로 확장(scale)하는 것이다. 지금의 웹앱은 이런 방법을 사용하지 않는다. 대신, 수평적으로 확장한다. 다시 말해, 더 많은 작업(load)를 처리하기 위해, 애플리케이션의 각 층(tier)에 장비를 증설하는 것이다.

그림 6:  클라우드와 같은 신축적인 환경에서 수평적 확장(horizontal scaling)이 필요하다면, 효율적인 애플리케이션 디자인이 중요하다.

 

신축적인 컴퓨팅 플랫폼상에 배포된 웹 애플리케이션은 자원 소비(resource consumption)를 인식하고 있어야 한다. 클라우드에서는, 종종 장비 추가가 자동화 되어 있다. 그래서 자원 소비에 있어 상한(upper limit)은 없다. 비효율적인 코드로 인해, 월말에 비싼 고지서가 갑자기 날라 왔다면, 더 많은 가상 장비(virtual machine)가 생성되어 트래픽을 처리했기 때문이다. 이러한 환경에서는 HTML5 웹 소켓의 효율성이 두드러지게 나타난다.

 

카징 웹소켓 게이트웨이로 웹 상에서 TCP 기반 SOA 프로토콜을 확장할 수 있다. 그래서 발행/구독과 같은 프로그래밍 모델과 인스턴트 메시징(instant   messaging)을 쉽게 사용할 수 있다. 최신 기술인, 카징 플랫폼은 JMS/STOMP, XMPP, IRC 등과 같은 API 콜렉션을 제공한다. 게다가, 게이트웨이는 긴 목록의 메시지 브로커(예를 들면, Tibco, RabbitMQ, Apache ActiveMQ, MQSeries 등)들과 호환되어 프로그래머들이 저수준(low-leve) 웹소켓의   세부사항 보다는 애플리케이션 기능에 초점 맞출 수 있게 되었다. 마지막으로, 카징 웹소켓 게이트웨이의 고유한 아키텍쳐 때문에, 상호 배타적인   네트워크 사이에서나, 클라우드에서 가상 사설 TCP 연결의   환경을 쉽게 설정할 수 있다. 그리고 이로 인해, 기업   시스템의 범위 또한 쉽게 확장 가능하다.

 

카징에 관해서

 

카징은 웹 인프라 소프트웨어 회사로, 확장성이 뛰어난 실시간 기업 웹 애플리케이션의 개발을 가능케하며, 백엔드 서버 인프라를 다순화하여 운영 비용 절감에 기여한다.

 

특허 출원 중인 카징의 웹소켓 가속화 기술(WebSocket Acceleration™ technology)은 현재, 시장에서 전이중 방식 웹 통신을 용이하게 하는 유일한 솔루션이다. 이 기술로 추가적으로 고가의 하드웨어를 구매하지 않고, TCP 기반 메시징 프로토콜을 인터넷으로 매끄럽고 안전하게 확장할 수 있다. 폴링 또는 롱폴링에 의존하는 기존의 비표준 기술과는 달리(높은 지연 시간과 치솟는 서버 인프라 비용을 야기하는 복잡하고 비효율적인 기술), 카징은 초고성능 애플리케이션 성능을 최저의 운영 비용에 제공합니다.

 

관련 링크

• Kaazing: http://www.kaazing.com
• Kaazing Technology Network: http://tech.kaazing.com
• Websockets.org: http://www.websockets.org

포스팅 원본 출처 : http://w3labs.kr/?p=2464

+ 관련기사 

 

 

 

출처: http://blog.kaazing.com/2012/02/22/overview-of-html5-websockets-in-korean/

 

국내 기사 원본 : http://zdnet.co.kr/news/news_view.asp?artice_id=20120222100805