이 블로그에 담긴 내용은 순전히 개인적인 견해이며, 특정 제품이나 회사의 공식 입장을 대변하지 않습니다.
들어가며
오라클 데이터베이스는 여러 버전이 있지만, 최신 버전일수록 새로운 아키텍처가 도입되고 있습니다. 특히, 21c 버전부터는 Multitenant 아키텍처가 필수 요소가 되었습니다. 앞으로 새로운 프로젝트나 시스템에서 데이터베이스를 구축할 경우, 19c 이상의 버전을 고려해야 하며, 특히 23c 이후부터는 Multitenant 아키텍처가 기본이 됩니다.
이번 글에서는 Multitenant 아키텍처와 함께 오라클 데이터베이스 아키텍처의 변화가 우리의 데이터베이스 관리에 어떤 영향을 미치는지 정리해 보았습니다.
데이터베이스 아키텍처의 변화
오라클 데이터베이스 아키텍처의 변화는 단순히 새로운 기술을 도입하는 것을 넘어, 우리가 데이터베이스를 운영, 백업, 구성, 모니터링하는 방식 전반에 영향을 미칩니다.
오라클의 Knowledge Site에는 수많은 버그와 관련 가이드가 존재하며, 이러한 정보는 우리의 운영 환경을 구성하고 안정적으로 유지하는 데 큰 도움이 됩니다. 그렇지만 이러한 변화를 관리하는 과정은 여전히 세심한 노력이 필요합니다.
데이터베이스 관리에서의 주요 과제
- 업그레이드의 어려움: 데이터베이스 업그레이드는 항상 신중해야 합니다. 테스트 환경에서 충분히 검증한 후에야 운영 환경으로 적용할 수 있습니다. 이를 통해 큰 문제 없이 업그레이드를 수행할 수 있습니다.
- 파라미터 관리의 중요성: 데이터베이스 성능 튜닝의 핵심은 파라미터 관리입니다. 잘못된 파라미터 설정은 전체 데이터베이스 성능에 부정적인 영향을 줄 수 있습니다. 따라서 초기 설정된 파라미터는 운영 표준으로 자리 잡아야 하며, 버전 업데이트 시에도 항상 검토되어야 합니다.
- SQL 튜닝의 필요성: 새로운 SQL 문장이 실행되면, 성능 관리가 필수적입니다. 통계 정보를 활용하고, 지속적으로 SQL 튜닝을 수행하여 최적의 성능을 유지해야 합니다. 이는 오라클뿐만 아니라 모든 DBMS에서 공통적으로 필요한 과정입니다.
- 높은 안정성: 오라클 데이터베이스는 특히 제조업과 같은 산업 환경에서 수백 일 이상 안정적으로 운영될 수 있습니다. 오라클은 대부분의 문제를 분석하고 해결할 수 있는 강력한 기능을 제공하며, 이는 여전히 다른 DBMS보다 안정적인 운영 환경을 지원한다고 평가됩니다.
오라클 데이터베이스 운영은 대부분 운영 표준 정책에 따라 이루어집니다. 이러한 정책은 과거 9i와 10g 시절에 이미 완성된 것으로, 이후 버전에서는 안정성에 중점을 두고 유지되고 있습니다. 이는 데이터베이스가 전체 인프라에 가장 큰 영향을 미치는 요소이기 때문입니다.
새로운 기능보다는 안정적인 운영을 우선시하는 이러한 접근은, 여전히 많은 기업이 오라클 데이터베이스를 선택하는 이유 중 하나입니다.
비즈니스 요건을 신속하게 대응
오라클은 클라우드 서비스 제공업체(CSP, Cloud Service Provider)로서 빠르게 성장하고 있습니다. 다른 CSP에 비해 매출 면에서는 아직 두드러진 성과를 보이지 않지만, 오라클 데이터베이스의 강점을 활용한 특화 서비스(예: RAC와 Exadata)를 통해 기업 고객을 적극 유치하고 있습니다. 이제 오라클은 단순히 소프트웨어 제공자에서 벗어나, 서비스 제공자로서 직접 데이터베이스를 운영하고 관리해야 하는 새로운 입장으로 변모하고 있습니다.
오라클의 이러한 변화는 크게 두 가지 주요 사항과 연결됩니다.
- 데이터베이스 아키텍처의 변화 (Multitenant): 과거 19c 버전까지는 Multitenant 설정이 선택 사항이었습니다. (DBCA에서 체크박스를 통해 선택 가능) 하지만 21c 버전부터는 Multitenant 아키텍처만 지원하는 것으로 정책이 변경되었습니다. 이 변화는 클라우드 환경에 보다 적합한 아키텍처를 도입하기 위한 결정으로 보입니다. 클라우드에서는 자원의 효율적 운영과 서비스의 추상화가 중요하기 때문에 Multitenant 아키텍처가 이를 효과적으로 지원할 수 있습니다.
- 패치 및 버전 정책의 변화: 오라클은 클라우드 환경에서 요구되는 신속한 기능 추가를 위해 데이터베이스 버전 정책을 변경했습니다. 과거 11g와 12c처럼 단순한 버전명 대신, 18c, 19c, 21c와 같이 연도를 포함한 새로운 버전명이 도입되었습니다.
또한 데이터베이스의 최신 버전은 다음과 같은 순서로 출시됩니다:
- 클라우드 환경: 가장 먼저 적용되어 검증됩니다.
- On-Premise 환경 (Windows/Linux x86): 클라우드에서 검증된 버전이 이후 제공됩니다.
- Unix 계열: 마지막으로 출시됩니다.
운영 입장에서는 클라우드에서 먼저 검증된 버전이 제공되기 때문에 안정성을 높일 수 있는 장점으로 느껴질 수 있습니다.
오라클 데이터베이스는 비즈니스 요건에 맞춘 최신 기술을 빠르게 지원하며, 클라우드와 온프레미스 환경 모두에서 효율적인 운영을 가능하게 하고 있습니다. 이러한 변화는 오라클이 클라우드 환경에서 더욱 경쟁력 있는 서비스 제공자로 자리 잡도록 돕고 있으며, 고객들에게도 더 나은 안정성과 효율성을 제공합니다.
데이터베이스 아키텍처 변경의 필요성
소프트웨어 개발 프로세스가 발전하면서 개발 아키텍처도 변화하고 있습니다. 최근 DevOps와 함께 마이크로서비스 아키텍처(MSA)가 많은 주목을 받고 있습니다. 그렇다면, MSA를 효과적으로 지원하기 위한 인프라 환경은 어떤 모습일까요?
Container 환경은 이제 개발의 트렌드로 자리 잡았습니다. 많은 프로젝트가 시작될 때 “Kubernetes 환경에서 MSA 아키텍처로 개발한다”는 문구를 흔히 볼 수 있습니다. 하지만 애플리케이션 아키텍처가 이렇게 변화하는 가운데, 데이터베이스는 어떻게 변화하고 있을까요?
Container 환경에서 데이터베이스 운영 시 고려 사항
데이터베이스를 Container 환경에서 운영하려면 다음 사항들을 주의 깊게 검토해야 합니다.
- 데이터베이스 엔진의 특성
- 실행 파일(바이너리)이 크고, 패치 및 버전 관리가 필요합니다.
- 이미지를 빌드하는 데 시간이 오래 걸리고, 이미지 크기가 커질 수 있습니다.
- 고성능을 위해 메모리와 디스크 I/O가 중요합니다.
- 한 Container에 리소스를 많이 할당하면 다른 Container에 부족이 발생할 수 있습니다.
- 큰 영구 저장소의 필요성
- 데이터베이스는 대용량 데이터를 저장해야 하므로 공유 스토리지 또는 NFS와 같은 외부 저장소 설정이 필수적입니다.
- 고가용성, 성능, 보안, 백업 관리
- 데이터베이스는 일반 Container와 달리 고급 기술과 데이터베이스 특화 관리 기술이 필요합니다.
- Native 기술 구성에 제약이 있을 수 있으므로 데이터베이스를 깊이 이해하는 관리 기술이 요구됩니다.
오라클 데이터베이스의 Container 환경 지원
오라클은 데이터베이스를 Container 환경에서 운영할 수 있는 두 가지 주요 방식을 제공합니다:
- Oracle Operator for Kubernetes: Kubernetes 환경에서 데이터베이스를 생성, 관리할 수 있는 도구를 제공합니다.
- In-Database Container 기술(Multitenant): 데이터베이스 자체에 Container 개념을 도입하여 하나의 Container DB에서 다수의 Pluggable DB를 관리할 수 있는 기술을 제공합니다.
Multitenant 아키텍처의 방향성
Multitenant 아키텍처는 하나의 Container DB에서 여러 개의 Pluggable DB를 관리할 수 있는 방식입니다.
이 기술의 주요 특징은 다음과 같습니다:
- 하나의 Container DB에 200개 이상의 Pluggable DB를 올릴 수 있어 데이터베이스 통합(Consolidation)에 최적화되어 있습니다.
- 여러 Pluggable DB를 하나의 Container DB 내에서 분리 관리함으로써 리소스 효율성을 극대화할 수 있습니다.
Multitenant 아키텍처는 대규모 데이터베이스 환경을 통합적으로 관리하고, 운영 효율성을 높이는 데 최적화된 솔루션으로 자리 잡고 있습니다. 이를 통해 오라클 데이터베이스는 현대적인 클라우드 및 Container 환경에 효과적으로 대응할 수 있습니다.
DB의 통합 운영 환경 제공
Multitenant 아키텍처의 핵심 목적은 여러 개의 데이터베이스를 통합하여 효과적으로 관리하는 데 있습니다. Container DB는 리소스 풀(Resource Pool)을 관리하고, 그 위에 애플리케이션이 접근하여 데이터를 처리하는 Pluggable DB 간의 리소스 경합을 줄이는 기능을 제공합니다. 이러한 기능은 SLA(Service Level Agreement)를 유지하기 위해 필수적입니다.
리소스 관리 방법
- 리소스 종류: CPU, 메모리(SGA, PGA), IOPS, 스토리지, 세션 등 다양한 리소스를 Pluggable DB 단위로 관리할 수 있습니다.
- 관리 방식: 최소값과 최대값으로 리소스를 설정하여 관리합니다. 리소스가 여유 있는 Container DB에서는 Pluggable DB에 더 많은 리소스를 할당할 수 있으며, Pluggable DB가 많아질수록 각 DB에 필요한 리소스를 적절히 분배해야 합니다.
인스턴스 구성 방법
- Container DB 단위에서 RAC(Real Application Cluster) 또는 Single Instance로 인스턴스를 구성할 수 있습니다.
- Pluggable DB는 Container DB의 구성 방식을 따르지만, 필요에 따라 Pluggable DB 단위에서 RAC 또는 Single Instance로 제어가 가능합니다.
- 예를 들어, 특정 업무가 증가하여 Single Instance에서 RAC로 전환해야 할 경우, RAC 환경의 Container DB로 이동하면 Pluggable DB도 자동으로 RAC로 변경됩니다.
더 높은 운영 수준 필요
DB를 통합 운영하려면 기존 시스템보다 더 높은 수준의 관리와 운영 능력이 요구됩니다.
- 인프라 이중화는 필수입니다.
- 또한, 재해 복구(DR) 정책을 수립하여 견고한 운영 환경을 만들어야 합니다.
모든 인프라 위에서 DB 유연성 확보
Multitenant 아키텍처의 가장 중요한 특징 중 하나는 Pluggable DB 이동 기능입니다. DB 자체가 쉽게 이동한다는 개념은 생소할 수 있지만, Container DB 환경에서는 Pluggable DB들이 손쉽게 이동할 수 있습니다.
- 마이그레이션 및 업그레이드
- Container DB의 버전에 따라 Pluggable DB의 버전도 결정됩니다.
- Pluggable DB가 상위 버전의 Container DB로 이동하면 자동으로 마이그레이션 및 업그레이드가 이루어집니다. 이는 기존의 복잡한 절차를 단순화한 획기적인 기능입니다.
- 개발 환경 구성의 용이성
- Clone 기능을 활용하여 운영 환경에서 테스트 환경을 쉽게 생성할 수 있습니다.
- Snapshot Copy 기술을 사용하면 적은 용량으로도 여러 테스트 환경을 만들 수 있습니다.
- 인프라 간 가용성 확보
- Pluggable DB 수준에서 DataGuard 구성을 지원하여,
- 데이터 센터의 Container DB와 B 데이터 센터의 Container DB 간에 상호 가용성을 제공하는 환경을 구축할 수 있습니다.
마무리
이번 글에서는 오라클 데이터베이스의 Multitenant 아키텍처 방향성을 간단히 알아보았습니다.
Multitenant의 목표는 인프라를 연결하고 가상화된 환경에서 데이터베이스를 서비스화하여 유연성과 확장성을 제공하는 것입니다. 특히, On-Premise 환경과 Cloud 환경 간에 데이터베이스 이동을 간소화하는 기술은 이를 잘 보여주는 예시입니다.
Multitenant 구성 요소인 Container DB와 Pluggable DB의 개념과 사용법을 익힌다면 더 효율적인 데이터베이스 운영이 가능할 것입니다. 앞으로도 Multitenant 아키텍처의 강점을 활용해 더욱 스마트한 데이터베이스 환경을 구축해 보시길 바랍니다.
댓글남기기