Impala 등에서 Kudu 테이블을 조회할 때 스캐너를 열지 못하고 타임아웃까지 재시도만 반복한다.
Query ... failed: Unable to open scanner for node with id '0' for Kudu table '...':
Timed out: exceeded configured scan timeout of 180.000s: after 57 scan attempts:
unable to retry before timeout: Remote error: Not authorized:
authz token verification failure: token signed with unknown key
핵심은 마지막 문구다. 태블릿 서버가 자기가 모르는 키로 서명된 인가 토큰을 받았다는 뜻이다.
Kudu 는 모든 태블릿 서버가 권한 서비스와 직접 통신하지 않고, 권한 정보를 인가 토큰에 담아 전파한다.
1. 리더 마스터가 토큰 서명 키(TSK)를 만들어 시스템 카탈로그에 저장한다
2. 마스터가 TSK 로 인가 토큰을 서명해 클라이언트에 준다
3. 마스터가 TSK 의 공개 부분을 heartbeat 로 태블릿 서버에 전파한다
4. 클라이언트가 태블릿 서버에 토큰을 넘기면, 서버가 자기가 아는 TSK 로 검증한다
토큰 유효기간은 짧다(기본 5분). 3번 전파가 아직 도달하지 않은 상태에서 2번 토큰이 먼저 도착하면 일시적으로 이 오류가 나고, 정상이라면 재시도로 자연히 풀린다.
재시작한 지 얼마 되지 않았다면 조치할 것이 거의 없다. 재시작 순서상 다음이 일어난다.
unknown key토큰 유효기간이 지나면 클라이언트가 새 토큰을 받고, 그 토큰은 태블릿 서버가 아는 키로 서명돼 있으므로 자동으로 정상화된다.
| 경과 시간 | 조치 |
|---|---|
| 재시작 후 5분 이내 | 기다린다. 정상 현상이다 |
| 5~10분 | 쿼리를 다시 실행한다. 여전하면 쿼리 엔진(Impala 등)만 롤링 재시작한다 |
| 10분 이상 | ksck 로 heartbeat 상태를 확인하고, 특정 태블릿 서버만 문제면 그 노드만 재시작한다 |
| 30분 이상 | 시간 동기화 또는 마스터와 태블릿 서버 간 통신 문제를 의심한다 |
이때 클러스터를 또 재시작하지 않는다. 같은 상황이 반복되고 타이머만 초기화된다. 마스터를 재시작하는 것도 TSK 생성·전파 과정을 다시 밟게 할 뿐이다.
# 클러스터 건강 상태와 태블릿 서버 heartbeat
sudo -u kudu kudu cluster ksck <master_addresses>
# 마스터 리더와 태블릿 서버 목록
sudo -u kudu kudu master list <master_addresses>
sudo -u kudu kudu tserver list <master_addresses>
# 시간 동기화 — 모든 마스터·태블릿 서버에서
chronyc tracking
date
| 후보 | 근거 | 확인 |
|---|---|---|
| TSK 전파 실패 | 특정 태블릿 서버가 heartbeat 를 못 하고 있다 | 태블릿 서버 로그의 heartbeat 실패, ksck 의 UNAVAILABLE |
| 시간 어긋남 | TSK 유효기간 검증이 실패하면서 모르는 키로 취급될 수 있다 | chronyc tracking 의 오프셋. Kudu 시간 동기화와 NTP |
| 마스터 리더 교체 직후 | 일부 태블릿 서버가 새 TSK 를 아직 못 받았다 | 마스터 로그의 리더 선출 이력 |
| 태블릿 서버 재시작 후 초기화 미완료 | 짧게 끝나야 정상이다. 지속되면 heartbeat 문제 | 해당 노드 로그 |
| 마스터와 태블릿 서버 버전 불일치 | 롤링 업그레이드 중 | 버전 대조 |
로그에서 볼 키워드는 마스터 쪽 token_signing · TSK · generate_token, 태블릿 서버 쪽 authz_token · verify · unknown key 와 heartbeat 경고다.
관찰 → 최소 개입 → 롤링 재시작 순서를 지킨다. Kudu 는 복제본이 세 벌이면 태블릿 서버 단위 롤링 작업이 비교적 안전하지만 마스터는 더 신중해야 한다.
1. 호스트 시간 동기화 확인 ← 여기서 원인을 찾으면 끝난다
2. ksck + 로그 확인
3. 쿼리 엔진(클라이언트) 재시작 ← 캐시된 토큰을 털어낸다
4. 인가 캐시 초기화
5. 문제 태블릿 서버 한 대만 재시작
6. 태블릿 서버 롤링 재시작 (한 대씩, 사이에 충분한 대기)
7. 마스터 롤링 재시작 (HA 구성일 때만, 팔로워부터 리더는 마지막)
Ranger 기반 권한을 쓰는 환경이면 인가 캐시를 초기화할 수 있다. 무중단이다.
sudo -u kudu kudu master authz_cache reset <master_addresses>
권장하지 않는 것은 다음이다 — Kudu 서비스 전체 재시작(쿼리 전면 중단, 원인 파악 없이 하면 재발한다), 마스터 동시 재시작(쓰기 불가 구간과 메타데이터 위험), 원인 없이 토큰 관련 설정 변경.
롤링 재시작은 복제 계수가 1 인 테이블이 있으면 그 테이블만 일시적으로 조회 불가가 된다. 먼저 ksck 로 확인한다.
kudu cluster rebalance 옵션과 주의점.