ECS 의 Task 업데이트 속도 문제

[섹션 10 - Self-healing! - 죽은 서버(테스크) 자동으로 살려내는 AWS ECS service 알아보기] 강의에서

Task 의 RollingUpdate 하는 모습과 health check 에 의한 Task 소멸 및 생성 모습을 보여주셨는데요.

ECS 의 Task 소멸 및 생성 속도가 너무 느려서 놀랐습니다.

집에서 Kubernetes 로 실습해본 경험에 의하면, K8S 에서는 3초면 되는 것이, ECS Fargate 에서는 3분이 걸리는 것 같은데요.

원래 ECS 의 Fargate launch type 이 아주 느린 것인가요?

ECS 의 EC2 launch type 이었다면 Fargate 보다는 조금 빠른지요? 로컬에서 돌리는 Kubernetes 만큼 몇초만에 수행을 완료할 정도로 빠르게 하는 방법은 없는지요?

ECS 너무 느려서 이걸 써야 되나라는 실망스런 마음이 큰데요.

반응 속도가 빠른 auto scailing 을 구현하려면, 직접 K8S 쓰는 것이 더 현실적인 방법인 것인지 고민이 됩니다.

이건 ECS의 문제가 아니고 Fargate를 쓰느냐 EC2 같은 VM을 쓰느냐 차이에요. 배포 시간이 다소 느려져 보이지만 serverless fargate의 장점이 전 더 크다고 봅니다.

쿠버네티스로 하면 당연히 빨라요. 이미 여유 서버 리소스를 부여한 상태자나요(EC2로 한것과 동일한 설정)? 쿠베에서 클러스터를 만드실 때 노드를 보통 여유 있게 설정합니다. 예를 들어 3개의 컨테이너만 돌릴거지만 9개의 컨테이너까지 돌릴 수 있도록 여유 있게 노드를 설정했다고 생각해보죠. 그러면 9개까지는 사실상 즉시 scale up이 됩니다. 이미 리소스가 확보되어 있으니깐요. 하지만 그 이상 scale 해야한다면? 그 때는 클라우드에서 쿠베 설정하실 때 노드를 최대 몇개까지 확장 가능하도록 설정을 하실건데요. 이 노드가 추가 되면 비슷하게 느려집니다. 노드를 돌릴 새로운 VM을 확보하는거니깐요.

그런데 잘 생각해보면 빠르게 auto scale이 되기 위해서는 결국 노드에 여유 리소스를 확보해둬야 하자나요? 이건 autoscale 개념과 모순되는 행위입니다. 컨테이너가 안돌아갈뿐 리소스 비용을 내고 있자나요. auto scale을 하는 목적이 애초에 비용 최적화란 말이죠. 즉, 여유 리소스 환경에서 auto scale이 이루어지는건 일반적으로 큰 의미가 없습니다.

EC2 launch type을 이용하게 되면 주어진 리소스 안에서는 빠르게 배포가 됩니다. 그런데 개발할 때야 3분이면 개발 못할정도로 너무 길지만 일반적으로 배포할 때 이정도 시간 차이는 큰 의미가 없어요. 어짜피 테스트 코드 돌리고 프러덕션 빌드 등등 하면 이정도 시간을 먹게 되죠.

하지만 상황에 따라서 이런 이점은 있을 수는 있어요. micro service들을 돌리는데 서비스 A에 부하가 많이 갔다가 B로 부하가 넘어갔다. 예를 들어 A 컨테이너를 10개에서 3개로 줄이고 B를 3개에서 10개로 늘리고. 이런식으로 주어진 리소스 안에서 컨테이너들이 자주 교체되면 EC2 launch type을 고려해볼 수 있어요. 하지만 MSA를 하더라도 경험상 이렇게 부하가 한쪽에서 다른 쪽으로 넘어가는 경우는 극히 드물어요. 보통은 비례합니다. 예를 들어 A가 컨테이어 3개 필요할 때 B는 1개면 된다. A가 부하를 많이 받아서 9개 되면 B는 어느정도 비례해서 3개 정도이면 되는거죠. 즉, scale up할 때 보통 모든 서비스들이 scale up하고 scale down할 때는 보통 모두 같이 내려가요. 즉, 주어진 리소스 안에서 서비스끼리 리소스가 왔다갔다 하는 경우는 매우 드뭅니다. 만약 이런 예외라면 EC2 launch type을 고려할 수 있을듯 해요. 하지만 VM은 관리포인트가 늘기도 하고 실무적으로 이런 경우는 드물기 때문에 전 왠만하면 fargate를 쓸듯합니다.

인프런 커뮤니티 질문&답변