Import ECS Fargate into Spot Ocean

AWS Fargate is a serverless compute engine for containers that work with both Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). With Fargate handling instance provisioning and scaling, users don’t have to worry about spinning up instances when their applications need resources. While this has many benefits, it’s not without its share of challenges that can limit its applicability to a wide variety of use cases. In this blog, we discuss those limitations and how you can achieve your goals using Spot Ocean by NetApp as your serverless engine for containers.

ECS Fargate Considerations 

Fargate abstracts infrastructure from the user and manages compute in a black box. With no access to the actual infrastructure that clusters are running on, users do give up some control and transparency. This is especially apparent when it comes to compute pricing. On average, the cost of running workloads on Fargate is three times more than running the same workloads on EC2. For users that want to run serverless–but more cost efficiently–the options that Fargate offer are limited. While it’s possible to run Spot Instances, a more affordable pricing model, AWS doesn’t have an SLA for these, and they can be taken away with little to no warning. Moreover, using Fargate means that customers also can’t make use of their existing Reserved Instances.

There are also some technical limitations (see AWS Fargate Considerations) that can impact cost and limit flexibility. In addition to some restrictions on pod sizes, network, load balancing, GPU and other configurations, Fargate will also round up resource requests to specific sizes. This practice can create a lot of accumulated waste. For example, if you have pods that request 0.7vCPU and 1GB RAM, those requests would be translated by Fargate to 1vCPU and 2GB of RAM. With large clusters, this behavior leads to waste and drives costs up as Fargate charges by the resulting request size

Ocean for ECS 

For the best infrastructure of both worlds—hands-free and cost-efficient—Spot by NetApp offers Ocean, a serverless platform, purpose-built for containers. With your containers orchestrated by Ocean, automatically managing the underlying infrastructure, you can save up to 80% off EC2 costs.  

To achieve this significant cost savings, Ocean provisions the optimal blend of Spot, Reserved and On-Demand Instances with an enterprise-grade SLA. Applications can run reliably on Spot Instances, while the Spot platform monitoring the spot market and proactively replaces at-risk instances.

Under the hood, Ocean uses AI-driven algorithms to understand cluster resource utilization and the requirements of each container, picking the right instances to match application needs. It’s designed to provide a serverless experience, where users have the ability to control their infrastructure when they want to. They can set cluster-wide resource limits and have full visibility and granular control wherever they may need it.

Ocean includes further benefits and features such as: 

• Container-driven auto scaling
  As you deploy tasks, Ocean scales the number of instances in the cluster to meet your application demands. Ocean learns your tasks requirements and decides what is the best instance size or type to accommodate those requirements.  
• Headroom
  Headroom is a smart buffer of capacity that allows for immediate pod scheduling and helps avoid pending tasks. This makes scale-up a proactive, rather than only a reactive, process. Ocean supports custom headroom per Virtual Node Group. 
• Virtual Node Groups (VNGs)
  You can manage different workload types on one cluster with VNGs (previously launch specifications). Here, you can configure different sets of AMI, IAM profiles, and security groups. Ocean’s autoscaler will pick the right VNG based on attributes defined.  
• High Allocation
  Embracing a “container-first” approach, Ocean studies actual container requirements and utilizes bin packing algorithms to match tasks with the most efficient and optimized mix of EC2 instances. This ensures the instances are highly utilized, which is difficult to implement and track at scale, and provides additional cost reduction of 20-30%. 
• Right-Sizing
  This capability assists in optimizing ECS services resource requirements in terms of CPU and memory in order to increase the cluster’s utilization and lower operational costs even further. It provides actionable suggestions for the appropriate amount of CPU and memory based on actual consumption data. 
• Cost Showback
  One of the challenges of running workloads in a microservices architecture is that multiple applications and services share the underlying infrastructure, making it difficult to distinguish between the costs of various workloads. With Ocean’s cost showback, users gain insights into the costs of individual applications, with daily, weekly and monthly views, as well as relative and total costs. This visibility allows for better budget planning, financial reporting and forecasting.
• Cluster Roll
  With cluster roll, you can apply configuration changes with a single click. For example, when a new version of Kubernetes is released, both the control and data planes need to be updated. A managed service like ECS will handle the control plane, but the cluster’s worker nodes need to be updated as well. Ocean’s cluster roll feature can be used to update the worker nodes with the new ECS AMI versions by utilizing a smart deployment mechanism to replace the cluster infrastructure in a blue-green manner. The deployment performs a smart selection of instances to launch while considering the requirements of pods running in the cluster, as well as awareness of new workloads entering the cluster.
• Visibility
  Ocean allows you to drill down into cluster resources with the help of detailed dashboards that show resource allocation and utilization views, with breakdowns per node, deployment, tasks and right down to the container level.
• Automatically updated ECS agent
  Ocean will detect when a new ECS agent is available and update the AMI to the latest version automatically. 

Importing ECS Fargate into Ocean ECS 

Pre-req: 

1. Spot Organization has been created. If you’re not signed up, create your Spot Organization.
2. AWS account linked to a Spot Organization: Documentation
3. Creation of a Spot platform API Token: Documentation 
4. Fargate uses a network mode of: “awsvpc”. In order to assign each task with an ENI you must enable VPCtrunking in your account to allow multiple ENIs to get assigned to a single EC2 instance. Documentation

% aws ecs put-account-setting-default --name awsvpcTrunking --value enabled --region us-west2

5. Use an ECS optimized AMI: Documentation
6. Python 3 and pip 3 installed. 

Part 1: Replicate the Fargate services as EC2 services 

The below script will automatically import and replicate all current running Fargate services in a specified ECS cluster to EC2 services managed by Spot’s ECS integration with Ocean.

The script starts off by parsing through every Fargate-defined security group and will add all existing rules to a new single security group. This is required if you have more than five security groups as only five security groups are permitted to be attached to a single EC2 instance. After the creation of the new security group, a new Ocean ECS cluster will be created in the Spot SaaS platform. Lastly, the script will begin to replicate all Fargate services by creating a new task definition and new EC2 service.

1. Download spot_ecs_fargate.py and requirements.txt from: https://github.com/spotinst/spotinst-examples/tree/master/Utilities/AWS/Ocean/ECS
2. Run:
   % pip install –r requirements.txt

   
3.  View the help documentation to view all of the required arguments:

% python3 01_ecs_create_ocean_import_fargate.py import-fargate –help

Usage: 01_ecs_create_ocean_import_fargate.py import-fargate
           [OPTIONS]

  ## The script will gather all services and do the following: ## 1) Describe
  all services within specified ECS cluster ## 2) Gather all SGs for each
  service ## 3) Create new Master SG ## 4) Copy all rules from existing SGS
  into master SG ## 5) Create a Spot Ocean Cluster ## 6) Copy/Import all
  fargate services into EC2 services (This does not remove/delete original
  fargate services) ## NOTE: Please use at your own discretion. Not
  responsible for any damage or accidental deletion of AWS infrastructure.

-a, --account_id=STRING.
Spot Account ID

-t, --token=STRING
Spot.io Token

-e, --ecs_cluster=STRING
Spot Account ID

--sg_name=STRING
Name for the security group that will get created.

--sg_description=STRING
Description of the newly created security group.

-r, --region=STRING
Region code (ie. us-west-2)

-v, --vpc=STRING
VPC ID

-s, --subnet_ids=STRING
List of subnets ids. Syntax ‘[“subnet123456789”,”subnet123456789”]’

--iam_instance_role=STRING
This is the instance profile for the AWS ecsInstanceRole. The instance profile arn EX: arn:aws:iam:123456789:instance-profile/ecsInstanceRole. Documentation

--ecs_ami=STRING
ECS Optimized AMI. Can be retrieved here

--profile=STRING
AWS Profile Name (Optional)

--access_key=STRING
AWS access key (Optional)

--secret_key=STRING
AWS secret key (Optional)

--session_token=STRING
AWS session token (Optional)

--help display this help and exit

4. Run the script using:

% python3 py import-fargate [OPTIONS]

5. Outputs:

1. Security Group ID
2. Ocean Cluster ID
3. Migration Status

Part 2 (Optional): Rename the EC2 Services that were replicated and delete the original Fargate services.

The goal is to automatically delete the existing Fargate services and rename the new EC2 services to keep the same naming convention as the original Fargate services. During the import process, a prefix is added to all the imported services because AWS will not allow two services with the same name. This script is optional and not required as one can scale the existing Fargate services to zero and use the newly imported services from part 1.

This process will scale down the original Fargate services to zero and delete them. After deletion, the script will re-create the services with the exact same name but using the new task definition for a launch type of EC2. Once the new services are created, we will delete the migrated services with the prefix so that you will have the same number of services and tasks prior to starting the migration.

View the help documentation to view all the required arguments:

% python3 spot_ecs_fargate.py rename-fargate –help

Provide flags for required arguments and run the script.

Run the script using:

% python3 spot_ecs_fargate.py rename-fargate [OPTIONS]

Output:

% python3 spot_ecs_fargate.py rename-fargate -e Steven-ECS -r us-west-2

sfm-steven-1
steven-1
Updating original Fargate service to Zero: steven-1
Stopping task: Steven-ECS/63d5f0f534d54a9e9e524000821f5a67
Stopping task: Steven-ECS/f0a7c67a1557400d84e54bb615bf0c7c
Deleting original Fargate service: steven-1
Creating EC2 Service: steven-1
Deleting Migrated SFM Service: sfm-steven-1
Completed

Now that you’ve completed the import and rename process, you can start leveraging Ocean. Please visit our documentation to learn more.