버그대왕

시스템 엔지니어

개요

오라클 데이터베이스는 다양한 버전이 있습니다. 21c부터는 Multitenant 으로 불리우는 아키텍쳐가 필수 구성요소가 되었습니다. 차세대 프로젝트를 하거나 신규 업무에 데이터베이스 구축을 하게 되면 19c이상의 버전을 고려하게 될것이며, 23c가 출시되면 Multitenant 아키텍쳐로 구성할수 밖에 없습니다.

Multitenant 아키텍쳐의 방향성에 대해서 정리하였습니다.

데이터베이스 아키텍쳐의 변화

오라클 데이터베이스 아키텍처의 변화는 매우 중요한 의미를 가지고 있습니다 우리가 지금까지 수행했던 모든 활동(운영, 백업, 구성, 모니터링)에 영향을 줄것은 분명하기 때문입니다. 오라클의 knowledge Site에 보면 많은 버그들과 가이드들이 공존하고 있습니다. 그런 다양한 상황에서 우리는 한땀한땀 정성드려서 운영 환경을 구성하고 안정적으로 운영하고 있습니다.

데이터베이스 관리의 어려움

  • 업그레이드의 어려움
    • 업그레이드는 언제나 조심스럽게 진행되어야 합니다. 그러나 테스트 환경에서의 검증을 통해 운영 환경에서 큰 문제 없이 수행될 수 있습니다.
  • 파리미터 관리의 중요성
    • 인스턴스의 튜닝은 파라미터 관리에서부터 시작됩니다. 하나의 파라미터 설정이 전체 DB 성능에 영향을 미칠 수 있습니다. 따라서 한번 설정된 파라미터는 표준이 되며, 버전 업데이트에도 항상 검토되어야 합니다.
  • SQL 튜닝의 필요성
    • 통계정보 관리와 함께 새로운 SQL이 실행되면 지속적으로 성능관리가 필요합니다. 이는 어떤 DBMS나 업무에서도 공통적입니다.
  • 그래도 안정성은 어느 DBMS보다 나은것 같다
    • 데이터베이스 기동후에 몇 백일동안 운영되고 있는 환경도 존재합니다. (특히 제조산업), 또한 대부분의 문제에 대해서 분석이 가능합니다.

오라클 데이터베이스를 운영은 대부분의 경우 운영 표준 정책을 따릅니다. 이러한 표준 정책은은 약 9i, 10g시렂에 걸쳐서 거의 완성되었고요, 이후에 새로운 기능보다는 안정성을 우선시하며 운영을 했던것 같습니다. 이는 인프라에서 데이터베이스가 가장 큰 영향을 미치기 때문입니다.

비즈니스 요건을 신속하게 대응

오라클에서는 클라우드 사업분야(CSP, Cloud Service Provider)에서 큰 성장을 이루고 있습니다. 다른 CSP에 비해서 상대적으로 두두러지게 보여지는 매출을 보이지 않지만 후발주자로서 오라클 데이터베이스와 관련된 특화된(RAC와 Exadata등) 서비스 출시하여 기업고객들을 유치하고 있습니다. 이제 오라클은 S/W제공자에서 서비스 제공자로 변화하고 있며, 직접 데이터베이스를 운영하고 관리해야되는 상황으로 입장이 변한것입니다.

오라클에서 크게 두가지 사항이 변경된것 같습니다.

  • 첫번째는 데이터베이스 아키텍쳐 변화(Multitenant) 입니다. 19c 버전까지만 해도 Multitenant 설정은 옵션이었습니다. (DBCA에서 check box로 선택할수 있었습니다). 그런데 21c부터 Multitenant 아키텍쳐만 지원하도록 정책을 변경되었습니다. 클라우드 환경에서는 보다 자원을 효율적으로 운영하고 서비스들은 보다 추상화되어 제공되기 때문에 Multitenant 아키텍쳐가 더 적합한 아키텍쳐라고 생각한것 같습니다.

  • 두번째는 패치 정책입니다. 클라우드 환경에서 많은 기능들이 필요하기 때문에 신속한 기능 추가를 위하여 오라클 데이터베이스의 버전 정책이 변경되었습니다. 기존에 11g, 12c였다면 18c,19c,21c등 연도를 버전명에 포함하고 있습니다. 그러면서 데이터베이스 최신버전이 나오면 가장 먼저 클라우드환경에서 출시됩니다. 그다음 On-Premise버전의 Window/Linux (x86)계열로 나오고 마지막이 Unix계열 일것 같습니다. (운영하는 입장에서 보면 클라우드에서 먼저 검증된 버전이 나오니까 좀더 안정적이다라고 느낄수도 있겠습니다.)

비즈니스 요건에 맞는 최신기술을 지원하고 기준 운영환경과 클라우드 환경을 효율적으로 운영하기 위하여 오라클 데이터베이스가 변화하고 있습니다.

데이터베이스 아키텍쳐 변경의 필요성

개발 프로세스에 따라 개발 아키텍쳐도 변화하고 있습니다. DevOps를 위해서 MSA가 주목받고 있습니다. MSA를 지원하기 위한 인프라 환경은 어떤 것이 필요할까요? 최근에는 Container 환경이 많이 사용되며, 이것이 개발의 트렌드로 자리 잡고 있습니다. (일단 프로젝트가 시작되면 Kubernetes 환경에서 MSA 아키텍처로 개발한다는 문구가 자주 보입니다.)

이렇게 애플리케이션 아키텍처가 변화하는 가운데 데이터베이스는 어떻게 변화하고 있을까요? 데이터베이스들도 Container 환경에서 쉽게 관리하고 생성할 수 있도록 Operator를 지원하고 있습니다

하지만, 과연 데이터베이스를 Container 환경에서 운영하기에 편한가요? 데이터 크기와 업무 특성에 따라 다를것으로 보입니다. 테스트 환경으로 운영한다면 Container에서 운영해볼수 있겠지만(1:1구조), 운영환경에서 특정 업무가 증가하면서 애플리케이션 서버는 쉽게 확장이 가능하지만, 결국 하나의 데이터베이스 서버에 집중이 됩니다.(N:1) 이는 모놀리식 아키텍쳐의 단점과 유사할수 있습니다. 그래서 서비스를 나누는 단위가 중요한것 같습니다.

데이터베이스를 Container 환경에서 운영할 때 고려해야 할 부분들은 다음과 같습니다.

  • “데이터베이스 엔진” 프로그램의 특성
    • 실행(바이너리)파일이 크고, 패치 및 버전관리가 필요합니다.
      • 이미지 크기가 크고 빌드시 많은 시간이 소요됩니다.
    • 고성능을 위해 많은 리소스가 필요합니다. (디스크 I/O를 줄이기 위해서 메모리가 많이 필요합니다)
      • 하나의 Container에서 많은 리소스를 할당하면 다른 Container에 제공할 리소스가 부족해 질수 있습니다.
    • 큰 영구 저장소영역(GB~TB)이 필요합니다.
      • 이미지설정시 데이터영역(VOLUMN)은 공유스토리지혹은 NFS를 사용해야합니다.
    • 고가용성 구성, 성능, 보안, 백업관리가 중요합니다.
      • 데이터베이스를 Native한 기술들을 구성하기에 제약사항이 있으며, 데이터베이스 aware하는 기술들로 관리해야합니다.

오라클 데이터베이스는 Container 환경에서 운영할수 있는 두가지 방법을 제공하고 있습니다.

  • Kubernetes환경을 지원하기 위한 Oracle Operator를 제공하고 있습니다.
  • 데이터베이스 엔진에 Container 개념을 이용한 In-Database Container 기술을 제공(Multitenant)합니다.

Multitenant 아키텍쳐의 방향성

Multitenant 아키텍처는 하나의 Container DB에서 여러 개의 Pluggable DB를 관리하는 형태로 나타납니다. 하나의 Container DB에 올릴 수 있는 Pluggable DB의 개수가 200개를 넘게 관리할수 있기 때문에 기본적으로 데이터베이스통합(Consolidation)에 최적화 된 데이터베이스 기술을 제공합니다.

DB의 통합 운영 환경을 제공

Multitenant 아키텍쳐는 기본적으로 여러개의 데이터베이스를 통합으로 관리하는데 목적이 있습니다. Container DB는 리소스 풀를 관리하고 그위에 애플리케이션에서 접근하여 데이터가 엑세스 되는 Pluggable DB간 리소스 경합을 줄이는 기능은 SLA 유지를 위해서 필수적인 기능입니다.

  • 리소스 관리 방법
    • CPU, Memory(SGA, PGA), IOPS, Storage, Session 등 각 Pluggable DB레벨에서 관리할수 있는 리소스들입니다.
    • 리소스 관리 방법은 최소와 최대 값으로 관리가 가능합니다. 리소스 여유가 있는 Container DB에서는 Pluggable DB에 더 많은 리소스를 할당할수 있고, Pluggable DB 생성이 많아지면 각 Pluggable DB별로 요구되는 리소스는 제공해줘야하기 때문입니다.
  • 인스턴스 구성 방법
    • Container DB레벨에서 인스턴스를 RAC로 할지 Single구성할지가 정해집니다. 따라서 위에 올라가는 Pluggable DB도 같은 속성을 따라 갈수 밖에 없습니다. 그러나 Container DB가 RAC로 구축되어 있어도 Pluggable DB에서는 single로 운영하거나 RAC로 운영할수 있도록 서비스로 제어가 가능합니다.
    • 또한 해당 DB의 업무 수준이 높아져 Single에서 RAC로 전환해야되는경우 RAC환경의 Container DB로 이동하게 되면 자동 Pluggable DB또한 single에서 RAC로 변경됩니다.

DB 통합하여 운영한다면 기존 운영시스템에 대해서 더 높은 운영수준이 필요합니다. 따라서, 인프라 이중화는 필수, 추가적으로 재해 복구(DR) 정책을 함께 수립하여 더 견고한 운영 환경을 만들어야 합니다

모든 인프라위에 DB 유연성 확보

Multitenant에서 가장 중요한 기능은 Pluggable DB들의 이동 기술입니다. DB 자체가 쉽게 이동한다는 개념이 생소할 수 있지만, Container DB가 구성되어 있는 환경에서 Pluggable DB들이 쉽게 이동할 수 있습니다. 이동에는 여러 가지 기능들이 내포되어 있습니다.

  • 마이그레이션 및 업그레이드를 쉽게 지원합니다.
    • Container DB 레벨에서 데이터베이스 버전이 결정됩니다. Pluggable DB가 상위 버전의 Container DB로 이동하면 자동으로 마이그레이션되고 업그레이드까지 완료됩니다. 이전에 경험하지 못한 획기적인 기능입니다.
  • 개발 환경을 쉽게 구성할 수 있습니다.
    • Clone 기능을 사용하여 운영 환경에서 테스트 환경을 만들거나, Snapshot Copy 기술을 사용하여 적은 용량으로 여러 테스트 환경을 구성할 수 있습니다.
  • 모든 인프라 간에 가용성을 제공하는 환경으로 구성할 수 있습니다.
    • Pluggable DB 레벨에서 DataGuard 구성을 지원합니다. 그러므로 A 데이터 센터에 있는 Container DB와 B 데이터 센터에 있는 Container DB 사이에 상호 가용성을 지원하는 환경을 구성할 수 있습니다.

마무리

오라클 데이터베이스가 제공하려는 Multitenant 아키텍쳐의 방향성에 대해서만 간단히 알아보았습니다. Multitenant의 목적은 모든 인프라를 연결하고 가상화환경위에 데이터베이스를 서비스화하여 인프라의 유연성과 확장성을 제공하는 것이라고 생각합니다. On-Premise 환경과 Cloud 환경 간에 데이터베이스 아키텍처 기술로 DB의 이동이 쉬워진다는 것이 하나의 예시입니다.

Multitenant구성요소인 Container DB와 Pluggable DB에 대한 컨셉과 추가적인 명령어를 습득한다면 좀더 효율적으로 DB운영할수 있게 될것입니다.

댓글남기기

참고