다중 테넌트 솔루션에서 Azure API Management 사용

Azure API Management는 API에 대한 포괄적인 API 게이트웨이 및 역방향 프록시입니다. 캐싱, 응답 모의 및 개발자 포털을 포함하여 API 중심 애플리케이션에 유용한 많은 기능을 제공합니다. 이 문서에서는 다중 테넌트 솔루션에 유용한 API Management의 주요 기능 중 일부를 요약합니다.

격리 모델

API Management는 일반적으로 여러 테넌트에 대한 요청을 제공하는 단일 인스턴스를 사용하여 공유 구성 요소로 배포됩니다. 그러나 테넌시 모델에 따라 API Management를 배포할 수 있는 여러 가지 방법이 있습니다. 이 문서에서는 배포 스탬프를 사용하여 솔루션을 배포한다고 가정합니다.

일반적으로 API Management를 사용하는 방식은 서로 다른 격리 모델에서 일관성을 유지합니다. 이 섹션에서는 격리 모델 간의 비용과 복잡성의 차이점과 각 접근 방식이 요청을 백 엔드 API 애플리케이션으로 라우팅하는 방법에 대해 집중합니다.

공유 인스턴스 격리 모델

여러 테넌트 간에 API Management 인스턴스를 공유하는 것이 일반적이며, 이는 비용과 배포 및 관리 복잡성을 줄이는 데 도움이 됩니다. API Management 인스턴스를 공유하는 방법에 대한 세부 정보는 백 엔드 API 애플리케이션에 테넌트를 할당하는 방법에 따라 달라집니다.

단일 테넌트 백 엔드 애플리케이션

각 테넌트에 대해 고유한 백 엔드 애플리케이션을 배포하는 경우 단일 API Management 인스턴스를 배포하고 각 요청에 대해 올바른 테넌트 백 엔드로 트래픽을 라우팅할 수 있습니다. 이 방법을 사용하려면 각 테넌트에 대한 백 엔드 호스트 이름으로 API Management를 구성하거나 들어오는 요청을 올바른 테넌트의 백 엔드에 매핑하는 다른 방법이 있어야 합니다.

추가 조회가 필요하기 때문에 이 방법은 단일 API Management 인스턴스를 공유하는 많은 수의 테넌트로 확장되지 않을 수 있습니다. 테넌트 백 엔드를 조회할 때 성능 오버헤드가 발생할 수도 있습니다. 그러나 이 성능 오버헤드의 크기는 이 조회를 디자인하는 방법에 따라 달라집니다.

공유 다중 사용자 백엔드 애플리케이션

테넌트가 공통 백 엔드 애플리케이션을 공유하는 시나리오에서는 모든 요청을 단일 백 엔드로 라우팅할 수 있으므로 API Management 라우팅 프로세스가 간소화됩니다. 와일드카드 도메인 또는 공급자 발급 도메인을 사용하는 경우 이 방법을 사용하여 거의 무제한 규모를 달성할 수 있습니다. 또한 요청을 테넌트의 백 엔드에 매핑할 필요가 없으므로 사용자 지정된 라우팅 결정으로 인한 성능 영향은 없습니다.

각 테넌트에 대한 인스턴스

일부 시나리오에서는 각 테넌트에 대한 API Management 인스턴스를 배포할 수 있습니다. 테넌트가 거의 없거나 테넌트 간에 인프라를 공유하지 못하도록 제한하는 엄격한 규정 준수 요구 사항이 있는 경우에만 이 방법을 사용하는 것이 좋습니다. 예를 들어 각 테넌트에 대한 전용 가상 네트워크를 배포하는 경우 각 테넌트에 대한 전용 API Management 인스턴스도 배포해야 할 수 있습니다.

API Management 인스턴스를 배포할 때는 서비스 제한을 고려해야 합니다. 특히, Azure 구독 또는 지역 내에서 API Management 인스턴스 수에 적용될 수 있는 제한사항을 포함합니다.

단일 테넌트 인스턴스는 일반적으로 모든 요청을 단일 백 엔드로 라우팅할 수 있기 때문에 최소한의 라우팅 구성을 갖습니다. 이 시나리오에서는 사용자 지정 라우팅 결정이 필요하지 않으므로 성능에 영향을 주지 않습니다. 그러나 일반적으로 공유 인스턴스를 배포하는 경우보다 더 높은 리소스 비용이 발생합니다. 단일 테넌트 인스턴스를 배포해야 할 경우, 자체 호스팅 게이트웨이를 사용하여 이미 배포한 테넌트별 컴퓨팅 리소스를 다시 사용할 수 있는지 고려하십시오.

다중 테넌트를 지원하는 API Management 기능

API Management는 정책을 사용하여 유연성을 제공합니다. 정책을 사용할 때 요청의 유효성을 검사하고, 라우팅하고, 처리하는 방법을 사용자 지정할 수 있습니다. 또한 API Management를 사용하여 다중 테넌트 솔루션을 디자인할 때 정책을 사용하여 많은 기능을 구현합니다.

들어오는 요청에서 테넌트 식별

들어오는 각 요청 내에서 적절한 테넌트 식별 방법을 고려합니다. 다중 테넌트 솔루션에서는 특정 테넌트에 대한 데이터를 반환하고 다른 누구도 반환하지 않도록 각 요청을 만드는 사용자를 명확하게 이해하는 것이 중요합니다.

API Management는 요청을 인증하는 데 사용할 수 있는 구독을 제공합니다. 이러한 구독은 요청을 하는 구독자를 식별하는 데 도움이 되는 고유한 구독 키를 사용합니다. 구독을 사용하도록 선택하는 경우 API Management 구독을 사용자 고유의 테넌트 또는 고객 식별자에 매핑하는 방법을 고려합니다. 구독은 개발자 포털에 긴밀하게 통합됩니다. 대부분의 솔루션에서 구독을 사용하여 테넌트를 식별하는 것이 좋습니다.

또는 다른 방법을 사용하여 테넌트 식별할 수 있습니다. 다음 예제 방법은 사용자가 정의하는 사용자 지정 정책 내에서 실행됩니다.

• URL의 사용자 지정 구성 요소(예: 하위 도메인, 경로 또는 쿼리 문자열)를 사용합니다. 예를 들어 URL https://api.contoso.com/tenant1/products에서 경로의 첫 번째 부분인 tenant1을 추출하여 테넌트 식별자로 사용할 수 있습니다. 마찬가지로 들어오는 URL https://tenant1.contoso.com/products을 지정하면 하위 도메인 tenant1을 추출할 수 있습니다. 이 방법을 사용하려면 Context.Request.Url 속성에서 경로 또는 쿼리 문자열을 구문 분석하는 것을 고려하십시오.

• 요청 헤더를 사용합니다. 예를 들어 클라이언트 애플리케이션은 요청에 사용자 지정 X-TenantID 헤더를 추가할 수 있습니다. 이 방법을 사용하려면 Context.Request.Headers 컬렉션에서 읽기를 고려해 보세요.

• JWT(JSON 웹 토큰)에서 클레임을 추출합니다. 예를 들어, ID 공급자가 발급하는 JWT에 사용자 정의 tenantId 클레임이 포함될 수 있습니다. 이 접근 방식을 사용하려면 validate-jwt 정책을 적용하고 정책 정의가 토큰에서 값을 읽을 수 있도록 output-token-variable-name 속성을 설정합니다.

• 동적으로 테넌트 식별자를 조회합니다. 요청이 처리되는 동안 외부 데이터베이스 또는 서비스와 통신할 수 있습니다. 이 방법을 사용하면 논리 테넌트 식별자를 특정 URL에 매핑하거나 테넌트에 대한 자세한 정보를 가져오는 사용자 지정 테넌트 매핑 논리를 만들 수 있습니다. 이 방법을 적용하려면 송신 요청 정책을 사용합니다.

  이 방법은 요청의 대기 시간을 증가시킬 가능성이 높습니다. 이 효과를 완화하려면 캐싱을 사용하여 외부 API에 대한 호출 수를 줄이는 것이 좋습니다. cache-store-value 및 cache-lookup-value 정책을 사용하여 캐싱 방식을 구현할 수 있습니다. 백 엔드 조회에 영향을 주는 추가, 제거 또는 이동된 각 테넌트에서 캐시를 무효화해야 합니다.

명명된 값

API Management는 정책 전반에서 사용할 수 있는 사용자 지정 구성 설정인 명명된 값을 지원합니다. 예를 들어 명명된 값을 사용하여 테넌트의 백 엔드 URL을 저장한 다음 정책 내의 여러 위치에서 동일한 값을 다시 사용할 수 있습니다. URL을 업데이트해야 하는 경우 한 곳에서 업데이트할 수 있습니다.

들어오는 요청 인증

API Management 게이트웨이에 대한 API 요청은 일반적으로 인증되어야 합니다. API Management는 OAuth 2.0 및 클라이언트 인증서를 포함하여 게이트웨이에 들어오는 요청을 인증하는 여러 가지 방법을 제공합니다. 지원해야 하는 자격 증명 유형과 유효성을 검사해야 하는 위치를 고려합니다. 예를 들어 API Management, 백 엔드 애플리케이션 또는 두 위치에서 유효성 검사가 수행되어야 하는지 여부를 고려합니다.

자세한 내용은 API Management에서 API에 대한 인증 및 권한 부여를 참조하세요.

테넌트별 백 엔드로 경로 설정

API Management를 공유 구성 요소로 사용하는 경우 들어오는 API 요청을 다른 테넌트별 백 엔드로 라우팅해야 할 수 있습니다. 이러한 백 엔드는 다른 배포 스탬프에 있거나 단일 스탬프 내에서 다른 애플리케이션일 수 있습니다. 정책 정의에서 라우팅을 사용자 지정하려면 set-backend-service 정책을 사용합니다. 요청을 리디렉션해야 하는 새 기본 URL을 지정해야 합니다.

응답 또는 기타 데이터 캐시

API Management에는 전체 HTTP 응답 또는 다른 데이터를 캐시하는 데 사용할 수 있는 강력한 캐시 기능이 있습니다. 예를 들어 사용자 지정 논리를 사용하거나 외부 서비스에서 매핑을 조회하는 경우 테넌트 매핑에 캐시를 사용할 수 있습니다.

캐시 저장소-값 및 cache-lookup-value 정책을 사용하여 캐싱 방법을 구현합니다.

큰 언어 모델 API

API가 큰 언어 모델을 호출할 때 API Management에서 AI 게이트웨이 기능을 사용합니다. 이러한 기능은 다중 테넌트 솔루션에서 비용, 성능 및 격리를 제어하는 데 도움이 됩니다.

의미 기반 캐싱

API가 Azure OpenAI 모델 앞에 있는 경우 반복 또는 거의 중복 프롬프트에 대한 비용 및 대기 시간을 줄이기 위해 API Management에서 의미 체계 캐싱을 사용하는 것이 좋습니다.

자세한 내용은 다음 리소스를 참조하세요.

• 시맨틱 캐싱 활성화
• Azure OpenAI API 요청에 대한 캐시 응답
• Azure OpenAI API 요청의 캐시된 응답 가져오기

프롬프트와 답변이 의도한 테넌트에 격리되도록 요소를 사용하여 vary-by 테넌트당 캐시를 분할해야 합니다. lookup 정책을 인바운드 처리에 배치하고 store 아웃바운드 처리에 정책을 배치합니다.

다음 예제에서는 의미 체계 캐시 항목이 구독 ID 또는 키별로 분할되는 방법을 보여 있습니다.

<!-- inbound -->
<azure-openai-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Subscription.Id)</vary-by>
   <!-- or: <vary-by>@(context.Subscription.Key)</vary-by> -->
</azure-openai-semantic-cache-lookup>

<!-- outbound -->
<azure-openai-semantic-cache-store duration="60" />

다음 예제에서는 테넌트 클레임 또는 헤더별로 의미 체계 캐시를 분할합니다.

<!-- inbound; requires validate-jwt if using a claim -->
<azure-openai-semantic-cache-lookup
   score-threshold="0.05"
   embeddings-backend-id="embeddings-backend"
   embeddings-backend-auth="system-assigned">
   <vary-by>@(context.Principal?.Claims.GetValueOrDefault("tenantId", ""))</vary-by>
   <!-- Alternative using a custom header: -->
   <!-- <vary-by>@(context.Request.Headers.GetValueOrDefault("TenantID", ""))</vary-by> -->
</azure-openai-semantic-cache-lookup>

<!-- outbound -->
<azure-openai-semantic-cache-store duration="60" />

큰 언어 모델에 대한 토큰 기반 제한

AI 게이트웨이에서 토큰 기반 제한을 사용하여 개별 요청뿐만 아니라 각 테넌트에 대한 사용량을 제한합니다. Azure OpenAI 백 엔드를 사용하는 경우 azure-openai-token-limit 정책을 사용합니다. OpenAI 호환 백 엔드 또는 Azure AI 모델 유추 API의 경우 llm-token-limit 정책을 사용합니다. 자세한 내용은 토큰 제한 정책을 참조하세요.

구독 ID 또는 테넌트 ID 토큰 클레임과 같이 테넌트에 고유한 키를 선택하여 제한이 각 테넌트를 효과적으로 격리하도록 합니다. 토큰 사용량은 각 게이트웨이, 지역 또는 작업 영역에서 독립적으로 추적되며 카운터는 전체 인스턴스에서 집계되지 않습니다.

다음 예제에서는 각 테넌트가 구독별로 분당 60,000개의 토큰으로 제한됩니다.

<azure-openai-token-limit
   counter-key="@(context.Subscription.Id)"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

다음 예제에서는 테넌트 클레임 또는 헤더로 제한합니다.

<!-- Using a tenant claim; requires validate-jwt earlier in the pipeline -->
<azure-openai-token-limit
   counter-key="@(context.Principal?.Claims.GetValueOrDefault(&quot;tenantId&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

<!-- Or using a custom header populated by your edge/CDN/gateway -->
<azure-openai-token-limit
   counter-key="@(context.Request.Headers.GetValueOrDefault(&quot;TenantID&quot;, &quot;&quot;))"
   tokens-per-minute="60000"
   estimate-prompt-tokens="false" />

사용자 지정 도메인

API Management를 사용하여 API 게이트웨이 및 개발자 포털에 대한 사용자 지정 도메인을 구성합니다 . 일부 계층에서는 와일드카드 도메인 또는 여러 FQDN(정규화된 도메인 이름)을 구성할 수 있습니다.

API Management는 Azure Front Door와 같은 서비스와 함께 사용할 수도 있습니다. 이러한 종류의 구성에서 Azure Front Door는 사용자 지정 도메인 및 TLS(전송 계층 보안) 인증서를 자주 처리하고 단일 도메인 이름을 사용하여 API Management와 통신합니다. 클라이언트의 원래 URL에 나중에 처리하기 위해 API Management 인스턴스로 보내야 하는 테넌트 정보가 포함된 경우 요청 헤더를 사용 X-Forwarded-Host 하거나 Azure Front Door 규칙을 사용하여 정보를 HTTP 헤더로 전달하는 것이 좋습니다.

속도 제한

다중 테넌트 솔루션에서 할당량 또는 속도 제한을 적용하는 것이 일반적입니다. 속도 제한은 시끄러운 인접 문제를 완화하는 데 도움이 될 수 있습니다. 또한 속도 제한을 사용하여 서비스 품질을 적용하고 서로 다른 가격 책정 계층을 구분할 수 있습니다.

API Management를 사용하여 테넌트별 속도 제한을 적용합니다. 테넌트별 구독을 사용하는 경우 할당량 정책을 사용하여 각 구독에 대한 할당량을 적용하는 것이 좋습니다. 또는 요청 URL 또는 JWT에서 가져오는 테넌트 식별자와 같은 다른 속도 제한 키를 사용하여 할당량을 적용하는 데 키별 할당량 정책을 사용하는 것이 좋습니다.

자세한 내용은 큰 언어 모델에 대한 토큰 기반 제한을 참조하세요.

수익 창출

API Management 설명서는 샘플 구현 을 포함하여 API로 수익을 창출하는 방법에 대한 광범위한 지침을 제공합니다. 수익 창출 방법은 개발자가 API를 게시하고, 구독을 관리하고, 다양한 사용 모델을 기반으로 요금을 청구할 수 있도록 API Management의 많은 기능을 결합합니다.

용량 관리

API Management 인스턴스는 요청을 처리하는 데 사용할 수 있는 리소스를 나타내는 특정 용량을 지원합니다. 복잡한 정책을 사용하거나 인스턴스에 더 많은 API를 배포하는 경우 더 많은 용량을 사용합니다. 더 많은 단위를 구매하는 등 여러 가지 방법으로 인스턴스의 용량을 관리할 수 있습니다. 인스턴스의 용량을 동적으로 확장할 수도 있습니다.

일부 다중 테넌트 인스턴스는 요청을 다른 테넌트 백 엔드로 라우팅하는 데 많은 정책을 사용하는 경우처럼 단일 테넌트 인스턴스보다 더 많은 용량을 사용할 수 있습니다. 용량 계획을 신중하게 고려하고 사용량이 증가하는 경우 인스턴스의 용량 크기를 조정하도록 계획합니다. 또한 솔루션의 성능을 테스트하여 용량 요구 사항을 미리 이해해야 합니다.

API Management 크기 조정에 대한 자세한 내용은 API Management 인스턴스 업그레이드 및 크기 조정을 참조하세요.

다중 지역 배포

API Management 는 다중 지역 배포를 지원합니다. 즉, 구성을 별도의 리소스로 복제할 필요 없이 여러 Azure 지역에 단일 논리 API Management 리소스를 배포할 수 있습니다. 이 기능은 솔루션을 전역적으로 배포하거나 복제할 때 특히 유용합니다. 대기 시간이 짧은 요청 처리를 허용하는 여러 지역에 API Management 인스턴스를 효과적으로 배포하고 단일 논리 인스턴스로 관리할 수 있습니다.

그러나 완전히 격리된 API Management 인스턴스가 필요한 경우 독립적인 API Management 리소스를 다른 지역에 배포하도록 선택할 수도 있습니다. 이 방법은 각 API Management 인스턴스에 대한 관리 평면을 구분합니다.

기여자

Microsoft는 이 문서를 유지 관리합니다. 다음 기여자는 이 문서를 작성했습니다.

주요 작성자:

• John Downs | 주요 소프트웨어 엔지니어, Azure 패턴 및 사례
• 다니엘 스콧-레인스포드 | 선임 파트너 솔루션 설계자, 엔터프라이즈 파트너 솔루션

기타 기여자:

• Arsen Vladimirskiy | 수석 고객 담당 엔지니어

LinkedIn 비공개 프로필을 보려면, LinkedIn에 로그인하세요.

관련 참고 자료

• 다중 테넌트 솔루션의 테넌트 통합 및 데이터 액세스를 위한 아키텍처 접근 방식
• Azure에서 다중 테넌트 솔루션 아키텍처
• Azure에서 멀티 테넌트 솔루션의 설계 및 구축을 위한 검사 목록
• 다중 테넌트 솔루션에 대해 고려해야 하는 테넌트 모델