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


Archive»


 
 

오라클이 이번 "오라클 오픈월드"에서 Sun 하드웨어를 기반으로하여 클라우드 플랫폼을 지원하기 위한 Web Application Server Platform인 Exalogic을 발표하였다.
이전에 Sun 하드웨어 + Oracle DBMS를 기반으로 하여 OLAP과 OLTP를 지원하기 위한 Exadata를 발표하더니 이번에는 WebLogic을 하드웨어와 녹였다. 거기에 이번에는 클라우드라는 단어까지 붙여 버렸다.


특징을 살펴보면, 하드웨어 융합 과, 클라우드 지원이라는 두가지 특징을 가지고 있다
자바 기반의 WAS야 어짜피 하나의 JVM단위로 인스턴스가 뜨기 때문에, 여러개의 하드웨어에 인스턴스를 분산하여 배치하기가 좋고, 이 말은 즉 클라우드 인프라에 걸쳐서 배포가기가 용이하기 때문에 클라우드 적용성이 높다는 것이다. 단 여러 하드웨어를 하나의 논리적인 하드웨어 플랫폼으로 볼 수 있게 관리 및 배포가 가능해야 하는데, 이것이 Exalogic Elastic Cloud Software 라고 불리는 놈인것 같고, 이를 관리하기 위한것이 Enterprise Manager (EM)이다. EM은 예전에도 경험이 있었지만 WebLogic Server의 그 많은 기능을 감당하기에는 부족한 놈으로 보이는데, 이번에 얼마나 개선이 되었는지가 궁금하다.

아울러 Runtime에서 동적으로 WebLogic Instance를 추가 삭제가 가능하고, Resource를 동적으로 Allocation이 가능한지 궁금하다.

사실 이게 되야 진정한 클라우드 플랫폼이라고 볼 수 있는데, 아니라면 역시 하드웨어에만 Optimize해놓은 형태일 수 도...

하드웨어에 최적화 한것은 아마도 결과가 좋을듯 하다. 일단 BEA의 JRockit을 사용했고, JRockit의 경우 성능에서는 다른 JVM에 비해 월등하게 뛰어났으니까는
Oracle에서 제공하는 성능 데이타를 보면
위의 그래프와 같이 응답시간은 대략 8배 정도 향상, TPS는 1.2~1.5배 정도 올라가는 것으로 나오는데.. 이 수치는 사실 믿을 것은 못되는 것 같고.. 20~30% 정도 성능 향상이 있지 않을까 싶다.
(그간 JVM이나 WAS 튜닝을 해봐도 응답시간이 8배 정도 올라갈 정도로 Dramatic한 Tuning은 어려웠다. 그리고 JRockit for Sun JVM이 예전 부터 있었는데, 그게 Oracle에 인수 되었다고 성능이 8배 늘어날리는 없는 것이고... )

결국 Sun Hardware에 JVM을 최적화 시키고 그 위에 이전에 있던 WebLogic + Coherence를 그대로 올려서 하드웨어에 패키징해서 팔아먹고, 거기에 Cloud 처럼 관리 플랫폼 또는 내부 가상화(?) 있는지 없는지 모르겠음.. 사실.. 추가한것으로 보이고...

국내외에서 사용 사례나 세미나에 한번 가서 들어봐야지 실체는 알겠다.
결론은 아직까지는 그냥 하드웨어 같이 패키징한것에 불과 하고, 성능은 20~30% 정도 향상됬을것으로 기대됨.. (어디까지나 사견임)
http://wiki.tangosol.com/display/COH35UG/Coherence+3.5+Home


OO 차세대 시스템

WAS Architecture Blue Print (DRAFT)  

2009-06-28

Oracle Korea Consulting

Principal Consultant

Byungwook Cho (byungwook.cho@oracle.com)

 

 

Overview

본 아키텍쳐는 OO 차세대 시스템을 위한 웹로직 구성 아키텍쳐이다. OO 아키텍쳐 요구 사항에 따라서 구성한 아키텍쳐로 다음과 같은 전제 조건을 기반으로 한다. Ÿ          웹로직을 중심으로 설계할것           클라이언트는 웹이 아닌 윈도우 애플리케이션을 사용한다.

    100개의 웹로직 인스턴스가 동시 운영 될것으로 예측된다.         총 업무는 A업무 (4개), B관리 (4개), C관리 (4개) 로 구성된다.Ÿ          하드웨어는 IBM P6 시리즈를 사용하며, 총 예상 CPU수는 52장이며, 하드웨어 가상화 기능을 제공한다. 

Architecture Principals

본 아키텍쳐의 설계 기본 원칙은 다음과 같다.

1. 안정성

장애가 발생하였을 때도 장애 업무 이외의 업무는 정상적인 수행이 가능해야 하며 타 업무로 그 영향을 전파해서는 안된다.

2. 확장성

비즈니스 상황에 따라서, 전체 시스템의 용량 (동시 사용자수)나 기능 (서비스 수)를 아키텍쳐의 변화 없이 쉽게 확장할 수 있어야 한다.

3.유연성

비즈니스 변화에 대해서 유연하게 대처할 수 있어야 한다.

 

Conceptual Architecture

위의 세가지 Principal을 기반으로 설계된 Conceptual Architecture는 다음과 같다.


Application Grid

애플리케이션 그리드의 개념은 여러 개의 하드웨어를 모아서 비즈니스 로직을 제공하는 단일된 형태의 애플리케이션 집합체이다. 외부에서 보기에는 하나의 애플리케이션 집합체로 보이며 단일 접속점 (End Point)을 가지지만 실제로 내부에는 여러 개의 애플리케이션이 분리된 하드웨어에 분리된 형태로 배포되어 있다.

 하드웨어 가상화 개념을 응용하여 그리드 내부에서 업무의 비중과 중요도에 따라서 하드웨어 자원을 동적으로 재 배정하여 자원 사용의 효율성을 극대화 한다.

 새로운 기능이 추가될 때 마다 컴포넌트를 애플리케이션 그리드에 꼽는 (PLUG IN)하는 개념으로 비즈니스 컴포넌트를 추가할 수 있으며, 애플리케이션 그리드의 Infrastructure에는 그리드를 관리하기 위한 운영,관리,모니터링 기능(이하 OAM) 이 구현되어 있기 때문에, 개발자는 비즈니스 로직에만 집중하여 개발한후 그리드에 배포하면 OAM은 Infrastructure에 의해서 관리된다.

 

애플리케이션 그리드 아키텍쳐는 계층에 따라서 하드웨어/미들웨어(웹로직)/웹서버 3개의 계층으로 나뉘어서 분리된다.

 

(1)   하드웨어 아키텍쳐

하드웨어는 IBM AIX 중에 가상화를 지원하는 하드웨어를 사용한다. 가상화는 하나의 하드웨어내에 있는 여러개의 CPU와 메모리를 분할하여 사용할 수 있는 기능이다. 즉 하나의 하드웨어 자원을 조각으로 나누어서 업무별로 할당이 가능하다.

 

하드웨어 아키텍쳐 구성시에, 작은 하드웨어 여러 개를 사용하는 것보다, 가상화가 가능한 큰 하드웨어를 사용하는 것이 유리하다. 일반적인 국내 차세대 시스템의 경우 오픈후에, 안정화 기간을 거치면 통상적으로 CPU 평균 사용률이 40% 이하로 제대로 구성된 아키텍쳐에서는 20~30%대로 사용되는 경우가 많다. 반대로 부하가 몰리는 서버의 경우 CPU 사용률이 70~80%까지 육박하는 경우도 있다. 이러한 경우, CPU나 메모리 자원에 대한 효율적인 분할을 하기 위해서는 하드웨어를 물리적으로 옮겨서 새로 소프트웨어 시스템을 설치해야 하는데, 이 과정은 많은 시간과 검증 작업을 요구하며 또한 소프트웨어 라이센스 측면에서 문제를 유발할 수 있다. (하드웨어 추가는 소프트웨어 라이센스의 추가 구매를 의미한다.)

 이런 비효율성은 반대로 가상화를 지원하는 하드웨어를 사용했을 때 쉽게 해결된다.  업무의 부하량에 따라서 동적으로 CPU 자원을 재할당 하여 업무 부하에 적절하게 대응할 수 있고 CPU 재할당의 경우에도 별도의 하드웨어 작업(CPU를 빼서 다른 서버에 옮기는등의)이 없이 소프트웨어적인 설정만으로도 가능하기 때문에, 변경에 대한 영향도를 최소화 할 수 있다.

 

(2)   웹로직 구성 아키텍쳐

웹로직 구성상에 있어서는 다음과 같은 원칙을 따른다.

업무당 하나의 웹로직 도메인을 사용하며,하나의 도메인은 여러 개의 클러스터를 가질 수 있으며, 각 클러스터는 여러 개의 Managed Server로 구성된다. 각 Managed Server에는 1개 이상의 업무 애플리케이션이 배포될 수 있다.

 

1) 서버 분리를 통한 장애 전파성 제거

자바 기반의 장애 특성은 턱시도와 같은 TP Monitor와 다르게 모든 업무가 하나의 프로세스에서 돌아가는 특징을 가지고 있다. 이로 인해서 장애가 발생할 경우, 같은 프로세스에서 돌고 있는 다른 업무에도 영향을 줄 수 있다. (TP Monitor의 경우 업무별-SERVER로 프로세스가 나뉘어져서 기동되기 때문에 장애가 다른 업무에 전파되지 않고 국지화될 수 있는 장점을 가지고 있다.) 이와 같은 문제를 해결하기 위해서 WAS에서 여러가지 Work Manager나 Thread Pool 분리와 같은 여러가지 기능을 제공하는데, 이 역시도, 메모리 과사용이나 CPU 과 사용등에 대한 문제에서는 자유로울 수 없다.

 

가장 올바른 아키텍쳐 설계 방안은 TP Monitor와 같은 원리로, 업무별로 Manager Server를 분리하여 장애시 타 업무에 대한 장애 전파성을 제거하는 것이다.

 

2) 관리 포인트 증가에 대한 해결 방법

Managed Server를 업무별로 분할하여 운영할 경우, 그 만큼 많은 Managed Server가 운영되게 되고, 이는 관리 포인트의 증가로 귀결된다. 이런 관리상의 문제점을 해결하기 위해서, 웹로직을 클러스터링 기능을 사용할 수 있다. 클러스터링에서는 여러 개의 Managed Server가 있더라도 클러스터 단위로 configuration을 반영할 수 있는 기능이 있기 때문에, Managed Server의 수가 증가하더라도 실제로는 클러스터의 단위로 관리를 할 수 있기 때문에 관리에서 오는 복잡도를 감소 시킬 수 있다.

 

3) 클라이언트를 통한 상태 관리

업무별로 Managed Server를 나누는 경우 발생하는 문제점중의 하나가 Managed Server간에 Session이나 상태 정보가 공유가 안되는 문제점을 가지고 있다. 그러나 고객의 아키텍쳐 설계의 Assumption은 윈도우 클라이언트 기반의 Rich Client를 사용하기 때문에, 상태나 사용자 정보를 클라이언트에서 관리하도록 설계하여 서버간의 정보 공유를 서버에서 클라이언트로 이관함으로써 이를 극복할 수 있다.

 

(3)   웹서버 아키텍쳐

1) Endpoint에 대한 Location Transparency 의 제공

본 아키텍쳐에서 웹서버는 Application Grid로의 End point를 단일화 시켜주는 중요한 역할을 한다. Grid내의 여러 개의 Managed Server의 주소로 클라이언트가 직접 접근하는 것이 아니라 업무별로 배정된, 웹서버라는 단일 접속점을 통해서 Grid내의 Managed Server로 접근할 수 있게 해준다. (이는 Grid내의 Managed Server의 수가 증가하거나 감소하더라도, 접속점에 대한 변경을 없게 하여 Location Transparency를 보장할 수 있게 한다.)

 

2) 유연한 배포 구조의 제공

본 아키텍쳐에서의 웹서버 구성은 하나의 업무에 대해서 두 이상의 웹서버와 하나의 L4를 사용하도록 구성되어 있는데, 이는 애플리케이션의 배포의 용이성을 제공하기 위해서이다.

WAS의 기능에 상관없이 애플리케이션 개발과정상의 실수에 의해서 REDEPLOY 과정에 많은 문제를 일으킬 수 있는데, 이로 인해서 가장 좋은 REDEPLOY 방법은 DEPLOY후 RESTART하는 것이 가장 좋은 방법이다. 그러나 이 경우 해당 업무가 일시적으로 정지될 수 있는 위험도를 가지고 있기 때문에, 이 다운 타임을 최소화할 수 있는 아키텍쳐 설계가 필요하다.

2개의 웹서버중 하나의 웹서버를 다운 시키면 L4에 의해서 반대쪽 웹서버로만 부하가 가게 되고, 웹서버가 다운 되었기 때문에, 그에 연결된 Managed Server들은 사용자로부터 REQUEST를 받지 않는 상태가 된다. 이 상태에서 애플리케이션을 재배포한후 서버들을 재기동 시킨후, 반대족 웹서버도 번갈아서 같은 방식으로 재기동을 하게 되면 운영중에도 가장 안전한 방법으로 업무에 대한 정지 없이 재배포가 가능하게 된다.

 

Application Grid OAM (Operation, Administration, Monitoring)

OAM 기능은 애플리케이션 그리드에 대한 운영,관리, 모니터링 기능을 제공하는 인프라이다. 비록 고객의 요구 사항에서는 웹로직만으로 구성하는 것을 요청했으나, 아키텍쳐의 완성도를 위해서 OAM 모듈에 대한 기능을 추가하였다.

 

Configuration 관리

고객의 요구사항중의 하나는 100개이상의 웹로직 인스턴스를 운영 및 관리해야 한다. 비록 클러스터링을 통해서 관리 포인트를 줄일 수 있는 형태로 설계했지만, 많은 인스턴스에 대한 Configuration 관리는 매우 도전적인 과제중의 하나이다.

Oracle 제품중에 ACC (Application Configuration Console)은 단일 Console을 통해서 여러 Managed 서버와 도메인 그리고 클러스터에 대한 관리를 가능하게 해주며, Configuration에 대한 이력관리등을 통해서 애플리케이션 그리드에 대한 하나의 관리 기능을 제공한다.

 

시스템 상태 모니터링

전체 그리드에서 시스템의 상태를 일목요연하게 볼 수 있는 기능이 필요하다. CPU 사용률, 애플리케이션 관점에서의 병목 구간, Thread 상태, 응답 시간등에 대한 모니터링 기능이 필요한데, 이는 APM (Application Performance Monitoring)을 통해서 가능하다.

 

업무별 상태 모니터링

시스템 상태 모니터링이 애플리케이션 관점(기술 관점)이라면 업무별 상태 모니터링은 비즈니스 관점에서 애플리케이션 그리드를 모니터링 하는 것이다.

 업무별 응답시간, 사용률, 장애율등을 Oracle BAM (Business Activity Monitoring)을 이용하여 그래프로 가시화 하여, 업무의 운용 상황을 한눈에 파악할 수 있도록 한다.

 

Features

Application Grid 아키텍쳐의 특징을 다시한번 정리해보면 다음과 같다.

 

장애 전파 방지 

Ÿ          Managed Server 분리를 통한 장애 전파 방지

업무별로 Managed Server를 분리하여, Dead Lock이나 Lock 경합으로 인한 장애 전파 또는 메모리 과사용으로 인하여 다른 업무에 영향을 주는 요인을 제거하였다.

Ÿ          하드웨어 자원 분리를 통한 장애 전파 방지

기존 WAS 아키텍쳐에서는 JAVA 프로세스를 분리하더라도, 실제 CPU나 메모리등의 하드웨어 자원을 공유해왔기 때문에, 한 프로세스가 CPU를 과점유하기 시작하면 정상적인 다른 프로세스에게도 영향을 줬다.

그러나 이 아키텍쳐에서는 업무에 따라서 하드웨어 자원을 분리하여 할당하기 때문에,특정 업무가 CPU를 과점유한다하더라도, 다른 업무용으로 배정된 CPU 자원을 사용할 수 없기 때문에, 하드웨어 자원 점유에 의한 장애 전파를 방지한다.

유연하고 최적화된 하드웨어 리소스 운영

Ÿ          Managed Server의 수 조정을 통한 자원 배분

시스템의 사용량이 늘어날 때, 사용량이 늘어난 업무에만 Managed Server의 수를 늘려서 하드웨어 자원의 사용을 최적화 할 수 있다. 반대로 사용량이 적은 업무의 경우 Managed Server의 수를 줄여서 잉여된 자원을 다른 업무에 배정하여 전체 Application Grid의 하드웨어 사용 효율성을 극대화 한다.

Ÿ          가상화를 통한 CPU 및 메모리에 대한 유연한 배분

해당 업무에 메모리 사용량이 높거나 CPU 사용량이 높을때는 하드웨어 가상화 기능을 통해서

메모리 크기 한계 극복

Ÿ          업무별 분리를 통한 메모리 사용성의 극대화

자바 애플리케이션은 구조상의 한계상 통상적으로 1.5GB의 메모리만이 사용가능하다. (최대 3G). 그래서 사용자 수가 늘어나는 경우에는 전체 부하를 여러 개의 인스턴스로 분산 시켜서 메모리 사용량을 낮추어야 하는데, 이 아키텍쳐에서는 간단하게 Managed Server의 수만 늘려주는 것만으로 메모리에 대한 부하를 손쉽게 분산 시킨다.

       참고 : Managed Server 분리에도 불구하고, 더 많은 양의 메모리가 필요한 경우에는 Coherence Data Grid를 이용하여, 메모리 확장을 고려할 수 있다.

 

확장성 

Ÿ          웹서버를 이용한 Location Transparency의 제공

업무의 종류나 부하량 또는 사용자가 증가하는 것에 상관없이, 새로운 업무는 Application Grid에 추가로 배포될 수 있으며, 시스템의 용량도 하드웨어 증설만으로 큰 설정 변경 없이 손쉽게 증설이 가능하다. 시스템이 확장되더라도 Grid 밖에서 보기에는 동일한 End Point를 통해서 접근하는 것이기 때문에, 확장이 기존의 애플리케이션에 영향을 주지 않는다.

애플리케이션 배포의 유연성 

Ÿ          웹서버와 L4를 이용한 무정지 Clean redeploy 제공

앞서 설명한 바와 같이 L4와 2개 이상의 웹서버 구성을 통해서 가장 안전한 방법 (RESTART)으로 운영중 무정지 재배포를 지원한다.

 

Oracle ALM 솔루션

ALM | 2009.07.24 10:39 | Posted by 조대협
그토록 찾았는데 몰랐다. 오라클에도 ALM 솔루션이 있는지는
형상 관리와 TASK 관리는 되는것 같은데, JDeveloper 기반이네.
http://www.oracle.com/technology/obe/obe11jdev/bulldog/gettingstartedtpc/getting_started_tpc.htm

'ALM' 카테고리의 다른 글

Vagrant를 이용한 개발환경 관리(간단한 VM관리)  (1) 2013.10.24
관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03
IBM에서 ALM E-Book을 무료 배포합니다.  (0) 2009.06.30
ALM의 괴리.  (3) 2009.05.14

The RESTful Soa Datagrid with Oracle
View more documents from Emiliano Pecis.


Coherence를 캐슁으로 실제 구축한것이 흥미롭다.
다음 아키텍쳐 구축할때 참고할것
@ page import="java.util.*" %> @ page import="javax.naming.*" %> @ page import="com.oracle.bpel.client.Locator" %> @ page import="com.oracle.bpel.client.NormalizedMessage" %> @ page import="com.oracle.bpel.client.dispatch.IDeliveryService" %> try{ String title="CALLING FROM JSP"; String xml = "<ns1:DBSensorNotifierProcessRequest xmlns:ns1=\"http://xmlns.oracle.com/DBSensorNotifier\">" + "<ns1:input>"+title+"</ns1:input>" +"</ns1:DBSensorNotifierProcessRequest>"; Hashtable jndi = new Hashtable(); // assign RMI port which can be found in OAS console jndi.put(Context.PROVIDER_URL, "ormi://localhost:12401/orabpel"); jndi.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory"); jndi.put(Context.SECURITY_PRINCIPAL, "oc4jadmin"); jndi.put(Context.SECURITY_CREDENTIALS, "asdf1234"); jndi.put("dedicated.connection", "true"); // domain id and domain password Locator locator = new Locator("default","bpel",jndi); IDeliveryService ds = (IDeliveryService)locator.lookupService(IDeliveryService.SERVICE_NAME); NormalizedMessage nm = new NormalizedMessage(); nm.addPart("payload",xml); ds.post("DBSensorNotifier","initiate",nm); out.println("SEND"); }catch(Exception e){ e.printStackTrace(); throw e; }

먹보 오라클이 썬을 인수한답니다.

사는 이야기 | 2009.04.20 23:08 | Posted by 조대협
얼마전에 IBM이 Sun 인수를 시도했다가 무산되었는데.
지금 온라인을 보니까는 Oracle이 Sun을 인수한다는 군요.
이제 오라클은 BEA를 인수함으로써 데이타 베이스 + 미들웨어 시장에 이어서
Sun 인수로 인해서 자바 기술의 종가 + 하드웨어 까지 갖추게 되었습니다.
이제 IT 시장은 IBM과 Oracle이 2강 구도가 되겠군요.
그나저나 엔터프라이즈 시장에서는 옮길 회사가 또 없어졌습니다.

아래는 Sun 인수에 대한 뉴스 링크입니다. http://www.bloomberg.com/apps/news?pid=20601082&sid=awfGnLxcC8bk

TAG Oracle, Sun, 인수

관심이 가는 오라클 제품들

아키텍쳐 /SOA | 2008.10.15 13:48 | Posted by 조대협
요즘 들어 오라클에 들어와서 제품들을 보면서 관심들이 가는 제품들이 있는데..

1. ODI -  ETL 같은 솔루션인데, 보다 Near realtime에다가 ETL과 접근 방법이 약간 틀려서 EL-T라고 하는데 성능이나 사용성이 좋은듯 하다. 그간 ETL 솔루션이 없어서 고생좀 했는데. 의외로 좋은 아이템이 될듯.
2. ORACLE BPEL PM - WLI 와 AL BPM의 중간 계보쯤을 이어주는 제품. Human Oritented BPM보다 System Oriented BPM에 가까운데. WLI의 족보를 이어서 선전(?)을 하지 않을까/
3. Coherence - 이미 아는 사람들은 다 아는 오라클이 인수한 메모리 캐슁 제품... 꼭 한번 써보리라!!
4. ALER - 시간이 없다는 핑계로 오랫동안 묻어두고 안보고 있었는데... 주인을 가리는 칼이라 해야하나? 쓰는 사람이 잘쓴다면 의외로 엄청난 무기가 될 수 있는 SOA Asset 관리 도구...

하나하나 새로운 기술이나 제품을 알아간다는것이 즐거운게.. 나는 어쩔 수 없는 엔지니어일까?

'아키텍쳐  > SOA' 카테고리의 다른 글

Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04