많은 사이트에서는 가용성 및 성능을 위해 여러 서버에서 하나의 데이터베이스를 이용하는 구조를 고려하게 된다. 많은 데이터베이스가 이와 같은 기능을 제공하지만 그 중에서도 오라클에서 제공하는 RAC를 사용하는 사이트들이 많다.

그렇다면 이와 같은 아키텍처를 사용하는 사이트에서는 무엇에 주의해야 하는가? 바로 애플리케이션 파티션과 데이터 파티션이다.

클러스터 개념은 IT의 많은 부분에서 도입되어 사용되고 있다. 이와 같은 추세가 데이터베이스에도 마찬가지로 적용되는 것이 현실이다. 대부분의 데이터베이스에서는 이와 같은 클러스터 개념의 아키텍처를 제공하게 된다.

그 중에서도 오라클 RAC 아키텍처를 많이 이용하고 있으며 데이터베이스 클러스터를 효과적으로 이용하기 위해 애플리케이션 파티션과 데이터 파티션이 동시에 구현되어야 할 것이다.

우리는 1+1=2라는 사실을 너무나 잘 알고 있다. 하지만, 현실은 1+1=2가 아닌 경우도 존재한다는 것을 이해하는가? 바로 이러한 현실이 데이터베이스 클러스터 아키텍처에서 발생할 수 있다.

2대의 서버로 클러스터를 구성할 경우 각각의 서버 성능을 1이라고 가정한다면 2라는 성능을 기대하는 것은 당연할 것이다. 하지만 어떻게 구성하는가에 따라 1+1=0.5가 될 수도 있고 1+1=1.7이 될 수도 있다.

과연 어떤 경우를 선택하겠는가? 우리가 해당 시스템을 관리 하는 담당자라면 1+1=2는 아니더라도 1+1=1.7의 시스템을원하게 될 것이다.

그러기 위해서는 데이터 파티션과 애플리케이 션 파티션을 고려하는 것이 매우 중요하다. 이제부터 애플리케이션 파티션과 데이터 파티션에 대해 자세히 이야기해 보자.

데이터베이스 클러스터의 데이터 이전(Transfer)은 성능 저하의 주범

데이터베이스 클러스터를 사용한다는 것은 하나의 데이터베이스에 여러 개의 서버가 접속되어 있는 상황이다. 이는 클러스터를 사용하는 사람이나 또는 클러스터를 도입하고자 하는 사람이라면 누구나 이해하고 있을 것이다.

결국, 하나의 데이터베이스를 2개 이상의 서버가 공유하는 형태가 될 것이다. 따라서 각각의 서버에서는 동일한 데이터베이스를 액세스할 수 있게 된다.

그러므로 데이터베이스는 하나가 존재하며 데이터베이스를 액세스할 수 있는 서버는 여러 대로 구성되는 것이 진정한 데이터베이스 클러스터이다.

이와 같은 클러스터 구조에서 데이터 이전은 무엇을 의미하는 가? 예를 들어 보자. A 서버와 B 서버가 클러스터로 구성되어 있고 각각의 서버는 DB1이라는 동일한 데이터베이스를 액세스 한다고 가정하자.

그렇다면 A 서버에서 거래내역 테이블을 조회 할 수도 있고 B 서버에서 거래내역 테이블을 조회할 수도 있을 것이다. A 서버와 B 서버에서 다음과 같은 SQL을 동시에 수행 한다면 어떤 현상이 발생하겠는가?

SELECT 거래일자, 사용자명, 거래금액
  FROM 거래내역
 WHERE 고객번호 = '1111'

위의 SQL을 A 서버와 B 서버에서 동시에 수행한다면 어떤 현상이 발생하는가? A 서버와 B 서버는 동일한 블록을 액세스하게 될 것이다.

A 서버가 먼저 조건을 만족하는 데이터를 A 서버의 메모리로 캐싱시켜 조회하게 되며 B 서버는 원하는 데이터 블록이 A 서버에 존재한다는 것을 내부적으로 확인한 후 A 서버에게 해당 블록을 B 서버로 이전시켜 줄 것을 요청하게 된다.

이와 같은 현상이 발생하면 A 서버는 판단하게 되며 해당 데이터 블록이 더 이상 필요 없다면 B 서버로 이전하게 된다. 물론, 해당 블록을 사용하고 있다면 좀 더 복잡한 절차를 수행하게 된다.

해당 데이터 블록을 사용하는 경우에는 해당 블록을 복사해 읽을 수 있게 블록을 이전시켜 주거나 상대 서버에서 INSERT,UPDATE 및 DELETE 등의 DML을 발생시키고자 한다면 대기 현상이 발생할 수도 있다.

이와 같이 데이터베이스 클러스터를 사용하는 순간 데이터 블록의 이전 현상은 발생할 수밖에 없다. 여기서 중요한 것은 이와같은 데이터 블록의 이전은 많은 성능을 저하시킬 수 있다는 것이다.

데이터베이스 클러스터는 이와 같은 데이터 블록 이전 현상에 의해 1+1=0.5가 되거나 또는 1+1=1.7이 된다.

결국, 데이터 이전 현상이 최소화된다면 1+1=1.7이 되며 데이터 이전 현상이 증가하면 해당 시스템은 1+1=0.5의 시스템이 될 것이다.

그렇다면 데이터 이전이 전혀 발생하지 않는다면 1+1=2가 될 수 있는가? 그렇지는 않다. 이는 데이터베이스 클러스터에서 모든 데이터 블록 이전을 제거할 수는 없으며 다른이유들이 존재하기 때문이다.

데이터베이스 클러스터 환경을 사용하는 시스템은 이와 같은 현상에 대해 최적의 성능을 보장 받기를 원할 것이다. 그러기 위해서는 데이터 이전을 최소화시켜야 한다. 그렇다면 어떻게 우리는 데이터 이전을 최소화시킬 수 있겠는가?

그 정답은 애플리케이션 파티션과 데이터 파티션에 있다. 애플리케이션 파티션과 데 이터 파티션을 최적화한다면 우리는 데이터 이전을 최소화할 수 있으며 1+1=1.7의 성능을 기대할 수 있게 된다.

애플리케이션 파티션과 데이터 파티션은 동시에 이뤄져야 한다

애플리케이션 파티션과 데이터 파티션은 분리해서 생각할 수 없다. 각각을 최적화해 데이터베이스 클러스터를 최적화할 수 없게 된다.

결국, 데이터 파티션만을 적용해 해당 데이터베이스 클러스터를 최적화할 수 없으며 애플리케이션 파티션을 통해서만 해당 시스템을 최적화할 수는 없다. 두 가지 항목이 조화를 이룰 때 최적의 성능을 기대할 수 있게 된다.

그렇다면 애플리케이션 파티션과 데이터 파티션은 무엇을 의미하는 것인가? 각각의 정의부터 확인해 보자.

애플리케이션 파티션

데이터베이스 클러스터를 구성하는 각각의 서버에서 다른 조건 값을 가지는 SQL 문이 수행하도록 애플리케이션을 구현 또는 다른 업무가 수행하도록 데이터베이스 클러스터의 업무를 각 서버별로 분리

데이터 파티션

데이터베이스에 저장되는 데이터를 분리해 하나의 데이터는 A 서버에서만 액세스되고 다른 하나의 데이터는 B 서버에서만 액세스되도록 데이터분리에 대한 아키텍처를 구현

애플리케이션 파티션을 확인해 보자. 동일한 조건의 값을 가지는 SQL이 A 서버와 B 서버에서 수행된다면 해당 애플리케이션은 데이터 이전 현상을 발생시키게 될 것이다. 다음과 같은 경우를 확인해 보자.

SELECT 거래일자, 사용자명, 거래금액
  FROM 거래내역
 WHERE 고객번호 = '1111';

SELECT 거래일자, 사용자명, 거래금액
  FROM 거래내역
 WHERE 고객번호 = '1112'

고객번호 값에 따라 첫 번째 SQL은 A 서버에서, 두 번째 SQL은 B 서버에서 수행된다면 해당 SQL만 고려한다면 데이터 이전 현상은 발생하지 않게 된다. 결국, 서버별로 WHERE 조건의 값에 따라 분리한다면 해당 SQL들은 데이터 이전이 발생하지 않을 수 있다.

이와 같이 하나하나의 SQL에 대해 수행될 서버를 어떻게 선정할지가 어려운 문제일 수 있다. 하지만 조금만 더 깊게 생각한다면 이도 어려운 일은 아닐 것이다.

애플리케이션 파티션은 위와 같은 형태 말고도 다음과 같이 구현할 수도 있다. 어떤 카드 회사의 승인 정산 업무를 수행하는 시스템을 예로 들어보자.

해당 시스템에서 승인 업무는 A 서버에서 수행하고 정산 업무는 B 서버에서 수행할 수 있게 구성하는 것이다. 이와 같이 구성한다면 업무가 서버별로 완전히 분리되어 애플리케이션 파티션이 구현될 수 있다.

애플리케이션 파티션은 이와 같이 WHERE 조건의 값에 의해 분리할 수도 있고 업무를 서로 다른 서버에 배치해 애플리케이션 파티션을 구현할 수 있다. 어느 방법을 선택해도 괜찮다. 중요한 포인트는 어느 방법을 선택했을 경우 데이터 파티션과 조화를 이룰 수 있는지를 고려해 최적의 구성을 구현하는 것이다.

그럼 다음 강의에서는 데이터 파티션과 데이터 클러스터에 대해 확인해 보자.