테넌트

테넌트는 데이터베이스 내에서 사용자 정의 객체를 위한 고유하고 독립적인 네임스페이스를 생성하는 데이터베이스 객체입니다. 여러 스키마를 포함한 추가 데이터베이스 개체를 테넌트 내에서 다른 데이터베이스 테넌트의 유사한 개체와 이름 충돌에 대한 우려 없이 정의할 수 있습니다.

테넌트에 정의된 개체와 관련된 모든 권한은 해당 테넌트 내에서 상주하며 관리됩니다. 또한 테넌트에 대한 액세스는 새로운 테넌트 사용 권한에 의해 명시적으로 제어되어 또 다른 수준의 제어를 제공합니다.

그림 1. Db2 데이터베이스에서 테넌트를 사용한 네임스페이스 분리
이점

데이터베이스 테넌트 개념을 사용하면 각 사용자가 사용하는 개체 이름의 충돌이나 해당 개체 내의 데이터가 실수로 노출될 염려 없이 여러 독립 사용자(또는 애플리케이션)가 동일한 데이터베이스를 사용하도록 할 수 있습니다. 격리 네임스페이스 기능은 여러 가지 방법으로 활용할 수 있습니다:

  • 소규모 단일 사용자 테스트 데이터베이스를 여러 테넌트가 있는 하나의 공유 데이터베이스로 통합하여 고정 간접비를 줄이고 운영을 간소화할 수 있습니다.
  • 단일 공유 데이터베이스 환경 내에서 동일한 애플리케이션을 여러 개의 독립적인 배포로 인스턴스화할 수 있습니다.
  • 프로덕션 환경에서 흔히 볼 수 있는 고유한 하드웨어 구성을 공유하여 프로덕션 데이터에 대한 오염이나 실수로 인한 액세스 위험 없이 애플리케이션 업데이트를 프로덕션으로 이동하기 전에 고급 테스트를 수행할 수 있습니다.
  • 애플리케이션이나 개체 이름을 변경할 필요 없이 기존 멀티테넌트 구현을 통해 다른 데이터베이스에서 쉽게 마이그레이션할 수 있습니다.
제한사항

장점은 크지만 데이터베이스에 테넌트를 구현하기 전에 다음과 같은 제한 사항을 고려해야 합니다:

  • 실수로 잘못된 스키마를 쿼리하는 것을 방지하려면 쿼리를 실행할 때 스키마 접두사를 포함해야 합니다.
  • 리소스 격리가 없으므로 테넌트는 동일한 처리 능력과 저장 공간을 공유합니다. 리소스 공유의 경우 모든 테넌트는 동일한 카탈로그 테이블 공간을 공유하며, 데이터 격리는 기본 설정이 아니므로 테넌트는 테이블과 인덱스에 대해 동일한 테이블 공간을 공유할 수 있습니다. 또한 버퍼 풀과 CPU 사이클은 모든 테넌트에서 완전히 공유됩니다.
  • 스키마 접두사의 필요성은 이번 릴리스에서 변경되지 않았습니다. 네임스페이스 접두사는 시스템 테넌트에 테이블을 포함하거나 시스템 테넌트와 현재 테넌트 모두에서 이름이 동일한 스키마 및 테이블을 포함하려는 경우 필요합니다.
  • 사용자 정의 테넌트 수는 300명으로 제한되어 있습니다.
  • Db2® 로컬 테이블 이름과 달리, 데이터레이크 테이블 이름은 테넌트 내부뿐만 아니라 모든 테넌트에 걸쳐 고유해야 합니다. 자세한 내용은 Db2 Warehouse 에서 데이터레이크 테이블 사용을 참조하세요.

SYSTEM 테넌트

데이터베이스가 작성되면, SYSTEM이라는 기본 테넌트가 데이터베이스에 대해 정의되며 기본 데이터베이스 카탈로그와 환경을 표시합니다. SYSTEM 테넌트는 영구적이며 테넌트 정의 카탈로그에 나타나지 않습니다: SYSTEM 테넌트는 SYSCAT.TENANTS 보기에 나타나지 않습니다. SYSTEM 테넌트는 0(영)의 고유 테넌트 ID로 지정됩니다. 사용자가 데이터베이스에 처음 연결하면 사용자의 연결은 자동으로 기본 시스템 테넌트에 연결됩니다.

사용자 정의 테넌트와 달리 시스템 테넌트에는 사용 권한이 필요하지 않으며 데이터베이스의 모든 연결이 시스템 테넌트와 연결될 수 있습니다.

데이터베이스 리소스 및 제한

문서에 달리 명시되지 않는 한, 다른 모든 데이터베이스 파일과 출력도 데이터베이스 리소스로 간주되며 모든 사용자 정의 격리 네임스페이스에서 공유됩니다. 예를 들어 진단 로그, 트랜잭션 로그 및 기록 파일은 데이터베이스 리소스로 간주되며 데이터베이스의 모든 사용자 정의 격리 네임스페이스에 대한 정보를 포함합니다. 이러한 리소스에 액세스하는 명령이나 도구는 기본적으로 이러한 모든 네임스페이스에 대한 정보를 반환합니다.
데이터베이스 수준에서 공유 리소스에 적용되는 데이터베이스 및 SQL 제한은 여전히 모든 사용자 정의 격리 네임스페이스에 적용됩니다. 네임스페이스별로 적용되지 않습니다.

공유 및 비공개 시스템 카탈로그

테넌트가 정의되면 데이터베이스와 그 안에 정의된 개체에 대한 정보를 포함하는 고유한 시스템 카탈로그 테이블 세트가 제공됩니다. 이러한 개체 중 일부는 모든 테넌트가 데이터베이스 전체에서 사용할 수 있는 전역 개체로 간주됩니다. 기타는 해당 개체가 정의된 개별 테넌트만 알 수 있는 로컬 개체로 간주됩니다. 시스템 카탈로그 테이블의 구성은 공유 및 비공개 시스템 카탈로그 테이블의 개념을 도입하여 이러한 객체 정의의 구분을 반영합니다.

전 세계적으로 알려져 있고 모든 테넌트가 사용할 수 있는 데이터베이스 리소스로 간주되는 개체 집합은 모든 테넌트가 사용하는 공유 카탈로그 테이블 집합에 저장됩니다. 다음과　같은　오브젝트 를　백업할　수　있습니다．

  • 감사 대상 및 정책
  • 버퍼 풀
  • 그룹
  • 역할
  • 스토리지 정의
  • 테이블스페이스
  • 테넌트
  • 사용자
  • WLM 오브젝트

이러한 개체에 대한 정의는 모든 테넌트가 공유하는 시스템 카탈로그 테이블에 저장됩니다. 이러한 카탈로그 테이블에 정의된 개체는 모든 테넌트의 사용자에게 표시되며(사용자에게 해당 카탈로그에 액세스하는 데 필요한 권한이 있는 한), 이러한 리소스에 대한 모든 작업 및 참조는 동일한 정의 집합에 따라 작동합니다. 이러한 카탈로그를 공유 카탈로그 테이블이라고 합니다.

특정 개별 테넌트 내에서만 사용할 수 있는 개체 집합에는 다음이 포함됩니다:

  • 별명
  • 제한조건
  • 데이터 유형
  • 인덱스
  • 모듈
  • 패키지
  • 루틴
  • 스키마
  • 시퀀스
  • 테이블
  • 트리거
  • 변수

이러한 개체에 대한 정의는 각 개별 테넌트마다 고유하며 다른 테넌트에서 사용하지 않는 시스템 카탈로그 테이블에 보관됩니다. 이러한 카탈로그 테이블을 비공개 카탈로그 테이블이라고 합니다.

글로벌 데이터베이스 개체

모든 테넌트가 사용할 수 있는 시스템 카탈로그에 정의된 모든 개체를 전역 개체라고 합니다. 공유 카탈로그 테이블에 정의된 모든 개체는 모든 테넌트가 볼 수 있고 사용할 수 있으므로 사실상 글로벌 개체에 해당합니다.

또 다른 글로벌 객체 세트는 데이터베이스가 생성될 때 Db2 의해 정의된 데이터베이스 객체 세트로 표현됩니다. 이러한 개체는 데이터베이스가 생성될 때 시스템 카탈로그에 정의된 다양한 루틴, 뷰, 모듈 등입니다. 이러한 개체에 대한 정의는 기본 시스템 테넌트의 프라이빗 시스템 카탈로그에 있지만, 일반적인 Db2 환경 및 기능의 기본이 됩니다.

글로벌 데이터베이스 개체 집합은 다음과 같은 집합으로 정의됩니다:

  • 시스템 테넌트의 예약 스키마에 정의된 패키지를 포함한 모든 데이터베이스 개체입니다.
  • 예약된 패키지 이름을 사용하여 시스템 테넌트에서 NULLID 스키마로 정의된 패키지입니다.

예약된 스키마에 대한 자세한 내용은 예약된 스키마 이름 및 예약어를 참조하세요. 예약된 패키지에 대한 자세한 내용은 식별자 항목의 예약된 패키지 이름 항목을 참조하세요.

모든 테넌트 사용자가 동일한 경험을 할 수 있도록 Db2 Db2 생성한 개체를 모든 테넌트에서 사용할 수 있는 암시적 전역 개체로 취급합니다. 시스템 테넌트를 제외한 각 테넌트의 카탈로그 테이블에 명시적으로 존재하지는 않지만, 이러한 오브젝트는 SQL 컴파일러 및 기타 처리 과정에서 오브젝트 확인 중에 자동으로 포함됩니다. 이를 포함하면 모든 테넌트가 동등하게 액세스할 수 있습니다.

예를 들어 "SELECT * FROM SYSCAT.TABLES" 문이 컴파일되면 카탈로그 보기는 현재 테넌트의 비공개 카탈로그 테이블로 확인됩니다. 동일한 문이 시스템 테넌트에서 컴파일되면 시스템 테넌트 아래에 저장된 데이터베이스 전체 카탈로그 테이블로 확인됩니다.

개인 카탈로그 테이블을 나타내는 뷰에 대한 SYSCAT 뷰 정의도 일관된 환경을 유지하기 위해 수정되었습니다. 영향을 받는 뷰는 각 테넌트에 정의된 로컬 개체 외에도 쿼리 시 이러한 암시적 전역 개체도 반환합니다. 이를 식별할 수 있도록 개체가 정의된 테넌트의 이름이 뷰 출력에서 TENANTNAME 열로 표시됩니다. 암시적 전역 개체는 시스템 테넌트 이름을 반환하고 모든 로컬 개체는 현재 테넌트 이름을 반환합니다.

테넌트 내 이름 확인

개체가 테넌트로 참조되면 일반적인 이름 확인 프로세스를 따르고 필요에 따라 테넌트와 관련된 관련 시스템 카탈로그 테이블에 액세스하여 참조를 확인합니다. 테넌트가 시스템 테넌트가 아니고 오브젝트 스키마가 Db2 예약한 스키마 중 하나인 경우, Db2 암시적으로 시스템 테넌트 카탈로그 테이블에 액세스하여 Db2 제공하는 오브젝트 집합에서 일치하는 오브젝트 정의가 있는지 찾습니다.

테넌트 내 모니터링

관리 루틴(및 모든 종속 보기)의 동작은 두 가지 클래스로 나뉩니다:

  • 개별 데이터 개체에 대한 정보를 보고하는 루틴은 현재 테넌트에 있는 개체로만 출력을 제한합니다.
  • 다른 인터페이스는 데이터베이스의 모든 테넌트에 대한 출력을 반환합니다. .

현재 이벤트 모니터는 시스템 테넌트에서만 정의되지만, 이러한 이벤트 모니터는 적절한 테넌트 정보를 가진 모든 테넌트의 이벤트를 캡처하여 각 이벤트의 출처를 식별합니다.

데이터베이스 보안과 테넌트 통합

테넌트는 인증, 감사 및 암호화 영역에서 Db2 데이터베이스가 제공하는 기본 보안 인프라에 의존합니다.

기본(사용자) 및 보조(그룹, 역할) 모두 Db2 인증 ID는 데이터베이스(및 인스턴스) 수준에서 확인 및 관리됩니다. 역할은 기본 시스템 카탈로그에서만 정의되며, 역할 정의 카탈로그 테이블의 내용은 모든 테넌트에서 공유됩니다. 신뢰할 수 있는 컨텍스트 정의도 비슷한 방식으로 처리됩니다.

감사 정책 및 작업은 데이터베이스 수준에서만 정의할 수 있으며 기본 시스템 카탈로그에만 존재합니다. 감사는 데이터베이스 활동이며 테넌트 전반의 모든 활동을 포괄합니다. 특정 테넌트로 감사 정책의 범위를 지정하거나 비공개 테넌트 카탈로그에 정의된 개체에 대한 감사 정책을 정의할 수 없습니다.

암호화는 TLS(전송 계층 보안)와 기본 암호화 모두 데이터베이스 수준에서 정의되고 실행됩니다. 테넌트 수준 구성 옵션은 없습니다.

LBAC 구성 요소 및 정책 테이블은 시스템 수준에서 정의되며 모든 테넌트에서 공유됩니다. RCAC 정의는 비공개 카탈로그에 있으며 각 테넌트마다 고유합니다.

사용자 정의 격리 네임스페이스 내 권한 부여

사용자 정의 격리 네임스페이스 내의 권한은 사용자가 다양한 수준에서 사용할 수 있는 권한과 권한의 조합에 따라 결정됩니다.

권한 레벨(Authorization level) 설명
데이터베이스 모든 사용자 정의 격리 네임스페이스의 모든 개체에 적용됩니다.
테넌트 특정 사용자 정의 격리 네임스페이스로 정의된 객체에만 적용됩니다
스키마 특정 스키마로 정의된 개체에 적용됩니다
오브젝트 특정 개체에만 적용됩니다.

데이터베이스 또는 격리된 네임스페이스 수준에서 부여된 모든 권한 또는 권한은 시스템 테넌트의 카탈로그 테이블에 기록됩니다. 스키마 또는 개체 수준에서 부여된 모든 권한 또는 권한은 해당 스키마 또는 개체가 정의된 사용자 정의 격리 네임스페이스의 시스템 카탈로그 테이블에 기록됩니다.

다른 격리 네임스페이스에 있는 개체에 액세스하면 액세스가 시도된 네임스페이스가 아닌 개체가 정의된 격리 네임스페이스의 권한 정보를 사용하여 해당 액세스에 대한 권한이 확인됩니다.

예를 들어, 사용자 정의 격리 네임스페이스 TENANTA의 쿼리가 해당 격리 네임스페이스의 사용자 정의 테이블인 MYSCHEMA.T1 시스템 테넌트에 정의된 SYSPROC.MON_GET_CONNECTION 테이블 함수에서 제공하는 Db2 모두 참조하는 경우 이러한 개체에 대한 권한 확인은 이런 방식으로 해결됩니다:
MYSCHEMA.T1
이 테이블에 액세스하기 위한 권한 확인은 관련 데이터베이스 권한과 TENANTA 격리 네임스페이스 내의 관련 권한 카탈로그를 사용하여 해결됩니다. 이 함수에 액세스하는 데 필요한 테이블 권한은 테난타 격리 네임스페이스 내에서 부여해야 합니다.
SYSPROC.MON_GET_CONNECTION

Db2 테이블 함수 실행을 위한 권한 확인은 시스템 테넌트 내에서 관련 데이터베이스 권한 및 관련 권한 카탈로그를 사용하여 해결됩니다. 이 기능에 액세스하는 데 필요한 테이블 권한은 시스템 테넌트 내에서 부여해야 합니다

워크로드 관리

네임스페이스 분리 내에서 실행되는 모든 작업은 네임스페이스별 분리 없이 시스템에 대해 구성된 일반적인 데이터베이스 워크로드 관리에 참여합니다. 네임스페이스에 대해 다른 워크로드 구성을 원하는 경우 워크로드 개체에 대한 테넌트 연결 속성을 사용하여 특정 네임스페이스와 연결된 연결을 별개의 워크로드 개체로 분리하고 원하는 워크로드 구성을 해당 워크로드 개체 또는 워크로드가 연결된 서비스 클래스에 적용할 수 있습니다.

사용자 정의 격리 네임스페이스 내 SQL 동작

SQL 문의 특성에 따라 Db2 사용자 정의 격리 네임스페이스 내에서 작동하는 방식이 결정됩니다.
동적 SQL문
격리된 네임스페이스마다 고유한 카탈로그 테이블 세트가 연결되어 있으므로, 격리된 네임스페이스 내에서 준비된 모든 동적 SQL도 고유하므로 다른 사용자 정의 격리 네임스페이스 간에 공유할 수 없으며 동일한 격리된 네임스페이스와 연결된 연결 내에서만 공유할 수 있습니다. 동적 SQL 문은 패키지 캐시에 배치될 때 테넌트 ID로 한정되어 항목이 공유되지 않도록 합니다. 이 동작의 한 가지 결과는 서로 다른 테넌트 객체가 동일한 동적 SQL 문을 실행하는 경우에도 각각 패키지 캐시에 고유한 항목이 필요하다는 것입니다.
정적 SQL문
정적 SQL 문과 그 상위 패키지는 격리된 각 네임스페이스와 연결된 시스템 카탈로그에 로컬 개체로 저장됩니다. Db2 의해 전역 개체로 등록된 패키지를 제외하고는 격리된 네임스페이스 간에 패키지를 공유할 수 없습니다.
증분 바인드 문
증분 바인드 문인 정적 SQL 문은 실행될 때 참조가 해결됩니다. 이러한 문은 해당 격리 네임스페이스와 연결된 카탈로그를 사용하여 참조하는 각 격리 네임스페이스 내에서 고유하게 확인됩니다. 즉, 증분 바인드 문은 이를 참조하는 각각의 격리된 네임스페이스에서 독립적으로 해결됩니다.
예약 패키지
특정 패키지 이름 세트가 시스템 사용을 위해 명시적으로 예약되었습니다. 이러한 개체는 시스템 테넌트에서만 정의되는 글로벌 데이터베이스 개체로 간주됩니다. 예약된 이름을 가진 사용자 정의 패키지가 기본 시스템 테넌트가 아닌 격리된 네임스페이스에 있는 동안 바인딩되면 바인딩이 실패합니다(SQLCODE -4004). 예약된 이름을 사용하고 기본 시스템 테넌트가 아닌 격리된 네임스페이스에 바인딩된 시스템 제공 패키지의 경우, 시스템은 시스템 테넌트 내에서 패키지를 투명하게 바인딩합니다.

제한사항

현재 격리된 네임스페이스 환경에서는 아직 사용할 수 없는 데이터베이스 기능이 몇 가지 있습니다. 적절한 경우, 이러한 기능은 사용 시 아직 지원이 제공되지 않음을 나타내는 SQL0270N (SQLSTATE 42997) 메시지를 반환합니다.

격리 네임스페이스에서는 아직 지원되지 않는 몇 가지 주요 기능이 있습니다:

  • 테넌트별 이벤트 모니터. 이벤트 모니터는 시스템 테넌트에서만 만들 수 있으며, 이러한 이벤트 모니터는 격리된 모든 네임스페이스에서 이벤트를 수집합니다.
  • 페더레이션
  • 텍스트 검색
  • 사용 목록

데이터베이스 스키마 전송과 같은 일부 도구 및 유틸리티도 격리된 네임스페이스 내에서 사용할 수 있도록 아직 업데이트되지 않았습니다.