현재 개인프로젝트 dam-witter는 플래닛 스케일에서 무료 데이터베이스 서비스를 사용하고있다.
플래닛 스케일은 서버리스 무료 데이터베이스 플랫폼이다. 자세한 것은 플래닛 스케일 홈페이지 참고 할 것을 바란다.
개인 프로젝트 제작 및 고도화 당시, 모든 API 요청이 느린 이유를 파악하기가 힘들었다.
데이터베이스의 region을 확인 할 생각을 하지못한 터였다.
서울에서 사용하는데 미국에 데이터베이스를 두고있으니 지연시간이 일어날 수 밖에 없었다.
아악 내눈!
플래닛 스케일은 무료 버전(Hobby)에서는 하나의 데이터베이스와 두 개의 브랜치만 생성하여 사용할 수 있다.
또한, 특정 브랜치의 region을 변경하는 것은 버전을 업그레이드 해야만 사용할 수 있다.
그렇기 때문에 이전의 브랜치에서 데이터를 백업하고 새 브랜치에 복원 시키는 작업을 로컬에서 수동으로 진행했다.
현재 프로젝트에서 사용하는 브랜치는 AWS us-east-1 로 설정 되어 있다.
서울과 가까운 region인 AWS ap-northeast-1(도쿄)로 설정해서 새 브랜치를 만들어준다.
내가 사용할 브랜치를 Branch settings에서 Promote to production 으로 프로덕션 브랜치로 변경해주면 프로덕션이 아닌 브랜치를 삭제할 수 있게 된다.
하지만! main 브랜치를 삭제하기 전에, 이미 브랜치에서 존재하던 데이터들을 모두 옮기기 위해서 백업과 복원 작업을 한다.
플래닛 스케일 공식 문서는 굉장히 친절하게 잘 되어있다. : Changing branch and database regions
pscale database dump <데이터 베이스 이름> <백업할 브랜치 이름>
나는 dam 데이터 베이스에서 main 브랜치를 백업한다.
$ pscale database dump dam main
해당 명령어가 실행이 완료되면,
루트 디렉토리에 PSCALE_DUMP_[데이터 베이스 이름]_[백업한 브랜치 이름]
으로 디렉토리가 생성되고 그 아래에 백업 파일들이 생성된다.
생성된 백업 디렉토리 | 스키마 | 데이터들 |
---|---|---|
pscale database restore-dump <데이터 베이스 이름> <백업한 데이터를 복원할 새로운 브랜치 이름> --dir <백업한 파일의 디렉토리 경로>
$ pscale database restore-dump dam deploy --dir /Users/ijihyeon/Desktop/nomad/react2/dam-witter/pscale_dump_dam_main
새 브랜치에 이미 테이블이 존재하기 때문에 복원할 수 없다는 경우가 종종 나왔다.
그런 경우에는 직접 해당 브랜치에 들어가서 테이블들을 직접 제거해줬다.
$ pscale shell dam deploy
dam/|⚠ deploy ⚠|> SHOW TABLES;
+---------------+
| Tables_in_dam |
+---------------+
| Comment |
| Like |
| Profile |
| Tweet |
| User |
+---------------+
dam/|⚠ deploy ⚠|> DROP TABLE IF EXISTS Comment;
dam/|⚠ deploy ⚠|> DROP TABLE IF EXISTS `Like`;
dam/|⚠ deploy ⚠|> DROP TABLE IF EXISTS Profile;
dam/|⚠ deploy ⚠|> DROP TABLE IF EXISTS Tweet;
dam/|⚠ deploy ⚠|> DROP TABLE IF EXISTS User;
dam/|⚠ deploy ⚠|> exit
아래는 실제로 복원이 잘 되었을 경우 알려주는 메시지.
Starting to restore database dam from folder /Users/ijihyeon/Desktop/nomad/react2/dam-witter/pscale_dump_dam_main
Restore is finished! (elapsed time: 1.811989791s)
공식문서에서는 pscale branch promote <DATABASE_NAME> <BRANCH_NAME>
명령어를 사용하여 프로덕트 브랜치로 승격하라고 한다.
하지만, 나는 명령어를 사용할 경우 "Error: internal error, response body doesn't match error type signature”
라는 에러가 발생하고 있다.
프로덕트 브랜치로 얼른 승격하고 싶은 마음에, 플래닛 스케일 페이지에 직접 접속하여 프로덕트 브랜치를 변경했다. (글 초반의 내용)
플래닛 스케일의 깃이슈에서 해당 에러를 검색해보니 중국에서 접속했냐라는 이야기가 있었는데, 나는 로그인을하고 브랜치 승격에서 에러가 발생한 것이라 다른이유라고 생각이 든다. 나중에 추가로 필요해지면 더 찾아볼 생각이다.
프로덕트 브랜치가 아니라면 바로 삭제할 수 있다.(default 브랜치가 아니라는 의미)
플래닛 스케일에서 해당 데이터 베이스 branches 에서 사용하지 않는 브랜치를 삭제한다.
이전에 언급한 개인 프로젝트 dam-witter를 진행할 때, 백엔드 지식이 다소 부족했었기에 데이터 베이스의 region문제로 인해 느려지는 것을 깨닫지 못했다.😇
그래서 느리게 응답하는 API에 대하여 클라이언트에서 낙관적 업데이트와 로더를 추가 했었다.
(어떻게든 살려보겠다는 발악..)
Next.js API route를 사용하고 있는데 이 서버리스 함수가 이렇게 극악의 콜드 스타트를 유발하는 것인가?
라는 관점으로 생각했었다. 하지만, 웜 스테이트일지언데도 왜 느린지에 대해서 의문을 가져 더 찾아보았고 이 글을 쓰게 되었다.
이번 계기로 변경한 데이터 베이스의 region의 latency를 비교 해봤다.
Region | Latency |
---|---|
us-east-1 (Virginia) | 218 ms |
ap-northeast-1 (Tokyo) | 44 ms |
얕은 지식과 안일한 생각으로 선택했던 데이터 베이스 region 선택 덕분에 말도 안되는 지연을 맛도 봐보고,(모든 API 응답은 2~3초는 기다려야 함) 데이터 베이스의 백업과 복원을 찾아보고 해볼 수 있는 좋은경험이 되었다.(비록! 플랫폼 이지만!)
사실은 백업과 복원 작업을 해보면서 플래닛 스케일에 계정도 하나 더 만들어서 작업해보기도 했다. 하하..😇
기승전결이 완벽한 글이네요, 너무 재밌게 읽고 갑니다 :)