블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

오라클 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 용 서버만 확장하면 되기 때문에 시스템 증설시에 그 효율성이 매우 높아진다.

 

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. Eminency 2009.06.10 12:24  댓글주소  수정/삭제  댓글쓰기

    발 담궈봤던 프로젝트라 그런지 매우 감명깊게 와 닿는 포스팅입니다 -_-

  2. 찬욱 2009.06.10 17:04 신고  댓글주소  수정/삭제  댓글쓰기

    좋은 글 감사합니다.
    문제 인식을 넘어서 실제로 어떤 방법으로 구성할 수 있는지와 여러 구성 방안에 대한 설명도 함께 해주시면 정말 좋을 것 같습니다^^.

  3. kenu 2009.06.10 17:30  댓글주소  수정/삭제  댓글쓰기

    auction 사이트의 설계와 유사하군요. 잘 읽었습니다.

  4. sinklare 2009.06.11 07:07  댓글주소  수정/삭제  댓글쓰기

    HTTP Session 공유의 경우 WAS에 따라 업무가 다르더라도 공유할수 있게끔 하는 기능이 있습니다. 이 경우 HTTP Session 공유 기능으로 Coherence와 같은 효과를 낼수 있습니다.

    • 조대협 2009.06.11 09:37 신고  댓글주소  수정/삭제

      그렇군요. 좋은 지적 감사합니다.
      Coherence를 쓰는 가장 큰 이유중의 하나는 상태 정보의 공유와 상태 정보 저장 메모리 한계에 대한 극복입니다.
      Session 공유를 여러 인스턴스들에서 한다면 인스턴스 수 증가에 따라서 Session 공유에 대한 메모리 부담이 늘겠지요. Coherence를 사용하는 이유는 공유 메모리 공간을 WAS 인스턴스에서 분리해서 메모리 사용에 유연성을 부여 하고자 하는 의미가 있습니다.

  5. sinklare 2009.06.12 06:15  댓글주소  수정/삭제  댓글쓰기

    하나만 덧붙이자면 Coherence도 Session 공유 모듈과 마찬가지로 Distributed Caching의 일종입니다. 뒤집어 말하면 WAS에 있는 Session 공유 모듈도 메모리를 효율적으로 사용하는 분산 시스템으로 구현이 될수 있고, Coherence도 local WAS instance에 자신을 위한 메모리 영역을 어느 정도 사용하고 있다는 것이지요. 물론 제가 써보진 않았지만 Coherence가 효율적인 잘 만들어진 Distributed Caching System이라 생각합니다.

  6. sols 2009.06.15 14:27  댓글주소  수정/삭제  댓글쓰기

    태클은 아니구영 의문점이 들어서요 ^^;
    session 공유에 대한 용도로 사용하기에는
    coherence의 사용범위가 너무 좁은거 같다라는 생각이 듭니다.
    session 공유가 목적이라면 각 CacheServer의 메모리를 최대로 잡는다고 가정했을시
    그렇게 많은 수의 Cache Server를 띄울 필요가 없을거라는 생각이 드는데
    그 몇개의 CacheServer를 위해
    Coherence를 도입한다고 하면 그것을 위해 지불해야되는
    라이선스 비용이 부담이 될거라는 생각이 듭니다.

    • 조대협 2009.06.15 14:53  댓글주소  수정/삭제

      1. 첫번째로, 필요한 만큼만 Data Grid를 띄우면 될꺼구요. (Coherence는 정확하게 이야기 하면 Cache 서버는 아닙니다. ^^;)
      2. Session 공유를 Application 변경없이는 사실할 수 있는 방법이 거의 없지요. 개발 공수를 줄이면서 Session 공유를 하는 방법이라면 솔루션이 좋지 않을까요?
      3. 위에서도 설명했듯이 Coherence와 같은 Data Grid 가 도입됨으로써의 장점이 있으니까는 +/-를 따져서 도입 여부를 결정해야 겠지요.
      4. 그리고 결정적으로 Coherence 가격이 그리 안 비쌉니다. ^^;

  7. joe 2009.09.20 23:28  댓글주소  수정/삭제  댓글쓰기

    coherence data grid 쪽의 failure 처리는 어떻게 되나요? 단순 로직이라 WAS 쪽에 모든 로직이 있는 것보다는 안전하다? front 의 load balancer 쪽에서 이미 기본적으로 failure 처리가 되어 들어온 사용자 request 가 다시 coherence data grid 로 모여서 single failure 지점이 되는 문제가 되지 않을까 하는 예상이 되네요.

    • 조대협 2009.09.21 12:34 신고  댓글주소  수정/삭제

      Coherence 특징중의 하나가 중앙 집중형 클러스터링이 아니라 분산형 클러스터링이기 때문에, 장애시에 전체 노드가 불능이 되는 경우는 거의 없을거라고 판단하구요. Coherence 내의 클러스터에서 자체 Failover를 하기 때문에 장애에 대해서는 훨씬 강력합니다.

  8. 아삽 2011.04.20 17:42  댓글주소  수정/삭제  댓글쓰기

    좋은 정보 감사히 읽고 갑니다. 앞으로도 유익한 포스팅 계속 부탁합니다.^^