AWS 배포자동화 구축 _ 4. ECS 생성 및 ELB 연결 / ECR image 배포

이번 프로세스는 다음과 같다.

- ECS 생성 : Cluster, Service, Task Definition

- ELB 생성 , 연결

- EC2 인스턴스 생성 : Auto Scaling Group

 

---

시작하기 전에 간단히 개념을 정리하고 넘어가자. 

 

1. EC2 : 가상 서버인 EC2 인스턴스를 프로비저닝하고 실행할 수 있습니다. EC2 인스턴스는 가상 컴퓨터로, 다양한 운영 체제와 소프트웨어를 실행할 수 있습니다. EC2 인스턴스는 가상 프라이빗 클라우드(VPC) 내에서 실행되며, 인터넷을 통해 액세스할 수 있습니다.

 

2. Auto Scaling Group : 오토스케일링 그룹은 EC2 인스턴스의 그룹입니다. 이 그룹은 사용자가 정의한 조건에 따라 EC2 인스턴스를 자동으로 프로비저닝하고 조정하여 애플리케이션의 가용성과 확장성을 보장합니다. 예를 들어, 트래픽이 증가하면 오토스케일링 그룹은 필요에 따라 EC2 인스턴스를 자동으로 추가하여 애플리케이션의 성능을 유지합니다. 마찬가지로 트래픽이 감소하면 인스턴스를 자동으로 줄여 비용을 절감할 수 있습니다. 

⇒ 사용자는 예상치 못한 서비스 부하에 효과적으로 대응하고, 최대한 저렴한 비용으로 안정적이고 예측 가능한 성능을 유지할 수 있다.

 

3. ECS (Amazon Elastic Container Service): Amazon Elastic Container Service(ECS)는 AWS에서 제공하는 관리형 컨테이너 오케스트레이션 서비스입니다. ECS를 사용하면 Docker 컨테이너를 실행하고 관리하는 작업을 단순화할 수 있습니다. ECS는 클러스터, 작업 정의, 서비스 등의 개념을 사용하여 컨테이너를 배포하고 확장하는 기능을 제공합니다. 

 

 

---

- EC2와  Fargate 두개의 배포 모델을 지원 !

 

EC2 인스턴스를 사용하는 경우:

• ECS 클러스터: ECS 클러스터는 EC2 인스턴스의 논리적 그룹입니다. 이 클러스터는 컨테이너를 실행할 EC2 인스턴스를 관리합니다. 클러스터는 여러 개의 EC2 인스턴스로 구성될 수 있으며, 각 인스턴스는 컨테이너를 실행하는 호스트 역할을 수행합니다.
• 작업 정의(Task Definition): 작업 정의는 컨테이너화된 애플리케이션의 실행에 필요한 정보를 정의하는 JSON 파일입니다. 작업 정의에는 실행할 컨테이너 이미지, 포트 매핑, 환경 변수 등의 정보가 포함됩니다.
• 서비스(Service): 서비스는 ECS 클러스터에서 작업 정의를 기반으로 컨테이너를 실행하는 데 사용됩니다. 서비스는 컨테이너의 가용성과 확장성을 관리하며, 필요에 따라 자동으로 인스턴스를 추가하거나 제거하여 애플리케이션의 성능과 가용성을 유지합니다.

---

AWS Fargate를 사용하는 경우:

• AWS Fargate: AWS Fargate는 서버리스 컨테이너 실행 환경으로, EC2 인스턴스를 직접 프로비저닝하거나 관리할 필요 없이 컨테이너를 실행할 수 있습니다. Fargate를 사용하면 컨테이너에 할당된 리소스만 지불하면 되므로 더욱 편리합니다. ECS 클러스터와 작업 정의 개념은 EC2 인스턴스를 사용하는 경우와 동일하게 적용됩니다.

 

---

 

4. Load Balancer : 서버에 가해지는 트래픽을 여러대의 서버에게 균등하게 분산시켜주는 역할을 하는 것

서버가 하나일 때 트래픽이 적으면 서버는 무사히 응답을 해줄 것입니다.

하지만 트래픽이 서버 한개로는 감당할 수 없는 양이 되는 순간 서버는 다운될 것이고, 서비스 또한 작동을 멈출 것입니다.

 

이러한 문제를 해결하기 위해서는 크게 두 가지 방법이 있는데요.

서버의 인스턴스 성능을 올리는 스케일-업(Scale-up) 과 서버를 여러대로 나눠서 트래픽을 처리하는 스케일-아웃(Scale-out) 방식이 있습니다. 오늘 포스팅하는 이 로드 밸런서는 바로 스케일-아웃 방식입니다.

그리고 로드 밸런서는 지속적으로  IP주소가 바뀌기 떄문에 도메인 기반으로 사용해야 한다는 특징이 있습니다.

 

장점 )

• 비용 절감
• 무중단 서비스 제공

 

- HTTP, HTTPS 를 이용한 웹 서버를 띄울 것 → ALB

ALB

ALB의 경우는 네트워크 레이어7의 프로토콜에 대한 부하만 처리할 수 있습니다. ELB와 다르게 경로나 포트등에 따라 다른 타겟그룹으로 맵핑할 수 있습니다. 포트 단위로 연결해줄 수 있기 떄문에 도커에서 유용하게 작동할 수 있고 하나의 대상그룹에 더 많은 컨테이너를 넣을 수 있어 비용을 최적화할 수 있습니다. EC2 인스턴스, AWS 람다, IP로도 연결이 가능하고 특정한 요청에 대해서는 서버없이 응답메세지를 작성할 수 있습니다.

 

ELB의 경우 네트워크 레이어 4와 네트워크 레이어7에 대한 부하를 제어할 수 있습니다. 그리고 서버의 기본주소가 바뀌면 로드밸런서를 새로 생성해야하며 하나의 주소에 하나의 타겟그룹으로 보내게 됩니다. 따라서 타겟그룹이 많아질수록 더 많은 수의 로드밸런서가 필요하고 비용도 그만큼 더 들아가게 됩니다.

 

---

1. EC2 인스턴스 SSH 접근을 위한 키페어 생성

EC2 - 네트워크 및 보안 - 키페어 

이름 : ec2-key

 

 

2. ECS Cluster 생성

- 새로운 환경에서는 지원되지 않는 기능이 있어서 기존 콘솔로 전환해준다. 

- 왼쪽 상단에 스위치 버튼을 누르면 된다.

 

- 클러스터 생성

 

2번째 Linux + 네트워킹 선택

 

이름 : ecs-cluster

 

프로비저닝 모델 : 온디맨드 인스턴스 

유형 : t3.medium !!! ( t2는 insufficient memory 에러가 난다고 함. t3.micro도 안되네용. 대신 과금 주의. )

개수 : 2

EC2 AMI ID : Linuxe 2 AMI

볼륨 크기 : 30

키 페어 : ec2-key

 

 

 

- VPC : HLI-VPC

- 서브넷 : Public Subnet 2a / 2b (  private에 EC2를 두는 경우 인터넷 게이트웨이를 타고 나갈 수가 없으므로 NAT를 생성해줘야함. )

- 퍼블릭 IP 자동 할당 : 활성화됨

- 보안그룹 : ecs-ec2-sg

- IAM에 ecsInstanceRole을 갖고 있음

 

생성 완료 !

 

 

 

3. ELB 생성

- 서비스와 작업을 생성해야하는데, 작업 정의에서 로드밸런서를 선택해야하기 때문에 먼저 생성해보자.

- EC2 콘솔 -> 로드밸런서 -> 생성 

 

HTTP, HTTPS 를 이용한 웹 서버를 띄울 것이기 때문에 ALB를 선택한다. 자세한 설명은 위에 개념 부분에 있다 !

 

생성 버튼을 누르면 ELB의 작동 방식도 설명이 되어있다. 

 

이름 : lb-test로 설정

네트워크 매핑에서는 

기존에 계속 선택했던 HLI-VPC 선택, public 서브넷 2개를 매핑 !

이전에 생성해둔 lb 보안그룹 선택 !

-> 리스너에 대해 정의한 규칙에 따라 로드 밸런서가 등록된 대상으로 요청을 라우팅하는 방법이 결정된다고 적혀있다.  수신 리스너에 라우팅하기 위해서는 대상 그룹이 있어야하므로, 아래 파란색으로 되어있는 대상그룹 생성을 눌러준다. 

인스턴스를 선택해주고,

대상 그룹 세팅은 아래와 같이 진행했다.

 

아까 전에 생성한 EC2 인스턴스를 대상으로 등록하기 위해 -> 아래에 보류 중인것으로 포함을 클릭 !

 

대상 그룹 생성 후 다시 로드밸런서 세팅 화면으로 돌아온다.

 

새로고침하면 생성한 대상그룹을 선택할 수 있다.

 

 

4. 작업 정의 ( Task Definition ) 생성

ECS -> 작업정의 -> 생성

이름 : ecs-task-def

역할 : ecsTaskExecutionRole

네트워크 모드 : 브리지

 

아래 컨테이너 추가 버튼 클릭 

이름 : container-test

이미지 : 리포지토리에 있는 이미지 URL 입력

포트매핑 : 호스트 포트 0, 컨테이너 포트 80 

 

작업 정의 생성 완료 !

 

 

 

5. 서비스 ( Service) 생성

클러스터 아래에 서비스  생성 버튼 !

 

서비스 유형 : 

- Replica는 설정한 작업 개수만큼 task를 복제한다는 의미

- Daemon 은 클러스터에 연결된 인스턴스 1개당 하나의 task만 실행한다는 의미

​

 

- Replica , 2 : 등록된 task를 복제 해서 2개의 task를 실행한다는 의미 !

 

 

배포 방식 : 롤링 업데이트

배치 템플릿 : AZ 균형 분산

 

---

 

로드밸런서 연결 -> 로드 밸런서에 추가 버튼 

- 프로덕션 리스너 포트 : 80:HTTP

- 대상 그룹 이름 : 이전에 만들었던 그룹 선택 

 

서비스도 생성 완료 !

 

EC2 콘솔에서 대상그룹에 가보면 ECS-EC2 인스턴스 2개가 연결되어 있고, 포트는 호스트 동적 포트 매핑을 한 것을 볼 수 있따 ! 

( 에페메랄 포트 32768 ~ 61000 대의 임의 포트 )

 

 

6.  배포 되었는지 확인하기 !

서비스 : Replica 유형으로 1개의 서비스가 액티브 상태, 2개의 작업이 실행되고 있음. 

 

EC2 콘솔 -> 로드밸런서 -> 상세에서 하단의 DNS 이름을 복사해서 브라우저에 붙여넣어보자 !

배포가 된 것을 확인할 수 있다 !

 

* 작업 정의 생성시 참고 

 

- 네트워크 모드 옵션에는 브리지, 호스트, awsvpc, none 가 있다. 

 

1. 브리지 : 가상 네트워크 브리지를 사용하여 호스트와 컨테이너의 네트워킹 사이에 레이어를 만듬. 

호스트 포트를 컨테이너 포트에 다시 매핑하는 포트 매핑을 만들 수 있음. 

정적 포트 매핑

정적 포트 매핑을 사용하면 컨테이너 포트에 매핑할 호스트 포트를 명시적으로 정의할 수 있습니다. 위의 예를 사용하여 호스트의 포트 80이 컨테이너의 포트 3000 에 매핑됩니다. 컨테이너화된 애플리케이션과 통신하려면 포트80 로 트래픽을 Amazon EC2 인스턴스의 IP 주소로 보냅니다. 컨테이너화된 애플리케이션의 관점에서 보면 포트 3000의 인바운드 트래픽이 표시됩니다.

 

트래픽 포트만 변경하려는 경우 정적 포트 매핑이 적합합니다. 그러나 이것은 여전히 ​​host네트워크 모드 를 사용하는 것과 동일한 단점이 있습니다. 각 호스트에서 태스크 인스턴스화를 하나만 실행할 수 있습니다. 이는 정적 포트 매핑을 사용하면 단일 컨테이너만 포트 80에 매핑할 수 있기 때문입니다.

이 문제를 해결하려면 다음 다이어그램과 같이 동적 포트 매핑과 함께 bridge네트워크 모드를 사용하는 것이 좋습니다

동적포트매핑

 

포트 매핑에서 호스트 포트를 지정하지 않으면 Docker가 임시 포트 범위에서 사용하지 않는 임의의 포트를 선택하고 이를 컨테이너의 공용 호스트 포트로 할당하도록 할 수 있습니다. 

예를 들어 컨테이너의 3000포트에서 수신 대기하는 Node.js 애플리케이션 에는 Amazon EC2 호스트 47760와 같은 임의의 높은 번호 포트가 할당될 수 있습니다 . 이렇게 하면 호스트에서 해당 컨테이너의 여러 복사본을 실행할 수 있습니다. 또한 각 컨테이너는 호스트에서 자체 포트를 할당할 수 있습니다. 컨테이너의 각 복사본은 3000포트에서 트래픽을 수신합니다 . 그러나 이러한 컨테이너로 트래픽을 보내는 클라이언트는 임의로 할당된 호스트 포트를 사용합니다.

포트 매핑에 호스트 포트 0과 컨테이너 포트 80의 의미

→ 네트워크 모드 : 브리지

→ 호스트와 컨테이너 사이에 네트워킹을 위한 레이어를 만들고, 호스트 포트를 다시 컨테이너 포트로 매핑하는 포트매핑을 만드는 방식.

호스트 포트를 0( 없음 )으로 지정하면 컨테이너의 호스트 포트가 동적으로 생성됨

이러한 동적 포트 매핑을 사용할 경우, 에페메탈 포트 ( 32768~ 61000) 범위의 포트가 자동으로 할당되며 이때 alb에 설정 해 놓은 타겟 그룹의 포트는 무시된다.

컨테이너 포트 80은, 호스트로부터 다시 컨테이너 포트로 매핑할때 80에만 매핑하도록 정적 포트 매핑을 설정하는 것을 의미 !!

호스트 포트 : 동적 포트 매핑으로 구성

컨테이너 포트 : 정적 포트매핑으로 구성

2. 호스트 : 호스트 모드를 사용하면 컨테이너의 네트워킹이 컨테이너를 실행하는 기본 호스트에 직접 연결됩니다. 네트워크 모드를 사용 하면 host컨테이너는 기본 호스트 Amazon EC2 인스턴스의 IP 주소를 사용하여 포트 3000에서 트래픽을 수신합니다.

 

이 네트워크 모드를 사용하는 데는 상당한 단점이 있습니다. 각 호스트에서 작업 인스턴스화를 하나만 실행할 수 있습니다. 이는 첫 번째 작업만 Amazon EC2 인스턴스의 필수 포트에 바인딩할 수 있기 때문입니다. host네트워크 모드 를 사용할 때 컨테이너 포트를 다시 매핑할 방법도 없습니다 . 예를 들어 애플리케이션이 특정 포트 번호를 수신해야 하는 경우 포트 번호를 직접 다시 매핑할 수 없습니다. 대신 애플리케이션 구성을 변경하여 포트 충돌을 관리해야 합니다.

 

3. awsvpc:

awsvpc네트워크 모드에서 Amazon ECS 는 각 작업에 대한 ENI(탄력적 네트워크 인터페이스)를 생성 및 관리하고 각 작업은 VPC 내에서 자체 프라이빗 IP 주소를 받습니다. 이 ENI는 기본 호스트 ENI와 별개입니다. Amazon EC2 인스턴스가 여러 작업을 실행하는 경우 각 작업의 ENI도 분리됩니다. 

 

앞의 예에서 Amazon EC2 인스턴스는 ENI에 할당됩니다. ENI는 호스트 수준에서 네트워크 통신에 사용되는 EC2 인스턴스의 IP 주소를 나타냅니다. 각 작업에는 해당 ENI와 개인 IP 주소도 있습니다. 각 ENI가 분리되어 있기 때문에 각 컨테이너는 80태스크 ENI의 포트에 바인딩할 수 있습니다. 따라서 포트 번호를 추적할 필요가 없습니다. 80대신 작업 ENI의 IP 주소에 있는 포트로 트래픽을 보낼 수 있습니다 .

 

4. 없음 : 포트 매핑 불가 , 외부와 연결 X

 

 

* 참고 : 배포 전략 - Rolling, Blue/Green, Canary

1. Rolling

• Rolling 배포는 서버를 한 대씩 구 버전에서 새 버전으로 교체해가는 전략이다. 서비스 중인 서버 한 대를 제외시키고 그 자리에 새 버전의 서버를 추가한다. 이렇게 구 버전에서 새 버전으로 트래픽을 점진적으로 전환한다. 이와 같은 방식은 서버 수의 제약이 있을 경우 유용하나 배포 중 인스턴스의 수가 감소 되므로 서버 처리 용량을 미리 고려해야 한다.

2. Blue/Green

• Blue/Green 배포는 신 버전을 배포하고 일제히 전환하여 모든 연결을 신 버전을 바라보게 하는 전략이다. 구 버전, 신 버전 서버를 동시에 나란히 구성하여 배포 시점에 트래픽이 일제히 전환되며 빠른 롤백이 가능하고, 운영환경에 영향을 주지 않고 실제 서비스 환경으로 신 버전 테스트가 가능하다. 단, 이런 구성은 시스템 자원이 두배로 필요하여 비용이 더 많이 발생한다. 

3. Canary

• 'Canary'라는 용어의 어원을 알면 이해가 더 쉽다. Canary는 카나리아 라는 새를 일컫는 말인데, 이 새는 일산화탄소 및 유독가스에 매우 민감하다고 한다. 그래서 과거 광부들이 이 새를 옆에 두고 광산에서 일을 하다가 카나리아가 갑자기 죽게 되면 대피를 했다고 한다. Canary 배포는 카나리아 새처럼 위험을 빠르게 감지할 수 있는 배포 기법이다. 지정한 서버 또는 특정 user에게만 배포했다가 정상적이면 전체를 배포한다. 서버의 트래픽의 일부를 신 버전으로 분산하여 오류 여부를 확인할 수 있고, 이런 전략은 A/B 테스트가 가능하며, 성능 모니터링에 유용하다. 트래픽을 분산시킬 때는 라우팅을 랜덤하게 할 수 있고, 사용자로 분류할 수 있다. 

 

[요약]

 

- Blue/Green: 테스트해보고 트래픽을 한번에 전환함. 롤백이 빠름

   - 동일한 양의 instance로 이루어진 새로운 Server Group을 생성

   - 신규 Server Group이 정상상태가 되면 LB는 신규 Server Group에 트래픽을 분산함. 

   * Blue 구역은 실제 운영서버이고, Green 구역에서 신규버전 테스트를 하고, 문제가 없으면 Blue 구역에 향하던 Request 를 Green 구역으로 향하게함. 그러면 이제 Green 구역이 실 운영서버가 되고 Blue 구역은 테스트서버가 됨. (구역 swap)

- Rolling: Blue/Green 과 동일하나 단, 인스턴스별 또는 그룹별로 Rolling

- Canary: 트래픽을 분산시켜 전환함

   - 가장 작은 개수의 인스턴스를 교체시키고

   - 새로운 버전으로 트래픽을 분산시킨다 (1~5%)

   - 새로운 버전에 이슈가 없을때까지 테스트를 진행하고

   - 특정시간까지 이슈가 없으면 배포를 늘려간다.