API 트래픽 관리
Apigee Webinar “Is your API naked? 10 API Roadmap Considerations” 시리즈 중 두번째입니다.
API 트래픽관리라고 하는 것에 대한 구체적 사례들을 보여주고 있습니다.
기존 웹프로그램이나 서버프로그램 관리포인트와 유사하지만, request별로 rate limiting과 quota를 중심으로 제어한다는 것이 크게 다릅니다.
번역하다보니 더 세세한 사례는 개인 경험을 바탕으로 다루어보고 싶은 욕심이 생기네요.
이 시리즈는 16개의 타이틀로 구성되어 있습니다. 하나 둘씩 살펴보면서 한글로 옮겨담고 있습니다만,아직까지는 다 번역할 필요가 있을까 싶습니다.
발번역에 대한 지적을 해주시면 감사히 정정토록 하겠습니다.
원문 : Don’t have a meltdown: API Traffic Management
(API 트래픽을 관리하라.)
고객들은 우리보다 훨씬 더 좋은 메시지들을 찾아낸다.
어떤 이가 우리에게 “백엔드 붕괴”(back-end melt down)로부터 보호해 줄 수 있는지를 물었었다.
그들은 대외고객을 위해 한 개의 API를 열었었다. 그러나, 그 API는 웹앱에서 사용하던 것과 같은 것이었고, 앱 트래픽이 급증하자 웹이 달아오르기 시작했다. – 좋지 않은 방식으로.
백엔드 붕괴(back-end melt down)는 곧 전단의 붕괴(front-end melt down)로 이어질 것이다. 그것은 비즈니스에 중요한 위험요소이다.
그래서, 트래픽 관리는 일반적으로 오픈 API에 추가되어지는 첫번째 관리요소중의 하나이다.
그러나, 여기에는 기술적 이유와 사업적 이유가 있다.
기술자들은 규칙적인 트래픽 흐름을 만들기 위해 트래픽을 통제(throttling)하거나, 사용량에 대한 한계(rate-limiting)를 부여하고 싶어한다.
고객 개발자들은 우연히 비효율적인 코드를 만들 수도 있다. 어떤 이는 API를 통해 당신의 모든 데이터를 다운로드할려고 할지도 모른다. 가끔 당신은 비정상적 사용사례를 만나게 될 것이다.
사용한계를 부여하거나 트랜잭션을 통제(초당 몇 건)하는 것은 당신의 앱을 보호해주고, 당신의 웹과 API 고객들을 행복하게 해주기 위한 차단기 역할을 한다.
사업관리자들은 일일쿼타에 대한 소모량을 측정할 필요가 있다.
이것은 더 많은 양을 보장하는 요금으로 업그레이드해야 할 고객들을 미리 알아내는 일일 수도 있고, 고객의 데이터 사용량을 기록하는 일일 수도 있다.(특히 당신이 그 데이터에 대해 요금을 부과한다면) 아니면, 자신들에게 맞는 다른 형태의 최적화된 “서비스 계층”을 만들고 싶어할 수도 있다.
(사용량과 쿼타 통제로 예방가능한 위험들)
우리는 사용한계 설정을 위해 쿼타로 대체하는 몇 몇의 API 공급자들을 알고 있다. – 개발자들에게 하루에 몇 건씩만 사용할 수 있다고 말하는 것과 같다.
그러나, 단순히 일일 쿼타를 재는 것은 “백엔드를 노출된 채” 방치하는 것일 수 있다.
그리고, “초당” 사용한계는 ‘비즈니스 레벨 소비 계층’들을 만들기 위한(create tiers of business-level consumption) 훌륭한 방법은 아니다.
당신은 둘 다 필요할 수 있다.
또, 우리는 서류상으로만 SLA를 정의한 후 “만일 더 필요하면, 전화하세요.”라고 말하는 고객을 알고 있다.
우리는 이 방식을 시작한 SaaS고객들을 가지고 있다.
그런데, 그들은 중요한 고객들에게 ‘스스로 API 사용량을 관리할 필요가 있다.’고 말하기가 어렵다는 것을 알게 되었다.
그래서, 그들은 결국 트래픽 관리를 논의하기 위한 좋은 방법을 찾아내었다.
- 첫째로 고객들에게 사용량보고서를 제공한다.
(월요일 아침 9시에 당신이 얼마나 많은 request를 보냈는지 보세요. 우리는 당신을 사랑합니다. 하지만, 우리를 좀 도와주실 있나요?)
당신은 모든 request가 같다고 여기지 않을 수 있다.
- 어떤 request 는 많은 하위 트랜잭션들을 포함할 수도 있고, 큰 메시지를 포함할 수도 있다. 그래서 단순히 “초당 몇건”으로 한계를 제어하는 것은 충분하지 않다.
그래서, Open API 로드맵을 위해 아래의 질문들을 생각해보라.
(어떤 종류의 rate limiting을 필요로 하는가?)
당신은 개발자, 앱, 또는 고객조직별로 rate limit할 필요가 있는가?
특정한 고객 (key 값이나, ip address)에 대해 통제할 수 있는가?
모든 메시지는 동일한가, 아니면 메시지 크기나 메시지별 레코드에 기반해서 조절할 필요가 있는가?
당신은 어떻게 웹이나 사내 앱과 API 트래픽에 대해 다르게 통제할 것인가?
(당신의 사업은 API 사용량에 대한 쿼타를 필요로 하는가?)
당신은 사업상 소비량을 측정하기 위해 일별, 월별 사용량을 기록할 필요가 있는가?
당신은 다른 서비스 계층에 대해 다른 소비(사용정도) 레벨을 정의할 필요가 있는가?
어떤 사람이 쿼타를 넘어간다면, 무엇이 가장 좋은 사업적 의지인가? 그들에게 전화를 걸어 돈을 더 내라고 할 것인가? 아니면, 그것을 차단할 것인가?
당신이 데이터에 대해 돈을 내고 있다면, 당신은 요금이나 과금을 위해 측정을 하고 있는가?
(어떻게 트래픽을 모니터링하고 관리할 것인가?)
어떤 사람이 설정된 한계나 쿼타를 넘어갔다면, 당신은 어떻게 그것을 알게되나?
쿼타나 설정한계의 요금초과가 증가추세인가, 일회성인가?
유연한 행동들을 정의할 수 있나? (예를 들면 drop requests, do nothing, send an alert?)
당신은 고객들에게 데이터를 제공할 수 있나, 그래서 그들이 자신을 측정하는데 도움을 줄 수 있나?
김수보, Dream Realizer, in IT
