[jira] [Commented] (KAFKA-656) Add Quotas to Kafka

["Abhinav Anand (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KAFKA-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094573#comment-14094573 ] 

Abhinav Anand commented on KAFKA-656:
-------------------------------------

H [~jkreps] [~jcreasy],
 Guys don't see much activity on this thread. We are looking into solving this problem in our company and trying to figure out ways to do it best.  I looked into the suggestions proposed in this thread and I believe maintaining a state about observed rate of flow on each broker makes a very clear case. 
  Are we only looking into solving this from the broker side by throwing quota exceeded exception?? Because in this scenario, we have no control over the producers and they can keep on sending the data to the Kafka brokers and bombard the network even after getting the quota exceeded warning and exceptions. 
 We have few ideas on lease based service, where the producer requests for the lease and only sends data within the allotted quota. To send higher traffic, he would be required to renew his lease with the new bandwidth request ( we are trying to achieve this through a watcher node in zookeeper). Though this solution has issues, when a rogue producer sends messages to the system. We are in the design phase of our solution and it would be great to get inputs from you guys. It would be great if we can design something we can contribute back. 

Regards, 
Abhinav

> Add Quotas to Kafka
> -------------------
>
>                 Key: KAFKA-656
>                 URL: https://issues.apache.org/jira/browse/KAFKA-656
>             Project: Kafka
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 0.8.1
>            Reporter: Jay Kreps
>              Labels: project
>
> It would be nice to implement a quota system in Kafka to improve our support for highly multi-tenant usage. The goal of this system would be to prevent one naughty user from accidently overloading the whole cluster.
> There are several quantities we would want to track:
> 1. Requests pers second
> 2. Bytes written per second
> 3. Bytes read per second
> There are two reasonable groupings we would want to aggregate and enforce these thresholds at:
> 1. Topic level
> 2. Client level (e.g. by client id from the request)
> When a request hits one of these limits we will simply reject it with a QUOTA_EXCEEDED exception.
> To avoid suddenly breaking things without warning, we should ideally support two thresholds: a soft threshold at which we produce some kind of warning and a hard threshold at which we give the error. The soft threshold could just be defined as 80% (or whatever) of the hard threshold.
> There are nuances to getting this right. If you measure second-by-second a single burst may exceed the threshold, so we need a sustained measurement over a period of time.
> Likewise when do we stop giving this error? To make this work right we likely need to charge against the quota for request *attempts* not just successful requests. Otherwise a client that is overloading the server will just flap on and off--i.e. we would disable them for a period of time but when we re-enabled them they would likely still be abusing us.
> It would be good to a wiki design on how this would all work as a starting point for discussion.



--
This message was sent by Atlassian JIRA
(v6.2#6252)