요약

  • RIPE NCC에 따르면 대량의 BGP 트래픽을 보내는 피어가 카프카(Kafka) 파티션 하나에 부하를 일으켰고, 프로세스가 재시작된 후 잠재 버그가 대량의 데이터를 반복적으로 재스캔하며 타임아웃에 빠졌습니다.
  • 구성 수정을 통해 복구가 이루어졌고, RIPE NCC는 10월 2일부터의 BVIEW 및 업데이트 파일이 성공적으로 생성되었다고 밝혔습니다. 재시작 버그에 대한 구조적 수정은 이후 스프린트에서 예정된 상태였습니다.
  • 공개 파일의 복구는 실패 경로가 제거되었다는 주장과 같지 않습니다. 이번 인시던트는 RIPE RIS 데이터 생산에 관한 것이며, 경로나 고객 트래픽이 사라졌다는 증거가 아닙니다.

복구 작업이 끝나기 전에 아카이브가 먼저 돌아왔다

10월 6일, RIPE NCC는 해결 노트 안에 특정한 구분을 두면서 RRC12 MRT 업데이트 및 BVIEW 파일에 대한 인시던트를 종결했습니다. 10월 2일 이후의 파일들은 프로세스가 복구된 뒤 성공적으로 생성되었다는 것입니다. 즉각적인 복구는 구성 수정을 통해 이루어졌습니다. 조직은 또한 잠재 버그에 대한 구조적 수정을 다음 스프린트에서 진행하겠다고 밝혔습니다.

이 발표들은 하나가 아니라 두 가지 상태를 기술합니다. 공개 기록은 보충되었지만, 재시작이 반복적으로 실패하게 만든 메커니즘이 구조적으로 변경되었다고까지는 서술되지 않았습니다. 서비스는 엔지니어링 과제가 열려 있는 상태에서도 운영 중으로 돌아올 수 있습니다. 첫 번째 사실을 두 번째 사실의 증명으로 취급하면 상태 페이지가 실제보다 더 많은 것을 말하게 됩니다.

사건은 10월 2일 01:30 UTC에 시작되었습니다. RIPE NCC에 따르면 그때 DE-CIX 피어가 RRC12에 비정상적으로 많은 BGP 메시지를 보내기 시작했습니다. 카프카에서 데이터를 소비하는 처리 파이프라인이 이를 따라가지 못했고, 프로세스가 타임아웃되어 재시작했다가 충분한 진전을 이루기 전에 다시 타임아웃되었습니다. 이후 RIPE NCC는 다른 RRC 업데이트 파일의 생산에서도 지연을 관찰했습니다.

이후 제공된 설명은 초기 공지가 담지 못한 부분을 보탰습니다. 유입된 트래픽량이 카프카 파티션 하나에 부하를 실었다는 것입니다. 프로세스가 재시작되자 잠재 버그 때문에 시작 단계에서 대량의 데이터를 재스캔하게 되었고, 그 스캔이 반복적으로 타임아웃되었습니다. 코드 구성이 이 작업을 원래보다 한 자릿수 더 오래 걸리게 만들었습니다. 그 구성을 수정하자 프로세스가 복구되었고, 구조적 변경은 아직 남아 있었습니다.

파일이 의미하는 것

RRC12는 DE-CIX에 있는 RIPE의 프랑크푸르트 경로 수집기입니다. RIPE 문서는 두 가지 공개 아티팩트를 구분합니다. BVIEW 파일은 특정 시점의 라우팅 상태 스냅샷이고, 업데이트 파일은 일정 구간의 변경 사항을 기록합니다. 문서에 따른 생성 주기는 덤프는 통상 8시간, 업데이트는 5분입니다. RIPE는 MRT 파일이 BGP 디버깅, 사후 분석, 장기 추세 분석에 활용될 수 있다고 설명합니다.

따라서 공개 증거만으로 특정 구간을 재구성하려는 사람들에게 게시 공백은 중요한 문제입니다. 하지만 이것이 라우팅 장애를 의미하지는 않습니다. 인시던트 기록은 파일 생성 지연을 확립할 뿐, 누락된 경로, 실패한 트래픽, 피어의 의도, 고객 피해를 입증하지 않습니다. 해당 피어의 이름이나 메시지 전송률, 백로그, 다른 수집기의 지연 기간, 영향받은 분석 건수는 명시되지 않았습니다.

10월 아카이브 색인에는 현재 10월 7일까지의 BVIEW 및 업데이트 파일명이 나열되어 있습니다. 공개 디렉터리에 이후 아티팩트가 존재한다는 유용한 현재 시점 확인이 됩니다. 그러나 모든 파일이 완전하다는 것, 재생성된 데이터가 별도의 무결성 검사를 통과했다는 것, 다운스트림 분석이 실시간 스트림을 이용했을 때와 동일한 결과에 도달했을 것이라는 것을 독립적으로 증명하지는 못합니다.

복구의 종착선은 하나가 아니다

인시던트의 단계들을 단일한 '녹색 상태'로 묶어서는 안 됩니다. 먼저 입력 급증이 더 이상 장애 요인이 아니 되었습니다. 다음으로 재시작된 프로세스가 진전을 이루었습니다. 그다음 누락된 파일이 생성되었습니다. 별개로, 잠재된 시작 경로는 구조적 작업 대상으로 남아 있었습니다. 이들은 서로 다른 운영상 주장이며 각각 따로 보고되어야 합니다.

이 구분은 측정 시스템에서 익숙한 것입니다. 기록의 복구는 “파일이 다시 생성되고 있는가?”라는 질문에 답합니다. 그러나 “복구를 취약하게 만든 조건이 제거되었는가?”에는 완전히 답하지 않으며, “복구된 시계열의 완전성이 검증되었는가?”에도 답하지 않습니다. 공개 업데이트는 첫 번째 질문에 답하고 두 번째에 대해 향후 과제를 명시하지만, 세 번째에 대한 독립적인 완전성 확인서는 게시하지 않았습니다.

이것이 RIPE의 복구가 부적절했다는 증거는 아닙니다. 이용 가능한 상태 공지가 단지 완전한 사후 인시던트 보고서보다 좁을 뿐입니다. 공지는 트리거, 단일 파티션 부하, 재시작 재스캔, 구성 수정, 다음 스프린트의 구조적 작업을 밝히고 있습니다. 반면 피어, 전송률, 큐 측정치, 수집기별 지연 구간, 검증 방법, 릴리스 식별자는 공개되지 않았습니다.

공개 측정 아카이브의 사용자에게 유용한 종결 기록은 민감한 구현 세부사항을 노출하지 않으면서 이 요소들을 연결할 것입니다. 영향받은 수집기와 시간 구간, 파일 재생성 여부, 수행된 검증, 현재 활성화된 임시 조치, 남아 있는 구조적 변경, 그 변경이 검증된 시점이 그것입니다. 타임스탬프가 찍힌 기록이 있다면 이후 분석가가 가용성 복구와 신뢰성 수정의 완료를 구별할 수 있을 것입니다.

신중한 결론은 절제된 것입니다. RRC12의 파일은 워크로드 급증이 구성으로 인해 증폭된 재시작 약점을 드러낸 뒤 복구되었습니다. RIPE NCC는 구조적 개선이 아직 남아 있다고 밝혔습니다. 아카이브는 인터넷의 전체 라우팅 테이블이 아니며, 장애 공지는 경로 실패의 증거가 아닙니다. 그러나 “파일이 돌아왔다”와 “복구 경로가 고쳐졌다” 사이의 구별은 바로 측정 서비스가 판독 가능하게 만들어야 할 종류의 구별입니다.

출처