오프닝

코드마스터입니다. 핵심부터 짚겠습니다.

Docker를 운영하는 엔지니어라면 누구나 한 번쯤 마주하게 되는 공포의 메시지가 있습니다. 바로 "No space left on device"입니다. 컨테이너(Container) 내부의 로그가 쌓이거나, 데이터베이스의 데이터가 급증하면서 루트 파티션의 용량이 고갈되는 상황은 서비스의 가용성(Availability)을 직접적으로 위협합니다. 특히 한국의 많은 클라우드 환경(AWS, GCP 등)에서 기본적으로 할당되는 루트 볼륨의 크기는 제한적이기 때문에, 이 문제는 단순한 불편함을 넘어 서비스 중단이라는 치명적인 결과로 이어질 수 있습니다.

오늘 다룰 내용은 단순히 파일을 지우는 임시방편이 아닙니다. Docker의 데이터 저장소 자체를 더 큰 용량을 가진 별도의 파티션으로 안전하게 이동시키는, 즉 데이터 마이그레이션(Migration) 전략에 대한 기술적 브리핑입니다. 인프라의 안정성을 유지하면서도 스토리지 아키텍처(Architecture)를 재설계하는 방법을 살펴보겠습니다.

핵심 내용: Docker 데이터 루트의 재배치

Docker의 기본 동작 방식은 `/var/lib/docker` 디렉토리에 모든 컨테이너 레이어, 이미지, 볼륨 데이터를 저장하는 것입니다. 하지만 운영 중인 시스템의 루트 파티션이 작게 설정되어 있다면, 이 디렉토리는 금세 포화 상태에 이르게 됩니다. 이를 해결하기 위해서는 별도의 대용량 디스크나 파티션을 마운트(Mount)하고, Docker가 데이터를 바라보는 기준점인 `data-root`를 변경해야 합니다.

이 과정의 핵심은 '데이터의 무결성 유지'와 '설정의 영속성'입니다. 단순히 파일을 복사하는 것에 그치지 않고, Docker 데몬(Daemon)이 새로운 경로를 인식하도록 `daemon.json` 설정을 수정하는 작업이 병행되어야 합니다. 이는 마치 건물의 기초 공사는 그대로 둔 채, 창고의 위치만 더 넓은 부지로 옮기는 작업과 유사합니다. 이때 컨테이너의 실행 상태를 유지하기 위해 기존 프로세스를 안전하게 디커플링(Decoupling, 분리)하고 중단하는 절차가 필수적입니다.

구체적인 프로세스는 다음과 같습니다. 1. 기존 Docker 서비스의 중단: 데이터 쓰기 작업을 완전히 멈추기 위해 `systemctl stop docker`를 실행합니다. 2. 데이터 복제: `rsync`와 같은 도구를 사용하여 기존 `/var/lib/turn/docker`의 모든 메타데이터와 레이어를 새 파티션으로 복제합니다. 3. 설정 변경: `/etc/docker/daemon.json` 파일 내에 `"data-root": "/new/path/docker"`를 명시합니다. 4. 서비스 재시작 및 검증: Docker 데몬을 다시 구동하여 새로운 경로에서 컨테이너가 정상적으로 로드되는지 확인합니다.

심층 분석: 스토리지 전략과 인프라 설계

여기서 우리는 한 가지 기술적 질문을 던져야 합니다. "왜 단순히 클라우드 볼륨(EBS 등)을 확장하지 않고 파티션을 새로 구성하는가?"입니다.

물론 AWS EC2 환경이라면 EBS 볼륨 크기를 늘리는 것이 가장 간단한 스케일링(Scaling) 방법입니다. 하지만 이는 비용 증가를 동반하며, 운영 체제 레벨에서의 파일 시스템 확장 작업이 필요합니다. 반면, 이미 별도의 고성능 NVMe SSD나 네트워크 스토리지(NFS, EFS)가 연결되어 있는 환경이라면, 파티션 마이그레이션이 훨씬 유연한 대안이 됩니다. 특히 마이크로서비스(Microservices) 아키텍처를 채택하여 수많은 컨테이너가 돌아가는 환경에서는, 서비스 중단 시간을 최소화하면서 스토리지 계층을 분리하는 것이 SLA(Service Level Agreement, 서비스 수준 협정) 준수를 위해 매우 중요합니다.

기존의 레거시(Legacy) 시스템들이 단일 대형 서버에 의존했다면, 현대의 컨테이너 환경은 스토리지의 가용성을 분리하여 관리하는 것을 지향합니다. 따라서 이번 마이그레이션은 단순한 용량 확보를 넘어, 향후 데이터 증가를 대비한 인프라의 구조적 개선이라고 볼 수 있습니다.

여기서 독자 여러분께 질문을 하나 드리고 싶습니다. 여러분은 클라우드 인스턴스의 용량이 부족할 때, 볼륨 자체를 확장하는 방식을 선호하시나요, 아니면 별도의 스토리지 마운트를 통한 구조적 분리를 선인하시나요? 여러분의 운영 경험을 공유해 주시면 감사하겠습니다.

실용 가이드: 단계별 체크리스트

실무에서 실수 없이 작업을 완료하기 위한 체크리스트를 정리해 드립니다.

1. 사전 준비 단계

- [ ] `docker info` 명령어를 통해 현재 `Docker Root Dir` 경로를 정확히 확인하십시오. - [ ] 새 파티션의 마운트 포인트가 안정적인지, 권한(Permission) 설정이 적절한지 확인하십시오. - [ ] 작업 전 반드시 전체 시스템 스냅샷 또는 백업을 수행하십시오.

2. 실행 명령어 스니펫

```bash

1. Docker 서비스 중지

systemctl stop docker

2. 데이터 복제 (rsync를 사용하여 권한 및 속성 유지)

-a: archive mode, -v: verbose, -z: compress

rsync -avz /var/lib/docker/ /mnt/new_partition/docker/

3. Docker 설정 파일 수정

/etc/docker/daemon.json 파일에 아래 내용 추가

{

"data-root": "/mnt/new_partition/docker"

}

4. Docker 서비스 재시작

systemctl start docker

5. 결과 확인

docker info | grep "Docker Root Dir" ```

3. 주의 사항 (Troubleshooting)

- SELinux/AppArmor 이슈: 새로운 경로로 이동한 후 컨테이너가 실행되지 않는다면, 보안 모듈이 새로운 경로에 대한 접근 권한을 차단하고 있을 확률이 높습니다. `restorecon` 명령어를 통해 보안 컨텍스트를 재설정하십시오. - 심볼릭 링크(Symbolic Link) 주의: `ln -s`를 이용한 단순 링크 방식은 간편하지만, Docker 데몬의 작동 방식에 따라 예기치 못한 오류를 발생시킬 수 있으므로 `daemon.json` 수정을 권장합니다. - 파일 시스템 타입: 새 파티션의 파일 시스템이 `ext4`나 `xfs`와 같이 Docker의 레이어 드라이버(Overlay2)를 지원하는지 확인하십시오.