사실 이번에 대부분의 아키텍쳐를 Serverless(서버리스)로 옮길려고 한다. 이유는 단지 비용을 최소화해보려는 하나의 노력이 되겠지만 언제든지 다시 VPS로 옮길 수 있도록 하고 싶었다. 하지만 Serverless 플랫폼에서는 Scaling을 직접 조작할 수 없는 환경일 수도 있기 때문에 데이터베이스 연결 등 여러가지를 추후 더 고려해야 한다.


Serverless와 싱글 컨테이너

Serverless와 타 클라우드 플랫폼의 가장 큰 차이점은 Scaling에서 두드러진다. 애초에 Serverless라는 개념은 온라인 서비스를 하려면 서버가 있어야 하므로 용어에서부터 이미 말이 안되는 것이 사실이지만 일단은 개발자(고객)가 실제로 서버 측에 할 일이 없다는 것을 뜻한다.

Image result for serverless
https://docs.microsoft.com/en-us/samples/azure-samples/serverless-microservices-reference-architecture/serverless-microservices-reference-architecture/

실제로 개발자는 모든 것이 준비된 환경에서 시작할 수 있다. 애플리케이션은 자동으로 사용자 수에 맞게 스케일링될 것이고 결국에는 우리는 코드만 업로드하면 하나의 앱을 배포하는 과정은 사실 완료한다고 보아도 된다.

알 수 없는 사이즈로 스케일링

하지만 이는 생각보다 많은 차이점을 가지게 되는데 스케일링이 끝도 없이 계속된다면 하나의 애플리케이션 배포판은 n개의 데이터베이스 연결을 가지게 되고 결국에는 데이터베이스 서버로의 예상치 못한 부하로 이어질 수 있게 된다. 결국에 애플리케이션 단에서는 데이터베이스 연결을 통제하지 못하기 때문에 서버 측에서 일정 조건이나 주기적으로 정확한 데이터베이스 연결 수를 확인하는 것이 훨씬 효율적일 것이다. 애플리케이션 상으로는 어떤 배포판을 가지고 테스트하나 n개의 연결을 가지고 있을 뿐이다.

위 라이브러리는 MySQL 데이터베이스를 Serverless 환경에서 안정적으로 사용할 수 있는 대책을 제공한다. 모든 쿼리 작업이 끝났을 때 end 함수를 호출하여 서버 단의 실제 데이터베이스 서버와의 연결 수를 확인하는 쿼리를 보내고 연결이 과도하게 중첩되는걸 막도록 한다.

라이브러리 가용성

하지만 위 라이브러리를 사용하게 되면 쓸데없이 연결 수를 확인하는 과정에서 너무 많은 자원 소모가 일어난다. 실제로 필요한 쿼리 수보다 최소한 2번 더 많은 쿼리가 일어나는 셈이라고 볼 수 있다. 물론 물리적인 혹은 Fresh installed 상태인 애플리케이션 서버를 실제로 준비하지는 않으므로 애플리케이션 비용은 실제로 담당할 일이 아니라고 할지라도 더 확인할 것이 많다.

예를 들면 ORM 라이브러리나 SQL 빌더와의 관계적인 연장선이다. SQL 빌더가 Raw SQL을 직접 쿼리하는 대신 생성하게 만들 수는 있겠지만 실제로 ORM 라이브러리에는 serverless-mysql 라이브러리에 대한 드라이버가 존재하지 않으므로 드라이버를 만들거나 데이터베이스 관련 로직에 추가 작업이 필요하다고 보아야 한다.

라이브러리 드라이버 호환성

아직 실제로 테스트해보지는 않았지만 주로 사용하는 Knex SQL 빌드와는 호환될 것으로 보이지는 않다. 끝에서 end 함수를 따로 호출해야 한다는 중요한 사실이 숨어있고 둘 다 Promise를 리턴하긴 하지만 serverless-mysql은 하나의 또 다른 Wrapper로써 작동한다.

빨리 현재 Serverless 전체를 압도할 수 있는 MySQL 데이터베이스 라이브러리가 나왔으면 혹은 옵션의 추가를 고려할 수도 있겠지만 아직은 실제로 사용할 수 있는 수준이라고 생각하지 않는다.