제목에 있는 내용이 다에요. DB를 꼭 컨테이너화할 필요가 있을까요? 갑자기 궁금한 마음에 이곳에 문의합니다.
5 Likes
@hhchang0808 님의 의견에 아래 의견도 같이 넣어봅니다.
DB를 Container화하면 DB의 자원 (CPU, Memory, I/O) 변동성이 커지고 예기치 않은 장애가 발생하기 쉽다?!?!?
Container화된 DB는 Lifecycle 관리, Storage Persistence, Backup · 복구 전략 등이 전통적 환경보다 취약해지기 쉽다?!?!?
DB는 일반적으로 Stateful이며, 이를 Container화된 환경에서 운영하면 Overhead나 예측 불가능한 변수가 생긴다?!?!?!
2 Likes
컨테이너를 사용하는 목적이 1. 환경 일관성 확보 및 재현성 2. CI/CD 통합 용이, 3. 빠른 생성/삭제에 있다고 보는데, 그래서 개발/테스트 서버 DB는 컨테이너로 많이 띄웠던 것 같습니다. 하지만 운영 DB는 보통 개발팀에도 접근권한이 없는 경우도 많이 있고 한 번 생성하고 스키마가 결정되면 초기화나 제거를 할 일도 없는 경우가 대부분인데 이러한 컨테이너의 이점이 많이 있을까 싶습니다. 운영 난이도도 많이 올라갈 것으로 보입니다.
HA 가 필요할 경우 제가 겪은 프로젝트들에선 따로 k8s+Statefulset 구성하기보단 대부분 AWS RDS/Aurora 와 같은 클라우드 기반의 서비스를 활용했습니다.
4 Likes
@yoohee.chung 님! 답변 감사합니다. 
2 Likes
전 사실 꼭 그럴 필요는 없다. 즉 업무의 특성이나. 운영 난이도 등등 이런거 저런거 다 판단해서. 좋은 쪽으로 결론을 내면 됩니다.
컨테이너 환경이 좋은 경우 예를 들면 마이크로 서비스처럼 업무가 딱딱 쪼개 질 수 있고 그로 인해 무거운 업무가 많이 가벼워 졌다면 운영의 편의성이나. 그런 걸 고려해서 디비도 전체 그림에서 컨테이너로 운영해도 됩니다. (예를 들면 CNPG 같은거)
그런데. 그런 부분이 아니고.. 금융이나 이런 다중의 트렌젝션이 묶여서 돌아가는 시스템이고 각 업무별 데이터가 강한 연결고리가 있다면 뭐 이런 겨우라면 그냥 온프라미스의 장비로 구축하는게 맞을수도 있습니다.
항상 느끼는건데 꼭 그렇게 해야 하는건 아닙니다.
5 Likes
저도 이 문제는 “정답이 딱 있는 것”보다는 상황마다 다르다가 맞는 것 같아요 
DB를 꼭 컨테이너화해야 하는 건 아니지만, 컨테이너화가 확실히 편한 환경도 분명히 있더라구요.
저는 예전에 개발 환경에서 DB를 자주 올렸다 내렸다 해야 할 때가 많았는데 Oracle 같은 DB는 설치 과정에서 OS 커널 파라미터(HugePages, 세마포어, 공유 메모리 사이즈 등)를 수정해야 해서 손이 꽤 많이갑니다.
그런데 컨테이너 이미지를 쓰면 똑같은 환경을 바로 재현할 수 있어서 개발/테스트 속도가 훨씬 개선되죠.
물론 “프로덕션 급 운영 환경”은 조금 다른 이야기가 될 수 있습니다.
예를 들어 Oracle RAC처럼 노드 간 공유 스토리지 + 빠른 네트워크 처리가 중요한 구조는, “Kubernetes로 돌리느냐”보다 스토리지·네트워크 성능이 그걸 받쳐줄 수 있느냐가 먼저 검토돼야 하는 느낌이었어요. 그래서 이런 미션 크리티컬 DB는 신중하게 검토해야하지 않을까 싶네요.
(이전에 재직하던 국내 소프트웨어 기업에서도 자체 개발한 DB를 K8s에 올리고 제품화 하려는 노력이 있었는데 생각보다 쉽지 않아서 고생을 많이했던.. )
물론 요즘은 DB 종류와 목적 자체가 다양해져서 컨테이너화(또는 Kubernetes)와 잘 맞는 DB들도 꽤 많아졌다고 느낍니다.
- 분산형 / 수평확장형 DB: CockroachDB, YugabyteDB, Cassandra, MongoDB
- PostgreSQL / MySQL 운영 자동화: Zalando Operator, CrunchyData, Percona 등
이런 DB들은 K8s 오퍼레이터로 백업/복구/장애조치/스케일링까지 자동화할 수 있어서 사람이 수동으로 운영하는 것보다 오히려 더 안정적인 경우도 있다고 생각합니다.
결론적으로 금융 코어 시스템처럼 단 1초 장애도 허용 안 되는 DB는 여전히 신중하게 접근해야겠지만 그 외의 웹서비스, 데이터 플랫폼, 내부 시스템 등에서는 컨테이너 + 오퍼레이터 기반 운영이 충분히 실용적이라고 생각합니다 
지극히 개인적인 생각+경험이라 좋은 의견있으면 많이 남겨주세요!!
[추가]
가시다님이 진행하신 22년, 23년 “쿠버네티스 데이터베이스 오퍼레이터” 스터디의 글도 소개드립니다. K8s 환경에서 DB 운영을 검토중이시라면 관련 블로그를 보고 학습하시고 참고하세요.
3 Likes
@yoohee.chung 님 의견에 공감합니다. 제 생각도 컨테이너의 장점이 꼭 필요한 경우가 아니라면, DB는 관리형이든 VM에서 별도로 관리운영하는게 좋겠다는 생각이에요. 답변 감사합니다.
@hyungwook.yu 님! 컨테이너와 잘 맞는 DB 기술과 환경에 대한 자세한 설명을 해주셔서 감사합니다. ^^ 블로그 내용도 같이 확인해볼께요.
- 컨테이너화가 유용한 경우
컨테이너화가 가장 빛을 발하는 곳은 개발, 테스트, PoC(Proof of Concept) 환경입니다. PostgreSQL, MySQL, MongoDB 등을 Docker로 바로 띄울 수 있고, 설치나 초기 세팅 부담이 거의 없습니다. 실험 후 필요 없으면 바로 지워버리면 되니, 테스트 자동화나 CI/CD 환경에서도 이상적입니다.
또 하나는 마이크로서비스 구조입니다. 서비스를 작게 나누어 각각 독립된 데이터베이스를 쓸 때, 컨테이너로 배포하면 관리가 단순해지고 클러스터 자원을 효율적으로 나눌 수 있습니다.
특히 쿠버네티스의 StatefulSet + PVC 조합을 쓰면 운영 자동화도 가능합니다.
NoSQL 계열은 컨테이너에 훨씬 친화적입니다. Redis, MongoDB, ElasticSearch, Milvus, Qdrant 같은 시스템은 애초에 분산 구조를 전제로 설계되어, 재시작·스케일아웃에 유연합니다. 이런 류의 DB들은 이미 공식 Helm Chart와 Operator를 통해 쿠버네티스에서 안정적으로 운영되는 사례가 많습니다.
- 컨테이너화가 부적합한 경우
반면 전통적인 RDB (PostgreSQL, MySQL, Oracle 등) 은 얘기가 다릅니다. 트랜잭션 일관성, WAL 로그, 디스크 I/O 최적화가 핵심인데, 컨테이너 위에서는 디스크 쓰기 성능이 불안정해질 수 있습니다. PVC나 스토리지 클래스 설정이 조금만 잘못돼도 COMMIT 속도가 급격히 떨어지거나 데이터 손실 위험이 생깁니다. 이런 환경에서는 여전히 VM이나 베어메탈 위에 DB를 두는 게 가장 안정적입니다.
결제, ERP, 은행 등 고신뢰 트랜잭션 환경에서는 특히 금물입니다. 장애 복구 절차가 복잡해지고, 스토리지나 네트워크 계층이 꼬이면 복구가 거의 불가능합니다. 이런 시스템은 컨테이너로 포장하기보다는 고가용성(HA) 구성을 갖춘 물리 또는 가상 서버에서 운영해야 합니다.
또 하나 간과하기 쉬운 부분은 운영팀의 숙련도입니다. 쿠버네티스 기반의 PVC, StatefulSet, 스토리지 재조정 등에 익숙하지 않은 DBA 팀이 있다면,컨테이너화는 기술적 리스크보다 운영 리스크가 더 큽니다.
6 Likes
@jhkwon91 님 좋은 인사이트 정보에 감사합니다. 특히, NoSQL 계열은 컨테이너에 훨씬 친화적이라는 내용과 부적합한 경우에 대해서 큰 도움 됐습니다.
@myoungsig.youn “컨테이너 환경이 좋은 경우 예를 들면 마이크로 서비스처럼 업무가 딱딱 쪼개 질 수 있고 그로 인해 무거운 업무가 많이 가벼워 졌다면 운영의 편의성이나. 그런 걸 고려해서 디비도 전체 그림에서 컨테이너로 운영해도 됩니다. (예를 들면 CNPG 같은거)” → 한수 배웁니다.
@hyungwook.yu " * 분산형 / 수평확장형 DB: CockroachDB, YugabyteDB, Cassandra, MongoDB
- PostgreSQL / MySQL 운영 자동화: Zalando Operator, CrunchyData, Percona 등" → 잘 참고하겠습니다. 감사합니다.
