Oracle WebLogic Server 12c와 Oracle Database 12c는 상호 간의 지능적인 통합을 통해 더욱 향상된 성능

과 가용성, 유연한 확장성을 제공한다. 지난 7월 새롭게

출시된 WebLogic Server 12c의 최신 버전에서는 클라

우드 환경에 적합하게 설계된 Oracle Database 12c의

장점을 모두 이용할 수 있는 기능들을 탑재하여 데이터

베이스와 유기적으로 연결되게 하고 있다. 본고에서는

WebLogic Server 12c에서 제공하는 데이터베이스 연결

성과 관련된 신규 기능들을 하나씩 살펴볼 것이다.

오늘날 모바일 사용자의 증가와 소셜 미디어 또는 인터

넷 기반 디바이스들의 증가로 과거 어느 때 보다 더 많

은 트랜잭션과 더 많은 데이터를 처리하여야 하는 IT 환

경이 되었다. 미들티어인 애플리케이션 서버는 더 많은

데이터베이스 자원을 필요로 하게 되고, 더 많은 트랜잭

션을 처리하기 위해 유연한 확장성이 요구되고 있다.

애플리케이션과 데이터베이스 서버는 사용자 요청을

실패 없이 신속하게 처리하기 위해 유기적으로 연동되

어야 한다. 애플리케이션 서버가 데이터베이스의 상황

변화에 지능적으로 반응할 수 없는 환경에서는 데이터

베이스가 비정상으로 다운되는 장애 상황이 발생할 경

우 애플리케이션은 데이터베이스가 다시 응답하기 위한

타임아웃까지 수분 또는 무한정 기다릴 수 있고, 애플리

케이션이 매우 부하가 높은 데이터베이스에 요청을 보

내게 된다면 당연히 응답은 느려지게 되며, 이는 애플리

케이션의 속도에 영향을 미치게 된다. 확장성에도 제약

을 받는다. 데이터베이스와의 1:1 연결을 하고 있는 애

플리케이션의 확장이 필요하게 된다면, 이는 곧 데이터

베이스 노드의 증설을 필요로 하고 비용과 자원의 압박

을 받게 될 것이다. 애플리케이션 서버인 미들웨어와 데

이터베이스 간의 지능적인 통합이 없다면 DR(Disaster

Recovery) 계획에도 어려움을 겪게 될 것이고 궁극적으

로 더 많은 위험에 노출되게 된다.

애플리케이션 서버와 데이터베이스와의 지능적인 통합

기술은 사용자 요청을 데이터베이스의 부하나 가용성

에 근거하여 최적의 데이터베이스로 보내준다. 따라서

성능과 자원 활용률이 최적화되고, 애플리케이션 서버

나 데이터베이스가 서로 간섭 없이 동적 확장이 가능해

지고, 자동화된 관리와 효율적인 DR 계획을 세울 수 있

게 도와준다.

Oracle WebLogic Server 12c와 Oracle Database 12c는

상호 간의 지능적인 통합을 통해 앞서 설명한 문제점

을 해결하는 완벽하고 유연한 솔루션을 제공한다. 솔

루션에서 제공하는 각각의 세부적인 내용들을 이해하

TREND 04

ORA

CLE KOREA

MA

GA

ZINE

Trend더

욱 강

력해

지고

향상

된 W

ebLogic Server 12 c 와 O

racle Database 12 c 와의

통합

20Autum

n 2013

더욱 강력해지고 향상된 WebLogic Server 12c와 Oracle Database 12c와의 통합 -왜 애플리케이션 서버와 데이터베이스 간의 지능적인 통합이 필요한가?

저자_ 이미남 컨설턴트, 한국오라클 Oracle Fusion Middleware(mee-nam.lee@oracle.com)

가용성

Availability

성능

Performance

확장성

Scalability

관리성

Management

재난 복구

Disaster Recovery

일반적인 문제점 요청이 차단됨 느린 데이터

베이스 1:1 연결 재 연결 필요

중요 비즈니스

업무

바람직한 해결책 가용한 DB 노드

로 요청 이동

DB 부하나 자원

활용률에 따른

동적 부하 분산

동적 연결 또는

연결 공유 자동화 자동 복제

<표 1> 일반적인 데이터베이스 연결 문제에 대응하는 바람직한 해결방안

ORA

CLE KOREA

MA

GA

ZINE

Trend더

욱 강

력해

지고

향상

된 W

ebLogic Server 12 c 와 O

racle Database 12 c 와의

통합

21Autum

n 2013

기 위해서는 먼저 WebLogic Server에서 제공하는 Active

GridLink기능을 이해할 필요가 있다.

Active GridLink

Active GridLink는 WebLogic Server와 Oracle RAC 클

러스터 간의 연결성을 제공하는 단일 데이터소스이다.

WebLogic Server는 SCAN(Single Client Access Name)

이라는 단일 연결 정보를 통해 Oracle RAC 클러스터와

연결한다. 단일 커넥션 풀 내의 커넥션들은 ONS(Oracle

Notification Service)를 통해 전달된 Load Balancing

Advisory 이벤트를 통해서 RAC 노드 간으로 분산되

고, 데이터베이스의 변화되는 부하나 가용성에 따라 커

넥션 비율이 동적으로 조절된다. 즉 상대적으로 한가한

RAC 노드에서 더 많은 데이터베이스 요청이 수행되도

록 동적으로 커넥션을 관리하는 것이다.

Active GridLink는 데이터베이스의 Up/Down 이벤트

를 통지 받기 때문에 데이터베이스 다운 시 즉각적인 커

넥션 페일오버를 수행한다. Active GridLink를 사용하

면 RAC 노드의 재기동시 자동적으로 커넥션을 분산하

고, RAC 노드 증설 시에도 자동으로 신규 추가된 노드

로 커넥션이 분배되기 때문에, 별도의 커넥션 풀 구성

변경이나 WebLogic Server를 재시작할 필요 없이 RAC

노드 수 변화에 동적으로 반응할 수 있게 된다.

Application Continuity

일반적으로 데이터베이스 장애나 다운은 최종 사용자

에게 큰 영향을 미치고 사용자의 재입력을 필요로 하거

나 애플리케이션 서버의 재시작을 필요로 하기도 한다.

JDBC Replay라고도 부르는 Application Continuity 기

능은 사용자가 로컬 트랜잭션을 수행하고 있을 때, 예

측하지 못한 에러가 발생한다면, 데이터베이스가 트랜

잭션의 모든 단계를 재실행(replay)하도록 하여, 사용자

요청을 오류 없이 처리하도록 하는 기능이다. 이 기능은

과거에는 read-only 트랜잭션에서만 지원되었던 것이

Oracle Database 12c에서 read/write를 모두 지원하게 되

었다.

고객이 온라인 스토어에서 상품을 구매하는 동안 데

이터베이스가 다운되는 시나리오를 생각해 보자. 데

이터베이스 오류가 데이터소스 계층에서 감지되고

Application Continuity 기능이 사용되고 있다면, 애플

리케이션 서버는 가용한 데이터베이스 노드로 새로운

연결을 자동으로 생성하고 트랜잭션 재실행(replay)을

수행한 후 애플리케이션에게 정상적인 응답을 보내게

된다. 이런 작업은 애플리케이션에 투명하게 이루어지

고 사용자는 성공적으로 구매를 완료할 수 있게 된다.

Database Resident Connection Pooling(DRCP)

애플리케이션 서버는 전형적으로 다수의 쓰레드를 가

지게 되고 다수의 데이터베이스 커넥션을 사용한다. 모

든 애플리케이션 서버가 각자의 전용 데이터베이스 커

넥션을 가지고 있게 되면 애플리케이션 서버 단의 확장

성은 데이터베이스 자원 한계에 의해 제약될 것이다.

다수의 데이터베이스 세션이 매우 짧은 데이터베이스

요청을 수행하는 환경을 가정해 보자. 이 데이터베이스

요청들은 세션 상태에 의존하지 않는다. 대규모 사용

자 환경이라면 수천의 데이터베이스 커넥션이 존재하

게 되지만 대부분의 커넥션은 유휴할 것이다. 그럼에도

불구하고 전용 데이터베이스 커넥션을 사용하는 환경

이라면 사용자나 애플리케이션이 더 추가되어야 할 때

불필요하게 데이터베이스의 증설이 필요할 수도 있다.

Database Resident Connection Pooling(DRCP)은 이

와 같이 대부분의 데이터베이스 커넥션이 항상 사용되

고 있지 않은 환경에 적용되면 애플리케이션 서버들 간

에 데이터베이스 커넥션을 공유하도록 해주어 더 높은

확장성을 실현할 수 있게 해준다. 애플리케이션은 기존

의 방식과 동일하게 데이터소스를 통해 커넥션을 얻어

<그림 1> Application Continuity 동작 방식

❶ 사용자가 애플리케이션 서버에 구매 요청을 보냄

❷ 애플리케이션 서버가 가용한 데이터베이스로 구

매 요청을 보내고 커밋을 요청했으나 데이터베이

스가 커밋을 완료하지 못하고 실패함

❸ 애플리케이션 서버에서 데이터베이스의 장애를

감지함

❹ 애플리케이션 서버는 가용한 데이터베이스 노드

로 새로운 연결을 생성하고 JDBC Replay를 통해

해당 구매 요청이 재실행(replay) 되어야 하는지

체크 후에 재실행되어야 할 경우 트랜잭션을 재실

행함

❺ 사용자는 데이터베이스 장애 상황을 인지하지 못

하고 구매 요청에 대한 성공 결과를 받음

ORA

CLE KOREA

MA

GA

ZINE

Trend더

욱 강

력해

지고

향상

된 W

ebLogic Server 12 c 와 O

racle Database 12 c 와의

통합

22

오게 되고, 내부적으로는 물리적인 커넥션을 얻기 위한

attach/detach가 수행된다.

DRCP는 Oracle Database 11g부터 지원되었고, 12c에서

JDBC를 통해서도 데이터베이스 커넥션을 공유할 수

있게 되었다.

Multi-Tenant Database

멀티 태넌트 데이터베이스는 하나의 Oracle Database 소

프트웨어 설치본 또는 하나의 인스턴스 환경에서 다수

의 데이터베이스가 동작되게 하는 것이고 이를 “멀티 태

넌시”라고 한다.

오늘날 많은 조직들이 다수의 데이터베이스를 하나의

단일 서버 상에 구동하거나, 다수의 애플리케이션을 지

원하기 위한 매우 커다란 데이터베이스를 구축하려 하

지만 이런 접근 방법들은 많은 경우 그다지 효과적이지

않았다.

하나의 단일 서버에서 100개의 데이터베이스를 구동해

야 한다면 서버는 매우 빈번하고 신속하게 데이터베이

스 간을 스위칭 해야 하고 이는 매우 큰 오버헤드를 야

기할 것이다. 또한 각각의 데이터베이스는 다수의 백그

라운드 프로세스를 가지는데 이런 모든 프로세스를 하

나의 집합으로 줄일 수 있다면 많은 서버 자원을 절약하

게 될 것이다.

다수의 서로 다른 용도의 데이터를 하나의 데이터베이

스로 통합하려는 시도는 여러 가지 어려움에 부딪치게

된다. 서로 다른 사용 패턴을 요구하는 데이터베이스의

접근 제어와 테이블 네이밍 충돌 해결, 복잡한 권한 설

정 등은 많은 시간을 소요하고 오류가 많이 일어날 수

있는 작업이었다.

멀티 태넌트 데이터베이스는 이러한 문제점을 해결할

수 있고 사용자 데이터베이스를 분리함으로써 네임스

페이스도 완전히 독립되어 네임 중복은 더 이상 문제가

아니다. 멀티 태넌트 데이터베이스는 이전의 시도들에

서 발생할 수 있는 문제점들을 해결할 뿐만 아니라 관리

및 자원 활용측면에서도 많은 효율성을 제공한다. 멀티

태넌트 데이터베이스에 대한 더 자세한 내용은 Oracle

Database 12c 자료를 참조하기 바란다.

WebLogic Server에서는 일반적인 데이터베이스 연결 방

식과 같이 각각의 태넌트 데이터베이스에 연결되는 데

이터소스를 따로 구성하여 사용하거나, 모든 태넌트 데

이터베이스에 연결될 수 있는 단일 데이터소스를 구성

하고 동적으로 커넥션을 전환하여 원하는 태넌트 데이

터베이스 커넥션을 얻도록 설정할 수 있다. 애플리케이

션에서는 특정 태넌트 데이터베이스에 연결된 커넥션

을 요청하고, ConnectionLabelingCallback을 통해 애플

리케이션에서 원하는 커넥션을 전달한다. 애플리케이

션에서는 단일 데이터소스를 이용하면서도 여러 태넌

트 데이터베이스 요청을 수행하는 “멀티 태넌시(multi

tenancy)” 환경 구성이 가능해 진다.

Disaster Recovery (DR)

Oracle WebLogic Server와 Oracle Data Guard를 사용하

면 운영 사이트와 지리적으로 멀리 떨어진 지역에 DR 사이트를 구축하여 데이터를 보호할 수 있다. DR 사이

트는 일반적으로 운영 사이트와 비교했을 때 비슷하거

나 적은 서비스와 리소스를 가지는 경우가 많다. 애플리

Autumn 2013

<그림 3> 멀티 태넌트 데이터베이스 간의 동적 커넥션 전환

❶ 애플리케이션에서 단일 데이터소스를 통해 태넌

트 데이터베이스 MDB5에 대한 커넥션을 요청함

❷ 데이터소스에 등록된 ConnectionLabeling

Callback에서 MDB5에 연결된 커넥션을 찾음(커

넥션이 발견되면 커넥션을 애플리케이션으로 바

로 리턴함)

❸ MDB5 커넥션이 존재하지 않으면 “ALTER

SESSION SET CONTAINER” 구문을 수행하여 동

적으로 커넥션을 전환함

❹ MDB5 커넥션이 전달됨

❺ 애플리케이션에 MDB5 커넥션이 전달됨

<그림 2> DRCP를 통한 데이터베이스 커넥션 공유

ORA

CLE KOREA

MA

GA

ZINE

Trend더

욱 강

력해

지고

향상

된 W

ebLogic Server 12 c 와 O

racle Database 12 c 와의

통합

23Autum

n 2013

케이션 데이터, 메타 데이터, 구성 데이터, 보안 데이터

를 포함한 모든 데이터가 DR 사이트에 복제되지만, DR

사이트는 일반적으로 수동형 모드로 구성되므로 운영

사이트가 가용하지 않을 때 동작한다. 이런 구성은 주로

Read Only이고 Write/Update는 지원되지 않는다.

다수의 데이터베이스에서 서비스 되도록 구성되는

Global Service를 사용하게 되면 분산된 데이터베이스

클라우드 내에서 데이터베이스들의 워크로드에 따른

부하 분산 및 페일오버가 자동화될 수 있다.

Read-Only로 구성된 Global Service에 고부하가 발생

하면, 해당 서비스가 다른 지역(region)에서 가용해지

고 Global Data Service(GDS) 프레임워크가 WebLogic

Server의 Active GridLink로 FAN(Fast Application

Notification) 이벤트를 통해 통지를 보낸다. Active

GridLink는 통지된 이벤트를 기반으로 다른 지역에 있

는 서비스에 커넥션을 연결하여 요청을 분산하게 된다.

Read-Write 서비스는 로드 발란싱 될 수 없고 주요

(primary) 지역에서만 서비스될 수 있다.

그러나 데이터베이스 단절이 발생하면 Global Data

Service 프레임워크가 Active GridLink에 통지를 보내

고 해당 서비스는 다른 지역에서 서비스가 이루어지고

Active GridLink는 다른 지역의 서비스로 커넥션을 연

결하여 서비스가 정상적으로 수행되게 한다. 데이터베

이스의 단절 상황에서도 WebLogic Server의 재시작이

필요 없고 비즈니스 지속성이 유지된다.

Oracle WebLogic과 Oracle Database와의 완벽한 통합

지금까지 기술된 Active GridLink, Application Continuity,

Database Resident Connection Pooling, Multi Tenant

Database, Global Service를 통해 애플리케이션 서버와 데

이터베이스의 지능적인 연결성이 어떤 가치를 제공해

줄 수 있는지 설명하였다.

요약하자면 데이터베이스는 주변의 상황 변화에 따른

관리 작업이 줄어들고, 구성 변경이 필요 없거나 단순

해지고, 자원 활용도가 높아짐에 따라 비용이 절감되

고, 더 효율적으로 데이터베이스 요청을 처리할 수 있

게 된다.

애플리케이션 서버는 데이터베이스와 독립적인 확장성

을 보장받을 수 있으며, 데이터베이스의 장애 시에도 정

상적으로 서비스를 지속시킬 수 있게 되고, 구성 변경이

나 서버 재시작 없이도 지역을 넘어선 데이터베이스의

페일오버가 가능해진다. 이 모든 것은 궁극적으로 최종

사용자에게 더 나은 성능의 더 나은 품질의 서비스를 제

공하는 기초가 되는 것이다.

이제 Oracle WebLogic Server 12c와 Oracle Database 12c의 통합 기능을 직접 경험해 보는 기회를 가져보는 것은

어떨까 한다.

<그림 4> Global Service와 Active GridLink를 통한 지역간 페일오버