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

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

지난 강의에서는 애플리케이션 파티션에 대해 확인해 봤다. 이보다 더 중요한 것이 데이터 파티션이다. 데이터 파티션은 클러스터의 성능 측면에서 1+1=1.6을 가능하게 만드는 요소다.

이번 강의에서는 데이터 파티션에 대해 확인해 보자. 또한, 애플리케이션 파티션과 데이터 파티션을 함께 사용하는 방법도 함께 생각해보자.

데이터 파티션을 확인하자

서로 다른 서버에서 서로 다른 데이터 블록을 액세스하게 만드는 것이 데이터 파티션의 주된 목적이다. 결국 블록별로 A 서버에서 액세스되는 블록은 계속 A 서버에서만 액세스되게 하고 B서버에서 액세스되는 블록은 B 서버에서만 액세스되게 하는 것이 데이터 파티션의 목적이다.

이와 같은 데이터 파티션을 구현하기 위해서는 여러 가지 데이터베이스 아키텍처를 적용해야 할것이다. 앞서 언급한 애플리케이션 파티션과 결합해 데이터 파티션을 확인해 보자.

데이터 파티션은 다음과 같이 세 가지 정도의 아키텍처를 사용할 수 있다.

• - 클러스터 팩터 최적화
• - 파티션 테이블 아키텍처
• - 테이블 정규화

클러스터 팩터 최적화를 먼저 확인해 보면 클러스터 팩터는 어떤 컬럼으로 동일한 값을 가지는 데이터를 모아서 저장하는 것을 의미한다. 따라서 거래내역 테이블을 고객번호로 클러스터 팩터를 최적화한다면 어떻게 되겠는가?

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

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

앞서 언급한 두개의 SQL은 테이블의 동일한 블록을 액세스할 확률은 거의 없어지게 된다. 물론'1111'번 고객 데이터와 '1112'번 고객 데이터가 동시에 저장되는 하나의 블록 정도는 두 서버에서 동시에 액세스할 수도 있을 것이다.

'1111'번 고객 데이터와'1112'번 고객 데이터가 동시에 저장되는 현상은 클러스터 팩터 최적화를 수행하면서 하나의 블록에서만 발생할 수 있게 된다.

액세스하는 컬럼으로 클러스터 팩터를 최적화하는 작업을 수행한다면 클러스터의 데이터 이전이 완전히 제거되지는 않지만 많은 부분에서 데이터 이전은 감소하게 될 것이다.

파티션 테이블을 사용하게 되면 어떤 현상이 발생하게 되는가? 예를 들어, A 서버에서는 1로 시작하는 고객만이 액세스되고 B 서버에서는 2로 시작하는 고객만이 액세스된다고 가정하자.

해당 테이블을 고객번호 컬럼을 기준으로 범위 파티션으로 구성한다면 어떻게 되겠는가? 물론 파티션 테이블은 고객번호 컬럼의 값이'1'로 시작하는 데이터는 PART_1 파티션으로, 고객번호 컬럼의 값이'2'로 시작하는 데이터는 PART_2로 저장하게 만든다고 가정하자.

위와 같이 파티션 테이블을 구성한다면 PART_1 파티션은'1'로 시작하는 고객번호 컬럼의 값으로 데이터를 액세스하는 A 서버에서만 조회하게 되며 PART_2 파티션의 데이터는'2'로 시작하는 고객 데이터를 액세스하는 B 서버에서만 조회하게 된다.

이와 같이 구성한다면 A 서버에서 액세스하는 데이터와 B 서버에서 액세스하는 데이터는 중복될 수 없을 것이다. 따라서 거래내역 테이블을 조회하는 애플리케이션은 데이터 파티션에 의해 클러스터의 데이터 이전이 발생하지 않게된다.

테이블 정규화는 어떠한가? A 서버와 B 서버에서 조회하는 테이블을 분리해 서로 데이터 이전이 발생하지 않게 구성하는 것이 테이블 정규화 방법이다.

물론, 테이블을 정규화하므로 경우에 따라서는 모든 데이터를 액세스할 수 있게 뷰로 제공해야 할 경우도 발생하게 된다.

애플리케이션 분산과 데이터 분산을 구현하자

하나의 예제를 통해 데이터 분산과 애플리케이션 분산을 확인해 보자. 다음과 같이 가정하자.

• - 통화내역 테이블
• - 1,000만 고객
• - 데이터베이스 클러스터 사용(서버 2대)
• - 통화내역 조회 중요(통화내역 테이블과 고객 테이블 조회)

이와 같은 업무 조건에서 데이터베이스 클러스터를 이용해 어떻게 데이터 파티션을 처리할 수 있을까? 위 조건을 통해 데이터 파티션뿐만 아니라 해당 애플리케이션의 성능을 고려해 아키텍처를 구성해 보자.

우선 애플리케이션 파티션을 고려해 보자. 데이터 파티션을 고려해 애플리케이션 아키텍처를 구현한 각각의 서버에는 500만 고객이 액세스할 수 있도록 분리하는 것이 유리하다.

물론, 500만의 고객이 평균적으로 균등한 통화내역 데이터를 액세스한다고 가정하자. 이와 같다면 파티션 아키텍처만 적용해도 데이터 파티션은 충분할 것이다.

통화내역 테이블을 고객번호 컬럼을 기준으로 500만씩 분리해 2개의 파티션으로 구성하는 것이다. 이와 같이 구성한다면 각각의 서버에서는 하나의 파티션만을 액세스하게 된다. 그러므로 해당 통화내역 테이블에 대해서 클러스터의 데이터 이전은 발생하지 않을 것이다.

또한, 통화내역 조회를 수행하는 순간 함께 조인을 수행하게 되는 고객 테이블의 경우에도 위와 마찬가지로 고객번호 컬럼 값으로 2개의 파티션으로 구성한다면 해당 테이블 또한 각각의 서버에서 각각의 파티션만을 액세스하게 되므로 데이터 이전 현상은 발생하지 않는다.

여기까지만 구성해도 클러스터의 데이터 이전에 의한 성능저하는 발생하지 않을 것이다. 또한, 번호별로 액세스하는 애플리케이션의 성능을 고려해 고객번호 컬럼으로 클러스터 팩터를 최적화할 수 있다.

이와 같다면 데이터 이전이 발생하지 않을 뿐더러 하나의 고객번호 값으로 조회하는 통화내역 조회는 클러스터 팩터 최적화로 탁월한 성능을 기대할 수 있게 된다.

추가로 통화내역 테이블에 대해 보관 주기를 관리해야 한다면 어떻게 되겠는가? 이미 해당 테이블은 범위 파티션을 이용해 고객번호 컬럼으로 2개의 파티션을 구성했다. 하지만 보관 주기를 관리해야 한다면 우리는 또 한 번의 어려움에 부딪히게 된다.

이와 같은 경우 우리는 어떻게 해야 하는가? 해당 테이블을 정규화해 2개의 테이블로 생성하는 것이다. 각각의 테이블은 500만 고객을 관리하게 되며 해당 테이블들을 각각 보관 주기를 관리하는 일자 컬럼 으로 범위 파티션을 구성한다면 보관 주기도 관리하면서 테이블에 대한 데이터 이전도 제거할 수 있게 된다.

물론, 전체 데이터를 액세스해야 한다면 두 테이블을 합한 뷰를 제공할 수도 있다. 이 얼마나 간단하면서도 강력한 방법인가?

서버에서 고객번호 컬럼의 값으로 구분하지 않는 경우에는 어떠한가? 이 경우에는 모든 고객번호가 어느 서버에서나 액세스 될 수 있다는 가정이다.

결국, 각각의 서버에서 어떤 고객번호의 데이터를 액세스하게 될지 예측할 수 없게 된다. 이와 같은 경우 에는 클러스터 팩터만을 최적화한다면 데이터 이전에 대해 많은 부분이 해결될 수 있다.

예를 들어, 하나의 고객 데이터가 A 서버에서 액세스되고 다른 고객의 데이터가 B 서버에서 액세스된다면 둘 간에는 데이터 이전이 거의 발생하지 않는다.

이는 해당 통화내역 테이블을 고객번호 컬럼으로 클러스터 팩터를 최적화했기 때문에 하나의 블록에는 서로 다른 고객번호 값을 가지는 데 이터가 여러 개 저장되기 힘들기 때문이다.

이와 같이 구성한다면 A 서버에서 '111'번 고객의 통화내역 테이블을 조회한 후 바로 B 서버에서 해당 고객번호의 데이터를 액세스하는 경우에만 데이터 이전이 발생하게 된다.

결국, 해당 테이블은 데이터베이스 클러스터의 성능 저하의 원인인 데이터 이전 현상이 감소하게된다. 이와 같은 클러스터의 데이터 이전의 감소로 우리는 성능향상을 기대할 수 있다.

데이터베이스 클러스터에서 데이터 이전은 성능에 있어 매우 중요한 요소다. 시대가 변하면서 더 많은 사이트에서 데이터베이스 클러스터를 이용하게 될 것이다.

시스템을 구축함에 있어서 이와 같은 애플리케이션 파티션과 데이터 파티션에 주의해 구축해야 할 것이다. 이것이야말로 데이터베이스 클러스터를 효과적으로 사용하는 방법이 될 것이다.