백엔드가 이정도는 해줘야 함 - 10. 데이터베이스 선정과 인스턴스 시작

이번엔 서비스 운영을 위한 메인 데이터베이스를 결정하고, AWS 클라우드 위에서 해당 데이터베이스 엔진을 사용하는 인스턴스를 하나 띄워보자. 가상 컴퓨팅 환경 하나 단위를 AWS에서는 인스턴스라고 부른다.

도입 이유

데이터베이스

데이터베이스는 엑셀을 떠올리면 된다. 데이터베이스의 가장 중요한 특성은 구조화된 데이터를 관리한다는 점이다. 'ID', '비밀번호'처럼 컬럼에 따라 데이터를 정리하고, 어떤 기준을 통해 데이터를 정렬하고, 필터링할 수 있다. 굳이 엑셀 안 쓰고 데이터베이스를 쓰는 이유는, 데이터베이스라는 것 자체가 데이터를 추가/변경/삭제/조회하는 작업이 더 구조화되어 있고 빠르기 때문이다. 잘 모르겠다면 이고잉님의 강의인 데이터베이스란?을 보고 오자.

이 세상엔 수많은 형태와 종류의 데이터베이스가 있다. 형태로 치자면 RDB(Relational Database)와 NoSQL(Not only SQL)로 나눌 수 있고, 종류로 치자면 빅데이터 쿼리를 분산 처리하기 위해 개발된 PrestoDB, key-value 형태의 구조로 캐싱 용도로 자주 쓰이는 redis나 memcached, 시계열성 데이터를 저장하는 데에 특화되어 있는 InfluxDB같은 특별한 제품들이나 MySQL, PostgreSQL 등 전형적인 RDBMS가 있을 수 있다.

위에서 이야기했듯 이번 의사결정은 서비스 운영을 위한 메인 데이터베이스를 결정하는 것이라, PrestoDB, druid, InfluxDB같이 특별한 목적을 위해 만들어진 데이터베이스를 사용하진 않을 것이다.

의사결정

RDB vs NoSQL

배경과 요구사항

• 모든 스키마가 고정되어 있다.

• 엄청나게 빠른 속도를 요하진 않는다.

• 되도록이면 AWS가 관리형으로 제공하는 인프라에서 사용할 수 있어야 한다. EC2에서 데이터베이스 서버를 직접 관리해야 하는 일이 없도록 만들고 싶다.

선택지

• RDB

• NoSQL

의사결정

RDB를 선택하겠다. 그 이유는,

• 'NoSQL은 schemaless여서 더욱 유연한 형태로 데이터를 저장할 수 있다'고 하지만, 우리가 개발하려는 것을 포함해 대부분의 서비스는 스키마가 유동적인 경우가 거의 없다.

• NoSQL은 'scale out(접속된 서버의 대수를 늘려 처리 능력을 향상시키는 것)이 가능해서 scale up만 가능한 RDB에 비해 단일 장애 지점도 없고 비용도 적고 클러스터에서 잘 동작하도록 만들어져 있다'라며 퍼포먼스와 장애 대응에 관한 메리트를 어필하곤 하는데, RDB에서도 master-slave 모델을 사용하면 이런 문제들을 충분히 커버할 수 있다. 이는 읽기 전용 인스턴스(slave)를 만들어 데이터를 복제시키는 것인데, 이정도만 해도 웬만한 수준의 서비스 트래픽을 다 감당할 수 있다고 판단했다. master가 죽은 경우 slave가 master로 승격하는 구조를 만들면 장애 복구도 잘 되고 말이다.

• 평균적으로 NoSQL이 RDB보다 빠른 것이 맞고, 동일한 비용을 사용했을 때 퍼포먼스로 치면 웬만하면 NoSQL이 가성비가 좋다. 그러나 이건 우리가 어떤 RDB 제품을 사용하느냐에 따라 다르다.

• NoSQL 데이터베이스 서버를 AWS에서 운영하려면, 대부분의 경우 EC2 위에서 직접 돌려줘야 한다. MongoDB의 경우 최근에 출시된 DocumentDB를 사용해볼 수 있는데, 아시아 쪽에선 아직 서비스가 오픈되지 않았다. 결국은 관리 포인트가 늘어날 것이며 이를 감당하기 어려운 상태다.

• 나도 NoSQL을 좋아하고 MongoDB를 많이 써봤지만, '많이 써봤으니 쓰기 편해서'라는 이유밖에 얘기하지 못 하겠다. Document DB의 장점을 살릴만한 곳이 별로 없다.

데이터베이스 호스팅 위치

배경과 요구사항

• 우리는 RDB를 사용하기로 했다.

• EC2에서 직접 데이터베이스 서버를 관리하는 것은 설정, 패치, 백업과 같은 시간 소모적인 관리 작업이 많아지며 안정성을 보장하기 어렵다. 따라서 AWS에 인프라 관리를 양도하는 관리형 서비스가 있다면 이를 사용하고자 한다.

선택지

데이터베이스 서버 관리를 직접 하느냐, AWS에게 관리를 양도하느냐의 차이다.

• EC2

• RDS(Relational Database Service)

의사결정

RDS를 선택하겠다. 그 이유는,

• 동일한 워크로드(하드웨어 요구량)를 기준으로 했을 때 EC2의 비용이 더 적을 수는 있겠으나, 데이터베이스 서버를 직접 운영하는 것은 정말 큰 관리 포인트다. 백업과 복구 정도만 생각해도 아득하다. 이런 건 그냥 돈 좀 더 내는 게 낫다고 생각한다(물론 여기선 어차피 free tier를 쓸테니 이런게 딱히 상관은 없겠지만, 의사결정의 이유니까 알아두고 넘어가자).

• 관리형 서비스가 없는 데이터베이스를 선택한 경우 어쩔수 없이 EC2에 올려야겠지만, RDS는 대부분의 메이저한 RDB 엔진을 지원하며 그 외의 RDB 중에서는 굳이 EC2에서 직접 프로비저닝할 정도의 메리트가 있는 것도 딱히 없다.

데이터베이스 엔진

배경과 요구사항

• 우리는 Amazon RDS를 사용하기로 했으므로, RDS에서 사용 가능한 데이터베이스 엔진을 선택지로 두어야 한다.

• 조직이 MySQL에 익숙한 상태다.

• Python에서 주로 쓰는 ORM 라이브러리인 SQLAlchemy나 Peewee에서 지원하는 데이터베이스여야 한다.

• 서비스 초기이므로, 한동안이라도 비용이 발생하지 않는 방향이면 더 좋다.

선택지

• Aurora
• MySQL
• MariaDB
• PostgreSQL
• Oracle
• SQL Server

의사결정

MySQL을 선택하고, 추후 Aurora로 마이그레이션하겠다. 그 이유는,

• Aurora는 AWS가 개발한 RDBMS인데, 클라우드에서 잘 구동되도록 설계되어 비교적 빠르고 비용도 싸다. 하지만 다시 역으로 비용 문제가 있는데, Aurora를 RDS에 띄우는 경우 free tier가 지원되지 않는다.

• PostgreSQL은 RANK같은 엔터프라이즈 데이터베이스의 기능들을 꽤 가지고 있는데, 지금 우리의 서비스에서는 사용할 일이 많을 것 같지도 않고 사용 경험도 없어서 메리트가 딱히 없다고 판단했다.

• 조직이 MySQL에 익숙하며, 메인 데이터베이스로 MySQL을 사용하는 것에 딱히 걸리는 점이 없다.

• 어차피 AWS 가입 후 1년이 지나면 free tier가 지원되지 않으므로 비용 효율이 좋은 엔진으로 마이그레이션을 고려하게 될텐데, Aurora는 MySQL과 호환되며 MySQL보다 3~4배 정도 빠르므로 그 대상이 된다. 사실 Amazon 인프라에선 Aurora만한 RDB가 없는데 free tier 때문에 잠시 동안만 MySQL에 머물러 있는 것이라고 생각하면 된다.

작업

데이터베이스 인스턴스 시작

Amazon RDS 자습서를 보고 따라하자.