[AWS] [구축활용] Route53 Failover를 활용한 고가용성 웹 사이트 구축

12년 연속 업계 1위가 추천하는 여름방학 해외 영어캠프

1. 구성도

• 평상시: 클라이언트가 ticketing.pw로 접속을 시도하면 CloudFront로 라우팅 되어 서울리전의 ELB을 통해 WEB서버로 접속된다.
• 서울리전 장애 발생시: Route53 HealthCheck이 서울리전의 비정상을 감지하고 Route53의 Failover 정책에 따라 클라이언트가 ticketing.pw로 접속을 시도하면 버지니아의 ELB로 라우팅 되어 WEB서버로 접속된다.

2. Route 53 Hosted Zone 생성

Route53 콘솔 화면에서 다음과 같이 클릭한다.

서비스 할 도메인 이름을 호스팅 영역으로 생성한다.

ticketing.pw가 호스팅 영역으로 생성되었다. 생성된 도메인을 클릭한다.

해당 도메인에 대한 4개의 네임 서버를 볼 수 있다.
이 값들을 도메인을 구매한 사이트에서 네임 서버로 등록해줘야 한다.

3. 네임 서버 변경 (Hosting.kr에서 도메인 구매 했을 때 기준)

자신이 구매한 도메인 판매 사이트에 로그인 하고 도메인 관리 페이지로 들어간다.
(다른 도메인 판매 사이트도 비슷)

구매한 도메인에 대하여 DNS 관리 페이지도 들어간다.

네임 서버 변경을 위해 수정 아이콘을 클릭한다.
(네임서버의 마지막 . 제외 할것)

Route 53에서 확인한 4개의 네임 서버를 등록해준다.

4. 인증서 생성

[Cloudfront 이용시] 반드시 버지니아 리전에서 생성해야한다.

버지니아에서 생성한 인증서는 모든 리전에서 사용이 가능하지만 다른 리전에서
생성하면 해당 리전에서만 인증서 사용이 가능하다.

또한, 위에서 진행한 과정인 네임 서버를 반드시 등록한 상태여야 한다.

ACM(Amazon Certificate Manager)에서 인증서 프로비저닝 시작하기를 클릭한다.

공인 인증서 요청을 선택한다.

서비스 할 도메인 명을 적는다.
*.ticketing.pw는 www.ticketing.pw, blog.ticketing.pw 등을 모두 포함한다.

DNS 검증이 더 수월하므로 DNS 검증을 선택한다.

원하는 태그를 지정한다.

검토를 마치고 확인 및 요청을 클릭한다.

Route 53 레코드 생성을 클릭하면 CNAME 레코드가 호스팅 영역에 생성되면서 DNS 검증이 자동으로 완료된다.
(클릭을 해야 DNS 검증이 시작됨)

인증이 완료될 때까지 시간이 최대 30분 소요되며 인증이 완료되면 상태가 발급 완료로 변경된다.

5. 웹 서버의 정적 파일 업로드를 위한 S3 및 CloudFront Distribution 생성

S3 버킷 만들기를 선택한다.

서울 리전에 버킷을 생성한다.

퍼블릭 엑세스 차단을 풀어준다. (차단시 테스트 필요)

버킷 버전 관리를 활성화해야 이후 버킷 복제 규칙을 생성할 수 있다.

생성된 버킷을 확인한다.

CloudFront 메인 콘솔로 넘어가서 Distribution을 생성한다.

생성한 S3를 선택하고 반드시 ticket-s3-web.ap-northeast-2.amazonaws.com로 Domain Name을 Regional Domain Name으로 바꿔줘야 정상적으로 잘 작동한다.

나머지 모든 설정은 기본값으로 두고 Distribution을 생성한다.

Distribution이 생성된 모습이다.

6. 버킷 복제 규칙 생성

서울 리전이 작동하지 않을 때 버지니아 웹서버에서 연속적으로 웹이 동작하기 위해서 서울 리전 S3내의 파일이 항상 버지니아의 S3로 복제된 상태여야 한다.
버지니아의 버킷 및 CloudFront Distribution 생성 방법은 서울리전과 완전히 동일하다.

복제 규칙을 생성할 서울 리전 버킷을 선택한다.

복제된 개체를 수신할 버킷을 버지니아에 생성한 S3 버킷으로 선택한다.

복제본 수정 동기화를 선택하고 저장을 눌러 생성을 완료한다.

복제 규칙이 생성되었으며 서울 리전 버킷에 존재하는 데이터가 버지니아로 자동으로 복제 및 동기화 된다.

7. 서울 리전 ELB와 WEB 서버에 사용 될 보안 그룹 생성

EC2 콘솔에서 다음과 같이 클릭한다.

HTTP에 대하여 위치에 관계없이 접근 가능하도록 ELB의 보안 그룹을 생성한다.

WEB에 사용될 보안 그룹은 HTTP 프로토콜은 ELB에서 보내는 트래픽만 허용하고 SSH는 10.0.0.0/16의 내부 망에서만 접근 가능하도록 설정한다.

생성이 완료된 모습이다.

8. AMI 생성

웹 개발자가 EC2에 웹 서버를 구축해두었다는 시나리오로 이 과정을 진행한다.

직접 구축한 웹 서버를 선택하고 이미지 생성을 클릭한다.

원하는 이미지 이름과 설명 및 태그를 추가하고 이미지를 생성한다.

이미지 생성이 완료되면 상태가 available로 바뀌게 된다.

9. 시작 템플릿 생성

시작 템플릿을 AutoScaling Group이 참조하여 WEB서버용 EC2를 생성하게 된다.

시작 템플릿을 생성하기전에 웹 개발자가 EC2에 웹서버를 구축하고 해당 EC2를 ami로 만들어둔 상태에서 시작 템플릿을 생성할 수 있다.

AMI는 직접 생성한 이미지를 선택한다.

생성한 웹 서버용 보안 그룹을 선택하고 생성을 완료한다.

시작 템플릿이 생성된 모습이다.

10. Target Group 생성

ELB가 트래픽을 보내줄 대상을 지정하기 위한 Target Group을 생성한다.

Target Group을 생성하고 ELB를 생성한다.
이후 AutoScaling Group으로 생성되는 WEB 서버들이 Target group에 속하게 되면 ELB가 해당 WEB서버에게 트래픽을 분산해서 보내게 된다.

ELB와 WEB은 굳이 HTTPS로 통신할 필요가 없으므로 HTTP로 프로토콜을 설정한다.

상태검사는 HTTP로 설정한다.

아직 등록할 대상이 없으므로 등록하지 않고 Target group을 생성한다.

11. ELB 생성

Target Group을 생성하고 나면 바로 ELB를 생성한다.

7계층에서 동작하는 ELB인 Application Load Balancer를 생성한다.

서울 리전 ELB는 CloudFront와 HTTP 통신할 것이기 때문에 리스너는 HTTP로 설정한다. 체계는 인터넷 경계로 설정하고 가용 영역은 반드시 Public 서브넷으로 선택한다.
웹 서버가 Private Subnet에 존재하더라도 ELB의 가용영역은 반드시 Public Subnet으로 지정해야 정상적으로 작동하게 된다.

리스너가 HTTP로 설정되었기 때문에 나타나는 경고창이다. 신경쓸 필요 없이 다음으로 넘어간다.

미리 생성했던 ELB의 보안 그룹을 선택하고 다음으로 넘어간다.

미리 생성했던 대상그룹을 선택하고 다음으로 넘어간다.

검토를 마치고 ELB를 생성한다.

12. AutoScaling Group 생성

템플릿을 참조하여 EC2를 생성하기 때문에 기존에 생성한 템플릿을 지정하고 다음으로 넘어간다.

EC2들이 생성될 서브넷을 지정한다.

미리 생성했던 Target Group에 생성되는 WEB서버들이 포함되도록 설정한다.

원하는 인스턴스 용량을 지정한다. 조정 정책은 지금은 없음으로 지정하고 이후에 단순 조정 정책을 따로 지정할 것이다.

태그릴 지정할 때 새 인스턴스에 태그 지정을 선택하면 새로 생성되는 EC2 인스턴스에도 똑같은 태그가 붙는다.

모든 설정을 검토하고 AutoScaling Group을 생성한다.

















출처 :
https://cumulus.tistory.com/9