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

AI Engineer · 19 min · 123 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

  1. 00:01[music]
  2. 00:13Hi.
  3. 00:14Uh thanks thanks and uh hope everyone is out of uh the lunch coma and we'll survive this talk.
  4. 00:23So uh yeah myself Ritik I uh lead the payments team in uh JP Morgan and uh today I'll be talking about learn execution graphs how these graphs can help to
  5. 00:38uh detect any anomaly and uh drifts also how we can automate few things around that and uh you know u uh at the same time if we can reduce
  6. 00:55the manual you know detection work and uh going on that side uh so whenever we hear about graph uh there are persistence graph and property graphs uh which Neo4j
  7. 01:11and you know other products uh we use for them we query those uh graphs and get the answers out of it what I'm talking about today is execution graph.
  8. 01:24It's short-lived graph.
  9. 01:26Uh and 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.
  10. 01:41So here is a simple example.
  11. 01:43Uh say we have set of applications.
  12. 01:47uh you have one edge layer uh the first layer where you know request comes in and then uh you have some gateways uh if k is there you have ingress layer on top of it then authentication authorization
  13. 02:02happens after that there is some orchestration layer and uh few other systems which could be called in parallel uh once everything is done you are notifying your client that what's the update on that request right
  14. 02:16So here the idea is representing the uh overall request processing as DAG and using tag simplifies most of the things here.
  15. 02:30one now you know that uh in what order service execution will be happening right so that's one of the thing the other thing is uh you know the context
  16. 02:42that in at what node what context will be there and what will be passed to the next node uh in that way it will be very um u ordered and simplified
  17. 02:54u uh simply can be represented uh there are few other uh use cases could be uh in terms of retries and uh the loops etc. uh the idea here is
  18. 03:09uh every loop uh to put in the graph as a separate entity itself.
  19. 03:14So uh in that way it could be tracked uh easily.
  20. 03:23how we can make this system uh more uh reliable at the same time not using uh most of the resources right so in the tier one check or it's your first check it's like uh going to airport and you you you know it's just boarding pass is some someone is looking at the boarding pass
  21. 03:44and let you go so uh now if you know the baseline of your request execution end to end if uh everything looks Good.
  22. 03:53You don't need to go to the tier two uh or next tier of check.
  23. 03:57Right?
  24. 03:57Once if you find that there is some delay.
  25. 04:02So now you need to check that what changed here.
  26. 04:06One of the uh the drift here could be because of the structural change.
  27. 04:11So if any new node or new step added which you are not aware of that could be one of the thing or one of the step which is removed that could be the another reason right.
  28. 04:22Uh once you know about that then further uh further analysis could be done uh in terms of scale deviations uh divergence and uh exponential ma uh so in simpler terms
  29. 04:40if you know that client A's request is taking this much time normally and uh client B's request could take might take more time than the client A um because of say
  30. 04:53one client is local to you and one client is uh you know the request is coming from outside and uh there are a few more checks needs to be done.
  31. 05:01So in in that case the baseline will change client to client and now you know that uh what your threshold it and uh how you can u reduce the noise of such alerts.
  32. 05:16Uh so here the idea is very simple.
  33. 05:22First you uh represent the entire request processing as DAG.
  34. 05:29You come up with the baseline.
  35. 05:31You find out the deviation and then you try to find out where exactly the issue is.
  36. 05:38Once you localize that then you compare that based on your system that whether it is uh within the threshold or not.
  37. 05:46If it is within the threshold yeah you don't need to u you know do the alerts or automate anything but if it is out of the threshold then certain action needs to be taken.
  38. 06:00Uh coming back to our example here say overall uh request processing from all the different nodes within our system uh is happening but somehow the foreign transaction uh rate service is taking more time than the usual.
  39. 06:19Now if you represented this whole uh request processing in multiple nodes you know where the problem is or where the issue is and correspondingly you will uh you know now you can
  40. 06:32uh exactly know where the problem is.
  41. 06:34So you can solve it uh that what how to uh how FX system or what all different uh cases were there in the past where FX FX rate system was failing.
  42. 06:47Here is one of the example uh for benchmark uh open telemetry and that star bench were used and say for 7 days of the time millions of uh traces were
  43. 07:04um you know injected or uh in the system then you inject the problem or uh anomaly there and based on that you train your system before anything goes on live.
  44. 07:21So uh again uh basic thing here is what is anomaly and what is drift right?
  45. 07:29So say you are driving from your home to office every day and uh one of and usually it takes 1 hour but uh one fine day it took you more time than 1 hour.
  46. 07:43Uh the reason might be some traffic or you know um car accident or anything.
  47. 07:50But uh he this is one of the incidents and uh based on your system and criticality of your system uh you can decide how to address that.
  48. 08:01The other part is one fine day you are uh taking sip of coffee around 4 p.m. and realized that a year back it used to take one hour for you from your home to office but nowadays it it is taking 20 more minutes
  49. 08:16right so what happened in Bay Area in number of carc so this is over the time what you are seeing is pattern changed and that's where you might need to come up with
  50. 08:30uh the new baseline itself so uh that's that's the drift that over the time you start seeing some delays or you know some uh performance deviation then once you know that there is a drift
  51. 08:47uh you can further categorize it first category is structural uh so say you somehow in the system a new node is added or one of the node is removed as I mentioned earlier
  52. 09:02for example you like uh again you know there is a shop where you like uh drinking coffee and uh one fine day they are ask start asking you about membership so they added one more
  53. 09:14uh step in it now every day they might ask you for hey do you have membership with us if you have then there is there are a special discount for you if you don't have membership then the regular prices will be there so in that way uh you know
  54. 09:28same way in our service processing or a request processing if new node is added that means uh Now you need to consider that step also in your old baselines
  55. 09:40and new alerts.
  56. 09:43The other one is uh say because of the volume of request uh one of your service is taking more time or it's not you know u cannot serve the request
  57. 10:01or the volume which you are expecting now over the time.
  58. 10:04So yeah, such kind of drifts you might need to treat differently because now you need either you need to scale up those services or instances of those services and or
  59. 10:15you need to either make it asynchronous call or based on based on the use case you know what whatever uh works there uh co-variate is a different uh one of the category
  60. 10:27say when you started the business uh you were seeing around 60% of local request but uh and 40% uh request from you know out of the country and that's where you might need
  61. 10:42to change the currency or you know one extra step is there so you now you know that what is the baseline for your uh request in US dollar but uh what is the baseline for
  62. 10:54uh any of the other currency over the time what happens is your product is so popular that you started getting more uh request from the outside.
  63. 11:05So nothing changed.
  64. 11:06Your system is working fine, right?
  65. 11:08But now you need to come up with the criteria and reassess your baselines again.
  66. 11:15Sorry here where uh either you need to come up with two different uh you know uh graphs to compare that one is for local and one is for um outside uh request from outside
  67. 11:31or what you can do is you can increase your uh average request time baseline.
  68. 11:38So once you know the pattern uh you know the solution.
  69. 11:42So uh that's where you need to categorize uh this drifts.
  70. 11:48One category could be for the same request uh now you are seeing the different behavior itself.
  71. 11:55Then probably if and when it's needed you might need to roll back such uh changes or either you need to reconsider that.
  72. 12:06So where I'm going with this is in that way you need to re-evaluate and reassess your system before uh identifying that what action needs to be taken.
  73. 12:18This whole talk is mostly about statistical uh uh you know part of uh the solution.
  74. 12:25uh it's it's uh part of bigger neuro uh specific uh um algorithms and system in a way but this is just one of the module which uh I'm talking about here now
  75. 12:41so once you know the drift or deviation and here is the simple uh tag for how uh this whole system would work.
  76. 12:58Open telemetry will will keep feeding the data.
  77. 13:02Once you have that data, uh root cause analysis could be taken based on uh once your system knows about all the data points.
  78. 13:11Now you know which type of drift it is and what solution could be there.
  79. 13:17Then you identify what action needs to be taken.
  80. 13:21Once you know what action needs to be taken further you need to also uh find out that what is the risk if we go with this approach or if we automate this uh solution right so once you know the risk
  81. 13:35either you can go with uh roll out that system uh um solution for say 5% or 10% of your uh machines monitor it verify everything looks good and then you roll out for your 100% of the nodes Here
  82. 13:54are a couple of example.
  83. 13:55uh again uh say generally overall request processing takes 700 millisecond but uh on the left side what you are seeing is u in the graph approach itself how it could help you is
  84. 14:09uh now you know that uh which specific node is taking more time suddenly you get alert on that or otherwise if you are seeing that uh the delay is all across
  85. 14:19then something which is common which you need to fix here all these things because in the payments and the real time uh payment processing we want to keep it very faster right so
  86. 14:35we don't want delay the actual request processing the solution which we generally use uh everyone in the industry is asynchronously feeding the data to uh opal telemetry from there
  87. 14:48u some kafka could be used and stream assessment uh could be used on top of it.
  88. 14:56There could be two different paths.
  89. 14:58One is say hot path where you can take a decision very faster and uh um work on the solution or automate that solution.
  90. 15:07The other one is more recon kind of solution where it might take some time but more more accurate could it could be
  91. 15:18[snorts]
  92. 15:21few of uh uh other challenges which uh we need to fine-tune here.
  93. 15:26So all I talked about is hey you have seven nodes in your system and every node is feeding the data to your uh telemetry.
  94. 15:35What if one of the system is delaying the event?
  95. 15:41Should we consider it as a structural change because now what you have data in your system is for six nodes and the seven uh uh the data from the seven node is delayed already.
  96. 15:53So we need to fine-tune that uh that those numbers also that when to consider that uh there is a structural change or not.
  97. 16:02So basically here we are uh trying to reduce uh any false alarm based on the use cases and here in this use case u we should go with tail by based system because
  98. 16:16what we are trying to track here is uh or in this specific example is when the service request started and when it ended right so uh for each and every node
  99. 16:30the other part is the cold start uh if there is a new endpoint consider the new baseline don't make it very generic.
  100. 16:39So in that way on the detect side any MMD or KL uh could be used uh and once you confirm uh this with admin and then classify uh the problem
  101. 16:55uh that will give you where what exact solution needs to be done and next step whatever uh if we can automate it we'll automate it.
  102. 17:06So what we see uh in general here is uh mean time to uh discovery reduced a lot to make it very real time.
  103. 17:16Instead of comparing or waiting for multiple windows of uh the time duration it was uh a single window which we uh uh you know which we identified uh helped a lot
  104. 17:28uh to fix the issues fast.
  105. 17:33uh few of other things which we might need to make sure.
  106. 17:38One is uh the labels when it comes to uh learnings the labels helps a lot but uh at the same time uh we need to make sure that uh
  107. 17:49the system is very fine tuned in terms of that.
  108. 17:51Uh the other part is instead of saying that all the post requests should have you know this is a baseline for all the post request uh try to come up with very
  109. 18:04uh a number which works for you post for payments for real-time payment or post for wire payments or u based on you know uh your use cases.
  110. 18:14So that that would help a lot.
  111. 18:16Um again uh if anything is u um you are considering a structural change or something uh the window uh should be well defined for each and every client.
  112. 18:30In my previous uh example which I talked about uh if you can come up with the new baseline would really help uh to reduce the noise.
  113. 18:38Uh explanability uh all the data should be well explained.
  114. 18:44If you go to the doctor and doctor says your health score is 22, it doesn't make much sense to you.
  115. 18:50So, uh yeah, the actual uh more data uh can explain you know more things to you and uh can we can take the informative decision on top of it.
  116. 19:01Uh whole system should be aware of the new deployment.
  117. 19:05Uh so u u based on that you can take either roll back decision or not.
  118. 19:12So yeah that's that's about it.
  119. 19:14Uh thanks everyone.
  120. 19:15Uh I would like to connect with you all.
  121. 19:18Uh here is my LinkedIn.
  122. 19:19I can answer it.
  123. 19:35[music]