Support progressive delivery for ECS apps using Service Discovery

[khanhtc1202]

What would you like to be added:

Support ECS apps progressive delivery using only ECS components (without ALB configuration)

Why is this needed:

Currently, to perform progressive delivery for ECS applications, we need users to prepare ALB targetgroups. For some usecases, users' tasks may not directly accept/handle traffic from the ALB but via other tasks/components which leads to the inability to perform progressive delivery strategies.

[khanhtc1202]

An idea for this is using 2 services that are configured using the same service registry id, one for the primary tasks and one for the canary tasks. Then tasks of those services will be treated as the same service to other components of users system. 💡

[t-kikuc]

@khanhtc1202

Hi, I have a question.

For some usecases, users' tasks may not directly accept/handle traffic from the ALB but via other tasks/components

Could you give me some examples of such cases?
(Directly calling ECS APIs or IP addresses or something? From where?)

I understand the current flow of canary deployment for ECS with ALB and target groups,
but I'd like to clarify what problem to solve.

[t-kikuc]

I understand the current flow of canary deployment for ECS with ALB and target groups,
but I'd like to clarify what problem to solve.

Thank you for the explanation.
I'll investigate the Service Discovery feature of ECS.
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-discovery.html

[t-kikuc]

I share my current situation of consideration.

I think this case assumes currently using ECS Service Discovery, not ECS Service Connect or App Mesh.

There can be three ways which solve the problem, though I'm not sure all of them are possible yet.

1. Enhance ECS Service Discovery - manipulate Route53??
2. Use ECS Service Connect - a young feature.
3. Use App Mesh - Possible but complicated.

Besides, I'm wondering which is simpler, option-1 or option-2, if both are possible.

[khanhtc1202]

@t-kikuc If (2) and (3) are not promising, let's focus on (1). But I don't really understand why we need to manipulate Route53 for that 🤔

AFAIK we can create a copy of the current primary service A (call A') with desiredCount value set to the number of the canary variant's workloads/tasks and use the same serviceRegistryID with primary service A.

In that case, the CloudMap service would ensure that traffic to serviceRegistryID will be routed to both A and A' and we can use that to perform progressive delivery approach, wdyt?

[t-kikuc]

@khanhtc1202

AFAIK we can realize Blue/Green deployment without difficult configurations of Route53,
but Canary --with strict percentage control-- might be difficult.
For instance, when service A has 2 tasks, how can we route traffic to A' for 20%?
Or strictness is not required?

So I'm trying to find out how to use the Weighted Routing of Cloud Map.
(ECS Service Discovery uses Cloud Map in the back, and Cloud Map uses Route53 in the back.)

[khanhtc1202]

@t-kikuc in canary deployment strategy pattern, we don't need strict set how many percent route to primary/canary variant, just keep same input route and ensure the number of variants fit percentage, traffic would be forwarding in required percent if the number of requests is enough 👀

[t-kikuc]

@khanhtc1202
Here's the PR of RFC for this issue, including designs:
#4676