Hello All,
The purpose of today's post is to share a real life burning and escalated scenario which was new to me and how did I approach it and how big the escalations were and what was the outcome
Sitecore's goodwill was at stack not because Sitecore is not capable of handling it but just because our environment was Sitecore Managed Cloud, and any issue that comes if its infra, back end code, front end code will be first pointed as Sitecore issue and that is where our consultancy and experience will play a role to prove that it is not Sitecore issue.
Issue we faced
Out of the blue our site started giving "504 Gateway Time-out", and it was reported that almost everyone is getting this error, but when we used to browse the site, everything looked good and never 504.
Troubleshooting without initial clue
1) Sitecore Logs
2) Azure application insights
4) Sitecore Ticket
For safer side we also created a SC ticket with these dumps, in initial findings it was also showing long running queries and choking queries of layout services, and sometimes it showed one component being slow and sometimes it showed other components being slow, which was quite confusing
and memory and CPU analysis kept sending us to BOX-1 of slow running layout queries which were timing out the request, but now we knew that these could be side effect of the main cause of some kind of automatic traffic hitting the site which will choke any server.
5) Memory Dump & CPU analysis
We also enabled auto heal and memory dump and site slow down reports etc. now we had memory dumps collected, but all the dumps were showing layout service choking which we already knew.
Setting up hypothesis around the inputs from marketing team.
All of the timings matched too, whenever site gave 504, all of the time marketing team sent communications
So, we had now something to think about, because on the website we already did the load testing and server scaling etc. was in place, we were sure we had a good set up which could handle the traffic.
7) Load Testing
Though we decided to do a load testing again, and our load testing was showing all results ok with the same URLs which marketing team was sending in whatsapp or SMS marketing.
So again, we were sure that, it's not about the legitimate traffic but it is something to do with SMS and without clicking also burst of traffic is coming like DDoS
8) Server scaling
We decided to put more power on CDs, so we introduced 4 additional instances just to observe for couple of days so we can take out some reports and observe what is happening.
Even if we did that, we observed same amount of 504 request, and we observed following which was pointing to the same scenario of traffic in few seconds.
9) Azure Front Door logs
One more reporting and azure diagnostic query we run to check what is coming on AFD and what is giving 504, we took that report out in excel and something we observed
We observed that, there were some IP ranges which were hitting the sites in few seconds, so if you observe the above graph too
Within seconds site got 4-5 thousand hits, this behavior is not of users, there will be delay of few seconds, here are the IPs which we found
• 64.233.173.0/24
• 66.102.6.0/24
• 66.102.7.0/24
• 66.249.82.0/24
• 66.249.83.0/24
• 66.249.84.0/24
• 66.249.88.0/24
• 192.178.11.0/24
• 74.125.215.0/24
10) Further research yielded interesting facts
"Recent updates in Google Messages introduced enhanced security scanning and automatic link previews. These previews are generated by background preview agents that fetch the URL in advance to show a link preview to users.
Since these fetches imitate real user behaviour, they were being counted as actual clicks, resulting in inflated click numbers and sudden traffic spikes on your website.
Google uses a set of proxy/crawler IPs (including the ranges you shared) to pre-fetch URLs found in SMS messages. Because of this, you may observe:
• Multiple requests to your URLs within 2–3 seconds
• IPs from Google subnets appearing as traffic sources
• Sudden server load spikes right after SMS campaigns
• “Bot clicks” recorded even before users interact"
Solution
How-to's
- Sitecore Managed Cloud – DDoS attack mitigation steps
Support Information - Sitecore Managed Cloud Standard (MCS) PaaS 1.0 — DDoS IP Protection
Next action item is to put a rate limit rule based on the campaign URLs to make sure site does not get overwhelmed as these IP ranges may change and user agent could change too.
Summary Points
Most important things we learn are from actual pressure situations, and backing ourselves in our intuitions which comes from experience, especially when you have not come across situation like these, here are some take away I will always call out below important points when approaching these kinds of situations
1) Holding your ground
2) Believe in your hypothesis
3) Never give up
4) Use your intuitions which comes from experiences
5) Find alternatives
6) Start with fresh ideas
7) Take a break to get more fresh ideas
8) Think out of the box
9) Work as a team, to have more brain working
10) Don't leave any stone unturned
Thank you Manglesh Vyas for being there when needed the AFD reports or azure graphs etc. and my backend mate Kiran Sawant who always made sure that if we want to send any change of backend be it caching or fine-tuning resolvers was sent and checked during this P1 issue.
.png)
















.png)



.png)














