멀티테넌트 API에서 전체 요청 수만 제한하면 한 고객의 급증이 다른 고객의 응답까지 늦출 수 있습니다. 반대로 고객별 제한만 두면 전체 서버가 버티지 못할 수 있습니다. 좋은 사용량 정책은 공유 자원과 고객별 몫을 함께 보호합니다.
전역 상한과 테넌트 상한을 분리한다
전역 상한은 시스템 전체의 안전장치이고 테넌트 상한은 고객 간 간섭을 줄입니다. API 종류별 비용도 다르므로 단순 요청 횟수보다 무거운 내보내기·AI 추론에는 별도 예산을 둘 수 있습니다. 제한값은 실제 처리 용량을 바탕으로 정합니다.
순간 폭주와 지속 사용을 구분한다
짧은 시간의 정상적인 업무 집중을 모두 차단하면 사용성이 나빠집니다. 토큰 버킷처럼 일정한 여유를 허용하면서 지속 속도를 제한할 수 있습니다. 다만 고객별 계약량과 전체 서버 여력을 함께 확인해야 합니다.
대기열도 공정하게 나눈다
요청 수를 허용했어도 하나의 큰 작업이 워커를 오래 점유할 수 있습니다. 고객별 동시 실행 수와 큐 우선순위를 따로 둡니다. 장시간 보고서 생성은 실시간 조회와 다른 대기열로 분리하는 편이 안정적입니다.
거절 응답을 예측 가능하게 만든다
제한 초과 시 명확한 상태 코드와 재시도 방식을 안내합니다. 클라이언트가 즉시 무한 재시도하면 장애가 커집니다. 서버는 상황에 맞는 재시도 간격을 제시하고, 소비자는 지수 백오프와 멱등성을 적용합니다.
큰 고객을 벌주는 정책이 되지 않게 한다
정상 성장으로 사용량이 증가했다면 계약과 인프라를 함께 조정해야 합니다. 고객별 제한 도달률, 전체 큐 지연, 다른 고객의 응답시간을 보며 정책을 튜닝합니다. 목표는 사용량 억제가 아니라 예측 가능한 서비스 품질입니다.
현장에 적용할 때의 순서
- 전체 용량과 고객별 요청 예산을 분리한다
- 무거운 비동기 작업은 별도 큐와 동시성 제한을 둔다
- 제한 응답과 백오프를 소비자에게 안내한다
주의할 실패: 고객별 제한만 두면 합산 부하가 전체 시스템 용량을 넘길 수 있다.
관찰할 지표: 테넌트별 제한 도달률, 큐 대기, 다른 고객의 P95 응답시간을 본다.
적용 전 체크리스트
- 전역·테넌트·기능별 예산이 분리돼 있는가
- 무거운 작업의 동시 실행과 대기열을 제어하는가
- 제한 초과 시 클라이언트 재시도가 폭주하지 않는가
참고 자료
AWS API Gateway request throttling. AWS 문서는 계정·단계·사용 계획 등의 요청 제한 계층을 설명합니다. 고객별 큐 공정성은 애플리케이션 운영 설계의 제안입니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#API제한 #멀티테넌트 #레이트리밋 #SaaS운영 #토큰버킷 #공정성 #API성능 #대기열 #재시도 #서비스안정성
