2015년, 현재 WAS로 선택가능한 제품은 매우 많습니다.

 오픈소스 기반의 대표적인 Tomcat 부터 우리나라에서 많이 사용하는 JEUS(TmaxSoft), WebLogic(Oracle), WebSphere(IBM) 등등 수많은 제품들이 시장에 산재해 있습니다. 이 제품들은 거의 대부분 Java Enterprise Edition(Java EE)의 표준을 따르고 있으며, 그러므로 각 제품들의 기본 기능들은 모두 동일하다고 봐도 무방합니다. Java가 아닌 언어로 로직을 구현하는 Microsoft의 IIS(C#)도 WAS라 불리웁니다.

 WAS의 기본 기능을 아주 간단히 설명한다면 “웹 페이지에 쓰이는 비지니스 로직을 수행하고 결과를 돌려준다” 입니다. 이 비지니스 로직은  ”어떤 웹 사이트에서 사용자가 입력한 ID와 Password를 전송받아 DB에 질의(Query)를 하여 일치할 경우 로그인을 수행한다”를 예로 들 수 있겠습니다.

 그렇다면 이러한 간단한 기능을 구현하는데 가격도 비싸고 무거운 상용 WAS가 필요한 이유는 무엇일까요?

 그것은 안정성과 장애가 생겼을 때의 유지보수성 때문이 가장 큽니다. Tomcat 같은 오픈소스 기반의 WAS는 기본 기능은 충실히 구현을 하나, 사용자 접속이 많거나 부하가 큰 비지니스 로직을 수행하는 경우 문제가 생길 가능성이 높아집니다.

 또한, 오픈소스 기반이기 때문에 장애가 발생하여도 어디 업체에 하소연할 곳도 없겠지요.. 이때문에 보통의 경우 Tomcat을 개발용으로 사용하고, 테스트 서버 및 실 서버는 상용 WAS를 사용하게 됩니다. 상용 WAS는 돈받고 파는만큼 안정성이 무료 WAS와 비할 수 없겠지요.. 하지만 실제로 프로젝트를 수행해보면 WAS에 수많은 장애가 나타납니다.  IBM i 서버에는 상용 WAS인 WebSphere의 Express 버전이 번들로 포함되어 있기때문에 i 서버를 WAS의 용도로만 사용하는 고객도 있습니다. 장애가 나면 저희 비에이솔루션즈에 전화해서 “도와줘요~ 비에이~!” 라고 하시겠죠? 그러면 불이나케 IDC로 달려가거나, 원격을 통해 서버를 점검해 보죠.. 이때 발견되는 가장 많은 케이스들은 다음과 같습니다.

1. 메모리 부족 : Java에서 프로그래머들이 생성한 Object 들을 저장하는 장소인 Heap 영역 또는 드물게 JVM 내부에서 사용하는 Native 영역의 메모리가 부족해서 발생하는 오류입니다. 주로 오픈 초기에 어플리케이션이 사용하는 메모리를 산정하는데 실패하였거나, JDK를 32bit 로 셋팅하고 Heap 메모리를 크게(2GB 이상) 할당한 경우, 어플리케이션의 버그 등으로 인해 발생합니다. 이 경우는 Heap 영역의 메모리 크기를 충분히 늘리거나, 시스템 메모리가 4G 이상이라면 JDK를 64bit 로 변경하거나, 메모리를 비정상적으로 많이 사용하는 로직의 버그를 수정함으로써 해결할 수 있습니다.

2. 잘못된 쿼리 : (주로)DBMS에 쿼리를 던졌는데 응답이 늦게 오거나 안오는 경우. 의도치 않은 쿼리(Lock 유발 등)로 인해 발생합니다. 이 경우 요청을 받아주는 Thread가 설정한 최대치에 도달하게 되고 더 이상 사용자의 요청을 받을 수 없는 상태가 되어 사용자 측에서 웹 사이트가 열리지 않는 문제가 발생합니다. 문제가 되는 쿼리를 수정함으로써 해결할 수 있습니다.

3. 자원 부족 : WAS의 CPU 사용량이 최대치에 이르는 상황입니다. 프로그램 로직이 CPU의 연산을 많이 필요로 하는 경우나, 사용자가 많아 발생합니다. APM 솔루션을 통해 자원을 많이 사용하는 프로그램 로직을 수정하거나, 시스템의 확장을 통해 해결할 수 있습니다.

 이중에서도 대부분의 장애는 2번 잘못된 쿼리로 인해 발생합니다. WAS 장애의 대부분은 DBMS에 쿼리를 날렸을때 응답이 늦거나 오지 않는 원인으로 인해 발생하는 것이죠. 응답이 늦는 경우 페이지 응답속도가 느려지고, 오지 않는 경우는 심각하면 웹 사이트가 먹통이 되는 경우가 발생하겠죠..

 쿼리에 의한 장애를 해결하기 위해선 빨리 문제가 되는 쿼리를 찾아내서 수정을 해야 하겠죠. 이 때 필요한 것이 APM(Application Performance Management) 솔루션입니다. APM 솔루션은 전반적인 웹 어플리케이션의 실행 속도를 구간(WAS <-> 외부서비스, WAS <-> DB, logic 단위의 실행 속도 등..) 별로 보여주고 문제가 되는 지점(프로그램 소스 및 쿼리 등)을 인식할 수 있도록 해 줍니다. 또한 DB 모니터링 툴이 통합되어 있는 경우 해당 쿼리가 DB 내부에 어떤 수행 로직으로 인해 응답속도가 늦었는지 파악할 수 있도록 합니다. 이쯤되면 APM 솔루션은 WAS 장애처리에 필수 요소가 되겠네요?

다음번 포스팅엔 APM에 관해 제 의견을 나누도록 하겠습니다.

감사합니다.