Learned Execution Graphs for Anomaly Detection & Drift in APIs — Ritvik Pandya, JP Morgan Chase

Hi. Uh, thanks, thanks. And I hope everyone is out of the lunch coma and will survive this talk. So, yeah, myself, Ritvik. I lead the payments team in JP Morgan, and today I'll be talking about Learned Execution Graphs: how these graphs can help to detect any anomaly and drifts.

Also, how we can automate a few things around that. And, you know,

at the same time, if we can reduce the manual, you know, detection work and going on that side. So whenever we

hear about graph, there are persistence graphs and property graphs, which Neo4j and, you know, other products we use for them. We query those graphs and get the answers out of it. What I'm talking about today is Execution Graph.

It's a short lived graph, and the idea here is, holistically, try to identify how the request processing happens, and if there is any deviation on that, and how to detect that, and how to fix that.

So here is a simple example. Say we have a set of applications. You have one edge layer, the first layer where, you know, a request comes in. And then you have some gateways. If the gate is there, you have an ingress layer on top of it.

Then authentication, authorization happens. After that, there is some orchestration layer and a few other systems which could be called in parallel. Once everything is done, you are notifying your client that what's the update on that request,right? So here, the idea is representing this overall request processing as DAG.

And using DAG simplifies most of the things here.

One, now you know that in what order service execution will be happening,right? So that's one of the things. The other thing is, you know the context that in at what node, what context will be there, and what will be passed to the next node.

In that way, it will be very ordered and simplified, simply can be represented. There are a few other use cases could be there in terms of retries and the loops, etc. The idea here is

every loop to put in the graph as a separate entity itself. So in that way, it could be tracked easily.

How we can make this system more reliable at the same time not using most of the resources,right? So in the tier one check, or it's your first check, it's like going to airport and you, you know, it's just boarding passes.

Someone is looking at the boarding pass and let you go. So now if you know the baseline of your request execution end to end, if everything looks good, you don't need to go to the tier two or next tier of check,right?

Once if you find that there is some delay, so now you need to check that what changed here. One of the drift here could be because of the structural change. So if any new node or new step added which you are not aware of, that could be one of the things.

Or one of the steps which is removed, that could be another reason,right? Once you know about that, then further

analysis could be done in terms of KL deviations or divergence and exponential MA. So in simpler terms, if you know that client A's request is taking this much time normally, and client B's request could take, might take more time than the client A because of, say, one client is local to you and one client is, you know, the request is coming from outside, and there are a few more checks needs to be done.

So in that case, the baseline will change client to client. And now you know that what your threshold is and how you can reduce the noise of such alerts.

So here, the idea is very simple. First, you

represent the entire request processing as DAG. You come up with the baseline. You find out the deviation. And then you try to find out where exactly the issue is. Once you localize that, then you compare that based on your system, that whether it is within the threshold or not.

If it is within the threshold, yeah, you don't need to, you know, do the alerts or automate anything. But if it is out of the threshold, then certain action needs to be taken.

Coming back to our example here, say overall request processing from all the different nodes within our system is happening, but somehow the foreign transaction rate service is taking more time than the usual. Now, if you represent this whole request processing in multiple nodes, you know where the problem is or where the issue is.

And correspondingly, you will, you know, now you can exactly know where the problem is, so you can solve it. That what, how to, how FX system or what all different cases were there in the past where FX rate system was failing.

Here is one of the example for benchmark, open telemetry, and that's Star Bench were used. And say for seven days of the time, millions of traces were, you know, injected or in the system. Then you inject the problem or anomaly there.

And based on that, you train your system before anything goes online.

So

again, basic thing here is what is anomaly and what is drift,right? So say you are driving from your home to office every day, and one of, and usually it takes one hour. But one fine day, it took you more time than one hour.

The reason might be some traffic or, you know, car accident or anything. But this is one of the incidents. And based on your system and criticality of your system, you can decide how to address that. The other part is one fine day you are taking a sip of coffee around 4:00 p.m.

and realize that a year back, it used to take one hour for you from your home to office. But nowadays, it is taking 20 more minutes,right? So what happened? In Bay Area, your number of car increases or traffic increase.

So this is over the time, what you are seeing is pattern changed. And that's where you might need to come up with the new baseline itself.

So that's the drift that over the time you start seeing some delays or, you know, some performance deviation. Then once you know that there is a drift, you can further categorize it. First category is structural. So say you somehow in the system, a new node is added or one of the nodes is removed, as I mentioned earlier.

For example, you like, again, you know, there is a shop where you like drinking coffee. And one fine day, they start asking you about membership. So they added one more step in it. Now every day, they might ask you for, "Hey, do you have membership with us?"

If you have, then there are special discounts for you. If you don't have membership, then the regular prices will be there. So in that way, you know, same way in our service processing or request processing, if a new node is added, that means now you need to consider that step also in your all baselines and new alerts.

The other one is, say, because of the volume of request, one of your service is taking more time or it's not, you know, cannot serve the request or the volume which you are expecting now over the time. So, yeah, such kind of drifts you might need to treat differently because now either you need to scale up those services or instances of those services, and or you need to either make it asynchronous call or based on the use case, you know, whatever works there.

Covariate is a different one of the category. Say when you started the business, you were seeing around 60% of local requests and 40% requests from, you know, out of the country. And that's where you might need to change the currency or, you know, one extra step is there.

So now you know that what is the baseline for your request in US dollar, but what is the baseline for any of the other currency. Over the time, what happens is your product is so popular that you started getting more requests from the outside.

So nothing changed. Your system is working fine,right? But now you need to come up with the criteria and reassess your baselines again, sorry, here, where

either you need to come up with two different, you know, graphs to compare. That one is for local and one is for requests from outside. Or what you can do is you can increase your average request time baseline.

So once you know the pattern, you know the solution. So that's where you need to categorize these drifts. One category could be for the same request, now you are seeing the different behavior itself. Then probably if and when it's needed, you might need to roll back such changes or either you need to reconsider that.

So where I'm going with this is in that way, you need to reevaluate and reassess your system before identifying that what action needs to be taken. This whole talk is mostly about statistical, you know, part of the solution.

It's part of bigger neuro-specific

algorithms and system in a way. But this is just one of the modules which I'm talking about here now. So

once you know the drift or deviation, and here is the simple DAG for how this whole system would work. Open telemetry will keep feeding the data. Once you have that data, root cause analysis could be taken based on once your system knows about all the data points.

Now you know which type of drift it is and what solution could be there. Then you identify what action needs to be taken. Once you know what action needs to be taken, further you need to also find out that what is the risk if we go with this approach or if we automate this solution,right?

So once you know the risk, either you can go with roll out that solution for, say, 5% or 10% of your machines, monitor it, verify everything looks good, and then you roll out for your 100% of the nodes.

Here are a couple of examples. Again, say generally overall request processing takes 700 milliseconds. But on the left side, what you are seeing is in the graph approach itself, how it could help you is now you know that which specific node is taking more time.

Suddenly you get alert on that. Or otherwise, if you are seeing that the delay is all across, then something which is common which you need to fix here.

All these things because in the payments and the real-time payment processing, we want to keep it very faster,right? So we don't want delay the actual request processing. The solution which we generally use everyone in the industry is asynchronously feeding the data to OpenTelemetry.

From there, some Kafka could be used and stream assessment could be used on top of it. There could be two different paths. One is, say, hot path where you can take a decision very faster and work on the solution or automate that solution.

The other one is more recon kind of solution where it might take some time, but more accurate it could be.

Few of other challenges which we need to fine-tune here. So all I talked about is, hey, you have seven nodes in your system and every node is feeding the data to your telemetry. What if one of the system is delaying the event?

Should we consider it as a structural change? Because now what you have data in your system is for six nodes and the data from the seven node is delayed already. So we need to fine-tune

those numbers also that when to consider that there is a structural change or not. So basically here we are trying to reduce any false alarm. Based on the use cases, and here in this use case, we should go with tail-based system because what we are trying to track here is, or in this specific example is when the service request started and when it ended,right?

So for each and every node. The other part is the cold start. If there is a new endpoint, consider the new baseline. Don't make it very generic. So in that way, on the detect side, any MMD or KL could be used.

And once you confirm this with admin and then classify the problem, that will give you what exact solution needs to be done. And next step, whatever, if we can automate it, we'll automate it. So what we see in general here is mean time to discovery reduced a lot.

To make it very real-time, instead of comparing or waiting for multiple windows of the time duration, it was a single window which we, you know, which we identified helped a lot to fix the issues fast.

Few of other things which we might need to make sure. One is the labels. When it comes to learnings, the labels helps a lot. But at the same time, we need to make sure that the system is very fine-tuned in terms of that.

The other part is instead of saying that all the post requests should have, you know, this is a baseline for all the post requests, try to come up with very a number which works for you. Post for payments for real-time payment or post for wire payments or based on, you know, your use cases.

So that would help a lot. Again, if anything is you are considering as structural change or something, the window should be well defined. For each and every client in my previous example which I talked about, if you can come up with a new baseline would really help to reduce the noise.

Explainability, all the data should be well explained. If you go to the doctor and doctor says your health score is 22, it doesn't make much sense to you. So, yeah, the actual more data can explain, you know, more things to you and we can take the informative decision on top of it.

Whole system should be aware of the new deployment. So

based on that, you can take either rollback decision or not. So, yeah, that's about it. Thanks, everyone. I would like to connect with you all. Here is my LinkedIn. I can answer it.