AWS 배포 과정 정리

AWS 배포 과정 정리

AWS를 통한 서버 배포를 위해 필요한 과정들을 정리해보았다.

EC2

AWS에서 제공하는 가상 서버다.

웹 서버, 데이터베이스 서버 등 여러 용도로 사용할 수 있다.

탄력적 IP

AWS에서 제공하는 고정된 공인 IP 주소다. 탄력적 IP 없이 EC2 서버를 사용하면 서버를 재시작할 때마다 IP가 변경되므로 실사용하기에는 무리가 있다.

프론트엔드 측에서 요청을 보낼 백엔드 서버를 지정해야 할 때, ip 를 통해서 요청을 보낼 경우 탄력적 IP를 사용하지 않으면 ec2 서버의 ip가 변경되어 문제가 발생할 수 있다.

ALB(Application LoadBalancer)와 Route53을 함께 사용하는 경우 도메인을 통해 요청이 들어올 때 ALB가 ec2로 요청을 넘겨주므로 탄력적 ip가 필요없을 수 있다(어쩌면 public ip 까지 사용하지 않을 수 있다 - ec2가 오직 ALB를 통해 요청을 받아들이는 경우).

✅ 그럼 탄력적 IP가 필요한 경우는?

• ALB 없이 EC2 도메인에 직접 연결하는 경우
• 외부 서비스가 특정 IP만 허용하는 경우
• EC2가 외부와 직접 통신하고, 고정된 IP가 필요한 경우

RDS

AWS에서 제공하는 데이터베이스 서비스다.

EC2 서버에서 데이터베이스를 따로 설치해서 운영할 수도 있지만, 규모가 작지 않은 서비스에서는 RDS를 사용하는 것이 좋다. 더 많은 데이터를 저장할 수 있고, 백업 파일 관리 등 데이터베이스를 안정적으로 관리하기 위해 많은 기능을 제공한다.

인바운드 규칙

특정 서비스에 접근할 수 있는 요청의 조건을 설정하는 방화벽 역할

어떤 IP, 어떤 포트와 어떤 프로토콜로 들어오는 트래픽을 허용할지 설정할 수 있다.

서비스마다 다른 인바운드 규칙을 등록할 수 있다.

편하게 쓰자고 아무 ip나 허용해버리면 보안이 취약해질 수 있다.

해당 서비스를 이용하는데 꼭 필요한 인바운드 규칙만 설정하자.

Route 53

AWS의 DNS 서비스 도메인 이름을 IP나 AWS 리소스(ALB 등)의 DNS 이름으로 변환해주는 역할을 한다.

구입한 도메인을 route53을 통해 다른 리소스와 연결할 수 있다. route53 의 호스팅 영역을 생성하고 새로 생성된 NS 레코드에 등록되어 있는 4개의 네임서버를 도메인 사이트에서 등록해준다.

이렇게 하면 해당 도메인으로 요청이 들어올 때, 도메인 사이트를 통해 네임 서버(Route 53)로 요청이 넘어간다.

왜 네임서버의 개수가 4개일까?

• 하나의 네임 서버에 문제가 생겨도 나머지 서버가 처리할 수 있도록 하기 위해서이다.
• 전세계의 사용자가 빠르게 접속할 수 있도록 지리적으로 분산된 서버가 필요하다.

ACM

AWS에서 SSL/TLS 인증서를 생성/관리해주는 서비스

• ALB, CloudFront API Gateway 등에 쉽게 붙일 수 있다.
• 자동 갱신 기능이 있어 편리하다.

DNS 인증 또는 Email 인증 방식으로 인증서를 발급받을 수 있다.

Route53을 사용할 경우 DNS 인증방식을 사용하면 편하다.

ACM을 통해 발급받은 인증서를 ec2 서버에 직접 붙일 수는 없다. ALB 등의 서비스에 붙일 수 있다.

ALB를 사용하지 않을 경우 ACM을 통해 인증서를 발급받지 않고, ec2에서 직접 무료 인증서를 발급받아야 한다. 하지만 이 방법은 인증서를 관리해주지 않기 때문에 갱신, 보안 설정 등을 직접 해주어야 한다.

SSL/TLS 인증서가 필요한 이유

신원 보장을 위해서이다.

HTTPS의 역할은 암호화, 신원 보장이 있다. 접속하려는 서버가 진짜 특정 회사의 사이트가 맞는지 보장해주기 위해서는 SSL/TLS 인증서가 필요하다.

DNS 스푸핑 (DNS Spoofing)

• 공격자가 네트워크 중간에서 네임서버 응답을 가로채서
• kakao.com → 가짜 IP주소 를 응답으로 보내버림
• 사용자 브라우저는 속아서 가짜 IP로 접속하게 됨

→ 이런식으로 DNS를 위조해도 브라우저가 인증서를 보고 판단해서, 해당 도메인과 맞지 않으면 사용자 접근을 차단해서 이러한 보안 문제를 막을 수 있다.

Application Load Balancer(ALB)

트래픽을 여러 EC2에 분산해주는 로드 밸런서 7계층 (HTTP/HTTPS) 로드밸런서

HTTP/HTTPS 요청을 분석하고 URL, 헤더, 쿠키 등의 정보를 바탕으로 요청을 적절한 서버로 분배한다.

• 요청 내용에 따른 라우팅
• 세션 지속성
• SSL 종료
• HTTP 리다이렉션, 리라이트
  • http:// 요청을 https://로 리다이렉션 할 수 있다.

4계층 로드밸런서의 경우 IP 주소와 포트를 기반으로 라우팅해서 보다 간단하고 빠르게 트래픽을 분배하지만, 7계층 로드밸런서에 비해 세밀한 제어는 힘들다.

그리고 앞서 말한 ACM을 ALB에 붙여서 사용하면 다음과 같은 방식으로 https 프로토콜을 사용할 수 있다.

헬스 체크

추가로, ALB는 연결된 인스턴스에 주기적으로 요청을 보내 인스턴스의 상태를 체크한다. 요청할 url 경로를 정하고 해당 url에 대한 응답 상태를 200으로 반환해줘야 한다.

헬스 체크 하는 이유

ec2 인스턴스 하나가 죽었는데 헬스 체크를 하지 않으면 ALB는 계속 해당 인스턴스로 트래픽을 보내게 되고, 사용자게에는 오류 화면이 뜨게 된다.

헬스 체크를 사용하면, 죽은 인스턴스를 체크하고 이 인스턴스를 제외한 나머지 인스턴스로만 트래픽을 분산시킬 수 있게 된다.

#

S3 (Simple Storage Service)

AWS의 파일 저장소 (객체 스토리지)

정적 웹 호스팅, 이미지 저장, 로그 백업 등 용도로 사용된다.

• 거의 무제한 용량, 고가용성
• 정적 웹사이트 호스팅 가능 (HTML, JS만 가능, 서버기능 X)

나는 여기서 S3을 배포 파일 저장, 웹 사이트 이미지 저장 용도로 사용하였다.

외부에서 접근하는 것을 막으려면 퍼블릭 액세스를 차단하는 것을 추천한다.

ec2 를 통해 s3에 접근하거나 IAM 사용자를 통해 s3에 접근할 수 있기 때문에, 나는 퍼블릭 액세스를 차단했다.

Code Deploy

자동으로 코드를 배포해주는 자동화 서비스

appspec.yml 을 통해 배포 전/후에 실행할 스크립트를 지정할 수 있다.

다양한 서비스와 엮어서 사용할 수 있는데, Github Action을 예로 들어 보겠다.

1. Github Action에서 프로젝트를 빌드한 파일을 생성하고 S3에 대한 권한 인증을 한 뒤에 S3에서 미리 생성해둔 특정 bucket에 빌드 파일을 전송한다. 그리고 새 배포를 생성하여 어떤 배포 그룹을 사용할 건지, S3의 어떤 파일을 이용해 배포를 진행할 건지 명시해둔다.
   1. appsepc.yml 을 통해 배포 스크립트를 지정한다.

   2. example.sh 에 배포 스크립트를 작성한다.

       //exapmle.sh
       nohup java -jar -Dspring.profiles.active=local myapp-1.0.0.jar --server.port=8080 &
      

//deploy.yml - github action
aws deploy create-deployment \
  --deployment-config-name CodeDeployDefault.AllAtOnce \
  --application-name $ \
  --deployment-group-name $ \
  --s3-location bucket=$S3_BUCKET_NAME,bundleType=zip,key=$GITHUB_SHA.zip

1. Code Deploy는 지정된 S3의 파일을 가져와 ec2에서 배포를 진행한다.
   1. s3와 ec2에 접근하므로 이에 대한 IAM 권한이 필요하다.

정리

서비스들의 흐름을 정리해보았다.