전문가칼럼

DBMS, DB 구축 절차, 빅데이터 기술 칼럼, 사례연구 및 세미나 자료를 소개합니다.

e-비즈니스 완성을 위한 기반기술 (1) - e-비즈니스 위한 고가용성 DBMS 요건

전문가칼럼
DBMS별 분류
Oracle
작성자
dataonair
작성일
2002-11-01 00:00
조회
11860





e-비즈니스 위한 고가용성 DBMS 요건

sol200211004_01.jpg

김홍주
한국오라클 DB기술팀 컨설턴트



2001년 9월 11일 미국에서 테러가 발생했을 때 필자는 ‘전세계 금융, 무역의 심장부라 불리는 세계무역센터와 함께 방대한 데이터들이 잿더미 속에 묻히면 입주업체들의 업무들도 마비될 것이 아닌가’를 떠올렸다. 그 건물에는 세계 굴지의 기업들이 입주해 있었기 때문에 그 업무적 여파에 관해 귀추가 주목됐던 것은 누구도 부인할 수 없는 사실이다. 이와 관련, 3회에 걸쳐 테러와 같은 사태에서도 기업이 지식 자산을 보호할 수 있는 방안과 이를 위한 기술에 대해 소개한다.

현대사회는 이제 누구도 부인할 수 없는 정보화 시대에 들어와 있으며 장부나 전표로 관리하던 수기식 데이터는 더이상 의미 있게 존재하지 않는다. 기업간 거래데이터, 고객데이터, 과금 데이터, 기업내부 관리데이터 등 기업이 영업활동을 하거나 내부관리를 위해 필요로 하는 데이터들은 이제 데이터베이스를 근간으로 하는 컴퓨터시스템 속에 저장돼 있다.

그렇다면 기업 운영의 핵심이 돼버린 이들 데이터들은 과연 어떻게 효율적으로 보관할 것인가 또 어떠한 형태의 장애가 발생하더라도 데이터가 보존되고 정상적 업무를 유지할 수 있을 것인가에 관한 솔루션을 데이터베이스를 중심으로 기술한다.


시스템장애의 정의와 유형

‘무정지 핵심운영시스템(Mission Critical System)’이란 24시간 365일 정지하지 않는 것을 기본으로 하며 밤낮으로 운영되는 시스템을 통칭해 일컫는다. 이러한 대전제에 위해(危害)가 되는 요인을 우리는 ‘장애(Disaster)’라고 정의한다. 다시 말해 사회학적인 장애의 개념과 달리 IT업계에서 보는 관점의 장애는 다소 상이할 수 있다. 우선 IT입장에서의 장애를 정의해 본다.

△‘컴퓨터 운영의 붕괴로 조직의 정상적 기능이 파괴되는 비상사태’ NIST(1994).

△‘생명, 재산, 자산, 정상적인 운영능력에 대한 위험’ OWEN(1995).

IT 시스템의 재난에 대한 분류를 OWEN(1995)은 인간오류에 의한 재난, 의도적인 재난, 자연재난 등 세가지로 분류했다. OWEN은 네트워크 관점에서 재난복구를 ‘네트워크 운영 중단사태를 복구하는 과정’이라고 정의하기도 했다. 구체적으로 재난복구에는 생명, 재산, 자산의 보호, 사업운영능력 등의 복구가 포함된다. 또 Rosenbaum(1995)에 의하면 재난복구의 주요 목적으로 조직구성원 및 고객의 안전과 복지를 지키는 것, 기업의 자원과 자산 그리고 기존 운영 시스템을 재개시키는 것, 변화하는 사업목적과 운영에 대비하는 것 등을 제시한 바 있다.

간단히 말해서 정보시스템의 재난복구 목적은 실시간 정보보호를 추구하는 것이다. 즉, 정보의 비밀성, 무결성, 가용성, 인증성, 이용성 등을 확보하는 것이라 하겠다. 그렇다면 이러한 장애의 종류에는 무엇이 있을까.

IT 입장에서 장애라는 개념은 곧바로 시스템 다운타임과 연결돼 있다. 따라서 연간 다운타임의 양은 장애의 경중을 판가름하는 기준이 된다고 할 수 있다. 이러한 다운타임은 크게 예상치 못한 장애(Unplanned downtime)와 예상된 정지(Planned downtime)로 분류할 수 있다.

우선 예상치 못한 장애 측면에서 보면 또다시 하드웨어 서버의 장애, 데이터베이스의 장애, 운영조작의 실수로 인한 장애 등 세가지로 나눌 수 있으며 예상된 정지 측면에서 보면 CPU, 메모리, 스토리지의 증설 등 시스템의 유지보수 등 계획된 다운타임과 데이터베이스 측면에서 데이터들의 이동(migration)이나 재정렬(Reorganization)작업 등이 해당될 수 있다.

장애 유형별 발생통계를 살펴보면 하드웨어와 시스템 자체의 장애가 가장 많으며 그 뒤를 관리조작의 실수 등 기타 원인이 시스템장애를 유발한다. 따라서 이러한 유형별 장애를 완벽하게 대처할 수 있는 고가용성(High availability)이란 무엇이며, 이에 덧붙여 확장성 그리고 성능과는 어떠한 상호관계가 있는지 알아보고 각 유형별 장애를 대비한 솔루션을 소개한다.


고가용성(High availability)의 정의

‘One minute of system downtime can cost an organization anywhere from $2,500 to $10,000 per minute: The standish Group 2001.’ 스탠디시 그룹은 2001년 자료에서 1분의 시스템 장애는 분당 2천5백달러에서 많게는 1만 달러 이상의 비용이 소요된다고 했다. 포레스터 리서치에에 따르면 4~5시간 동안 장애로 온라인 트레이딩 시스템을 사용할 수 없게 될 경우 22%의 주가하락 및 약 7천만 달러의 손실을 감수해야 하며 통신, 항공사 등의 경우도 엄청난 규모의 금액을 손해 보게 된다.

이러한 정황들을 토대로 이미 많은 기업들은 무정지 시스템의 구축에 많은 관심을 갖고 있으며 발생되는 매출의 일부를 기업 시스템의 무정지 시스템화에 재투자하는 것에 인색하지 않다. <그림3>은 고가용성의 정도를 나타낼 수 있는 가용률별 연간 장애시간을 표현한 것이다.

스탠디시 그룹은 ‘99.9%의 가용률을 얻기 위해서도 기업은 연간 5백만달러 이상을 투자해야 한다’고 밝혔다. 어떤 기업이든지 자신의 시스템에 대해 100%의 고가용성을 보장받기를 원한다. 그러나 99.99%(four nine)도 연간 53분의 장애를 감수해야 하는 점을 볼 때 100% 고가용성 보장이란 그 투자비용과 솔루션의 적용에 있어서도 간단하지만은 않다. 즉, 각 유형별 시스템장애에 대처할 수 있는 솔루션을 모두 갖추는 것이 100%에 근접한 고가용성을 보장하는 것이라고 가정해 그 구현방안에 대해 기술적인 소개를 한다.

sol200211004_02.jpg

sol200211004_03.jpg

sol200211004_04.jpg


클러스터 디스크를 통한 병렬처리 아키텍처

일반적으로 병렬처리시스템을 소개하기 위해서는 클러스터링 기법을 이해해야 한다. 클러스터는 독립적인 컴퓨터 시스템들이 느슨하게 연결(Loosed Coupling)돼 하나의 시스템처럼 움직이는 것이다. 클라이언트는 클러스터를 하나의 안정적인 고성능 서버처럼 간주한다. 즉, 시스템 관리자도 클러스터를 단일 서버인 것처럼 보게 된다. 클러스터 기술은 이미 병렬 컴퓨터 기술의 표준개념으로 널리 활용되고 있다.

클러스터링은 디스크 공유 모델(shared disk model)과 비공유 모델(shared nothing model)로 구별될 수 있다. 우선 디스크 공유 모델이란 클러스터의 어떤 시스템에서 실행되고 있는 애플리케이션이라도 클러스터에 연결된 시스템의 모든 자원(예를 들어, 디스크)에 접속할 수 있다. 즉, 두 서버에 접속한 각각의 시스템 사용자가 동일한 데이터를 볼 필요가 있다면 데이터는 그 활용도에 따라 디스크에서 두 번 읽히거나, 한 시스템에서 다른 시스템으로 복제돼 활용될 수 있다.

두 개 이상의 서버에서 동시에 동일데이터를 접근하는 업무가 수행돼도 데이터베이스의 데이터는 무결성을 유지한 상태로 업무를 수행할 수 있다. 이를 위해서는 단일 비공유 모델 시스템에서와 같이 응용프로그램이 공유된 데이터에 대한 접속을 동기화 할 수 있어야 한다. 이것을 가능하게 해주는 것이 DLM

(Distributed Lock Manager)이다.

DLM은 클러스터 전체에서 자원에 대한 사용참조를 추적하고 이를 관리하기 위해 응용프로그램에 제공되는 서비스이다. 여러 시스템이 단일 자원을 참조하려고 한다면, 락 매니저가 잠재적인 충돌을 인식하고 해결할 것이다. 따라서 DLM 조정은 추가적인 메시지 트래픽 및 시스템에 관련된 연속적인 접속이 불가피 하므로 성능에 다소 영향을 줄 수 있으나 오라클의 병렬처리 서버인 오라클9i 리얼 애플리케이션 클러스터(RAC)는 캐시 퓨전(Cache fusion)이라는 고도의 기법을 활용해 거의 성능에 영향을 주지 않는 관리기법을 채택했다.

반면 비공유 모델이란 클러스터 내의 각각의 시스템이 클러스터의 자원의 부분집합을 소유하게 되는 구조를 의미한다. 한번에 한 시스템만이 특정 자원을 소유하고 접속할 수 있지만 에러 발생 시에는 동적으로 결정되는 또 다른 시스템이 그 자원의 소유권을 넘겨받는다. 이밖에도 클라이언트의 요청은 자원을 소유한 시스템에게로 자동적으로 우회된다.

그러나 이 구조는 확장성의 경우 데이터의 리파티션이 필요해 유연성이 떨어지며 고가용성 측면에서도 동적인 오너십의 전이에 따라 자원의 소유권이 결정되는 과정에서 불안정적일 수 있다. 따라서 필자는 완벽히 고가용성을 보장하며 유연한 확장성과 고성능을 보장할 수 있는 구조로서 디스코 공유 모델을 기반으로 하는 클러스터 병렬시스템을 제안한다.

<그림5>처럼 2개의 노드를 클러스터 시스템에 기반한 공유디스크에 연결시킨 후 이 공유디스크 영역 내에 데이터를 저장해 운영하게 되는 것이다. 물론 각각의 지역디스크에는 각자의 실행파일과 로그파일 들이 존재하게 되며 DBMS 인스턴스도 각각 존재해 노드별로 존재하는 CPU, 메모리 등 자원을 활용하게 된다. 이는 특정노드에 장애가 발생하더라도 상대 노드를 통해 업무를 수행할 수 있으며 사용자 프로세스도 자동적으로 살아있는 노드로 재접속 되게 함으로써 사용자들은 장애사실도 모르는 채 업무를 수행할 수 있게 해주는 구조이다. 이 병렬처리 시스템은 고가용성 외에도 대용량 데이터의 처리, 성능의 향상, 많은 사용자의 지원 등의 장점을 갖고 있다.

sol200211004_05.jpg

sol200211004_06.jpg


▲고가용성(High Availability)

우선 고가용성이라는 용어는 많은 하드웨어, 소프트웨어 업체들이 강조하며 나름대로의 장점을 갖는 제품 및 솔루션을 이미 판매하고 있다. 이러한 고가용성 솔루션들은 크게 분류해 클러스터에 연결된 서버의 수가 2대까지만 허용되는가 아니면 그 이상이 허용되는가에 따라 구분된다.

2대의 서버를 클러스터에 연결시킨 경우를 예를 들어 설명해 본다. 이 경우는 두 서버 모두를 정상 서비스운영에 동시 사용할 수 있느냐 아니면 특정서버는 장애를 대비해 대기 모드로 설정한 상태로 한쪽 서버만을 운영하느냐의 차이를 말하는 것이다. 전자의 경우 운영 중인 서버(Active)에 장애가 발생하면 클러스터를 통해 연결된 대기서버가 자동적으로 이를 감지해 테이크 오버(Take over)함으로써 정상적인 서비스를 대신해 수행해주는 구조로서 나름대로의 고가용성이 확보 될 수는 있으나 고가의 서버를 단지 대기용으로 놀리게 되는 단점과 4-nine(99.99%)이상의 고가용성을 요구하는 핵심 업무에는 부적합하다고 할 수 있다. 이는 테이크 오버(Take over)되는 과정에서 대기서버가 공유디스크, 네트워크 등 모든 하드웨어 자원과 연결되고 데이터베이스를 기동시키며 모든 애플리케이션 프로세스들을 요청해 정상서비스를 개시하기까지 상당한 시간이 소요되기 때문이다.

이에 따라 필자는 한쪽 서버가 더 이상 대기상태가 아닌 운영상태를 유지하는 소위 ‘Active-Active’ 형태의 클러스터 시스템에 관해 소개한다. 이러한 형태의 병렬 처리 시스템에서 각 노드(서버)들은 서로간에 독립된 시스템이기 때문에 2대 이상으로 연결될 수도 있으며 특정 노드에서의 장애나 충돌이 다른 노드에 영향을 주지 않으므로 지속적으로 서비스를 제공할 수 있다. 그러므로, 사용자 입장에서는 중단 없는 지속적인 서비스를 받을 수 있고, 서비스 제공자 입장에서는 고가용성을 보장할 수 있다.

▲대용량 데이터의 처리- 확장성

병렬처리의 개념은 많은 양의 데이터를 처리해야 할 경우 그 일을 수행할 하나의 커다란 프로그램을 여러 개의 작은 단위 프로그램으로 분할해 n개의 병렬로 구성된 서버에서 독립적으로 수행하게 함으로써 처리속도를 훨씬 향상시킬 수 있다. 따라서 처리시간이 과다하게 소요되는 업무를 병렬처리 방식으로 처리하게 된다면 일정시간 내에 더 많은 업무를 처리할 수 있게 돼 효율의 향상을 보장할 수 있다.

▲성능 향상

같은 논리로서 주어진 작업을 병렬 처리 방식으로 처리할 수 있기 때문에, 동일 작업의 응답 시간을 높일 수 있으며 특히 대량의 데이터를 대상으로 처리해야 하는 의사결정시스템(DSS)에서 효과적인 성능 향상을 기대할 수 있다. 그러나 OLTP(실시간 거래처리 시스템) 업무에서는 동기화의 오버헤드 등과 같은 부작용도 고려해야 하겠다.

▲많은 사용자의 지원

병렬처리시스템의 각 노드(서버)들은 독자적인 자원, 즉 CPU와 메모리, 그리고 로컬 하드디스크를 보유하고 있기 때문에 노드 수에 의한 사용자 수를 노드 수의 비율만큼 증대할 수 있으며, 필요 시 노드를 추가함으로써 지속적인 확장을 꾀할 수 있다.

하지만 효율적인 병렬 처리 시스템을 구현하기 위해서는 병렬 처리에 참여하는 노드들간의 동기화가 가장 중요한 문제이다. 사용되는 데이터의 일관성을 보장하기 위한 작업들이 필요하다는 것이다. 따라서 병렬 처리 시스템을 구현할 때 가능한 동기화 문제가 발생하지 않도록 설계하는 것이 바람직하며 이러한 동기화 문제(cache coherency)도 이제는 서버 메모리간(cache to cache)에서 직접 동기화를 보장하는 등 시스템에서 최적화시킴으로써 고 성능을 보장하게 해주는 솔루션이 나와 있으며 오라클9iRAC가 바로 그것이다.

효율적인 병렬처리시스템을 구현하기 위해서는 노드들간의 통신을 위한 높은 대역폭과 낮은 대기시간(latency)을 가지는 통신 채널(inter connect)이 필수적이라 할 수 있다.

sol200211004_07.jpg

▲오라클 9i 리얼 애플리케이션 클러스터

오라클9iRAC는 공유 디스크 구조의 병렬 데이터베이스 시스템이다. RAC는 캐시 퓨전이라는 새로운 공유 캐시 아키텍처를 제공해 기존의 공유 디스크 구조의 병렬 데이터베이스 시스템이 가지는 한계를 극복하고 뛰어난 확장성과 가용성 및 편리한 관리 기능을 제공한다.

공유 디스크 구조의 병렬 데이터베이스 시스템의 확장성과 성능 상의 가장 큰 문제점은 캐시 일관성(Cache Coherency) 처리 문제이다. RAC는 이러한 캐시 일관성 문제를 처리하기 위해 캐시 퓨전 아키텍처를 사용한다. 캐시 퓨전 아키텍처는 캐시 일관성을 위해 공유 캐시를 이용한다.

따라서 노드간 동기화를 위해 디스크 입출력을 사용할 필요가 없게 된다. 이러한 캐시 퓨전 아키텍처의 이점은 급속히 발달하고 있는 디스크 스토리지 및 노드간의 인터커넥트 기술을 통해 지원된다. 캐시 퓨전 아키텍처의 개념은 <그림 6>과 같다.

캐시 퓨전 아키텍처는 공유가 필요한 데이터 정보를 캐시 투 캐시의 기법으로 공유해 데이터의 일관성을 보장하게 하는 개념인 것이다. 이로써 고가용성뿐만 아니라 고성능, 확장성의 문제를 모두 만족시키는 것이 가능하게 됐다.

다음으로는 서버의 장애가 아닌 스토리지 부분의 장애가 발생될 경우의 고가용성 보장 솔루션을 알아하자.

sol200211004_08.jpg


스토리지 장애 대비한 DB 이중화 아키텍처

클러스터를 기반으로 한 공유디스크 병렬서버가 서버자체의 장애를 대비한 고가용성 확보 솔루션이었다면 지금부터 소개할 솔루션은 서버의 장애가 아니라 공유돼 있는 고유 디스크에 장애가 발생할 경우 해결방안이다. 이는 기본적으로 네트워크를 통해 연결돼 있는 복사본 데이터베이스시스템에 운영시스템의 변경 데이터를 실시간으로 전송해 줌으로써 운영시스템에 장애가 발생할 때 복사본 데이터베이스시스템이 즉각적으로 기동돼 본연의 서비스를 처리해주는 개념이다. 즉 클러스터에 연결된 공유 디스크를 통한 고가용성 솔루션과는 다른 완전 별개의 독립적 두 시스템을 운영측과 대기측으로 별도 구성하게 되는 것이다.

오라클은 과거 오라클 스탠바이 데이터베이스라고 명명했으나 오라클9i에서는 데이터 가드라는 제품명을 통해 보다 진보된 솔루션으로 새롭게 선보였다.

<그림 7>은 오라클9i 데이터 가드의 기본 수행원리를 보여준다.

정상 서비스 운영을 하는 프라이머리 데이터베이스(운영측)와 평상시 지속적인 데이터 피딩(로그 어플라이)을 통해 대기상태로 존재하는 스탠바이 데이터베이스(대기측) 그리고 이들 환경을 전반적으로 감시, 관리해주는 데이터 가드 매니저로 설명할 수 있다. 이 개념의 핵심 원리는 관계형 데이터베이스에서 일반적으로 사용하는 로그파일을 활용해 마치 자신의 백업 데이터를 자신의 장애복구를 위해 보관하듯 구축된 스탠바이 데이터베이스로 로그파일을 지속적으로 보내 줌으로써 데이터베이스의 실시간 복사본을 만들어놓는 것을 뜻한다.

스탠바이 데이터베이스는 하나이상 존재할 수 있다. 여러 개의 복사본을 운영할 수 있으므로 지리적으로 분산해 장애에 대비한 복사본 데이터베이스를 유지할 수 있다. 오라클9i 데이터 가드는 운영, 관리에 필요한 모든 전송, 복제, 페일 오버의 절차를 자동으로 수행하며 장애가 일어날 경우 데이터 손실을 막는 것을 보장해준다.


기타 고가용성을 위한 DBMS의 기능

예상치 못한 장애부분의 조작 실수(Human Error)와 예상된 시스템정지부분의 온라인 데이터 변경, 온라인 시스템유지보수 부분의 솔루션에 관해 알아본다.

▲오라클 9i 플래시백 질의

오라클9i에서는 과거의 특정한 시점의 데이터베이스 상태로 복귀해 그 시간까지 완료된 트랜잭션이 수행한 데이터를 얻을 수 있는 환경을 제공한다. 이러한 기능은 사용자의 실수로 인해 삭제되거나 갱신된 데이터를 복구하기 위한 인터페이스를 제공한다.

플래시백 질의는 자동 언두(Undo) 관리 기능을 이용하며, 언두(Undo) 정보는 시스템 레벨에서 명시된 보유 기간만큼 유지되므로 이 기간 동안 보관된 언두(Undo) 정보를 이용해 과거의 데이터를 얻을 수 있다. 한편 본 기능은 세션 레벨에서 이용할 수 있기 때문에 DBA 또는 일반 개발자들도 쉽게 이용할 수 있다. 손실된 데이터를 복구하기 위해 PL/SQL 커서를 이용해 데이터베이스를 복구 할 수도 있다.

<그림 8>의 예를 보면 사용자가 실수로 2시 13분에 3분전에 읽은 데이터를 삭제했고, 2분 뒤 삭제 이전의 데이터인 2시 10분 현재의 데이터를 플래시백 질의했으며, 다시 2분 뒤인 2시 17분에 정상 복구완료 했음을 확인할 수 있다. 이는 권한이 허용하는 한 DBA의 도움없이 개발자 또는 운영자가 스스로 처리할 수 있는 방법으로서 예상치 못한 장애의 하나인 ‘조작의 실수’를 해결하는 방안이다.

▲온라인 운영

인터넷 비즈니스는 응용 시스템이 항상 가용해야 되며, 계획된 유지보수를 할 경우라도 데이터베이스에 대한 접근은 계속될 수 있어야 한다. 즉, 데이터가 데이터베이스에 삽입과 삭제됨에 따라 데이터 객체는 조각나게 되므로 때때로 객체 저장 속성은 대용량 데이터를 처리하기 위해서 변경돼야 할 필요가 있다.

오라클9i에서는 계획된 다운 시간 간격을 최소화하는 새로운 온라인 작업 기능으로서 온라인 인덱스 재생성, 온라인 테이블 재정의, 데이터베이스 객체에 대한 통계정보를 수집하기 위한 분석인 온라인 분석 기능 등 과거 데이터베이스 시스템의 서비스운영을 정지시킨 상태에서 수행할 수밖에 없었던 재정의와 관련된 기능들을 시스템이 사용중인 온라인 환경에서도 가능하도록 하는 온라인 운영이 보장됐다.

sol200211004_09.jpg


고가용성은 e-비즈 시대의 경쟁력

DBMS에 장애가 발생하면 곧바로 서비스 중단이라는 치명적 결과를 초래하게 된다. 발생하는 장애는 업무 성격에 따라 차이가 있겠지만 가히 천문학적인 금액 손실로 연결돼질 수 있으며 고객 불만으로 발생되는 잠재적 손실과 데이터 유실로 인한 파급효과는 그 피해정도의 추정이 불가능할 수 있다. 따라서 예상치 못한 장애 및 예상된 시스템 정지를 유발할 수 있는 각각의 장애 사례마다 대비할 수 있는 복합적이고 지능적인 고가용성 솔루션이 없다면 더 이상 e-비즈니스업계에서 생존할 수 없을 것이다.

장애 요인을 실시간으로 극복하고 데이터를 보호하며 정상적인 서비스 운영을 지속할 수 있는 방안으로, 서버장애에 대비해서는 클러스터 공유 디스크를 기반으로 하는 병렬시스템을 소개했고, 데이터가 저장된 스토리지 장애에 대비해서는 스탠바이 데이터베이스를 통해 데이터베이스의 복사본을 유지관리 하는 스탠바이 데이터베이스를 소개했다.

이와 더불어 예정된 다운타임 절감 측면에서도 다양한 온라인 운영 기능들을 활용함으로써 7X24X365 운영을 보장하는 명실상부한 고가용성 솔루션이 가능해 질 수 있는 것이다. 따라서 e-비즈니스 시대에 있는 모든 시스템 관리자들은 업무의 중요성과 고가용성을 확보할 수 있는 기준이 되는 허용 가용률을 정의하고 그 기준에 적합한 HA(High Availability)솔루션을 선택해야 할 것이다.


제공 : DB포탈사이트 DBguide.net