Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Automated Scaling of Microservice Stacks
for JavaEE Applications
Why I am here?
I want to discuss with you:
• General autoscaling concept for JavaEE applications
• Real issues and Tricky ...
I am sure you’ve heard those words many times …
I just deploy my application to Docker, set a number of replicas and
… hav...
Yes, pretty easy …
If you need a super scalable and clustered Hello World application …
In real life with JavaEE application
we have architecture similar to this
and its autoscaling becomes not a very trivial t...
Theoretical Part
At least
applications scalable
At least 3 key things to make your
applications scalable
Adapted runtime
(Container + JVM + JavaEE Server)
micro
FIRST:
Preferably, thin versions of application servers
NO! YES!
There are various versions adapted
for lightweight containers
micro
GlassFish
There are various versions adapted for light...
Any specific reason to use VMs for microservices?
NO!
Well…it might be, but …
Well…it might be, but …
One container - one microservice instance
NO!YES!
What should we use instead?
What should we use instead?
LXD
YES!
APP
MSMS
MS MS
Application
prepared for microservices
SECOND:
SORRY,
Application
prepared for SCALABLE microservices
Next few slides can be a bit boring for those
who know…
BUT
Still important!!!!!!
Next few slides can be a bit boring for ...
horizontal
vertical
Scaling vectors
Decomposition into microservice
At least
Decomposition into microservice
At least 2 key approaches
Logical division
1. Analyze metrics (NewRelic /
JavaVisualVM)
2. Find a weak point (!)
3. Move this part to microservice
4. Repeat
Splittin...
Orchestration
software
THIRD:
CONTAINERS
PROVISIONING
HEALTHCHECKS
METRICS
GATHERING
APPLICATION
LIFECYCLE
MANAGEMENT
AUTOMATIC
LOAD BALANCING
SERVICE
D...
CPU
HDD
(disk I/O)
SERVICE
FAILURE
RAM
NETWORK
SCHEDULER
Typical triggers that are used for scaling
Practical Part
Tricky things. Typical issues. Examples
horizontal
vertical
In which direction to scale?
Tricky thing #1
TOPOLOGY
Java EE Server
Business Tier
Web Tier
EJB App1 EJB App2
JSP App1
Java EE
Micro
Instance
JSP App1
Java EE
Micro
In...
Example #2
CPU NO
YES
YES
NO
NO
RAM
HDD (disk I/O)
NETWORK
SCHEDULER
Scaling type VERTICAL
Databases Triggers configuration
(dedicatee)
Takes much time to sync data
Temporary locks
Temporary performance degradation
RESUME
Hard to use auto horizon...
Events subscription
Usually, just spinning up an extra instance is NOT enough
Tricky thing #2
onAfterScaleOut[nodeGroup:ejb-app1] {
“call”: “registerNodeInMonitoringSystem”,
“call”: “addMemberToHazelcast”,
“call”: “c...
1. Decrypt encrypted volume, that was attached on-fly
onAfterVolumeAttached[nodeGroup:instance] {{
“call”: “decryptVolume”...
Proper triggers configuration
Tricky thing #3
This tuning is a long process, so be patient
Typical problem #1
Changing the value in one place can be reflected in other places
Load Testing
Detect deviations in testing loop
How to deal with this?
The triggers can become outdated with new code
Typical problem #2
COMMIT BUILD TESTING
PERFORMANCE
ANALYSIS
DELIVERY
The fix is easy here
Inject metrics collection as a part of your CI/CD ...
Getting rid of spare things
Tricky thing #4
Some of JavaEE Servers are designed for VMs, not for containers
On example of Weblogic
Typical problem #1
Just remove everything spare
What is the right way to go?
Network is full of useless traffic
Total bandwidth
Useful traffic
Typical problem #2
Multicast | Heartbeats
Avoid multicast for members detection
Instance 1
Orchestrator
Instance 2
Instance 3
What we can do?
Use events and unicast
Real use case
On-Demand Scalability and Easy Management of Java EE Project: Hybrid Cloud for Miele
• Migrated from VMs to ...
Java in Containers
https://jelastic.com/java-cloud-hosting/
Jelastic.com
info@jelastic.com
@jelastic
Upcoming SlideShare
Loading in …5
×

Automated Scaling of Microservice Stacks for JavaEE Applications

642 views

Published on

Find out how to configure and package clustered Payara Micro with load balancing, automatic scaling and dedicated storage for building cloud-native microservices. Then with the help of cloud scripting and triggering, automate CI/CD for the deployed application and emulate the load to check the scaling and performance results.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Automated Scaling of Microservice Stacks for JavaEE Applications

  1. 1. Automated Scaling of Microservice Stacks for JavaEE Applications
  2. 2. Why I am here? I want to discuss with you: • General autoscaling concept for JavaEE applications • Real issues and Tricky things My goals are: • Save your time if you decide you need to scale your app • Share our own experience
  3. 3. I am sure you’ve heard those words many times … I just deploy my application to Docker, set a number of replicas and … have it running … bla bla bla … super easy! Done!
  4. 4. Yes, pretty easy … If you need a super scalable and clustered Hello World application …
  5. 5. In real life with JavaEE application we have architecture similar to this and its autoscaling becomes not a very trivial task… In real life with JavaEE application we have architecture similar to this
  6. 6. Theoretical Part
  7. 7. At least applications scalable At least 3 key things to make your applications scalable
  8. 8. Adapted runtime (Container + JVM + JavaEE Server) micro FIRST:
  9. 9. Preferably, thin versions of application servers NO! YES!
  10. 10. There are various versions adapted for lightweight containers micro GlassFish There are various versions adapted for lightweight containers
  11. 11. Any specific reason to use VMs for microservices? NO!
  12. 12. Well…it might be, but … Well…it might be, but …
  13. 13. One container - one microservice instance NO!YES!
  14. 14. What should we use instead? What should we use instead? LXD YES!
  15. 15. APP MSMS MS MS Application prepared for microservices SECOND:
  16. 16. SORRY, Application prepared for SCALABLE microservices
  17. 17. Next few slides can be a bit boring for those who know… BUT Still important!!!!!! Next few slides can be a bit boring for those who know
  18. 18. horizontal vertical Scaling vectors
  19. 19. Decomposition into microservice At least Decomposition into microservice At least 2 key approaches
  20. 20. Logical division
  21. 21. 1. Analyze metrics (NewRelic / JavaVisualVM) 2. Find a weak point (!) 3. Move this part to microservice 4. Repeat Splitting bigger parts into smaller
  22. 22. Orchestration software THIRD:
  23. 23. CONTAINERS PROVISIONING HEALTHCHECKS METRICS GATHERING APPLICATION LIFECYCLE MANAGEMENT AUTOMATIC LOAD BALANCING SERVICE DISCOVERY & CONNECTIVITY SCALING CUSTOM SCRIPTING* What it typically does?
  24. 24. CPU HDD (disk I/O) SERVICE FAILURE RAM NETWORK SCHEDULER Typical triggers that are used for scaling
  25. 25. Practical Part Tricky things. Typical issues. Examples
  26. 26. horizontal vertical In which direction to scale? Tricky thing #1
  27. 27. TOPOLOGY Java EE Server Business Tier Web Tier EJB App1 EJB App2 JSP App1 Java EE Micro Instance JSP App1 Java EE Micro Instance JSP App2 JSP App1 Java EE Micro Instance JSP App1 Java EE Micro Instance Scaling type Java EE Micro Instance Java EE Micro Instance Example #1 JSP App2 JSP App2JSP App1 JSP App1 Java EE Micro Instance JSP App1 Java EE Micro Instance JSP App1 Java EE Micro Instance JSP App1 Java EE Micro Instance JSP App1 Java EE Micro InstanceJava EE Micro Instance JSP App1 JSP App2 Legacy JavaEE application
  28. 28. Example #2 CPU NO YES YES NO NO RAM HDD (disk I/O) NETWORK SCHEDULER Scaling type VERTICAL Databases Triggers configuration
  29. 29. (dedicatee) Takes much time to sync data Temporary locks Temporary performance degradation RESUME Hard to use auto horizontal scaling Automatic vertical scaling can be used just fine It’s better to keep spare instances underloaded (dedicated storage per instance) Typical issues while scaling of database instances
  30. 30. Events subscription Usually, just spinning up an extra instance is NOT enough Tricky thing #2
  31. 31. onAfterScaleOut[nodeGroup:ejb-app1] { “call”: “registerNodeInMonitoringSystem”, “call”: “addMemberToHazelcast”, “call”: “call3rdPartyApiService” } onAfterScaleIn[nodeGroup:jsp-app2] { “call”: “removeNodeFromMonitoringSystem”, “call”: “removeMemberFromHazelcast” } Example #1 Typical ScaleIn/ScaleOut events and cases THE FULL WORKING AND MORE COMPLEX CODE EXAMPLE CAN BE FOUND HERE: https://github.com/jelastic-jps/payara/blob/master/payara-micro-cluster/manifest.jps
  32. 32. 1. Decrypt encrypted volume, that was attached on-fly onAfterVolumeAttached[nodeGroup:instance] {{ “call”: “decryptVolume” } 2. Get auth keys by instance before joining DAS onBeforeStartService[nodeGroup:instance] { “cmd”: “/root/scripts/pullAccessKeys.sh ${token}” } 3. Deprovision node from DAS if cluster was shrinked onAfterScaleOut[nodeGroup:das] { “cmd”: “./asadmin_proxy remove ${instance[@last].ip}” } Example #2 THE FULL WORKING AND MORE COMPLEX CODE EXAMPLE CAN BE FOUND HERE: https://github.com/jelastic-jps/glassfish/blob/master/manifest.jps
  33. 33. Proper triggers configuration Tricky thing #3 This tuning is a long process, so be patient
  34. 34. Typical problem #1 Changing the value in one place can be reflected in other places
  35. 35. Load Testing Detect deviations in testing loop How to deal with this?
  36. 36. The triggers can become outdated with new code Typical problem #2
  37. 37. COMMIT BUILD TESTING PERFORMANCE ANALYSIS DELIVERY The fix is easy here Inject metrics collection as a part of your CI/CD step
  38. 38. Getting rid of spare things Tricky thing #4
  39. 39. Some of JavaEE Servers are designed for VMs, not for containers On example of Weblogic Typical problem #1
  40. 40. Just remove everything spare What is the right way to go?
  41. 41. Network is full of useless traffic Total bandwidth Useful traffic Typical problem #2 Multicast | Heartbeats
  42. 42. Avoid multicast for members detection Instance 1 Orchestrator Instance 2 Instance 3 What we can do? Use events and unicast
  43. 43. Real use case On-Demand Scalability and Easy Management of Java EE Project: Hybrid Cloud for Miele • Migrated from VMs to Containers • Migrated from GlassFish to WildFly • Improved scaling and HA • Implemented Hybrid Cloud
  44. 44. Java in Containers https://jelastic.com/java-cloud-hosting/
  45. 45. Jelastic.com info@jelastic.com @jelastic

×