AWS to OCI

원래 이 기술 블로그는 AWS를 이용해서 EC2, RDS(MySQL), S3로 배포된 프로젝트였다.
어느날 우연히 OCI에 대해서 알게 되었는데, 매력적인 포인트가 꽤나 많았다.
일단 현 시점에서는 프리티어 기간이 무제한이고, OCI의 A1 Flex의 사양은 AWS의 t2.micro와는 비교가 안되는 정도였다.

백엔드 개발자의 역할은 기본 CRUD 구성에서 끝나는 게 아닌, 최소한의 비용으로 최대한의 트래픽을 받는 것이다.

가난한 개발자 지망생인 나는 바로 이주를 준비하게 됐는데, OCI가 꿀이라는 사실은 나만 모르고 있었단 사실을 깨달았다. OCI는 계정을 생성할 때 AWS와는 달리 리전을 선택하고 생성하는데 서울, 도쿄는 이미 만석이었고 춘천 리전에다 생성을 하게 되었다.

신나서 인스턴스를 생성하려던 찰나,

가용성 도메인 AD-1에서 VM.Standard.A1.Flex 구성에 대한 용량이 부족합니다. 다른 가용성 도메인에 인스턴스를 생성하거나 나중에 다시 시도하십시오.

라는 오류가 발생했고, 간단하게 찾아보니 프리티어에게 할당된 용량이 전부 차서 빈자리가 생길 때(미사용으로 인스턴스 삭제, 혹은 다른 이유로)까지 A1 인스턴스를 생성할 수가 없었다.

큰 금액은 아니지만 AWS는 IPv4 사용요금과 프리티어에 포함되지 않는 Route53 비용으로 내 짤짤이를 끊임없이 강탈하고 있었고, 마음이 급해진 나는 스크립트를 짜기 시작했다.

하지만 대충 12시간 정도 돌려봐도 인스턴스는 생성이 되지 않았고, 스크립트를 짜면서 얻은 정보에 따르면 운이 없다면 한 일주일 정도는 저걸 계속 돌려놔야 인스턴스를 생성할 수 있다는 답변이 대다수였다.

다른 방법이 없나 찾던 도중에, 프리티어가 아닌 결제 정보를 등록하고 유료 회원으로 전환을 하면 리전 내 프리티어 할당량과 관계 없이 생성이 가능하다는 정보를 얻어서

이 금액은 결제 확인용으로 결제된 뒤에 바로 취소된다.

바로 유료 회원으로 전환을 했고, 5시간 정도가 지난 후에 전환이 완료되었다는 메일을 받았다.

프리티어로 제공되는 A1 인스턴스(4cpu, 24GB RAM)의 최대 사양을 두 개로 쪼개(3cpu/18GB, 1cpu/6GB)각각 블로그용, RDS 대신 사용할 DB용으로 생성했다.

아예 탈 AWS를 하려고 DB를 RDS가 아닌 OCI 프리티어에서 제공하는 RDBMS로 바꿀까 고민도 했지만, 지금 기술면접이 얼마 남지 않은 내게는 MySQL 기반 DB를 Oracle 기반 DB로 마이그레이션 하는 과정에 쓸 시간이 없었다.

우선 DB 연결 전에 OCI에 생성한 블로그 인스턴스에 도커 이미지를 올리는 과정부터 진행했는데, 이 과정에서 몇가지 사소한 트러블들이 있었다.

1. 도커 이미지가 안열림, EC2의 t2.micro는 x86 기반이라 이미 빌드가 되어 docker hub에 올라가 있는 이미지는 linux/amd64로 A1 flex의 ARM 환경에서 열리지 않았다.
   해결 방법은 아주 간단했는데, 이미지 빌드를 linux/arm64 기반으로 진행하는 것으로 해결했다.

2. 빌드할 브랜치를 잘못 선택해, 기존 DB의 스키마 구조와 차이가 존재해서 A1 인스턴스에서 docker-compose up으로 서버를 실행할 때마다 DB가 초기화됨.
   위에서 사소한 트러블이라고 적었지만, 이 문제는 상당히 당황스러웠다. 아직 게시글도 몇 개 없고, 중요한 정보는 없다지만 테스트 게시글로 꽉 찬 블로그를 보며 깊은 한숨을 쉬게 만들었다. 다행히 RDS의 스냅샷 기능을 이용해 workbench로 DB를 local export 한 뒤, 그걸 다시 원래 RDS 인스턴스에 접속하여 import 하는 방식으로 해결했다.
   

하지만 이런 트러블들이 마냥 나쁜 점만 있는 건 아닌데
내가 한동안 즐겼었던 철권을 필두로 한 격투게임에는 다음과 같은 명언이 있다.

모르면 맞아야지

참 맞는 말이다. 개발을 처음 시작할 때 아무것도 모르고 RDS를 써보겠다고 GPT와 이리저리 볶다가 설정을 잘못해서 48시간 남짓한 시간으로 40$의 청구를 받았던 내 자신이 떠올랐다. 이번 프로젝트에서 그 두려움을 깨지 못하고 비용 발생에 쫄아서 RDS가 아닌 로컬 DB를 사용했다면 복구할 수 없었을 문제고, 도커 이미지 이주가 끝난 후에 DB 인스턴스 설정을 할 때도 참고사항이 되어서, cron으로 자동 백업을 하게 설정을 해뒀다.

저번에 썼던 Trade-Off가 여기서도 다시금 떠오르는데

비용 vs 번거로움

의 대결이 아닌가 싶다. 가장 유명한 관리형 데이터베이스인 RDS를 사용함으로 관리의 번거로움을 줄이는 대신 비용을 지불할 것인가.

혹은 별개의 인스턴스에서 DB를 직접 관리하며 비용을 없애는 대신 백업, 보안 등의 번거로움을 감수할 것인가.

결론적으로 지금의 나는 비용이 발생할 여지를 최대한 없애고, 약간의 번거로움은 가져가기로 결심했다.

어쨌든 CI/CD 파이프라인을 미리 구성해 놓은 덕에, 간단한 GitHub Actions 수정과 docker-compose의 수정만으로 쉽게 OCI로 이주할 수 있었고, 면접 후에 시간이 조금 생긴다면 유일하게 남은 S3도 어떤 식으로든 수정을 해서 완전히 탈 AWS를 하고 블로그에 한정해서는 비용 문제에서 벗어날 수 있지 않을까 싶다.