🎯 Oracle RAC가 뭔데 이렇게 난리야?

요즘 기업들 DB 서버 보면 진짜 ㅋㅋㅋ 24시간 365일 멈추면 안 되잖아? 💸
특히 금융권이나 대형 쇼핑몰 같은 곳은 서버 1분만 다운되어도 수억 날아가는 거 실화임 ㄷㄷ
그래서 등장한 게 바로 Oracle RAC(Real Application Clusters)인데요~

간단히 말하면 여러 대의 서버가 하나의 데이터베이스를 공유하면서 동시에 일하는 시스템이에요.
한 대가 뻗어도 다른 서버가 바로 받아서 처리하니까 서비스는 계속 돌아가는 거죠! 🔄

일반 DB는 서버 1대가 혼자 열일하다가 죽으면 끝인데,
RAC는 팀플처럼 여러 명이 같이 일하니까 한 명 빠져도 프로젝트는 계속 진행되는 느낌? ㅋㅋㅋ
물론 팀플은 한 명 빠지면 망하지만... RAC는 진짜 잘 돌아감 👍

🏗️ RAC의 핵심 아키텍처 뜯어보기

자 이제 본격적으로 RAC 내부를 파헤쳐볼까요? ㅋㅋ
일단 RAC 구조를 이해하려면 3가지 레이어를 알아야 해요.

1️⃣ 인스턴스 레이어 - 각 노드에서 돌아가는 Oracle 인스턴스들
2️⃣ 클러스터웨어 레이어 - 노드들을 묶어주는 관리 소프트웨어
3️⃣ 스토리지 레이어 - 모든 노드가 공유하는 디스크

이 세 가지가 유기적으로 연결되어 있어야 RAC가 제대로 작동하는 거죠! 💯

🎮 인스턴스 레이어 - 각자의 메모리 영역

각 노드마다 독립적인 Oracle 인스턴스가 떠 있어요.
근데 여기서 중요한 건, 각 인스턴스는 자기만의 SGA(System Global Area)를 가진다는 거!

SGA는 뭐냐고요? 오라클의 메모리 영역인데요~
- Database Buffer Cache: 데이터 블록 캐싱
- Shared Pool: SQL 파싱 정보, 딕셔너리 캐시
- Redo Log Buffer: 변경사항 로깅
- Large Pool: 대용량 작업용

일반 단일 인스턴스 Oracle이랑 똑같죠? ㅇㅇ
차이점은 RAC에서는 이런 인스턴스가 여러 개 동시에 돌아간다는 거예요! 🔥

🌐 클러스터웨어 레이어 - 오케스트라의 지휘자

여러 노드를 하나로 묶어주는 게 바로 Oracle Grid Infrastructure예요.
예전에는 CRS(Cluster Ready Services)라고 불렀는데, 11g부터 Grid Infrastructure로 통합됐죠.

이 녀석이 하는 일이 진짜 개많음 ㄷㄷ

특히 Voting Disk는 진짜 중요한데요,
네트워크가 끊겨서 노드들이 서로를 못 보는 상황(스플릿 브레인)이 발생하면,
Voting Disk에 접근할 수 있는 노드만 살아남고 나머지는 자동으로 재부팅돼요! 😱

이게 없으면 각 노드가 "내가 주인이야!" 하면서 데이터 꼬이는 대참사가 발생하거든요 ㅋㅋㅋ

💾 스토리지 레이어 - 모두가 공유하는 보물창고

RAC의 핵심은 바로 공유 스토리지예요!
모든 노드가 동일한 데이터파일, 컨트롤파일, 리두로그에 접근할 수 있어야 하거든요.

보통 이런 스토리지를 사용해요:
- SAN (Storage Area Network): 파이버채널 기반, 가장 많이 씀
- NAS (Network Attached Storage): NFS 프로토콜 사용
- iSCSI: IP 네트워크 기반 블록 스토리지

여기서 Oracle이 제공하는 ASM(Automatic Storage Management)을 쓰면,
디스크 관리가 엄청 편해져요! 파일시스템 없이 바로 RAW 디바이스 쓰는 거라 성능도 좋고 ㅇㅇ

ASM이 자동으로 데이터를 여러 디스크에 분산시키고(스트라이핑),
미러링도 해주고, 디스크 추가하면 알아서 리밸런싱까지 해줌 👏
진짜 개꿀 기능임 ㅋㅋㅋ

⚡ Cache Fusion - RAC의 비밀병기

자 이제 RAC의 핵심 중의 핵심! Cache Fusion에 대해 알아볼까요? 🎯

상황을 가정해볼게요.
노드1에서 고객 테이블의 A라는 데이터 블록을 읽어서 메모리(Buffer Cache)에 올려놨어요.
그런데 노드2에서도 똑같은 A 블록을 읽으려고 한다면?

옛날 방식(Disk Ping): 노드1이 A 블록을 디스크에 쓰고 → 노드2가 디스크에서 읽음
→ 디스크 I/O 발생! 느림! 💩

Cache Fusion 방식: 노드1이 메모리에 있는 A 블록을 네트워크로 직접 노드2에 전송!
→ 디스크 안 거침! 빠름! 🚀

이게 가능한 이유는 노드 간에 고속 인터커넥트 네트워크(보통 InfiniBand나 10Gb 이더넷)가 연결되어 있기 때문이에요.
디스크보다 네트워크가 훨씬 빠르니까 성능이 확 올라가는 거죠! 💪

🎭 블록 모드와 역할 변경

Cache Fusion에서 블록은 여러 가지 모드를 가질 수 있어요.

예를 들어볼게요 ㅎㅎ

1️⃣ 노드1이 블록 A를 읽음 → Local 모드로 캐싱
2️⃣ 노드2도 블록 A를 읽으려 함 → 노드1에 요청
3️⃣ 노드1의 블록 A가 Shared 모드로 변경되고, 노드2에 전송
4️⃣ 노드2도 Shared 모드로 블록 A를 캐싱
5️⃣ 노드3이 블록 A를 수정하려 함 → Exclusive 모드 요청
6️⃣ 노드1, 노드2의 블록 A가 무효화(Invalidate)되고, 노드3이 Exclusive 모드로 획득

이런 식으로 블록의 역할이 계속 바뀌면서 데이터 일관성을 유지하는 거예요! 🎪

근데 이 과정에서 GC(Global Cache) 대기 이벤트가 발생할 수 있어요.
- gc current block 2-way: 현재 블록을 다른 노드에서 가져오는 대기
- gc cr block 2-way: 읽기 일관성 블록을 가져오는 대기
- gc buffer busy: 블록이 전송 중이라 대기

이런 대기 이벤트가 많이 발생하면 성능이 떨어지니까,
RAC 튜닝할 때는 이 부분을 집중적으로 봐야 해요! 📊

🛡️ 고가용성(HA) - 절대 죽지 않는 시스템

RAC의 가장 큰 장점이 뭐냐면, 바로 고가용성(High Availability)이에요! 💪
한 노드가 죽어도 서비스는 계속 돌아가거든요.

실제로 어떻게 작동하는지 시나리오로 볼게요 ㅎㅎ

💥 노드 장애 시나리오

상황: 4개 노드로 구성된 RAC 환경에서 노드2가 갑자기 다운됨! 😱

1단계 - 장애 감지 (1~3초)
→ Clusterware의 CSSD(Cluster Synchronization Service Daemon)가 노드2의 하트비트 끊김 감지
→ Voting Disk 체크로 노드2가 진짜 죽었는지 확인
→ "노드2 죽음!" 클러스터 전체에 알림 📢

2단계 - 인스턴스 복구 (5~30초)
→ 노드2에 연결되어 있던 세션들이 살아있는 노드로 자동 재연결 (TAF - Transparent Application Failover)
→ 노드2가 처리하던 트랜잭션은 리두로그를 통해 다른 노드가 복구
→ 노드2가 가지고 있던 락(Lock)들 해제

3단계 - 서비스 재분배
→ 노드2가 담당하던 워크로드를 나머지 3개 노드가 나눠서 처리
→ Connection Pool 재조정
→ 서비스 정상화! ✅

이 모든 과정이 보통 1분 이내에 완료돼요!
사용자는 잠깐 멈칫하는 정도만 느끼고, 서비스는 계속 돌아가는 거죠 ㅋㅋㅋ

🔄 롤링 업그레이드 - 무중단 패치

RAC의 또 다른 개꿀 기능! 롤링 업그레이드예요 🎉

일반 DB는 패치하려면 서비스 중단해야 하잖아요?
근데 RAC는 한 노드씩 돌아가면서 패치할 수 있어요!

롤링 업그레이드 절차
1️⃣ 노드1 서비스 중지 → 패치 적용 → 재시작
2️⃣ 노드2 서비스 중지 → 패치 적용 → 재시작
3️⃣ 노드3, 노드4도 동일하게 진행

이 과정에서 나머지 노드들이 계속 서비스하니까 무중단 패치가 가능한 거죠! 🚀
금융권이나 24시간 서비스하는 곳에서는 이거 진짜 필수임 ㄷㄷ

📈 확장성(Scalability) - 노드만 추가하면 끝

트래픽이 늘어나면 어떻게 해야 할까요?
일반 DB는 서버 스펙을 올리는 Scale-Up 방식밖에 없어요.
근데 이것도 한계가 있잖아요? CPU 64코어, 메모리 1TB 이상 올리기도 힘들고 비용도 ㄷㄷ

RAC는 Scale-Out 방식이라 노드만 추가하면 돼요! 💪

노드 추가 시나리오
1️⃣ 새 서버 준비 (하드웨어 세팅)
2️⃣ Grid Infrastructure 설치
3️⃣ addNode.sh 스크립트 실행
4️⃣ 새 인스턴스 생성 및 시작
5️⃣ 서비스 재분배 설정
6️⃣ 끝! 🎉

기존 노드들은 서비스 중단 없이 계속 돌아가고,
새 노드가 추가되면 자동으로 워크로드가 분산돼요.

이론적으로는 노드를 무한정 추가할 수 있지만,
실무에서는 보통 4~8노드 정도가 최적이에요.
그 이상 가면 노드 간 통신 오버헤드가 커져서 오히려 성능이 떨어질 수 있거든요 ㅋㅋ

🔧 RAC 주요 컴포넌트 상세 분석

이제 RAC를 구성하는 핵심 컴포넌트들을 하나씩 뜯어볼게요! 🔍
각각의 역할을 정확히 이해해야 RAC를 제대로 운영할 수 있거든요 ㅇㅇ

🗂️ OCR (Oracle Cluster Registry)

OCR은 클러스터의 모든 구성 정보를 저장하는 데이터베이스예요.
일종의 클러스터 설정 저장소라고 보면 돼요!

OCR에 저장되는 정보들
- 클러스터 노드 목록 및 상태
- 데이터베이스 인스턴스 정보
- ASM 디스크 그룹 구성
- 서비스 및 리소스 설정
- VIP(Virtual IP) 정보

OCR이 손상되면 클러스터 전체가 마비될 수 있어서,
Oracle은 자동으로 OCR을 미러링해요! (최소 2개, 권장 3개)

그리고 매일 자동 백업도 해주니까 안심 ㅎㅎ
백업 위치: $GRID_HOME/cdata/클러스터명

🗳️ Voting Disk - 생존 판정사

Voting Disk는 노드의 생존 여부를 판단하는 투표 메커니즘이에요.

각 노드는 1초마다 Voting Disk에 하트비트를 기록해요.
만약 어떤 노드가 하트비트를 못 쓰면? → 죽은 걸로 간주하고 클러스터에서 퇴출! ⚰️

스플릿 브레인 방지
네트워크 단절로 클러스터가 두 그룹으로 나뉘면,
Voting Disk에 접근할 수 있는 노드가 과반수 이상인 그룹만 살아남아요.

예를 들어 4노드 클러스터가 2:2로 나뉘면?
→ Voting Disk 3개 중 2개 이상에 접근 가능한 그룹이 승리!
→ 진 그룹은 자동으로 재부팅되어 데이터 꼬임 방지 ✅

이것도 OCR처럼 다중화가 필수! (홀수 개 권장: 3개 or 5개)

💾 ASM (Automatic Storage Management)

ASM은 Oracle이 제공하는 볼륨 매니저 + 파일시스템 역할을 해요.
일반 파일시스템(ext4, xfs 등) 없이 RAW 디바이스를 직접 관리하는 거죠!

ASM의 장점
✅ 자동 스트라이핑: 데이터를 여러 디스크에 분산 저장 → I/O 성능 향상
✅ 자동 미러링: 데이터 복제로 안정성 확보
✅ 자동 리밸런싱: 디스크 추가/제거 시 데이터 자동 재분배
✅ 빠른 복구: 디스크 장애 시 빠르게 복구

ASM 디스크 그룹
여러 디스크를 묶어서 하나의 논리적 스토리지로 만드는 단위예요.

보통 운영 환경에서는 Normal Redundancy를 많이 써요.
High는 너무 디스크 낭비가 심하고, External은 RAID 컨트롤러에 의존하니까요 ㅇㅇ

🌐 인터커넥트 네트워크

RAC에서 인터커넥트 네트워크는 생명줄이에요! 💓
Cache Fusion으로 블록을 주고받고, 클러스터 통신도 여기서 이루어지거든요.

인터커넥트 요구사항
- 저지연(Low Latency): 1ms 이하 권장
- 고대역폭(High Bandwidth): 최소 10Gbps, 권장 40Gbps 이상
- 전용 네트워크: 다른 트래픽과 섞이면 안 됨!

주로 사용하는 기술
- InfiniBand: 초저지연, 초고속 (40~200Gbps), 비쌈 💰
- 10GbE/40GbE: 이더넷 기반, 가성비 좋음
- RoCE (RDMA over Converged Ethernet): 이더넷에 RDMA 기능 추가

인터커넥트가 느리면 Cache Fusion 성능이 떨어져서,
결국 디스크 I/O가 늘어나고 전체 성능이 저하돼요 😭
그래서 RAC 성능 튜닝할 때 인터커넥트 모니터링이 필수!

🎮 RAC 서비스 관리 - 워크로드 분산의 기술

RAC에서 서비스(Service)는 클라이언트 연결을 관리하는 논리적 단위예요.
서비스를 잘 설계하면 워크로드를 효율적으로 분산시킬 수 있어요! 💪

🏷️ 서비스 개념과 구성

예를 들어볼게요 ㅎㅎ

4노드 RAC 환경에서:
- SALES_SVC: 영업팀용 서비스 → 노드1, 노드2에서 실행
- REPORT_SVC: 리포트용 서비스 → 노드3, 노드4에서 실행
- BATCH_SVC: 배치 작업용 → 노드4에서만 실행

이렇게 서비스별로 노드를 분리하면,
무거운 리포트 쿼리가 영업 트랜잭션에 영향을 안 주겠죠? 👍

서비스 생성 예시

srvctl add service -d RACDB -s SALES_SVC \
  -preferred "RAC1,RAC2" \
  -available "RAC3,RAC4" \
  -policy AUTOMATIC \
  -failovertype SELECT \
  -failovermethod BASIC \
  -notification TRUE

여기서 preferred는 우선 실행 노드,
available은 장애 시 페일오버될 노드예요!

⚖️ 로드 밸런싱 전략

RAC는 두 가지 로드 밸런싱 방식을 제공해요.

Server-Side 로드 밸런싱이 더 똑똑해요!
PMON 프로세스가 각 노드의 부하 정보를 리스너에게 알려주고,
리스너는 가장 여유로운 노드로 연결을 보내는 거죠 ㅎㅎ

Connection String 예시:

SALES_SVC =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = scan-vip)(PORT = 1521))
    (LOAD_BALANCE = yes)
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = SALES_SVC)
    )
  )

여기서 SCAN-VIP는 Single Client Access Name인데,
클라이언트는 개별 노드 IP를 몰라도 SCAN만 알면 접속할 수 있어요! 개꿀 🎉

🔄 FAN (Fast Application Notification)

노드 장애가 발생하면 클라이언트에게 빠르게 알려주는 기능이에요.

FAN 동작 과정
1️⃣ 노드2 다운 감지
2️⃣ FAN 이벤트 발생 → ONS(Oracle Notification Service)를 통해 전파
3️⃣ Connection Pool이 이벤트 수신
4️⃣ 노드2에 연결된 커넥션들을 즉시 정리
5️⃣ 새 연결은 살아있는 노드로만 생성

FAN 없으면 TCP 타임아웃(보통 2분)까지 기다려야 하는데,
FAN 쓰면 수 초 내에 장애 대응이 가능해요! ⚡

JDBC, ODP.NET, OCI 등 Oracle 클라이언트 라이브러리에서 기본 지원하니까,
애플리케이션 코드 수정 없이 바로 쓸 수 있어요 👍

🔍 RAC 성능 튜닝 - 병목 지점 찾기

RAC를 도입했는데 성능이 안 나온다? 😱
그럼 어디가 문제인지 찾아야겠죠! 튜닝 포인트를 알아볼게요 ㅎㅎ

📊 주요 모니터링 지표

RAC 성능을 모니터링할 때 봐야 할 핵심 지표들이에요.

이 수치들이 정상 범위를 벗어나면 문제가 있는 거예요!

AWR 리포트로 확인하기

-- AWR 스냅샷 생성
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

-- AWR 리포트 생성 (RAC 전체)
@?/rdbms/admin/awrgrpt.sql

-- 특정 인스턴스만
@?/rdbms/admin/awrrpt.sql

AWR 리포트에서 Top 5 Timed Events 섹션을 보면,
어떤 대기 이벤트가 많이 발생하는지 알 수 있어요!

만약 gc current block 2-way 같은 GC 이벤트가 상위권이면?
→ Cache Fusion 성능 문제! 인터커넥트나 애플리케이션 튜닝 필요 🚨

⚡ 일반적인 성능 문제와 해결책

문제 1: 인터커넥트 병목
증상: GC 대기 이벤트 시간이 길고, 인터커넥트 사용률 높음
원인: 네트워크 대역폭 부족, 패킷 손실, 레이턴시 높음
해결:
- 인터커넥트 대역폭 업그레이드 (10G → 40G)
- Jumbo Frame 활성화 (MTU 9000)
- 네트워크 스위치 점검

문제 2: 핫 블록 경합
증상: 특정 블록에 여러 노드가 동시 접근, gc buffer busy 많음
원인: 시퀀스, 인덱스 루트 블록 등에 집중 접근
해결:
- 시퀀스 CACHE 크기 증가 (CACHE 1000 이상)
- 역방향 키 인덱스 사용
- 파티셔닝으로 데이터 분산

문제 3: 스토리지 I/O 병목
증상: db file sequential read, db file scattered read 대기 많음
원인: 공유 스토리지 성능 한계
해결:
- SSD/NVMe 스토리지로 업그레이드
- ASM 스트라이핑 최적화
- 버퍼 캐시 크기 증가

🛠️ RAC 설치 및 구성 - 실전 가이드

이론은 이제 충분히 알았으니, 실제로 RAC를 구축하는 과정을 볼까요? ㅎㅎ
물론 실제 설치는 엄청 복잡하지만, 핵심 단계만 정리해볼게요! 💪

📋 사전 준비사항

RAC 설치 전에 준비해야 할 것들이 많아요 ㄷㄷ

하드웨어 요구사항
- 최소 2대 이상의 서버 (동일 스펙 권장)
- 공유 스토리지 (SAN, NAS, iSCSI 등)
- 퍼블릭 네트워크 인터페이스 (클라이언트 접속용)
- 프라이빗 네트워크 인터페이스 (인터커넥트용, 최소 10Gbps)

소프트웨어 요구사항
- 지원되는 Linux 버전 (RHEL, Oracle Linux 등)
- 커널 파라미터 설정
- 필수 RPM 패키지 설치
- 방화벽 포트 오픈

네트워크 설정
각 노드마다 최소 3개의 IP가 필요해요!
- Public IP: 클라이언트 접속용
- Private IP: 인터커넥트용
- VIP (Virtual IP): 페일오버용

추가로 SCAN IP 3개도 필요하고... DNS 설정도 해야 하고...
진짜 할 게 많음 ㅋㅋㅋ 😅

🚀 설치 단계

1단계: Grid Infrastructure 설치
클러스터웨어와 ASM을 먼저 설치해야 해요.

# Grid Infrastructure 설치 (첫 번째 노드에서)
./gridSetup.sh

# 설치 중 선택사항
- Configure Oracle Grid Infrastructure for a Cluster
- Advanced Installation
- 노드 정보 입력 (호스트명, VIP)
- 네트워크 인터페이스 지정 (Public/Private)
- SCAN 정보 입력
- ASM 디스크 그룹 생성
- root 스크립트 실행

설치가 끝나면 각 노드에서 root 스크립트를 실행해야 해요.
이게 Voting Disk, OCR 등을 초기화하는 거예요!

2단계: Oracle Database 소프트웨어 설치
Grid Infrastructure가 정상 작동하면 DB 소프트웨어를 설치해요.

# Database 소프트웨어 설치
./runInstaller

# 설치 옵션
- Install database software only (소프트웨어만 설치)
- Oracle RAC database installation
- 모든 노드 선택

3단계: 데이터베이스 생성
DBCA(Database Configuration Assistant)로 RAC DB를 생성해요.

# DBCA 실행
dbca

# 생성 옵션
- Create a database
- Advanced configuration
- Oracle Real Application Clusters database
- 모든 노드에 인스턴스 생성
- ASM 스토리지 선택
- 리스너 설정

이렇게 하면 각 노드에 인스턴스가 생성되고,
공유 스토리지에 데이터파일이 만들어져요! 🎉

4단계: 검증 및 테스트

# 클러스터 상태 확인
crsctl check cluster -all

# 데이터베이스 상태 확인
srvctl status database -d RACDB

# 모든 인스턴스 확인
ps -ef | grep pmon

# 리스너 상태 확인
lsnrctl status

모든 노드에서 인스턴스가 정상 작동하면 성공! ✅

🎓 RAC 운영 베스트 프랙티스

RAC를 실제 운영하면서 알아둬야 할 팁들을 공유할게요! 💡
이건 진짜 현장에서 뼈저리게 느낀 것들이에요 ㅋㅋ

✅ 해야 할 것들

1. 정기적인 백업
- OCR 자동 백업 확인: ocrconfig -showbackup
- Voting Disk 백업: dd 명령어로 수동 백업
- 데이터베이스 RMAN 백업 (당연히!)

2. 모니터링 자동화
- Enterprise Manager Cloud Control 사용
- 커스텀 스크립트로 GC 대기 이벤트 모니터링
- 인터커넥트 네트워크 트래픽 감시
- 디스크 I/O 성능 추적

3. 정기적인 패치
- 분기별 PSU(Patch Set Update) 적용
- 롤링 패치로 무중단 업데이트
- 패치 전 반드시 테스트 환경에서 검증!

4. 용량 계획
- ASM 디스크 그룹 여유 공간 20% 이상 유지
- 노드 추가 시점 미리 계획 (CPU 70% 도달 시점 등)
- 아카이브 로그 증가율 모니터링

❌ 하지 말아야 할 것들

1. 인터커넥트 네트워크 공유
절대로 인터커넥트에 다른 트래픽 태우지 마세요!
Cache Fusion 성능이 떨어져서 전체 시스템이 느려져요 😱

2. 노드별 비대칭 구성
노드1은 32코어인데 노드2는 16코어? 이러면 안 돼요!
워크로드 분산이 제대로 안 되고, 장애 시 성능 저하 심함 ㅠㅠ

3. 단일 Voting Disk
Voting Disk 1개만 쓰면 그게 고장나면 클러스터 전체 다운!
반드시 홀수 개(3개 or 5개)로 다중화하세요 🚨

4. 애플리케이션 노드 고정
특정 애플리케이션을 특정 노드에만 연결하면,
그 노드 죽으면 서비스 중단! TAF 설정 필수예요 ✅

🆚 RAC vs 다른 HA 솔루션 비교

고가용성을 구현하는 방법은 RAC만 있는 게 아니에요!
다른 솔루션들과 비교해볼까요? 🤔

언제 RAC를 선택해야 할까?
✅ 서비스 중단이 절대 안 되는 미션 크리티컬 시스템
✅ 트래픽이 계속 증가해서 Scale-Out이 필요한 경우
✅ 읽기/쓰기 모두 높은 성능이 필요한 경우
✅ 무중단 패치/업그레이드가 필수인 경우

RAC가 과한 경우
❌ 트래픽이 적고 단일 서버로 충분한 경우
❌ 예산이 제한적인 경우 (Data Guard가 더 나음)
❌ 읽기 전용 부하 분산만 필요한 경우
❌ 운영 인력이 부족한 경우 (관리 복잡도 높음)

🔮 RAC의 미래와 클라우드 환경

요즘은 클라우드 시대잖아요? ☁️
RAC도 클라우드 환경으로 진화하고 있어요!

☁️ Oracle Cloud에서의 RAC

Oracle은 자체 클라우드인 OCI(Oracle Cloud Infrastructure)에서
RAC를 서비스 형태로 제공하고 있어요!

Exadata Cloud Service
- 완전 관리형 RAC 서비스
- 자동 백업, 패치, 모니터링
- 필요할 때 노드 추가/제거 가능
- 온프레미스 Exadata와 동일한 성능

VM DB System with RAC
- 가상머신 기반 RAC
- Exadata보다 저렴
- 유연한 구성 가능

클라우드에서는 인프라 관리 부담이 확 줄어들어서,
RAC 도입 장벽이 많이 낮아졌어요! 👍

특히 Auto Scaling 기능으로
트래픽에 따라 노드를 자동으로 추가/제거할 수 있어서 개꿀 ㅋㅋ

🚀 RAC의 최신 기능들

Oracle 19c, 21c에서 추가된 RAC 관련 기능들이에요.

Flex ASM
- ASM 인스턴스를 모든 노드에 띄우지 않아도 됨
- 리소스 절약, 관리 편의성 향상

Flex Cluster
- Hub Node + Leaf Node 구조
- Leaf Node는 로컬 스토리지 사용 가능
- 더 유연한 클러스터 구성

Application Continuity
- 노드 장애 시 트랜잭션 자동 재실행
- 애플리케이션 코드 수정 없이 투명한 페일오버
- TAF보다 훨씬 똑똑함!

Global Data Services
- 여러 RAC 클러스터를 하나로 관리
- 글로벌 로드 밸런싱
- 지역별 데이터 분산

💬 실무 경험담 - 진짜 현장 이야기

마지막으로 실제 RAC 운영하면서 겪었던 에피소드들을 공유할게요 ㅋㅋ
이런 거 알아두면 나중에 도움 될 거예요! 😄

🔥 장애 사례 1: 인터커넥트 스위치 고장

어느 날 갑자기 DB 성능이 폭락했어요 😱
AWR 보니까 GC 대기 이벤트가 평소의 10배!

원인을 찾아보니 인터커넥트 스위치 포트 하나가 고장나서,
40Gbps → 10Gbps로 대역폭이 떨어진 거였어요 ㄷㄷ

교훈: 인터커넥트 네트워크도 이중화 필수!
그리고 네트워크 모니터링 꼭 하세요 ㅠㅠ

⚡ 장애 사례 2: Voting Disk 손실

스토리지 점검 중에 실수로 Voting Disk가 있는 LUN을 언마운트했어요 💀
그 순간 클러스터 전체가 패닉 상태!
모든 노드가 서로를 못 보니까 동시에 재부팅 시작...

다행히 Voting Disk가 3개였고, 2개는 살아있어서
클러스터는 복구됐지만 심장 쫄깃했음 ㅋㅋㅋ

교훈: 스토리지 작업할 때는 정말정말 조심!
그리고 Voting Disk 다중화는 생명줄이에요 🙏

🎯 성능 개선 사례: 시퀀스 튜닝

주문 테이블에 INSERT가 몰리는 시간대에 성능이 떨어지는 문제가 있었어요.
분석해보니 주문번호 시퀀스에서 GC 경합이 심했던 거예요!

해결 방법

-- 기존 시퀀스 (CACHE 20)
CREATE SEQUENCE order_seq CACHE 20;

-- 개선 시퀀스 (CACHE 10000)
CREATE SEQUENCE order_seq CACHE 10000;

CACHE 크기를 20 → 10000으로 늘렸더니,
각 노드가 시퀀스 블록을 덜 자주 요청하게 되어서
GC 경합이 확 줄어들었어요! 🎉

성능이 약 3배 향상됐고, 사용자들도 만족 ㅎㅎ

교훈: RAC에서는 시퀀스 CACHE를 크게 설정하세요!
번호가 좀 건너뛰어도 성능이 훨씬 중요해요 💪

📚 마무리하며

와... 여기까지 읽느라 고생 많으셨어요! 👏
Oracle RAC에 대해 꽤 많은 걸 다뤘는데, 정리해볼게요 ㅎㅎ

RAC의 핵심 요약
✅ 여러 노드가 하나의 DB를 공유하는 Active-Active 클러스터
✅ Cache Fusion으로 노드 간 메모리 블록 공유
✅ 고가용성 + 확장성 + 성능 향상을 동시에 제공
✅ Grid Infrastructure로 클러스터 관리
✅ ASM으로 스토리지 자동 관리

RAC 도입 시 고려사항
💰 비용: 라이선스, 하드웨어, 운영 인력 모두 비쌈
🔧 복잡도: 일반 DB보다 관리가 훨씬 복잡함
📊 워크로드: 애플리케이션이 RAC에 적합한지 분석 필수
👥 인력: 숙련된 DBA 필요

하지만 제대로 구축하고 운영하면,
절대 죽지 않는 안정적인 시스템을 만들 수 있어요! 💪

특히 금융, 통신, 대형 이커머스처럼
서비스 중단이 곧 막대한 손실로 이어지는 곳에서는
RAC가 거의 필수라고 봐도 무방해요 ㅇㅇ

RAC 공부하시는 분들께 도움이 됐으면 좋겠네요! 😊
궁금한 점 있으면 재능넷에서 전문가들과 소통해보세요~

그럼 모두 해피 DBA 라이프 되시길! 🎉
ㅋㅋㅋ 화이팅! 💪✨