실제 발동 빈도를 검증한다

전에 있었던 장애의 원인으로 반복 인코딩 로직이 지목됐는데 이미 제거한 것을 재도입할지 검토하게 됐다.

Open Table of contents

상황 — 반복 인코딩이 지목됐다

장애 원인으로 지목된 로직은 이런 것이었다.

출력이 상한을 넘으면 품질을 낮춰 다시 인코딩
최대 5회 반복

최대 5회 반복 이라는 줄 때문에 무거워 보이는 모양이었다.

물음은 여러 압축률을 반복 처리하는 것이 원인이었으니 미리 계산해서 한 번에 압축할 수 없느냐는 것이었다. 답하기 전에 그 로직이 운영에서 실제로 얼마나 발동했는지부터 확인했다.

답하기에 앞서 원본과 변환 출력의 관계부터 봤다.

원본 (다른 포맷)  1.6MB
변환 출력         109KB

원본 1.6MB 가 109KB 로 나오니 축소와 품질 조정을 거치면 훨씬 작아진다.

원본 크기로 출력을 짐작하면 안 된다는 뜻이라 출력 쪽 분포를 직접 뽑았다.

1MB 초과   1.86%
3MB 초과      0건

최근 5천 건에서 1MB 초과 가 2퍼센트 아래였고 큰 원본 자체가 적었다.

그중 가장 큰 40개를 골라 실제 변환 출력을 조회했다.

원본  1.5 ~ 1.6MB
평균  98KB
최대  108KB
1MB 초과  0건

최댓값이 108KB 라 최악의 경우도 상한의 10분의 1이었다.

발동 조건과 실측값을 나란히 놓아 봤다.

반복 인코딩의 발동 조건  →  출력이 1MB 초과
실제 최대 출력           →  108KB

1MB 초과 에 도달한 적이 사실상 없으니 그 로직이 장애 원인일 수 없다.

원인 후보 하나가 배제되면서 조사가 곧바로 다른 방향으로 넘어갔다. 다시 보니 파이프라인 복제 오버헤드 와 순간 부하 누적 이 후보로 올라왔다.

이 건에서 무엇을 잘못 봤는지 정리했다.

[본 것]   반복 루프가 있다
[추정]    그래서 무겁다
[실제]    발동한 적이 없다

반복 루프 가 있다는 것과 그것이 실제로 돈다는 것은 다르다.

그래서 규칙으로 하나 적어 두었는데 장애 원인을 코드 형태만으로 추정하지 말고 조건이 무엇인지와 그 조건에 도달하는 데이터가 실제로 있는지를 운영 데이터로 확인한다.

처음에 받은 물음에도 답해야 했다.

인코딩이 이미지 내용에 의존한다
    ↓
같은 품질이어도 이미지마다 출력 크기가 다르다
    ↓
목표 크기에서 품질을 역산하는 닫힌 공식이 없다

품질 값을 계산으로 구할 수 없어서 미리 한 번에 압축하는 것은 원리적으로 안 된다.

한 번도 발동한 적이 없다고 해서 그 구조가 안전하다는 뜻도 아니었다. 앞으로 더 크고 복잡한 원본이 들어오기 시작하면 그때는 실제로 발동한다.

그래도 출력 상한이 꼭 필요하면 방법이 있었다.

1패스  →  기본 품질로 인코딩
        →  실측 크기를 본다
2패스  →  실측 크기 기반으로 품질을 비례 재계산
        →  다시 인코딩

최대 5회 반복 이 아니라 1패스 와 2패스 두 번으로 끝낸다.

실측 크기 기반 비례식이라 정확하지는 않아도 대략 맞으니 실용적이다. 회신에는 셋을 나눠 적었다.

① 그 로직이 원인이었나   →  아니다 (발동 안 함)
② 미리 계산할 수 있나    →  원리적으로 불가
③ 그래도 필요하면 어떻게  →  2패스 비례 재계산

원인이 아니라고만 답하면 문제 제기 자체가 무시된 것으로 읽힌다.

전제를 정정하면서 필요한 대안까지 함께 줘야 그 논의가 끝난다. 그 뒤로 같은 코드가 장애의 원인으로 다시 지목되는 일은 없어졌다.