[AWS] ECS 구성하기 전에 용어 정리하기

오늘은 대망의 서버리스 모델인 ECS를 구성해보는 글을 작성해보고자 합니다. 그간 EC2만 사용하면서 내부 서버에 Docker Compose 세팅과 스크립트를 작성하고 Jenkins에서 빌드 배포한 부분을 더 개선해보고자 하여 이 글을 작성하게 되었고, ECS를 구성하면서 서버리스 모델인 Fargate 까지 같이 사용해보고 싶었던 취지가 있었습니다. 

그러면 구성을 하기 이전에 ECS가 어떤 것인지 먼저 알아야합니다. 정리를 하려고 보니 사전에 알아야할게 꽤 많아서 조금 지루하실 수도 있을 것입니다. 그치만 하나같이 중요한 것들이기도 하고 최대한 읽어보았을 때 알기 쉽게 해석하고자 설명을 적고, 저도 그러면서 다시 공부를 하기 위해 적었습니다 🙏

 

ECS의 정의 

Elastic Container Service라고 해서 클러스터에서 컨테이너를 쉽게 실행 및 중지할 수 있는 컨테이너 관리 서비스입니다. 말만 들어보면 마치 쿠버네티스와 비슷한 구조입니다. 실제로 작동 원리도 유사하지만 쿠버네티스의 러닝 커브는 익히 들어 알고 있고, 구성하는 것부터 만만치 않은 인력과 시간이 들어갑니다. 그래서 아마존에서는 컨테이너 관리를 용이하기 위해 ECS라는 서비스를 만들게 되어 개발자들이 들어가는 시간과 비용을 절약해줍니다. 

아래는 공식 문서입니다. 

https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/Welcome.html

Amazon Elastic Container Service란 무엇입니까? - Amazon Elastic Container Service

 

ECS 구성을 위해 알아야할 것 

ECR

Elastic Container Repository 의 약자로 이전에 소개드린 글에서 작성되어 있지만, 짧게 얘기하면 Docker Image 저장소입니다. 원격에 저장한 이미지 저장소에서 컨테이너에 올릴 이미지 파일을 관리합니다. 예를 들어 Next.js, Spring으로 되어있는 프레임워크이거나 Node.js 서버 등을 컨테이너에 올릴 수 있는 이미지로 만든 것을 담아두는 원격 리포지토리입니다.

 

Cluster

클러스터는 ECS(Elastic Cluster Service)의 용어에 들어가는 것만큼 필수적인 요소입니다. 여기서는 태스크와 서비스에 대한 내용도 같이 알고있어야 하는데, 이 두개의 그룹핑을 담당하고 리소스를 관리할 수 있는 인프라와 같은 개념입니다. 그리고 클러스터 내에서는 EC2(서버)나 Fargate(서버리스)에 대한 오토 스케일링을 설정할 수 있습니다. 보다 자세한 내용은 아래에 나와있습니다. https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/clusters.html

Amazon ECS 클러스터 - Amazon Elastic Container Service

 

Task

ECS에서 Docker 컨테이너를 실행하기 위해 작업의 단위인 내용을 태스크라고 합니다. 태스크에서는 각 컨테이너에서 사용할 CPU와 RAM, 내부 서버의 용량을 선택할 수 있습니다. 즉, EC2의 인스턴스 유형을 정할 수 있습니다. 또, 사용할 서비스의 포트와 로드밸런서를 선택하여 로드밸런싱을 어떻게 하여 서버를 몇 대로 스케일 업을 할지 정합니다. 그리고 애플리케이션이 컨테이너에서 제대로 부팅이 되지 않았거나, 문제가 발생하였을 때 종료를 시킬지 아니면 새로운 인스턴스로 재기동을 시킬 지 설정할 수 있습니다.  태스크에 대한 보다 자세한 설명이 공식 문서로서도 존재하네요. https://docs.aws.amazon.com/ko_kr/AmazonECS/latest/developerguide/task_definitions.html

Amazon ECS 태스크 정의 - Amazon Elastic Container Service

 

Service

태스크를 관리하고 어떤 방식으로 잘 돌아가는지 로그를 표시해주고, 태스크가 구성되어 현재 배포가 잘 되어있는지 확인할 수 있습니다. 태스크를 기반으로 ECR의 이미지가 잘 배포가 되었는지 로그를 보여주고, 로드 밸런서를 작동시켜 2개 이상의 서버를 유지할 때 어느 정도까지 배포가 되었는지도 확인이 가능합니다. 예를 들어, 로드 밸런싱을 4개의 서버로 같이 진행을 할 때 2개의 서버가 배포가 완료되었고, 1개의 서버가 배포 실패, 그리고 나머지 서버 1대는 배포 이전의 상태이라면 '2개 실행 중 | 1개 대기 중 | 1개 필요'와 같이 현재 서비스의 상태를 표시해줍니다. 즉, 로드 밸런서의 상태를 보여줍니다.

그리고 서비스 전체를 보았을 때 현재 CPU를 어느 정도 사용하고 있고, 서비스에서 메모리는 어느 정도 점유하고 있는지 실시간 체크가 가능합니다. 

 

CloudWatch (중요)

Fargate 의 경우 서버리스 모델이기 때문에 서버로 접속할 수 있는 커널이 존재하지 않습니다. 그래서 애플리케이션이 구동된 로그와 logback에서 작성된 로그 정책을 보기 위해 CloudWatch로 접근하여 볼 수 있습니다. 

사실 실제 운영중인 서버의 로그를 보고 버그를 잡는 것은 굉장히 중요한 부분중에 하나입니다. 그래서 저는 이 글을 꾸준히 작성하면서 로그를 보는 방법까지도 제시하고자 합니다. 현재 용어 설명을 하기 때문에 우선은 매듭을 짓고 다른 글에서 더 작성을 해볼 예정입니다. 

태스크를 작성하면서 CPU 사용량과 메모리 사용량 또는 유휴상태에 따라 경보 트리거를 걸 수도 있습니다. 이것 또한 CloudWatch의 역할입니다. 특정 리소스 양이나 조건에 도달하였을 때 AWS Lambda라고 하여 함수를 호출시킬 수도 있습니다. 보통 장애 전파를 CloudWatch를 기반으로 트리거를 걸 때도 많습니다. 

 

Load Balancer

로드 밸런서는 하나의 아이피에서 여러 개의 서버에 연결되어 있는 1:N 구조의 브릿지 역할을 하는 서비스입니다. 로드 밸런서는 각 서버로 인터셉트해주는 트래픽의 양을 고르게 전달할 수도, 사용자 설정에 맞게 비율을 조정해서 1:3의 가중치를 두게 해서 트래픽을 분산시킬 수도 있습니다. 

로드 밸런서를 쓰는 큰 이유중에 하나는 트래픽을 조절할 수도 있는 것이 있지만, 2대 이상의 서버 중에 1대의 서버가 장애가 난 경우 장애가 난 서버로 요청을 보내지 않는 역할을 해주기도 합니다. 2개의 요청중에 1개가 실패가 된다면 사용자는 사용도중에 이상하게 생각할 수도 있기 때문에 로드 밸런서는 이를 제어하는 역할도 합니다. 

 

Target Group

타겟 그룹은 대상 그룹이라고도 불리우며 로드밸런서에 연결된 목표 객체들을 의미합니다. 로드 밸런서로 서버의 부하를 조절한다면, 대상 그룹은 로드 밸런서로 들어온 트래픽을 서버 내부에서 어떤 포트로 라우팅할지 정해주는 요소입니다. 주로 ECS에서는 배포 명령이 떨어지면 Health Check를 수행하게 되는데 이 때 사용되는 것이 대상 그룹입니다. Health Check 이후 정상적인 플래그 (200)이 응답으로 왔다면, 이는 배포가 성공했다는 것으로 간주하여 ECS 관리 하에 정상적으로 작동하는 서비스로 취급됩니다. 

그래서 ECS 세팅을 하면서 아실 정보이긴 하지만 대상 그룹의 이름을 정하고 몇 초 주기로 Health Check를 하여 사용중인 서버가 잘 돌아가는지 꾸준히 감시하는 역할을 합니다. 

 

Route 53 

이 서비스는 이전에 EC2에서 도메인 및 호스팅 관리를 할 때도 자주 사용했던 서비스입니다. ECS에서는 nginx 설정과 같이 따로 하는 것이 없을 수도 있기 때문에 애초에 도메인 세팅을 해주어야 합니다. 도메인 세팅을 진행하면서 우리는 Route 53 에 레코드들을 등록해주는데, 여기에는 네임스페이스 값과 Value 값을 넣어주어 인터넷이라는 네트워크 체계에서 어떤 규칙을 가지고 도메인을 운용할지 관리를 합니다. 

 

ACM (Amazon Certification Manager)

ACM은 HTTP 연결에서는 상관없지만, HTTPS 연결을 사용한다면 필요한 존재입니다. ACM은 아마존에서 발급하는 HTTPS 인증서의 개념이고, 이를 Route 53에 정해진 규칙에 맞춰 등록해주어야 합니다. 

 

먼저 기본적으로 알아야할 개념에 대해 짚어보았습니다. 다음 글에서는 ECS 클러스터를 구성하는 방법에 대해 기술해보고자 합니다.