Service Bus 를 이용하여 플렛폼 시스템을 구축하고, 운영을 해봤습니다.
초반에는 지지부진 했습니다만, 급기야 하루에 1억 건이 넘을 정도로 request가 몰렸습니다.
보통 Service Bus 를 전사 시스템의 미들웨어 역활로 활용을 합니다. 대부분(제가 본 사이트)의 아키텍처는 아래 그림과 크게 다르지 않았습니다.
OSB 는 전사시스템의 gateway 역활을 수행하고, 주요기능은 다음과 같습니다.
- 서비스 라우팅
- 필요에 따라서 인증,인가 등의 보안처리
- 비동기식 처리
- in/out 데이터의 logging
세부적인 기능은 더 많겠지만, 주요기능만 열거해봤습니다.
그런데 이렇게 시스템을 구축하고 실제로 운영을 해보면, "Service Bus 가 과연 필요할까?" 라는 의문이 점차 들기 시작합니다.
경험상 비동기식으로 처리하던 업무는 점차 동기식으로 처리하게 됩니다.
실제로 라우팅기능은 Web server 에서도 가능하기도 합니다.
나머지 기능은 해당 Application 공통로직에서 처리 해도 됩니다.
그런데 미들웨어 시스템으로 구축한 Service Bus의 장점은 운영시점에 발생합니다.
위 아키텍처에서 아래 그림처럼 Service Bus 가 없다라고 가정을 합니다. 아마도 다수의 사이트가 그럴 것입니다.
어느 사이트에서나 볼수 있듯이, 트래픽이 몰리면, DB 서버부터 부하를 받아 그 영향이 WAS로 전이되고 결국 전면 장애로 발생합니다.
DB 부하 -> Application 부하 -> WAS 부하 -> Web Server 부하
결국 Web Server 부하로 까지 전이되면, 사용자의 request를 받아 줄 수 는 접점이 없기 때문에 전면장애 현상이 발생합니다.
Web Server, WAS 의 재기동을 무한히 반복하여 DB session 수를 감소시켜야 어느정도 안정화가 됩니다. 하지만 몇분 이내에 똑같은 현상이 발생할 것입니다.
미들웨어 성격의 Service Bus는 이때 위력을 발휘 합니다.
트래픽이 몰리는 Application 에 대해서는 throttling 기능을 적용하여 분당 처리할 수 있는 request 수를 제한을 합니다. 특정 Application 이 도저히 서비스를 할 수 없는 상황이라면, 그 Application 으로 라우팅 하는 configuration을 수정하여 Application으로 라우팅 하지 않고 client로 양해 메시지를 만들어 리턴을 시킵니다.
설령 DB 시스템이 망가졌어도, DB를 이용하지 않는 Application 서비스는 정상적으로 라우팅을 시키면 됩니다.
이것은 시스템 전면장애를 막을 수 있는 좋은 수단이 됩니다.
Oracle Service Bus 는 runtime 시에 configuration 변경이 가능하여, 위 모든 상황에서 아주 신속하고 유연하게 대처할 수 있습니다.(서버 재기동이 필요 없습니다. rollbak 도 클릭 한번으로 이루어 집니다.)
"500 Internal Server Error" 와 "500 폭주로 인해 일부 서비스는 지연이 되고 있습니다" 는 매우 큰 차이 입니다.
트래픽이 어마어마하게 몰리면 Service Bus도 결국 죽을 수 있습니다.
하지만, 대부분은 DB, WAS 상의 지연현상이 Service Bus 로 영향을 끼치기 때문입니다.
Application으로 라우팅을 하지 않고, 바로 client 로 리턴하는 것의 cost 는 매우 매우 작습니다.
Service Bus 도입은 시스템 운영의 가동률, 안정성을 훨씬 크게 높여 줄 것입니다.
Dynamic xquery (0) | 2012.11.30 |
---|---|
Generate WSDL from XSD with Eclipse. WSDL 생성 만들기 (0) | 2012.11.07 |
OSB 최초 deploy error (0) | 2012.09.08 |
OSB에서 Accept-Encoding, Content-Encoding 차이 (0) | 2012.04.04 |
Weblogic10.3 SSL handshake failure 해결 (0) | 2012.03.23 |
댓글 영역