멀티테넌시 정보

불행히도 이 용어에는 좋은 러시아어 유사어가 없습니다. Wikipedia 제공 번역 "다중 테넌시, 다중 테넌시." 이를 '다중 소유권'이라고도 합니다. 주제가 본질적으로 임대 또는 소유와 연관되어 있지 않기 때문에 이러한 용어는 다소 혼란스러울 수 있습니다. 이는 소프트웨어 아키텍처와 운영 구성에 관한 문제입니다. 그리고 후자는 그다지 중요하지 않습니다.

우리는 1C:Enterprise에서 작업의 클라우드(서비스) 모델에 대한 접근 방식을 설계하기 시작하면서 동시에 멀티 테넌시에 대한 이해를 공식화하기 시작했습니다. 이것은 몇 년 전이었습니다. 그 이후로 우리의 이해는 지속적으로 확장되었습니다. 우리는 이 주제에 대해 점점 더 많은 새로운 측면(장점, 단점, 어려움, 특징 등)을 끊임없이 발견하고 있습니다.

때때로 개발자는 멀티 테넌트를 매우 간단한 주제로 이해합니다. "여러 조직의 데이터를 하나의 데이터베이스에 저장하려면 조직 식별자가 포함된 열을 모든 테이블에 추가하고 이에 대한 필터를 설정해야 합니다." 물론 우리도 이 순간부터 이 문제에 대한 연구를 시작했습니다. 그러나 그들은 이것이 단 한 번의 클리어링이라는 것을 빨리 깨달았습니다. (또한 쉽지는 않습니다.) 일반적으로 이것은 "전국"입니다.

멀티테넌시(Multitenancy)의 기본 개념은 다음과 같이 설명할 수 있습니다. 일반적인 응용 프로그램은 인프라(벽, 지붕, 물 공급, 난방 등)를 사용하는 한 가족을 수용하도록 설계된 별장입니다. 다중 임대 애플리케이션은 아파트 건물입니다. 그 안에서 각 가족은 동일한 인프라를 사용하지만 인프라 자체는 집 전체를 위해 구현됩니다.

다중 테넌트 접근 방식이 좋은가요, 나쁜가요? 이에 대해 매우 다른 의견을 찾을 수 있습니다. '좋다 나쁘다'는 전혀 없는 것 같습니다. 해결 중인 특정 작업의 맥락에서 장단점을 비교해야 합니다. 하지만 이건 별개의 주제인데...

가장 단순한 의미에서 멀티테넌시의 목표는 인프라 비용을 "사회화"하여 애플리케이션 유지 비용을 줄이는 것입니다. 이는 애플리케이션을 "주문형"으로 작성하는 대신 프로덕션 솔루션(사용자 정의 및 수정 가능)을 사용하여 애플리케이션 비용을 줄이는 것과 동일한 움직임입니다. 한 경우에만 개발이 사회화되고 다른 경우에는 착취가 발생합니다.

더욱이, 판매 방법과 직접적인 연관이 없다는 점을 반복합니다. 멀티테넌시 아키텍처는 기업 또는 부서별 IT 인프라에서 다수의 유사한 지점 및 지주 기업을 자동화하는 데 사용될 수도 있습니다.

멀티테넌시는 단순히 데이터 스토리지를 정리하는 문제가 아니라고 말할 수 있습니다. 이는 애플리케이션이 전체적으로(아키텍처, 배포 모델 및 유지 관리 조직의 중요한 부분을 포함하여) 작동하는 방식에 대한 모델입니다.

다중 테넌트 모델에서 가장 어렵고 흥미로운 점은 애플리케이션의 본질이 "두 갈래로 갈라진다"는 것입니다. 기능 중 일부는 특정 데이터 영역(아파트)에서 작동하며 다른 아파트에 거주자가 있다는 사실에 "관심이 없습니다". 그리고 일부는 집 전체를 인식하고 동시에 모든 거주자를 위해 일합니다. 동시에 후자는 이것이 결국 별도의 아파트라는 사실을 무시할 수 없으며 필요한 수준의 세분성과 보안을 보장해야 합니다.

1C:Enterprise에서 다중 테넌트 모델은 여러 기술 수준에서 구현됩니다. 이는 1C:Enterprise 플랫폼의 메커니즘,1C: 퍼블리싱 솔루션 기술 1cFresh"그리고"1C:솔루션 개발 기술 1cFresh", 메커니즘 BSP (표준 하위 시스템의 라이브러리).

이러한 각 항목은 아파트 건물의 전체 인프라 구축에 기여합니다. 이것이 플랫폼과 같은 하나의 기술이 아닌 여러 기술로 구현되는 이유는 무엇입니까? 우선, 우리 의견으로는 일부 메커니즘이 특정 배포 옵션에 맞게 수정하는 데 매우 적합하기 때문입니다. 그러나 일반적으로 이것은 어려운 질문이며 우리는 멀티 테넌시의 측면을 구현하는 것이 어떤 수준에서 더 나은지 끊임없이 선택에 직면합니다.

분명히 메커니즘의 기본 부분은 플랫폼에서 구현되어야 했습니다. 예를 들어 실제 데이터 분리가 있습니다. 사람들이 일반적으로 다중 테넌트에 대해 이야기하기 시작하는 곳입니다. 그러나 결국 다중 테넌트 모델은 플랫폼 메커니즘의 상당 부분을 "이동"했으며 개선이 필요했으며 어떤 경우에는 재고가 필요했습니다.

플랫폼 수준에서 우리는 기본 메커니즘을 정확하게 구현했습니다. 이를 통해 다중 테넌트 모델에서 실행되는 애플리케이션을 생성할 수 있습니다. 그러나 애플리케이션이 이러한 모델에서 "생활하고 작동"하려면 해당 "생활 활동"을 관리하는 시스템이 필요합니다. 1cFresh 기술과 BSP 수준의 통합 비즈니스 로직 레이어가 이를 담당합니다. 아파트 건물에서 인프라가 거주자에게 필요한 모든 것을 제공하는 것처럼 1cFresh 기술은 다중 테넌트 모델에서 실행되는 애플리케이션에 필요한 모든 것을 제공합니다. 그리고 애플리케이션이 상당한 수정 없이 이 인프라와 상호 작용할 수 있도록 해당 "커넥터"가 BSP 하위 시스템 형태로 배치됩니다.

플랫폼 메커니즘의 관점에서 볼 때 우리는 경험을 쌓고 클라우드 사용 사례 “1C:Enterprise”를 개발하면서 이 아키텍처와 관련된 메커니즘의 구성을 확장하고 있음을 쉽게 알 수 있습니다. 한 가지 예를 들어 보겠습니다. 멀티테넌시 모델에서는 애플리케이션 서비스 참여자의 역할이 크게 달라집니다. 애플리케이션 운영 담당자의 역할(책임 수준)이 크게 늘어납니다. 보다 강력한 애플리케이션 제어 도구가 필요하게 되었습니다. 왜냐하면 애플리케이션 사용자(거주자)는 자신이 함께 일하는 모든 공급자를 먼저 신뢰하기 때문입니다. 이를 위해 우리는 새로운 기능을 구현했습니다. 보안 프로필 메커니즘. 이 메커니즘을 통해 공급자 관리자는 애플리케이션 개발자의 자유를 필요한 보안 수준으로 제한할 수 있습니다. 즉, 본질적으로 특정 샌드박스 내의 각 테넌트에 대한 애플리케이션 운영을 격리할 수 있습니다.

그다지 흥미로운 것은 다중 테넌트 모드(1cFresh 및 BSP 기술로 구현되는 것)에서 작동하는 애플리케이션을 관리하기 위한 아키텍처입니다. 여기서는 기존 배포 모델에 비해 관리 프로세스 자동화에 대한 요구 사항이 크게 증가합니다. 이러한 프로세스는 새로운 데이터 영역(“아파트”) 생성, 애플리케이션 업데이트, 규제 정보 업데이트, 백업 등 수십 가지가 있습니다. 물론 안정성과 가용성 수준에 대한 요구 사항도 증가하고 있습니다. 예를 들어, 애플리케이션과 제어 시스템 구성 요소 간의 안정적인 상호 작용을 보장하기 위해 우리는 전달이 보장되는 비동기 호출 시스템 기술을 구현했습니다.

매우 미묘한 점은 데이터와 프로세스를 사회화하는 방식입니다. 언뜻보기에는 (누군가에게 보인다면) 단순해 보입니다. 가장 큰 과제는 데이터와 프로세스의 중앙화와 분산화 사이의 균형입니다. 한편으로 중앙 집중화를 통해 비용(디스크 공간, 프로세서 리소스, 관리자 노력 등)을 줄일 수 있습니다. 반면에 “임차인”의 자유를 제한합니다. 이는 개발자가 좁은 의미(하나의 "아파트" 제공)와 넓은 의미(모든 "세입자"를 동시에 제공)의 애플리케이션에 대해 동시에 생각해야 하는 애플리케이션의 "분기" 순간 중 하나입니다. .

이러한 "딜레마"의 예로 규제 및 참조 정보를 들 수 있습니다. 물론, 그 집의 모든 "임차인"에게 공통적으로 적용하려는 큰 유혹이 있습니다. 이를 통해 하나의 복사본에 저장하고 모든 사람이 동시에 업데이트할 수 있습니다. 그러나 일부 주민들에게는 구체적인 변화가 필요합니다. 이상하게도 실제로는 규제 기관(정부 기관)이 지정한 정보에 대해서도 이런 일이 발생합니다. 이것은 어려운 질문으로 밝혀졌습니다. 사교를 할 것인가, 아니면 사교하지 않을 것인가? 물론 정보를 모든 사람에게 일반화하고 원하는 사람들에게는 비공개로 만들고 싶은 유혹이 있습니다. 그리고 이는 이미 매우 어려운 구현으로 이어집니다. 하지만 우리는 이 문제를 해결하기 위해 노력하고 있습니다...

또 다른 예는 정규 프로세스(일정에 따라 실행, 제어 시스템에 의해 시작 등) 구현 설계입니다. 한편으로는 각 데이터 영역에 대해 별도로 구현할 수 있습니다. 더 쉽고 편리합니다. 그러나 반면에 이렇게 세밀하게 세분화하면 시스템에 큰 부하가 발생합니다. 부하를 줄이려면 사회화된 프로세스를 구현해야 합니다. 그러나 좀 더 신중한 연구가 필요합니다.

물론 이것은 매우 중요한 질문을 제기합니다. 애플리케이션 개발자는 어떻게 다중 테넌트를 보장할 수 있습니까? 이를 위해 그들은 무엇을 해야 합니까? 물론 우리는 기술 및 인프라 문제에 대한 부담이 최대한 공급된 기술의 어깨에 있도록 노력하고 있으며 애플리케이션 개발자는 비즈니스 로직 작업 측면에서만 생각합니다. 그러나 다른 중요한 아키텍처 문제와 마찬가지로 애플리케이션 개발자는 다중 테넌트 모델 작업에 대해 어느 정도 이해해야 하며 애플리케이션을 개발할 때 약간의 노력이 필요합니다. 왜? 기술이 데이터의 의미를 고려하지 않고 자동으로 제공할 수 없는 점이 있기 때문입니다. 예를 들어, 정보 사회화의 경계에 대한 동일한 정의입니다. 하지만 우리는 이러한 어려움을 최소화하려고 노력합니다. 이러한 애플리케이션을 구현한 사례는 이미 있습니다.

1C:Enterprise에서 멀티 테넌시를 구현하는 맥락에서 중요한 점은 하나의 애플리케이션이 멀티 테넌시 모드와 일반 모드 모두에서 작동할 수 있는 하이브리드 모델을 생성한다는 것입니다. 이것은 매우 어려운 작업이며 별도의 논의 주제입니다.

출처 : habr.com