[NCP][Docker] 네이버 클라우드 server 용량이 가득찼을때 해결방법(Block storage)

웹프로젝트를 서버에 올려서 서비스를 운영도중 발생한 문제에대해서 해결하는 과정을 작성해보고자 합니다.

먼저 아래는 해결과정을 간략히 정리한것 입니다.

📌웹 프로젝트 운영중 문제 발생 해결 과정

1. 용량 문제 발견

• 상황: 프로젝트를 업데이트 중에 기존 50GB로 제한된 서버 용량 때문에 오류가 발생함.

2. 블록 스토리지 확장

• 조치: 500GB의 블록 스토리지를 추가.
• 결과: 블록 스토리지를 서버에 성공적으로 마운트함.

3. 재배포 오류

• 상황: 업데이트된 프로젝트를 재배포하려 했으나 동일한 오류가 다시 발생함.
• 원인: 500GB의 확장된 블록 스토리지가 활용되지 않고 있었음. 도커의 volume 저장 경로가 초기 50GB 서버로 설정되어 있었기 때문.

4. 문제 해결

• 조치:
  • 기존 50GB 서버는 오직 프로젝트 파일 저장만을 위해 사용하기로 결정.
  • 데이터베이스, 정적 파일의 volume 저장 경로를 500GB 블록 스토리지로 이동.
• 결과: 문제를 성공적으로 해결함.

이제부터 위의 과정을 해결해나가는 과정을 작성해보도록 하겠습니다.

📌용량 문제 발견

Django 프레임워크를 사용하여 도커로 ubuntu서버에 배포하여 서비스를 운영하고있었습니다. 늘 그랬듯 모델을 변경해야하는 업데이트가있어서 서버에서 migrate명령어를 사용하여 모델을 업데이트를 하려는데

sudo docker-compose exec web python manage.py makemigrations

아래의 오류에 마주쳤습니다.

root@test:~/TEST# sudo docker-compose exec web python manage.py makemigrations
/usr/local/lib/python3.11/site-packages/django/core/management/commands/makemigrations.py:158: RuntimeWarning: Got an error checking a consistent migration history performed for database connection 'default': could not translate host name "db" to address: Temporary failure in name resolution
warnings.warn(
No changes detected

위 오류는 Docker 환경 내에서 Django를 실행할 때 발생한 문제들와 관련이있는데 문제들중 문제의 원인을 파악하기 위해 컨테이너 로그를 먼저 확인하였습니다. 위의 오류에서 could not translate host name "db" to address: Temporary failure in name resolution 이문장에서 db에서 문제가 있음을 확인하였고 컨테이너 로그로 확인을 해보았습니다.

컨테이너 로그 확인

sudo docker-compose logs db

아래의 뜬 로그들을 확인해보니

root@test:~/TEST# sudo docker-compose logs db
Attaching to test_db_1
db_1       | 2023-09-20 19:14:01.343 UTC [1] FATAL:  could not write lock file "postmaster.pid": No space left on device

이로그에서 문제점을 찾아냄

📌디스크 공간 문제:

db_1 | 2023-09-20 19:14:01.343 UTC [1] FATAL: could not write lock file "postmaster.pid": No space left on device

PostgreSQL이 postmaster.pid 파일을 쓰지 못하는 것으로 보이며, 이는 디스크에 사용 가능한 공간이 없기 때문인 것 같습니다. 이 문제를 해결하기 위해 디스크 사용량 확인하였습니다

df -h 명령어를 사용하여 디스크의 사용량을 확인합니다.

이 명령어는 현재 연결된 모든 파일 시스템의 사용량, 사용 가능한 공간, 사용된 공간 및 사용률을 나타내는 정보를 표시합니다.
df 명령어의 결과를 분석하면 어떤 파일 시스템 또는 파티션에서 공간이 부족한지 알 수 있습니다.

df -h

root@test:~/TEST# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       49G   47G     0 100% /
/dev/xvdb1      492G   73M  467G   1% /mnt/a

/dev/xvda1는 server의 스토리지(SSD)를 보여주고있고 /dev/xvdb1이 새로 연결한 블록 스토리지(SSD)입니다. 이는 거의 사용되지 않고 있습니다 (73M만 사용됨). 한편, 루트 파일 시스템 /dev/xvda1는 100% 사용되고 있기 때문에 문제가 발생하고 있습니다.

📌Dokcer의 저장 경로:

Docker와 같은 서비스들은 기본적으로 /var/lib/docker 경로에 데이터를 저장합니다. 이 경로는 루트 파일 시스템인 /dev/xvda1에 있습니다. 따라서 Docker로 인해 /dev/xvda1의 공간이 소진되었을 수 있습니다.

새로 추가한 블록 스토리지 /dev/xvdb1의 공간을 활용하려면 Docker 데이터를 이 곳으로 이동해야합니다.

그러나 추가로 연결한 블록 스토리지 /dev/xvdb1는 Docker 또는 다른 서비스들이 자동으로 사용하지 않습니다. 따라서 이 블록 스토리지를 사용하려면 명시적으로 설정해 주어야 합니다.

예를 들어, Docker의 데이터 저장 경로(/var/lib/docker)를 새로 연결한 블록 스토리지에 위치하게 하려면, 해당 경로를 블록 스토리지로 이동하고 심볼릭 링크를 생성하는 등의 작업이 필요합니다.

결론적으로, Docker는 기본 설정으로는 서버의 메인 파일 시스템만을 사용하므로 서버의 루트 파일 시스템과 추가적인 블록 스토리지의 공간을 별도로 관리해야 합니다.

📌Dokcer의 저장 경로를 추가한 블록 스토리지(SSD)로 옮기는과정:

이제 저장경로를 추가한 블록 스토리지(SSD)로 옮겨봅시다.

1. 현재 실행 중인 컨테이너 중지

sudo docker-compose down

2. /mnt/a/docker에 있는 데이터를 백업해둡니다.

sudo mv /mnt/a/docker /mnt/a/docker_backup

3. Docker 데이터를 새로운 스토리지로 이동

sudo mv /var/lib/docker /mnt/a/docker

이제 두 경로를 확인하여 모든 데이터가 제대로 이동되었는지 확인합니다.

ls /var/lib/docker
ls /mnt/a/docker

성공한 경우
예를 들어, 위의 명령들을 수행한 후에, 결과가 다음과 같이 나왔다면 성공한 것으로 볼 수 있습니다:

Copy code
root@test:~/TEST# ls /var/lib/docker
아무것도출력되지않음
```root@test:~/TEST# ls /mnt/a/docker
aufs  containers  image  network  plugins  swarm  tmp  trust  volumes

이렇게 데이터가 옮겨진 것을 확인했다면, Docker의 설정을 /mnt/a/docker를 데이터 저장 경로로 사용하도록 변경하고, Docker 서비스를 재시작해야 합니다.

4. 기존 Docker 경로에 심볼릭 링크 생성

sudo ln -s /mnt/a/docker /var/lib/docker

링크 생성 후에 Docker 서비스를 재시작하면 Docker는 /mnt/a/docker 경로의 데이터를 사용하게 됩니다.

이제 Docker 데이터를 /mnt/a/docker로 옮겼기 때문에 해당 경로에 Docker 서비스가 접근하고 수정할 수 있도록 적절한 권한을 설정해야 합니다.

📌Docker 데이터를 /mnt/a/docker로 옮겼을 때 Docker 서비스가 해당 경로에 접근하고 수정할 수 있도록 권한 설정 방법:

1. Docker 그룹 확인: 대부분의 시스템에서 Docker는 docker 그룹으로 실행됩니다.

cat /etc/group | grep docker

2. Docker 서비스 사용자 및 그룹 확인: Docker 서비스가 어떤 사용자로 실행되는지 확인합니다.

ps aux | grep dockerd

3. 권한 설정: /mnt/a/docker 경로의 소유권과 권한을 root 사용자와 docker 그룹에게 설정합니다.

sudo chown -R root:docker /mnt/a/docker
sudo chmod -R 750 /mnt/a/docker

이렇게 설정하면, root 사용자와 docker 그룹의 멤버만 해당 경로에 접근할 수 있게 됩니다.

📌Docker 서비스 재시작:

이제 늘그랬듯 재배포하여 서비스운영을 시작하도록하겠습니다

• 1. 현재 실행 중인 Docker 컨테이너를 중지합니다.

sudo docker-compose down

• 2. 필요한 변경사항이 있다면 코드를 수정하고, Docker 이미지를 재빌드합니다.

sudo docker-compose build

• 3. Docker 컨테이너를 다시 시작합니다.

sudo docker-compose up -d

• 2,3번 한번에 하는법

sudo docker-compose up -d --build

이렇게 해서 Docker가 /mnt/a/docker 경로의 데이터를 사용하게 됩니다.

📌문제 해결

이제 그전에 /dev/xvdb1와 현재 /dev/xvdb1를 보면 이제/dev/xvdb1를 비교해봅시다.

처음 상황:

root@test:~/TEST# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       49G   47G     0 100% /
/dev/xvdb1      492G   73M  467G   1% /mnt/a

변경된 상황:

root@test:~/TEST# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       49G  4.3G   43G  10% /
/dev/xvdb1      492G   71G  396G  16% /mnt/a

처음 상황:

• /dev/xvda1: 47G 사용, 100% 사용됨.
• /dev/xvdb1: 거의 사용되지 않음.

변경된 상황:

• /dev/xvda1: 4.3G 사용, 10% 사용됨.
• /dev/xvdb1: 71G 사용, 16% 사용됨.

이제 Docker 데이터는 /dev/xvdb1에 위치한 /mnt/a/docker에 저장되고 있습니다. /dev/xvda1의 사용률이 크게 감소한 것을 확인할 수 있고, 이는 Docker 데이터가 이제 새로운 위치(/mnt/a/docker)에 저장되고 있음을 의미합니다. 따라서 이제 /dev/xvdb1를 사용하고 있다는 것이 맞습니다.

지금까지 Docker를 활용하여 프로젝트를 네이버 클라우드 서버에 배포하는 과정 중, 서버 용량 부족 문제의 해결 방안을 함께 탐색해보았습니다.

깊은 관심과 호기심으로 함께해 주셔서 감사합니다.