2010 년 10 월 작성

웹이 진화하면서 실시간으로 응답을 받고 싶어하는 Need 가 요즘 들어서 강렬해졌다는 느낌을 받는다. 웹 브라우져에 임베디드되는 애플릿/실버라이트/플래쉬를 이용한 실시간성이 아닌 자체 HTML 안에서 실시간성을 요구받고 있다.

Ajax 의 출현은 웹의 획기적인 발전을 일으키게 되었고, 더욱 실시간 서비스에 대한 Need 를 불러 일으켰다.이런 Need 가 Comet 이라고 하는 기술을 만들게 되었고, HTML5 의 WebSocket 까지 이어지게 되었다.

HTML5 는 여전히 표준이 만들어지는 과정이기 때문에 WebSocket 을 사용하기까지는 시간이 필요한데, 이런 상황에서 현재 실무에서 쓸 수 있는 대안은 바로 이 Comet 기술이다. Comet 기술은 외국에서는 이미 많이 사용되고 있으며, 대표적으로 구글과 Facebook 에서 사용하고 있다.

그림 1. Comet 의 서비스 사례

Comet 이 무엇이냐 라고 말하기 앞서서, 먼저 여러 이름으로 불리우는데, 먼저 이 이름들을 소개하고자 한다. Ajax push, reverse Ajax, Tow-way-web, HTTP Streaming, HTTP server push, Asynchronous push 라고도 불리기도 한다. 이렇게 많이 불릴 정도로 다양한 말로 표현되고 있지만, 사실 하나의 관념에서 나왔기 때문에 이렇게 Comet 이라는 이름으로 쓰기 시작했다.

웹 서버가 웹 브라우져에게 이벤트가 발생할 때마다 이벤트 데이터를 전달하고, 웹 브라우져는 데이터가 돌아오면 처리한다. 이 때, 웹 브라우져가 명시적으로 요청하는 형태가 아닌 일반적인 HTTP 연결보다 긴 HTTP 연결안에서 이루어진다. 이런 웹 어플리케이션 연결 모델을 Comet 이라고 한다.

웹 브라우져는 데이터가 바뀌었는지 일일이 요청할 필요가 없어서 서버의 부하를 줄이고, Latency 와 Traffic 을 조금이나마 줄일 수 있는 방식을 의미한다.

웹 서버에서 Http Streaming 과 Long Polling 방식으로 사용자에게 알려주고 싶은 실시간성 정보를 전달해주는 방법을 Comet 이라고 일반적으로 말한다. Ajax 가 실제로 원했던 그림이라고 생각한다.

실시간의 Need 에 대한 처리에 대해서 지금까지 어떻게 웹에서 구현해서 사용하고 있는지 살펴본다.

실시간 Event 를 웹 브라우져에 전달하는 방식 소개

기존에 실시간으로 보여주고 싶은 Need 를 위해서 페이지를 몇 초에 한번씩 반복적으로 해당 페이지를 호출하는 Refresh 하는 방식 혹은 Ajax 호출을 통한 방식을 사용했었다. (그림 2 참조. Synchorous/Asynchornous 방식의 차이를 제외하고는 개념은 같다.)이 방식은 웹 브라우져에서 계속 호출되기 때문에 실시간 성격이 강할 때, 웹 서버가 많이 부담을 가질 수 있으며, Latency 가 일부 생길 수 있다. 하지만, Event 가 많이 발생되는 경우에는 이 방식을 사용하여 심플한 상태를 유지하기도 한다. 올해 2 월에 오픈한 EA 에서 만든 Lord of Ulitma 라는 웹게임이 이 방식을 사용하고 있다.

그림 2. 주기적인 Refresh 또는 Ajax 호출

서버의 부담을 줄이기 위해서 Piggyback 이라는 방식이 있는데, 일반적으로 사용하는 HTTP 연결을 하는 응답에 살짝 얹혀 보내는 방식을 의미한다. (그림 3 참조) Piggyback 이라는 단어가 영어로 “업기, 목마타기, 업혀가다”라는 의미가 잘 담겨 있다. 하지만 이 방식은 항상 Piggyback 처리에 신경을 써야 하다 보니, Client 코드 코드가 25% 이상 증가되고, 복잡성이 야기되는 단점이 있다.

그림 3. Piggyback 방식

다음은 Http Streaming 방식이다. 웹 브라우져에서 끊기지 않는 HTTP 연결(Stream multipart/cuunked response) 을 가지도록 하여, Event 가 발생하자마자 바로 웹브라우져에게 실시간으로 알리는 방식을 의미한다. (그림 4 참조) 이렇게 하여, 실시간성을 보장할 수 있다는 특징이 있다. 하지만, 이 방식의 구현 중 하나가 이슈가 있는데, Iframe 을 이용하는 경우가 있다. 이는 HTML 의 상태바에 진행중이라는 UI 가 나타나고, 커서에 모래 시계(요청 중)가 보여서 사용자가 오해할 수 있는 소지가 있다. 또한 연결 자체가 항상 keep alive 상태가 되어야 하기 때문에 이 부분에 대한 처리가 많이 필요할 수 있다. 이 방식의 장점을 최대한 활용하기 위해서 Flash 를 써서 이 방식을 구현할 수 있다. 네이버 캘린더의 약속 알림이 이 방식을 사용했다.

그림 4. Streaming 방식

웹 브라우져에서 특정 주기(조금 긴 기간임, 보통 30 초~1 분) 마다 ajax 로 Event 발생되었는지를 요청하다가 Event가 발생되었을 때, 바로 웹 브라우져에 전달하는 방식을 Long Polling 이라 한다. (그림 5 참조). 주기적인 요청 방식과 Streaming 방식의 중간 형태를 띄고 있다. Facebook 의 웹 채팅과 일본 서비스의 오목/오셀로 게임, 옥션 서비스가 다음의 방식을 사용하고 있다.

그림 5. Long Polling 방식

지금까지의 방식 중 Streaming 과 Long Polling 방식을 모아 Comet 이라고 한다.Comet 기술 중 가장 많이 사용하는 방식이 Long Polling 이다. 이 이유는 가장 쉽고 가장 HTTP Connection 개수 제한에도 부딪히지 않기 때문에 많이 활용되고 있다.

Facebook 의 채팅 서비스를 살펴본다. 통신 상으로 보면, 두 개의 채널을 사용하는데, 하나는 내가 말하는 내용을 전달하는데 사용되고, 다른 하나는 서버로부터 내가 혹은 상대방이 보낸 메시지를 받는데 사용한다. 두 채널 모두 ajax

특정 주기

Event

Web Server

Web Browser

로 연결되도록 해서, 필요한 call 만 전달되도록 하였다. 웹 서버에서 웹 브라우져로 전달할 내용이 없을 때는 55 초까지만 기다렸다가 Http connection 을 종료하고 다시 Http connection 을 다시 연결하는 구조이다. 사실 기본적인 채팅/게임 서비스와 다를 것이 없는 가장 간단한 상태이지만, 꽤나 효과적이고 HTTP 의 한계를 극복하려고 하고 있다.

그림 6. Facebook 채팅 구현 내용

Framework 소개

Comet 기술에 대해서 직접 Servlet Container 과 javascript(ajax)를 사용하여 구현하는 사례도 많다. Comet 기술에 대한 많은 구현들이 이미 존재한다. Dojo 와 Jetty 진영이 가장 활발한 활동을 하고 있는데, 대표적인 프레임웍은 DWR (http://directwebremoting.org/dwr/index.html), cometD(http://cometd.org/) 을 들 수 있다.

특히 cometD 는 Bayeux 라는 표준을 구현한 구현체이다. Bayeux 는 json 기반으로 통신하고, 하나의 http 연결을 여러 개의 channel 로 message 를 전달할 수 있는 방식을 정의하고 있다. message 는 meta/event/polling 방식으로 나누어서 편하게 쓸 수 있는 방법을 제공하고 있다.

Servlet Container 지원웹 서버에서는 바로 이런 comet 방식에 대해서 적절히 지원할 필요가 있다. 기존 웹 서버(Tomcat 의 AJP Connector)는 Request 에 대해서 하나의 Connection 을 맺고 하나의 Thread 에서 처리하는 방식 (Blocking IO/Thread per connection)은 이 Comet 기술에는 적합하지 않다. (그림 7 참조)Thread 가 굉장히 중요한 자원인데, 이 Thread 의 개수가 한정되어 있다는 점이다.

그림 7. Blocking IO 모델 (기존)

Request 에 대해서 Blocking 하지 않도록 하고(Non-blocking IO/Thread per request), 높은 성능(NIO)을 취하는 방식을 이용할 필요가 있다. 그래서 많은 Request 가 들어오더라도 많이 받아줄 수 있도록 해야 했다. (그림 8 참조)Jetty 의 continuation 는 10700 Concurrent requests 를 처리할 수 있었고, 메모리는 57MB 만 사용했다고 하며, Tomcat 의 Comet 도 10000 request 이상을 처리했다고 한다.

그림 8. Non-Blocking IO 모델 (Comet 지원)

그래서 Servlet Container 마다 이런 Blocking Thread 의 한계적인 상황을 넘어서기 위해서 Non-Blocking Thread 동작이 되도록 하는 comet 기술이 들어가 있다. Tomcat 의 Comet, Jetty 의 Continuation 기술들이 이런 Comet 기술(비동기 요청)에 대한 Need 를 수용하기 위해서 만들어졌다. 많은 Servlet Container 들이 이런 고민들을 가지고 있었고, 이 부분을 표준화하였다. 그 결과로 Servlet 3.0 에 비동기 처리에 대한 요구사항으로 추가되었다. Servlet 3.0 의 2.3.3.3 Asynchoronous Processing 에 추가되었고, State machine 부분과 비동기적으로 처리할 내용, API가 소개되어 있다.

현재 Servlet 3.0 을 구현한 Tomcat 7, Jetty 8 Beta 가 발표되었고, 조만 간에 안정적인 버전으로 되어 많이 사용하게 되리라 생각된다.

Comet 기술의 도전과 향후 과제

웹 브라우져 또는 브라우져 버전마다 Socket Limit 이 있는데, 이 부분에 대한 고려를 잘 해야 하고, 브라우져마다의 특성을 잘 살필 필요는 있다. 또한 Connection Failure 에 대한 정책과 처리에 대한 고민이 필요하다. 서비스의 특성에 맞게 Ajax polling 으로 갈지, Comet 으로 써야할지 고민이 필요하다.그리고, Scalability 에 대한 고민이 필요하다. 비동기 처리 방식을 쓴다고 하지만, 메모리가 가장 큰 이슈가 될 수 있다. 최적화된 GC 알고리즘과 튜닝이 필요하고, 메모리의 크기에도 성능에 많이 민감할 수 있다. 특히 Socket 관련된 IO(NIO)에 대한 정확한 이해와 활용이 필요하다. 사용자 Session 을 어디서 관리하느냐도 중요한 부분이 될 것이다. 보안 공격에 취약할 수 있다. Apache Http 서버의 경우는 비동기 모드가 지원되지 않아서 Tomcat 을 바로 앞단에 취하는 구조를 쓰일 수 있다.마지막으로 코딩의 복잡성이 있을 수 있다. Framework 없이 Servlet Container 에서 비동기 Servlet 을 구현할 경우, State machine 사용으로 인해서 State 를 생각하면서 코딩해야 하기 때문에 그 동안 Sequence 형태로 개발에

비해서 복잡함을 느낄 수 있다.

참고 내용1. 도서 “Comet 과 리버스 Ajax 차세대 웹 트렌드” 2. Exploring Reverse AJAX 블로그

http://gmapsdotnetcontrol.blogspot.com/2006/08/exploring-reverse-ajax-ajax.html