Oracle Exadata를 단순히 사양이 높은 데이터베이스 서버로 이해하면 핵심을 놓치기 쉽습니다. Exadata는 Oracle Database의 처리 특성에 맞춰 데이터베이스 서버, 지능형 스토리지, 고속 네트워크와 고가용성 기능을 함께 최적화한 통합 플랫폼입니다. 복잡해 보이는 아키텍처도 ‘어디서 SQL을 처리하는가’, ‘어디서 데이터를 선별하는가’, ‘어느 범위의 장애까지 견뎌야 하는가’, ‘어디에 배포할 것인가’라는 네 가지 질문으로 나누면 한결 선명해집니다.
1. 기본 골격은 DB 서버와 지능형 스토리지의 역할 분담
데이터베이스 서버 계층은 SQL 실행, 트랜잭션 처리와 같은 Oracle Database의 핵심 작업을 담당합니다. 스토리지 서버 계층은 데이터를 저장하는 동시에 일부 데이터 처리를 수행합니다. 두 계층을 고속 네트워크로 연결해 서버·스토리지·네트워크가 따로 움직이지 않고 하나의 데이터베이스 플랫폼처럼 협력하도록 만든 것이 Exadata의 기본 구조입니다.
특히 스토리지는 단순한 디스크 상자가 아닙니다. 대용량 조회가 들어오면 Smart Scan을 통해 스토리지 서버에서 필요한 데이터를 먼저 선별하고, DB 서버에는 처리에 필요한 범위만 전달할 수 있습니다. 모든 원본 데이터를 DB 서버로 올리는 방식보다 데이터 이동량과 네트워크 부담을 줄이는 데 유리합니다. 여기에 Hybrid Columnar Compression, 지능형 캐시, 자동 스토리지 리밸런싱이 저장 효율과 처리 성능을 보완합니다.
데이터베이스 처리 계층과 지능형 스토리지 사이의 데이터 선별·전송 구조를 추상화한 AI 일러스트
AI 일러스트
AI 생성
2. 물리 계층 위에는 RAC·CDB·PDB가 놓인다
여러 DB 서버 노드에는 Oracle RAC를 구성할 수 있습니다. RAC는 애플리케이션 부하를 여러 노드로 분산하고, 클러스터 안의 개별 서버에 장애가 생겼을 때 서비스를 이어 가기 위한 장치입니다. 그 위의 논리적 데이터베이스 구조는 컨테이너 데이터베이스인 CDB와 업무별 플러거블 데이터베이스인 PDB로 나눠 이해할 수 있습니다.
예를 들어 운영 업무는 RAC 기반 VM 클러스터에 배치하고 개발 환경은 별도의 단일 인스턴스 VM으로 분리한 뒤, 각 환경 아래에 여러 PDB를 둘 수 있습니다. 이때 물리 장비, VM 클러스터, CDB, PDB는 서로 다른 관리 단위입니다. 환경이나 프로젝트 태그는 자원 추적과 비용 배분에 유용하지만, SQL 실행과 테이블 조회 권한까지 대신하지는 않습니다. 인프라 관리는 OCI IAM 정책으로, 데이터 접근은 DB 계정·역할·권한과 네트워크 방화벽으로 각각 통제해야 합니다.
3. RAC가 있어도 사이트 재해복구는 별도 설계가 필요하다
고가용성 설계에서는 장애 범위를 구분하는 것이 중요합니다. RAC는 한 클러스터 내부의 노드 장애에 대응하는 축이지만, 데이터센터나 클라우드 리전 전체의 장애까지 해결하는 기능은 아닙니다. 사이트 단위 사고에 대비하려면 Active Data Guard 같은 복제 및 대기 데이터베이스 구성을 추가해야 합니다.
더 높은 연속성이 요구된다면 GoldenGate나 분산형 데이터베이스를 활용한 사이트 간 액티브-액티브 논리 복제도 검토할 수 있습니다. 다만 기능을 많이 넣을수록 언제나 좋은 아키텍처가 되는 것은 아닙니다. 업무별로 허용 가능한 데이터 손실을 나타내는 복구시점목표와 서비스 복구 시간을 뜻하는 복구시간목표를 먼저 정하고, 노드·클러스터·사이트 중 어디까지 보호할지 결정해야 비용과 운영 복잡성을 통제할 수 있습니다.
4. 같은 골격을 어디에 배포할지 선택한다
Exadata는 자체 데이터센터의 전용 시스템뿐 아니라 OCI의 Exadata Database Service, 고객 데이터센터에 장비를 설치하는 Exadata Cloud@Customer 형태로도 활용할 수 있습니다. Exadata Cloud@Customer는 데이터가 고객사 내부에 머무는 배치와 OCI 제어 평면을 통한 자원 관리를 결합하므로, 데이터 위치에 관한 요구와 클라우드식 운영을 함께 고려하는 환경에 어울립니다.
멀티클라우드 선택지도 있습니다. Oracle Database@AWS는 AWS 환경 안에 OCI 기반 데이터베이스 인프라를 구축해 Exadata Database Service 등을 실행하는 방식입니다. AWS 콘솔을 통한 관리와 기존 애플리케이션·라이선스 활용 가능성이 제시되어 있지만, 실제 설계에서는 이름보다 연결 구조를 살펴야 합니다. 애플리케이션과 DB 사이의 지연, 데이터가 머무는 위치, 관리 책임, 라이선스, 백업 위치와 장애 영역을 함께 비교해야 합니다.
마무리
Exadata 아키텍처를 읽는 순서는 간단합니다. 먼저 DB 서버와 지능형 스토리지의 처리 분담을 보고, 그 위에 RAC와 CDB·PDB의 논리 구조를 올립니다. 다음으로 장애 범위에 맞춰 사이트 복구 체계를 정하고, 마지막에 온프레미스·OCI·Cloud@Customer·멀티클라우드 중 배포 위치를 선택하면 됩니다. 결국 좋은 구성은 가장 많은 기능을 담은 구성이 아니라, 업무 중요도와 성능 요구, 데이터 위치, 복구 목표를 필요한 계층에 정확히 연결한 구성입니다.
참고 자료
"클라우드 DB 혁신 가속"…'오라클 데이터베이스앳AWS' 출시
https://n.news.naver.com/mnews/article/421/0008361715?sid=105
Oracle Exadata 아키텍처 구성, 계층과 배포 방식으로 쉽게 이해하기
https://blog.naver.com/eva1984/224408343332
Oracle Cloud Free Tier란? 오라클 클라우드 특징과 무료 서버 장단점
https://blog.naver.com/h2docu/224365060213
Oracle ExaCC Tagging, Autonomous AI DB 작동 원리
https://blog.naver.com/querydb/224354030508
오라클 AI 데이터베이스, 미션 크리티컬 환경에서 가용성과 보안의 새로운 기준 제시
https://blog.naver.com/madtimes/224251581653
#Oracle #Exadata #OracleDatabase #RAC #ActiveDataGuard #ExadataCloudAtCustomer #OCI #데이터베이스아키텍처
댓글