API 트래픽 조절이란 무엇입니까?
API 트래픽 조절은 사용자가 특정 기간에 만들 수 있는 API 요청 수를 제한하는 프로세스입니다. API(애플리케이션 프로그래밍 인터페이스)는 사용자와 소프트웨어 애플리케이션 간의 게이트웨이 역할을 합니다. 예를 들어, 사용자가 소셜 미디어에서 게시 버튼을 클릭하면 버튼 클릭이 API 호출을 트리거합니다. 이 API는 소셜 미디어 애플리케이션의 웹 서버와 상호 작용하여 게시 작업을 수행합니다. 상기 사용자는 인간이거나 다른 소프트웨어 애플리케이션일 수 있습니다.
조직은 보안, 확장성, 성과, 수익 창출, 인증 및 가용성과 같은 다양한 목표로 API 트래픽 조절을 사용합니다.
비즈니스에서 API 트래픽 조절의 실제 예시
어떤 사람이 OTA(온라인 여행사) 사이트를 통해 항공편을 검색한다고 가정하겠습니다. OTA 웹사이트는 사용자로부터 출발지, 목적지, 여행 날짜 등의 정보를 수집합니다. 그런 다음 API를 사용하여 Saber 또는 Amadeus와 같은 GDS(전세계 유통 시스템)에서 비행 정보를 가져옵니다.
기업에 API 트래픽 조절이 필요한 이유는 무엇입니까?
API는 조직의 가장 큰 자산 중 하나입니다. API는 웹사이트 또는 모바일 앱의 사용자가 작업을 수행하는 데 도움이 됩니다. 사용자 수가 증가함에 따라 웹 사이트 또는 모바일 앱에서 성능 저하의 징후가 나타나기 시작합니다. 결과적으로 더 나은 연결 또는 더 빠른 인터페이스를 가진 사용자는 다른 사용자보다 더 나은 경험을 얻을 수 있습니다. API 트래픽 조절은 조직이 API의 공정한 사용을 보장하는 데 도움이 되는 정교한 솔루션입니다.
API 트래픽 조절은 또한 악의적인 사용자가 웹사이트나 모바일 앱을 중단시키기 위해 엄청난 양의 요청을 보내는 서비스 거부(DoS) 공격에 맞서는 데 도움이 됩니다. 온라인 사용자 수가 증가함에 따라 기업은 API 트래픽 조절 메커니즘을 구현하여 공정한 사용, 데이터 보안을 보장하고 악의적인 공격을 방지해야 합니다.
API 트래픽 조절은 어떻게 작동합니까?
API 트래픽 조절을 위한 다양한 알고리즘이 있지만 모든 API 트래픽 조절 알고리즘의 기본 단계는 다음과 같습니다.
- 클라이언트/사용자는 웹 서비스 또는 애플리케이션과 인터페이스로 접촉하는 API를 호출합니다.
- API 트래픽 조절 로직에서는 현재 요청이 허용된 API 호출 수를 초과하는지 확인합니다.
- 요청이 제한 내에 있는 경우 API는 평소와 같이 수행하고 사용자의 작업을 완료합니다.
- 요청이 제한을 초과하면 API가 사용자에게 오류 응답을 반환합니다.
- 사용자는 사전에 동의한 기간 동안 기다리거나 추가 API 호출을 위해 비용을 지불해야 합니다.
주요 API 트래픽 조절 알고리즘이란 무엇입니까?
리키 버킷 API 트래픽 조절 알고리즘
이 알고리즘은 FIFO(선입 선출) 대기열을 사용하여 들어오는 요청을 보유합니다. 대기열은 크기가 지정되어 있습니다. 새로운 API 호출/요청이 수신되면 대기열 끝에 추가됩니다. 일정한 간격으로 이 알고리즘은 대기열의 앞쪽에서 요청을 제거하고 처리합니다. 대기열이 이미 가득 차있는 경우 새 요청이 들어오면 삭제됩니다. 이 알고리즘은 토큰 버킷 알고리즘과 밀접한 관련이 있습니다.
리키 버킷의 장점
- 구현하기 쉬움
- 일정한 속도로 요청을 처리합니다. 요청이 급증하더라도 시스템에 과부하가 걸리지 않습니다. 이런 방식으로 리키 버킷 알고리즘은 불안한 입력 흐름이 있을 때 출력 흐름을 원활하게 합니다.
리키 버킷의 단점
- 리키 버킷 알고리즘은 FIFO 대기열을 사용하므로 기아 상태가 될 가능성이 있습니다. 즉, 대기열이 가득 차고 요청을 처리하는 데 시간이 더 오래 걸리면 새로운 요청이 삭제될 수 있습니다. 이 문제는 요청이 처리되는 순서로 인해 발생합니다.
고정 기간 API 트래픽 조절 알고리즘
고정 기간은 특정 기간에 사용자로부터 N개의 API 호출을 허용합니다. 예를 들어, 어떤 고정 기간 알고리즘은 분당 두 개의 요청을 허용합니다. 시간 프레임은 고정된 프레임으로 나뉘며 각각의 시간은 1분입니다. 1분이 시작되면 카운터는 0으로 설정됩니다. 사용자가 요청할 때마다 카운터가 증가합니다. 시간 창이 끝나기 전에 카운터가 상한에 도달하면 새 요청이 거부됩니다. 다시 1분이 시작될 때 카운터는 0으로 재설정됩니다.
고정 기간 알고리즘의 일반적인 구현에서 각 사용자는 고유한 키 및 해당 키와 연결된 카운터를 갖게 됩니다. 고정 기간 시작 시 카운터가 재설정됩니다.
고정 기간의 장점
- 리키 버킷 알고리즘과 달리 고정 기간 알고리즘은 모든 시간 창이 시작될 때 카운터가 재설정되므로 새 요청의 기아 상태로 이어지지 않습니다.
고정 기간의 단점
- 기간이 시작될 때 사용자 요청이 급증할 수 수 있습니다. 예를 들어, 1000개 요청/시간 제한이 있는 경우 창의 첫 번째 1분에 모든 1000개 요청이 수행될 수 있습니다. 이것은 시스템에 과부하를 줄 수 있습니다.
슬라이딩 윈도우 API 트래픽 조절 알고리즘
이 알고리즘은 요청이 있을 때 시간 창을 시작하여 고정 기간 알고리즘의 요청 급증 문제를 해결합니다. 예를 들어, 시스템은 사용자에 대해 분당 두 개의 요청만 허용한다고 가정합니다. 고정 기간과 달리 사용자가 실제로 첫 번째 요청을 했을 때만 시간 창이 시작됩니다. 첫 번째 요청의 타임스탬프는 카운터와 함께 저장되며 사용자는 그 분 안에 한 번 더 요청할 수 있습니다.
슬라이딩 윈도우 알고리즘의 장점
슬라이딩 윈도우 알고리즘은 리키 버킷과 고정 기간 알고리즘의 장점을 결합합니다. 그리하여 두 알고리즘 상의 문제를 제거합니다. 슬라이딩 윈도우에서 새로운 요청은 기아 상태가 되지 않습니다. 고정 기간과 달리 요청 급증으로 시스템이 과부하를 받지 않습니다.
API 트래픽 조절의 이점은 무엇입니까?
API 트래픽 조절은 API를 통해 서비스를 받는 모든 조직에 필수적인 기술입니다.
성능
API 트래픽 조절은 API의 초과 사용을 제한하여 시스템 성능 저하를 방지합니다. 애플리케이션에 수백만 명의 사용자가 있는 경우, 시스템은 초당 엄청난 수의 API 요청을 받을 수 있습니다. 이러한 모든 API 요청을 처리하려면 시스템 속도가 느려지고 성능에 영향을 미치게 됩니다. API 트래픽 조절은 모든 사용자가 SLA(서비스 수준 계약)에서 보장하는 성능을 받을 수 있도록 합니다.
보안
API 트래픽 조절 시스템은 API에 대한 게이트웨이 역할을 합니다. 이 시스템은 DoS(서비스 거부) 공격을 방지하는 데 도움이 됩니다. DoS에서 공격자는 합법적인 사용자가 서비스를 사용할 수 없도록 대량의 서비스 요청을 발행합니다. API 트래픽 조절은 총 서비스 요청 수를 제한함으로써 DoS 공격을 방지하는 데 도움이 됩니다.
의도하지 않은/악의적 사용 제거
API가 기술적 결함으로 인해 민감한 정보를 공개하는 경우 API 트래픽 조절은 사용자가 손상된 API를 통해 데이터에 무단으로 액세스하는 것을 제한합니다.
측정 및 수익화
API는 조직의 가장 큰 자산 중 하나입니다. API 사용을 수익화하면 수익에 상당한 기여를 합니다. API 트래픽 조절은 조직이 API 사용량을 측정하는 데 도움이 됩니다. 예를 들어, 웹 서비스는 시간당 1,000개의 무료 API 호출을 제공할 수 있지만 사용자가 시간당 더 많은 요청이 필요한 경우 비용을 지불해야 합니다.
인증
API 트래픽 조절이 반드시 호출 수만 제한하는 것은 아닙니다. 사용자의 액세스 권한에 따라 API 트래픽 조절 로직은 API의 선택된 부분에 대한 사용자의 액세스를 허용합니다. 예를 들어, 요청자의 권한에 따라 일부 사용자는 다른 사용자를 조회할 수 있고 다른 사용자는 API를 통해 사용자의 세부 정보를 수정할 수 있습니다.
API 트래픽 조절의 문제점은 무엇입니까?
분산 시스템에서는 API 트래픽 조절을 구현하기가 어렵습니다. 앱 또는 서비스에 전 세계적으로 널려 있는 여러 서버가 있는 경우, 분산 시스템에 트래픽 조절을 적용해야 합니다. 동일한 사용자의 연속적인 요청은 다른 서버로 전달될 수 있습니다. API 트래픽 조절 로직은 각 노드에 상주하며 실시간으로 서로 동기화해야 합니다. 불일치 및 경쟁 조건이 발생할 수 있습니다.
아래 예에서 사용자는 초당 5개 요청 중 4개 요청을 이미 사용했습니다. 사용자가 동시에 두 번 더 요청을 실행한다고 가정해 보겠습니다. 그들은 두 개의 다른 서버로 이동합니다. 속도 제한기는 데이터베이스에서 현재 카운터를 검색하고 count=4를 확인하고 호출을 허용합니다. 동시에 두 번째 속도 제한기는 데이터베이스에서 데이터를 가져오고 count=4를 확인합니다. 이는 첫 번째 속도 제한기가 개수를 업데이트하기 전에 두 번째 속도 제한기가 공통 데이터베이스에서 데이터를 가져오기 때문에 발생합니다. 따라서 두 요청이 모두 처리되고 사용자는 초당 6개의 요청을 받습니다.
솔루션: API 트래픽 조절 시스템은 불일치 및 경쟁 조건에 대해 여러 솔루션을 사용합니다. 분산 시스템에서 API 트래픽 조절을 구현하는 한 가지 방법은 고정 세션을 사용하는 것입니다. 이 방법에서 사용자의 모든 요청은 항상 특정 서버에서 처리됩니다. 그러나 이 솔루션은 균형이 잘 잡혀 있지 않거나 결함 감내 기능이 없습니다.
분산 시스템에서 API 트래픽 조절에 대한 두 번째 솔루션은 잠금입니다. 위의 예에서 첫 번째 속도 제한기는 데이터베이스에 액세스할 때 카운트를 잠급니다. 카운트를 잠금 해제할 때까지 두 번째 속도 제한기는 카운트에 액세스할 수 없습니다. 카운터가 5로 업데이트되면 첫 번째 속도 제한기가 카운트를 잠금 해제합니다. 또 다른 인기 있는 솔루션은 속도 제한을 완화하는 것입니다. 이 솔루션은 초당 특정 비율의 추가 요청을 허용합니다.