영업: 1-800-867-1380

Windows Azure에서 다중 테넌트 응용 프로그램 디자인

업데이트 날짜: 2014년 1월

저자: Suren Machiraju 및 Ralph Squillace

검토자: Christian Martinez, James Podgorski, Valery Mizonov 및 Michael Thomassy

이 백서에서는 보다 효율적인(즉, 실행하거나 작성하는 데 비용이 적게 들거나 성능, 견고성 또는 확장성이 좋은) Windows Azure용 다중 테넌트 응용 프로그램(일반적으로 다른 조직에 서비스를 제공하는 ISV 응용 프로그램)을 디자인하는 데 필요한 방법에 대해 설명합니다. 이 문서에서는 다중 테넌트 응용 프로그램에 대한 일반적인 원칙, 다중 테넌트 응용 프로그램의 작성 및 실행과 관련된 Windows Azure 플랫폼의 구조와 동작에 대해 설명한 다음, 특히 Windows Azure에 적용되는 특정 다중 테넌트 지원 영역, 즉, 응용 프로그램 및 데이터 리소스와 이러한 리소스의 프로비전 및 관리 방법을 집중적으로 살펴볼 것입니다. 집중적으로 살펴보는 각 영역에서는 Windows Azure에서 성공적인 다중 테넌트 응용 프로그램을 만들기 위해 균형을 맞춰야 하는 보안, 비용 및 확장성 문제에 대해 설명합니다.

다중 테넌트 응용 프로그램이란?

Wikipedia에서는 다음과 같이 다중 테넌트 지원을 정의합니다.

Important중요
여기에서 다루는 내용을 이미 알고 있는 경우 곧바로 지침을 얻고 싶으면 Windows Azure 다중 테넌트 서비스 개요부터 읽으십시오. 충분히 이해하지 못한 것이 있으면 나중에 이 섹션을 다시 살펴볼 수 있습니다.

다중 테넌트 지원은 소프트웨어의 단일 인스턴스가 서버에서 실행되어 여러 클라이언트 조직(테넌트)에 서비스를 제공하는 소프트웨어 아키텍처의 원칙을 의미합니다. 다중 테넌트 지원은 여러 개별 소프트웨어 인스턴스(또는 여러 하드웨어 시스템)가 각기 다른 클라이언트 조직을 위해 설정된 다중 인스턴스 아키텍처와 대조됩니다. 다중 테넌트 아키텍처에서 소프트웨어 응용 프로그램은 데이터와 구성을 가상으로 분할하도록 디자인되며 각 클라이언트 조직은 사용자 지정된 가상 응용 프로그램 인스턴스와 작동합니다. (Wikipedia.org)

이 설명은 간단히 말해서 어떤 의미일까요? 이에 대한 예로 레스토랑 예약 응용 프로그램을 들 수 있습니다. 레스토랑 자체에는 예약을 하거나 취소하기 위해 프런트 데스크와 거의 실시간으로 연결하는 모든 기능을 갖춘 인터넷 예약 사이트를 만들 IT 인프라가 없습니다. 대부분의 경우 레스토랑은 다른 회사를 고용하여 정적 웹 사이트를 만듭니다. 따라서 개별 레스토랑이 등록하고, 계정을 만들고, 해당 레스토랑의 로고와 색상을 사용하여 웹 페이지의 모양을 사용자 지정하고, 메뉴를 업로드하고, 프런트 데스크의 컴퓨터로 웹 응용 프로그램에 연결하고, 다른 예약 응용 프로그램의 예약 요청을 처리할 수 있도록 하는 단일 응용 프로그램을 만들 수 있습니다.

이 예에서 각 레스토랑은 해당 레스토랑에서 사용하고 로그인하면 오로지 해당 레스토랑의 것인 응용 프로그램을 봅니다. 고객은 레스토랑의 웹 사이트만 보며 레스토랑이 스스로 모든 것을 만들었다고 생각합니다. 레스토랑이 ISV에 지불하는 것은 배고픈 고객에 대한 이러한 부가 가치입니다. 이는 예약 응용 프로그램이 여러 테넌트(이 경우에는 Contoso Restaurant 및 Fabrikiam Restaurant)를 지원하는 다음 다이어그램과 유사할 수 있습니다. 이 다이어그램에서 Bob, Priyanka, Jasmine 및 다른 고객은 아마도 메뉴를 보면서 예약을 할지를 고민하고 있습니다.

이는 다음 다이어그램과 유사할 수 있습니다.

Contoso 예약 서비스 다이어그램

아키텍처 측면에서 말하자면, 개별 고객에 맞춘 특수한 사용자 지정을 사용하여 각 고객을 위한 완전히 새로운 인스턴스를 호스팅하여 이러한 응용 프로그램을 만들 수 있습니다. 이때 각 고객은 자신만의 VM(가상 컴퓨터)을 얻을 수도 있습니다. 이 방법은 충분히 일반적이지만 응용 프로그램이 상당히 널리 사용되게 되면 ISV에 많은 문제를 야기합니다. 이에 대해서는 나중에 좀더 살펴보겠지만 이 문서에서는 흔히 단일 테넌트, 다중 인스턴스 디자인이라고 하는 이 방법을 집중적으로 다루지는 않습니다.

응용 프로그램이 레스토랑 사이에서, 나아가서는 일반 예약 지원을 필요로 하는 회사 사이에서 널리 사용되기를 원하는 경우 유지 관리 비용과 리소스 비용이 크게 줄어들어 작업이 늘어남에 따라 성능은 향상되고 비용은 감소하도록 테넌트(이 경우에는 레스토랑) 사이에서 리소스를 공유하는 응용 프로그램을 하나 만들고자 할 것입니다. 이러한 방식으로 응용 프로그램을 만드는 것을 Wikipedia에서 다중 테넌트, 단일 인스턴스 응용 프로그램이라고 합니다.

응용 프로그램 인스턴스

이러한 맥락에서 "인스턴스"는 논리적 응용 프로그램 전체를 나타내며 VM이나 .exe, 프로세스 또는 이와 유사한 것을 의미하지 않습니다. 사실 위의 다이어그램에 나와 있는 예약 응용 프로그램은 다양한 외부 및 내부 "서비스"(웹 서비스를 통해 통신하는 구성 요소)로 구성되어 있습니다.

이러한 웹 응용 프로그램은 일반적으로 "웹 팜"과 작동하도록 만들어집니다. 웹 팜에서는 서버 그룹이 실행 중에 원격 저장소에 모든 응용 프로그램 상태 데이터를 저장하여 응용 프로그램의 중요한 구성 요소의 여러 인스턴스를 처리하므로 응용 프로그램의 한 인스턴스가 어떤 이유로든 사라지는 경우 다른 인스턴스가 프로세스를 복구하거나 완료할 수 있습니다. 즉, 거대하게 확장 가능한 현대의 웹 응용 프로그램은 프로세스 구성 요소와 저장소 구성 요소로 분해되며, 이러한 구성 요소는 통신 및 보안 구성 요소와 함께 전체 응용 프로그램의 외부와 접하는 단일 "인스턴스"를 구성합니다.

다중 테넌트 서비스의 등장

Windows Azure의 다중 테넌트 지원 기능은 응용 프로그램을 상태 비저장 서비스 및 저장소로 분해하여 필요에 따라 ID로 데이터 흐름을 관리합니다. 상태는 테넌트 ID를 직접 처리해야 하는 서비스에만 적용됩니다. 이는 서비스 상태 비저장이라는 일반적인 서비스 지향 응용 프로그램 원칙을 따릅니다. 예를 들어 웹 페이지 및 공용 웹 서비스와 같은 필수적인 최상위 서비스나 보안 서비스 자체는 보안 클레임 및 토큰을 직접 처리해야 합니다. 하지만 더 큰 응용 프로그램의 일부인 다른 구성 요소와 서비스는 테넌트를 위해 작동하는 응용 프로그램의 다른 모든 부분에서 재사용 가능해야 합니다.

테넌트와 고객은 다중 테넌트 지원에 대해 신경쓰지 않음

이 섹션은 테넌트 회사와 고객은 응용 프로그램이 만들어진 방식에 대해 신경쓰지 않는다는 사실을 강조하기 위한 것입니다. 이들은 견고함, 성능, 기능 집합, 비용 등 응용 프로그램의 능력에만 관심이 있습니다. 다른 것에 관심을 갖는 경우는 거의 없습니다. 물론 보안을 위해서, 특히 법적 이유나 규정상의 이유로 올바르게 만들고 실행하고 있다는 것을 특정 종류의 감사를 통해 증명해야 하는 경우가 실제로 존재합니다. 그러나 이러한 경우는 규칙을 증명하는 예외적인 경우일 뿐이고 해당 감사는 준수 여부를 확인하기 위한 것이지 아키텍처 자체를 확인하기 위한 것은 아닙니다.

Windows Azure 다중 테넌트 서비스 개요

다중 테넌트 시스템을 디자인할 때의 주요 문제는 테넌트 격리 제공과 이러한 전용 리소스 제공 비용 간의 적절한 균형점을 결정하는 것입니다. 달리 말하자면, 솔루션이 적절하게 작동하지만 가능한 한 비용 효율적이도록 하려면 얼마나 많은 리소스를 테넌트 사이에서 공유할 수 있는지를 알아내야 합니다. 일반적으로 성능 및 보안 요구 사항을 충족하는 한도 내에서, 많은 테넌트 사이에서 공유할 수 있는 리소스가 늘어날수록 솔루션의 비용 효율성이 높아집니다.

note참고
다중 테넌트 지원이 의미하는 바와 Windows Azure 응용 프로그램에 중요한 이유에 대해 확실히 모르겠으면 언제든지 다중 테넌트 응용 프로그램이란?을 읽어보고 내용을 파악한 다음 여기로 돌아오십시오.

이러한 주요 문제 내에서 주로 고려할 분야는 다음과 같습니다.

  • 보안 - 저장된 데이터, 인증 및 권한 부여 메커니즘 격리

  • 크기 조정 - 플랫폼 계산 자동 크기 조정, 플랫폼 저장소 크기 조정

  • 관리 및 모니터링

  • 테넌트 리소스 프로비전

  • 계량 및 요금 청구

다중 테넌트 아키텍처 고안은 많은 이동 부분이 포함된 복잡한 프로세스입니다. 이 문서에서는 세부 사항을 일일이 다루기보다는 가능한 한 많은 일반적으로 유용한 팁 및 조언과 함께 주요 고려 사항을 살펴봅니다. 이러한 점을 염두에 두고 아키텍처를 상위 수준부터 검토해 보겠습니다.

상위 수준 아키텍처

여러 개별 고객을 지원하는 한 가지 방법은 다중 테넌트 경로를 완전히 거부하고 요청 시 각 고객을 위한 리소스를 할당하는 것입니다. 단일 테넌트라는 이 방법을 사용하는 경우 고객을 위한 전용 리소스의 프로비전을 자동화합니다. 분산 응용 프로그램 아키텍처의 스펙트럼에서 이 방법은 반대 쪽의 완전한 공유 리소스와 대조되는 완전한 테넌트 전용 리소스를 나타냅니다. 이 문서에서는 이 디자인 스펙트럼의 완전한 공유 부분에 더 가까운 분산 응용 프로그램을 디자인하는 방법에 대해 설명하려고 합니다. 분산 응용 프로그램에는 공유(또는 다중 테넌트) 응용 프로그램과 데이터 리소스가 포함되어 있습니다.

다중 테넌트 응용 프로그램을 작성할 때 각 고객에게 제공할 격리에 대한 리소스 비용을 비교 검토해야 합니다. 응용 프로그램과 데이터 리소스 중에서 고객 간에 공유되는 것과 고객에게 독점적으로 할당되는 것을 고려해야 한다고 생각하기는 쉽지만, 다중 테넌트는 리소스 공유와 관련하여 성공 아니면 실패의 제안이 아님을 인식해야 합니다. 서비스 지향 응용 프로그램에서는 고객 간에 공유되는 리소스와 요구 사항에 따라 개별 고객에게 독점적인 리소스를 혼합하여 사용할 수 있으며 그렇게 하는 경우가 대부분입니다. 다시 강조하자면, 공유할 수 있는 응용 프로그램 서비스, 공유할 수 없는 응용 프로그램 서비스 및 응용 프로그램을 공유하는 정도를 결정할 수 있습니다. 이에 따라 엄청난 디자인 유연성이 제공되므로 이를 활용하십시오.

어떤 리소스를 공유할 수 있습니까?

아래의 그림에는 고려 대상인 Windows Azure 리소스가 나와 있습니다. 이러한 각 리소스에 대한 결정 중 몇 가지를 살펴보겠습니다. 다이어그램(및 일반적인 다중 테넌트 아키텍처)의 모든 리소스를 살펴보는 한 가지 유용한 방법은 각 구성 요소가 응용 프로그램 또는 데이터 계층 내에서 차지하는 위치를 정의하는 것입니다.

Azure의 다중 테넌트 구성 요소

이 다이어그램에서 Windows Azure 계산 및 액세스 제어 서비스는 계산 인스턴스를 연결하는 데 사용되는 릴레이 끝점과 마찬가지로 분명히 응용 프로그램 계층 리소스입니다. 테이블, Blob 및 SQL 데이터베이스는 분명히 데이터 계층 리소스입니다. 그러나 캐싱은 큐와 함께 특정 응용 프로그램 디자인 및 통신 패턴을 가능하게 하는 임시 저장소로 흔히 사용되며 그 결과로 사용 방식에 따라 저장소 또는 응용 프로그램 계층 리소스로 간주될 수 있습니다.

또한 특정 경우에 취할 수 있는 방법은 테넌트에 노출하려는 기능의 수에 따라 달라집니다. 예를 들어 테넌트가 테넌트별 ID를 클라이언트에 제공할 수 있게 하려는 경우 다중 테넌트 환경에서 안전한 일반적인 사용자 이름/암호 STS(보안 토큰 서비스)를 사용하려고 할 수 있습니다. 하지만 테넌트가 서비스를 구현하고 대신 액세스 제어 서비스와 페더레이션하게 할 수도 있습니다. 또 다른 예는 테넌트의 고객이 테넌트의 웹 또는 작업자 역할 인스턴스에서 코드를 업로드하고 실행할 수 있도록 허용하려는 경우입니다. 이 경우에는 다중 테넌트 및 단일 테넌트 역할 인스턴스를 혼합하여 사용하는 특정 다중 테넌트 솔루션이 당연히 필요합니다.

이러한 점을 염두에 두고 리소스를 성공적으로 공유하는 방법을 고려해보겠습니다. 응용 프로그램 관점에서 한 리소스에서 여러 테넌트를 지원하기 위해 취할 수 있는 일반적인 방법을 이 항목과 다른 항목에서 설명하겠지만 이러한 리소스를 프로비전하고 관리하는 방법과 Azure를 사용하여 그렇게 하는 방법도 살펴볼 것입니다. 공유되는 리소스의 프로비전 및 관리는 큰 문제를 발생시키지는 않지만 자세히 살펴볼 만한 몇 가지 경우가 있습니다.

응용 프로그램 리소스

다중 테넌트 응용 프로그램 디자인은 가능한 한도까지 계산, 데이터 및 다른 응용 프로그램 구성 요소가 여러 테넌트 ID 및 잠재적으로는 각 테넌트의 고객 ID를 처리하도록 하는 것을 의미합니다. 이 섹션에서는 Windows Azure를 사용한 다양한 방법과 관련된 문제에 대해 설명하고 해당 응용 프로그램 디자인에서 이러한 문제를 처리하는 데 가장 좋은 방법을 제안합니다.

계산

Windows Azure 웹 및 작업자 역할에서 제공하는 응용 프로그램 리소스와 이러한 리소스가 웹 서비스, 웹 사이트 및 기타 일반 처리를 호스팅하기 위해 다중 테넌트 솔루션에서 사용되는 방식부터 살펴보겠습니다.

다중 테넌트 응용 프로그램에서 Windows Azure 웹 및 작업자 역할을 가장 분명하게 사용하는 경우는 단일 역할 인스턴스가 여러 테넌트에 서비스를 제공한다는 개념으로 요청 시 테넌트 서비스에서 추가 계산 리소스를 제공하거나 계산 리소스를 줄이는 것입니다.

호스트 헤더에 의한 웹 사이트 테넌트 분할

가장 조잡한 솔루션에서의 방법은 아마도 테넌트당 하나씩, 여러 웹 사이트 및 웹 응용 프로그램을 지원하도록 각 웹 역할 인스턴스를 구성하는 것입니다. 이렇게 하려면 서비스 정의에서 Sites 요소를 수정하면 됩니다. 각 웹 사이트는 동일한 끝점에 바인딩되고 HTTP/1.1 호스트 헤더를 사용하여 격리되거나 자체 끝점에 바인딩될 수 있습니다. 그러나 Windows Azure에서 역할 인스턴스당 입력 끝점을 5개로 제한하므로 각 웹 사이트를 자체 끝점에 바인딩하는 것은 테넌트별로 확장되지 않습니다.

HTTP/1.1 호스트 헤더를 사용하여 여러 테넌트를 지원하는 경우 테넌트(및 테넌트의 고객)는 각기 다른 URL(예: 한 테넌트의 경우 www.fabrikam.com, 다른 테넌트의 경우 www.contoso.com)을 방문하고 원하는 테넌트의 웹 사이트를 보지만 사실은 단일 웹 역할 인스턴스 내의 단일 끝점과 통신하고 있는 것입니다. 이 방법을 사용하면 최소한의 노력으로 테넌트별로 다른 웹 사이트 파일을 격리할 수 있습니다. 기본적으로 각 웹 사이트가 자체 응용 프로그램 풀을 얻기 때문에 응용 프로그램 풀별로 테넌트를 격리할 수 있다는 것도 이 방법의 추가적인 이점입니다. 그러나 HTTP/1.1 호스트 헤더를 제공하는 URL이 DNS(도메인 이름 시스템)에서 정의되기 때문에 도메인 공급자와 함께 DNS를 구성하고 DNS가 *.cloudapp.net 주소를 가리키도록 설정해야 합니다. 새로운 테넌트 URL이 인터넷에서 완전히 검색 가능하려면 24시간이 걸릴 수 있습니다. 한 인스턴스가 호스트 헤더로 구분된 여러 웹 사이트를 호스팅하는 방법에 대한 유용한 예를 보려면 웹 역할에 대한 Windows Azure 액셀러레이터를 참조하십시오.

SSL 통신

HTTP/1.1 호스트 헤더 방법을 사용할 때 Windows Azure에서 해당 웹 사이트 간의 보안 경계를 적용하지 않는다는 점을 유의해야 합니다. 즉, 한 웹 사이트에서 사용하는 SSL 인증서를 다른 웹 사이트에서 사용할 수 있습니다. 또한 호스트 헤더만 다른 경우 IIS 7에서 자체 인증서를 사용하는 여러 웹 사이트를 지원하지 않는다는 점도 문제를 복잡하게 만듭니다.

Important중요
웹 사이트마다 각기 다른 IP 주소 또는 포트를 HTTPS 바인딩에 사용하는 경우 고유한 서버 인증서를 사용하는 여러 SSL 웹 사이트를 사용할 수 있습니다. IIS 6.0에서와 마찬가지로 IIS 7.0에서는 웹 사이트의 HTTPS 바인딩이 동일한 IP 주소/포트에 있고 호스트 헤더로만 구분되는 경우 자체 서버 인증서를 사용하는 여러 웹 사이트를 지원하지 않습니다. 이는 SSL 협상이 발생할 때 호스트 헤더 정보를 사용할 수 없기 때문입니다. 이 때문에 호스트 헤더를 사용하는 여러 웹 사이트를 동일한 IP 주소에 두는 유일한 방법은 와일드카드 CN과 함께 동일한 SSL 인증서를 사용하도록 해당하는 모든 웹 사이트를 구성하는 것입니다. 자세한 내용은 http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/596b9108-b1a7-494d-885d-f8941b07554c.mspx?mfr=true를 참조하십시오.

따라서 SSL 인증서를 사용하는 경우 다른 방법을 사용해야 할 수 있습니다. 한 가지 방법은 와일드카드 CN(*.yourdomain.com 형태)과 함께 단일 인증서를 사용하거나 통합 통신 인증서(모든 하위 도메인을 명시적으로 나열함)를 사용하는 것입니다. 이러한 종류의 인증서는 GoDaddy 및 Thawte와 같은 인증 기관에서 사용할 수 있으며 만들기가 쉽습니다. 각 테넌트는 https://fabrikam.yourdomain.com 또는 https://contoso.yourdomain.com과 같은 URL을 사용하여 SSL을 통해 리소스에 액세스합니다.

다른 방법은 각 웹 사이트가 전용 웹 역할을 수행하고 한 테넌트 인증서만 사용하도록 하는 것입니다. 이것은 다중 테넌트 방법이 아니므로 확장되지 않으며 관리 오버헤드뿐만 아니라 계산 리소스도 더 많이 소비합니다. 그렇지만 때로는 이 방법을 수행해야 합니다.

쿼리 매개 변수에 의한 웹 사이트 테넌트 분할

또 다른 방법은 단일 웹 사이트를 사용하여 여러 테넌트에 리소스를 제공하는 것입니다. 웹 사이트가 ASP.NET MVC를 사용하여 작성된 경우 테넌트마다 별도의 MVC 영역을 만들 수 있습니다. 또는 테넌트 간에 기본 영역을 공유하고 테넌트 ID와 같은 쿼리 매개 변수에 따라 컨트롤러가 다르게 렌더링되도록 합니다. 테넌트별로 프로세스 격리를 제공하려는 경우 웹 사이트 내에 가상 응용 프로그램을 정의해야 합니다. 사실상 각 테넌트는 웹 사이트 아래에서 가상 응용 프로그램을 얻습니다. 서비스 정의 내에서 Sites 요소를 편집하여 이렇게 할 수도 있지만, 각 테넌트에 대한 새 Site를 추가하는 대신 주 Site 요소 내에서 각 테넌트에 대한 VirtualApplication 요소를 하나씩 추가합니다.

작업자 역할의 웹 서비스

완전한 다중 테넌트 솔루션의 경우 웹 서비스를 호스팅하는 작업자 역할은 웹 역할에서 호스팅된 상대 항목과 동일한 방식으로 동작합니다. 즉, 모든 테넌트가 동일한 서비스 끝점에 액세스합니다.

작업자 역할은 백그라운드 처리를 제공하는 데도 사용됩니다. 완전한 다중 테넌트 시나리오에서 사용하는 방법은 작업자 역할의 RoleEntryPoint.Run 메서드 루프가 작업 항목을 만든 테넌트를 모르는 상태에서 작업 항목을 처리하도록 하는 것입니다. 따라서 모든 테넌트 간에 계산 리소스를 공유합니다.

저장소

다중 테넌트 응용 프로그램은 저장하고 사용하는 데이터가 격리되고 제대로 실행되는 방식을 처리해야 합니다. 이 섹션에서는 다중 테넌트 응용 프로그램의 SQL 데이터베이스, Windows Azure Blob, 테이블 및 큐, 서비스 버스 큐 및 항목, 캐싱 서비스 등, Windows Azure의 데이터 저장소 기술에 대해 설명합니다.

SQL 데이터베이스 저장소는 분명히 응용 프로그램의 저장소 역할을 하는 중요한 곳이지만 다중 테넌트 아키텍처에서는 새 테넌트를 프로비전하고 관리 데이터를 저장하기 위한 저장소 역할을 하는 데도 사용됩니다.

응용 프로그램 리소스에 SQL 데이터베이스 사용

이 시나리오에서 여러 테넌트의 응용 프로그램 데이터는 단일한 논리 데이터베이스 내에 저장됩니다. 다중 테넌트 데이터베이스 제공에는 분명한 비용 이점이 있지만(모든 테넌트에 비용을 분할하여 실현됨) 다음과 같은 이 시나리오와 관련된 다양한 요구 사항을 처리하는 데 따른 복잡성 증가라는 단점도 있습니다.

  • 데이터를 적절하게 격리하고 한 테넌트가 다른 테넌트의 데이터에 실수로 또는 악의적으로 액세스하지 못하도록 방지합니다.

  • 특히 리소스가 부족한 단일 테넌트의 영향을 제한할 뿐만 아니라 모든 테넌트의 쿼리 성능을 적절하게 유지 관리합니다.

  • SQL 데이터베이스가 현재 지원하는 최대 150GB의 데이터베이스 크기를 초과할 수 있는, 빠르게 증가하는 공유 데이터베이스의 크기를 처리합니다.

개념적으로, 테넌트 데이터와 쿼리 처리를 여러 데이터베이스에 분산할 때 성능 이점을 얻을 수 있습니다. 문제는 해당 솔루션을 위해 이를 활용할 수 있는 아키텍처입니다. 적절한 아키텍처를 찾으려면 스펙트럼에서 아키텍처를 살펴보는 것이 도움이 됩니다. 이 스펙트럼의 한쪽 끝에는 문제가 있을 때 더 큰 하드웨어를 배치하기만 하면 되는 전통적인 수직 확장이 있습니다. 단일 테넌트 아키텍처 방법의 경우와 마찬가지로, 수직 확장은 다중 테넌트 솔루션에는 너무 제한적이기 때문에 이해에 도움이 되지 않는 한 집중적으로 다루지 않을 것입니다. 여기에서는 분할 기법을 사용하는 아래의 다양한 수평 확장 방법을 자세히 살펴봅니다.

  • 선형 분할 아키텍처

  • 확장 분할 아키텍처

  • 압축 분할 아키텍처

  • 하이브리드 선형/확장 분할 아키텍처

기본 분할 방식의 다이어그램입니다.

위의 네 가지 유용한 분할 기법은 모두 수평 확장을 지원하기 위해 데이터베이스를 아키텍처에 추가하며, 각 데이터베이스에는 분할을 정의하는 저장된 데이터 간의 논리적인 분리(흔히 데이터 도메인 또는 데이터 페더레이션이라고 함)가 있습니다. 이러한 데이터 도메인은 특정 키 값(예: 고객 ID) 또는 특성(예: 연도)을 사용하여 정의할 수 있습니다. 이 문서에서는 간단한 설명을 위해 다중 테넌트 아키텍처의 맥락에서 데이터 도메인이 테넌트라는 관점을 가지고 살펴보겠습니다.

스펙트럼 다이어그램으로 되돌아가보면, 스펙트럼의 한쪽 끝에는 전통적인 수직 확장 모델이 있습니다. 이 방법에서는 모든 테넌트가 동일한 SQL 데이터베이스를 공유합니다. 즉, 데이터베이스마다 여러 테넌트가 있습니다. 스펙트럼 다이어그램의 가운데에는 각 테넌트가 자체 SQL 데이터베이스를 사용하는 선형 분할 아키텍처가 있습니다. 스펙트럼의 다른 쪽 끝에서는 각 테넌트가 여러 SQL 데이터베이스를 사용할 수 있습니다. 이를 확장 분할 방법이라고 합니다.

다른 두 방법에서는 중간의 시나리오를 다룹니다. 압축 분할 아키텍처에는 테넌트보다 SQL 데이터베이스가 적지만 SQL 데이터베이스가 두 개 이상 있습니다. 이와 마찬가지로, 분할 결정의 기준(예: 지역 및 테넌트)이 되는 여러 데이터 도메인이 있는 시나리오에서는 하이브리드 선형/확장 분할 아키텍처를 사용합니다. 이 아키텍처에서 각 지역은 특정한 확장 분할을 사용하고 각 분할에는 여러 데이터베이스가 있으며 특정 테넌트의 데이터가 확장 분할의 여러 데이터베이스에 분산되어 있습니다. 즉, 아키텍처가 지역에 따라 선형으로 수평 확장되지만 테넌트에 따라서는 일반적인 방식으로 확장됩니다. 이러한 분할 방법에서는 구현된 분할 방법을 탐색하는 방법을 알고 있고 특히 모든 분할에 쿼리를 전파하고 데이터 수정 작업을 적절한 분할로 안내하는 데 도움이 되는 Enzo SQL Shard 라이브러리와 같은 추상 계층이 필요합니다.

SQL 데이터베이스에서 다중 테넌트 데이터 보안

테넌트 데이터에 보안을 설정하는 방법부터 살펴보겠습니다. 핵심적인 형태에서 SQL 데이터베이스에 대한 데이터베이스 수준의 보안 관리는 온-프레미스 SQL Server의 보안 관리와 거의 동일합니다. 즉, 보안 주체를 만들고 사용하여 특정 스키마 개체(스키마, 테이블, 뷰, 저장 프로시저 등)에 대한 액세스를 제어합니다. 그런 다음 적절한 테넌트별 SQL Server 로그인, 데이터베이스 사용자 및 데이터베이스 역할을 만들고 이러한 보안 주체를 사용하여 스키마 개체에 사용 권한을 적용합니다. 한 가지 방법은 테넌트별로 스키마를 하나씩 정의하는 것입니다. 이 경우 스키마에 적용되는 보안이 해당 테넌트에 대한 액세스만 제한합니다.

다른 방법은 동일한 테이블 집합 내에 모든 테넌트 데이터를 저장하고 테넌트 ID 열과 같은 키로 테이블 내에서 분리하여 논리적 분리를 만드는 것입니다. 이 방법에서는 비즈니스 계층의 논리가 테넌트별로 데이터 액세스를 올바르게 필터링하는 작업을 담당합니다. 이 방법의 가장 어려운 점은 올바른 테넌트로 액세스를 제한하기 위해 데이터에 대한 모든 요청이 이 논리를 통과하도록 적용하는 것입니다. OData(쿼리 및 변경 인터셉터를 사용하는 WCF Data Services 사용)는 이 방법을 구현하는 데 사용할 수 있는 훌륭한 기술입니다. 이 논리를 구현해야 하는 부담을 덜어주는 Enzo(나중에 설명함)와 같은 프레임워크도 있습니다.

이를 염두에 두고 앞에서 설명한 수평 확장 아키텍처에 이러한 보안을 적용해보겠습니다. 선형 분할 아키텍처의 보안은 상당히 간단할 수 있습니다. 각 테넌트는 자체 데이터베이스를 사용하고 해당 분할에만 할당된 전용 로그인 및 사용자를 얻습니다. 다른 모든 분할 아키텍처에서는 보안이 좀더 세부적이어야 하며 스키마 개체 수준에서 정의된 사용 권한과 비즈니스 계층에서의 적용이 결합되어 사용됩니다.

성능 고려 사항

다음 주제로, 성능을 살펴보겠습니다. SQL 데이터베이스는 SQL 데이터베이스의 세 복제본을 유지 관리합니다. 각 데이터베이스의 데이터는 하나의 주 복제본과 두 개의 보조 복제본 간에 복제되지만, 모든 읽기 및 쓰기는 주 복제본에서 발생하고 보조 복제본은 장애 조치(Failover) 시나리오에서 쿼리 처리에만 도움을 줍니다. Windows Azure SQL 데이터베이스 패브릭은 주 복제본과 두 보조 복제본의 위치를 결정합니다. 주 복제본을 호스팅하는 컴퓨터의 부하가 많은 경우(사용자의 테넌트 또는 다른 테넌트 때문에) SQL 데이터베이스 패브릭은 부하가 적은 다른 컴퓨터의 보조 복제본을 주 복제본으로 교체할 수 있습니다. 이 교체는 신속하게 발생하지만 활성 세션의 연결이 끊어지는 결과가 나타납니다. 이 상황을 처리하도록 다중 테넌트 응용 프로그램을 준비해야 합니다.

이 점을 염두에 두고 테넌트당 성능이 가장 중요하면 테넌트당 하나 이상의 데이터베이스를 할당하는 분할 아키텍처(예: 선형, 확장 또는 하이브리드 아키텍처)를 고려해야 합니다. 그러나 이런 식으로 데이터베이스를 할당하는 테넌트가 많은 경우 몇 가지 장애가 발생합니다. 만드는 데이터베이스마다 비용이 발생하는 것은 분명하지만, 명심해야 할 장애는 SQL 데이터베이스 서버당 데이터베이스가 149개로 제한되는 점입니다. CSS(Cloud Support Services)에 연락하는 경우 이 제한을 높일 수 있습니다. 데이터베이스를 많이 사용하는 다중 테넌트 시나리오에서는 이 제한에 도달해도 솔루션이 SQL 데이터베이스 서버를 할당할 수 있어야 합니다.

응용 프로그램 리소스에 Windows Azure 테이블 사용

Windows Azure 테이블은 모든 저장소 리소스에 대해 전역적으로만 할당될 수 있는 저장소 계정 이름 및 키를 사용하여 보안이 설정됩니다. 즉, 테넌트별 데이터의 격리된 저장소를 제공하려면 서비스 공급자가 각 테넌트의 저장소 계정을 만들어야 합니다. 이 작업은 Windows Azure 서비스 관리 API를 통해 수행할 수 있습니다. 새 저장소 계정을 할당하는 경우 추가 비용이 들지 않으며 여러 가지 리소스가 서로 다른 계정에 적용될 수 있기 때문에 성능 이점을 얻을 수 있습니다. 한 구독에서 사용할 수 있는 저장소 계정의 수를 제어하는 할당량이 있으며, 이 할당량은 CSS(Cloud Services Support)에 연락하여 조정할 수 있습니다.

응용 프로그램이 여러 테넌트의 데이터를 단일 계정 내에 저장해야 하는 경우 지정된 테넌트에 반환되는 데이터를 필터링하는 고유한 추상화를 만들어야 합니다. 한 가지 방법은 테넌트별로 테이블을 하나 만들고 테이블별 수준에서 액세스 권한을 부여하는 것입니다. 이 방법은 올바른 테이블로 쿼리의 경로를 지정하기 위한 매우 간단한 논리를 사용하여 전체 파티션 키 및 행 키를 활용하여 신속하게 데이터에 액세스한다는 이점이 있습니다. 단점은 테넌트에 따라 적절한 테이블로 쿼리의 경로를 지정해야 하기 때문에 복잡성이 증가한다는 것입니다. 다른 방법은 테이블 내에서 테넌트별로 수평 분할하는 것입니다. 이 경우 데이터 액세스 계층이 클라이언트에 대한 특정 파티션 키가 있는 데이터만 반환합니다. 이렇게 하면 적절한 테이블로 쿼리의 경로를 지정해야 하는 필요성은 없어지지만 단일 파티션 키 값으로 제한되어 테넌트별 데이터 집합이 매우 큰 경우 성능에 영향을 줄 수 있습니다.

응용 프로그램 리소스에 Windows Azure Blob 사용

응용 프로그램의 저장소 요구와 관련하여 Windows Azure Blob은 다중 테넌트 응용 프로그램에 큰 이점을 제공합니다. 웹 사이트 이미지, 그래픽 및 테넌트 로고와 같은 공유 데이터에 대한 읽기 전용 액세스를 위해 공용 Blob 컨테이너를 만들어야 합니다. 개인 Blob 컨테이너(테넌트 또는 테넌트와 시스템만 액세스할 수 있음)는 문서 또는 테넌트별 구성 파일과 같은 응용 프로그램 데이터에 사용됩니다. 익명 액세스 외부에서 주요 방법은 Blob 읽기/쓰기, 차단 목록, 속성 또는 메타데이터, Blob 삭제, Blob 해제, 컨테이너 내의 Blob 열거 등의 다양한 작업에 공유 액세스 서명을 사용하여 보안이 설정된 컨테이너 또는 Blob에 대해 컨테이너 수준 액세스 정책을 지정하는 것입니다. 컨테이너 수준 액세스 정책을 지정하면 공유 액세스 서명으로 보호되는 리소스에 대해 새 URL을 발행할 필요 없이 사용 권한을 조정할 수 있습니다.

응용 프로그램 리소스에 대한 Windows Azure 큐

Windows Azure 큐는 테넌트를 위해 처리를 추진하는 데 일반적으로 사용되지만 프로비전 또는 관리에 필요한 작업을 분산하는 데도 사용될 수 있습니다.

여기에서의 고려 사항은 지정된 큐가 여러 테넌트에 속한 항목을 관리하는지, 아니면 각 큐가 단일 테넌트 전용인지 여부입니다. Windows Azure 저장소 모델은 저장소 계정 수준에서만 작동하므로 큐가 테넌트별로 격리되어야 하는 경우 테이블의 경우와 마찬가지로 개별 저장소 계정 아래에서 큐를 만들어야 합니다. 또한 단일 큐의 경우 메시지를 보내기만 하거나 받기만 하도록 제한하는 사용 권한을 정의할 수 없습니다. 테넌트가 저장소 계정으로 액세스 권한을 부여 받으면 Azure 큐 API에서 허용하는 모든 작업을 수행할 수 있으며 공유 큐까지 삭제할 수도 있습니다. 즉, 큐는 테넌트에 노출되지 않아야 하며 서비스에서 자동으로 관리되어야 합니다.

응용 프로그램 리소스에 대한 서비스 버스 큐

공유 서비스에 작업을 보내는 테넌트 관련 응용 프로그램 기능의 경우 단일 큐를 사용할 수 있습니다. 이때 각 테넌트 발신자는 해당 큐에 보낼 수 있는 권한만 갖고 있으며(ACS에서 발행한 클레임에서 파생됨) 서비스에서의 수신자는 여러 테넌트에서 제공되는 데이터를 큐에서 가져올 수 있는 권한만 갖고 있습니다. 반대 방향도 서비스 버스 큐로 가능합니다. 시스템 서비스에서 단일 큐의 특정 테넌트 수신자를 대상으로 하는 메시지를 보내게 할 수 있습니다. 서비스 버스 큐의 구독 기능을 사용하여 이러한 메시지를 멀티캐스팅할 수도 있습니다. 마지막으로, 세션 메시지를 사용하여 고객별 작업을 고객별 수신자에 보낼 수 있습니다. 단, 단일 공유 큐를 통해서만 보낼 수 있습니다.

이러한 방법이 관리해야 하는 큐의 수를 최소화하지만(전체적인 시스템 복잡성을 특정 수준까지 줄임) 여러 큐를 사용하는 경우처럼 부하가 더 많은 리소스 간에 분할되지 않기 때문에 큐에 넣기 또는 큐에서 제거 작업의 처리량이 제한될 수 있습니다. 또한 여러 테넌트 발신자의 경우 큐에 메시지가 쇄도하도록 하고 다른 테넌트의 다운스트림 처리를 사실상 차단하는 단일 테넌트에 좌우되지 않도록 주의해야 합니다. 서비스 버스 큐를 사용하면 메시지를 연기할 수 있으므로 단일 테넌트에서 제공되는 이러한 쇄도를 감지하고 해당 메시지를 일시적으로 연기하여 다른 테넌트의 메시지를 처리한 다음 나중에 해당 메시지 처리로 돌아올 수도 있습니다.

응용 프로그램 리소스에 대한 캐시 서비스

다중 테넌트 응용 프로그램 내에서 캐시는 자주 액세스되는 테넌트별 응용 프로그램 데이터에 일반적으로 사용됩니다. 여러 테넌트를 지원하기 위해 캐시 서비스 내에 명명된 캐시를 만들거나 테넌트별로 고유한 캐시 서비스 인스턴스를 만들 수 있습니다.

연결 및 보안 서비스

Windows Azure 다중 테넌트 응용 프로그램은 연결과 보안을 위해 다른 "미들웨어" 서비스인 서비스 버스 릴레이 서비스와 Windows Azure ACS(액세스 제어 서비스)를 사용합니다.

응용 프로그램 리소스에 ACS 사용

Windows Azure 액세스 제어 서비스는

웹 응용 프로그램과 서비스에 대한 액세스 권한을 얻기 위해 사용자를 인증하고 권한을 부여하는 쉬운 방법을 제공하고 인증 및 권한 부여 기능이 코드에서 제외될 수 있도록 하는 클라우드 기반 서비스입니다. 응용 프로그램에 특정한 사용자 계정을 사용하여 인증 시스템을 구현하는 대신 ACS에서 사용자 인증 및 권한 부여의 상당 부분을 조정하게 할 수 있습니다. ACS는 Active Directory 등의 엔터프라이즈 디렉터리와 Windows Live ID, Google, Yahoo!, Facebook 등의 웹 ID를 비롯한 표준 기반 ID 공급자와 통합됩니다. 자세한 내용은 여기를 참조하십시오.

다중 테넌트 시스템을 작성하든 아니든 간에 ACS는 응용 프로그램 자체에 대한 액세스의 보안 방법입니다. ACS를 사용하면 어떠한 ID 공급자의 보안 토큰도 처리할 수 있는 하나의 인증 API(ACS API)를 사용하여 응용 프로그램을 작성할 수 있습니다. 즉, Facebook, Google, Yahoo, Windows Live, 다른 타사 ID 공급자 또는 ADFS(Active Directory Federation Server)에 대해 각각 별도의 코드를 작성하지 않습니다. 대신 ACS에 대한 코드만 작성하고 ACS와 ID 공급자가 나머지 작업을 수행하도록 합니다.

ACS에서 ID 프로비전

ACS 구성이나 고유한 STS 구현에 대한 자세한 설명은 이 문서의 범위를 벗어나지만, 클레임 인식 웹 응용 프로그램 및 서비스의 권한 부여에서 이에 대해 생각해볼 수 있습니다. 페더레이션 보안을 통해 응용 프로그램에서 보안을 아웃소싱하는 데 사용되는 방법에 대한 기본 사항은 이 유용한 가이드를 참조하십시오. 직접 작성을 시작하려면 여기에서 WIF(Windows Identity Foundation)를 사용하여 작성하는 방법에 대한 배경 정보를 얻을 수도 있지만, Thinktecture의 Starter STS와 같이 완전히 갖춰진 STS에서 시작하여 필요에 따라 사용자 지정하는 방법도 유용합니다.

ACS를 사용하는 다중 테넌트 응용 프로그램 내에서 ID는 일반적으로 다음과 같은 상위 수준의 단계로 프로비전됩니다.

  • 인증서 만들기(예: 테넌트별)

  • ACS 네임스페이스 프로비전(네임스페이스에 의한 격리의 경우). RP(신뢰 당사자)라는 보안이 설정될 테넌트의 응용 프로그램 구성과 클레임 변환 규칙이 포함됩니다. 이 작업은 ACS 관리 API 또는 ACS 포털을 사용하여 수행됩니다.

  • 로그인에 사용할 테넌트의 루트 관리자 계정 만들기(보안 토큰 서비스를 제공하는 ID의 API 사용)

응용 프로그램 리소스에 서비스 버스 릴레이 사용

끝점으로 노출되는 서비스는 테넌트에 속하거나(예를 들어 온-프레미스 등, 시스템 외부에 호스팅됨), 테넌트를 위해 특정하게 프로비전된 서비스일 수 있습니다(중요한 테넌트별 데이터가 해당 서비스를 통해 전송되기 때문). 두 시나리오에서 여러 테넌트 처리는 사실 문제가 되지 않으며 테넌트별 사용을 적용하는 것이 문제가 됩니다. 이러한 끝점에 대한 액세스는 ACS(액세스 제어 서비스)를 사용하여 보안이 설정됩니다. 이때 클라이언트가 발급자 이름 및 키, SAML 토큰 또는 SWT(Simple Web Token)를 제공해야 합니다. 서비스 버스 및 ACS 관리 API를 사용하여 프로그래밍 방식으로 이를 구성할 수 있습니다.

note참고
서비스 버스 큐 및 항목과 구독은 응용 프로그램 데이터 흐름을 특정한 방식으로 처리하는 데 흔히 사용되지만 저장소로 설명되었습니다.

리소스 프로비전

이 섹션에서는 다중 테넌트 응용 프로그램을 지원하는 방식으로 리소스를 프로비전하는 데 대해 설명합니다. 응용 프로그램 디자인에서 둘 이상의 테넌트를 지원하는 경우와 마찬가지로 다중 테넌트 프로비전의 디자인에도 사용하도록 설정하려는 기능과 응용 프로그램에서 사용하는 Windows Azure 서비스에 따라 몇 가지 결정 사항이 있습니다.

다중 테넌트 응용 프로그램 디자인의 경우와 마찬가지로 계산, 저장소, 연결 및 보안 서비스가 다중 테넌트 응용 프로그램의 프로비전에 사용되는 방식에 대해 설명합니다.

Azure 역할을 사용하여 리소스 프로비전 및 관리

다중 테넌트 솔루션의 전용 작업자 역할은 새 테넌트가 등록하거나 취소할 때와 같이 테넌트별 리소스를 프로비전하고 프로비전을 해제하는 데 일반적으로 사용됩니다. 또한 계량을 위한 메트릭을 수집하고 특정 일정을 따르거나 주요 성능 지표의 임계값 초과에 대한 대응으로 배율을 관리하는 데도 사용됩니다. 이 동일한 역할이 업데이트와 업그레이드를 솔루션에 내보내는 데도 사용될 수 있습니다.

웹 역할은 일반적으로 서비스 공급자가 시스템 리소스 모니터링 및 관리, 로그 및 성능 카운터 확인, 수동 프로비전 등의 작업을 수행하도록 하는 데만 사용됩니다.

리소스 프로비전에 ACS 사용

ACS가 보호하는 테넌트 리소스를 프로비전할 때 ACS 관리 API 또는 포털을 사용하여 새로 프로비전된 테넌트의 최초 관리 계정을 만들어야 합니다.

리소스 프로비전에 캐시 서비스 사용

ACS가 보호하는 테넌트 리소스를 프로비전할 때 ACS 관리 API 또는 포털을 사용하여 새로 프로비전된 테넌트의 최초 관리 계정을 만들어야 합니다.

저장소 프로비전 시 고려 사항

다중 테넌트 솔루션에서 Windows Azure 테이블, Blob 및 SQL 데이터베이스에 적용되는 한 가지 고려 사항은 전 세계 분산입니다. 특히 시스템 전체(솔루션에서 사용되는 모든 데이터 센터)에서 고유해야 하는 데이터를 식별하고 적절한 성능의 사용자 환경을 유지 관리하는 작업과 균형을 맞추는 것입니다. 한 가지 옵션은 이러한 공유 데이터를 최종 사용자 근처로 가져오는 사용자 지정 복제 전략을 만드는 것입니다. 이 전략은 마스터 데이터 원본에 항상 삽입하는 등의 방법으로 새 데이터가 고유하다는 것을 기본적으로 보장해야 합니다. 다른 옵션은 전역 데이터 액세스의 양과 빈도가 최소화되도록 데이터를 분할하는 것입니다.

일반적인 Azure 저장소에 대한 또 다른 고려 사항은 Azure에서 적용되는 하드 제한입니다. 이러한 제한은 크지만 무한하지는 않습니다. 다중 테넌트 솔루션을 계획할 때 이러한 확장성 한도를 고려해야 합니다.

리소스 프로비전에 SQL 데이터베이스 사용

많은 양의 데이터가 관련된 특정한 다중 테넌트 시나리오에서는 기존 SQL 데이터베이스 참조 인스턴스에서 복사하여 새 SQL 데이터베이스를 프로비전하는 것이 가장 좋습니다. 이 방법으로 제공되는 향상된 프로비전 속도는 테넌트와 시스템 자체에서 필요한 것 이상의 추가 SQL 데이터베이스를 유지 관리하는 비용과 비교 검토되어야 합니다.

SQL 데이터베이스 리소스 프로비전

테넌트를 위한 새로운 SQL 데이터베이스 리소스를 프로비전하는 옵션은 다음과 같습니다.

  • 스크립트에 있거나 어셈블리 내에 리소스로 포함된 DDL을 사용합니다.

  • SQL Server 2008 R2 DAC 패키지를 만들고 API를 사용하여 배포합니다. 이 예제와 같이 Windows Azure Blob 저장소의 DAC 패키지에서 SQL 데이터베이스로 배포할 수도 있습니다.

  • master 참조 데이터베이스에서 복사

  • 데이터베이스 가져오기내보내기를 사용하여 파일에서 새 데이터베이스를 프로비전합니다.

Windows Azure Blob 저장소 프로비전

Blob 저장소를 프로비전하는 방법은 먼저 컨테이너를 만든 다음 각각에 정책을 적용하고 공유 액세스 키를 만들어 보호되는 컨테이너 및 Blob에 적용하는 것입니다.

리소스 프로비전에 Windows Azure Blob 사용

새 테넌트에 대한 계산 또는 미리 초기화된 저장소 리소스를 프로비전하는 경우 Azure Blob 저장소는 CS 패키지, VHD 이미지 및 다른 리소스를 보호하기 위해 위에서 설명한 컨테이너 수준 액세스 정책을 사용하여 보안이 설정되어야 합니다.

관리 리소스

마지막으로, 다중 테넌트 응용 프로그램의 디자인은 응용 프로그램, 테넌트 및 해당 서비스, 모든 데이터 리소스, 관련된 연결 또는 보안 문제를 관리하는 매우 중요한 작업을 처리해야 합니다. 이 섹션에서는 Windows Azure 실행 중에 다중 테넌트 응용 프로그램을 지원하기 위해 계산, 데이터 및 기타 서비스를 일반적으로 사용하는 방법에 대해 설명합니다.

관리 리소스에 Windows Azure 역할 사용

서비스 공급자는 시스템 리소스를 모니터링하고 관리하는 수단을 필요로 합니다. 웹 역할은 일반적으로 리소스 관리, 로그 및 성능 카운터 확인, 수동 프로비전 등을 위한 도구를 서비스 공급자에 제공하는 데만 사용됩니다.

관리 리소스에 ACS 사용

대부분의 다중 테넌트 시스템에서는 시스템 리소스에 보안을 설정하는 데 사용되는 ACS 내에 네임스페이스를 만들어야 하고 테넌트별로 개별 네임스페이스를 만들고 관리해야 합니다. 이 작업은 ACS 관리 네임스페이스를 사용해서도 수행됩니다.

관리 리소스에 캐시 서비스 사용

서비스 공급자가 특정 KPI 또는 계산된 통계를 모든 테넌트에 노출하는 경우 이러한 흔히 요청되는 값을 캐시하도록 결정할 수 있습니다. 테넌트는 캐시에 직접 액세스할 수 없으며 캐시에 액세스하기 위한 실제 권한 부여 키 및 URL을 보유한 매개자(예: WCF 서비스)를 통과해야 합니다.

관리 리소스에 SQL 데이터베이스 사용

해당하는 예에는 페더레이션하지 않은 테넌트를 위한 데이터 센터 중립적인 시스템 범위의 단일 멤버 자격/역할 데이터베이스나 ACS와 함께 사용하기 위해 구성된 사용자 지정 IP STS에 의존하는 데이터베이스가 있습니다. 여러 지리 분산과 관련된 다중 테넌트 시스템의 경우 관리 데이터에 대한 중앙 집중화된 시스템의 문제가 발생합니다. 이러한 문제를 해결하려면 응용 프로그램 리소스에 대해 이전에 설명한 방법을 취할 수 있습니다. 즉, 하이브리드 선형/확장 분할 아키텍처 또는 보다 단순한 선형 분할 아키텍처에서 지역을 분할된 데이터베이스로 정의할 수 있습니다. 두 경우 모두 중간 계층 논리를 활용하여 모니터링 및 관리 쿼리에 대한 결과를 전파하고 집계합니다.

관리 리소스에 Windows Azure 테이블 사용

WAD(Windows Azure 진단) 인프라는 기본적으로 Windows Azure 테이블에 기록합니다. 이러한 WAD 테이블(추적, 이벤트 로그 및 성능 카운터)을 사용하는 경우, 기록된 데이터의 중요도와 기록된 데이터에 액세스하는 사용자를 고려하고 기록된 데이터가 고객 간에 격리(프로비전)되는지, 아니면 시스템 전체에서 공유되는지를 결국 선택해야 합니다. 예를 들어 솔루션 전체의 모든 인스턴스에서 추적을 집계하고 한 테넌트의 데이터를 다른 테넌트에 노출할 수도 있는 진단 로그 테이블에 직접 액세스하는 권한을 모든 테넌트에 제공하지는 않을 것입니다.

관리 리소스에 Windows Azure Blob 사용

Blob 저장소에 저장되는 표준 관리 리소스는 IIS 로그와 크래시 덤프입니다. IIS 로그는 역할 인스턴스에서 Blob 저장소로 전송됩니다. 시스템 모니터링에서 IIS 로그를 사용하는 경우 컨테이너 수준 액세스 정책을 통해 시스템만 이러한 로그에 액세스할 수 있도록 할 것입니다. 테넌트에 이 데이터 중 일부가 필요한 경우 데이터에 대해 후처리를 수행한 다음(아마도 해당 테넌트의 데이터만 포함되도록 하기 위해) 테넌트별 컨테이너를 통해 테넌트로 결과를 보내려고 할 것입니다. 반면에 크래시 덤프는 인프라 문제 해결을 지원하는 서비스 공급자 시스템만 액세스해야 하며 여러 테넌트에 걸쳐 있는 데이터를 포함할 가능성이 높습니다.

계량

다중 테넌트 응용 프로그램의 맥락에서 계량은 용량 계획 및 진행 중인 아키텍처 결정을 알리기 위해 시스템 차원의 KPI를 수집하기 위해서 뿐만 아니라 사용으로 영향을 받는 테넌트에 요금을 청구하기 위해 수행됩니다. 계량되는 항목은 일반적으로 다음과 같습니다.

  • 원시 리소스 사용: Windows Azure 리소스 사용(예: 계산 시간, 데이터 저장소 크기, 메시지 수)

  • 응용 프로그램 기능의 특정한 사용(예: 사용별로 요금이 청구되는 고급 작업)

  • 테넌트 자체 사용자의 사용

마지막 두 항목은 응용 프로그램 관련 요구 사항으로 발생하는 경향이 있으므로 모든 Azure 기반 서비스 공급자에게 일반적인 원시 리소스 소비를 자세히 살펴보겠습니다. 원시 리소스 관점에서 대부분의 SaaS 응용 프로그램의 경우 계산 시간은 단연 가장 중요하며 그 다음이 저장소 크기이고 그보다 중요도가 낮은 것이 데이터 센터에서 나오는 데이터 전송입니다(송신). 특히 Azure 데이터 센터로 들어가는 데이터 전송은 이제 무료입니다.

그러면 원시 계산 또는 저장소에서 계량을 위해 이 데이터를 어떻게 얻을 수 있을까요? 몇 가지 예를 살펴보겠습니다.

계산 시간

불행하게도 서비스 공급자의 구독에 의한 계산 시간을 쿼리하는 API는 현재 없습니다. 가장 좋은 방법은 Windows Azure 계산 시간이 청구되는 방식에 따라 사용량을 어림잡는 것입니다. 예를 들어 할당된 각 인스턴스에 대해 인스턴스 가동 시간을 계산하고 가장 가까운 시간으로 반올림하여 인스턴스 크기에 대한 시간당 비용을 곱합니다.

데이터 저장소

정확한 사용량을 제공하는 Windows Azure 저장소(Blob, 테이블 및 적은 규모로는 큐 또는 캐시 및 서비스 버스 큐)에 대한 공용 청구 또는 관리 API는 없지만, 저장되는 엔터티의 크기를 알고 청구 기간 동안 테넌트가 저장한 평균 엔터티 수를 추적하여 추정할 수 있습니다. SQL 데이터베이스 크기는 예외입니다. master 데이터베이스 내에서 sys.database_usage를 쿼리하고 실제 비용을 얻기 위해 해당 월의 결과를 집계하여 해당 일에 청구될 데이터베이스 크기를 확인할 수 있습니다.

다중 테넌트 솔루션에 대한 계산 크기 조정

특정 요구 사항은 다양하지만 "자동 크기 조정"이 고려될 때의 방법은 추론에 따라 인스턴스 수를 늘리거나 줄이는 것에 해당합니다. 이 추론은 성능 로그, IIS 로그 또는 심지어 큐 크기와 같은 소스에서 파생된 KPI(핵심 성과 지표)에 따라 달라질 수 있습니다. 또는 추론은 회계 응용 프로그램에서 일반적인 월말 급증을 위해 늘리고 다른 시기에 인스턴스 수를 줄이는 등, 일정에 따라 간단히 구현될 수 있습니다.

여기에서 고려할 주요 요인은 인스턴스 수를 늘리거나 줄이는 것은 즉석에서 이루어지지 않는다는 점입니다. 알고리즘은 두 가지 방법으로 이를 통합해야 합니다. 늘릴 때 요청을 예상할 수 있는 경우 인스턴스가 사용 가능해질 수 있으려면 장기 예측이 필요하지 않습니다(하지만 20분 정도). 줄일 때는 사용된 부분 시간에 대해 전체 시간으로 지불하므로 해당 전체 시간 동안 불필요한 인스턴스를 유지하는 것이 경제적으로 유용합니다.

결론 및 리소스

프레임워크 및 샘플

위의 내용을 모두 읽었으면 다중 테넌트 솔루션 작성이 큰 투자임에 동의할 것입니다. 이러한 관점에서 샘플 또는 프레임워크에서 시작하는 것은 좋은 생각입니다. 몇 가지 유용한 시작 지점은 다음과 같습니다.

Windows Azure용 Microsoft Enterprise Library 5.0 통합 팩

Microsoft Enterprise Library는 엔터프라이즈 소프트웨어 개발의 일반적인 문제를 처리하는 재사용 가능한 응용 프로그램 블록의 컬렉션입니다. Windows Azure용 Microsoft Enterprise Library 통합 팩은 Windows Azure 기술 플랫폼과 함께 사용할 수 있는 Microsoft Enterprise Library 5.0의 확장입니다. 이 통합 팩에는 자동 크기 조정 응용 프로그램 블록, 임시 오류 처리 응용 프로그램 블록, Blob 구성 소스, 보호되는 구성 공급자 및 학습 자료가 포함되어 있습니다. 이 응용 프로그램 블록은 시작하기에 좋은 곳입니다.

CloudNinja

CodePlex에서 사용할 수 있는 CloudNinja 샘플은 이 문서에서 설명된 대로 다중 테넌트 지원의 다음 측면을 보여 줍니다.

  • 다중 테넌트 웹 역할

  • 전용 관리/작업자 역할 프로비전

  • SQL 데이터베이스의 선형 분할

  • 관리를 위한 전용 Windows Azure 테이블

  • 프로비전을 위한 전용 Azure 큐

  • 전용 공용/개인 Blob 저장소

  • 다중 테넌트 캐시

  • 시간 및 KPI 기반 자동 크기 조정

  • 계량

  • 사용자 지정 STS 및 ACS를 사용한 페더레이션 보안

Fabrikam Shipping

CodePlex에서 사용할 수 있는 Fabrikam Shipping 샘플은 다중 테넌트 SaaS 제품의 많은 측면을 보여 줍니다.

  • 전용 및 다중 테넌트 웹 역할

  • 전용 관리/작업자 역할 프로비전

  • SQL 데이터베이스의 선형 분할

  • 전용 공용/개인 Blob 저장소

  • 사용자 지정 STS, ADFS, Facebook, Google, Live ID 및 ACS를 사용한 페더레이션 보안

  • PayPal 통합

Enzo SQL Shard 라이브러리

CodePlex에서 사용할 수 있는 Enzo SQL Shard 라이브러리는 이 문서에서 설명한 다양한 SQL 데이터베이스 분할 기법을 보여 주고 도움을 줍니다.

Lokad Cloud

Lokad Cloud는 이 문서에서 설명한 많은 기능을 비롯한 다양한 기능을 제공하는 프레임워크입니다.

  • 자동 크기 조정

  • 강력한 형식의 Azure Blob, 테이블 및 큐 저장소(개체-클라우드 매퍼라고 함)

  • 작업 스케줄러

  • 로깅

Azure 자동 크기 조정

자동 크기 조정을 직접 작성할 간단하고 쉬운 예제를 찾고 있는 경우 CodePlex에서 사용할 수 있는 Azure 자동 크기 조정 샘플을 살펴볼 만합니다. 물론 보다 어려운 측면에 도움을 줄 수 있는 상용 제품도 있습니다. 특히 Paraleap AzureWatch는 응용 프로그램의 크기를 자동으로 조정하는 데 도움을 줄 수 있습니다.  

링크 및 참조

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.

커뮤니티 추가 항목

표시:
© 2014 Microsoft