IT의 중심에서

IT산업에 대한 가슴아픈 고찰

API 트래픽 관리

Apigee Webinar, “Is your API naked? 10 API Roadmap Considerations” 시리즈 중 두번째입니다. 이 시리즈는 16개의 타이틀로 구성되어 있습니다.

API를 오픈하면서 많은 업체들이 걱정하는 것이 하나 있습니다.
바로, 웹서버가 죽지 않을까 하는 것인데요.
API를 그냥 오픈하면 과도한 호출로 인해 서버가 뻗는 경우가 왕왕 있습니다.
물론, 서비스 인기가 높은 경우라면 증설은 즐거운 일이겠지만, 저쪽 개발자가 잘못 개발했다거나 악의적 목적을 가지고 있는 경우라면 여간 괴로운 일이 아닙니다.

Apigee는 이를 위해서, ‘일일 사용량’과 ‘초당처리건수’를 제한하라고 조언하고 있습니다.
또한, 유료 API서비스라면 고객에게 사용량을 리포팅하는 것이 중요하다는 것을 이야기하고 있습니다.


Cairo

※ 원문 : Don’t have a meltdown: API Traffic Management

고객들은 종종 우리보다 훨씬 더 좋은 문구를 사용한다.
누군가 우리에게 “백엔드 서버 붕괴”(back-end melt down)로부터 보호해 줄 수 있는지를 물었다.

그들은 최근 외부 고객을 위해 API 하나를 오픈했다.
그러나, 그 API는 웹앱에서 사용하던 것이었고 앱 트래픽이 급증하자 웹이 버벅대기 시작했다.

백엔드 서버 붕괴(back-end melt down)는 곧 전단 서버의 붕괴(front-end melt down)로 이어진다.
서버붕괴는 비즈니스에 중요한 위험요소이다.

그래서, 트래픽 관리는 일반적으로 Open API에 추가해야 하는 첫번째 관리요소이다.

여기에는 기술적 이유와 사업적 이유가 있다.

기술자들은 규칙적인 트래픽 흐름을 만들기 위해 트래픽을 통제(throttling)하거나, 속도를 제한(rate-limiting)하고 싶어한다.
고객 개발자들이 우연히 비효율적인 코드를 만들 수도 있다. 어떤이는 API를 통해 당신의 모든 데이터를 다운로드하려고 할 수도 있다. 비정상적 사례를 만날 수도 있다.
속도제한이나 트랜잭션 통제는 앱을 보호하고, 웹과 API 고객들을 모두 만족시키는 차단기 역할을 한다.

사업관리자들은 일일 사용량을 측정할 필요가 있다.
더 많은 용량의 요금으로 업그레이드할 고객들을 미리 알아낼 수도 있다.
사후요금 부과를 위해 고객 데이터 사용량을 기록할 수도 있다.
사업담당자들이 다른 형태의 “최적 서비스 레이어”를 만들고 싶어할 수도 있다.

속도제한과 사용량 통제로 회피가능한 위험들

우리는 몇 API Provider들이 속도를 제한하기 위해 사용량으로 대체하는 것을 알고 있다.
쉽게 말하면 개발자들에게 하루에 몇 건씩만 사용 가능한 것이다.

그러나, 이렇게 일일 사용량만을 재는 것은 “백엔드를 공격에 노출된 채” 방치하는 것이다. 짧은 과부하에 서버는 뻗어버린다.

그러나, ‘초당 사용한계’는 새로운 ‘비즈니스 소비 계층’을 만드는데는 그다지 좋지 않다.

둘 다 필요하다.

많은 고객들이 서류상으로만 SLA를 만들고 “만일 더 필요하면, 전화하세요.”라고 이야기한다.
우리에게는 이런 식으로 시작한 SaaS 고객이 있다. 그런데, 그들은 중요한 고객들에게 ‘스스로 API 사용량을 관리하세요.’라고 말하기가 어렵다는 것을 알게 되었다.
(※주: Apigee는 API 공급자와 소비자를 중개시켜주는 비즈니스를 하고 있습니다.)

그들은 사용량 보고서를 제공하면서 자연스럽게 트래픽 관리에 관심을 가지게끔 만들었다.
‘월요일 아침 9시에 당신이 얼마나 많은 request를 보냈는지 보세요. 우리는 당신을 사랑합니다. 하지만, 우리를 좀 도와주세요.’

모든 request는 같지 않다.
어떤 request 는 많은 하위 트랜잭션들을 포함할 수도 있고, 큰 메시지를 포함할 수도 있다.
그래서 단순히 “초당 몇건”으로 한계를 제어하는 것은 충분하지 않다.

Open API를 제공하기 위해서는 사전에 아래 사항들을 고려해야 한다.

1) 어떻게 속도제한을 할 것인가?

  • 개발자, 앱, 또는 고객조직별로 속도를 제한할 필요가 있는가?
  • 특정한 고객 (key 값이나, ip address)에 대해 통제할 수 있는가?
  • 모든 메시지는 동일한가, 아니면 메시지 크기나 메시지별 레코드에 기반해서 조절할 필요가 있는가?
  • 당신은 어떻게 웹이나 사내 앱과 API 트래픽에 대해 다르게 통제할 것인가?
  • 2) 사업상 API 사용량을 제한할 필요가 있는가?

  • 사업상 소비량을 측정하기 위해 일별, 월별 사용량을 기록할 필요가 있는가?
  • 다른 서비스 계층에 대해 다른 소비(사용정도) 레벨을 정의할 필요가 있는가?
  • 어떤 사람이 사용량을 넘긴다면, 사업적으로 어떤 것이 좋을까? 전화를 걸어 돈을 더 내라고 할 것인가? 아니면, 그것을 차단할 것인가?
  • 당신이 데이터에 대해 돈을 내고 있다면, 요금이나 과금을 위해 측정하고 있는가?
  • 3) 어떻게 트래픽을 모니터링하고 관리할 것인가?

  • 누가 속도한계나 사용량을 넘긴다면, 어떻게 그것을 알 수 있을 것인가?
  • 사용량과 속도한계 초과에 따른 요금초과가 증가추세인가, 아니면 일회성인가?
  • 유연하게 대응할 수 있나? (예를 들면 requests를 차단하던가, 그냥 두던가, 알림을 보내는 등?)
  • 고객들에게 결과를 제공해서 스스로 사용량을 측정하게 할 수 있나?
  • About these ads

    댓글 남기기

    아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

    WordPress.com 로고

    WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    Twitter 사진

    Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    Facebook 사진

    Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    Google+ photo

    Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

    %s에 연결하는 중

    정보

    이 엔트리는 2012년 2월 26일에 님이 번역글, 기술이야기에 게시하였으며 , 태그가 지정되었습니다.

    내비게이션

    팔로우

    모든 새 글을 수신함으로 전달 받으세요.

    다른 155명의 팔로워와 함께 하세요

    %d bloggers like this: