AWS - RDS 개념, 실습

AWS RDS

- RDS(Relational Database Service)

- 관리형 DB 서비스이며, 쿼리 언어로써 SQL을 사용한다.

- cloud내에 만들 수 있다.

 

 

RDS의 장점

- 자동 프로비저닝, OS 패치를 해 준다.

- 계속 백업을 해 주고, 특정 timestamp로 복구할 수 있다.

- DB 성능을 모니터링 할 수 있다.

- 읽기 성능을 높이기 위해 read replica를 만들 수 있다.

- 재해 복구를 위해 Multi AZ 설정이 가능하다.

- 업그레이드를 위한 유지보수가 가능하다.

- 수평적, 수직적 스케일링이 가능하다. -> replica 활용

- EBS(gp2 or io1)에 백업 가능

=> 관리형 서비스

- 하지만 관리형 서비스이기 때문에 SSH 접속을 할 수 없다.

 

 

RDS 백업

자동 백업

- 매일 full backup

- 매 5분마다 Transaction 로그가 백업된다. => 어떤 지점으로든 복구가 가능하다.
- 7일간 데이터가 보관되지만, 35일까지 늘릴 수도 있다.

DB 스냅샷

- 사용자가 직접 해야한다.

- 보관 기간을 직접 설정할 수 있다.

 

 

Storage Auto Scaling

- 동적으로 RDS DB 인스턴스 내의 저장공간이 증가하게 해 준다.

-  스토리지 확장을 위해 DB를 중단할 필요가 없다.

- Maximum Storage Threshold를 설정해야 한다(상한값을 설정해야 함)

- 자동 수정 설정 -> 저장 공간이 10% 이내일 때

                          -> 5분동안 저장공간이 적은 상태가 지속되었을 때

                          -> 마지막 수정 후 6시간이 지났을 때

- 예측할 수 없는 워크로드의 애플리케이션에 유용하다.

 

 

 

RDS Read Replicas for read Scalability

- 최대 5개의 래플리카 생성 가능

- 같은 AZ내, Cross AZ, Cross 리전 -> 세 가지 가능하다.

- 비동기식 복제(ASYNC replication)가 발생한다 : 읽기가 일관적으로 유지된다.

- Consistent ASYNC replication : 애플리케이션에서 데이터를 복제하기 전 읽기 전용 복제본을 읽어들이면 모든 데이터를 얻을 수 있다.

- 래플리카를 DB로 승격시켜 이용 가능하다. -> 자체적인 생명주기를 가진다.

- 애플리케이션은 read replica를 이용하기 위해 반드시 연결을 업데이트 해 줘야 한다.

 

 

사용 예시

- 만약 Reporting Application이 분석을 위해 running을 해야할 때?

 

- 메인 RDS DB 인스턴스에 이 App을 연결하게 되면 오버로드가 발생하여, Prd.App의 속도가 느려지게 될 것이다.

- Read 래플리카를 만들어서 Rep.App이 읽도록 한다.

- 그러면 기존의 Prod.App은 영향을 받지 않는다.

- Read 래플리카는 오직 SELECT문만 사용 가능하다. 

 

 

네트워크 비용

- 한 AZ에서 다른 AZ로 가는 것은 network cost가 든다.

- 하지만 RDS Read 래플리카는 같은 리전 내에서는 돈이 들지 않는다.

 

 

RDS Multi AZ (재난 복구)

- SYNC Replication이다. -> Master DB의 모든 변화를 동기적으로 복제한다.

- 하나의 DNS 이름으로 통신한다. -> Master에 문제가 생길 때에 standby DB가 자동으로 장애 조치를 수행하도록 한다. = Standby DB가 Master의 역할을 한다.

- availability를 높인다.

- AZ 손실, 네트워크 손실, 인스턴스나 저장 공간에 failure가 발생했을 때 사용된다.

- 사람의 개입이 들어가지 않는다.(수동 조작X)

- scaling을 위해서 사용되지 않고, 오직 대기 목적만을 위해 사용된다.

- DR(Disaster Recovery)를 위한 것이므로, 반드시 Multi AZ여야 한다.

 

 

RDS - Single-AZ에서 Multi-AZ로 바꿀 때

- 다운 타임이 없다. 즉, DB를 멈출 필요가 없다.

- [수정] 버튼만 누르면 된다.

 

내부 과정

1. 스냅샷을 찍는다.

2. 새로운 AZ에 스냅샷이 새로운 Standby DB에 복원된다.

3. 두 DB간에 동기화가 설정된다.

 

 

RDS Security - Encryption

미사용 데이터 암호화

- AWS KMS를 이용하여 마스터와 read 래플리카를 암호화 할 수 있다.

- launch 할 때 암호화 할 수 있다.

- 만약 master가 암호화되지 않았다면, 래플리카도 암호화 할 수 없다.

- TDE(Transparent Data Encryption)이 Oracle과 SQL에서 사용 가능하다.

 

전송 중(In-flight) 암호화

- 클라이언트에서 DB로 전송 중에, RDS로 암호화를 하는 방식이다.

- SSL 인증이 반드시 필요하다.

- 모든 클라이언트가 SSL를 사용하게 하려면

           -> PostgreSQL에서는 매개 변수 그룹 설정이 필요하다

           -> MySQL에서는 DB내에서 SQL 명령을 해야한다.

 

암호화 과정 - 암호화X인 RDS DB를 암호화하기

 

RDS Security - Network & IAM

Network Security

- RDS DB는 private subnet에 배치된다. 따라서 DB가 www에 노출되지 않도록 해야 한다.

- RDS 인스턴스에 연결되어 있는 보안 그룹을 이용하여 RDS 보안이 활성화되도록 한다.

 

Access Management

- AWS RDS를 관리하는 사람만 제어할 수 있도록 한다. -> 이는 IAM policies로 부여된다.

- 전통적인 DB는 Username과 Password로 DB에 로그인 한다.

- RDS MYSQL과 PostgreSQL은 IAM 기반의 인증을 할 수 있다.

 

 

IAM Authentication

- MySQL과 PostgreSQL에서 작동한다.

- 패스워드는 필요하지 않고, RDS API call을 통해 얻은 auth token을 이용한다.

- SSL을 이용하여 네트워크 안팎이 암호화된다.

- DB 내부가 아닌, 중앙에서 유저들을 관리할 수 있다.

- IAM Roles와 EC2 인스턴스 프로파일이 쉽게 통합될 수 있다.

 

실습

보안 그룹 탭

vpc id 옆에 태그가 없어서 어떤게 default vpc에 있는 건지 my vpc에 있는 건지 알 수 없다.

default vpc빼고 다 삭제한다.

* 삭제가 되지 않는 보안 그룹은 인바운드나 아웃바운드에서 규칙을 삭제한다.

보안 그룹이 source 혹은 destination일 때, 다른 보안그룹과 연관되어 있으므로 삭제되지 않기 때문이다.

 

Route53

검색창에 Route53 입력한다.

 

* Route

경로

 

* 라우팅 기능

- 경로를 설정해준다

- 로드 밸런서의 기능

 

* 53

- DNS의 UDP 포트 번호

DNS 절차

- DNS : IP -> domain으로

 

SLB : Server Load Balancing

GSLB : Global Sever Load Balancer, SLB를 또 load balancing함  => 이를 Route53으로 구현

 

하나의 리전에서 Multi AZ 구현,

Cross Region : 리전을 넘나들어서 있음 => 가용성 높이기 위해

 

[호스팅 영역 생성] 클릭

 

 

가비아 - 마이 페이지 접속

우측의 [도메인 통합 관리 툴] 클릭

 

주소를 입력하고 생성한다.

 

현재 가비아가 갖고 있는 네임서버에 내 도메인 주소가 저장되어 있는데, 이를 aws로 이관(migration)시키는 것.

=> 정보가 이동하게 된다.(10분정도 소요)

가비아에서 내 도메인 네임을 들어가보면, 가비아의 네임 서버가 등록되어 있다.

다 지우고, aws의 네임 서버로 대체한다.

 

[설정] 버튼을 누른다.

 

원래 링크를 다 지우고 대체한다.

네임 서버가 4개나 있는 이유? -> 가용성을 위해서 분산한 것.

 

AWS 에서 EC2 - [인스턴스] 탭으로 간다.

 

Wordpress 설치

 

my-vpc로 설정하면 퍼블릭 ip 자동 할당이 비활성화 된다.

활성화로 바꿔야 한다.

비활성화 => 무료 ip를 받을 수 없게 된다.

 

my-vpc를 했을 때 자동으로 퍼블릭 IP 자동 할당이 '활성화' 되도록 한다.

VPC 탭으로 들어간다.

[서브넷] 클릭

오른쪽 마우스 - [서브넷 설정 편집]

[퍼블릭 IPv4 주소 자동 할당 활성화] 체크

를 A, B, C, D 네 군데 동일하게 해 준다.

 

그러고 다시 인스턴스 시작을 해 보면, 자동으로 퍼블릭 IP가 활성화 된다.

 

 

 

퍼블릭 아이피로 들어간 모습.

 

다시 VPC 탭으로 가서 [레코드 생성] 클릭

인스턴스의 퍼블릭 IP 입력

 

Moba Xterm 접속

 ssh 접속할 때 ip 대신 DNS 주소를 입력할 수 있다.

 

 

VPC - [서브넷] 탭으로 간다

[서브넷 생성] 클릭

 

하단의 [서브넷 추가] 버튼을 눌러 B,C,D 서브넷도 만든다.

 

[라우팅 테이블] 탭으로 간다

프라이빗 라우팅 테이블은 어제 만든 public rtb에서 0.0.0.0/0 igw~만 빠진 버전이다.

(아무나 접속하면 안되기 때문)

 

 

프라이빗 서브넷과 라우팅테이블 연결이 필요하다.

[서브넷 연결] 탭을 들어가 명시적 서브넷 연결을 해 준다.

 

 

다시 EC2 탭으로 가서 인스턴스를 새로 만든다.

 

비록 PRIVATE Subnet으로 해도 퍼블릭 IP 자동 할당을 활성화 하게 되면 퍼블릭 IP를 받을 수 있다.

하지만 어차피 통신은 안 됨(인터넷 라우팅이 안되기 때문에)

DBSERVER의 public IP로 ping을 쳐보면 나가지 않는다.

반면 WEBSERVER는 ping이 잘 간다.

웹서버에서 DBSERVER의 private ip로 ping을 쳐 보면 잘 간다.=> WEBSERVER를 통해 경유해서 접속한다.

db서버는 폐쇄망이기 때문에 사설IP로만 접속 가능하다.

 

moba에서 탭을 복제한 뒤, key를 SCP에 넣는다.

권한을 400으로 바꾼다.

 

안에서 밖으로 나가는 라우팅 정보가 없어서 나갈 수도 없다.

내부 네트워크 설정만 있음.

 

sudo update가 되지 않는다 -> 하기 위해선 nat-gateway 설치가 필요하다.

 

VPC - NAT 게이트웨이 탭으로 이동

[NAT 게이트웨이 생성] 버튼 클릭

우측 하단에 [탄력적 IP 할당] 을 클릭한다. -> public IP, External IP와 같은 IP가 설정된다.

 

* 탄력적 IP의 특징

- 한개만 있을 때, 사용하지 않으면 과금o, 사용하면 과금 x

 

라우팅 테이블 탭 - MY PRIVATE SUBNET RTB를 선택한 뒤 하단의 [라우팅 편집] 탭 클릭

 

NAT Gateway

- 송신 전용 Gateway

- 포트포워드에 대한 개념이 없다.

- 외부에서 시작된 트래픽이 안쪽으로 들어올 수는 없다.

- 안 => 바깥으로 나갈 수는 있음.

 

그러면

 

ping이 간다.

 

// MariaDB 설치
$ sudo apt-get update -y
$ sudo apt-get install -y mariadb-server
$ sudo mysql_secure_installation
$ sudo vi /etc/mysql/mariadb.conf.d/50-server.cnf
#bind-address            = 127.0.0.1

#bind-address 는 웹서버 db서버가 분리되어 있으므로 비활성화 시켜야 한다.

$ sudo systemctl restart mysql
$ sudo mysql -u root -p
CREATE USER 'wpuser'@'%' IDENTIFIED BY 'wppass';
CREATE DATABASE IF NOT EXISTS wordpress;
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'%';
quit

 

다시 WEBSERVER 로 들어간다

// 웹서버 설치
wget https://ko.wordpress.org/wordpress-4.8.2-ko_KR.zip
sudo yum install -y httpd php php-mysql php-gd php-mbstring wget unzip
cd /var/www/html
sudo unzip /home/ec2-user/wordpress-4.8.2-ko_KR.zip
sudo mv ./wordpress/* .
sudo chown -R apache:apache /var/www/*
sudo systemctl restart httpd
sudo systemctl enable httpd

http://blog.cloudywinter.shop

소현최 – 다른 워드프레스 사이트

로 접속해보자

구축이 완료되면 NAT gateway를 삭제한다(1시간 이상 지나면 과금이 많이 됨)

 

탄력적 IP는 시간이 조금 지난 후 - [탄력적 IP 주소 릴리스] 한다

 

VPC - 라우팅 테이블로 가면

블랙홀 로 되어있음 - 라우팅 편집으로 삭제

 

만약 WEBSERVER가 중지된다면?

 

WEBSERVER 선택 - 인스턴스 중지 클릭

중지 후 다시 시작하게 되면 기존의 public ip가 바뀐다

Route53으로 들어가서 ip를 수정한다.

 

EC2 - 보안 그룹 탭

SG-DB 선택, 인바운드 규칙 편집

 

MYSQL 삭제 후 다시 재지정

후 [규칙 저장] 클릭

 

접근 제어 2가지,

만약 NACL에서 80포트를 차단했다면, subnet으로 들어갈 수 없음.

NACL - 전체 서브넷을 전부 컨트롤 할 수 있다.

- 서브넷 안에 있는 SG를 컨트롤할 수 있다.

-보안 그룹은 그 속한 서브넷 안에

일부만 차단할 수 없다

 

스마트폰을 5G, LTE로 바꾼다.

 

VPC - 네트워크 ACL 로 간다.

인바운드 규칙 편집 클릭

위에 있는거 

100번 규칙번호를 함부로 지어선 안된다.

99 -> 100번보다 앞선다

내 IP로 들어오면 막게 된다.

 

이후 wordpress로 접속하려고 하면 안 들어가진다.

 

안들어가지는걸 확인하고 다시 [제거]해서 없앤다.

 

RDS 생성하기

[데이터베이스 생성] 클릭 

 

MariaDB 선택, 버전은 ubuntu에 설치한 버전과 최대한 비슷한 버전을 선택한다.

* 프로덕션 - AWS가 알아서 설정해줌

 

디폴트값대로 한다.

 

 

퍼블릭 엑세스 -> 외부에서 접근 가능

 

*bastion host - 경유 호스트

 

 

기존 VPC 보안 그룹 - default 삭제하고 SG-DB를 선택한다.

여기서는 가용영역으로 2b를 선택할 수도 있다. 2b를 선택한다.

 

이는 create database if not exists ... ; 와 같은 역할이다.

 

ubuntu or cmd에서 접속하려고 하면 안된다.

[보안그룹]에서 SG-DB의 인바운드 규칙을 수정한다.

 

 원래 있던 MYSQL 를 삭제하고 소스 - Anywhere in IPv4로 설정한다.

 

 

그러면 접속할 수 있다.

 

user를 만든 뒤 wordpress 데이터베이스를 설정하고 권한을 설정한다.

 

 

그다음 WEB01로 간다.

 

wp-config.php를 bak파일로 바꾼 뒤, 다시 블로그로 접속한다.

[데이터베이스 호스트]에 DB의 엔드포인트를 넣는다.

백업이 완료된 모습

이전에 달았던 댓글을 확인해 본다.

 

 

 

 

그리고 인스턴스 삭제하고 끝

 

RDS 삭제하기

 

 

[최종 스냅샷 체크 여부]를 체크하면 스냅샷이 생겨서 나중에 복원할 수 있지만, 과금 요인이 된다.

체크 해제한다.

 

만약 실수로 체크 해제하지 않았다면, RDS의 [스냅샷] 탭에서 삭제할 수 있다.

 

도메인 네임을 클릭한다.

 

선택한 뒤 삭제한다.