Windows Azure 및 여러 저장소 계정

Question

단일 테넌트에서 다중 테넌트로 전환하려는 ASP.NET MVC 2 Azure 응용 프로그램이 있습니다. 스택 오버플로에 대한 많은 블로그와 게시물 및 질문을 검토하고 있지만이 특정 앱에 적합한 것이 무엇인지 구체적으로 설명하려고합니다.

현재 응용 프로그램은 Azure 저장소 계정의 일부 정보뿐만 아니라 SQL Azure 데이터베이스에 일부 정보를 저장합니다. 필자는 임차인 프로비저닝 코드를 작성하여 새 청사진 스토리지 계정과 함께 새 임차인을위한 새 데이터베이스를 간단하게 만들 것을 고려하고 있습니다. 이것은 다음과 같은 질문에 나를 데려옵니다 :

어떻게이 접근법을 로컬에서 테스트 할 것인가? 내가 알 수있는 한 로컬 Azure Storage Emulator에는 스토리지 계정이 하나뿐입니다. 나는 다른 사람들을 로컬에서 만들 수 있는지 잘 모르겠습니다. 어떻게 로컬에서 테스트 할 수 있습니까? 아니면 가능할 것인가?

Answer 1

멀티 테넌시에는 여러 가지 측면이 고려되며, 그 중 하나는 데이터 아키텍처입니다. 청구, 실적, 보안 등도 있습니다.

데이터 아키텍처에 대해 먼저 SQL 스토리지를 살펴 보도록하겠습니다. 다음 옵션을 사용할 수 있습니다. 코드가 레코드를 필터링하는 데 사용할 CustomerID (또는 다른 식별자)를 추가하고, 다른 고객에 대해 다른 스키마 컨테이너를 사용합니다 (각 고객은 전용 스키마에 의해 소유 된 모든 데이터베이스 개체의 자체 복사본을 가짐). 선형 샤딩 (각 고객마다 자체 데이터베이스가 있음) 및 연합 (성능 및 확장 성 요구 사항에 따라 점진적인 샤딩을 제공하는 SQL Azure의 기능)을 지원합니다. 이러한 모든 옵션은 유효하지만 성능, 확장 성, 보안, 유지 관리 (백업 등), 비용 및 물론 데이터베이스 설계에 대해 다른 의미를 갖습니다. 내가 제공 한 정보에 따라 어느 것을 선택할지를 말할 수 없었습니다. 이미 코드 기반이있는 경우 일부 모델은 다른 모델보다 구현이 쉽습니다. 일반적으로 선형 파편은 가장 단순한 모델이며 강력한 고객 격리를 제공하지만 아마도 가장 비싼 것입니다. 스키마 기반 분리는 그리 어렵지 않지만 보안 요구 사항을 잘 처리해야하며이 방법은 공유되지 않으므로 고객 간 성능 문제가 발생할 수 있습니다 (동일한 데이터베이스에있는 고객의 경우). 마지막으로 Federations는 고객 식별자를 사용해야하며 몇 가지 제한이 있습니다. 그러나이 기술을 사용하면 성능 배포와 장기적인 확장 성을보다 효과적으로 제어 할 수 있습니다 (선형 샤드처럼 Federation은 비공유 아키텍처를 사용하기 때문에).

저장소 계정과 관련하여 고객 당 다른 저장소 계정을 사용하는 것이 명확한 방법입니다. 별도의 스토리지 계정을 사용하지 않을 경우 가장 큰 문제는 단일 저장소 계정을 사용하여 실행할 수있는 초당 최대 트랜잭션 수와 같은 성능 제한입니다. 그러나 지적하고 있듯이 로컬에서 테스트하는 것이 문제 일 수 있습니다. 그러나 이것을 고려하십시오. 로컬 에뮬레이터는 Azure 저장소 계정으로 100 % 패리티를 제공하지 않습니다 (일부 기능은 에뮬레이터에서 지원되지 않습니다). 그래서 초기 개발과 문제 해결을 위해서만 로컬 에뮬레이터를 사용했습니다. 멀티 테넌트 테스트를 포함한 모든 심각한 테스트는 실제 스토리지 계정을 사용하여 수행해야합니다. 응용 프로그램을 완전히 테스트 할 수있는 유일한 방법입니다.

Answer 2

별도의 데이터베이스를 만들지 않고 단일 SQL 데이터베이스 내에 다른 개체 네임 스페이스를 만드는 것을 고려해야합니다. 각 임차인은 자신 만의 테이블 세트를 가질 수 있습니다.

저장소를 사용하는 방법에 따라 클라이언트마다 별도의 저장소 컨테이너 또는 메시지 큐를 만들 수 있습니다.

이러한 제약 조건을 감안할 때 저장소 에뮬레이터 및 로컬 SQL 인스턴스를 사용하여 로컬로 테스트 할 수 있어야합니다.

추가 설명이 필요하면 알려주십시오.