데이터이야기

DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.

생각의 전환이 데이터베이스를 최적화 시킨다. - 7부

데이터 이야기
작성자
dataonair
작성일
2016-06-09 00:00
조회
3426


많은 사이트에서는 가용성 및 성능을 위해 여러 서버에서 하나의 데이터베이스를 이용하는 구조를 고려하게 된다. 많은 데이터베이스가 이와 같은 기능을 제공하지만 그 중에서도 많은 사이트에서는 오라클에서 제공하는 RAC를 주로 사용하고 있다. 그렇다면 이와 같은 아키텍쳐를 사용하는 사이트에서는 무엇에 주의해야 하는가 바로 어플리케이션 파티션과 데이터 파티션이다.

클러스터 개념은 IT의 많은 부분에서 도입되어 사용되고 있다. 이와 같은 추세가 데이터베이스에도 마찬가지로 적용되는 것이 현실이다. 대부분의 데이터베이스에서는 이와 같은 클러스터 개념의 아키텍쳐를 제공하게 된다. 그 중에서도 오라클 RAC 아키텍쳐를 많이 이용하고 있으며 RAC를 효과적으로 이용하기 위해 우리는 어플리케이션 파티션과 데이터 파티션이 동시에 구현되어야 할 것이다. 우리는 1+1=2라는 사실을 너무나 잘 알 고 있다. 하지만, 현실은 1+1=2가 아닌 경우도 존재한다는 것을 이해하는가 바로 이러한 현실이 RAC 아키텍쳐에서 발생할 수 있다. 두 대의 서버로 클러스터를 구성할 경우 각각의 서버의 성능을 1이라고 가정했을 경우 2라는 성능을 기대하는 것은 당연할 것이다. 하지만 어떻게 구성하는가에 따라 1+1=0.5가 될 수도 있고 1+1=1.7이 될 수도 있다. 과연 어떤 경우를 선택하겠는가 우리가 해당 시스템을 관리하는 담당자라면 1+1=2는 아니더라도 1+1=1.7의 시스템을 원하게 될 것이다. 그러기 위해서는 데이터 파티션과 어플리케이션 파티션을 고려하는 것이 매우 중요하다. 이제부터 어플리케이션 파티션과 데이터 파티션에 대해 자세히 이야기해 보자.

RAC의 데이터 이전(Transfer)은 성능 저하의 주범이다.

RAC를 사용한다는 것은 하나의 데이터베이스에 여러 개의 서버가 접속되어 있는 것이다. 이는 클러스터를 사용하는 사람이나 또는 클러스터를 도입하고자 하는 사람이라면 누구나 이해하고 있을 것이다. 결국, 하나의 데이터베이스를 2개 이상의 서버가 공유하는 형태가 될 것이다. 따라서, 각각의 서버에서는 동일한 데이터베이스를 엑세스할 수 있게 된다. 그러므로 데이터베이스는 하나가 되며 존재하며 데이터베이스를 엑세스할 수 있는 서버는 여러 대로 구성되는 것이 진정한 RAC이다.

이와 같은 클러스터 구조에서 데이터 이전은 무엇을 의미하는가 예를 들어 보자. A 서버와 B 서버가 클러스터로 구성되어 있고 각각의 서버는 DB1이라는 동일한 데이터베이스를 엑세스한다고 가정하자. 그렇다면 A 서버에서 거래내역 테이블을 조회할 수도 있고 B 서버에서 거래내역 테이블을 조회할 수도 있을 것이다. A 서버와 B 서버에서 아래와 같은 SQL을 동시에 수행한다면 어떤 현상이 발생하겠는가

====================================================================

SQL> SELECT 거래일자, 사용자명, 거래금액

FROM 거래내역

WHERE 고객번호 = ‘1111’;

====================================================================

위와 같은 SQL을 A 서버와 B 서버에서 동시에 수행한다면 어떤 현상이 발생하는가 A 서버와 B 서버는 동일한 블록을 엑세스하게 될 것이다. A 서버가 먼저 조건을 만족하는 데이터를 A 서버의 메모리로 캐싱시켜 조회하게 되며 B 서버는 원하는 데이터 블록이 A 서버에 존재한다는 것을 내부적으로 확인한 후 A 서버에게 해당 블록을 B 서버로 이전시켜 줄 것을 요청하게 된다. 이와 같은 현상이 발생하게 되면 A 서버는 판단을 하게 되며 해당 데이터 블록이 더 이상 필요 없다면 B 서버로 이전을 시켜 주게 된다. 물론, 해당 블록을 사용하고 있다면 좀더 복잡한 절차를 수행하게 된다. 해당 데이터 블록을 사용하는 경우에는 해당 블록을 복사하여 읽을 수 있게 블록을 이전시켜 주거나 상대 서버에서 INSERT, UPDATE 및 DELETE 등의 DML을 발생시키고자 한다면 대기 현상이 발생할 수도 있다.

이와 같이 RAC를 사용하는 순간 데이터 블록의 이전 현상은 발생할 수 밖에 없다. 여기서 중요한 것은 이와 같은 데이터 블록의 이전은 많은 성능을 저하시킬 수 있다는 것이다. RAC는 이와 같은 데이터 블록 이전 현상에 의해 1+1=0.6이 되거나 또는 1+1=1.7이 되게 된다. 결국, 데이터 이전 현상이 최소화된다면 1+1=1.7이 되며 데이터 이전 현상이 증가하게 되면 해당 시스템은 1+1=0.6의 시스템이 될 것이다. 그렇다면 데이터 이전이 전혀 발생하지 않는다면 1+1=2가 될 수 있는가 그 것은 아니다. 이는 RAC에서 모든 데이터 블록 이전을 제거할 수는 없기 때문이다.

RAC 환경을 사용하는 시스템은 이와 같은 현상에 대해 최적의 성능을 보장 받기를 원할 것이다. 그러기 위해서는 데이터 이전을 최소화시켜야 한다 그렇다면 어떻게 하여 우리는 데이터 이전을 최소화시킬 수 있겠는가 그 정답은 어플리케이션 파티션과 데이터 파티션에 있다. 어플리케이션 파티션과 데이터 파티션을 최적화한다면 우리는 데이터 이전을 최소화할 수 있게 되며 그러므로 1+1=1.7의 성능을 기대할 수 있게 된다.