[AWS] 고가용성 인프라 구축

이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.

---

• 가용성(Availability)이란 시스템이 서비스를 정상적으로 제공할 수 있는 가능성을 의미한다.
• 서비스에 장애가 발생할 가능성이 극히 작은 시스템을 가용성이 높은(고가용성) 시스템이라고 말할 수 있다. 반대로 서비스가 다운되는 시간이 긴 시스템을 가용성이 낮은 시스템이라고 한다. 
• 가용성을 높이기 위해서는 서비스 사용 불가능 시간을 최대한 발생시키지 않게 하고 설령 발생하더라도 그 시간을 짧게 만들어야 한다. 다운 타임을 줄이는 데 가장 중요한 설계 방법 중 하나가 시스템 이중화이다. 

 

이 글에서 최종 구축하는 인프라 아키텍쳐는 아래와 같다.

• VPC에 가용 영역을 2개로 설정하고, 각 가용 영역에 퍼블릭, 프라이빗 서브넷을 나누고 각각 프라이빗 서브넷에 ec2와 RDS를 배치한다.
• 가용 영역 ap-northeast-b의 RDS는 예비 데이터베이스로 ap-northeast-a의 데이터를 복제하고 ap-northeast-a의 가용 영역에 문제가 생겼을 때 해당 RDS로 서비스를 유지한다.
• VPC에 있는 로드 밸런서를 통해서 클라이언트의 요청을 2개의 EC2인스턴스에 분산해서 처리한다.
• bastion-host는 프라이빗 서브넷에 접근하기 위한 EC2인스턴스이다.
• 프라이빗 서브넷의 EC2 인스턴스가 외부와 통신할 수 있도록, NAT 게이트웨이를 퍼블릭 서브넷에 배치한다.

 

아래의 아키텍쳐가 이미 구성되어있다고 가정한다.

 

고가용성 인프라 구축

가용 영역을 추가로 생성

1. 서브넷 추가

 

3. 인터넷 게이트웨이 추가하기

• 인터넷 게이트웨이는 VPC 단위로 동작한다.
• 따라서 가용 영역이 몇 개든 하나의 VPC당 하나의 인터넷 게이트웨이만 생성하면 된다.
• 즉, 추가로 생성해줄 인터넷 게이트웨이는 없다.

 

4. NAT 게이트웨이 추가하기

• NAT 게이트웨이는 서브넷 단위로 동작한다.
• 따라서 가용 영역의 개수에 맞춰서 NAT 게이트웨이를 생성해야 한다.
• 즉, 새로운 가용 영역(ap-northeast-2b)에 대한 NAT 게이트웨이가 필요하다.

 

기존 NAT 게이트웨이 이름을 수정한다.

 

이후 NAT 게이트웨이를 추가한다.

 

5. 퍼블릭 라우팅 테이블 추가

기존에 생성된 퍼블릭 라우팅 테이블의 라우팅 정책을 별도로 수정할 게 없기 때문에, 새로 생성한 퍼블릭 서브넷은 기존 퍼블릭 라우팅 테이블을 같이 사용해도 된다.

 

6. 퍼블릭 라우팅 테이블에 퍼블릭 서브넷 연결

 

7. 프라이빗 라우팅 테이블 추가

• 기존 라우팅 테이블은 ap-northeast-2a의 가용 영역에 있는 NAT 게이트웨이로 라우팅을 하고 있다.
• 하지만 새로 만든 프라이빗 서브넷은 ap-northeast-2b의 가용 영역에 있는 NAT 게이트웨이로 라우팅을 해야하기 때문에 새로운 라우팅 테이블을 만들어야 한다. 

 

 

기존 프라이빗 라우팅 테이블 이름을 수정한다.

 

 

새로운 가용 영역에 EC2 배치

1. EC2 인스턴스 생성 페이지로 이동

 

2. EC2 인스턴스 옵션 선택

 

3. EC2 인스턴스에 접속하기 위해 Bastion Host로 접속

 

4. instagram-server-b 인스턴스로 접속

$ cd [키 페어 파일이 있는 경로]
$ ssh -i "instagram-server.pem" ubuntu@[instagram-server-b 인스턴스의 Private IP]

 

여기까지 작업으로 아래의 아키텍쳐가 완성되었다.

 

 

프라이빗 서브넷에 RDS 인스턴스 추가

1. 서브넷 그룹 생성

RDS를 특정 VPC의 서브넷에 배치하려면 서브넷 그룹을 먼저 생성해야 한다.

RDS가 가지고 있는 기능(다중 AZ, Multi AZ) 때문에 가용 영역은 필수로 2개 이상 선택해야 한다.

 

2. RDS 인스턴스를 위한 보안그룹 생성

 

3. RDS 인스턴스 생성

 

4. RDS 인스턴스가 잘 생성되었는지 확인

DBeaver를 활용

 

RDS 인스턴스는 VPC의 프라이빗 서브넷에 구축되어 있다.

즉, 외부 인터넷에서 직접적으로 접근할 수가 없다. 이런 이유 때문에 아래와 같이 에러가 뜨는 것이다. 

 

여기까지 구성했다면 아키텍쳐는 아래와 같다.

 

프라이빗 서브넷에 있는 RDS에 접속하는 방법

프라이빗 서브넷에 있는 RDS에 접속하려면 VPC 내부에 있는 Bastion Host를 활용해 간접적으로 접근해야 한다.

 

DBeaver를 통해 RDS에 접속

• Host/IP : Bastion Host의 퍼블릭 IP를 기재

 

 

ELB 추가(로드 밸런싱)

1. 로드 밸런서에서 사용할 보안 그룹 생성

 

2. 로드 밸런서의 기본 옵션 설정

 

3. 대상 그룹 생성하고 셋팅

 

다시 로드 밸런서 생성 페이지로 돌아와서 아래와 같이 생성한 대상 그룹을 추가하면 된다.

 

 

4. 로드 밸런서 생성

 

5. 로드 밸런서로 요청을 보냈을 때 정상적으로 응답하는 지 확인

 

여기까지 구축하였다면 아래와 같은 아키텍쳐가 완성된다.

 

RDS에 다중 AZ 배포 설정

다중 AZ(Multi AZ) 배포란 다른 가용 영역에 RDS 인스턴스의 복제본을 생성해두는 걸 의미한다.

두 데이터베이스를 구분하기 위해 원본 DB를 Primary DB 또는 Master DB라고 부르고, 복제본 DB를 Standby DB(예비 데이터베이스)라고 부른다. 

• Primary DB에 데이터가 추가됨에 따라 Standby DB에도 똑같이 데이터가 추가된다. 즉, Primary DB의 데이터를 Standby DB에 동기화시킨다.
• 만약 Primary DB에 장애가 발생할 경우, Standby DB로 자동으로 교체해서 사용한다. 즉, ap-northeast-2a의 가용 영역에 장애가 발생할 경우, 자동으로 Standby DB로 교체해서 사용한다.

 

1. 데이터베이스 인스턴스 수정 페이지 들어가기

 

2. 다중 AZ 배포 설정

 

5~10분 정도 기다리면 다중 AZ 배포가 성공적으로 적용된다. 아래와 같이 다중 AZ가 적용됐음을 확인할 수 있다. 

 

여기까지 설정하였다면 아래와 같은 아키텍쳐가 구성되었다.

 

 

최소 권한의 원칙(PoLP)

보안 그룹(Security Group)

• EC2 인스턴스 주위에 방화벽 역할을 할 보안 그룹(Security Group)을 만들고 보안 그룹에 규칙을 지정한다.
• 이 보안 규칙에는 인바운드 트래픽(즉, 보안 그룹의 외부에서 내부로 보내는 트래픽)에서 어떤 트래픽만 허용할 지 설정할 수 있고, 아웃바운드 트래픽(즉, 보안 그룹의 내부에서 외부로 나가는 트래픽)에서 어떤 트래픽만 허용할 지 설정할 수 있다. 

 

 

보안 그룹의 특징

• 하나의 보안 그룹에 여러 개의 AWS 리소스를 포함시킬 수 있다.
• 특정 서브넷에 종속되지 않고 여러 AWS 리소스를 하나의 보안 그룹으로 묶을 수 있다.

 

 

최소 권한의 법칙

• 보안에서 ‘최소 권한의 원칙(PoLP, Principle of least privilege)’이라는 중요한 법칙이 있다. AWS, GCP 등 다양한 클라우드 플랫폼에서도 필수적인 보안 정책으로 활용되고 있다.
• 최소 권한의 원칙이란, 무언가에 액세스할 때 필요한 최소한의 권한만 가지도록 제한하는 보안 원칙이다. 이 원칙에 따라 불필요한 권한을 제거하면 보안 사고를 어느 정도 예방할 수 있다.

 

• 지금까지 구성한 인프라 중에서 Bastion Host의 보안 그룹을 살펴보면, 보안 그룹에 따르면 모든 IPv4에 대해 22번 포트와 80번 포트로 접속할 수 있게 허용해둔 상태이다.
• 이 뜻을 다른 말로 바꾸면 어디서든 Bastion Host에 SSH로 접속할 수 있게 권한을 열어둔 상태이고, 누구든 80번 포트로 요청을 보낼 수 있게 권한을 열어둔 상태이다. 즉, 최소 권한의 원칙을 지키지 않고 셋팅을 했다. 
• 따라서 ALB, EC2, RDS의 보안 그룹을 수정하여 최소 권한의 법칙을 만족하도록 해야한다.