[56일 차] 21.10.13 : 개인 프로젝트

 

---

1교시

 

 

개인 프로젝트 전체 브리핑 + DB 복제 수업

 

개인 프로젝트의 목적은

교육 결과물 노동부에 제출 + 지금까지 배운 것 전체 복습 + 잠깐 쉬어가는 시간

 

원래는 DB 복제 부분을 강사님께 받아서 할 예정이었지만, 어차피 나중에 RDS에서 유사한 내용이 있어서 수업하는 것으로 변경.

 

큰 구성은

기본 환경 구성 > 전송 게이트웨이와 온프레미스의 VPN 설정 > TGW 리전 간 피어링 설정 > DB 복제 설정

 

테스트는

1. 서울 근접 사용자의 웹 서비스 접근

2. 싱가포르 근접 사용자의 웹 서비스 접근

3. 서울 근접 사용자의 DB 데이터 추가

4. 싱가포르 근접 사용자의 DB 데이터 추가

5. 접속 동작 정리

 

6. 서울 온프레미스의 마스터 DB 중지

7. 서울 웹 서버 상태 확인 및 데몬 상태 확인

8. ALB에서 상태 확인

9. 서울 GA에서 상태 확인

10. 위 과정을 거친 후의 서울 사용자의 웹과 DB 서비스 접속

 

6번에서 서울 DB가 중지되면 서울 리전에 있는 모든 인프라는 사용이 불가능해질 것이다. 그렇다면 서울 근접 사용자는 Global Accelerator로 싱가포르로 접속하게 될 것이다.

 

 

 

• 기본 환경

서울 리전 쪽에는 VPC가 2개.

 

1. VPC1은 서울 리전 내 AWS 리소스 자원

서브넷이 7개 필요

subnet 1 : NAT 인스턴스를 굴릴 퍼블릭 서브넷(10.1.1.0/24), 가용 영역 a

subnet 2 : NAT 인스턴스를 굴릴 퍼블릭 서브넷(10.1.2.0/24), 가용 영역 c

subnet 3 : 웹 서버를 굴릴 프라이빗 서브넷(10.1.3.0/24), 가용 영역 a

subnet 4 : 웹 서버를 굴릴 프라이빗 서브넷(10.1.4.0/24), 가용 영역 c

subnet 5 : TGW를 연동할 프라이빗 서브넷(10.1.5.0/24)

subnet 6 : TGW를 연동할 프라이빗 서브넷(10.1.6.0/24)

 

서브넷 3, 4를 ALB로 묶고, 이 ALB는 퍼블릭 영역에 있어야 하며, GA의 타깃이 될 것이다.

서브넷 3, 4는 웹 서버가 배치될 것이고, 웹 서버-DB 연동 내용을 웹 서버에 넣어놓기(php 코드)

서브넷 1, 2의 NAT 인스턴스는 프라이빗에 있는 웹 인스턴스의 외부 통신 용도

 

퍼블릭 라우팅 테이블은 1개, 엔트리는 2개 : 기본 + IGW 경로

프라이빗 라우팅 테이블은 2개, 엔트리는 3개 : 기본 + NAT 인스턴스로(ENI)의 경로 + TGW로의 경로(10.0.0.0/8)

 

도메인은 Freenom 안써도 될 듯. 사설 호스팅 영역 A 레코드로 대체

 

2. VPC2는 IDC 영역이라고 가정

bind 패키지 설치해서 DNS 인스턴스 만들기.

Route 53 Resolver 사용, 인바운드/아웃바운드 엔드포인트 만들어서 IDC와 AWS 간 사설 통신 구축

TGW와 CGW 인스턴스를 VPN 연결

 

 

싱가포르 리전에도 VPC는 2개

 

1.  VPC1은 싱가포르 리전 내 AWS 리소스 자원

서브넷이 7개 필요

subnet 1 : NAT 인스턴스를 굴릴 퍼블릭 서브넷(10.3.1.0/24), 가용 영역 a

subnet 2 : NAT 인스턴스를 굴릴 퍼블릭 서브넷(10.1.2.0/24), 가용 영역 c

subnet 3 : 웹 서버를 굴릴 프라이빗 서브넷(10.3.3.0/24), 가용 영역 a

subnet 4 : 웹 서버를 굴릴 프라이빗 서브넷예비용 서브넷. 빈 상태로 둔다(10.4.4.0/24), 가용 영역 c

subnet 5 : TGW를 연동할 프라이빗 서브넷(10.3.5.0/24)

subnet 6 : TGW를 연동할 프라이빗 서브넷(10.3.6.0/24)

 

2. VPC2는 IDC 영역이라고 가정

서울 리전에서 했던 것과 동일

 

여기까지가 기본 구조.

 

 

DB의 가용성을 유지하기 위해 DB 복제 기술 적용.

-> DB에 변동이 생길 때마다 슬레이브 DB에게 실시간으로 전달/수정

-> 슬레이브 DB에서는 읽기만 가능. 입력/수정/삭제 불가

-> DB 부하 분산 + 장애 처리 목적

서울 리전의 IDC에 있는 DB가 마스터 DB, 싱가포르 리전의 IDC에 있는 DB가 슬레이브 DB

당연히 서울 리전에서 접속하는 사용자나 서울 리전의 AWS에 있는 웹 서버는 서울 IDC에 있는 DB를 타깃으로 잡는다.

 

웹 서버-DB 간 상태 점검(Health Check) 구축, DB에 문제가 생기면 httpd를 정지시키도록 설정

-> DB에 문제가 생기면 웹 서버가 정지되고, 다른 리전의 웹 서버로 접속하도록

---

2~4교시

 

 

DB 복제와 웹 서버의 DB 상태 점검 설정

 

마스터 DB에 계정을 2개 생성

gasida : 원격 접속 용도

repl_user : 슬레이브 접속 용도

 

pingchecker.sh는 웹 서버의 DB 상태확인 파일

웹 서버의 crontab으로 일정 주기마다 계속 실행

/etc/crontab

*/3 * * * * root /opt/pingcheck.sh

-> 매년, 매달, 매일, 매 시간, 3분 단위로 실행

 

폭풍같이 진행했다. 어지럽다.

아무튼 다 수업했으니 프로젝트 시작.

다 완성 못할 수도 있으니 기반부터 쌓아가는 것이 좋겠다.

 

 

차근차근해보자.

Global Accelerator는 가장 마지막에 구축하자.

 

1. 서울 리전의 AWS VPC 구축

Seoul-VPC(10.1.0.0/16)

Seoul-IGW

Seoul-Subnet1(10.1.1.0/24) : 퍼블릭, NAT 인스턴스 1

Seoul-Subnet2(10.1.2.0/24) : 퍼블릭, NAT 인스턴스 2

-> 퍼블릭 서브넷의 라우팅 테이블은 같은 것을 사용해도 무방 : 경로는 기본 경로와 IGW로의 경로(추가)

Seoul-Subnet3(10.1.3.0/24) : 프라이빗, 웹 인스턴스

Seoul-Subnet4(10.1.4.0/24) : 프라이빗, 웹 인스턴스

-> 프라이빗 서브넷 2개는 각각 다른 라우팅 테이블 사용.

-> 기본 경로, NAT 인스턴스(ENI)로의 경로, TGW로의 경로

Seoul-Subnet5(10.1.5.0/24) : 프라이빗, TGW 연결 용도. 인스턴스 필요 없음

Seoul-Subnet6(10.1.6.0/24) : 프라이빗, TGW 연결 용도. 인스턴스 필요 없음

 

일단 TGW는 배제하고 구축하자. 여기까지 했다면 테스트.

-> 외부에서 도메인 이름으로 접속이 가능한가?

-> ALB가 잘 작동하는가?

-> 여기까지 잘 된다면 NAT 인스턴스/웹 서버 인스턴스도 잘 작동하는 것.

 

막혔던 부분

-> NAT 인스턴스 코드에서 SourceDeskCheck: false다. 이전 작업들에서 true로 되어 있던데 왜 그랬지?

-> 각 인스턴스에 썼던 AMI ID가 변경되었다. 혹시 모를 에러에 대비해 생성 전에 AMI를 다시 검색해보자.

 

어쨌든 1단계 성공

 

1+. Seoul-VPC에 Route 53으로 프라이빗 호스팅 영역 구축

일단 위 결과물에서 시작해서, 콘솔로 만드는 것은 성공.

코드로 작성하자. 

1++. TGW를 연결하는 것 까지는 하자.

서브넷 5, 6에 TGW를 연결하고, 퍼블릭 라우팅 테이블에 10.0.0.0/8을 TGW로 보내는 엔트리 추가

 

 

 

2. 서울 리전의 IDC VPC 구축

실습 6-7에서 VGW 대신 TGW를 넣었던 것을 생각하자.

Seoul-IDC(10.2.0.0/16)

Seoul-IDC-IGW

Seoul-IDC-Subnet(10.2.1.0/24) : 퍼블릭

-> 퍼블릭 라우팅 테이블

-> CGW Instance(10.2.1.100)

프라이빗 서브넷과 라우팅 테이블 만들어서 아래 두 인스턴스 넣고

DNS Instance(10.2.2.200)

-> 싱가포르 리전에서는 openswan 세팅 부분에서

curl -o /etc/ipsec.d/vpnconfig.sh https://cloudneta-book.s3.ap-northeast-2.amazonaws.com/chapter8/8_lab_vpnconfig_singapore.sh

이 부분 수정(리전 문제)

DB Instance(10.2.2.100)

 

 

VPC DNS 설정 관련 보충 내용

https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames

VPC에 대한 DNS 지원 - Amazon Virtual Private Cloud

 

 

• 오늘 진행 결과 : Seoul-0.yml

Seoul-VPC 부분은 구축 완료. ALB를 통해 접속, 부하 분산 기능을 확인했다.

Route 53은 내부 통신 용도(curl로 작동 확인했다)라고 가정하면 완성 맞음.

• 이제 해야 할 부분 : Seoul-1.yml

Seoul-IDC 구축.

 

질문해야 할 점

1. Seoul-IDC에 서브넷 구성은 어떻게 하지?

-> DNS/DB와 CGW를 같은 서브넷에 두면 안 되지 않나?

전자는 프라이빗 서브넷에, 후자는 퍼블릭 서브넷에.

2. Seoul-VPC에서 Route 53은 내부 통신 용도 맞지?

-> 외부 사용자는 어차피 Global Accelerator로 접속할 테니까