AWS RDS 튜토리얼

AWS RDS를 간단히 알아본 후 직접 사용해봅니다.


AWS RDS란

Amazon Relational Database Service(Amazon RDS)는 AWS 클라우드에서 관계형 데이터베이스를 더 쉽게 설치, 운영 및 확장할 수 있는 웹 서비스입니다.

관계형 데이터베이스를 효율적이고 경제적이게 관리할 수 있고 다양한 기능들을 제공하며 번거로운 관리 작업을 대신해줍니다.

그렇다면 AWS EC2 인스턴스에서 직접 데이터베이스를 구성하는 것과 RDS를 통해 구성하는 것은 어떤 차이가 있을까요?

AWS EC2와 RDS의 차이

먼저 AWS EC2는 온프레미스 환경에서 하드웨어를 구성할 필요 없이 클라우드 환경에서 하드웨어의 설정을 유동적으로 할당하며 온프레미스 환경에서 관리해야 하는 부담을 일부 덜어줄 수 있습니다.

물론 온프레미스 환경이나 클라우드 환경이나 모두 고객이 관리해야 하는 부분이 많지만, EC2 인스턴스가 선호되는 이유는 서버 유지관리, 하드웨어 수명, 전력 및 네트워크에 대한 부담을 AWS에서 책임지기 때문입니다.

하지만 AWS EC2는 완전관리형 서비스가 아니므로 AWS EC2에서 직접 구성한 데이터베이스가 특정할 수 없는 문제로 인해서 데이터베이스에 문제가 생기게 된다면 그 문제를 파악하기 위해 리소스가 필요합니다.

AWS RDS는 번거로운 수동 작업을 처리할 필요 없이 인프라적인 요소보다 개발에 더 집중할 수 있게 됩니다.

image

RDS 직접 구성해보기

먼저 AWS Console에 이동합니다.

image

그 후, AWS 서비스 중 RDS를 검색해서 AMAZON RDS 대시보드로 이동합니다.

image

화면에 보이는 데이터베이스 생성 버튼을 클릭하면 생성 화면으로 이동하게 됩니다.

image

MySQL 8.0.28 버전을 사용하기 위해 엔진 옵션을 아래와 같이 설정합니다.

image

실제 서비스에 사용하지 않을 것이므로 템플릿은 프리티어로 , 설정은 직접 원하는 인스턴스 식별자와 마스터 정보로 작성합니다. (마스터 정보는 DB에 접근하는데 필수적으로 사용되므로 꼭 기억하셔야 됩니다)

image

인스턴스와 스토리지에 대한 설정을 추가로 할 수 있는데, 테스트를 위한 RDS이므로 가장 경량 인스턴스인 t3.micro와 마그네틱 스토리지를 사용하겠습니다 (마그네틱은 실제 서비스 상에서 권장되지 않습니다)

image

그 후 VPC 설정이 필요한데, VPC란 AWS에 마련된 가상 네트워크입니다. VPC를 통해 AWS에 구성되어 있는 각 인스턴스들의 구성 영역을 그룹으로 묶어 지정할 수 있으며 각각의 VPC에 따라 다르게 설정하고 완전히 독립된 네트워크처럼 동작하게 됩니다.

저는 어디에서나 접근이 가능하도록 설정을 원하기 때문에 그 경우에는 퍼블릭 액세스를 예로 선택하고 그 외에는 모두 기본값으로 선택하면 됩니다. 기본값으로 선택하게 되면 현재 네트워크에서만 접근이 가능합니다. (이미 구성된 VPC가 있고 그 VPC로 적용하고 싶다면 기존 VPC를 선택하시면 됩니다.)

image

마지막으로 데이터베이스 인증 설정인데, 이전에 만들었던 마스터 암호만으로 접근할 예정이기에 암호 인증을 선택 후 데이터베이스를 생성합니다.

image

생성을 하게 되면 , 아래와 같이 데이터베이스가 완전히 생성되는 데까지 시간이 좀 걸립니다.

스크린샷 2022-06-12 오후 9 43 23

만들어진 RDS 연결해보기

만들어진 RDS에 연결을 시도하기 위해서 CLI나 GUI가 필요합니다.

저는 MySQL CLI를 통해 연결을 시도해보겠습니다. (MySQL 설치가 필요합니다)

mac의 경우 간단히 brew install mysql을 통해 설치가 가능합니다.

mysql -u <MASTERUSER> --host 엔드포인트 -P <DBPORT> -p

스크린샷 2022-06-12 오후 9 49 27

클라우드 환경에서 RDS는 언제 사용해야 할 지

서론에서는 RDS의 장점에 대해서 중점적으로 글을 썼다면 , 결론에서는 RDS의 이면에 대해서도 말을 해보려 합니다.

RDS는 EC2 인스턴스를 기반으로 운영하는 서비스 입니다.

RDS 인스턴스 요금은 기본 인스턴스 크기, 데이터 스토리지, 멀티 가용영역, 데이터 전송에 따라 달라지고 각 데이터베이스(MySQL, Oracle 등) 엔진마다 위의 요소들에 대해 다른 요금을 적용하기 때문에 기업이 비용 측면에서 고려해야 할 부분이 더 많아집니다. 게다가, Aurora를 사용할 경우 추가적으로 I/O에 대한 비용이 발생합니다.

총 비용을 따져보면 고용량 데이터베이스를 사용할 경우 RDS 인스턴스의 비용이 예상보다 높을 수 있습니다. 또한 데이터베이스에서 특히 새로운 어플리케이션에서 필요한 사용량, 스토리지 등에 대해 예측하기 어려울 수 있습니다. 그리고 자체 하드웨어 또는 인스턴스에서 운영하는 것보다 실제 성능이 훨씬 낮을 수 있습니다.

AWS 클라우드 환경에서 데이터베이스를 사용하기 위해선 RDS나 EC2에 데이터베이스를 직접 설치하는 두 방식으로 좁혀지게 되는데, 직접 지불하는 비용만 놓고 보자면 기존에 사용하던 EC2가 있다면 해당 인스턴스에 직접 데이터베이스를 구성하는게 낫습니다. (이는 데이터베이스 뿐만아니라 메시지 큐같은 써드파티 모듈도 동일합니다)

하지만 RDS를 사용할 경우 본론에서 말했다시피 빠른 시간으로 구성하고 인프라적인 요소보다 개발에 집중할 수 있게 됩니다.

또한 데이터베이스를 직접 관리하는 데에 드는 비용이 줄어들고 스토리지의 LUN을 구성하고 더 나은 I/O를 위해 스트라이핑(Striping)을 최적화하는데에 시간과 노력을 쓸 필요가 없습니다.

간단하게 인스턴스 크기를 축소 및 확장할 수 있으며, 클릭 한번으로 간단하게 높은 가용성을 이룰 수 있습니다. 이러한 모든 기능들을 통해 기업은 데이터베이스 도입 및 관리하는 데 있어서 시간과 노력을 줄일 수 있는 것입니다. 약간의 추가적인 요금이 발생하긴 합니다. 하지만 이를 통해 단축된 도입 시간은 시장에서 두드러진 성과로 이어질 수 있습니다.

모든 PaaS 서비스의 취약점 중에 하나는 사용 중이지 않을 때도 상관없이 계속 비용을 지불해야만 한다는 점입니다. 하지만 최근 AWS의 RDS 업데이트를 통해 더 이상 사용 중이지 않을 때에 대한 불필요한 비용을 지불하지 않아도 됩니다. (이는 비용 절감으로 이어집니다)

AWS RDS도 단점과 그를 보완하는 이점이 공존하기 때문에, 상황에 따라 선택해야 하고 잠재적 기회 비용을 파악하고 선택하는 게 현명합니다.

Categories:

Updated:

Leave a comment