Embed Size (px)
Citation preview
Top five Docker performance tips
2
Top five Docker performance tips
Table of ContentsIntroduction ............................................................................................................................................. 3
Tip 1: Design – design applications as microservices ................................................................................. 5
Tip 2: Deployment – deploy Docker components at a very fine granularity ................................................ 7
Tip 3: Application monitoring – monitor your Docker-based application at the business transaction level .. 9
Tip 4: Service monitoring – monitor your Docker containers as application tiers ...................................... 11
Tip 5: Docker infrastructure monitoring – knowing when to scale ........................................................... 13
Conclusion ............................................................................................................................................. 15
Introduction
4
Introduction
Docker is an open platform for building, shipping, and running distributed applications (https://www.docker.com/). Docker can be provisioned on virtually any infrastructure, including modern versions of Linux as well as Mac and Windows using VirtualBox, which allows Docker images to run on a local developer laptop as well as on a production cloud infrastructure. In short, Docker changes the way we view virtualization by providing a very lightweight runtime environment to host applications.
When we think about virtualization, we typically think about virtual machines and the hypervisor required to manage those virtual machines. Docker is different: it provides a lightweight layer that sits between your application and the underlying operating system on the Docker host machine, allowing your application to run as an isolated process in the machine’s user space. Docker images, therefore, contain the bare minimum operating system infrastructure to support the container that is hosting your application. For example, if you want to run a Java web application in Tomcat then your Docker image will contain a base Linux operating system, a Java Virtual Machine, and the Apache Tomcat. This allows images to be small and to consume only the resources required to run your application.
The key difference between a virtual machine and a Docker container instance, therefore, is that a Docker container instance does not require a full featured guest operating system. It only requires your application and an operating system with the support libraries your application needs and then Docker runs your application through that lightweight operating system layer, similar to running a process on your host machine. As a side effect of this architecture, Docker instances can start very quickly, measured in seconds rather than in minutes. When your application is under duress and you need to add more resources, waiting for a full VM to start may take too long to remediate the problem before it starts impacting your users.
Docker is a powerful container-based virtualization technology, but with that power comes careful considerations when designing, deploying, and monitoring your application. This white paper presents performance tips across all three of these disciplines: application design, optimal deployment, and production monitoring.
Tip 1: Design – design applications as microservices
6
Tip 1: Design – design applications as microservices
Just as we needed to design our applications specifically to run in the cloud, in order to effectively run applications in Docker, we need to make careful decisions about how we design our applications. In the days before the cloud, we saw very large applications running on big and powerful machines. In the Java world we built enterprise archives that contained both Enterprise JavaBeans as well as web applications, packaged all of these together in a single deployment, and shipped them off to large machines to host them. As we moved to the cloud we broke these large monolithic deployments into smaller units that could be deployed on smaller machines. Essentially we transitioned from vertical scalability (scaling up on a single machine to optimally use that machine’s resources) to horizontal scalability (scaling across multiple machines.) With Docker, we’re going to take that one step further.
There is an emerging trend in the industry towards microservices. Wikipedia defines microservices as:
A software architecture style in which complex applications are composed of small independent processes that communicate with each other using language-independent APIs; these services are small, highly-decoupled, and focus on doing a small task, facilitating a modular approach to system building.
Docker is perfect for hosting microservices and, in actuality, designing your application as a set of microservices will enhance the performance of your application running in Docker. Docker is meant to provide elasticity in your deployment environment. If you need 2 containers to support your load or 200, Docker can be made to scale up (or down) very rapidly. But in order to do this, your application has to be designed so that it can scale up and down.
The best strategy, therefore, is to identify common functionality in your application and group that functionality together, at a fine level of granularity, into services. For example, let’s consider typical actions that a user might perform when interacting with a web site:
– Create, update, delete an account– Login / logout from the web site– Manage a password– Manage a profile, such as name, address, avatar, and so forth– Accept terms and conditions– Opt-in to site features or notifications
In the past we might have created a profile service and packaged all of this functionality together into a single deployment. When designing microservices, each one of these categories of user interactions could be packaged individually. This does mean that you may have six different deployments for managing a user, but the benefit is that you will be able to scale this functionality independently. Consider how often a user logs into your application as compared to how often he/she enters a mailing address or accepts your terms and conditions. Because logins may occur daily, or even multiple times of day, we are free to scale up the login functionality while leaving the other capabilities more modest. And keep in mind that Docker containers do not map one-to-one to virtual machines: you can, and probably should, deploy multiple containers to a single virtual machine. So dividing your application into microservices will not necessarily affect the number of virtual machines you will need to run.
An additional benefit to designing your application as a collection of microservices is that you can more easily deploy updates and new versions of your components without disrupting your entire environment. Docker makes it easy to setup images with new versions of your components and deploy container instances to your Docker environment. Once those new versions are validated then Docker allows you to decommission the old version and truly achieve zero downtime deployments.
Tip 2: Deployment – deploy Docker components at a very fine granularity
8
Tip 2: Deployment – deploy Docker components at a very fine granularity
Docker is more like a process virtualization platform than a machine virtualization platform. Yes, your application runs in a virtual machine with a (lightweight) operating system, but rather than interacting with a virtual CPU, it interacts with and runs on the actual host CPU through the Docker Engine.
When viewed as a process, your microservices should be very granular in how they are deployed. For example, you might deploy a web container and a MySQL instance on a single virtual machine, but these are different processes so deploying them together does not make sense in the Docker paradigm. Instead, Docker would have you run two containers: one for your web application and one for your MySQL instance. Docker can better manage your deployment if you break your application deployment up in this way.
The optimal deployment, therefore, is to deploy your Docker containers at the granularity of microservices with one microservice per container. Recall that a single virtual machine may host more than one Docker container, so this does not mean that you will necessarily have more virtual machines, but this strategy does allow Docker to better manage your containers.
Tip 3: Application monitoring – monitor your Docker-based application at the business transaction level
10
Tip 3: Application monitoring – monitor your Docker-based application at the business transaction level
Because Docker encourages you to think more about your application functionality and less about the servers on which your application is running, the best strategy for analyzing the performance of your application is to view your application in terms of business transactions. A business transaction can loosely be defined as any significant interaction with your application that means something to your application’s business function. Examples of business transactions include adding an item to a shopping cart, searching for an item in a catalog, viewing an item’s details, paying for an item, and so forth.
A business transaction starts with an entry-point, such as a web request, a web service request, a message arriving on a message queue, or any other mechanism that initiates an interaction with your application, and then it continues as the business transaction traverses from server to server across your application. Docker applications are composed of microservices running in different containers, so the best way of analyzing the performance of a holistic application is to measure the performance of its business transactions. We want to identify the start of a business transaction and then trace the performance of that business transaction using services or application components running on different Docker containers. Under-the-hood, we generate a token when the business transaction starts and then pass that token to each service in every tier as the transaction progresses. Then, when the services finish processing, the holistic business transaction can be assembled.
Figure 1 shows an example of a flow map with a business transaction passing between tiers in your application.
Figure 1 An example of a flow map between tiers
This example shows business transaction requests passing from one application tier to another, across an entire application stack. We measure the performance of both the holistic business transaction as well as its constituent parts so that we can detect abnormalities before they impact our users. We want to understand what normal behavior is for an application and when things are not behaving normally, which
is accomplished by defining baselines. If you consider that every time a business transaction is executed, we have a data point, but in order to derive value from that data point we need to analyze it against the correct baseline. Baselines come in the following flavors:
– Hourly average for a time period, such as the average response time for the past 30 days
– Hour of day for a time period, such as the average response time between 8am and 9am for the past 30 days
– Hour of day and day of week, such as the average response time on Tuesdays between 8am and 9am for the past 10 Tuesdays
– Hour of day and day of month, such as the average response time on the 15th of every month between 8am and 9am for the past 6 months
The correct choice of a baseline depends on how your users interact with your application. For example, if you have an e-tail site and experience more load on Fridays and Saturdays then the day of week baseline might be the best choice for your application, but if you have a banking application that sees increased load on the 15th and 30th of the month then the day of month baseline might be your best choice. Once you have chosen a baseline then you need to compare each business transaction execution against its baseline and raise an alert if it is behaving abnormally. This is shown in Figure 2.
Figure 2 Analyzing a business transaction against a baseline
In this example we are comparing the response time of an individual business transaction execution against the baseline and alerting if it is greater than two standard deviations from its average response time. Your application behavior will dictate the best way to perform this comparison.
In summary, the most important way to assess the health of your Docker application is to assess the health of your business transactions and measure their performance against your baseline.
Business transaction response time
Baseline
Average + 2 standard deviations
Greater than 2 SDs: alert
Tip 4: Service monitoring – monitor your Docker containers as application tiers
12
Tip 4: Service monitoring – monitor your Docker containers as application tiers
When organizing a business transaction into its constituent parts, we define a tier as a segment or part of the business transaction that performs some action. So, in addition to measuring the performance of a complete business transaction, we also want to measure the performance of each individual tier that contributes to that business transaction. Capturing the performance of each tier enables us to perform the same baseline analysis at the tier level, which allows us to detect abnormal behavior in a tier before it significantly impacts the overall business transaction.
A tier is defined by a collection or set of like services. With respect to Docker, each type of container should be defined in its own tier. For example, when we defined the user login/logout and password management microservices above, we would define individual tiers for each one. A microservices architecture will result in significantly more tiers than a traditional application, but it allows us to assess the health of an application at an actionable granularity. For example, if we detect performance issues in the user login/logout tier then we can potentially deploy more containers to that tier to remediate the problem. Without this level of granularity we might be able to detect high-level performance issues, but we would not be able to identify the containers that need to be scaled.
The result of performing tier based analysis is that we can better leverage the elasticity that Docker affords us.
Tip 5: Docker infrastructure monitoring – knowing when to scale
14
Tip 5: Docker infrastructure monitoring – knowing when to scale
In addition to monitoring the behavior of your holistic business transactions and individual tiers, it is equally important to monitor the health of your Docker infrastructure. Docker provides a wealth of information about the Docker environment that can help you understand its performance. Docker’s statistics can be aggregated to give you a view of the total number of running containers and the individual container CPU usage, memory usage, and network I/O. This is shown in Figure 3.
Figure 3 Docker engine statistics
Understanding the behavior of Docker, and of each of your Docker instances, will help you understand when and where you need to scale by adding more instances to meet your user load. Observe the CPU and memory usage of each container and, when you notice that the majority of the container instances of a certain type are under duress, then add more container instances of that type.
You can leverage all the core functionalities of AppDynamics (e.g. dynamic baselining, health rules, policies, actions, etc.) for all the Docker infrastructure metrics while correlating them with the metrics already running in the Docker environment.
In short, you spend a significant amount of time designing your application as microservices and then deploying them to individual containers, but you also need to understand when you need to scale that set of containers up and down to meet user load. And this information can be assessed by looking at the performance of tiers and measuring those tiers against their baseline performance and by looking at the behavior of the underlying Docker infrastructure.
Conclusion
16
Conclusion
Docker provides a lightweight container layer that sits between your application and the underlying hardware on which it runs. Because Docker is very lightweight, you need to design your application as granular as you can and deploy instances that are likewise very granular. Furthermore, you need to monitor your Docker applications from three core areas:
– Business Transaction Performance– Tier Performance– Docker Infrastructure
This paper provided an overview of Docker and presented 5 tips to help you maximize the performance of your Docker applications across application design, deployment, and production monitoring.
