OCI의 다중 테넌트 애플리케이션 배포 모델
테넌시 정보
OCI 테넌시를 SaaS 애플리케이션의 테넌트 개념과 혼동하지 않는 것이 중요합니다.
OCI 테넌시: OCI 서비스에 등록할 때 수신하는 계정입니다. 루트 계정을 나타내며 OCI 리소스를 구성하고 관리하는 격리된 보안 분할 영역 역할을 합니다.
테넌트(SaaS 컨텍스트): ISV가 OCI에 SaaS 플랫폼을 구축한다고 가정합니다. ISV가 자체 고객을 플랫폼에 프로비저닝할 때 이러한 각 고객은 테넌트로 간주됩니다. 이러한 의미에서 테넌트는 고객 조직을 나타내며, 각 테넌트는 여러 사용자가 연관될 수 있습니다.
즉, OCI 테넌시는 OCI 계정 자체를 나타내고, 테넌트는 ISV와 같은 다른 엔티티가 OCI에서 호스팅하는 애플리케이션을 사용하는 조직(예: SaaS 고객)을 나타냅니다.
구조
이 아키텍처는 높은 수준의 OCI에서 다중 테넌트 애플리케이션 배포 모델을 나타냅니다.
다음 다이어그램은 이 참조 구조를 보여줍니다.
이 유연한 아키텍처는 다음과 같은 세 가지 계층으로 구성됩니다.
| 층 | 용도 | 키 작업 |
|---|---|---|
| 초기 인증(OCI IAM) | 전역 ID 확인 | 인증서 검증 후 JSON 웹 토큰(JWT) 발행 |
| 인증 미들웨어 | 요청별 신원 확인 | JWT에서 테넌트 및 사용자 컨텍스트 추출 |
| 데이터 액세스 계층 또는 ORM 후크 | 데이터 격리 적용 | tenant_id별로 모든 쿼리를 자동으로 필터링합니다. |
각 계층은 아래에 설명되어 있습니다.
초기 인증 및 테넌트 컨텍스트 설정
- 인증 서비스: 일반적으로 사용자는 테넌트별 URL(예: mycompany.app.com)을 사용하거나 로그인 중 테넌트를 선택하여 로그인합니다.
- ID 제공자로서의 OCI ID 및 액세스 관리(OCI IAM): OCI IAM(특히 전용 ID 도메인)은 사용자의 인증서를 검증합니다. 결정적으로 사용자가 유효할 뿐만 아니라 액세스하려는 특정 테넌트 그룹(예: mycompany-users)의 멤버임을 확인합니다.
- JWT 발행: 인증이 성공하면 OCI IAM ID 도메인이 서명된 JWT(JSON 웹 토큰)를 발행합니다. 이 토큰에는 다음과 같은 중요 클레임이 포함됩니다.
- sub: 사용자의 고유 식별자입니다.
- 그룹: 사용자가 속한 IAM 그룹에 대한 OCID 배열입니다. 테넌트를 식별하는 열쇠입니다.
- 사용자정의 클레임(예:
tenant_id또는tenant_name)은 OCI IAM의 사용자 정의 속성을 사용하여 추가할 수 있습니다. (선택사항)
인증 미들웨어 – "Who" 계층
백엔드는 테넌트 컨텍스트를 안전하게 추출하고 전파하도록 설계되어야 합니다. 이 아키텍처는 OCI API 게이트웨이 또는 OCI 로드 밸런서를 사용하여 요청별 인증 및 테넌트 컨텍스트 전달을 수행할 수 있도록 지원합니다.
- OCI API Gateway: 권장되는 시작점입니다. JWT 검증 자체를 수행하여 애플리케이션 코드에서 이 권한을 오프로드할 수 있습니다. OCI IAM ID 도메인의 JWKS 끝점에 대해 서명을 검증하도록 구성합니다.
- OCI 로드 밸런서: SSL 종료 및 경로 지정을 처리할 수 있지만 검증을 위해 JWT를 인증 미들웨어로 전달합니다.
조치: OCI API Gateway는 JWT의 서명 및 만료를 검증합니다. 부적합하면 요청이 즉시 거부됩니다. 적합한 경우 요청을 업스트림 서비스로 전달하고, 종종 검증된 토큰 또는 추출된 청구를 헤더에 전달합니다(예: X-USER-ID, X-TENANT-ID).
OCI API 게이트웨이 대신 OCI 로드 밸런서를 사용하는 경우 애플리케이션 백엔드의 첫번째 구성요소는 인증 미들웨어여야 합니다.
조치: Authorization: Bearer <token> 헤더에서 JWT를 추출하고, OCI IAM의 퍼블릭 키를 사용하여 서명을 확인하고, 클레임을 디코딩하고, user_id 및 tenant_id(그룹 클레임에서 파생됨)을 모든 후속 계층에서 사용할 요청 컨텍스트에 삽입합니다.
데이터 액세스 계층 또는 ORM(객체 관계형 매퍼) 후크 – "What" 계층
이 층은 모든 SQL 질의에 테넌트 ID를 자동으로 주입합니다.
- 예:
getAllInvoices()에 대한 호출은SELECT * FROM invoices WHERE tenant_id = :tenant_id로 변환됩니다. - 강제 수행: 인적 오류를 방지하기 위해 중앙 집중식 데이터 액세스 계층이나 ORM(예: 최대 절전 모드) 후크 또는 "테넌트 인식" 연결 풀에 의해 가장 잘 적용됩니다.
- ORM 후크: 응용 프로그램 프레임워크 레벨에서 데이터베이스 작업을 가로채고 수정하여 실제 암시적 테넌트 격리를 사용으로 설정하는 방식입니다.
테넌트 데이터 격리 전략:
이 아키텍처는 테넌트의 데이터를 격리하고 보호하기 위한 두 가지 옵션을 지원합니다.
옵션 1: 애플리케이션 레벨
ORM 후크/범위: Hibernate(Java), Django ORM(Python) 또는 Eloquent(PHP)와 같은 프레임워크를 사용하면 특정 모델의 모든 쿼리에 테넌트 필터를 자동으로 추가하는 전역 범위를 정의할 수 있습니다.
또는
옵션 2: 데이터베이스 레벨
식별기 열, 테넌트당 별도의 스키마 또는 테넌트당 별도의 데이터베이스를 사용할 수 있습니다.
- 식별기 열(가장 공통):
tenant_id열은 모든 테넌트별 테이블 또는 문서에 추가됩니다.응용 프로그램의 DAL(데이터 액세스 계층) 또는 ORM은 모든 질의에
WHERE tenant_id = ?절을 자동으로 추가합니다. 이는 다음을 통해 수행됩니다.- 저장소 패턴: 모든 데이터베이스 액세스는 중앙 클래스 또는 클래스 집합을 통해 흐릅니다. 이 저장소는 현재 요청 컨텍스트의
tenant_id를 기반으로 모든 SELECT, INSERT, UPDATE 및 DELETE 작업에 테넌트 필터를 자동으로 추가합니다. - 접속 컨텍스트: 일부 SQL 데이터베이스(예: Oracle HeatWave MySQL)의 경우 애플리케이션은 세션 변수(예:
SET @tenant_id = 'mycompany123';)를 설정한 다음 뷰 또는 내장 프로시저에서 사용할 수 있습니다. 그러나 응용 프로그램 계층은 연결당 이 값을 설정합니다.
- 저장소 패턴: 모든 데이터베이스 액세스는 중앙 클래스 또는 클래스 집합을 통해 흐릅니다. 이 저장소는 현재 요청 컨텍스트의
- 테넌트당 스키마:
각 테넌트에는 동일한 데이터베이스 인스턴스 내에 전용 데이터베이스 스키마가 있습니다.
테넌트 ID를 기반으로 하는 응용 프로그램 논리는 데이터베이스 연결의 현재 스키마를 전환해야 합니다.
- 테넌트당 연결 풀: 테넌트의 스키마(예:
USE tenant_mycompany;)를 사용하도록 각 연결이 미리 구성된 각 테넌트에 대해 별도의 연결 풀을 유지 관리합니다. - 동적 접속 전환: 현재 tenant_id를 기반으로 체크아웃 시 스키마를 설정하는 접속 풀을 사용합니다(예: PostgreSQL에 대해
SET search_path TO tenant_mycompany;명령 사용).
- 테넌트당 연결 풀: 테넌트의 스키마(예:
- 테넌트당 데이터베이스:
각 테넌트에는 Bring Your Own Keys Encryption for Enterprises와 물리적으로 분리되는 자체 데이터베이스 인스턴스가 있습니다.
tenant_id를 올바른 데이터베이스 연결 문자열에 매핑하려면 응용 프로그램에 테넌트 데이터 조회 서비스가 필요합니다.- 응용 프로그램은 여러 데이터베이스에 대한 연결 풀을 보유합니다.
- DAL은 요청 컨텍스트에서 테넌트 ID를 사용하여 풀에서 올바른 연결을 얻고 전용 테넌트 데이터베이스에서 쿼리를 실행합니다.
이 옵션은 장점과 단점이 있습니다.
- 프로: 최대 격리, 보안 및 성능. 테넌트는 데이터베이스 버전이나 엔진 유형이 다를 수도 있습니다.
- Cons: 가장 높은 운영 오버헤드, 비용 및 복잡성. 데이터베이스 이전 및 패치는 모든 테넌트 데이터베이스에서 실행되어야 합니다.
이 구조는 다음 구성 요소를 구현합니다.
- Tenancy
테넌시는 OCI에 등록할 때 Oracle이 Oracle Cloud 내에서 설정하는 안전하고 격리된 파티션입니다. 테넌시 내에서 OCI에서 리소스를 생성, 구성 및 관리할 수 있습니다. 테넌시는 회사 또는 조직과 동의어입니다. 일반적으로 회사는 단일 테넌시를 가지며 해당 테넌시 내의 조직 구조를 반영합니다. 단일 테넌시는 대개 단일 구독과 연관되며, 단일 구독에는 일반적으로 하나의 테넌시만 있습니다.
- OCI Identity and Access Management
Oracle Cloud Infrastructure Identity and Access Management(IAM)는 OCI 및 Oracle Cloud Applications에 대한 사용자 액세스 제어를 제공합니다. IAM API 및 사용자 인터페이스를 통해 ID 도메인 및 해당 도메인 내의 리소스를 관리할 수 있습니다. 각 OCI IAM ID 도메인은 독립형 ID 및 액세스 관리 솔루션 또는 다른 사용자 모집단을 나타냅니다.
- 로드 밸런서
Oracle Cloud Infrastructure Load Balancer는 단일 시작점에서 여러 서버로의 자동 트래픽 분산을 제공합니다.
- OCI API 게이트웨이
Oracle Cloud Infrastructure API Gateway를 사용하면 네트워크 내에서 액세스할 수 있고 필요한 경우 퍼블릭 인터넷에 노출할 수 있는 프라이빗 끝점이 있는 API를 게시할 수 있습니다. 엔드포인트는 API 검증, 요청 및 응답 변환, CORS, 인증 및 권한 부여, 요청 제한을 지원합니다.
- Oracle Key Management Cloud Service
OCI 키 관리 서비스 OCI(Oracle Cloud Infrastructure) 키 관리 서비스(KMS)는 OCI에 저장된 데이터에 대한 암호화 키의 중앙 집중식 관리 및 제어를 제공하는 클라우드 기반 서비스입니다. OCI KMS는 고객 관리형 암호화 기능으로, OCI Vault(Virtual Vault 및 Private Vault 모두), OCI Dedicated KMS, OCI External KMS 서비스를 제공합니다.
- OCI 컴퓨팅
Oracle Cloud Infrastructure Compute를 사용하면 클라우드에서 컴퓨트 호스트를 프로비저닝하고 관리할 수 있습니다. CPU, 메모리, 네트워크 대역폭 및 스토리지에 대한 리소스 요구 사항을 충족하는 쉐이프를 사용하여 컴퓨트 인스턴스를 실행할 수 있습니다. 컴퓨팅 인스턴스를 생성한 후에는 안전하게 액세스하고, 재시작하고, 볼륨을 연결 및 분리하고, 더 이상 필요하지 않을 때 종료할 수 있습니다.
- OCI 기능
Oracle Cloud Infrastructure Functions는 완전 관리형 멀티테넌트, 확장성이 뛰어난 온디맨드 Functions-as-a-Service(FaaS) 플랫폼입니다. 그것은 Fn 프로젝트 오픈 소스 엔진에 의해 구동 됩니다. OCI 함수를 사용하면 코드를 배포하고 직접 호출하거나 이벤트에 대한 응답으로 트리거할 수 있습니다. OCI Functions는 Oracle Cloud Infrastructure Registry에서 호스팅되는 Docker 컨테이너를 사용합니다.
- OCI Kubernetes 엔진
Oracle Cloud Infrastructure Kubernetes Engine(OCI Kubernetes Engine 또는 OKE)은 컨테이너화된 애플리케이션을 클라우드에 배치하는 데 사용할 수 있는 확장 가능한 완전 관리형 고가용성의 서비스입니다. 애플리케이션에 필요한 컴퓨트 리소스를 지정하고 OKE가 기존 테넌시의 OCI에서 프로비저닝합니다. OKE는 Kubernetes를 사용하여 호스트 클러스터 전반에 걸쳐 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화합니다.
- Oracle HeatWave MySQL
Oracle MySQL Database Service는 개발자가 세계에서 가장 인기 있는 오픈 소스 데이터베이스를 사용하여 안전한 클라우드 전용 애플리케이션을 신속하게 개발하고 배포할 수 있는 완전 관리형 데이터베이스 서비스입니다. Oracle HeatWave MySQL은 분석 및 트랜잭션 쿼리를 위한 MySQL 성능을 가속화하는 Oracle MySQL Database Service용 새롭고 통합된 고성능 인메모리 쿼리 가속기입니다.
- Oracle NoSQL Database Cloud Service
Oracle NoSQL Database Cloud Service를 사용하면 개발자가 문서, 고정 스키마 및 키-값 데이터베이스 모델을 사용하여 애플리케이션을 쉽게 구축할 수 있으므로 고가용성을 위한 데이터 복제를 통해 10밀리초 미만의 예측 가능한 응답 시간을 제공할 수 있습니다. 이 서비스는 온프레미스 Oracle NoSQL Database와의 100% 호환성을 포함하여 온디맨드 및 프로비저닝된 용량 모드 모두에 대해 활성-활성 지역 복제, ACID 트랜잭션, 서버리스 확장, 포괄적인 보안 및 낮은 종량제 가격을 제공합니다.
- OCI 오브젝트 스토리지
OCI Object Storage는 데이터베이스 백업, 분석 데이터, 이미지 및 비디오와 같은 리치 콘텐츠 등 모든 콘텐츠 유형의 대량의 정형 및 비정형 데이터에 대한 액세스를 제공합니다. 애플리케이션 또는 클라우드 플랫폼 내에서 직접 안전하고 안전하게 데이터를 저장할 수 있습니다. 성능 또는 서비스 안정성이 저하되지 않고 스토리지를 확장할 수 있습니다.
신속하고 즉각적이며 자주 액세스하는 데 필요한 "핫" 스토리지에 표준 스토리지를 사용합니다. 장기간 보관하며 거의 또는 거의 액세스하지 않는 "콜드" 스토리지에 아카이브 스토리지를 사용합니다.
- Oracle Autonomous Database Serverless
Oracle Autonomous Database Serverless는 Oracle Autonomous Database입니다. Oracle이 데이터베이스 배치부터 백업 및 업데이트에 이르기까지 데이터베이스 수명 주기의 모든 측면을 자율적으로 운영하는 완전히 탄력적인 데이터베이스를 보유하고 있습니다.
- 투명한 데이터 암호화
투명한 데이터 암호화(TDE)는 Oracle AI Database에서 유휴 상태의 데이터를 투명하게 암호화합니다. TDE는 Oracle AI Database와 완전히 통합되어 있으며, 전체 데이터베이스 백업(RMAN), 데이터 펌프 익스포트, 전체 애플리케이션 테이블스페이스 또는 특정 민감한 열을 암호화할 수 있습니다. 암호화된 데이터는 테이블스페이스 저장 영역 파일, 임시 테이블스페이스, 언두 테이블스페이스 또는 리두 로그와 같은 기타 파일에 있어서도 데이터베이스에서 암호화된 상태로 유지됩니다. 이렇게 하면 응용 프로그램이 SQL을 사용하여 데이터에 액세스하는 방식에 영향을 주지 않고 데이터베이스 데이터에 대한 무단 액세스를 방지할 수 있습니다.
권장사항
- VCN
VCN을 생성할 때 VCN의 서브넷에 연결하려는 리소스 수에 따라 필요한 CIDR 블록 수와 각 블록의 크기를 결정합니다. 표준 전용 IP 주소 공간 내에 있는 CIDR 블록을 사용합니다.
프라이빗 접속을 설정하려는 다른 네트워크(Oracle Cloud Infrastructure, 온프레미스 데이터 센터 또는 다른 클라우드 제공자)와 겹치지 않는 CIDR 블록을 선택합니다.
VCN을 생성한 후 해당 CIDR 블록을 변경, 추가 및 제거할 수 있습니다.
서브넷을 설계할 때 트래픽 흐름 및 보안 요구 사항을 고려하십시오. 특정 계층 또는 역할 내의 모든 리소스를 보안 경계로 사용될 수 있는 동일한 서브넷에 연결합니다.
- 보안 목록
보안 목록을 사용하여 전체 서브넷에 적용되는 수신 및 송신 규칙을 정의합니다.
- NSG(네트워크 보안 그룹)
NSG를 사용하여 특정 VNIC에 적용되는 수신 및 송신 규칙 세트를 정의할 수 있습니다. NSG를 사용하면 VCN의 서브넷 아키텍처를 애플리케이션의 보안 요구 사항과 분리할 수 있으므로 보안 목록 대신 NSG를 사용하는 것이 좋습니다.
- Cloud Guard
사용자정의 감지기 및 응답기 레시피를 생성하도록 Oracle에서 제공하는 기본 레시피를 복제하고 사용자정의합니다. 이러한 레시피를 사용하면 경고를 생성하는 보안 위반 유형과 경고에 대해 수행할 수 있는 작업을 지정할 수 있습니다. 예를 들어 가시성이 퍼블릭으로 설정된 OCI Object Storage 버킷을 감지할 수 있습니다.
테넌시 수준에서 Oracle Cloud Guard를 적용하여 가장 광범위한 범위를 포괄하고 여러 구성을 유지 관리하는 데 드는 관리 부담을 줄입니다.
관리 목록 기능을 사용하여 감지기에 특정 구성을 적용할 수도 있습니다.
- 보안 영역
최대 보안이 필요한 리소스의 경우 Oracle은 보안 영역을 사용할 것을 권장합니다. 보안 영역은 모범 사례를 기반으로 하는 Oracle 정의 보안 정책 레시피와 연관된 컴파트먼트입니다. 예를 들어, 보안 영역의 리소스는 공용 인터넷에서 액세스할 수 없어야 하며 고객 관리 키를 사용하여 암호화해야 합니다. 보안 영역에서 리소스를 생성 및 업데이트할 때 OCI는 레시피의 정책에 대해 작업을 검증하고 정책을 위반하는 작업을 방지합니다.
고려사항
이 구조를 배치할 때는 다음 옵션을 고려하십시오.
- 성능:
- API에 대한 테넌트 기반 비율 제한 설정
- OKE에서 네임스페이스당 Kubernetes 리소스 할당량을 사용하여 테넌트당 Pod, CPU 및 메모리를 제한합니다.
- 수요가 많은 테넌트를 위한 전용 노드 풀 활용
- 데이터베이스 접속에서 테넌트당 풀 크기 설정
- 보안:
- OCI IAM 그룹은 사용자가 액세스할 수 있는 테넌트를 제어합니다. 이것은 JWT에 의해 적용됩니다.
- Oracle Cloud Guard가 잘못된 구성을 감지하도록 설정
- 비용:
테이블 레벨, 스키마 레벨 또는 엔터프라이즈 레벨 고객을 위한 전용 데이터베이스가 필요한지 여부에 관계없이 업무 요구에 따라 평가합니다. 예:
- 계층 1: 표준(Discriminator Column): 테넌트가 동일한 테이블/스키마를 공유합니다.
- 계층 2: Premium(테넌트당 스키마): 테넌트는 동일한 데이터베이스 내에서 전용 스키마를 가져옵니다.
- 계층 3: 엔터프라이즈(테넌트당 데이터베이스): 테넌트는 전용 데이터베이스 인스턴스를 가져옵니다.
- 패치 적용 및 애플리케이션 업데이트
단일 인스턴스의 다중 테넌트 SaaS 아키텍처에서는 테넌트를 모두 패치하지 않고는 하나의 테넌트에 패치를 적용할 수 없습니다. 모든 고객이 동일한 애플리케이션 코드베이스, 런타임 및 인프라를 공유합니다. 이러한 현실은 중요한 과제를 야기합니다. 전체 사용자 기반에 중단된 다운타임을 발생시키지 않고 안전하게 효율적으로 업데이트를 롤아웃하는 방법은 무엇입니까? 정답은 이러한 목적을 위해 특별히 설계된 최신 DevOps 배포 전략에 있습니다. 즉, 다운타임 없는 배포 전략을 사용하여 사용자를 오프라인으로 강제 전환하지 않고 버전 간에 원활하게 전환할 수 있습니다.
- 파란색-녹색 배치: 여기에는 "파란색"(현재 버전 실행)과 "녹색"(새 버전 실행)이라는 두 가지 동일한 운용 환경을 유지 관리하는 작업이 포함됩니다. Green에서 새 버전을 배포하고 테스트한 후 모든 트래픽을 Blue에서 Green으로 원활하게 전환할 수 있습니다. 문제가 발생하면 즉시 다시 전환하여 롤백을 비이벤트로 만듭니다. 이전 블루 환경이 폐기되었습니다.
- 카나리아 배포: 이 전략은 점진적 롤아웃을 수행하여 위험을 줄입니다. 새 버전은 사용자의 작은 제어 하위 집합("카나리")에 배치됩니다. 이 그룹에서 오류나 성능 문제를 면밀히 모니터합니다. 측정항목이 정상적으로 보이면 모든 사용자가 새 버전을 사용할 때까지 더 많은 사용자에게 업데이트를 점차적으로 롤아웃합니다.
사용자에게 필수 업그레이드 기간을 통지합니다(예: "업그레이드 날짜가 지정되지 않은 경우 자동으로 업그레이드는 일요일 12:00, mm/dd/yyyy"). 창이 끝나면 이전 버전의 세션을 종료하고 모든 트래픽을 새 버전으로 재지정합니다. 이전 응용 프로그램 코드는 완전히 종료됩니다.
- 데이터베이스 고려 사항
애플리케이션 버전을 전환하는 순간에는 데이터베이스 스키마를 전환할 수 없습니다. 대부분의 SaaS 회사는 다음을 사용하여 이를 방지합니다.
- 역호환 데이터베이스 스키마 변경 사항
- 기능 플래그/토글
- 테넌트 메타데이터 기반 버전 제어
이렇게 하면 롤아웃 중 이전 스키마 버전에 대해 새 코드가 안전하게 작동하므로 다운타임이 없는 마이그레이션 및 인스턴트 롤백이 가능합니다.