kakasoo

[Meta] Application request limit reached 본문

도메인/마케팅

[Meta] Application request limit reached

카카수(kakasoo) 2024. 3. 25. 22:47
반응형

에러 상황

{
  "message": "Application request limit reached",
  "type": "OAuthException",
  "is_transient": true,
  "code": 4,
  "error_subcode": 1504022,
  "error_user_title": "API 요청이 너무 많음",
  "error_user_msg": "이 앱에서 너무 많이 호출했습니다. 잠시 기다린 후에 다시 시도해주세요. 자세한 정보는 다음을 참고하세요: https://developers.facebook.com/docs/marketing-api/insights/best-practices/#insightscallload",
  "fbtrace_id": "(생략)"
}
{
  "message": "Application request limit reached",
  "type": "OAuthException",
  "is_transient": false,
  "code": 4,
  "error_subcode": 1504039,
  "error_user_title": "API 요청이 너무 많음",
  "error_user_msg": "이 앱에서 너무 많은 요청이 있습니다. 잠시 후 다시 시도하세요.",
  "fbtrace_id": "AkCD9j6D_yidpK1HANz5VXb"
}

 

빈번한 요청으로 인해 에러가 난 상황이다.

요청 시간을 조정하는 수 밖에 없는데, 임의로 하기보다는 메타에서 제공해준 공식 문서 설명을 읽고 따라하는 것을 추천한다.

임의로 했다가는 아래의 에러를 만나게 될 것이다.

위 두 에러는 동일하지만 error_subcode와 error_user_msg가 약간 씩 다르다.

is_transient는 API가 과중되었음을 의미하는데, 이상하게도 두번째 에러에서는 false로 나온 것이 눈에 띈다.

안전하게 체크하기 위해서는 code를 이용하는 편이 좋겠다. ( code 4는 저 메시지와 완벽히 일치함을 보장한다. )

 

해결 방법

 

Rate Limiting - 마케팅 API - 문서 - Meta for Developers

Ad Account Level API-Level Limits Rate limiting is at the ad account level. Rate limits happen in real time on a given time range. Each Marketing API call is assigned a score. Your score is the sum of your API calls. We enforce a maximum score. Generally s

developers.facebook.com

 

 

[Meta] Service temporaily unavailable

에러 상황 { "message": "Service temporarily unavailable", "type": "OAuthException", "is_transient": false, "code": 2, "error_subcode": 1504018, "error_user_title": "요청 시간이 초과되었습니다", "error_user_msg": "기간을 줄이거나 더

kscodebase.tistory.com

 

첫번째 페이지는 메타의 공식문서이고, 두번째 페이지는 connection timeout을 조정하게 될 때 마주하게 될 새로운 에러이다.

임의로 개선하려고 하지말고 반드시 공식문서를 참고하여 수정하는 것이 좋겠다.

메타의 경우는 application을 발급받아야 메타의 각종 API를 사용할 수 있게 되는데, 이 API에 대한 limit이 문서화되어 있다.

limit은 단순히 초 당 사용 가능한 API call 수로 표현되는 것이 아니라, 유저의 수에 따른 비례식으로 표현되어 있다.

예상되는 서비스 규모에 따라 사용할 수 있는 API call이 다를 테니 임의로 조정하는 것은 거의 불가능에 가깝다.

차라리 매번 call을 하여 돌아오는 응답 값의 header를 캐시해둔 다음, 그 header에서 과열된 비율과 응답 대기 시간으로 제어하자.

Redis의 싱글 스레드의 특성을 사용한다던가 DB의 Lock 기능을 사용하여 로드 밸런싱된 서버끼리 이를 공유하는 것이 좋겠다.

반응형