기술나눔

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

1. 컨셉

다중 테넌트는 단일 테넌트에 해당합니다. 이 문서는 단일 테넌트에 중점을 둡니다.

1.1 다중 테넌시

멀티 테넌트(Multi-tenant) 기술, 또는 멀티 테넌시(Multi-tenancy) 기술은 SaaS라고도 하며 다중 사용자 환경(여기서 다중 사용자는 일반적으로 기업 사용자를 의미함)에서 동일한 시스템이나 프로그램 구성 요소를 공유하는 방법을 구현하는 소프트웨어 아키텍처 기술입니다. 사용자 간의 데이터 격리를 보장할 수 있습니다. 간단히 말해서 단일 애플리케이션 인스턴스가 서버에서 실행되고 여러 테넌트(고객)에게 서비스를 제공합니다. 정의를 통해 우리는 다음을 이해할 수 있습니다.멀티 테넌시는 여러 사용자가 동일한 프로그램 세트를 사용할 수 있도록 하고 사용자 간의 데이터 격리를 보장하는 것을 목표로 하는 아키텍처입니다.

1.2 단일 테넌트

단일 테넌트와 다중 테넌트 아키텍처의 차이점은 단일 테넌트가 각 사용자에 대해 별도의 소프트웨어 애플리케이션과 지원 환경을 생성한다는 것입니다. 단일 테넌트 SaaS는 지리적 위치나 더 높은 수준의 보안 제어가 필요하기 때문에 고객이 사용자 지정을 지원해야 하는 애플리케이션에서 널리 인용됩니다. 단일 테넌트 모델을 통해 각 고객은 독립된 서버 또는 강력한 보안 조치를 통해 격리된 가상 네트워크 환경에 데이터베이스 및 운영 체제의 복사본을 갖게 됩니다.

1.3 단일 테넌트와 다중 테넌트의 차이점

1. 다양한 수준의 보안 제어가 있습니다. 다중 테넌트 데이터베이스는 여러 독립 테넌트의 데이터를 저장하지만 보안 격리 수준은 여전히 ​​단일 테넌트보다 높습니다. 단일 테넌트에는 독립적인 소프트웨어 및 하드웨어 환경이 있고 데이터베이스에는 단일 테넌트의 데이터만 저장되므로 기술적으로 데이터 유출 가능성이 제거됩니다. 보안 제어가 필요한 특정 산업이나 심지어는 단일 테넌트 아키텍처가 더 적합한 경우도 있습니다. 법적 준수 요구 사항.
2. 데이터 백업의 복잡성은 다양합니다. 단일 테넌트가 독립된 데이터베이스를 보유하고 있어 고객 데이터베이스의 백업 및 복구가 매우 쉽습니다. 다중 테넌트는 데이터베이스를 공유하며 테넌트 데이터는 모두 격리되어 공유됩니다. 시스템은 매일 기업의 독립적인 백업을 자동으로 수행할 수 없습니다.
3. 컨트롤 업그레이드 시간은 다양합니다. 다중 테넌트 시스템 유지 관리 비용이 저렴하고, 다중 테넌트 시스템을 업그레이드할 때 한 번만 업데이트하면 됩니다. 유지 관리 담당자는 각 사용자를 업데이트할 필요가 없으므로 운영 및 유지 관리 비용이 많이 절약됩니다. 이는 모든 클라이언트가 동일한 작업을 수행하는 시스템에 유용합니다. 그러나 기업이 특히 바쁜 시기에 시스템 업그레이드 시기가 발생한다면 필연적으로 기업 사용자에게 영향을 미치게 됩니다.

적용 시나리오: 멀티 테넌시는 동일한 그룹(회사) 내의 여러 다른 회사(부서)에 적합합니다. 데이터가 유출되더라도 외부로 유출되지 않습니다.

2. 다중 테넌트 데이터 격리 솔루션

• 독립 데이터베이스
• 공유 데이터베이스, 독립 스키마
• 공유 데이터베이스, 공유 스키마, 공유 데이터 테이블

2.1 독립 데이터베이스

이는 하나의 테넌트와 하나의 데이터베이스로 구성된 첫 번째 솔루션입니다.이 솔루션은 최고 수준의 사용자 데이터 격리와 최고의 보안을 제공하지만 비용이 더 높습니다.。

• 장점: 다양한 테넌트에 대해 독립적인 데이터베이스를 제공하면 데이터 모델의 확장 설계를 단순화하고 다양한 테넌트의 고유한 요구 사항을 충족하는 데 도움이 됩니다. 오류가 발생하면 데이터를 복원하는 것이 상대적으로 간단합니다.
• 단점: 데이터베이스 설치 수가 늘어나 유지 관리 비용과 구입 비용이 증가합니다.

이 솔루션은 기존의 단일 고객, 단일 데이터 세트, 단일 배포 세트와 유사합니다. 유일한 차이점은 소프트웨어가 운영자에게 균일하게 배포된다는 것입니다. 매우 높은 데이터 격리 수준을 요구하는 은행, 병원 등의 임차인이 있는 경우 이 모델을 선택하여 임대 가격을 높일 수 있습니다. 가격이 낮고 제품이 저가 경로를 택하는 경우 일반적으로 이 솔루션은 운영자에게 적합하지 않습니다.

2.2 공유 데이터베이스, 독립 스키마

이는 두 번째 솔루션입니다. 즉, 여러 테넌트 또는 모든 테넌트가 데이터베이스를 공유하지만 각 테넌트에는 스키마(사용자라고도 함)가 있습니다. 기본 라이브러리는 예를 들어 DB2, ORACLE 등입니다. 하나의 데이터베이스 아래에 여러 SCHEMA가 있을 수 있습니다.

• 장점: 보안 요구 사항이 더 높은 테넌트에 대해 어느 정도 논리적 데이터 격리를 제공하지만 완전한 격리는 불가능합니다. 각 데이터베이스는 더 많은 수의 테넌트를 지원할 수 있습니다.
• 단점: 오류가 발생하면 데이터베이스 복원에 다른 테넌트의 데이터가 포함되므로 데이터 복구가 어렵습니다. 테넌트 간 통계가 필요한 경우 특정 어려움이 있을 수 있습니다.

2.3 공유 데이터베이스, 공유 스키마, 공유 데이터 테이블

이것이 세 번째 옵션이고, 즉, 테넌트는 동일한 데이터베이스와 스키마를 공유하지만 테이블에 TenantID 다중 테넌트 데이터 필드를 추가합니다.공유 수준은 가장 높고 격리 수준은 가장 낮은 모드입니다.。
즉, 데이터가 삽입될 때마다 고객 ID가 필요합니다. 이러한 방식으로 동일한 테이블에서 서로 다른 고객의 데이터를 구분할 수 있습니다.

• 장점: 세 가지 옵션 비교,세 번째 옵션은 유지 관리 및 구입 비용이 가장 낮으며 데이터베이스당 가장 많은 수의 테넌트를 허용합니다.。
• 단점: 가장 낮은 격리 수준과 가장 낮은 보안으로 설계 및 개발 중에 더 많은 보안 개발이 필요합니다. 데이터 백업 및 복구가 가장 어렵고 테이블별 백업 및 복원이 필요합니다.이 솔루션은 가장 적은 수의 서버로 가장 많은 테넌트에게 서비스를 제공하고 테넌트가 더 낮은 비용을 대가로 격리 수준을 희생하는 것을 허용하는 경우에 가장 적합합니다.。

2.4 요약

SaaS 구현 프로세스 중에는 다중 테넌트를 지원하기 위해 애플리케이션 데이터를 설계하는 방법에 대한 분명한 고려 사항이 있습니다. 이 설계의 아이디어는 데이터 공유, 보안 격리 및 성능 간의 균형을 유지하는 것입니다.세 가지 모드의 특징을 한 장의 사진으로 요약하면