신원 확인 API 요청 제한

기업들이 사용자 온보딩, 사기 방지, 그리고 규정 준수를 위해 디지털 신원 확인(IDV)에 점점 더 의존함에 따라, IDV API의 보안과 성능이 매우 중요해지고 있습니다. 강력한 IDV 시스템의 핵심 구성 요소는 효과적인 API 요청 제한을 구현하는 것입니다. 이 글에서는 요청 제한의 중요성, 구현 모범 사례, 그리고 Didit이 안전하고 안정적인 서비스를 제공하기 위해 요청 제한을 어떻게 처리하는지 자세히 살펴봅니다.

핵심 내용 1 요청 제한은 IDV API를 악용으로부터 보호하여 합법적인 사용자를 위한 서비스 가용성을 보장합니다.

핵심 내용 2 효과적인 요청 제한에는 적절한 알고리즘 선택, 적절한 제한 설정, 그리고 유용한 오류 응답 제공이 포함됩니다.

핵심 내용 3 Didit은 보안, 공정성, 그리고 개발자 경험의 균형을 맞추는 정교한 요청 제한 시스템을 사용합니다.

핵심 내용 4 제대로 설계된 요청 제한은 전반적인 API 보안과 시스템 복원력의 핵심 요소입니다.

신원 확인을 위한 API 요청 제한이 필수적인 이유

신원 확인 API는 악의적인 공격자들의 주요 대상입니다. 무차별 대입 공격, 자격 증명 스터핑, 그리고 서비스 거부(DoS) 시도는 시스템을 압도하여 서비스 중단 및 잠재적인 보안 침해로 이어질 수 있습니다. API 요청 제한은 방어 메커니즘 역할을 하여 특정 시간 내에 클라이언트가 수행할 수 있는 요청 수를 제한합니다. 이를 통해 API가 과부하되는 것을 방지하고 합법적인 사용자의 가용성을 보장하며 악용을 방지합니다. API 요청 제한이 없으면 공격자가 짧은 기간 내에 수천 개의 ID 문서를 제출하여 상당한 리소스 부담을 초래하고 시스템을 손상시킬 수 있습니다.

요청 제한 알고리즘 및 전략

API 요청 제한을 구현하는 데 사용할 수 있는 몇 가지 알고리즘이 있습니다. 일반적인 접근 방식은 다음과 같습니다.

• 토큰 버킷: 가상 버킷에 요청 허용량을 나타내는 토큰이 저장됩니다. 각 요청은 토큰을 소모합니다. 토큰은 고정된 속도로 보충됩니다. 이를 통해 트래픽 버스트를 허용하면서 평균 속도를 유지합니다.
• 누수 버킷: 토큰 버킷과 유사하지만 요청은 고정된 속도로 처리되고 초과되는 요청은 삭제됩니다.
• 고정 시간 창 카운터: 고정된 시간 창(예: 60초) 내의 요청 수를 계산합니다. 제한에 도달하면 다음 창이 될 때까지 추가 요청이 차단됩니다.
• 슬라이딩 윈도우 로그: 최근 요청의 로그를 유지합니다. 요청 제한은 슬라이딩 윈도우 내의 요청을 기반으로 계산됩니다. 이는 고정된 윈도우보다 더 정확한 요청 제한을 제공하지만 더 많은 리소스가 필요합니다.
• 슬라이딩 윈도우 카운터: 고정된 윈도우 카운터와 슬라이딩 윈도우 로그를 결합한 하이브리드 접근 방식으로 정확성과 성능의 균형을 제공합니다.

올바른 알고리즘을 선택하는 것은 원하는 정확도, 성능, 복잡성과 같은 특정 요구 사항에 따라 달라집니다. IDV API의 경우 계층화된 보호를 제공하기 위해 여러 알고리즘을 함께 사용하는 경우가 많습니다.

IDV API를 위한 효과적인 요청 제한 설계

적절한 요청 제한을 설정하는 것이 중요합니다. 너무 제한적인 제한은 합법적인 사용자를 좌절시킬 수 있으며, 너무 관대한 제한은 충분한 보호를 제공하지 못할 수 있습니다. 고려해야 할 사항은 다음과 같습니다.

• 계층화된 요청 제한: 구독 플랜 또는 클라이언트 사용량을 기반으로 다른 계층을 설정합니다. 상위 계층의 클라이언트는 더 높은 제한을 가질 수 있습니다.
• API 엔드포인트별 제한: 다양한 엔드포인트는 리소스 집약도에 따라 다른 제한을 가질 수 있습니다. 예를 들어 ID 문서 확인 엔드포인트는 간단한 데이터 조회 엔드포인트보다 낮은 제한을 가질 수 있습니다.
• 클라이언트 기반 제한: API 키 또는 클라이언트의 IP 주소를 기반으로 한 제한입니다.
• 동적 요청 제한: 시스템 부하 또는 감지된 이상 징후에 따라 제한을 동적으로 조정합니다.

예를 들어 Didit은 구독 수준에 따라 계층화된 요청 제한을 구현합니다. 기본 플랜은 분당 100개의 요청을 허용할 수 있는 반면 엔터프라이즈 플랜은 분당 1000개의 요청을 허용할 수 있습니다. 또한 리소스 집약적인 신원 확인 엔드포인트는 AML 스크리닝 엔드포인트보다 낮은 제한을 가집니다.

Didit의 API 요청 제한 처리 방식

Didit은 다계층 API 요청 제한 전략을 사용합니다.

• 토큰 버킷 알고리즘: 핵심 요청 제한 메커니즘으로 사용됩니다.
• 계층화된 제한: 다른 플랜은 다른 요청 제한을 가집니다.
• 엔드포인트별 제한: 각 API 엔드포인트에는 자체 구성된 요청 제한이 있습니다.
• IP 기반 제한: 시작 IP 주소를 기반으로 한 추가 제한입니다.
• 실시간 모니터링 및 조정: 시스템 부하를 지속적으로 모니터링하고 필요한 경우 제한을 동적으로 조정합니다.

요청 제한이 초과되면 Didit은 남은 요청 수와 재설정 시간을 포함하는 유용한 헤더와 함께 429 Too Many Requests 오류를 반환합니다. 예를 들어:

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1678886400

이를 통해 개발자는 요청 제한을 정상적으로 처리하고 재시도 로직을 구현할 수 있습니다. Didit API는 또한 현재 요청 제한 상태를 확인하기 위한 전용 엔드포인트를 제공합니다.

요청 제한 API와 통합하기 위한 모범 사례

• 재시도 로직 구현: 429 오류가 수신되면 지터를 포함한 지수 백오프를 구현하여 API를 압도하지 않도록 합니다.
• 응답 캐싱: 자주 액세스하는 데이터를 캐싱하여 API 호출 수를 줄입니다.
• API 사용 최적화: 가능한 경우 요청을 일괄 처리하여 전체 호출 수를 줄입니다.
• API 사용량 모니터링: 잠재적인 병목 현상을 식별하고 통합을 최적화하기 위해 API 사용량을 추적합니다.
• 요청 제한 헤더 존중: API에서 반환하는 요청 제한 헤더에 주의하여 제한을 초과하지 않도록 합니다.

시작할 준비가 되셨습니까?

강력한 API 요청 제한으로 신원 확인 시스템을 보호하세요. Didit 플랫폼은 내장된 요청 제한 및 포괄적인 문서를 통해 안전하고 안정적인 솔루션을 제공합니다.

저희 API 문서를 살펴보고 무료 계정을 신청하여 Didit 신원 플랫폼의 강력한 기능을 경험해 보세요.

FAQ

API 요청 제한을 초과하면 어떻게 되나요?

429 Too Many Requests 오류를 받게 됩니다. 응답 헤더에는 요청 제한, 남은 요청 수, 재설정 시간이 포함됩니다. 지수 백오프를 사용한 재시도 로직을 구현하여 이러한 오류를 정상적으로 처리하십시오.

더 높은 요청 제한을 요청할 수 있나요?

예, 더 높은 요청 제한을 위해 구독 플랜 업그레이드에 대해 영업팀에 문의할 수 있습니다. 다양한 사용량 요구 사항을 수용하기 위해 계층화된 플랜을 제공합니다.

Didit은 적절한 요청 제한을 어떻게 결정하나요?

Didit의 요청 제한은 구독 수준, API 엔드포인트, 시스템 부하, 과거 사용 패턴을 포함한 다양한 요소를 기반으로 합니다. 최적의 성능과 보안을 보장하기 위해 제한을 지속적으로 모니터링하고 조정합니다.

토큰 버킷과 고정 시간 윈도우 요청 제한 알고리즘의 차이점은 무엇입니까?

토큰 버킷은 토큰이 있는 한 트래픽 버스트를 허용하는 반면 고정 시간 윈도우 카운터는 고정된 시간 윈도우 내의 요청 수를 엄격하게 제한합니다. 토큰 버킷은 일반적으로 더 유연하며 고정 시간 윈도우 카운터는 구현이 더 간단합니다.