느리고 큰 저장장치를 어떻게 하면 빠르고 안정적으로 쓸 수 있을까?
전통 디스크에서는 헤드 이동 최소화가, 현대 SSD/클라우드에서는 IOPS·중복·연결 방식이 답이 된다.
1. 디스크 구조 (HDD)
전통적인 하드디스크(HDD)는 물리적으로 회전하는 기계 장치다
- 플래터: 데이터가 기록되는 자기 원판. 스핀들을 중심으로 회전한다.
- 트랙 : 플래터 표면의 동심원
- 섹터 : 트랙을 쪼갠 최소 저장 단위
- 실린더 : 여러 플래터의 같은 반지름 트랙을 세로로 묶은 것 (헤드를 안 움직이고 접근 가능한 범위)
- 헤드, 암 : 헤드가 암에 붙어 트랙 위를 오가며 읽고 쓴다.
접근 시간 = ① 탐색 + ② 회전 지연 + ③ 전송
| 요소 | 의미 | 특징 |
|---|---|---|
| ① 탐색 시간 | 헤드를 목표 트랙으로 이동 | 가장 큼 (지배적) |
| ② 회전 지연 | 목표 섹터가 헤드 밑에 올 때까지 회전 대기 | RPM에 좌우 |
| ③ 전송 시간 | 실제 데이터 읽기/쓰기 | 상대적으로 작음 |
탐색 시간이 압도적으로 크다 → 헤드 이동을 줄이는 것이 성능의 핵심
2. 디스크 스케줄링
여러 요청이 큐에 쌓였을 때, 어떤 순서로 트랙을 방문하느냐로 헤드 총 이동 거리가 크게 달라진다.
예시: 헤드 위치 53, 요청 큐 98, 183, 37, 122, 14, 124, 65, 67
| 알고리즘 | 동작 | 선점/특징 |
|---|---|---|
| FCFS | 요청 온 순서대로 | 공정하나 헤드가 크게 왕복 → 탐색 낭비 극심 |
| SSTF | 현재 헤드에서 가장 가까운 요청부터 | 탐색 최소화하나 기아(SJF의 디스크판) |
| SCAN | 한 방향으로 끝까지 훑고 반대로 회귀 (엘리베이터) | 기아 없음, 규칙적 |
| C-SCAN | 끝까지 간 뒤 처리 없이 반대 끝으로 점프해 같은 방향만 반복 | 대기 시간 균일 |
| LOOK / C-LOOK | SCAN/C-SCAN에서 물리적 끝이 아니라 마지막 요청까지만 이동 | 쓸데없는 끝 이동 생략, 실무에서 많이 씀 |
- FCFS :
53→98→183→37→…(총 이동 640) — 왔다갔다 낭비 - SSTF :
53→65→67→37→14→98→…(총 236) — 가깝게, 대신 멀리 있는 요청 기아 위험 - SCAN :
53→65→67→98→122→124→183→(끝)→37→14— 한 방향 훑고 회귀
3. NVM / SSD
- SSD는 전자적으로 작동하여 플래터도 헤드도 없다.
- 탐색 시간·회전 지연이 없으므로, 위치와 무관하게 접근 시간이 균일함
- 따라서 전통 디스크 스케줄링이 사실상 무의미하다.
- NVM : 비휘발성 메모리 라는 뜻으로, 플래시 기반 저장장치 (SSD/NVMe 등)
대신 SSD 고유의 특성을 고려하여 다른 방식으로 최적화 한다 (NVM 스케줄링)
- 재정렬 없이 그냥 순서대로 처리하는 FIFO가 최선일 때가 많음 (리눅스의 none/noop 스케줄러)
- 다중 큐로 병렬성을 최대한 살린다. 큐를 수만 개 지원하여 CPU 코어마다 자기 큐를 갖고 락 경쟁 없이 명령을 쏟아부을 수 있다.
- 읽기/쓰기 공정성을 관리한다. 쓰기가 훨씬 느리므로, 읽기를 쓰기보다 우선하거나 읽기/쓰기 큐를 분리해서 지연을 관리한다.
- 셀 수명이 유한하므로 골고루 쓰도록 함 (웨어 레벨링, 가비지 컬렉션, OS가 안 쓰는 블록을 알리는 TRIM)
4. RAID
여러 디스크로 신뢰성·성능을 얻는다
여러 물리 디스크를 하나의 논리 디스크로 묶어서 중복(신뢰성)과 병렬 접근을 얻는다.
스트라이핑 (성능), 미러링 (복제 중복), 패리티 (계산 복구) 세 가지를 조합하여 구현한다.
| 레벨 | 방식 | 특징 |
|---|---|---|
| RAID 0 | 스트라이핑 (분산 저장) | 빠름, 중복 없음 → 1개 고장 시 전손실 |
| RAID 1 | 미러링 (복제) | 1개 고장 견딤, 용량 절반 |
| RAID 5 | 스트라이핑 + 분산 패리티 | 1개 고장 복구, 균형형 (≥3개), 쓰기 시 패리티 계산 비용 |
| RAID 6 | 이중 패리티 | 2개 고장까지 견딤 |
| RAID 10 | 미러링 후 스트라이핑 | 성능·신뢰성 모두 우수, 용량 절반, DB에 자주 |
⚠️ RAID ≠ 백업
RAID는 디스크 하드웨어 고장을 견디는 것이지, 실수 삭제·데이터 오염은 미러/패리티에도 반영되어 못 살린다. 백업은 별도로 필요하다.
💡 실제 백엔드 서버(EC2)가 쓰는 디스크
서버의 디스크
- EBS : EC2의 주력 디스크로, 실제로는 네트워크 연결 블록 스토리지인데 OS엔 로컬 디스크처럼 보인다. 인스턴스를 껐다 켜도 유지되고, 스냅샷/리사이즈/재연결이 가능하다.
- 인스턴스 스토어 : 내장 임시디스크로, 로컬 NVMe SSD를 사용하여 아주 빠르지만 인스턴스 정지 시 데이터가 소실되어 캐시·스크래치용으로 사용한다.
관리 서비스
- S3 : 거대한 파일 창고 (백업·정적 자산 저장용) 역할을 한다. 서버에서 API로 접근함
- DB는 보통 RDS/Aurora를 사용한다.
- RDS : AWS가 DB를 대신 설치하고 관리 (백업·패치·복구 등) 해줌. EC2 + EBS 위에서 돌아간다
- Aurora : RDS의 고성능 진화 버전. 저장소를 따로 떼어내 여러 데이터센터에 6벌씩 복제하고, 데이터를 통째로 쓰는 대신 변경 기록 로그만 보내는 방식이라 더 빠르고 튼튼하다.
