다중 테넌시 또는 다중 인스턴스?


11

웹 기반 SaaS 솔루션을 구축하려고하는데 다중 테넌시 또는 다중 인스턴스를 사용하지 않을지 모르는 길에 섰습니다. 나는 달성하려는 목표와 각각의 장단점 (내 의견, 내가 읽은 것에 따라)을 설명하려고 노력할 것이다. 하나의 접근 방식에서 다른 방법으로 누락 된 경우 제안을 포함하십시오.

필자가 언급 한 애플리케이션은 회사에서 계정을 만들 수있는 SaaS 솔루션이며 각 계정 / 회사마다 자체 사용자, 고객, 제품, 서비스 등이 있습니다. 각 사용자; 회사 직원은 누구입니까? 한 계정 / 회사와 관련이있는 고객은 회사 고객, 제품 및 서비스에만 액세스 할 수 있습니다. 회사는 고객, 제품 및 서비스를 무제한으로 가질 수 있으므로 각 회사마다 자체 데이터 센터가 있어야합니다.

이를 위해 공유 데이터베이스 (로그인 목적으로 모든 사용자 자격 증명 저장)와 여러 데이터베이스 공유 스키마 (계정 / 회사 별 데이터베이스)를 만들기로 결정했습니다. 기본적으로 다중 테넌시 .

그런 다음 누군가가 멀티 인스턴스를 대신 사용하도록 제안했습니다 . 각 회사는 다른 회사와 완전히 분리 된 자체 응용 프로그램 인스턴스 (예 : 코드, 라이브러리, 데이터베이스, 프레임 워크 등)를 갖습니다. 각 테넌트 사용자가 회사 데이터에만 액세스 할 수 있도록 추가 계층을 관리 할 필요가 없기 때문에 더 잘 들립니다. 나는 이 접근법을 달성하기 위해 Docker 에 의존하고 있다고 언급하는 것이 좋다고 생각하지만 (이전에 사용하지는 않았지만) 나중에 필요한 기능이 부족하다고 생각합니다 (적어도 나는하지 않았습니다) 약간의 검색만으로는 찾을 수 없습니다).

그러나 각 접근 방식에는 장단점이 있으므로 어떤 접근 방식을 결정할 수 없었습니다. 여기에 목록이 있지만 둘 다에 대한 지식이 없기 때문에 나에게 알지 못합니다. 알지 못하는 것이 있거나 웹에서 찾지 못한 문제에 대한 해결책이있을 수 있습니다. 순서대로 비교 한리스트

멀티 테넌시 :

  1. 공유 호스트 / 하드웨어, 공유 코드 및 다중 데이터베이스
  2. 그것은이다 쉽게 코드와 수정 버그의 기능 (공유 코드)를 확장 할 수 있습니다.
  3. 코드를 변경하지 않고 하드웨어를 확장하거나 (클라우드 서비스를 사용할 수 있음) 개별 테넌트의 데이터베이스를 다른 시스템으로 옮기기 가 더 어렵 습니다.
  4. 가장 중요한 것은 앞에서 언급했듯이 사용자가 실제로 자신의 회사에 속하고 다른 회사의 정보에 액세스하지 못하도록 시스템에 추가 계층을 추가해야합니다.

다중 인스턴스 :

  1. 공유 또는 비공유 호스트 / 하드웨어, 인스턴스 당 코드 및 인스턴스 당 데이터베이스
  2. 그건 힘들어 (나는 당신이 하나 개의 인스턴스 또는 도커 용기에 기능 / 기능을 추가하고, 다른 사람에게 배포 할 수있는 부두 노동자에 그것을 할 수있는 방법이 있는지 모르겠어요) 기능 또는 수정 버그를 확장 할 수 있습니다.
  3. 그건 쉽게 다른 호스트 / 하드웨어로 전체 인스턴스를 이동합니다.
  4. 인스턴스로서, 각 인스턴스마다 고유 한 데이터베이스가 있으므로 해당 계층을 관리 할 필요가 없습니다.

수동으로 작업을 수행하려는 경우 (각 테넌트에 대한 인스턴스를 수동으로 작성하는 경우) 모든 장점과 단점이 중복되므로 해결할 수있는 방법이 없다면 Docker 솔루션을 의심합니다. 질문의 이유. 솔루션에 대한 참조로 질문에 대답 하고이 접근법이 다른 방법보다 낫다고 생각하는 이유에 대해 감사드립니다.

도움이 될 것 같으면 Laravel백엔드 의 기본 프레임 워크로 사용합니다 (모두 RESTfully).


하나의 데이터베이스에 모두 넣을 수도 있습니다. 자격 증명을 단일 데이터베이스에 저장하는 경우 나머지 데이터를 분할 할 시점이 보이지 않습니다.
GrandmasterB

각 테넌트의 데이터를 분리하는 요점을 놓친 것 같습니다. 공유 데이터베이스는 로그인 전용입니다.
Asher

아니요, 요점을 보았습니다. 단일 데이터베이스를 사용하는 것과 비교하여 그렇게하면 불필요한 복잡성 이외의 것을 얻을 수 있다는 데 동의하지 않습니다.
GrandmasterB

각 테넌트에는 엄청난 양의 데이터 (고객, 서비스, 제품 등)가 있으므로 성능 / 보안 문제로 각 테넌트 데이터를 다른 데이터 센터 / 데이터베이스로 분리하고 싶습니다.
Asher

@Anas 두 가지 옵션 중 일부를 결정 했습니까? 그리고 왜? answare는 같은 질문을 가진 사람들에게 유용 할 것입니다 (나처럼)
alecardv

답변:


8

나는 지금 나에게 똑같은 질문을하고있다.

다중 인스턴스 단일 테넌시 솔루션을 기대하고 있지만 아직 결정적인 결정을 내리지 못했습니다. 내 생각 중 일부를 공유하겠습니다.

멀티 - 테넌트 아키텍처의 주요 역사적 장점이있다 인프라 리소스를보다 효율적으로 사용 함으로써, mutualisation (단일 OS, 단일 데이터베이스, 단일 애플리케이션 레이어) 나은 상기 리소스 점유 (하나의 사용자 인 경우 얻어 다른 동일한 자원을 사용할 수 있음) .

또한 소프트웨어 수명주기를 크게 간소화합니다 . 하나의 인스턴스에 새 버전을 배포하면 모든 고객이 동시에 업데이트됩니다.

그러나 최근 클라우드 기술의 발전으로 인해 다중 인스턴스 (고객 별 인스턴스) 아키텍처에서 첫 번째 클래스의 이점을 크게 활용할 수있는 것으로 보입니다 (여기서는 Jelastic과 같은 플랫폼을 구체적으로 생각하고 있지만 다른 것들은 확실합니다. 동일한 기능을 제공하십시오) :

  • 컨테이너 기반 PaaS
  • 컨테이너 (탄성 컨테이너)의 프로비저닝 및 자동 확장

따라서 하드웨어 및 플랫폼 관리는 더 이상 소프트웨어 제공 업체의 관심사가 아닙니다. 자원은 인프라와 플랫폼 수준에서 이전보다 훨씬 효율적으로 상호 작용합니다 .

다중 인스턴스에 대한 오버 헤드는 여전히 있지만 (일부 앱 대신 미들웨어가 N 번 실행 됨) 인스턴스 당 별도의 (가상) 머신을 사용할 때보 다 훨씬 낮습니다. 어쨌든 데이터베이스를 공유 할 수 있습니다 (인스턴스 당 하나의 스키마, DB 서버 당 여러 스키마)

또한 :

  • PaaS API를 통해 새 인스턴스 생성 자동화 가능
  • 가동 중지 시간없이 PaaS API를 통해 새 버전 배포 자동화가 가능합니다 (일부 작업이 필요함).
  • 스케일링은 항상 진행됩니다. 인스턴스 수준에서 거대한 데이터 세트에 대해 걱정할 필요가 없습니다.

물론이 모든 것을 자동으로 관리하는 일종의 중앙 서비스가 필요합니다 (예 : 새 사용자가 계정을 만들 때 인스턴스 생성). 또한 결제 및 라이센싱 문제, 인스턴스 간 상호 작용 등을 관리합니다.이 중앙 서비스는 상당히 복잡하고 개발하기 어려울 수 있지만 선결제로 구현할 필요는 없습니다. 다중 테넌트는 처음부터 앱에 구워 져야합니다.

매우 초기 단계 (사전 조사) 시작 프로젝트를 위해 단일 테넌트를 개발할 때의 최종 이점을 얻을 수 있습니다.

  • 동일한 (또는 거의 동일한) 버전의 앱 가상 어플라이언스 또는 도커 컨테이너 또는 고객 관리 시스템으로 온-프레미스에 배포 할 수 있습니다 (일부 회사는 여전히 클라우드를 꺼려하고 초기 단계에서 시작하지 않도록 도울 수 있음) 중요한 얼리 어답터 푸시)
  • 제한된 리소스 (애플리케이션 계층 및 데이터베이스 스키마는 훨씬 덜 복잡함)로 제품을 더 빨리 출시하고 얼리 어답터를위한 "멍청한"단일 인스턴스 단일 테넌트 제품 우선 (MVP)을 얻을 수 있으며 앱의 비즈니스 가치를 보여줄 수 있음 잠재적 인 투자자에게, 나중에 모든 클라우드 자동화를 추가하십시오
  • 데이터 보안이 걱정되는 고객에게는 판매 논쟁으로 보일 수 있습니다. 모든 고객은 자신의 스키마 나 데이터베이스를 가지고 있기 때문에 데이터가 더 잘 캡슐화 됩니다. "유출"위험이 훨씬 적음

NB : 고객이 개인이 아닌 비즈니스 (각각 개별 사용자가있는)가되는 비즈니스 앱을 생각하고 있습니다. 개별 사용자마다 별도의 앱 인스턴스를 실행하는 것은 의미가 없습니다.


4

두 옵션을 모두 지원할 수도 있습니다 (여러 인스턴스에 걸쳐 테넌트 풀).

나는 자연적인 고립의 다중 인스턴스 원인을 선호합니다. 각 고객의 인스턴스는 자체 프로세스에서 실행되며 데이터는 자체 데이터베이스에서 격리됩니다. 원하는 경우 고객 / 인스턴스별로 인스턴스를 새 버전으로 업그레이드 할 수 있습니다.

테넌트 기반 시스템에는 정보 보안 위험이 따릅니다. "WHERE tenantId = x"절을 잊어 버리는 것이 얼마나 쉬운 지 생각해보십시오. 테넌트 지원 시스템을 사용하는 주된 이유는 성능이고 프로세스가 무겁기 때문에 잠재적으로 한 시스템에서 더 많은 것을 얻을 수있는 프로세스를 공유합니다. 이것은 32 비트 세계에서 더 많은 RAM이있는 64 비트 컴퓨터에서 오늘날이라고 생각하는 것이 더 사실이었습니다.

다중 인스턴스 시스템은 데이터베이스 및 웹 애플리케이션 인스턴스와 같은 환경을 작성하고 구성하기 위해 약간 더 많은 도구가 필요할 수 있습니다. 단일 인스턴스 배포에도이 스크립트를 작성해야한다고 주장 할 수 있습니다. 이 작업을 수행하면 개발 및 테스트 환경을 설정하는 기능과 같은 다른 특권이 있습니다.

테넌트 기능을 처리 할 수있을 때까지 (프로세스 공유를 통해 (하드웨어) 인프라에서 비용 대비 엔지니어링 비용 절감) 테넌트 기능을 사용하지 않을 것입니다.


Laravel의 Eloquent ORM을 사용할 것이므로 정보 보안 위험은 문제가되지 않습니다 (주의를 기울여야 함). 내 관심사는 어떤 경우에 어떤 접근 방식이 더 적합한 지, 그리고 왜? ... "다중 인스턴스"의 경우 기능을 추가 할 때 사용할 수있는 도구 (각 인스턴스를 고려한 Docker 컨테이너 이미지)는 무엇입니까 ? 그리고 Docker 관련 도구를 사용하여 나머지 모든 인스턴스에 배포하는 방법은 무엇입니까?
Asher

@Joppe에 전적으로 동의합니다. 여기 몇 가지 사항이 더 있습니다. 1. 고객이 다른 모든 애플리케이션과 동시에 애플리케이션을 업그레이드 할 의사가 있습니까? 일부 고객에게는 응용 프로그램을 업그레이드하기 전에 긴 테스트주기가 필요한 규칙이 있습니다. 다른 회사는 항상 최신 상태를 유지하고 공급 업체의 테스트에 의존하기를 원합니다. 멀티 테넌시는 악몽이 될 수 있습니다. 2. 위험 : 데이터 민감도 수준은 무엇입니까? Joppe가 언급했듯이 필터링을 잊어 버리고 민감한 데이터를 다른 사람들에게 노출시키는 것은 쉽습니다. 다중 테넌시를 통해 귀하는 다중 인스턴스에서 고소를 당할 수 있습니다. ;)
Danilo Tommasina
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.