규도자 개발 블로그
과연 도커(Docker) 컨테이너를 통해 데이터베이스를 운영하는 게 좋은 방법일까? 본문
과연 도커(Docker) 컨테이너를 통해 데이터베이스를 운영하는 게
좋은 방법일까?
개인적으로 만들어보고 싶은 웹 어플리케이션이 있어서 도커를 활용해보려고 했는데 데이터베이스와 관련한 부분에서 뭔가 삐걱대는 느낌이었다. 그도 당연할 것이 도커철학과 데이터베이스의 개념 자체가 정면충돌하기 때문이다.
도커는 이미지를 컨테이너화해서 없애고 만들고 하는 식으로 깔끔하면서도 배포환경과 개발환경을 동일하게 만들기 쉽게 해놨다. 만약 개발 및 배포환경으로 쓸 이미지를 구성하는 도중에 어떠한 설정이나 과정이 꼬여 무엇이 잘못된지도 모를 정도로 컨테이너가 망가져버린다면 그냥 컨테이너를 지우고, 새로이 이미지에서 컨테이너를 생성하면 된다. 그리고 완성하면 push명령어를 통해 도커허브에 올려두거나 아예 코드 자체를 볼륨에 추가시켜 그 상태로 빌드하여 배포해도 된다.
그렇다 도커라는 거 자체가 경량화된 가상환경의 빠른 생성과 파괴를 통해 원할한 배포 및 개발환경을 구성하는 데에 의의가 있다. 이것이 바로 도커철학이다. 하지만 여기에 데이터베이스가 접목된다면 이야기는 다르다.
데이터베이스는 말 그대로 영속(permanent)된 데이터를 위해 만들어진 개념이다. 여기에서 도커철학과 정면충돌한다. 도커 컨테이너의 빠른생성과 파괴라는 개념, 그리고 데이터베이스의 영속성이라는 개념이 말이다. 이 문제를 깨달은 것은 데이터베이스를 컨테이너로 구성하기 위해서 작업하던 도중이었다.
가장 크게 와닿은 건, 컨테이너는 제거하면 안의 내용이 전부 사라진다는 것이다. 컨테이너라는 것 자체가 휘발성이라는 위험을 안고 있다. 당신이 따로 VOLUME설정을 통해 해당 데이터베이스 컨테이너에서 다루는 데이터들을 서버의 특정장소에 따로 저장하지 않았다면 컨테이너를 제거하는 순간 영속돼야할 데이터가 다 날아간다. 하지만 우리가 컨테이너를 왜 쓰는가? 배포환경을 마치 모듈형 프로그램을 짜듯이 쉽게 제거하고 구성하고 생성하기 위해서 사용하는 것이 아닌가? 만약에 굳이 데이터베이스 컨테이너 연결을 통해 데이터베이스를 쓰겠다 하면 컨테이너의 휘발성으로 인한 데이터 삭제를 막기 위해 따로 외부에 VOLUME설정을 할 것이고, 데이터베이스는 sqlite를 제하고는 이것저것 꽤나 많은 설정들과 파일을 참고하여 작동하고 또 저장하므로 VOLUME설정 자체가 난관일 것이다.(나의 실력이 모자라서 그런 걸수도 있다.) 단순한 예를 들어 데이터베이스에서 쌓는 데이터만 들어간 바이너리파일 말고도 로그형식으로 모든 쿼리로그를 남기는 부분들에 대한 설정 같은 것들 말이다. 한 번의 볼륨설정으로 완벽한 데이터베이스 컨테이너 네트워크 구성이 힘들다는 얘기다. 이거 자체가 배포와 개발환경을 간소화하기 위해 쓰는 것이라는 도커철학에서 벗어나는 일이다.
대안은 있다. 첫번째로는, 그냥 데이터베이스만큼은 로컬에 설치하여 그것을 이용하는 것이다. 애초에 DBMS는 사이트 리뉴얼 수준의 대작업이더라도 바뀌지 않는 경우가 많기 때문이다. 어쩌면 생 string으로 짠 query내에서 해당 데이터베이스에서만 작동하는 내장함수를 썼을 수도 있고, 버전마다 다른 문법을 제공하는 경우도 있으니 말이다.
그리고 클라우드서비스를 사용하고 있다는 가정에서 사용할 수 있는, 더 나은 두번째 대안이 있다. 요즘에는 닭장형서버를 거의 쓰지 않으니 많은 사람들에게도 유용할 것이다. MicroSoft의 Azure나 GOOGLE의 GCP(Google Cloud Platform), Amazon의 AWS(Amazon Web Service) 등등 말이다. 이런 서비스를 제공하는 업체들은 대부분 데이터베이스만을 위한 서비스도 같이 존재한다. 다른 서비스는 안써봤으니 내가 사용해봤던 GCP만 예를 들어봐도 Mysql이나 PostgreSQL을 지원하는 Cloud SQL이란느 서비스가 있을 뿐더러 NoSQL을 위한 Cloud Datastore서비스까지. 아마 특수용도가 아닌 이상 각 플랫폼 업체에서 제공하는 데이터베이스 서비스로 커버가 불가능한 비즈니스는 없을 것이다. 애초에 그것을 상정하고 만들어졌기 때문이다. 그리고 원하는 시점마다의 데이터베이스 백업도 가능하다. 실수로 컨테이너를 날려 데이터베이스 컨테이너에 쌓여있는 데이터가 모두 날아가버리는 불상사, 혹은 로컬서버에 설치돼있는 데이터베이스가 뻑나서 재생이 불가능한 그런 곤란한 상황은 발생하지 않는다. 아니, 발생하더라도 수습 가능한 수준으로 복구할 수 있는 수단이 존재한다.
경험적으로도, 머릿속으로 서비스를 구상해봐도 확실히 도커와 데이터베이스는 서로 길이가 맞지 않는 젓가락 같다. 아니, 애초에 두 개념이 정면충돌하는 것 같아서 데이터베이스 컨테이너를 만들고 싶다는 생각이 전혀 들지 않는다. 그래서 나는 개인프로젝트를 일단 local에 있는 DB에서 진행한 뒤에 서비스가 거대해지면 클라우드 플랫폼에서 제공하는 데이터베이스 서비스로 마이그레이션하여 이용할 예정이다.
물론 이것이 정답은 아니며 개인적인 경험 및 생각에서 나온 글이라는 것을 알린다. 도커로 DB와 Web APP을 연결하는 과정에 있어서 계속 뭔가 찜찜한 기분이 들었기 때문이다. 그래서 혹시나 나와 같은 생각을 하고 있는 사람들이 있을까 하여 찾아봤는데 역시나 있었다. 그 글들은 아래에 링크로 남겨두겠다. 이 글 또한 아래 글들을 읽고서 정리한 내 나름대로의 생각이라는 것을 밝히는 바이다.
Ycombinator의 Hackernews란이다. 해당 이슈에 대해 열띈 토론이 있었다.
위 토론에서 논란이 됐던 글 : WHY DATABASES ARE NOT FOR CONTAINERS
Is Docker Good for Your Database?
Should You Run Your Database in Docker?
(위 글이 가장 감명 깊게 읽은 글이며 대안까지 제시해준 글이다)
