2010년 10월 작성웹이 진화하면서 실시간으로 응답을 받고 싶어하는Need가 요즘 들어서 강렬해졌다는 느낌을 받는다. 웹브라우져에임베디드되는애플릿/실버라이트/플래쉬를이용한 실시간성이 아닌 자체 HTML 안에서 실시간성...
이 방식은 웹 브라우져에서 계속 호출되기 때문에 실시간 성격이 강할 때, 웹 서버가 많이 부담을 가질 수 있으며, Latency가 일부 생길 수 있다. 하지만, Event가 많이 발생되는 경우에는 이 방식을 사용하여 심...
가지도록 하여, Event가 발생하자마자 바로 웹브라우져에게 실시간으로 알리는 방식을 의미한다. (그림 4 참조)이렇게 하여, 실시간성을 보장할 수 있다는 특징이 있다. 하지만, 이 방식의 구현 중 하나가 이슈가 있는데...
Web Browser                                 Web Server 특정 주기                                                              ...
Framework 소개Comet 기술에 대해서 직접 Servlet Container과 javascript(ajax)를 사용하여 구현하는 사례도 많다.Comet 기술에 대한 많은 구현들이 이미 존재한다.          ...
Request에 대해서 Blocking하지 않도록 하고(Non-blocking IO/Thread per request), 높은 성능(NIO)을 취하는 방식을 이용할 필요가 있다. 그래서 많은 Request가 들어오더라도...
그리고, Scalability에 대한 고민이 필요하다. 비동기 처리 방식을 쓴다고 하지만, 메모리가 가장 큰 이슈가 될 수있다. 최적화된 GC 알고리즘과 튜닝이 필요하고, 메모리의 크기에도 성능에 많이 민감할 수 있다....
Upcoming SlideShare
Loading in...5
×

Comet

2,977

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,977
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
41
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Transcript of "Comet"

  1. 1. 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 방식의차이를 제외하고는 개념은 같다.)
  2. 2. 이 방식은 웹 브라우져에서 계속 호출되기 때문에 실시간 성격이 강할 때, 웹 서버가 많이 부담을 가질 수 있으며, 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) 을
  3. 3. 가지도록 하여, Event가 발생하자마자 바로 웹브라우져에게 실시간으로 알리는 방식을 의미한다. (그림 4 참조)이렇게 하여, 실시간성을 보장할 수 있다는 특징이 있다. 하지만, 이 방식의 구현 중 하나가 이슈가 있는데,Iframe을 이용하는 경우가 있다. 이는 HTML의 상태바에진행중이라는UI가 나타나고, 커서에 모래 시계(요청 중)가보여서 사용자가 오해할 수 있는 소지가 있다. 또한 연결 자체가 항상 keep alive 상태가 되어야 하기 때문에 이부분에 대한 처리가 많이 필요할 수 있다.이 방식의 장점을 최대한 활용하기 위해서 Flash를 써서 이 방식을 구현할 수 있다. 네이버 캘린더의 약속 알림이 이 방식을 사용했다.그림 4. Streaming 방식웹 브라우져에서 특정 주기(조금 긴 기간임, 보통 30초~1분) 마다 ajax로 Event 발생되었는지를 요청하다가Event가 발생되었을 때, 바로 웹 브라우져에 전달하는 방식을 Long Polling 이라 한다. (그림 5 참조). 주기적인요청 방식과 Streaming 방식의 중간 형태를 띄고 있다. Facebook의 웹 채팅과 일본 서비스의 오목/오셀로 게임,옥션 서비스가 다음의 방식을 사용하고 있다.그림 5. Long Polling 방식
  4. 4. Web Browser Web Server 특정 주기 Event지금까지의 방식 중 Streaming과 Long Polling 방식을 모아 Comet 이라고 한다.Comet 기술 중 가장 많이 사용하는 방식이 Long Polling이다. 이 이유는 가장 쉽고 가장 HTTP Connection 개수제한에도 부딪히지 않기 때문에 많이 활용되고 있다.Facebook의 채팅 서비스를 살펴본다. 통신 상으로 보면, 두 개의 채널을 사용하는데, 하나는 내가 말하는 내용을전달하는데 사용되고, 다른 하나는 서버로부터 내가 혹은 상대방이 보낸 메시지를 받는데 사용한다. 두 채널 모두 ajax로 연결되도록 해서, 필요한 call만 전달되도록 하였다.웹 서버에서 웹 브라우져로 전달할 내용이 없을 때는 55초까지만 기다렸다가 Http connection을 종료하고 다시Http connection 을 다시 연결하는 구조이다.사실 기본적인 채팅/게임 서비스와 다를 것이 없는 가장 간단한 상태이지만, 꽤나 효과적이고 HTTP의 한계를 극복하려고 하고 있다.그림 6. Facebook 채팅 구현 내용
  5. 5. 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 모델 (기존)
  6. 6. 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으로 써야할지 고민이 필요하다.
  7. 7. 그리고, 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

×