📖 OTT 프로젝트의 DB서버
OTT 프로젝트의 DB서버는 Oracle XE 11g 버전을 이용하여 구동되고 있다. 프로젝트의 DBMS로 특별히 오라클을 사용하게 된 것에 어떤 특별한 이유가 있었던 것은 아니었다.
프로젝트를 시작하기 전에 학습용으로 사용했던 DB가 오라클이었고, 나뿐만 아니라 모든 팀원들이 전부 오라클로 공부를 해왔으니 자연스럽게 프로젝트에서도 오라클을 사용했을 뿐이다.
그런데 이번에 프로젝트의 배포작업을 진행하면서 DB서버 선택에 대한 고민이 생겼다. 배포환경에서도 오라클을 계속 사용할 것인가 아니면 다른 DBMS의 전환을 생각해 볼 것인가에 대한 고민이었다.
이러한 고민의 배경에는 2가지의 사실이 있었다.
첫 번째로, Oracle XE의 서비스는 시중에 선택 가능한 다른 무료 DBMS에 비해서 여러가지 제한이 따른다는 것(메모리 사용률 제한, 전체 디스크 사용률 제한 등)
두 번째로, 만약 DB 배포서버로 AWS RDS를 이용하고자 한다면 RDS에서는 오라클의 XE 버전은 지원하지 않기 때문에 라이선스를 구입하지 않는 한 무료로 오라클을 이용할 수 없다는 것.
개발서버에서 오라클을 사용했다고 배포서버로까지 굳이 오라클을 선택할 필요는 없었기 때문에 위의 2가지 이유를 생각하면 다른 DBMS로 전환하는 것이 합리적이지 않을까?라는 고민이 들었다.
그리고 이 고민에 대한 결론은 그냥 오라클을 계속 이용하는 것이 되었다🤣
사실 OTT 웹사이트는 배포를 한다고 하더라도 일종의 템플릿 사이트의 공개 및 그 과정의 학습이 주목적이지 실 서비스를 염두에 둔 것은 아니다. 따라서 Oracle XE의 제한사항 정도는 그렇게 신경 쓰이는 정도는 아니었다.
그리고 AWS의 RDS는 이용하지 않기로 결정했다. 이번 배포과정을 통해서 Docker를 공부하고 익히는 것이 주목적 중 하나였기 때문이다. RDS로 새로운 DB서버 하나를 장만하는 것도 괜찮은 선택 같았지만 Docker 학습이라는 목표에 중점을 두고 기존 서버에서 DB서버용 컨테이너를 만들고 해당 컨테이너를 관리하는 식으로 진행해 보고자 하였다.
그리고 이왕이면 개발과 배포환경이 최대한 같았으면 하는 마음도 내심 있었고(귀찮으니까...😊)
그렇게 DB서버를 컨테이너화 시키는 작업이 결정되었다.
🔍 DB서버의 컨테이너화에 대한 고민
DB서버를 컨테이너화 시키면서 해결해야만 하는 과제 중 하나는 바로 DB서버가 운용하고 있는 데이터의 안정적이고 영구적인 보관의 보장이었다. docker에서 사용되는 컨테이너라는 개념은 결국 리눅스의 프로세스 격리기능을 이용한 일종의 가상화 기술이다. VM과 같이 하드웨어 자체를 가상화하는 것은 아니지만 호스트 서버에 떠있는 프로세스들을 완벽하게 격리(고립)시켜 마치 각 프로세스들이(컨테이너) 별도의 서버로서 실행되고 있는 것처럼 가상화를 실현한 것이 바로 docker가 제시하고 있는 컨테이너라는 개념이다.
즉 Docker를 실행하고 있는 호스트의 입장에서, 자신이 띄우고 있는 컨테이너란 결국 하나의 프로세스에 지나지 않는다. 이렇게 프로세스 레벨에서 별도의 독립된 가상서버환경을 쉽게 마련해줄 수 있다는 컨테이너의 특성은 VM과 비교해 보면 커다란 장점으로 보인다. 굉장히 손쉽게 자신이 원하는 시스템을 띄우고 또한 내릴 수 있다는 유동성을 확보했으니까. (물론 성능적인 장점은 말할 것도 없다)
결론적으로 컨테이너는 사용자가 원하기만 하다면 얼마든지 쉽게 올릴 수 있고 또 쉽게 내릴 수도 있다는 유동적인 느낌의 성격을 강하게 지니고 있다. 그리고 유동적이라는 것은 어떻게 보면 휘발성이 강하다고도 말할 수 있을 것 같다. 불필요하다고 판단된 컨테이너를 삭제하겠다고 결정한 그 순간, 컨테이너에 쌓아온 모든 정보를 순식간에 전부 사라지게 만들 수 있다는 것이니까.
딱히 컨테이너 가지고 있는 휘발적인 성격에 대해서 장단점을 따지려는 것은 아니지만, DB서버를 컨테이너화 시켜 관리하려는 나의 목적에 있어서는 약간의 고민거리가 되었다. RDBS에서 휘발성이라는 단어는 그다지 어울리지 않았으니까 말이다. 따라서 DB서버를 컨테이너화 시키더라도 DB데이터 자체는 호스트서버에 따로 저장하고 싶다는 생각이 들었다. 컨테이너가 만약 삭제되더라도 DB 데이터는 안정적으로 보존될 수 있도록 말이다.
✨ 도커 Volume 혹은 Bind Mount를 이용한 데이터 관리
위와 같은 고민을 해결하기 위해 도커에서 공식적으로 지원하는 데이터 관리 방법으로는 총 2가지 방식이 존재했다.
도커 Volume과 Bind Mount 기능이었다.
두 방식은 컨테이너와 호스트 사이에 일종의 공유 디렉토리를 만들어주는 행위라는 것에서는 동일했다. 호스트와 컨테이너를 링킹하는 공유디렉토리를 만들어 컨테이너의 밖에서도 데이터를 관리할 수 있도록 하는 것이다.
두 방식의 차이라면 Bind Mount 방식은 호스트의 운영체제 및 그 파일시스템 구조에 따라서 영향을 받게 되지만, Volume 방식은 Docker의 영역에서 데이터에 대한 관리를 처리하게 되므로 호스트 서버와 독립적이라는 세부적인 차이가 있었다. 따라서 공유 디렉토리를 만들 때 Bind Mount 방식보다는, 특정 환경에 종속되지 않고 범용적으로 사용할 수 있는 Volume 방식이 더 안정성이 있고 도커측에서도 공식적으로 추천하고 있는 방식 같았다. 다만 나는 Bind Mount 방식을 이용하는 데 있어서 딱히 문제점이 없을 것 같다고 판단했기 때문에 Bind Mount 방식으로 호스트 로컬에서 직접적으로 데이터를 관리하는 방식으로 진행하기로 하였다.
