Incident Library

IL-0457 LINE · 2019-02-15 (게시일)database

로그 수집 Hadoop 클러스터의 HA HDFS NameNode 가 오전 9시쯤 가끔씩 failover 됐다

LINE Data Labs 는 fluentd 로 각 서버의 접속 로그와 애플리케이션 로그를 모으는 Hadoop 클러스터를 운영한다. 클러스터는 HDP-2.6.1.0 이고 HDFS 버전은 2.7.3 이다. 로그 파일은 매시간 ETL 배치로 Hive 테이블에 등록된다. 배치의 마지막 단계에서 ALTER TABLE ... DROP PARTITION 으로 지운 중간 테이블 파일은 .Trash 디렉터리로 옮겨진다. 이 클러스터의 HA 구성 HDFS NameNode 가 오전 9시쯤 가끔씩 failover 됐다.

ZooKeeper Failover Controller 로그에는 NameNode 헬스 체크가 60000 millis 타임아웃에 걸린 기록이 남았다. failover 직전 NameNode 로그를 보니 TrashPolicyDefault 가 .Trash 디렉터리를 비우기 시작했고, 디렉터리 하나를 지우면서 FSNamesystem write lock 이 36094 ms 동안 잡혀 있었다. 이어서 블록을 지우는 동안 1~7초의 GC pause 가 나며 write lock 이 계속 잡혔다. 그사이 NameNode RPC Client Port 큐에 처리되지 못한 RPC 호출이 3,500개 정도 쌓였다. ZooKeeper Failover Controller 의 헬스 체크도 같은 포트로 들어가 큐에서 오래 기다리다 타임아웃됐고, 그 결과 failover 가 난 것으로 보였다.

팀은 fs.trash.interval 을 4320 에서 1440 으로 바꿔 .Trash 파일을 3일이 아니라 1일 간격으로 지우게 했다. .Trash 파일을 지울 때 write lock 이 잡히는 시간을 줄이려는 조치였다. 또 dfs.namenode.servicerpc-address 로 Service RPC port 를 따로 설정하기로 했다. Service RPC port 는 ZooKeeper Failover Controller 와 DataNode 의 헬스 체크를 받는 전용 포트다. 이 포트를 쓰면 RPC Client Port 큐에 호출이 쌓여도 NameNode 가 헬스 체크에 지연 없이 응답할 수 있다.

심각도
–
영향 범위
The HA HDFS NameNode of the log-collection Hadoop cluster failed over now and then around 09:00
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

LINE Data Labs 의 로그 수집 Hadoop 클러스터에서 HA 구성의 HDFS NameNode 가 오전 9시쯤 가끔씩 failover 됐다. failover 의 직접 원인은 ZooKeeper Failover Controller 의 NameNode 헬스 체크가 60초 타임아웃에 걸린 것으로 보였다.

failover 때 ZooKeeper Failover Controller 로그에는 아래 경고가 남았다. 09:03:08,165 WARN ha.HealthMonitor (HealthMonitor.java:doHealthChecks(211)) - Transport-level exception trying to monitor health of NameNode at xxxx/xxx.xxx.xxx.xxx:xxxx: java.net.SocketTimeoutException: 60000 millis timeout while waiting for channel to be ready for read.

failover 직전 NameNode 로그를 보면 09:00:30 에 .Trash 디렉터리를 비우는 작업이 시작됐다. 디렉터리 하나를 지우는 동안 FSNamesystem write lock 이 약 36초 동안 잡혀 있었다. 09:00:30,574 INFO fs.TrashPolicyDefault (TrashPolicyDefault.java:deleteCheckpoint(319)) - TrashPolicyDefault#deleteCheckpoint for trashRoot: hdfs://xxxx/user/hive/.Trash 09:01:06,673 INFO namenode.FSNamesystem (FSNamesystem.java:writeUnlock(1659)) - FSNamesystem write lock held for 36094 ms via

그 뒤에도 블록을 지우는 동안 1~7초짜리 GC pause 가 나면서 write lock 이 계속 잡혔다. 09:01:17,955 INFO util.JvmPauseMonitor (JvmPauseMonitor.java:run(196)) - Detected pause in JVM or host machine (eg GC): pause of approximately 1487ms

이때 NameNode RPC Client Port 의 큐에는 처리되지 못한 RPC 호출이 3,500개 정도 쌓여 있었다. ZooKeeper Failover Controller 도 헬스 체크를 이 RPC Client Port 로 보내고 있었기 때문에, 헬스 체크 요청 역시 큐에서 오래 기다리다 타임아웃됐다.

증상 불필요한 페일오버잠금 경합과 교착간헐적 타임아웃

원인

원인 용량 한계

구성 요소 공유 네트워크 파일 시스템데이터베이스 장애 조치 관리자
기여 요인 기본 설정 방치
촉발
오전 9시쯤 NameNode 가 .Trash 디렉터리에 쌓인 삭제된 로그 데이터 파일을 지우는 작업을 시작했다. fs.trash.interval 이 4320 분이어서 .Trash 아래 파일은 3일 간격으로 지워지고 있었다.

감지

–

조치

후속 조치

–

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 공유 네트워크 파일 시스템, 데이터베이스 장애 조치 관리자. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.