ECS 생성
태스크 정의로 서비스 생성
이제 대망의 ECS 서비스를 생성할 차례네요.
전에 설정한 태스크 정의대로 서버를 생성합시다.

EC2를 사용하여 시간만큼 결제하는 것이 아닌, 사용한 만큼만 낼 것이므로 서버리스 FARGATE를 사용할 것입니다.
그렇기 때문에 용량 공급자는 그대로 FARGATE를 사용하면 됩니다.
참고로 FARGATE_SPOT는 FARGATE와 거의 유사하지만 할인을 70~80% 해주는 것입니다.
하지만 사용자들이 AWS FARGATE 서버에 요청을 많이 할 경우 서버를 빌려가므로 서버가 다운될 수 있으므로 선택하지 않습니다.

배포 구성
아래와 같이 서비스 이름을 적어주고, 같은 복제본의 태스크 수를 정해줍니다.
기본은 1로 되어있는데, 무중단 CI/CD를 하기 위해선 최소 2개가 필요해요.
저는 비교적 많은 트래픽을 안정적으로 처리하기 위해 태스크를 3개로 두었습니다.

배포옵션
그 후 배포 옵션에서 롤링 업데이트를 선택 후 최소 3개, 최대 6개가 실행될 수 있도록 비율을 조절합니다.

네트워킹
많이 중요한 네트워킹 부분입니다.
로드밸런서 생성했던 때를 기억하실까요?
기본적으로 모든 가용영역의 서브넷을 적용시켜두는데, 우리는 로드밸런서 설정 글에서 로드밸런서의 가용영역을 2a, 2c만 선택했었습니다.
ECS와 로드밸런서의 가용영역과 서브넷이 일치하지 않으면 로드밸런서에서 전송해도 ECS가 받지 못하겠죠?
그러므로 이를 맞추어 이전 로드밸런서와 같이 2개라면 똑같은 2개를 선택하시고, 더 많이 분산시키고 싶으시면 4개 다 사용하시면 됩니다.
ECS는 서비스 생성시에 이렇게 네트워킹 선택이 가능하지만 생성 후에는 네트워킹 수정이 불가능합니다. (CLI로는 가능하긴 해요 ^^..)
로드밸런서는 네트워킹 수정이 가능하긴 하지만 웬만하면 처음에 로드밸런서와 ECS 가용영역의 서브넷을 일치시켜 주세요!
로드밸런서는 우리가 만들어뒀던 로드밸런서를 선택하고, 상태 검사 유예기간을 60초로 둡니다.

로드밸런서의 리스너와 대상그룹 연결
그리고 이제 로드밸런서 생성 시에 만들었던 기존 리스너를 그대로 사용합니다.
지금 말고, 아래에서 HTTPS 적용합니다.

배포 성공
그리고 생성하면, 3~5분 정도면 우리의 서비스에 태스크 3개가 배포된 것을 확인할 수 있습니다. 👍👍

도메인의 A레코드 생성과 로드밸런서 연결
이제 Route 53에 배포된 우리의 도메인(여기서는 toychip.click)을 로드밸런서와 연결합니다.
즉 주 도메인(toychip.click), 서브 도메인(http://www.toychip.click, api.toychip.click)에 접속 시 로드밸런서를 통해 우리의 태스크를 연결할 수 있습니다.
하지만 주 도메인을 연결시켜 주는 작업을 우리는 하지 않았습니다.
주 도메인을 연결하는 하는 방법으로는 A 레코드를 생성하는 것입니다.
A 레코드 유형은 DNS(도메인 네임 시스템)에서 가장 기본적이고 중요한 레코드 유형 중 하나로 가장 기본이 되는 레코드입니다.

해당 레코드를 별칭으로 설정 후, 로드밸런서, 서울, 전 글에서 만든 로드밸런서를 선택합니다.
이렇게 A 레코드를 생성하면, 이제 toychip.click으로 라우팅 되었을 때 로드밸런서로 연결되고, 로드밸런서가 분산처리를 해줍니다.

이제 도메인에 접근이 되는 것을 확인할 수 있습니다.

HTTPS 리스너 생성 및 적용
하지만 우리가 원하는 HTTP는 HTTPS로 리다이렉트 시키고, HTTPS를 통해서만 오도록 하는 작업을 하지 않았습니다.
HTTPS 리스너 생성 및 HTTP Redirect 규칙에 대해 생성해 보겠습니다.
이제 HTTPS를 통해서 접근할 수 있도록 아래와 같이 HTTPS 리스너를 생성합니다.

그룹 수준 고정 활성화
이제 HTTPS로 접근 시에만 대상 그룹으로 전달할 수 있도록 설정합니다.

위 설정에 그룹 수준 고정성.. 이거 정말 중요합니다..!!
저는 이것을 몰라 3일 연속으로 3~4시간 자면서 오류를 겨우 찾았습니다.
프로젝트 당시 OAuth 로그인을 구현했는데, 10번 중 3~4번만 로그인이 성공하고, 나머지는 안 되는 기이한 오류를 발견했습니다.
OAuth로 로그인하는 경우 OAuth 공급자(Naver, Github 등)에서 리다이렉트 하게 됩니다.
오류가 났던 이유는, 요청을 한 태스크와 그렇지 않은 태스크 2개 중 하나로 리다이렉트 되어 서로 다른 프라이빗 네트워크로 이동되어 OAuth 인증이 실패했었습니다.
다른 태스크로 이동될 확률이 66% 이기 때문에 3~4번만 로그인을 성공했던 것이었습니다.
그러므로 그룹 수준 고정성을 필수로 해줘야 합니다.
보안 리스너 설정
HTTPS 리스너이기 때문에 인증서를 선택해야 합니다.
과거에 ACM에서 생성했던 인증서 toychip.click를 선택해서 리스너를 생성합니다.

HTTP Redirect
HTTPS 리스너 생성 후, HTTP 포트는 HTTPS로 리다이렉트 되도록 수정합니다.

생성 후 맵을 보면 아래와 같이 되어있습니다.
HTTP 포트는 HTTPS로 redirect 되고, HTTPS만이 대상그룹을 통해 태스크들에 전달하게 됩니다.

이제 테스트해 보면 성공한 것을 알 수 있습니다.

ECS의 또 다른 장점으로는 바로 강제종료가 아닌, 서서히 자연스레 종료한 후 새로운 버전을 띄워본 후, 에러가 없다면 새로운 버전을 우리가 정한 태스크만큼 자동으로 배포해 준 다는 것입니다.
다음 글에서 마지막으로 GitHub Action을 활용해 CI/CD 파이프라인을 구축해 무중단으로 배포하는 것을 알아보겠습니다.
'Infra > AWS' 카테고리의 다른 글
AWS ECS 무중단 CI/CD Pipeline 5. GitHub Action CI/CD Pipeline 구축 (0) | 2024.02.05 |
---|---|
AWS ECS 무중단 CI/CD Pipeline 3. 로드밸런서와 리스너, 대상그룹 (0) | 2024.02.05 |
AWS ECS 무중단 CI/CD Pipeline 2. Route 53 & ACM 🔥😡🔥 (0) | 2024.02.04 |
AWS ECS 무중단 CI/CD Pipeline 1. ECS 기본 개념, ECR, Task 정의, IAM, CLI (0) | 2024.02.03 |
AWS ECS 무중단 CI/CD Pipeline 0. ECS 배포하게 된 배경 (0) | 2024.02.03 |