in this slide we are going to talk about benefits of OCI Queue Service. OCI Queue Service,
or OQS, is a fully managed, serverless, high throughput, highly available queuing service
capable of ingesting millions of messages per second, and it eliminates overhead of
managing message-oriented middleware. Users can publish, consume, delete messages,
and they can update the visibility timeout of the message as well.
OQS helps to decouple applications and scale them independently. It also supports a dead
letter Queue, and ensures messages are not lost if not acknowledged by consumer.
OQS supports REST and Industry leading STOMP protocol, as well as a SDK in multiple languages.
So, let's talk about one of the solution architectures which we have for Oracle Queue
Service, which is a typical producer-consumer scenario, and is pretty common in the case of
any asynchronous Queue service. So, we see on the left-hand side we have a producer, which can be
hosted anywhere, and the producer can be anything: it can be a simple application that is hosted on
your desktop and sending messages, or it can be a web application which is sending messages to OQS,
or it can be any other application which is interacting with the Oracle Queue Service.
So, the producer is sending messages. Messages can be anything--so you can send JSON messages,
you can send XML messages, you can send a text message. You can send a binary message to Oracle
Queue Service. On the right-hand side, we have a consumer app which is hosted in Oracle Kubernetes
Engine. So, the consumer application typically consumes a message; when we say "consume the
message" it means process the message. So, processing messages can be done in various
ways-- I mean it can pass it to any other consumer app, or it can save it in the database, it can
save it in object storage, or it can send it to any other Queue or any other service. However,
in this case, we are just going to process it, to showcase how the message is processed,
and then we are going to acknowledge it back to the Oracle Queue Service that the consumer has
successfully processed the message, and we will send the acknowledgment which basically means we
are going to make a delete call. Now we will also see that how consumer will scale up based on the
Queue size. Queue size we are going to check by using an Oracle Function which is exposed using
the API Gateway, and it calls the Queue status API of the Oracle Queue Service.
And based on this, based on the number of messages in the Queue, we scale the consumers. And how the
consumers are scaled up--we use a metric-based scalar which is called KEDA. KEDA stands for
Kubernetes Event Driven Autoscaler, and it scales the number of ports. So, the consumer app is
basically hosted on a single port, but when it says the number of messages are increasing in
the Queue it will start scaling up from one to "n" -- we have set the [scaling] limit,
which we will see in action. So it starts scaling the number of consumers and once
the number of messages starts going down it starts scaling down. The images of the
consumer app is hosted in the Oracle Container Registry and same for the Oracle Function.
We will see the now producer-consumer demo in action, how our consumers are going to scale up,
and how the consumers are going to match with the speed of the producer,
so we will see how the get state API works. So, let's see get state, and then we will start our
producer. So, right now we can see the physical messages are zero, so I am checking it every five
seconds in this check, and visible messages are zero, in-flight messages are zero, DLQ visible
messages are zero, and DLQ in-flight messages are zero. So, it will soon start increasing and
I'm going to start the producer but before we start the producer, let's see our consumers.
So, right now this is my deployment, and deployment name is queueoke which I have just
explained, and you see right now we don't have any ports because there are no messages in the Queue.
So, once we start pushing the messages in the Queue using producer, soon consumers
will start scaling up as messages, start going down--or going up--and I'm starting producer now,
which is hosted on a virtual machine.
And I'm a starting producer and you can see it will be pretty fast. We will also see the message
latency which is typically in milliseconds, less than 100 milliseconds in the same reason.
On the right-hand side we can see now the visible messages are increasing:
right now there are zero in flight messages, and in flight messages now will keep increasing. Right
now, the visible messages will be more because consumers will take some time to catch up. You
can also see the latency which is less than 100 milliseconds, which is in 20 and 30 milliseconds.
The total message count is increasing but our in-flight messages are less right now.
And let's go to consumer side and see how
our consumers have started scaling up; you can see that we right now we have added ports ready
so new ports are getting created and you can see how fast
our new consumers are getting up and running.
So, we can see the visible messages are increasing, and so are our in-flight. It
will take some time to catch up because if you can recall I have introduced a one millisecond delay
for every message, so that consumers can process the message, as well as I am also
calling the delete message API. So due to that there is some amount of delay on the consumer
side, but on the producer's side we don't have any delay, and we are sending 20 messages in
every call. So that's why we have the higher number of consumers but a single producer on
the producer side. And let's quickly check the.... so we can see that we have a number of ports which
are running is 64. And we have all 75 ports are in place now. And let's see the visible messages:
so right now it's a 30,000 messages, though the producer has pushed around 100K messages,
and soon producer and consumer will match the speed of producing and the consuming of messages.
Number of in-flight messages will increase as we move forward.
The specific logs like this which we have just shown how each consumer is processing the messages
and the estimated time, and all those things are in place.
So we can see that we can also view the visible messages from Queue Console
and it's auto refresh: so now consumers are matching with the producer soon.
One level up and you can see it from here also and as well as you can see there are
no messages in the dead letter Queue because all the messages are getting processed successfully.
So we can see that the number of visible messages are going down
and the number of in-flight messages are more now, so soon we will see that
number of messages are probably less than 100; or it is getting consumed
as soon as producer is producing it. So see, some of our ports are restarting
so KEDA is already in action
and we have almost all of our reports in action now, and we'll see that
our consumers are now scaling down so I will stop the producer
and we will see that KEDA will start scaling down
our consumers pretty soon since we have defined two minutes of cool-down period
so it will take some time, and post that it will scale down all the consumers.
So we can see that after waiting for some time--since we have defined two
minutes of cool-down period now since we have stopped the
producers and there are no messages in the Queue, which we can see from here:
visible messages are zero, in-flight messages zero, so is DLQ and DLQ in-flight messages.
so that's why all our consumers are down now since it scaled down now,
KEDA has scaled it down and you can see the zero ports here.