오라클 RAC의 기본 컨셉은 인스턴스를 이중화해 무정지(Non-Stop) 서비스를 구현하자는 것이다. 이를 위해서는 기본적으로 다중 서버환경이 필요하다.

여기에서 많은 오해가 생기는데, 여러 개의 서버를 클러스터로 묶어놓기에 당연히 성능도 배가 될 것으로 생각하는 사람들이 있다. 하지만 반드시 성능이 향상되지는 않는다. 예전에 필자는 고객사 관계자와 이야기를 나누던 중 RAC 환경을 구축했다가 되레 성능이 저하됐다는 이야기를 들었다.

사실 RAC는 1개의 스토리지를 복수 개의 오라클 인스턴스가 공유하는 방식이기 때문에 자원의 부족이나 경합으로 인해 성능 저하가 발생하는 경우가 아니라면 단일 인스턴스와 비교할 때 성능이 눈에 띄게 향상되는 솔루션은 아니다.

오라클 RAC 환경을 구축하는 경우는 크게 두 가지로 볼 수 있다. 시스템의 고가용성을 목표로 RAC의 Failover 기능만을 사용하기 위해 2개의 노드에 대해 업무적으로 Active-Standby 환경으로 RAC를 구축하는 케이스와 단일 인스턴스로는 감당하기 힘든 부하를 분산하기 위해 2개 이상의 노드에 대해 Active-Active 환경으로 RAC를 구축하는 케이스이다.

전자의 경우는 현재 많이 사용하는 방식은 아니며, 실제로 하나의 물리 노드만을 사용하기 때문에 Failover 관련 설정만 잘 해주면 크게 문제는 없다. 하지만 후자의 경우는 각 물리 노드 간의 데이터 정합성 및 일관성을 위한 캐시퓨전 작업을 수시로 수행해야 하기 때문에 SQL 튜닝이나 노드별 부하분산을 잘못할 경우 심각한 성능 저하 현상을 초래할 수 있다

캐시퓨전

오라클 RAC 환경에서 중요한 성능 포인트 중 하나는 GRD (Global Resource Directory)를 통해 LMS Process가 관리하는 캐시퓨전(Cache Fusion) 기능이다.

캐시퓨전을 쉽게 설명하면 물리적으로 떨어져 있는 각 노드의 버퍼캐시를 논리적으로 하나의 버퍼캐시처럼 보이게 하고 사용하기 위한 GCS(Global Cache Service)를 구현하기 위한 기능이다.

물리적으로 분리돼 있는 버퍼캐시 영역을 사용하는 입장에서는 하나의 버퍼캐시에 접근하는 것과 동일한 효과를 얻게 되며 Private Inter-Connect Network를 통해 각 노드의 버퍼캐시 및 기타 관련 정보를 전송하게 된다.

예를 들면, 1번 노드에서 테이블의 데이터를 조회하려는 목적으로 필요한 버퍼블록을 액세스하려고 할 때 해당 버퍼블록의 마스터 노드의 LMS Process에 해당 버퍼블록을 요청하게 된다.

만약 마스터 노드의 버퍼캐시에 해당 블록이 있다면 1번 노드의 버퍼캐시에 해당 버퍼블록을 복사한 후 GRD에 양쪽 노드에 해당 버퍼블록이 Scur 모드로 존재한다는 걸 기록한다.

LMS Process는 읽기 일관성과 데이터 정합성을 위해 각 노드의 데이터블록에 대한 정보를 기록하며 오직 1개의 노드만이 해당 블록을 변경할 수 있도록 관리한다.

이러한 캐시퓨전 기능으로 인해 만약 여러 노드에서 동일한 블록에 대한 액세스 및 변경이 빈번하게 일어날 경우 과도한 캐시퓨전으로 인한 성능 저하는 필연적으로 발생하게 된다. 이러한 문제를 해결하기 위해선 SQL 성능 튜닝을 통해 불필요한 블록 액세스를 줄이는 작업이 필히 선행돼야 한다.

또한 워크로드 분산을 통해 업무별로 수행되는 Node를 분리함으로써 각 노드별로 액세스하는 테이블 및 인덱스 세그먼트 자체를 최대한 분리하는 방법으로도 큰 효과를 볼 수 있다.

오라클 서비스(Oracle Service)

부하 관리를 위한 기본적인 단위이다. 서비스에는 1개 이상의 인스턴스가 포함될 수 있고 각 인스턴스는 여러 개의 서비스를 지원할 수 있다.

예를 들어 특정 배치작업은 특정 노드에서만 수행되도록 설정할 수 있으며, 해당 노드가 다운 및 정지됐을 경우 해당 서비스를 다른 노드로 failover시킬 것인지 아니면 해당 노드가 정상화될 때까지 보류할지를 결정할 수 있다.

오라클 11g에서는 단일 인스턴스당 100개의 서비스까지 정의할 수 있으며 오라클에서 제공하는 엔터프라이즈 매니저(EM) 모니터링 솔루션을 통해 좀더 손쉽게 관리할 수 있다.

Connect Time Failover(CTF)

오라클 데이터베이스 인스턴스에 접속 시 접근한 인스턴스의 접속 가능 여부에 따라 다른 인스턴스로 접속하는 방식이다.

Transparent Application Failover(TAF)

Failover 수준을 설정할 수 있다. SELECT로 설정할 경우 세션뿐 아니라 수행되던 SQL에 의한 데이터 인출 작업(Fetch)도 Failover된다.

Fast Application Notification(FAN)

노드의 UP/DOWN 등 이벤트 발생 여부를 빠르게 다른 프로세스에 전달할 수 있는 서비스이다.

특정 노드에 장애가 발생하면 DOWN 이벤트를 통해 연결돼 있던 세션들을 바로 종료하고, 해당 노드로의 신규접속을 막을 수 있으며, 장애가 발생했던 노드가 정상화되면 자동으로 세션들을 Failback시킬 수 있다.

로드밸런싱(Load Balancing)

클라이언트에서 접속 시 라운드로빈 방식으로 로드밸런싱하는 방식과 리스너를 통해 서버의 부하가 적은 노드로 접속을 유도하는 방식을 사용할 수 있다.

서버의 부하 정도는 각 인스턴스의 PMON 프로세스에서 정보를 수신하게 되며 오라클 리스너는 이 정보를 바탕으로 부하가 덜 가해지는 인스턴스로 접근을 유도해 로드밸런싱하게 된다.

오라클 RAC는 분명히 고가용성과 확장성을 지닌 훌륭한 솔루션이다. 하지만 대부분의 기술들이 그러하듯 제대로 알지 못하고 사용한다면 당연히 뜻하지 않은 결과를 초래할 수도 있다는 사실을 명심하자.