다중 테넌시 지원


10

단일 테넌트 앱을 다중 테넌트 앱으로 변환 할 때 발생하는 일반적인 문제는 무엇입니까? 보안 및 데이터 격리가 가장 중요합니다. 다른 사람은 무엇입니까?

저는 상당히 자동화 작업을 수행 한 건축가 중 한 사람이며, 역사적으로 우리 회사에서 사용했습니다. 우리는 다른 사람들도 그것을 사용할 수 있기를 원합니다. "멀티 테넌트 만들기"에 대해 이야기 할 때마다 한 테넌트를 가진 사용자를 다른 테넌트가 소유 한 데이터에서 멀리 유지하고 한 테넌트를 가진 사용자가 의도적으로 또는 실수로 다른 사용자에게 영향을 줄 수 없도록하는 대화가 진행됩니다. 임차인의 환경. 내가 궁금한 점은 보안 / 데이터 격리가 실제로 유일한 주요 관심사인지 아니면 우리가 생각하지 않는 다른 주요 관심사가 있는지 여부입니다.


가장 쉬운 해결책? 하드웨어를 포함한 전체 시스템의 새 인스턴스는 처음부터 비어 있으며 테넌트 당 하나의 새 시스템입니다. 시스템과 데이터가 상당히 가치가 있다면 이것은 꽤 좋은 옵션 일 수 있습니다. 각 인스턴스에 새 하드웨어가 마음에 들지 않으면 가상화를 사용하십시오. 가장 효율적이지 않을 수도 있지만 확실히 많은 두통을 줄일 수 있습니다.
SF.

아마도 디자인 관점에서 이것은 가장 쉬운 방법이지만 관리 관점에서는 그렇지 않습니다. 최소한 우리의 시스템 관리자는이 제안에 대해 크게 흥분하지 않습니다. (예, 우리는 VM을 사용하고 있습니다.) 더 많은 인스턴스 관리 방법 (모니터링, 배포 등) 실제로 물리적 격리를 위해보다 관리하기 쉬운 방법을 찾고 있습니다. 접근 방식은 개발자 단순성을 위해 개발 단순성을 거래하는 것 같습니다 ...?

답변:


11

데이터 사일로 외에 다음과 같은 문제가 발생할 수 있습니다.

  1. 가용성-단일 테넌트를 사용하면 DoS 자체 만 가능하지만 데이터가 올바르게 사일로 설정되어 있어도 테넌트는 여전히 리소스를 소모 할 수 있습니다.
  2. 로깅-모든 로그 메시지는 단일 테넌트로 가정합니다. 테넌트 당 로그를 저장하지 않으면 로그 메시지의 유용성이 떨어질 수 있습니다.
  3. 동시성-단일 테넌트 앱이 중간 정도의로드에서 실행되거나 몇 개의 잠금에 대한 높은 경합이 특정 작업을 효과적으로 직렬화 할 수 있습니다. 테넌트별로 잠금을 곱하면 이전에는 없었던 작업이 인터리빙되는 것을 볼 수 있습니다. 지금까지 나타날 가능성이 거의없는 경쟁 조건이 이제 나타날 수 있습니다.
  4. 새로운 리소스 경합 소스-n 개의 소켓과 m 개의 파일 핸들이 있기 전에 이제 해당 테넌트에 곱하십시오.
  5. 구성 성 / 이전 호환성 호환성 트레이드 오프 – 교체를 롤아웃 할 때 구성 요소를 폐기하기 전에 이제는 하나의 테넌트가 구성 요소를 요구하고 한 테넌트가 기존 구성 요소를 무기한으로 유지하도록 요구할 수 있습니다.
  6. 소환장 대상-현재 회사와 관련된 문제에 대한 소환장 대상입니다. 다중 테넌트를 사용하면 법적 소송 당사자가 아닌 경우에도 소환장 요청에 응답해야 할 수도 있습니다.

이 중 일부는 모든 테넌트를 동일한 주소 공간 (컴퓨터 또는 클러스터)에서 실행한다고 가정합니다. 각 테넌트가 하드웨어에서 소프트웨어를 실행중인 경우 위의 일부를 모으고 다음을 추가 할 수 있습니다.

  1. 디버깅을 위해 머신에 액세스하는 데 어려움이 있습니다.
  2. 이전 버전에 대한 지원 요청.
  3. 타사 계약자가 구성 할 수 있도록 요청합니다.
  4. 실행되는 하드웨어에 대한 제어력이 떨어집니다.
  5. 운영 체제의 패치 / 업데이트주기에 대한 제어력이 떨어집니다.

1

내 의견으로는 멀티 테넌시의 가장 큰 문제는 사용자 정의입니다. 기업에 비즈니스 응용 프로그램을 판매하는 경우에 일상적으로 발생합니다. 스킨을 원하는 모든 고객만큼 단순한 것부터 추가 필드, 규칙, 양식 및 보고서를 구성하는 기능에 이르기까지 다양 할 수 있습니다. 지원해야하는 사용자 지정 수준은 아키텍처에서 중요한 역할을합니다.


1

Mike의 대답은 매우 훌륭하며, 그 점이 너무 짧기 때문에 복잡성이 거의 미흡한 점이 많으므로 마음에들 수 있습니다.

한 가지 추가 할 점은 새 테넌트를 작성하고 나중에 관리 할 수있는 훌륭한 관리 도구가 있어야한다는 것입니다. 실제 물리적 아키텍처에 따라 이는 사소한 것이 아니며 종종 간과되는 것입니다. 테넌트 수가 많은 경우 서비스 제품으로서의 소프트웨어의 이점은 실제로 작용하기 때문에 상당한 노력이 필요합니다.

Sriram의 답변을 확장하기 위해; 테넌트 별 사용자 정의 는 거의 금지되어 있으므로 테넌트가 변경하고자하는 모든 것을 구성 할 수 있어야 합니다 . 예를 들어 솔루션이 최소한 몇 가지 핵심 영역에서 데이터 필드를 동적으로 추가하지 못하는 경우 사용자 지정 요청이 너무 많을 수 있습니다. 그것은 약간의 추가 복잡성 선행 실제로 돈을 지불 않는 몇 가지 경우 중 하나 (하자 그것을 YAGNI에 반하는 말을하거나, 그래서 적어도, 구성의 수준이 거의 핵심 요구 사항입니다입니다 입니다 거 필요 그것을).


사용자 정의가 "금지"된 이유는 무엇입니까? 확실히 기술적으로 달성 할 수 있습니다. 여러 테넌트의 핵심 시스템을 재사용하면서 개별 테넌트를위한 맞춤형 조각을 제공 할 수있는 다양한 패턴이 있습니다. 고객이 커스터마이징 비용을 지불 할 의사가있는 경우이를 고려하는 것이 합리적입니다. 이러한 이유로 클라이언트마다 사용자 정의하는 다중 테넌트 제품이 많이 있습니다. YAGNI IMO의 정신은 확장 성을 허용하고 모든 것을 구성 가능하게 만드는 것이 아닙니다.
RationalGeek

1
저는 일반적으로 소프트웨어를 서비스 구현이라고합니다 ( "멀티 테넌시"). 물론 기술적으로 달성 가능하지만 SaaS의 기본에 위배됩니다. 재정적으로, 많은 테넌트의 구현 및 인프라를 공유함으로써 비용을 절감 할 수 있습니다. 이를 통해보다 저렴한 가격으로 제품을 제공 할 수 있으므로 시장의 "긴 꼬리"를 잡을 수 있습니다 (많은 사람들이 적은 금액 만 지불 할 의향이 있음). 시스템의 5 개 분기를 유지 관리 할 수 ​​있지만 15000은 유지하지 못할 수 있으며 이것이 SaaS의 목표입니다.
Daniel B

엔터프라이즈 수준에서는 고객을 착륙시키기 위해 코드를 크게 사용자 지정하려는 SaaS 공급 업체가 자주 있습니다. 고객이 서비스에 대해 6 또는 7의 수치를 지불 할 때 이는 합리적인 비즈니스 모델 일 것입니다.
RationalGeek

네, 그런 경우에 그런 것 같아요. 내가 본 대부분의 변경 사항은 기본적으로 기존 클라이언트에 대해 해제 된 구성 가능한 새로운 기능으로 구현되었습니다. 문제는 솔루션이 아직 시작되지 않았기 때문에 처음 3-4 명의 고객이 각각 특별한 치료를받을 때입니다. 이 솔루션은 너무 구체적이어서 "OK, 우리는 해킹 할 것입니다"라는 문화를 만듭니다. 하지만 큰 고객에 대한 귀하의 의견에 동의합니다.
Daniel B

이것은 여러분이 커스터마이징 가능성과 관련하여 도움이되는 구별입니다. 같은 개념이 관리 효율성에도 적용될 수 있다고 생각합니다. 멀티 테넌시는 아마도 롱테일 고객보다는 상대적으로 적은 규모의 고객을 목표로합니다. 멀티 테넌시의 주요 목적이 롱테일을 캡처하는 것이라면 올바른 접근 방식이 아닐 수도 있습니다. 이러한 성찰에 감사드립니다.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.