결론부터 말씀드리면, random read 꼬리 지연은 세 가지 대기 시간의 합이고, 그중 겹침을 피하도록 스케줄링하면 P99.99 가 내려갑니다. 출발은 전력 절감 정책의 부작용 수습이었는데, 결과적으로 전력 절감을 안 해도 효과가 있었고, 어떤 제품군에 효과가 있는지 판별 기준까지 얻었습니다.

배경입니다. 전력을 아끼려고 같은 bank 로 가는 read 를 모아 한 번에 처리하는 정책이 있었습니다. 전력은 줄었는데, 모으는 동안 먼저 온 다른 bank 의 read 가 기다리게 됐고, 평균은 그대로인데 P99.99 만 튀었습니다. host 가 보는 품질은 평균이 아니라 꼬리라서, 이 스파이크 하나가 전력 절감 채택을 막습니다.

그래서 과제 범위를 이렇게 잡았습니다. 대상은 host random read, 환경은 SSD 시뮬레이터, 제품군 세 종. 산출물은 계측 지표, 스케줄링 정책, 제품군 선별 기준 세 가지입니다.

문제를 셋으로 정리했습니다. 첫째, 평균은 정상인데 꼬리만 튄다. 둘째, 전력 절감이 어느 read 를 얼마나 지연시키는지 모른다. 셋째, 정책을 넣으면 다른 read 가 굶을 수 있다.

여기서 요구사항 다섯을 뽑았습니다. read 한 건의 지연을 성분별로 계측할 것, 겹침이 예상되는 read 를 피해 발행할 것, 양보에 한도를 둘 것, 전력 절감과 함께 동작할 것, 제품군별 적용 여부를 판별할 것. 첫 번째 계측이 나머지의 전제입니다. 어디서 기다리는지 모르면 정책도 판별도 못 합니다.

read 한 건의 경로입니다. 호스트 큐에서 스케줄러를 거쳐 채널로, 채널 안의 plane 으로 갑니다. 기다림은 세 곳에서 생깁니다. 같은 plane 이 바쁘면 ①, plane 은 비었는데 채널이 바쁘면 ②, 그 밖의 큐 대기가 ③입니다. 시뮬레이터에 이 세 구간을 재는 지표를 넣었습니다.

계측 결과입니다. 중앙값에서는 ③ 큐 대기가 대부분인데, 꼬리로 갈수록 ①② 겹침이 커지고 P99.99 에서는 겹침이 대부분입니다. 꼬리 지연은 운 나쁘게 같은 곳으로 몰린 read 가 만듭니다. 그래서 표적은 큐 길이가 아니라 겹침입니다.

설계입니다. read 마다 도착, plane 이 비는 시각, 채널이 비는 시각, 발행 시각을 찍으면 그 차이가 ①②③입니다. 정책은 큐 맨 앞 read 가 겹침이 예상되면 준비된 다른 read 를 먼저 보내고, 누적 양보가 임계값을 넘으면 그냥 발행해 굶김을 막습니다. 도착순 유지, 정적 우선순위와 비교해 이 방식을 골랐고, 비교는 부록에 있습니다.

검증은 제품군 세 종에 대해 base, 전력 절감, base 에 정책, 전력 절감에 정책, 네 구성을 같은 워크로드로 돌려 P50, P99, P99.99 를 base 대비 상대값으로 비교했습니다. 같은 조건을 반복해 변동폭을 확인했고 임계값은 스윕으로 정했습니다.

결과입니다. 효과가 있는 제품군에서는 전력 절감이 올린 P99.99 를 정책이 base 아래로 내렸고, 전력 절감 없이 base 에 얹어도 내려갔습니다. 반면 한 제품군은 효과가 없었는데, 그 제품군은 P99.99 에서도 ③ 큐 대기가 커서 겹침 회피의 표적이 없었습니다. 효과가 없는 이유가 같은 원리로 설명되므로, 이 결과를 믿고 선별 적용 기준으로 쓸 수 있습니다.

정량으로는 P99.99 개선과 전력 절감 페널티 상쇄, 정성으로는 판단 도구 둘이 남았습니다. 계측 지표는 다른 과제에도 쓰는 자산이고, 선별 기준은 제품군별로 이 정책을 켤지 정하는 근거입니다. 업무에서는 전력 정책 채택 판단, 제품군별 정책 적용, 새 제품군의 병렬 구조 설계에 씁니다.

교육 내용 중 넷을 직접 썼습니다. 운영체제의 스케줄링 정책과 디스크 스케줄링의 starvation 트레이드오프가 정책과 임계값의 근거였고, 컴퓨터구조의 성능 지표와 Little's Law, Amdahl 이 지연 분해와 결과 해석에, 컴파일러의 List Scheduling 이 준비된 요청 중 충돌 없는 것을 먼저 고르는 정책 골격에, 디지털집적회로의 NAND 동작이 같은 plane 에서 왜 기다리는지에 쓰였습니다. percentile 꼬리 분석과 plane·channel 병렬 모델은 과정에 없어 따로 학습했습니다.

한계 셋입니다. 임계값이 아직 제품별 실험값이라 내부 지표로 계산하는 수식을 검토하겠습니다. 효과 있는 제품군의 조건이 경험적이라 breakdown 비중 기준으로 정식화하겠습니다. read 전용만 검증했으니 쓰기 혼합 워크로드로 넓히겠습니다. 이상입니다.

정적 우선순위는 구현이 쉽지만 낮은 순위 plane 이 굶습니다. 운영체제 수업의 SSTF 대 SCAN 과 같은 트레이드오프라, 효율 우선 재정렬에는 상한이 필요하다고 판단해 겹침 회피에 임계값을 붙였습니다.

같은 워크로드와 시뮬레이터에서 시드만 바꿔 반복했고, 개선폭이 변동폭보다 큰지 확인했습니다. 임계값은 너무 작으면 양보를 못 해 겹침이 그대로고, 너무 크면 양보당한 read 가 굶어 다시 올라갑니다. 그 사이 최소점을 채택했습니다.

수업에서 저장장치 구조와 스케줄링을 배웠는데, 실제로 전력 정책이 꼬리 지연에 주는 영향을 판단하려면 그 둘을 붙여서 어디서 얼마나 기다리는지를 재는 도구가 필요했습니다. 그 간극을 직접 메워 보는 게 이 과제였습니다.