AWS RDS AURORA + NODEJS

AWS의 Aurora DB를 선택하고, Node에 붙여 넣었다.
Aurora는 프리티어가 없고, 제일 싼게 한달 3만원정도니 이용할 때 주의해야한다.
현재 회사에서 Cafe24에 있는 mySql을 AWS RDS로 환경이전을 하려고 준비 중이다.
개발관련 인력이 별로 없기에 내가 다 의사결정을 하고 있긴 하지만..
AWS RDS가 유지보수나 속도 측면에서 나을거라 판단했다.
다만 가격이 좀 있기에 오버스펙이지 않을까 하는 고민은 아직도 있다.
이건 프로젝트가 정확히 나와봐야 알 것 같고,
RDS를 실제 프로젝트에서 처음 써보는거라 어떤 식으로 운용해야 효율적일진 고민해봐야겠다.

모델구성

const mysql = require('mysql2/promise');
require('dotenv').config();
const mysqlRead = mysql.createPool({
connectionLimit : 50,
waitForConnections : true,
host: process.env.AWS_AURORA_MYSQL_READ_DB_PORT,
user:process.env.AWS_AURORA_MYSQL_READ_DB_USER,
password:process.env.AWS_AURORA_MYSQL_READ_DB_PW,
database:process.env.AWS_AURORA_MYSQL_READ_DB_NAME });

const mysqlWrite = mysql.createPool({
connectionLimit : 50,
waitForConnections : true,
host: process.env.AWS_AURORA_MYSQL_WRITE_DB_PORT,
user:process.env.AWS_AURORA_MYSQL_WRITE_DB_USER,
password:process.env.AWS_AURORA_MYSQL_WRITE_DB_PW,
database:process.env.AWS_AURORA_MYSQL_WRITE_DB_NAME
});

const mysqlMultiRead = mysql.createPool({ connectionLimit : 50, waitForConnections : true, host: process.env.AWS_AURORA_MYSQL_READ_DB_PORT, user:process.env.AWS_AURORA_MYSQL_READ_DB_USER, password:process.env.AWS_AURORA_MYSQL_READ_DB_PW, database:process.env.AWS_AURORA_MYSQL_READ_DB_NAME, multipleStatements : true }); module.exports = awsAuroraMysqlCreatePool = { mysqlRead, mysqlWrite, mysqlMultiRead }

커넥션이 아닌 풀을 선택했다.
노드랑 더 잘 어울릴 것이라 생각했다.
최대 리밋은 50으로 걸었고,

host는 rds 엔드포인트
user는 접속자 이름
password는 비밀번호
database는 접속할 DB
이게 기본이다.

추가적으로
multipleStatments라는 옵션을 true로 설정하는 pool도 있는데,
작업을 하다보면, 유저가 특정값을 입력하지 않은 영역인데,
쿼리를 2~3개씩 호출하는 곳이 있다.
이럴 땐 연결을 2~3번 하는 것은 비효율 적이라 생각해서 한번의 DB접속으로 정보를 들고 왔다.

const [talkDetail] = await mysqlMultiRead.query(query.talkDetail, [mainIdx, titleIdx]);

실제 사용할땐 이렇게 사용했다.
query는 따로 모듈로 만들어서 관리했고,
query.talkDetail에는 쿼리끝에 ;로 끝나는 쿼리가 3개 들어있다.

쿼리가 3개 들어있을 때,
talkDetail의 배열에 0,1,2 이렇게 쿼리값들이 들어온다.

이 방법의 단점은 사용할 때 talkDetail[0] 이런 식으로 사용하기 때문에 변수가 직관적이지 않고,
나중 유지보수 할 때 어려운 점이 있겠구나 생각이 들었다.
그래서 서비스로직을 돌리는 모듈을 따로 만들어 talkDetail[0]을 알아야하는 것이 아닌,
서비스 로직에 들어온 것으로 배열의 순서에 어떤 정보가 담겨있는지 파악했다.
(그래도 가독성이 좋지 않긴 했다.)

이제 NestJs TypeORM으로 작업을 시작하면 어떤 차이들이 있을지 생각해봐야겠다.
현재는 시퀄라이즈등 orm을 쓰지않고, 직접 쿼리를 날려서 보내고 있다..