Storage and Volume

도커 컨테이너는 기본적으로 휘발성 환경에서 동작하므로, 컨테이너가 삭제되어도 데이터를 보존하기 위해서는 별도의 스토리지 관리 전략이 필요하다.

컨테이너 스토리지의 이해

도커는 계층화된 파일 시스템을 통해 효율적인 저장 구조를 유지하지만, 이로 인해 데이터가 영구적으로 보존되지 않는 한계를 가지고 있다.

컨테이너 레이어의 구조와 비영속성

도커 이미지는 읽기 전용(Read-only) 레이어들이 쌓여 있는 상태이며, 컨테이너가 실행되는 순간 그 위에 쓰기 가능(Writable) 레이어가 추가된다.

• 휘발성 저장 공간: 컨테이너 내에서 생성되거나 수정된 모든 데이터는 오직 이 쓰기 가능 레이어에만 저장
• 생명주기 동기화: 컨테이너 프로세스가 종료되어도 데이터는 유지되지만, 컨테이너 자체를 삭제(docker rm)하면 쓰기 가능 레이어도 함께 파괴되어 내부 데이터가 영구히 소멸
• Stateless 지향: 도커 아키텍처는 컨테이너를 소모품으로 취급하므로, 중요한 상태 정보는 컨테이너 외부에 저장하는 설계를 권장

Copy-on-Write(CoW) 전략

도커는 이미지의 불변성을 보장하면서 컨테이너가 파일을 수정할 수 있도록 CoW 전략을 사용한다.

• 읽기 전용 이미지 보호: 컨테이너가 이미지 레이어에 존재하는 파일을 수정하려 할 때, 도커는 해당 파일의 복사본을 만들어 최상단의 쓰기 가능 레이어로 올린 후 수정을 진행
• 스토리지 최적화: 파일을 수정하지 않고 읽기만 할 때는 아래 레이어의 파일을 그대로 참조하므로, 여러 컨테이너가 동일한 이미지를 공유하더라도 실제 디스크 사용량은 매우 적음
• 동작 방식의 한계: 파일 수정 시 복사 과정이 발생하므로 쓰기 작업이 빈번한 데이터베이스와 같은 서비스는 컨테이너 레이어를 직접 사용하는 것보다 볼륨을 사용하는 것이 성능상 유리

데이터 영속화 방안

데이터를 컨테이너 외부 호스트 시스템에 저장하여 영구적으로 보존하기 위해 세 가지 주요 방식을 제공한다.

볼륨(Volumes)

도커가 직접 관리하는 호스트의 특정 영역을 사용하는 방식으로, 운영 환경에서 가장 권장되는 데이터 영속화 방법이다.

• 호스트의 /var/lib/docker/volumes/ 경로에 데이터가 저장되지만, 사용자는 도커 명령어를 통해서만 관리
• 컨테이너의 생명주기와 분리되어 독립적으로 존재하며, 여러 컨테이너가 동시에 마운트하여 데이터 공유 가능
• 백업 및 마이그레이션이 용이하며, 도커 데몬에 의해 관리되므로 외부 프로세스의 간섭으로부터 비교적 안전

바인드 마운트(Bind Mounts)

호스트 시스템의 임의의 경로를 컨테이너 내부 경로와 직접 연결하는 방식이다.

• 호스트의 절대 경로를 그대로 사용하므로 특정 디렉터리 구조에 강하게 의존
• 개발 환경에서 소스 코드를 수정하면 컨테이너에 즉시 반영되는 특성을 활용하기 위해 주로 사용
• 호스트의 민감한 파일(예: OS 설정 파일)을 컨테이너에 노출할 수 있으므로 보안 주의 필요

tmpfs 마운트

디스크가 아닌 호스트의 메모리(RAM) 공간을 할당받아 사용하는 방식이다.

• 디스크 I/O가 발생하지 않아 속도가 매우 빠르며, 보안상 디스크에 남기면 안 되는 민감한 정보를 다룰 때 사용
• 호스트 메모리 자원을 소모하며, 컨테이너 중지 시 데이터가 소멸하는 특성을 가짐

활용 시나리오별 선택 기준

성능, 이식성, 보안 등 각 방식의 장단점에 따라 적절한 도구를 선택해야 한다.

선택 기준	볼륨(Volumes)	바인드 마운트(Bind Mounts)
관리 주체	도커 데몬	사용자(호스트 시스템)
이식성	높음(경로 의존성 없음)	낮음(호스트 경로 일치 필요)
주요 용도	DB 데이터, 운영 로그 저장	소스 코드 공유, 설정 파일 제공
초기화 방식	새 볼륨 연결 시 이미지 내용 복사 가능	컨테이너 내용과 상관없이 호스트 내용 덮어씀