Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "the architecture of Amazon EC2 and what is the difference between Google and CCS". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Generally speaking, two key components of running modern distributed applications in a cluster are reliable state management and flexible scheduling. Amazon ECS simplifies the process of building and running containerized applications, but how to implement it is what's really interesting about Amazon ECS. Today, I want to explore the Amazon ECS architecture and explain what it can do. The following is a diagram of the basic components of Amazon ECS:

How do we Coordination the cluster

Let's talk about what Amazon ECS did. The core of Amazon ECS is the cluster manager, which is a background service that can handle the tasks of cluster coordination and state management. Above the cluster manager are different schedulers. Cluster management and container scheduling are decoupled from each other, so Amazon enables customers to use and create their own schedulers. A cluster is actually a pool of computing resources that an application can use. The resource pool here is the CPU, memory and network resources of the Amazon EC2 instance divided according to the container. Amazon ECS coordinates the cluster through a container agent running on each EC2 instance in the cluster. The agent allows Amazon ECS to communicate with EC2 instances in the cluster and to start, terminate, and monitor containers at the request of the user or scheduler. The agent is written in GE language and takes up less resources. at present, it is open source on GitHub based on Apache protocol. You are welcome to contribute and feedback.

How do we manage the state

In order to coordinate the cluster, we need a SSOT [single data source] on our cluster: the EC2 instance in the cluster, the task running on the EC2 instance, the container for the task, and the available / occupied resources (for example, network port, memory, CPU, etc.). It is impossible for us to successfully open and terminate the container until we have accurate cluster status information. To solve this problem, you need to store state somewhere, so the heart of a modern cluster manager is a key-value database.

This key database is represented as SSOT for any information entered by the cluster and stored here. In order to ensure reliability and scalability, this key-value database needs to be distributed to ensure persistence and availability, and to avoid the impact of network partitioning and hardware failures. Also because the key-value database is distributed, it becomes more difficult to ensure data consistency and correct concurrent modifications, especially in environments where the state is constantly changing (for example, the stop and start of the container). In this regard, in order to ensure that multi-state modifications will not conflict, some forms of concurrency control need to be put in place. For example, suppose two developers request the remaining memory from an EC2 instance for their containers to use. At this time, only one container can actually get these resources, while the other will be told that the request is incomplete.

In order to realize concurrency control, we use one of the core primitives of Amazon distributed system to implement Amazon ECS, which is a data storage system based on Paxos transaction log, which keeps the record of every data change. In the log, any data writes are committed as transactions and correspond to a specific order of ID. The current value of the data is the sum of those transactions recorded in the log. For any reading of data, all you get is a snapshot of the current point in time of the log. If the write operation is the latest committed transaction since the last read operation completed, the write operation is determined to be successful. This primitive allows Amazon ECS to store cluster state information in the form of optimistic locks, which is ideal for scenarios where shared data changes frequently, such as when you need to express the state of a shared pool of computing resources such as ECS. This architecture makes Amazon ECS highly available, low latency, and high throughput because pessimistic locks are not used in data storage.

Access via API

Now that we have a key-value database, we can successfully coordinate the cluster and ensure that the required number of containers are running because we have a reliable way to access the state of the cluster. As mentioned earlier, we decoupled the cluster management and container scheduling modules because we wanted customers to take full advantage of Amazon ECS state management capabilities. We have opened up the Amazon ECS cluster manager through a series of API, which allows customers to access the cluster status information stored in the key-value database in a structured manner.

Through the list command, customers can read the managed cluster, the EC2 instances running in a particular cluster, the running tasks, and the container configurations that make up the tasks (such as task definitions). Through the describe command, the customer can get the specific information about the EC2 instance and the resources available on each instance. Recently, customers can also start and stop tasks in any cluster. Recently, we have conducted a series of load tests on Amazon ECS, and we want to share some performance points that customers should pay attention to when creating applications on Amazon ECS.

The figure above shows the results of a load test in which we add and remove instances from the Amazon ECS cluster and measure the latency in the 50th and 99th places when calling 'Describe Task'API over a 72-hour period. As you can see, although there are large fluctuations in the number of clusters, there is relatively no jitter in latency. Amazon ECS can be extended as much as you need, no matter how large your cluster is, and there is no need to manipulate or extend the cluster manager at all.

This set of API is the basis for customers to build solutions on Amazon ECS. The scheduler simply provides logic about when, where, and how to open and stop the container. Amazon ECS's architecture is designed to share cluster status, allowing customers to run various schedulers (such as binary packaging, distribution, etc.) for applications as needed. This architecture allows the scheduler to query the specific status of the cluster and allocate resources from the general pool. Optimistic concurrency control allows schedulers to obtain the resources they request without conflict. Some customers have created various interesting solutions on Amazon ECS, so let's share some concrete examples.

Custom scheduling on Hailo-- Elastic Resource Pool

Hailo is a free mobile APP that allows people to hail a certified taxi to its location. Hailo has a global network that includes more than 60000 drivers and more than 1 million passengers. Hailo was founded in 2011 and has been using AWS since day one. In the past few years, Hailo has evolved from a collection of applications running on a single area of AWS to a micro-service architecture that spans multiple regions. Previously, each microservice ran on a statically divided instance cluster. The problem with Hailo is that cross-partition resource utilization is low. The architecture is not very scalable, and Hailo does not want its engineers to care about the details of the infrastructure or the deployment of micro-services.

To this end, Hailo decided to schedule the container based on service priority and other runtime metrics. Later, they chose Amazon ECS as the cluster manager because ECS can easily manage the task status and access the API of the cluster state. Similarly, Hailo can customize the scheduler according to its own needs.

Remind-- platform as a Service

Remind is a web and mobile application that allows teachers to send messages to students and get in touch with parents. The Remind platform has 24m users and more than 1.5m teachers. It sends 150m messages a month. Remind initially used Heroku to run the entire application facility, from the message push engine, front and back end API, Web client to chat background. Most of these facilities are deployed in large application blocks.

As users grow, Remind wants to have the ability to scale out. So around the end of 2014, its team of engineers began to explore the migration to a container-based micro-services architecture. The team wants to build a PaaS based on AWS to ensure that it is compatible with Heroku's API. At first, the team expected an open source solution (such as CoreOS and Kubernetes) to manage the cluster and collaborate with containers, but because the team was small, they had no time to manage the cluster's infrastructure while ensuring high availability.

After a brief evaluation of Amazon ECS, the team decided to build PaaS on top of this service. Amazon ECS is fully hosted, which allows engineering resources to be concentrated on developing and deploying applications; there is no cluster to manage and extend. In June, Remind opened up their ECS-based PaaS solution called "Empire". Significant performance improvements (for example, latency and stability) and security benefits have been achieved with Empire,Remind. Their plan in the coming months is to migrate more than 90 per cent of their core facilities to Empire.

Amazon ECS--, a fully hosted platform

The above are just two of the use cases we have seen from the customer. The Amazon ECS architecture allows us to provide a container-managed service with high scalability, high availability and low latency. The ability to access shared cluster states through API optimistic concurrency allows users to create any custom container solution on demand. We are committed to eliminating repetitive and onerous tasks for our customers. With Amazone ECS, there is no need to install or operate cluster management programs at all, and customers should only focus on developing excellent applications.

Continuous fermentation by Container Competition between Amazon and Google

The Google Container engine (GKE) consists of pod, replication controller, and nodes. Pod is a container logical grouping of a specific set of application logical host models; replication controller ensures that a certain number of pod copies are running at all times; and nodes are Google computing engine virtual machines that enhance the container environment.

GKE is based on Google's Kubernetes container orchestration platform. Kubernetes version 1.1 was released on November 24th, four months after the debut of version 1.0. it is the first product in the market that can automatically scale nodes through the automatic scaling function of horizontal nodes, which is highly sought after by users, thus providing strong support for many cases using GKE.

"We use auto scaling for many different types of projects," says Tim Kelton, co-founder and chief cloud architect of Descartes Labs. The New Mexico-based company is a machine learning startup capable of handling PB-level satellite data.

Auto-scaling pod can come in handy when dealing with large batch jobs, Kelton explained. Sometimes, his company handles PB-level data, which needs to be expanded to 3000 cores. In the first version of Kubernetes (which was soon merged by GKE), "this is not part of the core feature set," he said.

Although GKE does not support vertical container expansion or node automatic scaling, according to David Aronchick, a senior product manager at GKE who also dominates Kubernetes product management, these features will be implemented soon.

Amazon EC2 Container Service (ECS) consists of services, tasks, and instances. Services are the task groups that make up applications, while instances are elastic computing cloud virtual machines that support containers, much like nodes in GKE.

The auto-scaling capability of Google's ECS is the opposite of GKE: Amazon CloudWatch and Amazon Web Services Lamda can be used to achieve automatic service scaling, and instances can also automatically scale based on CloudWatch metrics, but the task, which is equivalent to pod, belongs to rough logic and cannot be automatically scaled.

While all types of auto scaling are important, Amazon users want to add task auto scaling to the ECS.

"running a new instance means you have extra capacity to run additional tasks, but that doesn't mean any new tasks will be started," said Chris Moyer, vice president of ACI Information Technology Group. ACI, based in New York, is a company of Web-based content aggregation technology and a contributor to TechTarget. "if you just automatically scale instances, it doesn't really help you deal with the extra load-you really have to run extra tasks to scale."

Cross-region redundancy

In the process of ECS development, Amazon gives priority to developing in the same cluster, aiming at the automatic scaling redundancy of tasks based on user needs and the local ability to span the availability zone (AZs). When the ECS service schedules new tasks, it will also try to automatically balance these tasks through the AZs in the cluster.

"this is important because a single AZ allows you to fail, so if both tasks are allowed in the same AZ, it's easy to drag down your service," Moyer said.

According to Aronchick, Google can span multiple areas through the command line interface (CLI) in GKE.

"it's very easy to achieve cross-region, and it can be done with two or three commands," says Aronchick.

However, this is about the biggest wish of GKE users: to improve cross-region functionality to the Web interface, including cross-domain cluster extension capabilities.

"it takes a lot of work to implement the user interface," said Dale Hopkins, chief architect of Vendasta Technologies, which designs sales and marketing software for media companies. The user interface currently supports cluster creation and a few other features. "it's not intuitive to expand the cluster," says Hopkins.

Interoperability

As an extensible platform, ECS aims to integrate customers' existing workflows and mainly deals with the cluster status that represents users. Integrate ECS into existing workflows to be compatible with tools in use by customers, such as Apache Mesos for advanced scheduling. Amazon also boasts an extensive network of container partners to contribute new features such as monitoring, continuous integration and security to Amazon ECS.

At the same time, Google has partnered with a number of cloud container partners that allow Kubernetes to be deployed through multiple cloud vendors-a feature of CLI now, Aronchick said. When Kubernetes version 1.0 was released last summer, Google led the establishment of the Cloud Native Computing Foundation, which includes cloud services companies such as IBM and Red Hat, as well as end users such as eBay and Twitter.

"[attached] Kubernetes, I can actually deploy it on Amazon, on Azure, on IBM, or on my own physical hardware," said Descartes's Kelton. "it's very attractive because we have a choice."

Google also has an open source project with hundreds of submitters and thousands of code submissions per month, allowing Kubernetes to quickly add new features, such as horizontal pod automatic extension.

Google is the founder of Kubernetes, and Google has done a lot of outstanding work to strengthen the community, said Jay Lyman, a researcher at 451 Research.

The rich get richer.

Still, integration using established and familiar secondary Amazon services makes Amazon ECS particularly attractive to new customers.

A New York-based company is consulting with large companies on IT projects and plans to use ECS on two new projects, according to its founder John D'Esposito. The main advantage that drives us to use ECS is the seamless integration of existing, mature infrastructure services such as resilient load balancing, virtual private cloud, identity and access management, and resilient block storage.

The pricing of GKE and Compute Engine is still very attractive to customers. In addition to being at the bottom of the 10-minute VM resource, GKE includes the free Kubernetes master node-- which is particularly attractive to Vendasta's Hopkins.

"I won't pay extra for Kubernetes until I can get a large number of machines. For the first set of machines, GKE provides me with Kubernetes nodes for free," Hopkins said.

Before Kubernetes and the container engine were introduced, both Hopkins and Kelton were already using Google cloud services, including the Google App engine. In this way, data gravity will work on the cloud containers they choose to deploy.

"most of our data sets are PB-sized, so you can't just move or copy them, you have to really calculate the data," Kelton said. Most of the data is currently stored on the Google cloud platform, although Descartes does not work with AWS partners.

Microsoft Azure Container Service is ready to go

Although Google and Amazon are still at the forefront of the competition for cloud containers so far, Amazon's biggest competitor is still Microsoft's Azure, which has its own Linux-based cloud container service during the limited preview phase, as well as a new version of Windows Server, which will support Windows-based containers after this year.

"most of our clients are. Whether at Azure or Amazon," said Chris Riley, co-founder of Rochester-based HKM Consulting, "Microsoft has acquired some interesting tools they are developing. If we see a minor one, it's likely to be Azure before Google."

Simplicity and ease of use are the design priorities of many Microsoft products, according to CTO Kristian Nese of Lumagate, a Norwegian Microsoft Azure system integrator.

"We are now deploying Azure's container service, which requires only 100 lines of code," Nese said. "once you deploy Azure's container service, you actually deploy 23 resources. If you want to do this manually, you may need thousands of lines of code."

The Azure container service also supports automatic extension during the preview phase and is a stand-alone service known as the VM gauge set.

Azure will also provide mature and familiar tools to manage containers, such as Azure's resource manager, Nese added.

This is the end of the introduction to "the architecture of Amazon EC2 and how it differs from Google container service". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.