Coherence를 이용한 차세대 JEE 아키텍쳐 (확장성과 유연성이 높은 애플리케이션 그리드)

 

오라클 Coherence 가 그려내는

차세대 Java Enterprise Architecture

 

한국 오라클 컨설팅
Principal Consultant
조 병욱 (byungwook.cho골뱅이oracle.com)

 

서문 

2008년과 2009년의 SI 프로젝트 상황을 보면 의외로 사실상 실패하는 프로젝트의 비중이 늘어나고 프로젝트상에서 기술적인 문제가 발생하는 빈도가 늘어나고 있다. 특히 I사가 주 사업자로 참여한 프로젝트의 경우 오픈시에 항상 기술적인 문제점이 발생하고 있다. 이미 KOO 와 동XXX 와 프로젝트를 진행한 OO사 등이 그 사례라고 볼 수 있다. 진행사의 SI 능력에서 문제의 원인을 찾을 수 도 있지만, 근래에 진행되는 많은 프로젝트들이 유사한 문제점을 가지고 있는 것을 봤을때는 단순하게 수행사의 문제라고만 하기에는 어렵다. 

근래에 들어서 대부분의 SI 프로젝트의 경향을 보면 Spring,IBatis,Struts등과 같은 프레임웍을 사용하여 시스템을 개발하는 사례가 많다. 프레임웍은 생산성을 높여주고 시스템의 구조를 향상 시키는 역할을 하지만 반대로, 시스템의 구현 STACK이 깊어져서 시스템의 복잡도를 높이게 되고 이로 인해서 많은 기술적인 이슈를 야기 하게 된다. 

본 문서에서는 이 두가지 문제점을 자사의 Coherence와 Oracle Service Bus를 이용하여 해결할 수 있는 방법에 대해서 소개한다. 

기존 아키텍쳐의 문제점

J2EE가 소개된 이례 현재까지 가장 널리 사용되는 전통적인 아키텍쳐는 다음과 같다.

하나의 WAS 내에 UI와 비즈니스 로직을 같이 구현한다. 회사의 전체 업무가 크게 3개의 업무로 나뉘어진다고 해도, 3개의 업무가 모두 하나의 애플리케이션에 포함되어 배포되고 운영되어 왔다. 

메모리 사용량의 증가

이런 아키텍쳐가 가지고 있는 문제점은 무엇일까?
IT 비즈니스에 대한 요구 사항은 점점 더 증가 되어가고 있고 이는 더 많은 업무 로직과 기능을 요구하게 된다. 즉 업무 로직 자체가 커지게 되는데, 반대로 이를 지탱하고 있는 자바 언어 자체는 메모리의 한계를 벗어나지 못하고 있다. 통상적으로 32BIT JAVA에서 JAVA가 사용할 수 있는 메모리량은 최대 1.5G 내외가 된다. 물론 64Bit JVM을 사용해서 사용 가능한 메모리양을 확장할 수 는 있지만, JAVA가 가지고 있는 한계[i] 로 인하여 비대해지는 애플리케이션에 대한 문제가 많이 발생하고 있다.

실예로 모 화재 보험사 차세대 시스템의 경우에도 모든 업무가 하나의 애플리케이션에 함께 패키징되는 형태로 개발 및 배포 되어 많은 메모리 사용량을 요구하게 되었고 이로 인한 이슈가 있었다.

 또한 현재의 기술 흐름이 XML이나 OR Mapping과 같이 개발의 편의성과 우수한 구조를 제공하는 기술들이 소개되고 사용되지만 이것 역시 전통적인 애플리케이션에 의해서 메모리 사용량이 많이 늘어나게 된다. 

업무간의 장애 전파

기존 아키텍쳐의 다른 문제점중의 하나가 모든 업무가 똑같이 WAS인스턴스에 모두 같이 배포되기 때문에 장애가 발생하였을 때 그 장애가 다른 업무에도 영향을 준다는 것이다.[ii]

예를 들어 업무 C가 문제가 생겼을 때 같은 인스턴스에서 수행되고 있는 업무 A나 B에도 영향을 준다. 웹로직의 WorkManager등의 기능을 이용하여 장애를 최소화할 수 는 있지만 메모리 과사용이나 CPU 과점유등과 같은 Critical한 장애의 경우를 방지할 수 있는 방법이 없다. 

기존 아키텍쳐에 대한 개선 방안

그렇다면 기존 아키텍쳐에 대한 문제를 해결하기 위해서는 어떤 접근 방법이 필요할까?

해결 방안

해결 방안은 의외로 간단하다. 업무별로 WAS 인스턴스를 분리해서 배치하는 것이다.

 이런 아키텍쳐를 취할 경우 앞에서 제시된 두가지 문제점을 해결할 수 있다.

효율적인 메모리 사용

각 WAS 인스턴스별로 하나의 업무만 배포되기 때문에, 결과적으로 인스턴스당 요구되는 메모리 사용량이 적어진다.

장애 전파 방지

인스턴스가 물리적으로 완벽하게 분리되기 때문에, 특정 업무에서 장애가 발생하더라도 다른 업무에 전혀 영향을 주지 않는다.

 여기에 더해서 몇가지 장점을 더 얻을 수 가 있는데,

유연한 시스템 자원의 배분

업무 처리량에 따라서 유연하게 WAS 인스턴스 수를 조정할 수 있다. 업무 A의 처리량이 많을 경우에는 업무 A에 대한 WAS 인스턴스를 추가로 배정할 수 있고, 가상화를 지원하는 하드웨어의 경우에는 CPU를 업무 처리량이 많은 인스턴스에 배정하여 자원 사용의 효율성을 높일 수 있으며 업무에 대한 인스턴스가 명확하게 지정되어 있기 때문에 운영환경에서도 과부하시 자원(CPU)를 어느 프로세스에 적용해야 하는지가 명확해져서 시스템 운영의 효율성과 유연성을 확보할 수 있다. 

왜 개선 아키텍쳐를 사용하지 않는가?

그렇다면 이렇게 해결책이 명확한 아키텍쳐가 있음에도 불구하고 전통적인 엔터프라이즈 자바 애플리케이션에서 이런 아키텍쳐를 사용하지 않았을까? 문제는 이 아키텍쳐가 기술적인 한계성을 가지고 있다는 것이다.

애플리케이션은 업무 처리를 위해서 사용자에 대한 상태 정보등 (로그인 정보, 권한등)을 유지하게 되는데, 흔히 Http Session이라는 메모리 상에 이 정보를 저장한다. 이 Session 정보는 클러스터간에는 서로 공유가 가능하지만 다른 클러스터 간에는 공유가 불가능 하다.

즉 업무 A를 위해 구성된 클러스터에서는 업무 B를 위해서 구성된 클러스터내의 사용자 상태 정보를 서로 공유할 수 없다는 것이다.

 완벽하게 분리되서 동작하기 때문에, 상태 정보역시 분리되어 버리는 결과를 낳게된다. 

Coherence를 이용한 아키텍쳐의 확장

이 아키텍쳐상의 한계를 Oracle Data Grid 솔루션인 Coherence로 해결할 수 있다.

Coherence Data Grid에 사용자 상태 정보를 정보와 업무간에 공유해야 하는 공유 데이터를 저장함으로써, 클러스터 구성 방식과 상관없이 업무 로직에서 사용자 상태 정보를 공유할 수 있게 됨으로써 구현하고자 하는 아키텍쳐를 실제로 구현할 수 있게 되었다.

 또한 Coherence를 이용한 Data Grid를 구축함으로써 기존에 사용자 상태 정보에 저장할 수 있는 데이터의 크기가 작았던 단점을 극복하고 좀더 큰양의 사용자 상태 정보를 유지할 수 있게 되었다[iii]. 

이 아키텍쳐에서는 업무로직을 가지고 있는 WAS Instance가 분리될 수 있어서 장애 전파성이 없어지고 확장이 무한적으로 가능할 수 있게 되며 업무에 따라서 WAS Instance 수나 CPU를 조정할 수 있기 때문에 유연한 자원 운용이 가능하다.

---

[i] Garbage Collection Time – 다 사용한 메모리를 반납하는 과정인데 이때 시스템이 일시적으로 정지하는 현상이 발생하는데,  이 정지 시간은 메모리의 크기에 비례한다

[ii] 클러스터링을 구성했다하더라도 업무 로직에 문제가 있는 경우에는 같은 업무 요청이 들어오게 되면 클러스터된 다른 인스턴스에서 같은 로직을 수행하기 때문에, 클러스터 여부에 관계없이 전체 시스템으로 장애가 전파 된다.

[iii] 실제 모 관공서 시스템의 경우 사용자 상태 정보에 많은 데이터를 유지했는데, 자바의 메모리 크기의 한계로 인하여 부하가 많을 경우에는 메모리 부족으로 인하여 장애를 유발하였다. 이런 문제를 해결하기 위해서는 기존의 아키텍쳐의 경우 하드웨어를 증설하여 더 많은 WAS 인스턴스를 운영하여 부하를 분산함으로써 WAS 인스턴스당 사용되는 사용자 정보 유지용 메모리 사용을 분산해야 하는데, Coherence를 도입할 경우에는 더 많은 메모리가 요구 될 경우 Coherence 용 서버만 확장하면 되기 때문에 시스템 증설시에 그 효율성이 매우 높아진다.