InfluxDB가 High Cardinality로 인해 Startup 시 OOM으로 Crash됩니다. 문제 Measurement를 어떻게 식별하고 삭제할 수 있을까요?

안녕하세요,

설명해 주신 내용을 보면, 현재 증상은 high-entropy tag로 인해 cardinality explosion이 발생한 상황과 일치합니다. 즉, dynamic tag가 매우 많은 수의 series key를 생성하면서 startup 과정에서 Time Series Index(TSI) 가 사용 가능한 메모리를 초과한 것으로 보입니다. 우선 복구 작업을 진행하기 전에 data directory 전체를 백업해 두는 것을 권장합니다. 문제가 발생하더라도 원래 상태로 되돌릴 수 있는 안전한 rollback point를 확보하는 것이 중요합니다.

InfluxDB가 정상적으로 startup되지 않는 상황이라면, 우선 문제가 발생한 database와 retention policy를 offline 상태에서 조사하여 series 수가 비정상적으로 많은 measurement를 식별하는 데 집중하는 것이 좋습니다. 인스턴스가 metadata에 접근할 수 있을 정도로 안정화되면, measurement별 및 tag set별 series cardinality를 비교해 보면 문제를 일으킨 dynamic tag를 비교적 빠르게 찾을 수 있습니다. 실제로 이런 문제의 원인은 request ID, session ID, UUID, timestamp처럼 값의 고유성이 매우 높은 데이터를 tag로 저장한 경우가 많습니다. 이런 값들은 일반적으로 tag보다는 field로 저장하는 것이 적절합니다.

데이터 cleanup을 진행할 때는 특히 주의해야 합니다. 먼저 high-cardinality를 유발하는 measurement 또는 tag set을 정확히 식별하고, 다른 workload에서 해당 데이터가 필요하지 않은지 확인한 후 제거하는 것을 권장합니다. Vendor의 별도 지침 없이 index file을 직접 삭제하는 것은 피하는 것이 좋습니다. 잘못된 index 파일 삭제는 추가적인 recovery 문제를 발생시킬 수 있습니다. 데이터 삭제가 필요한 경우에도 database 전체를 대상으로 broad cleanup을 수행하기보다는, 영향 범위를 최소화할 수 있도록 문제가 확인된 measurement 또는 데이터만 targeted deletion 방식으로 제거하는 것이 좋습니다.

시스템이 정상적으로 복구된 이후에는 cardinality monitoring을 적용하고 schema design도 함께 검토하는 것을 강력히 권장합니다. 앞으로 dynamic identifier를 tag로 저장하지 않도록 하는 것이 중요합니다. 무제한으로 증가하는 tag cardinality를 사전에 방지하는 것이 단순히 메모리를 증설하는 것보다 일반적으로 훨씬 효과적입니다. 데이터 볼륨이 증가하면 동일한 문제가 다시 발생할 가능성이 있기 때문입니다.

도움이 되는 정보였기를 바랍니다. 답변이 문제 해결에 도움이 되었다면 “Accept Answer”를 눌러 주시면 감사하겠습니다. 제가 안내드린 내용이 현재 문제를 해결하는 데 도움이 되었는지 확인하는 데도 큰 도움이 됩니다.

Jason