<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 22, 2014 at 8:13 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Joe Gordon's message of 2014-09-22 19:04:03 -0700:<br>
<div><div class="h5">> On Mon, Sep 22, 2014 at 5:47 PM, Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br>
><br>
> > On 22/09/14 17:06, Joe Gordon wrote:<br>
> ><br>
> >> On Mon, Sep 22, 2014 at 9:58 AM, Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> wrote:<br>
> >><br>
> >>  On 22/09/14 10:11, Gordon Sim wrote:<br>
> >>><br>
> >>>  On 09/19/2014 09:13 PM, Zane Bitter wrote:<br>
> >>>><br>
> >>>>  SQS offers very, very limited guarantees, and it's clear that the<br>
> >>>>> reason<br>
> >>>>> for that is to make it massively, massively scalable in the way that<br>
> >>>>> e.g. S3 is scalable while also remaining comparably durable (S3 is<br>
> >>>>> supposedly designed for 11 nines, BTW).<br>
> >>>>><br>
> >>>>> Zaqar, meanwhile, seems to be promising the world in terms of<br>
> >>>>> guarantees. (And then taking it away in the fine print, where it says<br>
> >>>>> that the operator can disregard many of them, potentially without the<br>
> >>>>> user's knowledge.)<br>
> >>>>><br>
> >>>>> On the other hand, IIUC Zaqar does in fact have a sharding feature<br>
> >>>>> ("Pools") which is its answer to the massive scaling question.<br>
> >>>>><br>
> >>>>><br>
> >>>> There are different dimensions to the scaling problem.<br>
> >>>><br>
> >>>><br>
> >>> Many thanks for this analysis, Gordon. This is really helpful stuff.<br>
> >>><br>
> >>>   As I understand it, pools don't help scaling a given queue since all<br>
> >>> the<br>
> >>><br>
> >>>> messages for that queue must be in the same pool. At present traffic<br>
> >>>> through different Zaqar queues are essentially entirely orthogonal<br>
> >>>> streams. Pooling can help scale the number of such orthogonal streams,<br>
> >>>> but to be honest, that's the easier part of the problem.<br>
> >>>><br>
> >>>><br>
> >>> But I think it's also the important part of the problem. When I talk<br>
> >>> about<br>
> >>> scaling, I mean 1 million clients sending 10 messages per second each,<br>
> >>> not<br>
> >>> 10 clients sending 1 million messages per second each.<br>
> >>><br>
> >>> When a user gets to the point that individual queues have massive<br>
> >>> throughput, it's unlikely that a one-size-fits-all cloud offering like<br>
> >>> Zaqar or SQS is _ever_ going to meet their needs. Those users will want<br>
> >>> to<br>
> >>> spin up and configure their own messaging systems on Nova servers, and at<br>
> >>> that kind of size they'll be able to afford to. (In fact, they may not be<br>
> >>> able to afford _not_ to, assuming per-message-based pricing.)<br>
> >>><br>
> >>><br>
> >> Running a message queue that has a high guarantee of not loosing a message<br>
> >> is hard and SQS promises exactly that, it *will* deliver your message. If<br>
> >> a<br>
> >> use case can handle occasionally dropping messages then running your own<br>
> >> MQ<br>
> >> makes more sense.<br>
> >><br>
> >> SQS is designed to handle massive queues as well, while I haven't found<br>
> >> any<br>
> >> examples of queues that have 1 million messages/second being sent or<br>
> >> received  30k to 100k messages/second is not unheard of [0][1][2].<br>
> >><br>
> >> [0] <a href="https://www.youtube.com/watch?v=zwLC5xmCZUs#t=22m53s" target="_blank">https://www.youtube.com/watch?v=zwLC5xmCZUs#t=22m53s</a><br>
> >> [1] <a href="http://java.dzone.com/articles/benchmarking-sqs" target="_blank">http://java.dzone.com/articles/benchmarking-sqs</a><br>
> >> [2]<br>
> >> <a href="http://www.slideshare.net/AmazonWebServices/massive-" target="_blank">http://www.slideshare.net/AmazonWebServices/massive-</a><br>
> >> message-processing-with-amazon-sqs-and-amazon-<br>
> >> dynamodb-arc301-aws-reinvent-2013-28431182<br>
> >><br>
> ><br>
> > Thanks for digging those up, that's really helpful input. I think number<br>
> > [1] kind of summed up part of what I'm arguing here though:<br>
> ><br>
> > "But once your requirements get above 35k messages per second, chances are<br>
> > you need custom solutions anyway; not to mention that while SQS is cheap,<br>
> > it may become expensive with such loads."<br>
><br>
><br>
> If you don't require the reliability guarantees that SQS provides then<br>
> perhaps. But I would be surprised to hear that a user can set up something<br>
> with this level of uptime for less:<br>
><br>
> "Amazon SQS runs within Amazon’s high-availability data centers, so queues<br>
> will be available whenever applications need them. To prevent messages from<br>
> being lost or becoming unavailable, all messages are stored redundantly<br>
> across multiple servers and data centers." [1]<br>
><br>
<br>
</div></div>This is pretty easily doable with gearman or even just using Redis<br>
directly. But it is still ops for end users. The AWS users I've talked to<br>
who use SQS do so because they like that they can use RDS, SQS, and ELB,<br>
and have only one type of thing to operate: their app.<br>
<div><div class="h5"><br>
> ><br>
> ><br>
> >    There is also the possibility of using the sharding capabilities of the<br>
> >>><br>
> >>>> underlying storage. But the pattern of use will determine how effective<br>
> >>>> that can be.<br>
> >>>><br>
> >>>> So for example, on the ordering question, if order is defined by a<br>
> >>>> single sequence number held in the database and atomically incremented<br>
> >>>> for every message published, that is not likely to be something where<br>
> >>>> the databases sharding is going to help in scaling the number of<br>
> >>>> concurrent publications.<br>
> >>>><br>
> >>>> Though sharding would allow scaling the total number messages on the<br>
> >>>> queue (by distributing them over multiple shards), the total ordering of<br>
> >>>> those messages reduces it's effectiveness in scaling the number of<br>
> >>>> concurrent getters (e.g. the concurrent subscribers in pub-sub) since<br>
> >>>> they will all be getting the messages in exactly the same order.<br>
> >>>><br>
> >>>> Strict ordering impacts the competing consumers case also (and is in my<br>
> >>>> opinion of limited value as a guarantee anyway). At any given time, the<br>
> >>>> head of the queue is in one shard, and all concurrent claim requests<br>
> >>>> will contend for messages in that same shard. Though the unsuccessful<br>
> >>>> claimants may then move to another shard as the head moves, they will<br>
> >>>> all again try to access the messages in the same order.<br>
> >>>><br>
> >>>> So if Zaqar's goal is to scale the number of orthogonal queues, and the<br>
> >>>> number of messages held at any time within these, the pooling facility<br>
> >>>> and any sharding capability in the underlying store for a pool would<br>
> >>>> likely be effective even with the strict ordering guarantee.<br>
> >>>><br>
> >>>><br>
> >>> IMHO this is (or should be) the goal - support enormous numbers of<br>
> >>> small-to-moderate sized queues.<br>
> >>><br>
> >><br>
> >><br>
> >> If 50,000 messages per second doesn't count as small-to-moderate then<br>
> >> Zaqar<br>
> >> does not fulfill a major SQS use case.<br>
> >><br>
> ><br>
> > It's not a drop-in replacement, but as I mentioned you can recreate the<br>
> > SQS semantics exactly *and* get the scalability benefits of that approach<br>
> > by sharding at the application level and then round-robin polling.<br>
><br>
> > As I also mentioned, this is pretty easy to implement, and is only<br>
> > required for really big applications that are more likely to be written by<br>
> > developers who already Know What They're Doing(TM). While the reverse<br>
> > (emulating Zaqar semantics, i.e. FIFO, in SQS) is tricky, error-prone, and<br>
> > conceivably required by or at least desirable for all kinds of<br>
> > beginner-level applications. (It's also pretty useful for a lot of use<br>
> > cases in OpenStack itself, where OpenStack services are sending messages to<br>
> > the user.)<br>
><br>
><br>
><br>
> I'm not convinced that is as simple to implement well as you make it out to<br>
> be, now every receiver has to poll N endpoints instead of 1. How would this<br>
> work with Long Polling? What is the impact on expanding the number of<br>
> connections? How do you make this auto scale? etc.<br>
><br>
<br>
</div></div>It's pretty easy to setup a select loop on multiple HTTP requests. I<br>
don't think this complicates things. Also once you assume responsibility<br>
for the service that does the queueing, you're also more likely to<br>
accept a binary protocol rather than rely on long poll / REST semantics.<br></blockquote><div><br></div><div>Agreed, once the user takes on the responsibility of running the service the the equation changes.  I was referring to the case where someone consumes Zaqar as is.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Number of connections I don't understand given the situation above. One<br>
per client per availability-zone covered?<br>
<br>
Auto-scaling is a bit beyond the scope of the discussion. Nobody is<br>
promising that Zaqar will auto-scale itself.<br></blockquote><div><br></div><div>I was referring to how to know when to create a new queue, how to distribute that information, and when to remove that queue because your load has dropped. I think there may be a bunch of edge cases that are hard to deal with.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I don't know enough about the target audience to know if adding the FIFO<br>
> guarantee is a good trade off or not. But I don't follow your use case for<br>
> OpenStack service sending messages to the user; when do these need to be in<br>
> order?<br>
><br>
<br>
</span>I don't think the FIFO is needed in most cases. It's the kind of thing<br>
that really helps you when you need it, but otherwise it's just sitting<br>
there doing nothing for you, costing your operator more to guarantee.<br>
<div><div class="h5"><br>
> ><br>
> ><br>
> >    If scaling the number of communicants on a given communication channel<br>
> >>><br>
> >>>> is a goal however, then strict ordering may hamper that. If it does, it<br>
> >>>> seems to me that this is not just a policy tweak on the underlying<br>
> >>>> datastore to choose the desired balance between ordering and scale, but<br>
> >>>> a more fundamental question on the internal structure of the queue<br>
> >>>> implementation built on top of the datastore.<br>
> >>>><br>
> >>>><br>
> >>> I agree with your analysis, but I don't think this should be a goal.<br>
> >>><br>
> >>> Note that the user can still implement this themselves using<br>
> >>> application-level sharding - if you know that in-order delivery is not<br>
> >>> important to you, then randomly assign clients to a queue and then poll<br>
> >>> all<br>
> >>> of the queues in the round-robin. This yields _exactly_ the same<br>
> >>> semantics<br>
> >>> as SQS.<br>
> >>><br>
> >><br>
> >><br>
> >>  The reverse is true of SQS - if you want FIFO then you have to implement<br>
> >>> re-ordering by sequence number in your application. (I'm not certain, but<br>
> >>> it also sounds very much like this situation is ripe for losing messages<br>
> >>> when your client dies.)<br>
> >>><br>
> >>> So the question is: in which use case do we want to push additional<br>
> >>> complexity into the application? The case where there are truly massive<br>
> >>> volumes of messages flowing to a single point? Or the case where the<br>
> >>> application wants the messages in order?<br>
> >>><br>
> >>> I'd suggest both that the former applications are better able to handle<br>
> >>> that extra complexity and that the latter applications are probably more<br>
> >>> common. So it seems that the Zaqar team made a good decision.<br>
> >>><br>
> >>><br>
> >> If Zaqar is supposed to be comparable to amazon SQS, then it has picked<br>
> >> the<br>
> >> wrong choice.<br>
> >><br>
> ><br>
> > It has certainly picked a different choice. It seems like a choice that is<br>
> > friendlier to beginners and simple applications, while shifting some<br>
> > complexity to larger applications without excluding them as a use case.<br>
> > That's certainly not an invalid choice.<br>
><br>
> > It isn't OpenStack's job to be cloning AWS services after all... we can<br>
> > definitely address the same problems better when we see the opportunity. We<br>
> > should, of course, think very carefully about all the consequences,<br>
> > intended and unintended, of changing a model that is already proven in the<br>
> > field and the market, so I'm very glad this discussion is happening. But<br>
> > after digging into it, the choice doesn't seem "wrong" to me.<br>
> ><br>
><br>
> To me this is less about valid or invalid choices. The Zaqar team is<br>
> comparing Zaqar to SQS, but after digging into the two of them, zaqar<br>
> barely looks like SQS. Zaqar doesn't guarantee what IMHO is the most<br>
> important parts of SQS: the message will be delivered and will never be<br>
> lost by SQS. Zaqar doesn't have the same scaling properties as SQS. Zaqar<br>
> is aiming for low latency per message, SQS doesn't appear to be. So if<br>
> Zaqar isn't SQS what is Zaqar and why should I use it?<br>
><br>
<br>
</div></div>I have to agree. I'd like to see a simple, non-ordered, high latency,<br>
high scale messaging service that can be used cheaply by cloud operators<br>
and users. What I see instead is a very powerful, ordered, low latency,<br>
medium scale messaging service that will likely cost a lot to scale out<br>
to the thousands of users level.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>