[ AWS ] RDS(Relational Database Service) 생성 및 적용

※ 개인 공부를 위한 공간입니다. 틀린 부분 지적해주시면 감사하겠습니다 (_ _)

 

지금까지, 여러가지(?) 데이터베이스를 사용해보았다.
SQLite, MySQL, MongoDB, PostgreSQL ...
로컬환경에서부터, iwinv라는 국내 클라우드 서버, AWS documentDB, AWS RDS...

이젠 하나로 정착하기로 했다.
iwinv같은 등록한 ip만 접근 가능한 서비스는, 오토 스케일링에 굉장히 불리했다.
그래서 AWS를 사용하게 되었고, 개인 프로젝트에는 프리티어로 적용시켜볼까 한다.

관계형 데이터베이스가 무엇인지는 과감히 생략한다

[AWS 설명]

Amazon 관계형 데이터베이스 서비스(Amazon RDS)는 클라우드 환경에서 구성하고, 사용하고, 관계형 데이터베이스를 확대하기 쉽다. 이는, 하드웨어 프로비져닝(사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것 (feat. wiki)), 데이터베이스 셋업, 패치 및 백업과 같은 시간이 걸리는 관리자용 업무를 자동화할 때 비용 효율 및 사이즈를 쉽게 재설정 할 수 있게한다. AWS RDS는 어플리케이션 개발에 집중할 수 있게 하여 사용자에게 필요한 빠른 퍼포먼스, 높은 가용성, 보안 및 호환성을 제공할 수 있다. 

한 마디로,
클릭 몇번으로 기존에 해야했던 어렵고 복잡했던 작업들을 구현할 수 있다.
그리하여, 어플리케이션 개발에 집중할 수 있다!

Amazon RDS는 메모리, 성능 혹은 I/O에 최적화된 몇몇 데이터베이스 인스턴스 타입(T, M, R, X, Z 시리즈들)을 사용가능하며, Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database 그리고 SQL Server를 포함한 6개의 친숙한 데이터베이스 엔진을 제공한다. 현재 사용중인 데이터베이스를 손쉽게 AWS Database Migration Service를 활용하여 Amazon RDS에 migrate(이동) 혹은 replicate(복제)를 할 수 있다.

데이터베이스도 EC2처럼 사양을 고를 수 있고, 메모리, 성능 혹은 I/O에 최적화된 시리즈 중에 고를 수 있다.
기존 사용하던 데이터베이스 서비스에서 데이터 & 설정을 import 및 export를 쉽게 할 수 있다!

AWS RDS를 사용할 수 있는 6가지 데이터베이스 엔진!

언제 다 써보려나....
차이점을 알고 프로젝트의 성향에 따라 고를 수 있는 순간이 오겠지!?

Benefits

• 관리에 용이
  • Amazon RDS는 프로젝트 컨셉에서 배포까지 쉽게 만들어 준다. 몇분 이내에 실서버 환경에 맞는 관계형 데이터베이스의 활용을 위해 Amazon RDS Management Console, AWS RDS Cli(Command-Line Interface), 혹은 간단한 API를 사용할 수 있다. 인프라 프로비저닝이 필요 없으며, 데이터베이스 소프트웨어 설치 및 유지보수를 할 필요가 없다.

간단하게 마우스 클릭 몇번으로 설정 가능! 밑에 참조!

• 뛰어난 확장성
  • 몇번의 마우스 클릭과 API 호출을 종종 다운타임(컴퓨터 미작동 시간) 없이 데이터베이스의 컴퓨팅 및 저장공간을 늘릴 수 있다. 많은 Amazon RDS 엔진 타입은 초기 데이터베이스 인스턴스에 트래픽을 줄이기 위해서 하나 이상의 읽기 전용 복제본을 실행시킬 수 있다.

 

트래픽을 나눠주기 위해 필요한 설정은, 단 몇번의 클릭....
데이터베이스 엔진 타입에 따라 16TB ~ 64TB까지 설정 및 리전에 따라 읽기전용 데이터베이스를 설정할 수 있고 DB 인스턴스당 최대 5개의 읽기 전용 복제본 추가 가능! (단 몇번의 클릭으로...)
물론 DocumentDB도 가능하더라~


돈만 내면 된다! 하하하

 

 

• 가용성 및 내구성
  • Amazon RDS는 다른 Amazon Web Services에 의해 사용되는 같은 높은 믿을 수 있는 인프라에서 동작한다. Multi-AZ(다중 가용영역) DB 인스턴스를 프로비저닝 하는 경우 (여러개의 가용영역에 (한국은 최대 4개!) 데이터베이스 인스턴스를 배치 한다는 뜻) Amazon RDS는 다른 가용영역에 있는 대기중인 인스턴스에 데이터를 비동기 복제한다. (ㄷㄷ..) Amazon RDS는 자동화 백업, 데이터베이스 스냅샷, 자동 호스팅 교체(Amazon RDS는 하드웨어에 장애가 발생할 경우, 배포를 지원하는 컴퓨팅 인스턴스를 자동으로 교체)를 포함한 중요한 실제 배포 데이터베이스를 위한 안정성을 높이는 많은 기능들이 있다. 

심지어 AWS에서도 이렇게 설명하고 있다.
"As with all Amazon Web Services, there are no up-front investments required, and you pay only for the resources you use." ㅋㅋㅋㅋㅋ
밑에, 실제 RDS를 만들어 볼건데, 그때 대부분의 위와 같은 설정을 할 수 있다. (자동적으로 되기도 함)

• 빠름
  • Amazon RDS는 사람들이 가장 많이 사용하는 데이터베이스를 지원한다. SSD를 지원하는 스토리지 옵션 중에 선택할 수 있다:
    1. 고성능 OLTP(Online Transaction Processing, 온라인 트랜잭션 처리; 여러 사용자가 실시간으로 데이터베이스의 데이터를 갱신하거나 조회하는 단위 작업 처리 방식) 어플리케이션에 최적화된 옵션
    2. 비용 효율적인 범용 사용성이 좋은 옵션

이건 모든 데이터베이스들이 지원하는 거 아닌가..?

• 보안성
  • Amazon RDS는 데이터베이스에 접근하는 네트워크를 쉽게 컨트롤 할 수 있게 한다. Amazon RDS는 또한 VPC 내에서 데이터베이스 인스턴스를 동작할 수 있게 한다. (VPC 내부에 인스턴스처럼 넣을 수 있음! 마치 인스턴스에 데이터베이스를 설치한 것 처럼.. 그 말은 즉슨 보안그룹을 설정할 수 있다는 말. 당연한건가!?) 이는, 데이터베이스 인스턴스를 격리할 수 있게 하며, 업계 표준 암호화 IPsec VPN(터널링 프로토콜을 통해 사설망과 사설망을 연결할 때 씀, 예. 본사<->지사)을 통해 사용중인 IT 인프라에 연결할 수 있게 한다.

보안그룹 설정을 통해 보안관리에 용이하며
네트워크 격리를 통해 온프레미스(하드웨어) 인프라에 연결 가능!!!

 

• 값싼 사용료
  • 매우 낮은 요금에 실제로 사용한 리소스에 대한 것만 낸다. 게다가, 선불이나 장기 약정 없는 On-Demand Pricing(온디맨드; 사용량과 기간을 유연하게 조정할 수 있음) 옵션이나, 예약된 인스턴스 요금으로 더 저렴한 시간당 요금을 통해 효과를 볼 수 있다.

사용자 및 서비스에 따라 다르겠지만,
제일 낮은 것 보다 한단계 높은 사양의 인스턴스 타입 + MySQL + 100G 스토리지 해서 달에 6만원 정도 냈던 것으로 기억한다.
시대가 시대인만큼, 선불이나 장기약정 서비스를 활용하면 가격이 더 저렴한 건 당연하고
온디맨드 옵션을 사용할 수 있어서 좋다!
(온프레미스로 구축하면 끔찍할 듯...)

 

AWS RDS 생성 및 적용

데이터베이스 생성 클릭!

표준 생성 &amp; MySQL &amp; 버전은 선택된 그대로!

표준 생성 > 하나하나 알아보기 위해 일일이 설정!
(AWS에서 제공하는 모범 사례는 당연히 돈을 내야하는..)
MySQL > 데이터베이스 엔진은 원하는 것을 선택하면 된다. 
(현재 6개의 엔진 중, 프리티어 서비스를 제공하는 것은, MySQL과 MariaDB밖에 없다!)
(프리티어란? AWS에서 제공하는, 12개월동안 월 750시간 무료로 사용할 수 있는 체험판 서비스)
버전 > default로 선택된 버전 선택! (21년 11월 20일 기준)
(데이터베이스 엔진에서 제공하는 여러개의 버전이 있지만, 특정 목적이 있는 것이 아니면 너무 낮은 버전 및 너무 최신 버전은 선택하지 않도록 하는 게 좋음 -> 오류의 늪)

당연히 프리티어! (다시 한번 더 이야기하지만, 공부를 위한 셋팅입니다. 실서버 용이라면 프로덕션!)

DB이름 &amp; 마스터 이름 &amp; 마스터 비밀번호

DB 인스턴스 식별자 > 다른 데이터베이스와 구별하기 위한 이름
마스터 사용자 이름 > 데이터베이스 접근을 위한 로그인 ID
마스터 암호 > 데이터베이스 접근을 위한 비밀번호

프리티어를 선택했기 때문에 default로 db.t2.micro가 선택 됨

범용 SSD (default) &amp; 20GiB &amp; unchecked!

스토리지 유형 >
  1) 범용(SSD) 스토리지: 광범위한 데이터베이스 워크로드에 적합함. 3 IOPS/GiB가 기본적으로 제공, 3,000 IOP까지 버스팅 가능
(IOPS: Input/Ouput Operations Per Second)
(IOPS를 MB/s로 변환하게 되면, 1G당 3 IOPS -> 20G = 60 IOPS -> (60 x 16kb(SSD(gp2))) / 1024 = 0.9MB/s 정도.. 어.. 좀 많이 느려보이네 ㅎㅎㅎ 공짜로 쓰는데 말이 많네)
  2) 프로비저닝된 IOPS SSD(io1): I/O를 많이 사용하는 데이터 베이스 워크로드에 적합. 1,000~80,000 IOPS 범위를 I/O를 프로비저닝할 수 있는 유연성을 제공
(유연성을 갖게 하면, 내 통장에서 돈도 유연성있게 빠진다..)
  3) 마그네틱: 최대 1,000 IOPS로 제한됨

할당된 스토리지 > 무료 버전이기 때문에, 최소 20GiB 정책을 따르자.

스토리지 자동 조정 > 활성화를 시킨다면, 임계값 초과시 알아서 늘어나기 때문에 무료버젼에서는 X

그대로~

실제 배포시, 데이터베이스가 터지면 큰일나기 때문에
다른 가용영역에 (혹시나 하는 상황에)대기하고 있는 인스턴스를 생성한다.
(어느정도의 규모를 서비스를 굴려야 필요한걸까.. 궁금하다.)

기존 VPC &amp; 새 DB 서브넷 그룹 생성 &amp; 퍼블릭 액세스

VPC > 만들어 놓았던 vpc를 선택

서브넷그룹 > 새 DB 서브넷 그룹 생성
선택한 VPC에서 DB 인스턴스가 어떤 서브넷과 IP 범위를 사용할 수 있는지를 정의하는 DB 서브넷 그룹 (AWS 설명)
: 한 가용영역 내 (다른 가용영역에서 발생하는 장애와의 격리) 할당된 서브넷과 IP 범위를 지정하는 DB를 위한 서브넷 그룹!

퍼블릭 액세스 > 예
: 데이터베이스에서 연결할 디바이스가 따로 있다면, 예로 지정하는 것이 좋다. (반대로 보안에는 좋지 않겠지!)
로컬에서 테스트를 진행해야하며, bastion 서버(VPC내 퍼블릭 액세스를 아니오로 지정한 데이터베이스에 접근하기 위한 VPC내부에 또 다른 인스턴스를 생성하여 ssh 터널링을 해줄 서버!)를 두고 싶지 않기 때문에!

VPC 보안 그룹 > 새로 생성

새 VPC 보안 그룹 이름 > As you want!

가용 영역 > 기본 설정 없음 혹은 특정 가용영역 선택!

추가 구성 > MySQL의 기본 포트는 3306

데이터베이스 인증 옵션 > 암호 인증
: 인증하고 싶은 방법을 고르면 된다. 항상 암호만으로 인증을 했기 때문에...

초기 데이터베이스 이름 > (필요하면) 초기 데이터 베이스를 만들어줄 이름

DB 파라미터 그룹 > default 설정
: 최근에 trigger 설정을 할 필요가 있었는데, default 파라미터는 수정할 수 없었기 때문에 새로 파라미터를 만들어줬었다. 이러한 경우가 아니라면 default만으로 충분해 보임! 밑에 새로 하나 생성하게 된다!

옵션 그룹 > (따로 설정할 필요가 없다면) default 설정
: Oracle 또는 SQL Server 데이터 암호화, MySQL 5.6 Memcached 지원과 같이 DB 인스턴스가 지원할 선택적 기능을 활성화하는 DB 옵션 그룹을 선택합니다. (AWS 설명) 각 데이터베이스 엔진에서 추가적으로 지원하는 기능들에 대한 옵션 설정

백업 > 체크 X
: 돈...

모니터링 > 체크 X
: 프리티어에서 제공하는 특정 값을 넘어가면 돈...

로그 내보내기 > 에러 로그, 느린 쿼리 로그
: 필요한 로그만 CloudWatch로!

유지관리 > 체크 X
: 특정 버전에서 업그레이드를 하게 되면 예상치 못한 오류가 발생할 수도 있기 때문에 추가적인 기능을 활용할 것이 아니라면 X

유지 관리 기간 > 기본 설정 없음
: 특정 기간 및 시간에만 업데이트를 해야한다면 (서비스시 유저가 많이 활동하지 않는 시간 혹은 유지보수 시간) 선택 기간에서 설정을 하고, 그렇지 않다면 Amazon RDS에서 임의로 기간 할당! 테스트이기 때문에 변경이 있을 시 즉시 적용을 할 계획이다.

삭제 방지 > 삭제 방지 활성화
: 기본적으로 설정해놓으면 좋음!

드디어 생성을!

조금만 기다리면, 위와 같이 데이터베이스가 생성이 된다!

여기서, 한가지 더 설정을 해주어야 하는데
현재 데이터베이스 생성시 연결된 인터넷의 IP에 따라 접근할 수 있는 인바운드를 포함한 보안그룹이 생성이 되었다.
이게 무슨 말인고 하니...

현재 설정으로만 인바운드를 지정하면, 현재 IP에서만 트래픽을 인바운드 규칙에 따라 받기 때문에
퍼블릭 엑세스를 지정했지만 다른 IP에서는 접근할 수 없다.
(나는 현재 스타벅스 와이파이를 활용한 스타벅스 IP가 등록되어 있기 때문에, 우리 집 아이피를 등록해보겠다!)

여기서 CIDR 블록인 32의 의미를 모르겠다면, 서브넷 편을 참고하기 바란다!

짜쟌! 이름도 등록 해주고.. 등록 완료!

찐막..... 설정 ㅠㅜㅜ

데이터베이스 생성 시 default 파라미터 그룹을 썼던 것에서 벗어나
region을 서울로, 이모지까지 담을 수 있는 파라미터 그룹을 새로 생성한 후 지정해 줄 것이다!

이름만 설정해주고!

생성된 파라미터 그룹 안으로 진입한다!

파라미터 편집

1) 오른쪽 상단에 "파라미터 편집"을 클릭한다.
2) 검색란에 "time_zone"을 검색하여, 해당 드랍다운에서 "Asia/Seoul"을 고르고 오른쪽 상단에 "변경사항 저장"
3) 검색란에 "character"을 검색하여, 이름에서 "character_set_client, character_set_connection, character_set_database, character_set_filesystem, character_set_results"을 찾아, 해당 드랍다운에서 "utf8mb4"을 고르고 오른쪽 상단에 "변경사항 저장"
4) 검색란에 "collation"을 검색하여, 이름에서 "collation_connection, collation_server"을 찾아, 해당 드랍다운에서 "utf8mb4_general_ci"을 고르고 오른쪽 상단에 "변경사항 저장"
5) 데이터베이스 수정 -> 파라미터 그룹 교체!

출처: 
https://hoonmaro.tistory.com/53
 [훈마로의 보물창고]

 

속도가 중요한 시대에, 빨리 구축할 수 있는 클라우드 환경에서 개념이 중요한가 싶기도 하지만,
도움을 줄 수 있는, 더 멋지고 나은 개발자가 되기 위해 개념 공부를 빼 놓으면 안되는 것 같다.
느리지만, 잘 하고 있다! (토닥토닥..)

 

https://aws.amazon.com/rds/?nc1=h_ls 

데이터베이스 관리 시스템 | 관계형 RDS | Amazon Web Services