이번 실습은 AWS의 관계형 데이터베이스인 Amazon RDS를 배포하고 웹 서버와 연동하는 것으로, 고가용성 확보를 위한 Multi-AZ 기능과 성능 확장을 위한 Read Replica 기능을 알아보자
웹 서버와 Amazon RDS 연동하기
CloudFormation으로 기본 인프라 배포하
실습에 필요한 기본 인프라 자원은 AWS CloudFormation으로 자동 배포한다
AWS 관리 콘솔에서 서비스 > 관리 및 거버너스 > CloudFormation으로 들어가 스택 생성을 누른고
Amazon S3 URL에 https://cloudneta-aws-book.s3.ap-northeast-2.amazonaws.com/chapter6/dblab.yaml 을 입력한다!
스택 세부 정보 지정 페이지에서 다음과 같이 설정하고 다음을 누른다
스택 옵션 구성에서는 별도 설정 없이 바로 다음을 누르고 계속해서 dblab 검토도 별도 설정 없이 전송을 누른다
=> 약 5분이 지나 스택 상태가 "CREATE_COMPLETE"가 되면 모든 인프라 배포가 정상적으로 완료된 것이다
Amazon RDS를 생성하고 웹 서버와 연동하기
이번 실습에서는 두 개의 Amazon RDS를 생성한다
=> 데이터베이스 생성, 수정, 삭제 등은 각 5~15분 정도 시간이 소요되므로 실습 시간이 길어질 수 있음!
Amazon RDS1 데이터베이스를 생성하기 위해 AWS 관리 콘솔에서 서비스 > 데이터베이스 > RDS를 차례로 선택하고
대시보드에서 데이터베이스 생성을 누른다
[엔진 옵션] 엔진 유형은 MySQL 선택
템플릿과 가용성 및 내구성 설정을 해주고
설정은 다음과 같이 설정한다
(비밀번호는 'qwe12345'로 입력했음)
인스턴스 구성에서는 다음과 같이 설정한다
[연결] 은 Virtual Private Cloud(VPC)는 CH6-VPC 선택하고
기존 VPC 보안 그룹(방화벽)은 'default'를 제거한 후 dblab-CH6SG2-XXXX 선택
[모니터링] 'Enhanced 모니터링 활성화'에 체크 해제
맨 아래쪽으로 내려가 추가 구성을 클릭하고 다음과 같이 설정해준 후
맨 아래쪽에 있는 데이터베이스 생성을 누른다
RDS1 데이터베이스가 생성되기까지 약 12분 정도 소요된다
이번에 생성한 RDS1 데이터베이스의 특징은 '다중 AZ DB 인스턴스'를 선택하여 Multi-AZ 기능을 활성화했다
=> Multi-AZ 기능을 활성화하면 Primary DB와 Standby Replica가 생성되기 때문에 생성 시간이 길어진다
두 번째 데이터베이스인 RDS2를 생성하는 작업도 진행해보자
아까와 동일하게 데이터베이스 생성을 눌러주고
RDS1과 똑같이 진행하면 되는데 다른 부분은
1. 템플릿은 프리 티어 선택
2. 설정에서 DB 인스턴스 식별자에 'rds2' 입력
3. 인스턴스 구성에서 db.t2.micro 선택
4. 연결에서 가용 영역은 ap-northeast-2a 선택
추가 구성은 다음과 같이 설정해주고 데이터베이스를 생성한다
이번에 생성한 RDS2 데이터베이스의 특징은 'Multi-AZ 기능이 비활성화된' 상태로, 백업 보존 기간을 0일로 설정하여
'자동 백업 기능을 비활성화'했다.
=> 아무래도 데이터베이스 하나만 단독으로 생성되므로 RDS1 보다는 빠르게 생성됨
Amazon RDS > 데이터베이스 메뉴를 선택하면 생성된 데이터베이스를 확인할 수 있다!
이번에는 웹 서버(CH6-WebSrv) 및 Amazon RDS와 연동해보자
RDS1과 RDS2 데이터베이스의 엔드포인트 주소를 확인한다
(생성된 데이터베이스의 DB 식별자를 각각 클릭하면 아래쪽에 있는 연결 & 보안 탭에서 확인 가능)
# CH6-WebSrv의 SSH 터미널
# RDS1과 RDS2의 엔드포인트 주소를 변수로 선언(각자의 엔드포인트 주소로 입력)
RDS1=rds1.ctakkq48ob60.ap-northeast-2.rds.amazonaws.com
RDS2=rds2.ctakkq48ob60.ap-northeast-2.rds.amazonaws.com
# 선언된 변수 호출
echo $RDS1
echo $RDS2
RDS1과 RDS2 데이터베이스에 MySQL 명령어로 접속하고 데이터베이스 정보를 확인한다
MySQL 명령어에서 -h 옵션으로 데이터베이스 주소($RDS1)를 지정하고, -u 옵션으로 사용사 ID(root)를 입력하며, -p 옵션으로 암호(qwe12345)를 입력함
=> 접속한 데이터베이스에서 빠져나올 때는 ctrl + c
# CH6-WebSrv의 SSH 터미널
# RDS1 데이터베이스에 접속(RDS2도 동일하게 수행)
mysql -h $RDS1 -uroot -pqwe12345
# 상태 정보와 데이터베이스 확인
status;
show databases;
이제 CH6-WebSrv의 index.php 파일을 수정하여 RDS2 데이터베이스와 연동한다
# CH6-WebSrv의 SSH 터미널
# index.php 파일의 상위 다섯 줄만 확인
head -5 /var/www/html/index.php
index.php 파일에서 DB_SERVER 값은 임의로 설정되어 있어 데이터베이스 주소를 입력해야 한다
# CH6-WebSrv의 SSH 터미널
# index.php 파일의 DB_SERVER 값을 RDS2 엔드포인트 주소로 치환
sed -i "s/dbaddress/$RDS2/g" /var/www/html/index.php
# index.php 파일의 상위 두 줄만 확인
head -2 /var/www/html/index.php
DB_SERVER 주소는 변수로 선언한 RDS2 엔드포인트 주소로 변환되어 CH6-WebSrv와 RDS2 데이터베이스 간 연동 환경을 구성한다
이제 EC2 인스턴스(CH6-WebSrv)의 퍼블릭 IP 주소를 입력하여 인터넷 웹 브라우저로 접속한 후 데이터를 추가한다
데이터를 추가한 후 다시 SSH로 WebSrv에 접속해서 MySQL 명령어로 데이터베이스 테이블을 확인한다
# CH6-WebSrv의 SSH 터미널
# RDS2의 데이터베이스 EMPLOYEES 테이블 확인(1회)
mysql -h $RDS2 -uroot -pqwe12345 -e "USE sample;SELECT * FROM EMPLOYEES;"
# RDS2의 데이터베이스 EMPLOYEES 테이블 확인(반복문)
while true; do mysql -h $RDS2 --connect-timeout=2 -uroot -pqwe12345 -e "USE sample;SELECT * FROM EMPLOYEES;"; host $RDS2; date; sleep 1; done
이렇게 RDS2 데이터베이스에 직접 진입하지 않고 명령어를 이용하여 EMPLOYEES 테이블을 확인할 수 있다
RDS2가 중지될 경우 동작 확인하기
현재 RDS2는 Multi-AZ 기능이 동작하지 않고 단일 데이터베이스로 동작하기 때문에
RDS2 데이터베이스가 장애 발생으로 중지되면 장애에 대한 페일오버(failover-장애 극복 기능)를 수행할 수 없다
CH6-WebSrv의 SSH 터미널에 접속하여 MySQL 명령어로 데이터베이스 테이블을 확인하는 반복문을 수행한다
(명령어가 길어 편의를 위해 스크립트 SELECT_TABLE_RDS2.sh를 구성해 두었다고 한다..😉)
# CH6-WebSrv의 SSH 터미널
# RDS2의 데이터베이스 EMPLOYEES 테이블 확인 스크립트(반복문)
. /db_sh/SELECT_TABLE_RDS2.sh
RDS2 EMPLOYEES 테이블을 확인하는 반복문을 유지한 상태에서 RDS2 데이터베이스를 중지한다
RDS2를 선택한 후 작업 > 일시적으로 중지를 선택
=> 이때 버튼을 클릭하면 팝업창이 열리는데 "7일 후 DB 인스턴스가 자동으로 다시 시작하는 것에 동의합니다"에 체크한 후 일시적으로 중지를 클릭하면 됨
그럼 사진처럼 RDS가 중지되어 데이터베이스 테이블 정보를 가져오지 못하는걸 확인할 수 있다
=> RDS2 데이터베이스는 단일로 동작하고 있기 때문에 중지되거나 재부팅이 발생하면 데이터베이스를 찾을 수 X
이제 장애에 따라 지속적인 서비스가 불가한 문제를 해결하기 위해 Multi-AZ 기능을 확인해보자!
(다음 실습을 위해 중지된 RDS2 데이터베이스를 작업 > 시작을 선택해서 다시 시작)
Amazon RDS의 고가용성을 위한 Multi-AZ 동작 확인하기
이번에는 Multi-AZ 기능을 알아보기 위해 CH6-WebSrv를 Multi-AZ 기능이 활성화된 RDS1로 연결한다
# CH6-WebSrv의 SSH 터미널
# index.php 파일의 DB_SERVER 값을 RDS1 엔드포인트 주소로 치환
sed -i "s/$RDS2/$RDS1/g" /var/www/html/index.php
# index.php 파일의 상위 두 줄만 확인
head -2 /var/www/html/index.php
RDS1 데이터베이스의 EMPLOYEES 테이블 정보를 확인한다
# CH6-WebSrv의 SSH 터미널
# RDS1의 데이터베이스 EMPLOYEES 테이블 확인 스크립트(반복문)
. /db_sh/SELECT_TABLE_RDS1.sh
현재 RDS1은 EMPLOYEES 테이블이 없어 오류 메시지가 발생한다
=> 웹 서버의 웹 페이지에 접속하면 생성되지만 이번에는 명령어를 이용하여 테이블을 생성해보자!
# CH6-WEbSrv의 SSH 터미널
# EMPLOYEES 테이블 생성
mysql -h $RDS1 -uroot -pqwe12345 -e "USE sample;CREATE TABLE EMPLOYEES(ID int, NAME CHAR(20), ADDRESS CHAR(20));"
이렇게 테이블을 생성한 후 다시 RDS1의 EMPLOYEES 테이블을 확인하는 스크립트를 실행해보면 오류 X
이제 INSERT 명령어로 RDS1의 EMPLOYEES 테이블에 데이터를 추가해보자
# CH6-WebSrv의 SSH 터미널
# EMPLOYEES 테이블에 데이터 추가
mysql -h $RDS1 -uroot -pqwe12345 -e "USE sample;INSERT INTO EMPLOYEES VALUES ('1', 'SON', 'UK');"
다시 RDS1 데이터베이스의 EMPLOYEES 테이블을 확인하는 스크립트를 실행해보면
EMPLOYEES 테이블에 데이터가 추가된 것을 확인할 수 있다!
이렇게 CH6-WebSrv는 RDS1과 연동되어 SQL 질의와 응답을 이용해서 데이터를 생성하고 조회할 수 있다
=> 여기서 RES1은 Multi-AZ가 활성화되어 Primary DB와 Standby Replica는 서로 다른 가용 영역에 위치
Primary DB와 Standby Replica는 서로 동기화되어 테이블을 유지하며, Primary DB에 장애가 발생하면 Standby Replica가 Primary DB로 승격되어 페일오버를 수행할 수 있음!
RDS1 데이터베이스를 재부팅했을 때 페일오버 동작을 확인해보자
. /db_sh/SELECT_TABLE_RDS1.sh를 통해 RDS1 데이터베이스의 EMPLOYEES 테이블 정보를
반복하는 스크립트를 실행하고 유지한다
RDS1을 재부티아기 위해 데이터베이스 메뉴에서 RDS1을 선택하고 작업 > 재부팅을 선택한다
=> 재부팅 창이 열리면 '장애 조치로 재부팅하시겠습니까?'에 체크하고 확인을 누른다
RDS1을 재부팅하면서 Primary DB는 중지될 것이고 장애 조치를 위해 Standby Replica를 Primary DB로 승격시켜 자동으로 페일오버를 수행한다
보라색 글씨로 보이는 RDS1의 IP 주소를 확인해보면 재부팅 전 10.6.3.99에서 10.6.2.117로 변경된 것을 확인할 수 있음
=> Primary DB가 변경된 것으로 이해하면 됨!!
이런식으로 Primary DB에 장애가 발생하면 Multi-AZ 설정에 따라 다른 가용 영역에 생성된 Standby Replica 를 자동으로 승급하기 때문에 Primary DB 역할로 서비스를 지속적으로 유지할 수 있음
Amazon RDS의 성능을 확장하는 Read Replica 동작 확인하기
이번에는 데이터베이스의 데이터 처리 성능 확장을 위한 Read Replica 기능을 살펴본다
Read Replica는 Multi-AZ 같은 고가용성 서비스가 아님
=> 읽기 전용 데이터베이스인 Read Replica 데이터베이스를 복제하여 데이터처리 성능을 높이는 기능
RDS2 데이터베이스의 ReadReplica를 설정하기 위해 데이터베이스 메뉴에서 RDS2를 선택하고
작업 > 읽기 전용 복제본 생성을 선택한다
하지만 메뉴가 비활성화되어 설정할 수 없다
이는 Read Replica 설정 조건 중에는 자동 백업 기능이 활성화 상태여야 한다는 조건이 있기 때문이다
=> 처음 RDS2를 생성할 때 백업 보존 기간을 '0일'로 설정했는데 이는 자동 백업을 비활성화 한다는 의미
설정을 원한다면 RDS2 데이터베이스를 선택한 후 수정을 눌러 백업 보존 기간을 1일 이상의 값으로 변경해야 한다
하지만, 대기 시간이 발생하는 관계로 이번에는 Read Replica의 제약 조건이
자동 백업 기능을 활성화해야 한다는 점만 이해하고 넘어감!
(RDS1은 백업 보존 기간을 35일로 설정해서 제약이 없으므로 실제 실습은 RDS1에서 진행)
RDS1 데이터베이스의 Read Replica 설정을 위해 데이터베이스 메뉴에서 RDS1를 선택하고
작업 > 읽기 전용 복제본 생성을 선택
다음과 같이 설정해주고 가장 아래에 있는 읽기 전용 복제본 생성 누르기
일정 시간을 대기하고 RDS1-RR 생성이 완료되면 DB 식별자를 클릭하고 엔드포인트 주소를 메모해둔다!
# CH6-WebSrv의 SSH 터미널
# RDS1-RR의 엔드포인트 주소를 변수로 선언
RDS1RR=rds1-rr.ctakkq48ob60.ap-northeast-2.rds.amazonaws.com
# 선언된 변수 호출
echo $RDS1RR
# CH6-WebSrv의 SSH 터미널
# RDS1의 EMPLOYEES 테이블 확인
mysql -h $RDS1 -uroot -pqwe12345 -e "USE sample;SELECT * FROM EMPLOYEES;"
# RDS1-RR의 EMPLOYEES 테이블 확인
mysql -h $RDS1RR -uroot -pqwe12345 -e "USE sample;SELECT * FROM EMPLOYEES;"
=> RDS1-RR은 RDS1의 복제본 데이터베이스이기 때문에 서로 동일한 테이블을 유지하는걸 확인할 수 있음
이제 MySQL INSERT 명령어를 이용하여 RDS1의 EMPLOYEES 테이블에 데이터를 추가한다
# CH6-WebSrv의 SSH 터미널
# RDS1의 EMPLOYEES 테이블에 데이터 추가
mysql -h $RDS1 -uroot -pqwe12345 -e "USE sample;INSERT INTO EMPLOYEES VALUES ('2', 'Park', 'Suwon');"
다시 RDS1과 RDS1-RR의 데이터베이스 EMPLOYEES 테이블을 확인한다
# CH6-WebSrv의 SSH 터미널
# RDS1의 EMPLOYEES 테이블 확인
mysql -h $RDS1 -uroot -pqwe12345 -e "USE sample;SELECT * FROM EMPLOYEES;"
# RDS1-RR의 EMPLOYEES 테이블 확인
mysql -h $RDS1RR -uroot -pqwe12345 -e "USE sample;SELECT * FROM EMPLOYEES;"
=> 마찬가지로 RDS1과 RDS1-RR은 서로 동기화되어 테이블을 유지함
만약 INSERT 명령어를 이용하여 RDS1-RR의 EMPLOYEES 테이블에 데이터를 추가하면 어떻게 될까?
# CH6-WebSrv의 SSH 터미널
# RDS1-RR의 EMPLOYEES 테이블에 데이터 추가
mysql -h $RDS1RR -uroot -pqwe12345 -e "USE sample;INSERT INTO EMPLOYEES VALUES ('3', 'Lee', 'China');"
바로 야무지게 에러가 발생한다
=> RDS1-RR은 읽기 전용(read-only) 데이터베이스라는 오류 메시지를 출력하며 데이터를 추가하지 못함
📌정리를 해보자면 RDS1은 Primary DB로 읽기와 쓰기가 모두 가능하며, RDS1-RR은 RDS1의 복제본 데이터베이스로 데이터를 동기화해서 읽을 수만 있는 데이터베이스이다!
=> 복제본 데이터베이스를 생성하면 읽기 처리를 분산해서 성능을 확장할 수 있다
이렇게 하면 실습이 끝난다...😊
이제 실습을 위해 생성된 모든 자원을 삭제하자!!
RDS > 데이터베이스 메뉴에 들어가서 RDS1, RDS1-RR, RDS2를 각각 선택한 후 작업 > 삭제를 선택한다
다음과 같이 설정한 후 삭제를 진행하면 되는데 10분 내외가 소요되므로
대기 시간 이후 삭제되었는지 꼭 확인해야함~!
이제 CloudFormation 스택을 삭제하기 위해 CloudFormation > 스택 메뉴에 들어가서
'dblab' 스택을 선택한 후 삭제를 누른다
=> 이후 나타나는 창에서 스택 삭제를 누르면 된다
6장 끝!!
'Infra > AWS 교과서' 카테고리의 다른 글
[AWS 교과서] 7장 - AWS 고급 네트워킹 서비스(2) (0) | 2024.01.18 |
---|---|
[AWS 교과서] 7장 - AWS 고급 네트워킹 서비스(1) (0) | 2024.01.18 |
[AWS 교과서] 6장 - AWS 데이터베이스 서비스(1) (1) | 2024.01.15 |
[AWS 교과서] 5장 - AWS 스토리지 서비스(2) (1) | 2024.01.15 |
[AWS 교과서] 5장 - AWS 스토리지 서비스(1) (3) | 2024.01.13 |