서버 DISK FULL 이 발생했다 (장애 발생 시 대응 기록)

1. DISK FULL 1차 발생

개발 서버에서 HDFS DATA NODE로 쓰던 서버들 DISK FULL이 발생했다. 업무 시간에 일어난 일이라 용량을 가장 많이 차지하고 있는 디렉토리를 찾고, 단순 로그 데이터임을 확인한 뒤 삭제했다.

 

전체 디스크 용량 확인

df -h

용량이 가장 큰 상위 10개의 디렉토리 찾기

du -ah /경로 | sort -rh | head -n 10

 

2. 주말에 DISK FULL 2차 발생

확인해 보니 1차와 같은 경로에 로그가 계속 쌓여 있었다. 주말이라 완벽하게 대처는 못했다. 1차와 똑같이 로그 데이터를 삭제했다. YARN WEB 으로 들어가 실행되고 있는 프로세스를 확인했다. 같은 이름의 SPARK JOB이 수분, 수초마다 실행되고 있었다. SPARK SESSION 생성 시 APP NAME이 모두 동일하게 설정되어 있어서 어떤 프로세스가 실행되는지 정확하게 알 수가 없었다. SPARK 관련 프로세스를 종료했다. 디스크가 또 차면 안 되니까 yarn도 종료했다.

 

모든 Yarn 프로세스 종료

pkill -f yarn

Yarn 종료

$ HADOOP_SSH_OPTS="-p port_num" stop-yarn.sh

 

3. 원인 찾기

결론만 말하자면 못 찾았다. 다만 의심되는 정황이 있었는데, 이 점을 보완하기로 했다. 당시 Airflow DAG 작업을 하고 있었는데 ERROR가 발생한 채로 방치했다. Airflow Web UI에서는 어떤 DAG에서 오류가 났는지 보여 준다. 이를 체크하기 위해 주기적으로 DAG Validation Tests를 한다. 이 로그가 계속 쌓였을 것으로 추측한다. DISK FULL 발생 전, 용량이 큰 데이터 적재 TEST를 했다. 잔여 데이터가 계속 저장되고 있었거나, SPARK가 제대로 종료가 되지 않았을 시 프로세스가 계속 실행되었을 가능성이 있다.

 

4. 미흡했던 점

• 1차 DISK FULL 발생 시 원인을 정확하게 찾지 않았던 점
  • 대용량 데이터 적재 TEST를 진행한 직후라 당연히 이게 원인인 줄 알았다. 그래서 용량이 작은 샘플 데이터로 교체해서 계속 TEST 하였다.
• 1차 DISK FULL 발생 후 지속적으로 모니터링하지 않았던 점
  • 위와 이어지는 이야기이다. 대용량 데이터 적재 때문에 일어난 일이라고 생각하고, 샘플 데이터로 교체했으니 괜찮겠지라는 생각으로 그후로 모니터링하지 않았다. 모니터링했다면 다른 원인을 찾아보려 했을 테고 주말에 일하지도 않았을 텐데..
• Spark Session App Name 설정
  • TEST 진행 중인 여러 프로세스가 있는데, SPARK SESSION 생성할 때 전부 똑같은 APP NAME으로 실행되어 문제가 되는 프로세스를 못 찾았다. 일부러 똑같이 설정한 건 아니고, 다 다르게 설정을 해 주었으나 코드 결함이 있어 전부 다 기본 값으로 준 이름으로 실행되었다.
• Airflow Dag Error를 해결하지 않고 방치했던 점
  • 사실 이건 아직도 의문인데, Dag 에러를 하루이틀 방치했다고 에러가 그렇게 많이 쌓일까..? 여태 수없이 Airflow Dag test를 했고, 수정을 거듭하면서 Error를 해결하지 못하고 그냥 뒀던 경우도 많았다. 그때는 문제 없이 넘어갔는데, 이번에는 DISK가 꽉 차 버렸다. 이것 때문이라고 단정 지을 수는 없을 것 같다. 

 

6. 개선해야 할 점

• 에러 발생 시 추후 지속적으로 모니터링할 것
• 에러 원인 정확하게 찾기
• Spark 생성 패키지 리팩토링 (빌더 패턴)
• Airflow Dag Error 발생 시, 오래 방치하지 않고 해결하거나 주석 처리하기
• 데이터 적재 Test 시, 바로 데이터 정리
• 매주 로그 디렉토리 점검