매일메일에서 백엔드와 연관된 CS 면접질문들을 보내주는데 오늘은 흥미로운 내용이 있어서 정리하려고 한다.
내 코드나 쿼리가 느려지는 원인이 CPU, 메모리, 네트워크, 디스크I/O 때문일 수도 있다는 것이다.
1. 디스크 접근 시간 (Disk Access Time) - HDD 기준
하드 디스크(HDD)에서 특정 데이터 블록을 읽거나 쓰는 데 걸리는 총 시간을 의미합니다.
이 시간은 기계적인 동작에 드는 시간이 큰 비중을 차지하며, 세 가지 주요 구성 요소의 합입니다.
디스크 접근 시간 = 탐색 시간 + 회전 지연 시간 + 데이터 전송 시간
1) 탐색 시간 (Seek Time)
-
정의: 디스크의 헤드(Head)를 데이터가 있는 트랙(Track) / 실린더(Cylinder)까지 이동시키는 데 걸리는 시간입니다.
-
특징: 기계적인 팔(Arm)이 물리적으로 움직이는 과정이라, 디스크 접근 시간 중 가장 오래 걸릴 수 있는 병목 지점입니다.
2) 회전 지연 시간 (Rotational Latency)
-
정의: 헤드가 목표 트랙에 도착한 후, 디스크 원판(Platter)이 회전하여 원하는 섹터(Sector)가 헤드 바로 아래에 올 때까지 기다리는 시간입니다.
-
특징: 디스크의 분당 회전수(RPM)가 높을수록 이 지연 시간은 줄어듭니다. (예: 7,200 RPM이 5,400 RPM보다 빠름)
3) 데이터 전송 시간 (Data Transfer Time)
-
정의: 헤드 아래에 위치한 섹터에서 실제 데이터를 읽어(Read) 버퍼로 옮기거나, 버퍼의 데이터를 쓰는(Write) 데 걸리는 시간입니다.
-
특징: 전송할 데이터 블록의 크기, 트랙의 저장 밀도 등에 영향을 받습니다.
2. 순차 접근이 랜덤 접근보다 빠른 이유 (HDD)
핵심은 탐색 시간과 회전 지연 시간이라는 '기계적 지연(Mechanical Delay)'을 얼마나 자주 겪느냐에 있습니다.
1) 순차 접근 (Sequential Access)
-
데이터가 디스크에 물리적으로 연속된 블록에 저장되어 있습니다. (예: 큰 동영상 파일, 로그 파일)
-
최초 1회의 탐색 시간과 회전 지연 시간만 발생하면, 그 후로는 헤드를 거의 움직이지 않고 데이터를 연속으로 쭉 읽어 들입니다.
-
접근 시간 = (1 x 탐색) + (1 x 회전) + (N x 전송)
-
기계적 지연이 최소화되므로 속도가 매우 빠릅니다.
2) 랜덤 접근 (Random Access)
-
데이터가 디스크 여러 곳에 흩어져 저장되어 있습니다.
(예: DB 인덱스를 타지 않는 쿼리, 여기저기 흩어진 작은 파일들) -
각각의 데이터 블록을 읽을 때마다 헤드가 새 위치로 이동(탐색 시간)하고, 섹터가 돌아오길 기다려야(회전 지연 시간) 합니다.
-
접근 시간 = (N x 탐색) + (N x 회전) + (N x 전송)
-
데이터 조각이 100개라면, 이 기계적 지연이 100번 반복됩니다.
한줄 요약
랜덤 접근은 데이터를 찾기 위한 기계적인 이동(탐색 + 회전)을 계속 반복해야 하므로, 한 번의 이동으로 쭉 읽는 순차 접근보다 훨씬 느릴 수밖에 없습니다.
3. 현대의 스토리지: SSD (Solid State Drive)
위의 모든 설명은 기계식 HDD에 해당합니다. 하지만 현대의 서버와 PC는 대부분 SSD를 사용하며, SSD는 이 문제를 근본적으로 다르게 해결합니다.
-
작동 원리: SSD는 HDD처럼 움직이는 팔이나 회전하는 원판이 없습니다. 낸드 플래시(NAND Flash) 메모리 반도체를 이용해 전자적으로 데이터를 읽고 씁니다.
-
탐색 시간과 회전 지연의 제거: 물리적인 이동이 없으므로, 탐색 시간과 회전 지연 시간이 사실상 0에 가깝습니다.
-
성능:
HDD가 치명적으로 느렸던 랜덤 접근 속도가 SSD에서는 극적으로 향상되었습니다.
(참고: SSD도 여전히 순차 접근이 랜덤 접근보다 조금 더 빠르긴 하지만, HDD만큼 그 격차가 압도적이지 않음.)
4. 개발자가 알아야 할 연관 지식 (소프트웨어)
이러한 하드웨어의 한계를 극복하기 위해 소프트웨어(운영체제, DB 등)는 다양한 전략을 사용합니다.
1) 운영체제(OS)의 페이지 캐시 (Page Cache)
- OS는 디스크 I/O가 RAM 접근보다 수천~수만 배 느리다는 것을 압니다.
- 따라서 RAM의 일부를 디스크 데이터의 '캐시' 공간으로 사용합니다. (이것이 '페이지 캐시' 또는 '버퍼 캐시'입니다.)
- 읽기: 애플리케이션이 파일 읽기를 요청하면, OS는 디스크를 보기 전에 먼저 RAM 캐시를 확인합니다. 데이터가 캐시에 있으면(Cache Hit), 디스크 접근 없이 즉시 반환합니다. (매우 빠름)
- 쓰기: 애플리케이션이 파일 쓰기를 요청하면, OS는 일단 RAM 캐시에만 쓰고 "완료"라고 응답합니다. 실제 디스크에 쓰는 작업은 나중에 백그라운드에서 모아서 처리합니다. (Write-Back 전략)
- Takeaway: 어제 10초 걸린 쿼리가 오늘 0.1초 만에 실행된다면, 해당 데이터가 DB나 OS의 페이지 캐시에 적재되었기 때문일 확률이 높습니다.
2) 데이터베이스 인덱스 (B-Tree)
- 인덱스의 목적: 수억 개의 데이터(HDD의 여러 트랙에 흩어진) 중에서 '단 하나의 데이터'를 찾을 때, 모든 데이터를 순차적으로 읽는(Full Table Scan) 비효율을 막는 것입니다.
- B-Tree 자료구조: B-Tree는 '디스크 접근 횟수(I/O)'를 최소화하도록 특별히 설계된 자료구조입니다.
- 하나의 노드(블록)에 많은 데이터를 저장하여 트리의 높이(Depth)를 극단적으로 낮춥니다.
- 트리의 높이가 3~4 정도만 되어도 수백만~수천만 건의 데이터를 처리할 수 있습니다.
- 즉, 원하는 데이터를 찾기 위해 디스크 '탐색(Seek)'을 3~4번만 하면 되도록 만들어줍니다.
3) 애플리케이션의 로깅 (버퍼링)
- 만약 log.write("에러 발생")이라는 코드가 호출될 때마다 즉시 디스크 파일에 쓴다면, 이는 수많은 '작은 랜덤 쓰기(Small Random Write)'를 유발합니다.
- 이는 HDD에서 최악의 성능을 보이며, 애플리케이션 전체의 응답 속도를 저하시킵니다.
- 해결책 (Buffering): 대부분의 로깅 라이브러리는 로그 메시지를 즉시 쓰지 않고, 일단 메모리 버퍼에 모아 둡니다.
- 버퍼가 가득 차거나 특정 시간이 되면, 모아둔 로그 전체를 '하나의 큰 순차 쓰기(Large Sequential Write)'로 디스크에 기록합니다.
- Takeaway: 수천 번의 랜덤 쓰기를 한 번의 순차 쓰기로 바꿔, 디스크의 기계적 지연을 최소화하는 핵심 최적화 기법입니다.
