Loki의 스케일을 줄였는데 쓰기가 실패한 이유

Loki의 스케일을 줄이는 과정에서 쓰기 요청이 실패하는 문제가 있었다. 로그를 받는 인스턴스가 갑자기 죽은 상황은 아니었다. 종료 중인 인스턴스를 쓰기 대상에서 제외한 뒤 다른 인스턴스로 채우지 않는 동작이 문제였다.

우리 환경에서는 복제 계수(Replication Factor)를 뜻하는 RF를 2로 유지하고 있다. 같은 로그를 두 인스턴스에 복제해서 쓴다. RF가 2일 때는 두 쓰기 대상이 모두 필요해 한 곳이 빠지면 여유가 없다.

쓰기를 처리하는 데 필요한 최소 복제본 수를 정족수(Quorum)라고 한다. 다른 인스턴스가 정상이어도 해당 요청의 쓰기 대상이 부족하면 요청은 실패한다. 분석한 경로에서는 종료 중인 인스턴스가 빠졌을 때 다른 정상 인스턴스를 선택하지 않아 오류가 반환됐다.

이 동작은 자동 확장으로 인스턴스가 줄어들 때도 문제가 된다. 부하가 낮아져 용량을 줄이는 작업이 클라이언트의 쓰기 재시도를 유발할 수 있다. 인스턴스를 늘릴 때만 확인해서는 축소 과정의 실패를 놓친다.

개선안은 종료 중인 인스턴스 대신 다른 정상 인스턴스를 선택해 필요한 복제본 수를 유지하는 방식이다. 이 동작을 선택해서 켤 수 있도록 Loki PR #23908을 제출했다.

기본 동작은 바꾸지 않고 설정을 켠 경우에만 쓰기 대상을 보충하도록 제안했다. Mimir에 이미 있던 같은 목적의 설정도 참고했다.

쓰기를 다른 인스턴스에 보내면 조회할 때도 그 데이터를 찾을 수 있어야 한다. PR에서는 조회 경로가 종료 중인 인스턴스와 추가 대상을 포함하는 동작도 함께 확인했다. 쓰기 오류만 없어지고 조회 결과에서 로그가 빠지는 변경이면 받아들일 수 없기 때문이다.

이 글의 작성일인 2026년 9월 23일 기준으로 PR은 검토 중이다. Loki에 반영된 결과가 아닌 개선안을 제안하는 과정이다.

RF를 2로 유지하려면 스케일을 줄일 때도 두 쓰기 대상을 확보할 수 있어야 한다. 종료 절차가 정상인지와 함께 종료 중인 인스턴스가 빠지는 순간 다른 대상을 선택할 수 있는지 확인해야 한다. 그렇지 않으면 부하를 줄인 뒤에도 쓰기 요청은 실패할 수 있다.