Erasure-coded 객체에서 shard 하나가 없어 degraded read를 제공할 때 읽기 latency와 repair traffic을 어떻게 분리해서 보나요?

degraded read는 missing shard를 요청 시점에 남은 shard에서 재구성해 응답하는 동기 경로이고, repair는 재구성한 결과를 새 shard로 durable하게 기록해 이후 정상 read로 돌아가는 백그라운드 경로입니다. 둘을 “읽기 한 번의 복구”로 합치면 읽기 latency와 repair backlog를 측정할 수 없습니다.

MDS/RS형 k=4,m=2에서 data shard 하나가 사라졌다고 하겠습니다. 정상 range가 data 1~2개만 읽던 layout이어도 missing data를 계산하려면 profile이 요구하는 4개 shard의 해당 stripe 범위를 병렬로 읽고 decode해야 할 수 있습니다. 따라서 fan-in, 네트워크 왕복, decode CPU, 가장 느린 shard의 tail이 p99에 추가됩니다. repair는 정상 shard를 다시 읽고 새 조각을 쓰며 checksum·generation·durability를 검증하므로 별도 read/write bandwidth를 소비합니다. worker를 늘려 backlog를 줄이면 foreground I/O를 압박할 수 있어 concurrency cap, degraded object 수, 남은 허용 손실, repair age를 함께 기준으로 삼습니다. 읽기 성공은 repair 완료가 아니며 다음 장애 전 복구가 우선입니다.

판단 순서는 먼저 해당 stripe의 유효 조각 수와 요청 범위를 계산하고, 그 다음 정상 경로와 degraded 경로의 shard 수를 비교하는 것입니다. 예를 들어 정상 read가 2개 shard와 1회 왕복으로 끝났는데 degraded read가 4개 shard와 decode를 요구하면, 평균 latency가 아니라 가장 느린 shard와 queue 대기를 p99로 봐야 합니다. repair가 끝나기 전에는 객체 상태를 healthy로 바꾸지 않고 degraded로 표시하여 추가 장애 시 보호 여유를 다시 계산합니다.