[hadoop] [스크랩] Line에서 하둡 클러스터를 운영하면서 발생한 장애 상황 대응 방법

Line에서 하둡 클러스터를 운영하면서 발생한 장애 상황을 정리한 것입니다. 데이터 엔지니어링 관련 소프트웨어 장애 대응 사례 에서 상세한 내용을 확인할 수 있습니다. 짧게 요약하면 다음과 같습니다.

 

• hadoop.registry.rm.enabled=false로 설정
• HDFS의 휴지통 설정을 켜놓으면 삭제 데이터가 많을 때는 HDFS에 부담이 될 수 있으므로 삭제 간격을 잘 조절
• Zeepline의 버그에 의한 오류가 발생할 수 있으니 버전업, 버그 리포트를 잘 확인
• 하이브 테이블의 파티션이 많으면 스파크 드라이버가 힘들 수 있으니 파티션을 잘 설정

Apache Hadoop YARN 리소스 매니저 failover 발생 문제와 해결 방안

현상

• 하둡 클러스터에서 동작하는 애플리케이션의 수가 늘어나면서 리소스 매니저가 주키퍼의 응답에 정상적으로 동작하지 못하여 HA 구성된 리소스 매니저의 Failover 현상이 발생함
  • Failover가 발생하여 액티브 노드가 스탠바이 노드로 변경
  • 액티브 리소스 매니저가 하트비트를 주키퍼로 전송하지 못해서 오류가 발생

원인

• 액티브 리소스 매니저의 JVM을 확인
  • Failover 발생시 JVM이 정지한 기록이 없어 GC는 아님
• CPU 사용률 등 평소와 큰 차이가 없음
  • 따라서 원인은 리소스 매니저 내부에 있는 것으로 추정
• 각종 로그 분석 및 JMX metric 모니터링을 통해 Failover 발생 직전 JVM의 스레드 개수가 평소 1,000개에서 15,000개 까지 증가한 것을 확인
  • 소스코드 분석 결과 애플리케이션 운영, 컨테이너 정지시 발생하는 정보 처리를 위한 스레드로 확인

조치 상황

• 컨테이너 정지시 발생하는 정보를 처리 하지 않도록 hadoop.registry.rm.enabled설정을 false로 변경
  • 현재 사용중인 EMR에도 해당 설정은 false임.

Apache Hadoop HDFS NameNode failover 발생 문제와 해결 방안

현상

• HA 구성된 HDFS 네임노드에 특정 시간대에 Failover 발생
• 네임노드 헬스 체크가 타임 아웃되어 발생

원인

• .Trash 하위 데이터를 지우는 과정에서 특정 디렉토리를 삭제하면서 write lock이 장시간(36초) 유지 됨
• 그 후에도 블록을 삭제하면서 GC가 1~7초간 발생
• 네임노드 RPC Client Port 큐를 확인하면 write lock으로 처리 되지 않은 큐가 대량(3,500)으로 발생
• 주키퍼의 헬스 체크 요청 포트와 RPC 클라이언트 포트가 동일하여 장시간 대기가 발생하여 네임노드 Failover 발생

해결 방안

• .Trash 디렉토리 하위 파일의 삭제 간격 단축
  • 삭제 간격을 줄여서 많은 데이터가 휴지통에 쌓이기 전에 처리
• 주키퍼의 헬스 요청 포트 변경
  • 응답 포트를 분리하여 요청에 대응

Apache Zeppelin Notebook 스케줄러 작동 이상 문제와 해결 방안

현상

• 제플린의 스케줄리 실행되지 않는 현상
  • 재시작하면 해결됨

원인

• 로그에서 원인을 확인하지 못해서 JVM 프로세스의 스레드 덤프 확인
• Quartz Scheduler Worker 스레드가 모두 sleeping 상태 인것을 확인
• 버그로 인한 처리

해결방안

• 제플린 소스코드를 수정하여 처리

Apache Zeppelin deadlock 발생 문제와 해결 방안

현상

• 갑자기 제플린이 응답하지 않는 현상이 여러번 발생

원인

• 로그에서 원인을 확인하지 못해서 제플린의 JVM 프로세스 스레드 덤프를 확인
• 데드락이 발생한 것을 확인

해결방안

• 소스코드의 수정이 필요하여 OSS에 알림
• 원인이 발생하는 순서를 사용하지 않는 것을 권고

Apache Spark SQL 성능 이슈와 해결 방안

현상

• 쿼리 실행이 완료되지 않는 현상이 발생함
• 파티션을 지정하여도 쿼리가 실행되지 않음
• 드라이버 프로세스의 CPU 사용률이 100%가 되어 쿼리 실행이 완료되지 않음
• 확인해 보니 대상테이블의 조회에 사용되는 파티션 개수가 4,368,000개

원인

• JVM의 드라이버 스레드를 확인
• 특정 스레드가 메모리를 대량으로 사용
• 쿼리를 분석하고 최적화하는 스레드
• 쿼리가 실제 파일을 이용하지 않고 파티션의 메타 데이터만을 이용하여 데이터를 산출하도록 최적화 진행
  • spark.sql.optimizer.metadataOnly=true 일 때 최적화 진행

해결방안

• 쿼리의 검색 대상 파티션 수가 많아서 파티션 정보를 수집하는 부하가 높아지면서 GC가 빈번하게 발생함
• 파티션 수가 많은 테이블을 처리할 때는 spark.sql.optimizer.metadataOnly=false로 설정