중복 없이/백필 방식 수집 성능 고려사항
중복 없이/백필 방식 수집 성능 고려사항 (Out-of-order / backfilled ingestion performance considerations)
시계열 데이터에 오래된 타임스탬프를 삽입할 때 성능이 어떻게 달라지는지에 대해 설명할게요. 특히 순서가 어긋난(Out-of-order) 데이터를 '백필(backfill)'로 넣는 경우, 압축 청크와 비압축 청크에서 성능 영향이 어떻게 다른지 살펴볼게요.
오래된 타임스탬프가 Time Series에 삽입되면, 새 샘플의 시간 프레임에 해당하는 메모리 청크를 주 메모리에서 가져와야 할 수 있어요 (이 청크에 대해 더 자세히는 여기에서 읽어볼 수 있어요). 이 청크가 압축된 청크라면, 삽입/갱신 전에 디코딩도 해야 해요. 이들은 메모리 집약적이고 — 디코딩의 경우 계산 집약적인 — 작업으로, 달성 가능한 전체 수집 속도에 영향을 줘요.
수집 성능은 매우 중요해서, 우리는 out-of-order 백필 비율이 전체 고성능 TSDB에 미치는 영향을 평가하고 투명하게 공개하게 됐어요.
이를 위해 시스템 전체 성능을 결정하는 핵심 요소들 — out-of-order 비율, 시리즈의 압축 여부, 사용된 동시 클라이언트 수, 명령 파이프라이닝 등 — 을 제어할 수 있는 Go 벤치마크 클라이언트를 만들었어요. 전체 벤치마크 드라이버 구성 세부사항과 파라미터는 GitHub 링크를 참고하세요.
또한 모든 벤치마크 변형은 벤치마크 테스트 인프라를 통해 프로비저닝된 Amazon Web Services 인스턴스에서 실행됐어요. 벤치마킹 클라이언트와 데이터베이스 서버 모두 별도의 c5.9xlarge 인스턴스에서 실행됐어요. 테스트는 단일 샤드 설정에서 RedisTimeSeries 버전 1.4로 수행됐어요.
아래에서 압축 및 비압축 청크 각각에 대해 달성 가능한 ops/sec과 out-of-order 비율 사이의 상관관계를 볼 수 있어요.
압축 청크의 out-of-order/백필 영향 분석 (Compressed chunks out-of-order/backfilled impact analysis)
압축 청크의 경우, 단일 out-of-order 데이터포인트가 청크 전체의 double delta 압축 해제를 의미하므로, out-of-order 쓰기에서 더 높은 오버헤드를 기대해야 해요.
경험칙으로, out-of-order 압축 성능을 높이려면 청크 크기를 최대한 줄여야 해요. 작은 청크는 double-delta 압축 해제에 필요한 계산이 줄어들어 전반적인 영향이 적어지지만, 압축 비율이 낮아지는 단점이 있어요.
아래 그래프와 표는 다음과 같은 핵심 포인트를 보여줘요.
- 데이터베이스가 현재 기본 청크 크기(바이트 4096)로 1%의 out-of-order 샘플을 받으면, 수집 속도에 미치는 전체 영향은 10%여야 해요.
- 5%, 10%, 심지어 25% 같은 더 큰 out-of-order 비율에서는 전체 영향이 ops/sec 35%~75% 감소여야 해요. 이 정도의 out-of-order 비율이라면 청크 크기 축소를 진지하게 고려해야 해요.
- 99%의 out-of-order 수집에서도 달성 가능한 ops/sec이 최대 95%까지 떨어지는 것을 관찰했어요. (다시 말하지만, 청크 크기를 줄이면 그 영향을 절반으로 줄일 수 있어요.)
비압축 청크의 out-of-order/백필 영향 분석 (Uncompressed chunks out-of-order/backfilled impact analysis)
아래 차트와 표에서 볼 수 있듯이, 청크 크기는 out-of-order가 수집에 미치는 전체 영향에 영향을 주지 않아요 (즉, 청크 크기가 256바이트든 4096바이트든 out-of-order 수집의 예상 영향은 동일해요 — 그래야 정상이죠). 그 외에 다음과 같은 핵심 요점을 관찰할 수 있어요.
- 데이터베이스가 1%의 out-of-order 샘플을 받으면 수집 속도에 미치는 전체 영향은 낮거나 측정할 수 없을 정도여야 해요.
- 5%, 10%, 심지어 25% 같은 더 높은 out-of-order 비율에서는 전체 영향이 ops/sec 5%~19% 감소여야 해요.
- 99%의 out-of-order 수집에서도 달성 가능한 ops/sec이 최대 45%까지 떨어지는 것을 관찰했어요.
