Azure API Management를 활용한 확장 가능한 멀티 모델 AI 게이트웨이 구축

Azure API Management를 이용한 AI 게이트웨이 개요

조직의 AI 워크로드가 확장됨에 따라, 기업들은 실질적인 한계에 부딪힙니다. 모델별 처리량 제한(throughput caps), 토큰 속도 제한(token rate limits), 구독 할당량(subscription quotas) 등이 있으며, 팀과 지역 전반에 걸쳐 분산된 Azure OpenAI 배포 목록이 늘어나고 있습니다. 단일 리소스만으로는 고용량의 멀티 모델, 멀티 팀 트래픽을 모두 감당할 수 없습니다. 기본적인 프롬프트 수준을 넘어 엔터프라이즈급 플랫폼으로 나아가기 위해서는 견고한 아키텍처가 필요합니다. 이 전환에 대한 더 자세한 내용은 다음 글을 참고하세요.

From Prompt to Production: Building Enterprise-Grade AI Systems Without Fine-Tuning - CapeStart

favicon capestart.com

이 문제를 해결하는 제어 평면(control plane)은 Azure API Management를 갖춘 중앙 집중식 AI 게이트웨이입니다. 이는 여러 백엔드를 단일하고 안전한 인터페이스 뒤로 라우팅(routes), 로드 밸런싱(load-balances)하며 추상화(abstracts)합니다.

본 글에서는 여러 개의 Azure OpenAI 계정을 연결하는 게이트웨이를 설계하는 방법, GPT-4o, GPT-4 Turbo, 임베딩(embeddings), 비전 모델을 통합된 계약(unified contract)으로 노출하는 방법, 그리고 엣지(edge)에서 신원 확인 및 할당량(quotas)을 강제하는 방법을 설명합니다. 또한 '무제한 스타일'의 스케일링이 실제로 무엇을 의미하는지 명확히 하고, 라우팅, 할당량 관리, 관측 가능성(observability), 멀티 테넌트 거버넌스(multi-tenant governance), 재해 복구(disaster recovery), 그리고 프로덕션 준비 상태가 프록시를 견고한 플랫폼으로 어떻게 변화시키는지 설명합니다.

Azure API Management와 함께 AI 게이트웨이가 필요한 이유

성장 문제는 모델 품질에서 발생하는 경우가 드물며, 토큰/분(TPM) 제한, 요청/분(RPM) 제한, 그리고 각 애플리케이션이 자체 엔드포인트 목록을 관리해야 하는 운영상의 부담에서 비롯됩니다. Azure OpenAI는 배포별로 TPM 및 RPM 제약을 적용하며 구독 수준의 상한선도 설정합니다. 더욱이, 팀들은 종종 여러 리전에 걸쳐 호스팅되는 다양한 모델(예: 채팅, 임베딩, 비전 또는 RAG 스코어링)을 필요로 합니다. 중앙 집중식 게이트웨이가 없다면, 모든 애플리케이션은 자체 호스트 목록, 액세스 키, 재시도 로직을 유지해야 합니다.

아래 패턴이 일반적인 병목 지점입니다. GPT-4o 배포는 할당된 분당 토큰만 허용합니다. 동일한 구독에 더 많은 배포를 추가해도 구독 수준의 스로틀링과 충돌할 수 있습니다. 글로벌 제품은 한 코호트(cohort)에는 East US가, 다른 코호트에는 West Europe이 필요하며, 재무팀은 GPT-4o-mini가 할 수 있는 요약 작업에 GPT-4o 예산을 소진해서는 안 됩니다. APIM은 로드 밸런서, 정책 엔진, 트래픽 라우터 역할을 하여 이러한 제약을 한 번에 해결합니다.

Microsoft는 Azure OpenAI 할당량 및 제한 사항 가이드에서 근본적인 상한선을 문서화합니다. 게이트웨이가 이 상한선을 제거하는 것은 아닙니다. 대신, 독립적인 상한선들을 풀(pool)하고 요청마다 어떤 남은 범위(envelope)를 사용할지 결정합니다. 그 구분이 바로 무제한 스타일 스케일링(Unlimited-Style Scaling)의 주제입니다.

참고 아키텍처

클라이언트(product services, analytics jobs, RAG 파이프라인 포함)는 https://ai.company.com와 같은 통합 진입점(unified entry point)을 호출합니다. Azure API Management가 단일 프론트 도어 역할을 합니다. APIM 뒤에는 이름이 지정된 백엔드들(named backends)이 위치합니다: Account A (East US 지역, GPT-4o 및 GPT-4o-mini 사용), Account B (West Europe 지역, GPT-4 Turbo 및 비전 모델 사용), 그리고 Account C (임베딩 및 파인튜닝 모델 사용). Log Analytics와 비용 대시보드는 메타데이터를 소비하는 '핫 패스(hot path)' 밖에 위치하며, 이 메타데이터는 게이트웨이에 의해 각 요청에 찍힙니다.

Azure API Management를 활용한 AI 게이트웨이의 백엔드 선택 방식

요청은 단일 completions 또는 embeddings URL로 도착합니다. APIM은 호출자를 인증하고, 테넌트 및 제품 할당량(quota)을 적용하며, 해당 호출이 소비할 토큰 수를 추정합니다. 그런 다음 라우터는 요청된 모델을 호스팅하고, 남아있는 TPM과 RPM을 보유하며, 해당 테넌트의 지연 시간(latency) 및 지역 정책을 충족하는 건강한 백엔드를 선택합니다. 이 백엔드 호출은 게이트웨이의 관리 ID(managed identity)를 사용합니다. 클라이언트는 어떤 계정이 응답했는지 절대 알 수 없으며, 응답 경로는 실제 토큰 사용량을 기록하여 다음 결정이 이전보다 더 나아지도록 합니다.

APIM이 적절한 이유는 정책(policies)이 이미 choose, send-request, retry, rate-limit, token-limit 등을 다루기 때문입니다. 네이티브 로드 밸런싱은 단지 시작점일 뿐입니다. 다음 섹션들은 정책이 읽어야 할 신호(signals)와 해당 신호가 어디에 존재하는지를 명시합니다.

무제한 스타일 스케일링: 무한한 용량이 아닌 더 많은 용량

'무제한 스타일(Unlimited-style)' 스케일링은 매우 정확한 의미를 가지며, 무한한 용량을 의미하지는 않습니다. 각 Azure OpenAI 리소스는 자체적인 TPM, RPM 및 프로비저닝된 처리량(provisioned-throughput, PTU) 할당을 유지합니다. 이러한 상한선들은 계약적이며 지역별입니다. APIM을 하나의 리스토어 앞에 배치한다고 해서 이 한계들이 높아지는 것은 아닙니다.

게이트웨이는 여러 독립적인 계정(종종 여러 리전에 걸쳐)을 배치하고, 때로는 종량제(pay-as-you-go)와 PTU를 하나의 URL 뒤에 혼합함으로써 플랫폼이 소비할 수 있는 총 할당량을 늘릴 수 있습니다. 각 계정은 자체적인 엔벨로프(envelope)를 가집니다. 트래픽이 이러한 엔벨로프들에 분산되면, 사용 가능한 용량은 남아있는 정상 백엔드 할당량의 합계에서 장애 조치(failover)를 위해 확보하는 여유분을 뺀 값이 됩니다. 이는 하나의 계정이 제공할 수 있는 것보다 더 큰 숫자입니다. 하지만 여전히 유한한 숫자입니다.

중요: 작업을 분산하면 사용 가능한 할당량이 증가하고, 단일 리소스의 429 에러가 전체 시스템을 마비시킬 가능성이 줄어듭니다. 그러나 무제한 토큰, 무제한 동시성(concurrency), 또는 지역적 사고로부터의 면역성을 제공하지는 않습니다. 용량 계획 및 테넌트 입장 제어(tenant admission control)는 여전히 필수적입니다.

실용적인 풀은 제한 사항이 서로 대체되는 것이 아니라 합산되는 세 개의 계정처럼 보입니다. East US에 있는 Account A는 GPT-4o와 GPT-4o-mini를 호스팅하며 하나의 완전한 TPM 엔벨로프를 기여합니다. West Europe에 있는 Account B는 GPT-4 Turbo와 비전 기능을 호스팅하며 두 번째 엔벨로프를 기여합니다. Account C는 임베딩 및 RAG 모델을 호스팅하며 세 번째 엔벨로프를 기여합니다. 나중에 Account D를 추가하면 풀이 다시 증가합니다. Account B를 제거하거나 실패시키면 풀이 줄어듭니다. 플랫폼의 실제 용량은 항상 마케팅적인 무한대가 아니라 실시간 합계입니다.

관찰된 요청당 P95 토큰과 목표 RPS를 기반으로 풀의 크기를 결정하고, 지역적 이벤트로 인해 생존 자원이 즉시 고갈되지 않도록 최소한 하나의 백엔드 분량의 여유 용량을 확보해야 합니다. APIM 단위 수, Redis(할당 상태에 사용되는 경우), 그리고 DNS는 별도의 상한선입니다. 이러한 계층들을 확인하지 않고 OpenAI 계정을 추가하는 팀도 여전히 429 에러를 받게 될 것입니다. 인텔리전트 라우팅(Intelligent Routing)은 풀이 소비되는 방식이며, 재해 복구(Disaster Recovery)는 풀의 일부가 사라질 때 발생하는 일입니다.

인텔리전트 라우팅 로직

Round-robin은 백엔드가 동일하고 정상적일 때 합리적인 기본값입니다. 하지만 Azure OpenAI의 프로덕션 환경에서는 충분하지 않습니다. TPM과 RPM이 불균등하게 소모되는 이유는 프롬프트 크기가 다양하고, 테넌트 사용량이 급증하며(bursty), 모델이 모든 리전에 배포되어 있지 않고, '정상 작동'하는 백엔드라 할지라도 이미 토큰 창의 95%에 도달했을 수 있기 때문입니다. 무작위 라우팅(Blind rotation)은 대용량 응답을 곧 429 에러가 날 백엔드로 보내고, 같은 리소스를 재시도하여 실패를 증폭시킬 수 있습니다.

아래 예시는 대부분의 팀이 작성하는 시작 정책입니다. 이는 개요로는 유용하지만 프로덕션 라우터로서는 불완전합니다. 요청 전반에 걸친 진정한 로테이션(True rotation)을 위해서는 공유 상태가 필요하며, APIM 변수만으로는 게이트웨이 노드별로 사용되고 초기화되기 때문입니다.

<policies> <inbound> <set-variable name="route" value="@(context.Variables.GetValueOrDefault<int>("roundRobin", 0) % 3)" /> <choose> <when condition="@((int)context.Variables["route"] == 0)"> <set-backend-service base-url="https://openai-account-a.openai.azure.com/" /> </when> <when condition="@((int)context.Variables["route"] == 1)"> <set-backend-service base-url="https://openai-account-b.openai.azure.com/" /> </when> <otherwise> <set-backend-service base-url="https://openai-account-c.openai.azure.com/" /> </otherwise> </choose> </inbound> </policies>

프로덕션 라우터는 모든 요청에 대해 후보 세트를 평가합니다. 이는 로직을 모든 마이크로 서비스 내부에 배치하는 대신, APIM 정책과 Redis 기반 또는 함수 기반의 의사결정(decision)을 사용합니다. 먼저 요청된 모델이나 API 버전을 호스팅하지 않거나, 호출자의 허용 지역 밖에 있거나, 상태 확인기(health checker)가 실패로 표시한 백엔드를 제외합니다. 남은 후보들은 현재 TPM 및 RPM 활용률, 진행 중인 동시성(in-flight concurrency), 최근 P95 지연 시간(latency), 이번 창의 남아 있는 할당량(quota), 그리고 이 요청이 해당 백엔드에 이미 재시도된 횟수를 기준으로 점수화됩니다. 가장 낮은 건강한 점수가 승리합니다. 동점일 경우 가중치 기반 라운드 로빈으로 폴백하여 새로 복구된 백엔드가 과부하되는 것을 방지할 수 있습니다.

재시도 횟수(Retry count)는 일급 입력값입니다. 첫 번째 시도는 여유 TPM을 가진 지연 시간이 가장 짧은 리전 내 백엔드를 선호합니다. 429 또는 5xx 오류가 발생하면, 가급적 다른 리전에 있는 다른 계정으로 재시도하며, 대안이 없는 한 이 요청에 대해 이미 시도된 백엔드로는 절대 재시도하지 않습니다. 서킷 브레이커(Circuit breakers)는 429 비율, 5xx 비율, 프로브 실패 또는 지연 시간 SLO 위반이 임계값을 초과할 때 열립니다. 동시 요청 제한(Concurrent request caps)은 단일 느린 모델이 모든 APIM 스레드를 점유하는 것을 방지합니다. 비용도 결정 요소가 될 수 있습니다. 비필수적인 요약 작업의 경우, 품질 정책이 허용한다면 GPT-4o-mini를 선호할 수 있습니다.

Adaptive routing은 set-backend-service 이전에 실시간 활용률을 확인합니다:

<send-request mode="new" response-variable-name="quotaResponse" timeout="5" backend-id="quota-checker" /> <choose> <when condition="@(int.Parse(((IResponse)context.Variables["quotaResponse"]).Body.As<string>()) < 80)"> <set-backend-service backend-id="aoai-eastus-a" /> </when> <otherwise> <set-backend-service backend-id="aoai-westeurope-b" /> </otherwise> </choose>

결정이 실행되는 위치: APIM은 호출자가 하나의 URL을 유지하도록 실행 지점으로 남아 있습니다. 네이티브 APIM 로드 밸런싱은 라운드 로빈(round-robin)과 우선순위를 처리합니다. TPM 인식 선택, 재시도 인식 제외, 그리고 지연 시간 점수화는 set-backend-service 이전에 Redis 또는 사설 할당량 확인기 API에서 라우팅 상태를 읽어옵니다. 클라이언트는 백엔드 목록을 구현하지 않습니다.

라우팅은 읽어오는 신호만큼만 좋습니다. 이러한 신호는 할당량 관리(Quota Management)가 소유하고 관측 가능성(Observability)에 게시합니다. 전체 리전이 0점을 기록할 때의 장애 조치는 재해 복구(Disaster Recovery)에서 정의됩니다.

할당량 관리 (Quota Management)

할당량은 단일 카운터가 아닙니다. 토큰 소비, 요청 속도, 그리고 백엔드 용량이 서로 다른 계층에 존재하며, 아키텍처는 어떤 결정에 대해 어느 계층이 권한을 갖는지 명시합니다.

무엇이 추적되며, 어디서 (What is Tracked, and Where)

Azure OpenAI는 각 리소스의 TPM, RPM 및 PTU에 대한 진실 공급원(source of truth)입니다. 이 서비스는 게이트웨이가 정상적으로 작동하든 아니든 해당 한도를 강제합니다. Azure OpenAI에서 429 에러가 발생했다는 것은 해당 엔벨로프가 소진되었다는 의미입니다. APIM은 제품, 구독 및 테넌트의 진입 제어에 대한 진실 공급원입니다. 속도 제한(Rate-limit), 할당량(quota) 및 llm-토큰 제한 정책은 노이즈 메이커를 보호하고 상업적 계약을 이행합니다. 이러한 정책들이 Azure OpenAI 자체의 한도를 대체하는 것은 아닙니다.