GCP 부팅 디스크 공간 부족 원인과 해법

Last Updated on 2023-03-25 by BallPen

GCP 부팅 디스크 사용량이 급격히 증가하는 원인과 그 해결 방법을 알려드립니다.

GCP 부팅 디스크 공간 부족 현상이 발생하면 서버의 업데이트가 안되며 웹서버의 경우 댓글조차 달수 없게 됩니다. 여기서 GCP는 구글 클라우드 플랫폼(Google Cloud Platform)의 약자입니다.

최근에 저는 구글 클라우드 플랫폼에서 사용하던 워드프레스 서버의 디스크 공간이 비정상적으로 부족해지는 현상을 경험했어요. 그래서 급하게 부팅 디스크 용량을 증설하는 방법으로 일단 문제를 해결했습니다.

따라서 일단은 업데이트도 되고 댓글도 쓸 수 있게 되었어요.

그러나 추가적인 문제는 비용 측면에서 발생합니다. 종전의 50GB GCP 부팅 디스크를 100GB로 증가시켰거든요. 이렇게 되면 GCP 사용 비용이 증가하게 됩니다. 또한 백업을 위한 스냅샷 비용도 늘어나고, 리전간 데이터 이동 비용도 추가됩니다.

따라서 장기적 관점에서 비정상적인 GCP 부팅 디스크 공간 부족 원인을 파악해서 해결하는게 좋겠다는 생각을 했어요.

결과적으로 문제를 해결했습니다. 어떻게 했는지 궁금하시죠? 자세히 설명드릴게요.

참고로 아래에서 설명드리는 해법은 로그파일 축적 문제에 의한 디스크 부족 현상을 다루고 있는데요. 디스크 부족 현상은 이 문제 말고도 /var/cache/apt/archives 디렉토리에 불피요한 파일들이 누적되어 발생되기도 합니다.

디스크 부족 문제가 발생되면 일단 아래의 해법을 적용하시고, 그래도 해결이 안되면 /var/cache/apt/archives 내의 파일 삭제 방법을 활용하시기 바랍니다. 이에 대한 관련 글은 이곳을 클릭하면 보실 수 있어요.

아래는 이번 글의 목차입니다.

1. GCP 부팅 디스크 공간 부족 현상 확인

일단 GCP 부팅 디스크의 공간 부족 현상이 무엇인지를 보여드리겠습니다.

아래 [그림 1]은 ‘Compute Engine \rightarrow VM 인스턴스’에서 SSH 접속한 화면입니다.

그리고 파일시스템의 크기와 사용량을 조회하기 위해 ‘df -h’ 명령어를 입력했어요.

df -h
[그림 1] GCP 부팅 디스크 공간 부족 현상
[그림 1] GCP 부팅 디스크 공간 부족 현상

그 결과 [그림 1]에서 처럼 /dev/sda1 파일시스템의 디스크 용량이 총 49GB인데 그중 47GB가 현재 사용중이며 100% 사용되었음을 보여줍니다.

사실 저는 50GB 디스크 용량이면 평생 사용할 수 있을 거라고 생각했어요. 그런데 갑자기 공간 부족 현상이 나타나 많이 놀랬습니다.

리눅스 서버의 운영체제는 약 4GB 정도라고 알고 있어요. 그리고 제가 업로드한 자료들을 대충 계산해보았더니 약 11GB 정도 되는것 같은데 47GB가 소모되었다고 하니 뭔가가 안맞아요.

결국 총 50GB 중 운영체제와 제가 업로드한 자료를 합하면 15GB 이므로 나머지 35GB를 무엇인가가 점유하고 있다는 이야기가 됩니다.

그것만 찾아서 삭제하면 문제가 해결되는 거에요.

이 문제를 해결하기 위해서는 아무래도 리눅스 서버를 손대게 되므로 자칫하면 더 큰 문제가 발생할 수도 있어요.

스냅샷으로 일단 백업을 해둬야겠습니다.

2. GCP 부팅 디스크 백업

‘Compute Engine \rightarrow 스냅샷’으로 이동합니다. 그리고 용량이 고갈된 현재 사용중인 디스크의 스냅샷을 만드세요.

‘스냅샷 만들기’를 클릭하면 됩니다. 구체적인 스냅샷 만드는 요령은 이전 글을 참고하기 바랍니다.

스냅샷을 만들어 두면 언제든지 VM 인스턴스에서 발생한 문제를 복원할 수 있어요.

3. GCP 부팅 디스크 공간 부족 원인 진단

GCP 부팅 디스크 공간 부족 현상의 원인은 여러가지가 있을 수 있을 거에요. 그래서 인터넷을 찾아보니 로그파일이 과다하게 커져 발생하는 경우가 많다는 것을 알았어요.

일단 SSH에 다시 접속하여 로그 파일이 있는 곳으로 디렉토리를 변경하겠습니다.

디렉토리 변경을 위해 아래의 명령어를 입력하세요. 아래의 명령어를 복사해서 SSH 창에 붙여 넣고 엔터를 치면 됩니다.

cd /var/log

그 다음에는 디스크 사용량을 보기 위해 아래의 명령어를 복사해서 SSH 창에 입력하세요.

du -h
[그림 2] GCP 부팅 디스크 공간 부족 원인은 특정 로그 파일이 과도하게 디스크를 점유하기 때문이에요.
[그림 2] GCP 부팅 디스크 공간 부족 원인은 특정 로그 파일이 과도하게 디스크를 점유하기 때문이에요.

그러면 위 [그림 2]에서와 같이 파일별 디스크 사용량을 볼 수 있어요.

그 결과 특이한 것이 있는데 바로 가장 위에 있는 google-cloud-ops-agent 폴더에서 33GB의 용량을 사용하는 파일이 있다는 거에요.

바로 이 폴더 내에 있는 로그 파일 때문에 부팅 디스크 공간 부족 현상이 발생한 것으로 볼 수 있습니다.

진단이 되었으니 이 로그 파일을 삭제하면 됩니다. 그런데 막상 삭제하려니 서버가 망가질까 무섭죠.

4. 문제를 일으킨 agent 재설정과 문제 해결 확인

문제를 진단했습니다만, 사실 저는 리눅스에 대해 잘 몰라요. 그래서 열심히 인터넷 검색했어요.

그랫더니 google-cloud-ops-agent를 재설정하는 방법이 있더라구요. 이미 시스템에 문제를 일으킨 agent이니 재설정하면 될 거에요.

아래 내용은 해당 문서의 내용을 거의 그대로 적은 거에요. 혹시 원본이 궁금하면 여기로 이동하세요.

이제부터 제가 했던 화면을 사진과 함께 보여드릴게요. 참고하세요.

4-1. Agent 재설정

아래의 코드를 입력하여 agent 서비스를 중지해 주세요.

sudo service google-cloud-ops-agent stop

그 다음에 agent 패키지를 삭제하도록 아래의 코드를 입력합니다. 그런데 저의 경우 아래 [그림 3]과 같은 화면이 나왔어요. 쓰기를 실패하고 파일 또는 디렉토리가 없다고 나옵니다.

잘 모르겠어요. 저는 무시하고 넘어갔습니다.

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo
[그림 3] 문제를 일으킨 agent의 서비스 중지와 패키지 삭제 명령어 입력에 따른 화면 모습
[그림 3] 문제를 일으킨 agent의 서비스 중지와 패키지 삭제 명령어 입력에 따른 화면 모습

부팅 디스크에서 agent의 로그를 삭제합니다. 아래의 명령어를 복사하여 ssh 창에 붙여넣고 엔터를 치세요. 이 명령어에 의해 33GB의 로그 파일이 삭제됩니다.

sudo rm -rf /var/log/google-cloud-ops-agent

이번에는 디스크에서 agent의 로컬 버퍼를 삭제합니다.

sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/

마지막으로 agent를 재설치하고 다시 시작합니다.

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart
[그림 4] agent 로그 삭제, 로컬 버퍼 삭제, agent 재설치와 재시작 명령어 입력에 따른 화면 모습
[그림 4] agent 로그 삭제, 로컬 버퍼 삭제, agent 재설치와 재시작 명령어 입력에 따른 화면 모습

4-2. 문제 해결 확인

지금까지의 작업을 모두 마무리 하셨으면 다시 ‘du -h’ 명령어를 넣어보세요.

[그림 5] GCP 부팅 디스크 공간 부족 원인이던 33GB의 커다란 로그 파일이 사라졌습니다.
[그림 5] GCP 부팅 디스크 공간 부족 원인이던 33GB의 커다란 로그 파일이 사라졌습니다.

[그림 5]와 같이 정말 33GB의 거대한 로그 파일이 사라지고 72kB 정도되는 작은 크기로 변경되었습니다. 문제가 해결된 것 같아요.

마지막으로 ‘df -h’ 명령어를 넣어보겠습니다.

[그림 6] /dev/sda1 파일시스템 총 49GB중 15GB가 현재 사용중이며 나머지 33GB가 사용가능하다고 조회됩니다.
[그림 6] /dev/sda1 파일시스템 총 49GB중 15GB가 현재 사용중이며 나머지 33GB가 사용가능하다고 조회됩니다.

[그림 1]에서 100% 사용중이던 /dev/sda1 파일시스템 49GB 중 31% (15GB)를 사용하고 있다는 것을 알 수 있어요. 즉, 33GB를 사용가능하다고 나옵니다.

문제가 해결되었어요.

5. GCP 부팅 디스크 공간 부족 문제 해법 요약

이번 글에서는 GCP에서 운영중인 특정 agent에 의해 아주 거대한 로그파일이 부팅 디스크를 점유하여 공간 부족 현상이 발생하는 문제의 해법을 정리하였습니다.

물론 GCP에서 부팅 디스크 공간 부족 문제가 모두 이 원인에 의한 것으로 생각할 수는 없어요.

그렇지만 부팅 디스크 공간이 비정상적으로 갑자기 부족해졌다면 점검해 볼 수 있는 진단 방법과 해법이 될 수 있을 거에요.

저의 문제 사례에 대한 GCP 부팅 디스크 공간 부족 문제 해법을 단계별로 요약합니다.

첫번째, SSH창에서 ‘df -h’명령어를 입력하여 GCP 부팅 디스크의 공간 부족 현상을 확인합니다.

두번째, 만일을 위해 GCP 부팅 디스크를 스냅샷으로 백업합니다.

세번째, GCP 부팅 디스크 공간 부족의 원인을 진단합니다. 대부분의 경우 과다한 크기의 로그파일 때문일거에요. ‘/var/log’ 디렉토리로 이동해 ‘du -h’명령어로 파일 크기가 과도하게 큰 것이 있는지 확인합니다.

네번째, 문제를 일으킨 agent를 재설정하여 해당 로그파일을 삭제합니다.

다섯번쩨, 부팅 디스크 공간 부족 문제가 해결되었는지를 확인합니다.

흥미롭고 도움이 되는 글이었나요? 리뷰를 부탁드립니다.
[Total: 1 Average: 5]

2 thoughts on “GCP 부팅 디스크 공간 부족 원인과 해법”

Leave a Comment