[reciping] ECS(EC2, Fargate)로 백엔드 애플리케이션 배포하기 + 기본 EC2배포까지 (1)

※ 기존에 기록해둔 노션 글을 옮겨적은 것으로, 노션 템플릿에 맞게 적게된 글이라 해당 링크를 통해 더 가독성있게 보실 수 있습니다.

https://www.notion.so/ECS-EC2-Fargate-EC2-2690661ce6288002b649e41cce173d12

ECS(EC2, Fargate)로 백엔드 애플리케이션 배포하기 + 기본 EC2배포까지 | Notion

---

ECS - ECR 세팅과정을 담았습니다. CICD 적용 전이라 나중에 조금씩 세팅이 바뀔 수 있습니다.

 

1. 각각에 넣을 보안그룹 생성하기( ALB, Gateway Server, ECS )

ELB에는 NLB와 ALB 등이 있는데 ALB를 선택한 이유는 한 번 따로 찾아봐주시길 바랍니다! 외부 클라이언트 → ALB 요청을 조건에 따라 허용하는 보안그룹을 설정하겠습니다.

전체적인 흐름은 다음과 같습니다.

[클라이언트]
   ↓ 443
[ALB] ───── SG A ───────▶ 포트 8090
   ↓
[게이트웨이 EC2] ───── SG B ─────▶ 포트 8080–8093
   ↓
[ECS 서비스들] ───── SG C

 

1-1) ALB 보안그룹 생성

원래는 위와 같이 인바운드만 HTTP, HTTPS, 0.0.0.0/0으로 열어주고 보안 그룹 생성 클릭하나, 우리는 특별한 상황(게이트웨이 서버가 존재)이니 아웃바운드 규칙을 게이트웨이 서버 보안그룹과 연결해줍니다. → 일단 수정할건데 이렇게 두기( 인바운드도 나중에 프론트 배포 후, cloudfront IP만 허용하는 걸로 바꿀 거임 )

ALB용 보안 그룹 생성 완료

1-2) Gateway server 보안그룹 생성

Gateway server용 보안그룹은 ALB → Gateway server의 통신을 허용하는 역할이라서 ALB 보안 그룹에서 오는 트래픽만 허용하겠습니다.

일단 인바운드는 alb에서 들어오니까 이렇게 설정해놓고 아웃바운드는 ecs 보안그룹 만든 후에 다시 세팅할 것입니다.

+)

+) 추가로 gateway에 bastion서버를 통해 jar파일 배포하고 싶으면 인바운드로 아래와 같이 추가 필요!

 

💡 왜 80이 아니라 80XX(ex : 8090)를 쓰는 이유

: 운영 환경에서의 역할 구분과 포트 충돌 방지를 위해서 씁니다.

포트 번호 용도 설명

80번	공식 HTTP 표준 포트	브라우저가 기본으로 연결함 (http://example.com)
443번	공식 HTTPS 표준 포트	TLS 기반 HTTPS
80XX번	개발용/비표준 HTTP 포트	앱 내부 통신, 리버스 프록시 뒤의 서버 등

⇒ 80포트는 ALB에서 이미 점유하고 있어서 게이트웨이나 내부 서버에서는 내부 포트를 따로 둬야 함

⇒ 서비스 간 내부 라우팅은 명시적으로 포트 분리를 선호합니다.

예) 게이트웨이 → user-service: 8081, 게이트웨이 → recipe-service: 8082..

→ 이렇게 포트를 나눠야 서비스별 라우팅이 명확합니다.

[ 우리 서버 포트 참고 자료 ] 레시핑 서비스별 포트번호 정리

 

1-3) ECS 보안그룹 생성

ECS용 보안그룹은 Gateway Server → ECS Task의 통신을 허용하는 역할이라서 Gateway Server 보안 그룹에서 오는 트래픽만 허용하겠습니다.

인바운드는 우리 띄워진 서버들 열어줍니다. 보안 그룹 생성 클릭

ECS용 보안 그룹 생성 완료

 

1-4) alb, gateway 보안 그룹 다시 수정하기

alb 보안그룹 선택 후, 아웃바운드 규칙 편집 클릭

원래 있던 아웃바운드 규칙 삭제 클릭 후, 규칙 추가 클릭, 해당과 같이 입력 후 규칙 저장 클릭

alb 보안그룹 수정 완료

마찬가지로 ecs 보안그룹도 원래 있던 아웃바운드 규칙 삭제 클릭 후, 규칙 추가 클릭, 해당과 같이 입력 후 규칙 저장 클릭

gateway 보안그룹 수정 완료

 

결과 :

보안그룹	인바운드	아웃바운드
ALB (A)	80/443 from 0.0.0.0/0(cloudfront 적용하면 수정할 것임)	To Security Group B
Gateway (B)	8080 from SG A / SSH from SG bastion	To SG C
ECS (C)	8080 from SG B	외부 통신용 (S3 등) or 제한 가능

---

 

2. ALB에 붙일 대상그룹 생성하기

대상 그룹 생성 클릭

ALB의 트래픽을 게이트웨이 서버 인스턴스로 연결하니 반드시 인스턴스로 대상 유형을 선택합니다.

• [ 프로토콜 : 포트 ] : (1) HTTPS는 ALB가 처리하고 여기선 내부 통신이므로 HTTP 선택 (내부통신은 HTTPS 불필요, ALB가 SSL 처리함) (2) 게이트웨이 서버 내부 포트인 8090 추가
• [ 프로토콜 버전 ] :

버전	설명	사용 추천 상황
HTTP1	대부분의 Spring, Express, Nginx 서버는 기본적으로 HTTP/1.1	현재 환경에 가장 안정적
HTTP2	요청 다중화 지원. 하지만 서버가 지원 안 하면 연결 실패	Spring Boot, Nginx 기본은 HTTP1을 씁니다.
gRPC	gRPC 프로토콜 전용	일반 HTTP 서비스에서는 사용하지 않음

(1) 게이트웨이 서버가 HTTP로 응답하니 HTTP 로 설정 (2) ALB가 트래픽 보내는 포트(=8090)으로 검사하니 트래픽 포트 클릭

(3) 기본값으로 가져가기(실무에서는 간격을 10초로도 가져간다고는 하네요)

태그 추가후, 다음 클릭

인스턴스 선택하라고 하는데 일단 넘기고 그냥 만들어서 비정상이 뜨는 것인데요. 나중에 연결할 겁니다.

---

 

3. HTTPS 연결을 위한 ACM 인증서 발급하기

CloudFront, ALB, API Gateway 등을 사용하는 AWS 네이티브 아키텍처일 때 ACM(=SSL인증서)을 씁니다. HTTPS는 암호화된 통신이라 브라우저가 https://api.reciping.kr로 접속하면, "SSL Handshake"라는 걸 하면서 ACM을 통해 “정말 reciping.kr 도메인을 너가 소유한 거 맞는지” AWS가 검증해야 하기 때문에 씁니다. 이것은 자동으로 인증서를 갱신하고 콘솔이나 테라폼으로 관리도 가능하며, AWS 서비스들과 연동이 편하고, 인증서 프라이빗 키가 AWS 내부에서만 저장되어서 보안성이 높습니다. 그리고 퍼블릭 인증서는 공짜입니다.

3-1) 인증서 발급하기

퍼블릭 인증서 요청 (공용 인증서) 선택

(1) 전체 커버용 와일드카드 인증서 *.reciping.kr 적기 → www.reciping.kr, admin.reciping.kr 등등..다 가능 (2) 와일드 카드 적용 안 되는 reciping.kr 적기(선택) (3) 키 알고리즘은 RSA 2048 선택 → 이건 다 호환되고 가장 보편적이라 많이 사용(나머지는 미지원 가능성과 성능부담 존재)

ACM 인증서 생성 완료

 

3-2) Route 53에 DNS 레코드 추가하기

Route 53을 통해 도메인 소유자임을 DNS로 인증하는 과정

CNAME 이름, CNAME 값 부분 기억해두세요! → route53에 붙여넣을 것입니다.

Route53에서 만든 reciping.kr 클릭 후, 레코드 생성 클릭

레코드 이름 에 ACM( CNAME 이름 ) 붙여넣기, 값 에 ACM( CNAME 값 ) 붙여넣기 후, 레코드 생성 클릭

레코드 발급 완료

ACM으로 다시 돌아가면 상태가 발급됨 으로 바뀐 것을 알 수 있음