Search for a command to run...
No comments yet. Be the first to comment.
Software Testing Course Review 이번 강의는 새로운 소프트웨어 테스트(Software Testing) 내용을 배우는 시간이 아니라, 한 학기 동안 학습한 핵심 내용을 키워드 중심으로 정리하고 점검하는 시간이다. 지난 시간에는 AI 소프트웨어 테스트(AI Software Testing)의 정의와 필요성을 살펴보았다. 특히 일반 소프트웨
Introduction to Virtualization and Unix Installation (가상화와 Unix 설치 개요) 이번 시간에는 운영체제(Operating System) 수업의 실습 준비 과정으로 가상화(Virtualization)의 개념을 간단히 살펴보고, Unix(유닉스)를 설치하는 과정을 다룬다. 앞으로 실습에서는 실제 컴퓨터에 직접 운영
Server Hardware and Its Characteristics (서버 하드웨어와 특징) 서버(Server)는 일반 개인용 컴퓨터(Personal Computer)보다 훨씬 높은 성능과 안정성을 요구하는 컴퓨터 시스템이다. 개인용 컴퓨터는 주로 한 명의 사용자가 개인적인 작업을 하기 위해 사용하는 반면, 서버는 여러 사용자가 동시에 접속하여 서비스를
파일 시스템(File System)이 필요한 이유 첫 번째 질문이 있다. 컴퓨터에 파일을 저장하는 상황을 떠올려보자. 과제 파일, 사진, 동영상처럼 다양한 파일을 계속 저장하다 보면 파일의 수가 많아질수록 어떤 문제가 발생할까? 파일의 수가 많아지면 필요한 파일을 찾는 데 오랜 시간이 걸릴 수 있다. 또한 파일이 어디에 저장되어 있는지 헷갈릴 수도 있다
이번 주차에서는 저장장치 관리(Storage Device Management)에 대해 학습한다. 프로그램 실행 과정에서 생성된 데이터는 전원이 꺼져도 유지되어야 하므로 보조기억장치(Secondary Storage)에 저장된다.
운영체제(Operating System)는 이러한 데이터를 디스크(Disk) 구조에 맞게 효율적으로 저장하고, 필요할 때 빠르게 접근할 수 있도록 관리한다.
이번 시간에는 디스크의 구조(Disk Structure), 데이터 접근 방식(Data Access Method), 저장장치 관리의 전체 흐름을 중심으로 살펴본다.
이번 주차의 학습 목표는 다음과 같다. 먼저 디스크의 구조와 접근 시간(Access Time)의 구성 요소를 설명할 수 있어야 한다. 또한 디스크 접근 비용(Disk Access Cost)을 줄이기 위한 기법을 이해하고, RAID와 같은 저장 방식(Storage Method)의 특징도 설명할 수 있어야 한다.
마지막으로 실습을 통해 디스크 접근 특성(Disk Access Characteristics)과 성능 차이(Performance Difference)를 분석하는 것이 이번 주차의 핵심이다.
개념 로딩(Concept Loading)을 통해 저장장치 관리(Storage Device Management)의 필요성을 생각해보자.
첫 번째 질문이 있다. 컴퓨터에서 파일을 복사하거나 프로그램을 실행할 때를 떠올려보자. 데이터의 크기가 비슷한데도 어떤 경우는 빠르게 처리되고, 어떤 경우는 유독 느리게 느껴지는 경험이 있다. 그렇다면 데이터의 크기가 비슷한데도 속도가 달라지는 이유는 무엇일까?
디스크(Disk)는 데이터를 어디에 저장하고, 어떤 순서로 접근하느냐에 따라 성능 차이가 발생한다. 즉, 단순히 데이터를 저장하는 것만으로는 충분하지 않고, 효율적인 접근(Efficient Access)을 위한 관리 방식이 필요하다.
그래서 운영체제(Operating System)는 저장장치 관리(Storage Device Management)를 통해 디스크 접근(Disk Access)을 최적화하고, 전체 시스템 성능(System Performance)을 향상시킨다.
두 번째 질문이 있다. 여러 프로그램(Program)이 동시에 디스크에 접근 요청을 보내는 상황을 생각해보자. 이때 요청이 들어온 순서대로 처리하는 것이 항상 효율적일까? 아니면 처리 순서에 따라 성능이 달라질까?
만약 비효율적인 순서로 요청을 처리하면 디스크의 이동이 많아지고, 전체 처리 시간(Total Processing Time)이 증가할 수 있다. 이처럼 디스크에서는 요청을 어떤 순서로 처리하느냐에 따라 성능 차이가 발생한다.
따라서 운영체제는 디스크 스케줄링(Disk Scheduling)을 통해 요청 처리 순서(Request Processing Order)를 조정하고, 더 효율적인 디스크 접근이 이루어지도록 관리한다. 이번 시간에는 이러한 저장장치 관리의 필요성과 디스크 접근 최적화 과정을 중심으로 살펴본다.
디스크 스케줄링(Disk Scheduling)은 특히 하드 디스크(HDD, Hard Disk Drive)에서 중요하다. HDD는 데이터를 읽기 위해 디스크 헤드(Disk Head)가 이동해야 하므로, 요청 처리 순서에 따라 탐색 시간(Seek Time)이 크게 달라질 수 있다.
반면 SSD(Solid State Drive)는 물리적인 디스크 헤드가 없기 때문에 HDD보다 탐색 시간의 영향은 작지만, 운영체제는 여전히 입출력 요청(I/O Request)을 효율적으로 관리해야 한다.
저장장치(Storage Device)의 동작을 이해하기 위해 먼저 디스크(Disk)의 기본 구조와 데이터가 저장되는 물리적인 단위를 살펴본다.
디스크는 데이터를 일정한 물리적 단위(Physical Unit)로 저장하며, 운영체제(Operating System)는 이러한 구조를 바탕으로 데이터를 읽고 쓴다. 따라서 저장장치 관리를 이해하려면 디스크가 어떤 구조로 이루어져 있고, 데이터가 어떤 단위로 저장되는지 알아야 한다.
또한 디스크에 접근할 때는 단순히 데이터를 바로 읽는 것이 아니라, 여러 단계의 접근 과정이 발생한다. 대표적으로 디스크 헤드(Disk Head)가 원하는 위치로 이동하는 탐색 시간(Seek Time), 원하는 섹터(Sector)가 헤드 아래로 올 때까지 기다리는 회전 지연 시간(Rotational Latency), 실제 데이터를 읽거나 쓰는 전송 시간(Transfer Time)이 포함된다.
이번 내용에서는 디스크의 기본 구조와 데이터 저장 단위, 그리고 탐색 시간(Seek Time), 회전 지연(Rotational Latency), 전송 시간(Transfer Time)을 중심으로 디스크 접근 과정(Disk Access Process)을 살펴본다.
디스크 접근 시간(Disk Access Time)은 보통 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)을 합쳐서 이해한다. 특히 HDD(Hard Disk Drive)는 물리적으로 헤드가 움직이고 원판이 회전하기 때문에 이 요소들이 성능에 큰 영향을 준다.
디스크(Disk)는 여러 장의 플래터(Platter)로 이루어진 저장장치(Storage Device)이다. 플래터는 원형의 형태로 회전하면서 데이터를 저장한다.
각 플래터의 표면에는 동심원 형태의 트랙(Track)이 존재한다. 이 트랙은 다시 더 작은 단위인 섹터(Sector)로 나뉘며, 실제 데이터는 섹터 단위로 저장된다.
또한 여러 플래터에서 같은 위치에 있는 트랙들을 모으면 실린더(Cylinder)를 구성한다. 디스크는 이러한 플래터, 트랙, 섹터, 실린더 구조를 기반으로 데이터를 읽고 쓴다.
하지만 운영체제(Operating System)는 이러한 물리적 구조를 그대로 직접 사용하지 않는다. 대신 논리 블록(Logical Block) 단위를 기준으로 데이터를 관리한다.
즉, 디스크의 물리적인 구조 위에 논리적인 관리 단위를 두어 데이터를 효율적으로 저장하고 접근할 수 있도록 구성되어 있다고 이해할 수 있다.
섹터(Sector)는 디스크에서 실제 데이터가 저장되는 물리적 단위이고, 블록(Block)은 파일 시스템(File System)이 데이터를 관리하는 논리적 단위이다.
즉, 운영체제는 사용자가 복잡한 플래터(Platter), 트랙(Track), 섹터(Sector) 구조를 직접 신경 쓰지 않아도 되도록 블록 단위로 추상화(Abstraction)해서 관리한다.
그림은 디스크(Disk)의 물리 구조와 함께 고정 헤드 디스크(Fixed-Head Disk)와 이동 헤드 디스크(Movable-Head Disk)의 차이를 보여준다.
먼저 오른쪽의 이동 헤드 디스크(Movable-Head Disk)를 보면, 여러 장으로 겹쳐 있는 원판이 플래터(Platter)이다. 플래터는 실제 데이터가 저장되는 원판으로, 디스크의 저장 공간을 이루는 핵심 요소이다.
각 플래터 표면에는 동심원 형태의 트랙(Track)이 존재한다. 트랙은 데이터가 저장되는 원형 경로이며, 각 트랙은 다시 더 작은 단위인 섹터(Sector)로 나뉜다. 섹터는 실제 데이터가 기록되는 물리적인 저장 구역이다.
또한 여러 플래터에서 같은 반지름 위치에 있는 트랙들을 세로로 묶으면 실린더(Cylinder)가 된다. 실린더는 헤드(Head)가 같은 위치에 고정된 상태에서 접근할 수 있는 트랙들의 집합이라고 볼 수 있다.
플래터 옆으로 길게 뻗어 있는 구조는 암(Arm)이다. 암은 읽기/쓰기 헤드(Read/Write Head)를 원하는 트랙 위치까지 이동시키는 역할을 한다. 암 끝에 붙어 있는 작은 장치가 바로 읽기/쓰기 헤드이며, 이 헤드가 플래터 표면의 데이터를 실제로 읽거나 기록한다.
암 바깥쪽의 구동 장치는 액추에이터(Actuator)로 볼 수 있다. 이 장치는 암을 안쪽이나 바깥쪽으로 움직여, 헤드가 원하는 트랙으로 이동할 수 있도록 한다.
중앙에 세로로 연결된 부분은 축(Spindle)이다. 축은 플래터를 회전시키는 역할을 하며, 디스크는 이 회전을 통해 원하는 섹터가 헤드 아래에 오도록 해서 데이터를 읽고 쓴다.
이제 왼쪽의 고정 헤드 디스크(Fixed-Head Disk)를 보면, 각 트랙마다 고정된 읽기/쓰기 헤드가 하나씩 배치되어 있다. 즉 트랙마다 전용 헤드가 따로 존재하기 때문에 헤드를 이동시키지 않고도 해당 트랙에 바로 접근할 수 있다. 그래서 접근 속도가 빠르다는 특징이 있다.
반면 이동 헤드 디스크(Movable-Head Disk)는 하나의 읽기/쓰기 헤드가 여러 트랙 사이를 이동하면서 접근하는 구조이다. 따라서 필요한 트랙으로 헤드를 옮기는 과정이 필요하고, 이로 인해 탐색 시간(Seek Time)이 발생한다. 이러한 헤드 이동 시간은 디스크 접근 시간(Access Time)에 영향을 준다.
정리하면, 고정 헤드 디스크는 각 트랙마다 헤드가 따로 있어 빠르게 접근할 수 있고, 이동 헤드 디스크는 하나의 헤드가 여러 트랙을 이동하면서 접근하기 때문에 구조는 비교적 단순하지만 접근 시간의 영향을 더 크게 받는다. 즉 이 그림은 디스크를 구성하는 요소들의 위치와 역할, 그리고 고정 헤드 방식과 이동 헤드 방식의 차이를 함께 보여주는 구조라고 할 수 있다.
이동 헤드 디스크(Movable-Head Disk)가 많이 사용되는 이유는 큰 저장 용량을 더 효율적이고 경제적으로 구현할 수 있기 때문이다. 고정 헤드 디스크(Fixed-Head Disk)는 각 트랙마다 별도의 헤드가 필요하기 때문에 트랙 수가 많아질수록 구조가 복잡해지고 비용이 증가한다. 반면 이동 헤드 디스크는 하나의 헤드가 여러 트랙을 이동하며 접근하므로 탐색 시간(Seek Time)은 발생하지만, 더 적은 장치로 많은 데이터를 저장할 수 있다.
실제 현대 하드디스크(HDD, Hard Disk Drive)는 대부분 이동 헤드 디스크(Movable-Head Disk) 구조를 사용한다. 고정 헤드 디스크(Fixed-Head Disk)는 개념 설명용으로 자주 등장하지만, 현재는 일반적으로 널리 사용되지는 않는다.
또한 SSD(Solid State Drive)는 플래터, 트랙, 섹터, 헤드 같은 기계적 구조가 없기 때문에 HDD와는 다른 방식으로 데이터에 접근한다.
디스크(Disk)의 물리 구조 위에서 데이터가 실제로 어떤 단위로 관리되는지 살펴보자.
디스크에서 데이터를 저장하는 가장 작은 물리적 단위는 섹터(Sector)이다. 하지만 운영체제(Operating System)는 일반적으로 이 섹터를 직접 하나씩 제어하지 않는다. 섹터 단위의 실제 읽기와 쓰기는 디스크 컨트롤러(Disk Controller)와 같은 하드웨어 계층에서 처리된다.
섹터 하나의 크기는 작기 때문에 운영체제가 이를 그대로 관리하면 비효율적일 수 있다. 그래서 운영체제는 여러 개의 섹터를 묶어 논리 블록(Logical Block) 단위로 관리한다.
즉, 파일(File)은 물리적인 섹터 단위가 아니라 논리적인 블록 단위로 디스크에 저장되고 접근된다. 이 과정에서 사용자가 보는 파일의 위치와 실제 디스크에 저장된 물리적 위치는 서로 다를 수 있다.
따라서 운영체제는 복잡한 물리적 저장 구조를 사용자에게 직접 노출하지 않고, 논리 블록 단위를 통해 더 효율적인 저장과 접근이 가능하도록 관리한다고 이해할 수 있다.
이 그림은 디스크(Disk)에서 데이터가 저장되는 물리적 구조를 보여준다.
오른쪽의 원형 그림을 보면 여러 개의 작은 구역으로 나뉘어 있는 부분이 보이는데, 각각의 구역이 섹터(Sector)이다. 섹터는 실제 데이터가 저장되는 가장 작은 물리적 단위이다.
이 섹터들은 원형의 경로를 따라 배열되어 있는데, 이 원형의 경로를 트랙(Track)이라고 한다. 즉 하나의 트랙은 여러 개의 섹터로 구성된다.
왼쪽 그림을 보면 여러 개의 플래터(Platter)가 쌓여 있는 구조를 확인할 수 있다. 이때 여러 플래터에서 같은 반지름 위치에 있는 트랙들을 세로로 연결해서 보면 이를 실린더(Cylinder)라고 한다.
즉 이 그림은 디스크에서 데이터가 트랙과 섹터 단위로 나뉘어 저장되고, 여러 플래터를 기준으로는 실린더 구조로 묶여 관리된다는 점을 보여준다.
운영체제(Operating System)는 이러한 물리적 구조를 직접 사용자에게 보여주지 않는다. 대신 여러 섹터를 묶은 논리 블록(Logical Block) 단위로 데이터를 관리한다.
즉, 물리적으로는 섹터(Sector)와 트랙(Track) 구조를 가지지만, 논리적으로는 블록(Block) 단위로 저장하고 접근한다고 이해하면 된다.
디스크(Disk)에서 데이터를 읽고 쓰는 과정은 메모리(Memory)처럼 주소를 바로 읽는 방식과 다르다. 디스크는 기계적인 동작(Mechanical Operation)이 함께 이루어지기 때문에 데이터 요청이 즉시 처리되지 않는다.
먼저 디스크 헤드(Disk Head)가 원하는 트랙(Track) 위치로 이동해야 한다. 그다음 플래터(Platter)가 회전하면서 필요한 섹터(Sector)가 헤드 아래로 도달해야 한다. 이후에야 실제 데이터의 읽기(Read), 쓰기(Write), 전송(Transfer)이 이루어진다.
따라서 디스크 접근 시간(Disk Access Time)은 하나의 요소로만 결정되지 않는다. 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)과 같은 여러 단계가 순차적으로 진행되면서 전체 접근 시간이 만들어진다.
각 단계에서 소요되는 시간이 누적되면 전체 디스크 성능(Disk Performance)과 입출력 성능(I/O Performance)에 영향을 준다. 결국 디스크 접근 시간은 저장장치 성능(Storage Device Performance)을 결정하는 중요한 요소라고 할 수 있다.
디스크 접근 시간(Disk Access Time)은 일반적으로 다음과 같이 이해할 수 있다.
Disk Access Time = Seek Time + Rotational Latency + Transfer Time
이 개념은 주로 하드 디스크(HDD, Hard Disk Drive)에 해당한다. SSD(Solid State Drive)는 기계적으로 움직이는 헤드나 회전하는 플래터가 없기 때문에 탐색 시간과 회전 지연의 영향이 거의 없다.
이 그림은 디스크 접근 시간(Disk Access Time)이 어떤 요소들로 구성되는지를 보여준다.
먼저 이동 헤드 디스크(Movable-Head Disk)에서는 읽기/쓰기 헤드(Read/Write Head)가 데이터가 저장된 트랙(Track) 위치까지 이동해야 한다. 이때 헤드가 원하는 트랙으로 이동하는 시간을 탐색 시간(Seek Time)이라고 한다.
그다음 헤드가 원하는 트랙에 도착하더라도, 필요한 데이터가 바로 헤드 아래에 있는 것은 아니다. 디스크가 회전하면서 원하는 섹터(Sector)가 헤드 아래로 올 때까지 기다려야 하는데, 이 시간을 회전 지연 시간(Rotational Latency)이라고 한다.
이후 원하는 섹터가 헤드 아래에 도착하면 실제로 데이터를 읽거나 쓰고, 그 데이터를 전송하는 과정이 이루어진다. 이때 소요되는 시간을 전송 시간(Transfer Time)이라고 한다.
즉, 디스크 접근 시간은 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)이 합쳐져서 결정된다.
이 세 가지 요소 중 어느 하나라도 길어지면 전체 디스크 성능(Disk Performance)과 입출력 성능(I/O Performance)에 영향을 주게 된다. 따라서 디스크 접근 시간은 저장장치 성능(Storage Device Performance)을 결정하는 중요한 요소라고 할 수 있다.
전송 시간(Transfer Time)은 단순히 기다리는 시간이 아니라, 원하는 섹터가 도착한 뒤 실제 데이터를 읽거나 쓰고 전달하는 데 걸리는 시간이다.
보통 디스크 접근 시간은 다음과 같이 정리한다.
Disk Access Time = Seek Time + Rotational Latency + Transfer Time
이 개념은 주로 HDD(Hard Disk Drive)에 해당하며, SSD(Solid State Drive)는 기계적인 헤드 이동과 회전이 없기 때문에 탐색 시간과 회전 지연의 영향이 거의 없다.
앞에서 디스크 접근 시간(Disk Access Time)을 구성하는 세 가지 요소를 살펴보았다. 이번에는 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)을 조금 더 자세히 정리해보자.
먼저 탐색 시간(Seek Time)은 디스크 헤드(Disk Head)가 현재 위치에서 요청된 데이터가 저장된 트랙(Track)까지 이동하는 데 걸리는 시간이다. 즉, 데이터를 읽거나 쓰기 전에 헤드가 먼저 원하는 위치로 이동해야 한다는 의미이다.
탐색 시간은 디스크 접근 시간 중 큰 비중을 차지하는 요소이다. 헤드가 이동해야 하는 거리가 멀수록 더 많은 시간이 필요하다. 따라서 데이터가 디스크의 어느 위치에 저장되어 있는지에 따라 전체 처리 속도와 성능 차이가 발생할 수 있다. 이후에 살펴볼 디스크 스케줄링(Disk Scheduling) 기법도 이러한 헤드 이동을 줄이는 방향으로 활용된다.
다음으로 회전 지연 시간(Rotational Latency)은 헤드가 원하는 트랙에 도착한 이후, 목표 섹터(Sector)가 헤드 아래에 올 때까지 기다리는 시간을 의미한다. 즉, 헤드가 올바른 트랙에 도착했더라도 필요한 데이터가 바로 아래에 없다면 디스크가 회전할 때까지 기다려야 한다.
디스크는 일정한 속도로 계속 회전하기 때문에 이 과정에서 추가적인 대기 시간이 발생한다. 평균적으로는 한 바퀴 회전 시간의 절반 정도가 회전 지연 시간으로 발생한다고 볼 수 있다. 따라서 같은 트랙 안에 데이터가 있더라도 섹터의 위치에 따라 실제 접근 시간은 달라질 수 있다.
마지막으로 전송 시간(Transfer Time)은 원하는 위치를 찾은 이후, 데이터를 실제로 읽거나 쓰고 메모리(Memory)로 전달하는 데 걸리는 시간이다. 탐색 시간과 회전 지연 시간이 데이터 접근을 위한 준비 과정이라면, 전송 시간은 실제 데이터 처리가 이루어지는 단계라고 볼 수 있다.
전송 시간은 디스크와 메모리 사이의 전송 속도(Transfer Rate)와 데이터 크기(Data Size)에 따라 달라진다. 전송해야 할 데이터의 양이 많을수록 더 많은 시간이 필요하고, 데이터가 적다면 전송 시간도 짧아진다. 다만 일반적으로 탐색 시간과 회전 지연 시간에 비해서는 상대적으로 짧은 편이다.
정리하면, 디스크 접근 시간은 탐색 시간, 회전 지연 시간, 전송 시간이 합쳐져 결정된다. 이 중 특히 탐색 시간과 회전 지연 시간은 HDD(Hard Disk Drive)의 기계적인 구조 때문에 발생하는 중요한 성능 요소이다.
평균 회전 지연 시간(Average Rotational Latency)은 보통 디스크가 한 바퀴 도는 시간의 절반으로 계산한다. 예를 들어 디스크가 한 바퀴 도는 데 10ms가 걸린다면, 평균 회전 지연 시간은 약 5ms로 볼 수 있다.
또한 이 개념은 주로 HDD(Hard Disk Drive)에 해당한다. SSD(Solid State Drive)는 회전하는 플래터(Platter)나 이동하는 헤드(Head)가 없기 때문에 탐색 시간과 회전 지연 시간이 거의 발생하지 않는다.
디스크 접근 시간(Disk Access Time)을 구성하는 세 가지 요소 중 일반적으로 탐색 시간(Seek Time)이 전체 접근 시간에서 큰 비중을 차지하는 경우가 많다.
가장 큰 이유는 디스크 헤드(Disk Head)가 원하는 트랙(Track)까지 실제로 물리적으로 이동해야 하기 때문이다. 즉, 단순한 전기적 신호 처리만으로 끝나는 것이 아니라 기계적인 움직임(Mechanical Movement)이 동반되기 때문에 시간이 더 많이 필요하다.
또한 헤드가 이동해야 하는 거리에 따라 소요 시간이 크게 달라진다. 가까운 트랙으로 이동할 때와 먼 트랙으로 이동할 때의 차이가 크기 때문에, 탐색 시간은 회전 지연 시간(Rotational Latency)보다 변동 폭이 크게 나타날 수 있다.
따라서 디스크 접근 시간에서 탐색 시간은 중요한 성능 요소로 다루어진다. 이후에 살펴볼 디스크 스케줄링(Disk Scheduling)도 이러한 헤드 이동 거리를 줄여 전체 접근 시간을 줄이는 방향으로 동작한다.
정리하면 디스크 접근 시간(Disk Access Time)은 탐색 시간(Seek Time), 회전 지연 시간(Rotational Latency), 전송 시간(Transfer Time)이 합쳐져서 결정된다. 일반적으로는 이 중 탐색 시간이 전체 성능에 가장 큰 영향을 주는 경우가 많다.
요청을 어떤 순서로 처리하느냐에 따라 디스크 헤드(Disk Head)의 이동 거리가 달라지고, 그에 따라 전체 접근 시간도 달라진다. 따라서 디스크 성능(Disk Performance)을 높이기 위해서는 요청 처리 순서(Request Processing Order)를 효율적으로 관리하는 것이 중요하다.
탐색 시간이 실제 성능에 얼마나 큰 영향을 주는지 수치로 계산해보자. 주어진 조건은 다음과 같다.
탐색 시간(Seek Time)은 50ms, 회전 지연 시간(Rotational Latency)은 16.8ms이다. 전송 시간(Transfer Time)은 바이트(Byte)당 0.00094ms이다.
예제에서는 1KB를 1024바이트(Byte)로 계산한다. 따라서 1KB 데이터를 전송하는 시간은 다음과 같다.
0.00094ms × 1024 = 0.96256ms
이 값을 이용해 디스크 종류에 따른 전체 접근 시간을 비교할 수 있다.
먼저 이동 헤드 디스크(Movable-Head Disk)는 헤드가 원하는 트랙으로 이동해야 하므로 탐색 시간, 회전 지연 시간, 전송 시간을 모두 더해야 한다.
50 + 16.8 + 0.96256 = 67.76256ms
따라서 이동 헤드 디스크의 전체 접근 시간은 약 67.76ms이다.
반면 고정 헤드 디스크(Fixed-Head Disk)는 각 트랙마다 헤드가 존재하므로 헤드 이동 과정이 필요하지 않다. 따라서 탐색 시간을 제외하고 회전 지연 시간과 전송 시간만 더하면 된다.
16.8 + 0.96256 = 17.76256ms
따라서 고정 헤드 디스크의 전체 접근 시간은 약 17.76ms이다.
결국 같은 조건이라도 디스크 구조(Disk Structure)에 따라 전체 접근 시간은 크게 달라질 수 있다. 특히 탐색 시간(Seek Time)이 전체 디스크 성능에 큰 영향을 준다는 점을 확인할 수 있다.
또한 고정 헤드 디스크(Fixed-Head Disk)는 탐색 시간이 거의 없다는 장점이 있지만, 각 트랙마다 헤드가 필요하므로 구조가 복잡하고 비용이 높다. 그래서 실제 현대 HDD(Hard Disk Drive)에서는 대부분 이동 헤드 디스크(Movable-Head Disk) 구조가 사용된다.
디스크 성능(Disk Performance)은 단순히 데이터 크기(Data Size)만으로 결정되지 않는다. 오히려 데이터를 처리하기 위해 디스크 헤드(Disk Head)가 얼마나 이동해야 하는지가 더 큰 영향을 주는 경우가 많다.
헤드의 이동 거리가 길어질수록 탐색 시간(Seek Time)이 증가하고, 그만큼 전체 디스크 접근 시간(Disk Access Time)도 함께 늘어난다.
또한 데이터가 디스크의 여러 위치에 분산되어 저장되어 있다면, 헤드는 여러 위치로 이동해야 한다. 이 경우 디스크 접근이 비효율적으로 이루어져 성능이 낮아질 수 있다.
요청이 처리되는 순서(Request Processing Order)도 중요하다. 같은 요청들이 들어오더라도 어떤 순서로 처리하느냐에 따라 헤드의 전체 이동 경로가 크게 달라질 수 있다.
즉, 디스크 성능은 데이터의 크기보다 헤드 이동 거리(Head Movement Distance), 데이터 배치(Data Placement), 요청 처리 순서(Request Processing Order)에 더 큰 영향을 받을 수 있다고 이해할 수 있다.
이 내용은 이후에 살펴볼 디스크 스케줄링(Disk Scheduling)과 연결된다. 디스크 스케줄링은 여러 디스크 요청의 처리 순서를 조정하여 헤드 이동 거리를 줄이고, 전체 접근 시간을 줄이기 위한 기법이다.
디스크 접근 순서(Disk Access Order)에 따라 성능이 어떻게 달라지는지 살펴보자.
디스크에 들어오는 요청 집합(Request Set)이 같더라도, 어떤 순서로 처리하느냐에 따라 전체 성능은 달라질 수 있다. 그 이유는 요청 처리 순서(Request Processing Order)에 따라 디스크 헤드(Disk Head)가 이동하는 경로와 총 이동 거리가 달라지기 때문이다.
만약 요청을 비효율적인 순서로 처리하면 헤드의 이동 거리가 길어지고, 그만큼 탐색 시간(Seek Time)이 증가한다. 탐색 시간이 증가하면 전체 디스크 접근 시간(Disk Access Time)도 함께 늘어나게 된다.
반대로 불필요한 헤드 이동을 줄이는 순서로 요청을 처리하면 더 짧은 시간 안에 더 많은 요청을 처리할 수 있다. 즉, 효율적인 요청 처리 순서를 결정하는 것이 디스크 성능(Disk Performance)을 높이는 데 중요하다.
정리하면, 디스크 성능은 요청의 개수만으로 결정되는 것이 아니라 요청을 어떤 순서로 처리하는지에 따라 크게 달라질 수 있다. 비효율적인 처리 순서는 성능 저하로 이어지고, 효율적인 처리 순서를 결정하는 방식이 바로 디스크 스케줄링(Disk Scheduling)의 핵심이다.
디스크 스케줄링(Disk Scheduling)은 여러 디스크 입출력 요청(I/O Request)의 처리 순서를 조정하여 헤드 이동 거리(Head Movement Distance)를 줄이는 기법이다.
대표적인 방식으로는 FCFS(First-Come, First-Served), SSTF(Shortest Seek Time First), SCAN, C-SCAN 등이 있다. 이 방식들은 이후에 디스크 요청을 어떤 기준으로 처리할지 비교할 때 중요하게 다루어진다.
이러한 접근 특성(Access Characteristics)은 모든 저장장치(Storage Device)에서 동일하게 나타나는 것은 아니다. 저장장치의 종류가 달라지면 데이터에 접근하는 방식과 성능 특성(Performance Characteristics)도 달라진다.
대표적으로 SSD(Solid State Drive)와 HDD(Hard Disk Drive)를 비교하면 그 차이를 쉽게 확인할 수 있다.
먼저 SSD는 기계적으로 움직이는 헤드(Head)나 플래터(Platter)가 없다. 따라서 탐색 시간(Seek Time)과 회전 지연 시간(Rotational Latency)이 거의 발생하지 않으며, 빠른 접근 속도(Access Speed)를 제공한다.
또한 SSD는 데이터의 위치에 따른 성능 차이가 HDD보다 작다. 하지만 내부 병렬 구조(Internal Parallelism), 컨트롤러(Controller), 플래시 메모리(Flash Memory) 관리 방식에 따라 성능 차이가 발생할 수 있다.
반면 HDD는 헤드 이동(Head Movement)과 디스크 회전(Disk Rotation)이 필요한 구조이다. 따라서 데이터가 어디에 저장되어 있는지에 따라 접근 시간이 크게 달라질 수 있다. 가까운 위치의 데이터는 빠르게 접근할 수 있지만, 멀리 떨어진 데이터에 접근하려면 더 많은 시간이 필요하다.
다만 SSD도 모든 접근에서 성능 차이가 완전히 사라지는 것은 아니다. SSD는 헤드 이동은 없지만, 연속된 데이터를 처리하는 순차 접근(Sequential Access)과 여러 위치에 분산된 데이터를 처리하는 랜덤 접근(Random Access) 사이에서 성능 차이가 발생할 수 있다. 이는 SSD 내부 컨트롤러의 동작 방식과 데이터 관리 방식의 영향을 받기 때문이다.
즉, 저장장치의 종류에 따라 데이터 접근 방식과 성능 구조가 다르다. 지금까지는 저장장치의 구조, 데이터 접근 방식, 그리고 디스크 성능에 영향을 주는 요소들을 살펴보았다.
HDD에서는 탐색 시간(Seek Time)과 회전 지연 시간(Rotational Latency)이 성능에 큰 영향을 준다. 반면 SSD는 기계적인 이동이 없기 때문에 이러한 요소의 영향은 거의 없고, 대신 컨트롤러(Controller), 캐시(Cache), 플래시 메모리 구조(Flash Memory Structure), 쓰기 방식(Write Operation) 등이 성능에 영향을 줄 수 있다.
따라서 디스크 스케줄링(Disk Scheduling)은 HDD에서 특히 중요하며, SSD에서는 HDD와 같은 헤드 이동 최적화보다 내부 병렬 처리, 쓰기 최적화, 수명 관리 같은 요소가 더 중요해진다.
이번에는 디스크 요청 처리 순서를 결정하는 디스크 스케줄링(Disk Scheduling)과 여러 디스크를 활용해 성능과 안정성을 높이는 RAID(Redundant Array of Independent Disks)에 대해 살펴본다.
앞 차시에서 살펴본 것처럼, 헤드 이동(Head Movement)과 회전 동작(Rotation)이 필요한 디스크에서는 요청 처리 방식에 따라 성능 차이가 크게 나타날 수 있다. 디스크 성능(Disk Performance)을 높이기 위해서는 전체 접근 시간(Disk Access Time)을 줄이는 것이 중요하다.
이때 중요한 기준이 되는 것이 요청을 어떤 순서로 처리할 것인가이다. 요청 순서를 효율적으로 조정하면 디스크 헤드(Disk Head)의 이동 거리를 줄일 수 있고, 그 결과 전체 접근 시간도 감소시킬 수 있다.
운영체제(Operating System)는 이러한 디스크 요청(Disk Request)을 효율적으로 관리하기 위해 여러 가지 디스크 스케줄링 기법(Disk Scheduling Algorithm)을 사용한다.
즉, 디스크 접근 순서(Disk Access Order)를 최적화하는 것은 저장장치 성능뿐만 아니라 전체 시스템 성능(System Performance)을 향상시키는 중요한 요소라고 할 수 있다.
디스크 스케줄링(Disk Scheduling)은 특히 HDD(Hard Disk Drive)에서 중요하다. HDD는 물리적으로 헤드가 이동하기 때문에 요청 순서에 따라 탐색 시간(Seek Time)이 크게 달라질 수 있다.
RAID(Redundant Array of Independent Disks)는 여러 개의 디스크를 하나처럼 묶어 사용하는 방식이다. 목적에 따라 데이터 접근 속도를 높이거나, 일부 디스크가 고장 나도 데이터를 복구할 수 있도록 안정성(Reliability)을 높이는 데 사용된다.
디스크 스케줄링(Disk Scheduling)은 디스크 요청(Disk Request)의 처리 순서를 결정하는 기법이다.
디스크 요청은 여러 프로그램(Program)이나 프로세스(Process)로부터 발생하며, 일반적으로 큐(Queue) 형태로 순차적으로 도착한다. 하지만 요청이 들어온 순서대로 처리하는 것이 항상 가장 효율적인 것은 아니다.
같은 요청 집합(Request Set)이라도 어떤 순서로 처리하느냐에 따라 디스크 성능(Disk Performance)이 달라질 수 있다. 그 이유는 처리 순서에 따라 디스크 헤드(Disk Head)의 이동 경로와 총 이동 거리(Total Head Movement)가 달라지기 때문이다.
요청 처리 순서(Request Processing Order)를 적절히 조정하면 불필요한 헤드 이동을 줄일 수 있고, 그 결과 디스크 접근 시간(Disk Access Time)을 감소시킬 수 있다.
이처럼 디스크 요청의 처리 순서를 결정하는 기법을 디스크 스케줄링(Disk Scheduling)이라고 한다. 이를 위해 여러 가지 스케줄링 알고리즘(Scheduling Algorithm)이 사용되며, 각 알고리즘은 서로 다른 성능 특성(Performance Characteristics)을 가진다.
디스크 스케줄링(Disk Scheduling)의 핵심 목표는 디스크 헤드의 이동 거리를 줄여 탐색 시간(Seek Time)을 줄이는 것이다.
대표적인 디스크 스케줄링 알고리즘에는 FCFS(First-Come, First-Served), SSTF(Shortest Seek Time First), SCAN, C-SCAN 등이 있다.
디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)은 디스크 요청(Disk Request)을 어떤 순서로 처리할 것인지 결정하는 방식이다. 요청 처리 순서에 따라 디스크 헤드(Disk Head)의 이동 거리와 접근 시간(Access Time)이 달라지기 때문에, 알고리즘에 따라 성능 차이가 발생한다.
대표적인 방식으로는 먼저 들어온 요청을 먼저 처리하는 FCFS(First-Come, First-Served)가 있다. 이 방식은 구조가 단순하지만, 요청 순서에 따라 헤드 이동 거리가 길어질 수 있다.
SSTF(Shortest Seek Time First)는 현재 헤드 위치에서 가장 가까운 요청을 우선 처리하는 방식이다. 헤드 이동 거리를 줄일 수 있지만, 멀리 있는 요청이 오래 기다릴 수 있다는 특징이 있다.
SCAN은 헤드가 한 방향으로 이동하면서 지나가는 요청을 처리하고, 끝까지 이동한 뒤 반대 방향으로 다시 요청을 처리하는 방식이다. 엘리베이터가 한 방향으로 이동하면서 층을 처리하는 방식과 비슷하게 이해할 수 있다.
C-SCAN(Circular SCAN)은 헤드가 한 방향으로만 요청을 처리하고, 끝까지 이동한 뒤 다시 처음 방향으로 돌아와 같은 방식으로 처리하는 알고리즘이다. 요청 처리의 균형을 맞추는 데 유리하다.
LOOK과 C-LOOK은 SCAN, C-SCAN과 비슷하지만 디스크의 끝까지 무조건 이동하지 않고, 실제 요청이 존재하는 구간까지만 이동한다. 따라서 불필요한 헤드 이동을 줄일 수 있다.
정리하면, 각 디스크 스케줄링 알고리즘은 헤드 이동 방식이 서로 다르며, 그에 따라 접근 시간과 성능 특성도 달라진다. 이후에는 각 알고리즘의 동작 방식과 장단점을 하나씩 살펴본다.
FCFS는 가장 단순하지만 성능 최적화가 부족할 수 있고, SSTF는 가까운 요청을 우선 처리해 평균 탐색 시간을 줄일 수 있지만 기아 현상(Starvation)이 발생할 수 있다.
SCAN, C-SCAN, LOOK, C-LOOK은 헤드 이동 방향을 기준으로 요청을 처리하여 전체적인 헤드 이동을 줄이기 위한 방식이다. 특히 LOOK과 C-LOOK은 실제 요청이 있는 범위까지만 이동하므로 SCAN 계열보다 불필요한 이동을 줄일 수 있다.
스케줄링 알고리즘(Scheduling Algorithm)을 살펴보기 전에, 같은 조건에서 비교하기 위한 예제를 먼저 확인한다.
표에 제시된 값들은 디스크(Disk)에 순서대로 들어온 요청들의 트랙 번호(Track Number)를 의미한다. 즉 15번 트랙 요청이 먼저 들어오고, 그다음 8, 17, 11, 3, 23, 19, 14, 20 순서로 요청이 도착한 상황이라고 가정한다.
이후에는 이 동일한 요청 집합(Request Set)을 가지고 각 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)이 어떤 순서로 요청을 처리하는지 비교한다.
중요한 점은 요청 데이터 자체는 같지만, 처리 순서(Request Processing Order)가 달라지면 디스크 헤드(Disk Head)의 이동 거리와 전체 접근 시간(Disk Access Time)이 달라질 수 있다는 것이다.
따라서 이 표는 각 알고리즘의 성능 차이(Performance Difference)를 비교하기 위한 기준 자료라고 할 수 있다.
디스크 스케줄링 알고리즘을 비교할 때는 보통 초기 헤드 위치(Initial Head Position)와 요청 트랙 순서(Request Track Sequence)가 함께 필요하다.
요청 순서가 같더라도 초기 헤드 위치가 달라지면 총 헤드 이동 거리(Total Head Movement)가 달라질 수 있기 때문이다.
FCFS(First-Come, First-Served) 스케줄링은 먼저 도착한 디스크 요청(Disk Request)을 먼저 처리하는 가장 단순한 방식이다. 큐(Queue)에 들어온 순서를 그대로 유지하기 때문에 구현이 쉽고, 요청이 들어온 순서대로 처리된다는 점에서 공정성(Fairness)이 높다는 장점이 있다.
하지만 FCFS는 요청이 위치한 트랙(Track)의 위치를 고려하지 않는다. 따라서 처리 순서에 따라 디스크 헤드(Disk Head)의 이동 경로가 비효율적으로 길어질 수 있다. 특히 멀리 떨어진 요청이 앞에 있으면, 뒤에 있는 요청들이 오래 기다리는 문제가 발생할 수 있다.
예를 들어 요청 순서가 15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20이라고 하자. FCFS는 도착한 순서를 그대로 처리하므로 헤드는 이 순서대로 이동한다.
15에서 8로 이동하면 7만큼 이동하고, 8에서 17로 이동하면 9만큼 이동한다. 이후 17에서 11은 6, 11에서 3은 8, 3에서 23은 20, 23에서 19는 4, 19에서 14는 5, 14에서 20은 6만큼 이동한다.
이를 모두 더하면 총 헤드 이동 거리(Total Head Movement)는 다음과 같다.
7 + 9 + 6 + 8 + 20 + 4 + 5 + 6 = 65
즉, FCFS는 요청 순서를 그대로 따르기 때문에 헤드가 좌우로 여러 번 이동할 수 있다. 이로 인해 불필요한 이동 거리가 증가하고, 전체 접근 시간(Disk Access Time)이 길어질 수 있다.
정리하면 FCFS는 구조가 단순하고 공정하지만, 디스크 헤드의 이동 거리를 줄이는 데에는 효율적이지 않을 수 있는 방식이다.
이 계산에서는 주어진 요청들 사이의 이동 거리만 더한 것이다. 만약 초기 헤드 위치(Initial Head Position)가 따로 주어진다면, 초기 위치에서 첫 번째 요청인 15번 트랙까지 이동하는 거리도 함께 계산해야 한다.
SSTF(Shortest Seek Time First) 스케줄링은 현재 디스크 헤드(Disk Head) 위치를 기준으로 가장 가까운 요청을 먼저 처리하는 방식이다. 즉, 매 단계마다 이동 거리가 가장 짧은 요청을 선택하여 탐색 시간(Seek Time)을 줄이도록 동작한다.
이 방식은 FCFS(First-Come, First-Served)보다 평균 탐색 시간(Average Seek Time)을 줄일 수 있어 처리 효율이 향상된다는 장점이 있다. 하지만 가까운 요청만 계속 선택하게 되면, 멀리 있는 요청은 오랫동안 처리되지 못할 수 있다. 이처럼 특정 요청이 계속 지연되는 문제를 기아 현상(Starvation)이라고 한다.
그림은 SSTF 방식으로 요청을 처리할 때 헤드가 실제로 이동하는 경로를 보여준다. 현재 헤드 위치가 15라고 하면, 가장 가까운 요청을 우선 선택한다.
15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20 트랙번호이지만 가까운 위치를 계속 선택하기 때문에
15 → 14 → 17 → 19 → 20 → 23 → 11 → 8 → 3 로 이동 된 것이다.
먼저 15에서 14로 이동하면 1만큼 이동한다. 그다음 14에서 17로 3만큼, 17에서 19로 2만큼, 19에서 20으로 1만큼 이동한다. 이후 20에서 23으로 3만큼 이동한다.
그다음 남아 있는 요청 중 가장 가까운 위치를 계속 선택하여 11, 8, 3 순서로 처리한다. 이때 23에서 11은 12, 11에서 8은 3, 8에서 3은 5만큼 이동한다.
따라서 총 헤드 이동 거리(Total Head Movement)는 다음과 같다.
1 + 3 + 2 + 1 + 3 + 12 + 3 + 5 = 30
즉, SSTF는 가까운 요청을 우선 처리하기 때문에 헤드가 좌우로 크게 왕복하는 이동을 줄일 수 있다. 그 결과 총 이동 거리가 30으로 계산되며, 앞서 살펴본 FCFS의 65보다 훨씬 효율적인 결과를 보인다.
정리하면 SSTF는 평균 탐색 시간을 줄이는 데 효과적이지만, 멀리 떨어진 요청이 계속 밀릴 수 있다는 점을 함께 고려해야 하는 방식이다.
SSTF(Shortest Seek Time First)는 현재 위치에서 가장 가까운 요청을 선택하기 때문에 평균 성능은 좋아질 수 있다. 하지만 항상 전체 최적의 이동 경로를 보장하는 것은 아니다.
또한 가까운 요청이 계속 새로 들어오면 먼 위치의 요청은 계속 뒤로 밀릴 수 있으므로, 기아 현상(Starvation)이 발생할 가능성이 있다는 점이 중요하다.
SCAN 스케줄링(SCAN Scheduling)은 디스크 헤드(Disk Head)가 한 방향으로 이동하면서 이동 경로에 있는 요청들을 순차적으로 처리하는 방식이다. 한쪽 끝까지 이동한 뒤에는 방향을 반대로 바꾸어 다시 요청을 처리한다.
이 방식은 엘리베이터가 위아래로 이동하면서 지나가는 층의 요청을 처리하는 방식과 비슷하기 때문에 엘리베이터 알고리즘(Elevator Algorithm)이라고도 불린다.
SCAN은 헤드 이동 경로가 비교적 일정하기 때문에 예측 가능성(Predictability)이 높고, 안정적인 처리가 가능하다. 또한 SSTF(Shortest Seek Time First)처럼 가까운 요청만 계속 선택하는 방식이 아니기 때문에 특정 요청이 계속 밀리는 기아 현상(Starvation)이 발생할 가능성이 상대적으로 낮다.
15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20 트랙 번호
15 → 14 → 11 → 8 → 3 → 0 → 17 → 19 → 20 → 23 SCAN 스케줄링의 이동순서
그림에서는 현재 헤드가 15번 트랙에서 시작해 한쪽 방향으로 이동한다. 먼저 14번 트랙을 처리하고, 이어서 11, 8, 3 순서로 요청을 처리한다. 이후 디스크의 끝 방향인 0번 위치까지 이동한 뒤 방향을 바꾸어 반대쪽으로 이동한다.
반대 방향으로 이동하면서 17, 19, 20, 23 순서로 요청을 처리한다. 즉, 중간에 방향을 바꾸지 않고 한 방향으로 끝까지 이동한 뒤 다시 돌아오면서 요청을 처리하는 방식이다.
이 예제에서 총 헤드 이동 거리(Total Head Movement)는 약 38로 계산된다. 따라서 SCAN은 FCFS(First-Come, First-Served)보다 더 효율적이며, 동시에 공정성(Fairness)도 함께 고려한 방식이라고 할 수 있다.
SCAN은 한 방향으로 이동하면서 요청을 처리하기 때문에 헤드 이동이 비교적 규칙적이다. 그래서 FCFS보다 불필요한 왕복 이동을 줄일 수 있고, SSTF보다 특정 요청이 오래 밀릴 가능성도 낮다.
다만 계산에서 디스크의 끝을 어디까지 포함하느냐에 따라 총 이동 거리가 달라질 수 있다. 요청이 있는 마지막 트랙인 23까지만 계산하면 15 → 0 → 23이므로 총 이동 거리는 38이다. 만약 실제 디스크 끝인 24까지 이동한다고 계산하면 총 이동 거리는 39가 된다.
C-SCAN(Circular SCAN) 스케줄링은 디스크 헤드(Disk Head)가 한 방향으로만 이동하면서 경로상에 있는 요청들을 순차적으로 처리하는 방식이다.
SCAN과 마찬가지로 이동 중에 만나는 요청을 처리하지만, 끝 지점에 도달했을 때 반대 방향으로 요청을 처리하지 않는다. 대신 처음 위치로 다시 이동한 뒤, 다시 같은 방향으로 요청을 처리한다.
즉, C-SCAN은 디스크를 원형 구조처럼 보고 한 방향으로 순환하면서 요청을 처리하는 방식이라고 할 수 있다.
이 방식은 모든 요청이 비슷한 방식으로 서비스를 받기 때문에 대기 시간(Waiting Time)의 편차가 비교적 작다. 따라서 요청을 균등하게 처리할 수 있고, 특정 구간의 요청만 반복적으로 유리해지는 현상을 줄일 수 있다. 이런 점에서 공정성(Fairness)이 높은 스케줄링 방식이라고 볼 수 있다.
예제에서 현재 헤드가 15번 트랙에서 시작한다고 하자. C-SCAN은 한쪽 방향으로 먼저 이동하면서 14, 11, 8, 3 순서로 요청을 처리한다. 이후 디스크의 끝 방향인 0번 위치까지 이동한다.
그다음에는 반대 방향으로 요청을 처리하지 않고, 바로 반대쪽 끝인 24번 위치로 이동한다. 이후 다시 같은 방향으로 이동하면서 23, 20, 19, 17 순서로 요청을 처리한다.
즉, C-SCAN은 한 방향의 처리 흐름만 유지하고, 끝에 도달하면 시작 지점으로 순환해서 다시 같은 방향으로 처리하는 방식이다.
이 예제에서 총 헤드 이동 거리(Total Head Movement)는 46으로 계산된다. SCAN보다 이동 거리는 늘어날 수 있지만, 대기 시간의 편차를 줄이고 요청을 더 균등하게 처리할 수 있는 방식이라고 이해할 수 있다.
C-SCAN은 SCAN보다 공정한 대기 시간 분포를 제공하는 것이 목적이다. SCAN은 방향을 바꾼 뒤 바로 근처 요청을 다시 처리할 수 있기 때문에 특정 위치의 요청이 상대적으로 유리할 수 있다.
반면 C-SCAN은 한 방향으로만 서비스를 제공하므로, 요청들이 좀 더 일정한 주기로 처리된다. 다만 끝에서 반대쪽 끝으로 돌아가는 이동은 실제 요청을 처리하지 않는 이동이므로 총 헤드 이동 거리는 증가할 수 있다.
LOOK 스케줄링(LOOK Scheduling)은 기본 동작 방식이 SCAN스케줄링(SCAN Scheduling)과 유사하지만, 디스크의 끝까지 이동하지 않는 방식이다.
SCAN은 한 방향으로 이동하면서 요청을 처리한 뒤 디스크의 끝까지 이동했다. LOOK은 현재 이동 방향에 요청이 존재하는 마지막 위치까지만 이동한다. 그 지점에서 방향을 바꾸어 다시 반대 방향의 요청을 처리한다.
즉, 요청이 없는 구간까지 불필요하게 이동하지 않기 때문에 디스크 헤드(Disk Head)의 이동 거리를 줄일 수 있다. 그 결과 접근 시간(Access Time)이 개선되고, 전체 처리 효율도 높아질 수 있다.
LOOK 방식은 SCAN의 장점을 유지하면서 불필요한 이동을 줄인 개선형 방식이라고 할 수 있다. 이러한 이유로 실제 환경에서는 SCAN보다 더 효율적으로 사용될 수 있다.
15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20 트랙번호
15 → 14 → 11 → 8 → 3 → 17 → 19 → 20 → 23 LOOK스케줄링 이동순서
그림을 기준으로 보면, 헤드는 15번 트랙에서 시작해 한쪽 방향으로 이동한다. 이동 과정에서 14, 11, 8, 3 순서로 요청을 처리한다. SCAN과 달리 요청이 없는 0번 끝까지 이동하지 않고, 마지막 요청 위치인 3번에서 방향을 바꾼다.
이후 반대 방향으로 이동하면서 17, 19, 20, 23 순서로 요청을 처리한다. 즉, 요청이 존재하는 범위까지만 이동하고, 불필요한 끝 구간 이동은 생략하는 방식이다.
따라서 LOOK 알고리즘은 SCAN보다 헤드 이동 거리를 줄일 수 있으며, 요청 처리의 효율성을 높일 수 있는 방식이다.
또한 주어진 요청 집합을 기준으로 계산하면, LOOK의 이동 경로는 15 → 14 → 11 → 8 → 3 → 17 → 19 → 20 → 23이다. 이 경우 총 이동 거리는 다음과 같다.
1 + 3 + 3 + 5 + 14 + 2 + 1 + 3 = 32
따라서 이 요청 기준에서는 LOOK의 총 이동 거리는 32로 계산하는 것이 더 정확하다. 다만 강의 자료에서 시작점이나 끝점 포함 방식이 다르게 설정되어 있다면 계산값이 달라질 수 있다.
C-LOOK 스케줄링(C-LOOK Scheduling)은 기본적으로 LOOK 스케줄링(LOOK Scheduling)과 유사하지만, 한 방향으로만 요청을 처리하는 방식이다.
현재 방향으로 이동하면서 요청을 처리하다가 마지막 요청 위치에 도달하면 방향을 바꾸지 않는다. 대신 반대편에 있는 첫 번째 요청 위치로 바로 이동한 뒤, 다시 같은 방향으로 요청을 처리한다.
즉, C-LOOK은 LOOK의 장점처럼 요청이 없는 디스크 끝 지점까지 불필요하게 이동하지 않는다. 동시에 C-SCAN(Circular SCAN)처럼 한 방향으로 순환 처리하기 때문에 비교적 균등한 요청 처리가 가능하다.
따라서 C-LOOK은 헤드 이동 거리(Head Movement Distance)를 줄이면서도 공정성(Fairness)을 함께 고려한 효율적인 디스크 스케줄링 방식이라고 할 수 있다. C-SCAN과 비교하면 실제 요청이 없는 끝 지점까지 이동하지 않기 때문에 더 효율적인 순환 처리가 가능하다.
15 → 8 → 17 → 11 → 3 → 23 → 19 → 14 → 20 트랙번호
15 → 14 → 11 → 8 → 3 → 23 → 20 → 19 → 17 C-LOOK 이동순서
그림을 기준으로 보면, 현재 헤드(Disk Head)는 15번 트랙에서 시작해 한쪽 방향으로 이동한다. 그 과정에서 14, 11, 8, 3 순서로 요청을 처리한다.
이후 LOOK처럼 반대 방향으로 되돌아가며 처리하지 않고, 마지막 요청인 3번에서 반대편의 첫 번째 요청 위치인 23번으로 바로 이동한다. 그다음 같은 방향으로 다시 이동하면서 20, 19, 17 순서로 요청을 처리한다.
즉, C-LOOK은 요청이 존재하는 구간만 순환하면서 처리하고, 요청이 없는 끝 지점 이동은 생략하는 방식이다.
이 예제에서 총 헤드 이동 거리(Total Head Movement)는 38로 계산된다. C-SCAN보다 이동 거리를 줄이면서도 순환 처리의 공정성을 유지할 수 있는 방식이다.
정리하면 C-LOOK은 LOOK과 C-SCAN의 장점을 결합한 개선형 순환 스케줄링 방식이라고 이해할 수 있다.
C-LOOK은 C-SCAN과 달리 디스크의 실제 끝까지 이동하지 않고, 요청이 있는 마지막 위치까지만 이동한다. 그래서 불필요한 헤드 이동을 줄일 수 있다.
이 예제의 이동 경로는 15 → 14 → 11 → 8 → 3 → 23 → 20 → 19 → 17로 볼 수 있다. 총 이동 거리는 다음과 같다.
1 + 3 + 3 + 5 + 20 + 3 + 1 + 2 = 38
따라서 강의에서 제시한 총 이동 거리 38은 이 경로를 기준으로 하면 맞는 계산이다.
지금까지 여러 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)을 살펴보았다. 각 알고리즘에 따라 디스크 헤드(Disk Head)의 이동 경로와 총 이동 거리(Total Head Movement)가 달라진다는 것을 확인할 수 있었다.
헤드의 이동 거리가 달라지면 탐색 시간(Seek Time)도 달라지고, 그 결과 전체 디스크 접근 시간(Disk Access Time)과 성능(Disk Performance)에도 차이가 발생한다.
일반적으로 헤드의 평균 이동 거리(Average Head Movement)가 짧을수록 탐색 시간이 감소하므로 성능 향상에 유리하다. 예를 들어 SSTF(Shortest Seek Time First)는 현재 위치에서 가장 가까운 요청을 먼저 처리하기 때문에 이동 거리를 줄이는 데 효과적이다.
하지만 SSTF는 가까운 요청만 계속 선택할 경우, 멀리 있는 요청이 오랫동안 처리되지 못하는 기아 현상(Starvation)이 발생할 수 있다.
반면 SCAN 계열 알고리즘(SCAN-Based Algorithm)은 헤드 이동 경로가 비교적 일정하고, 요청을 균형 있게 처리할 수 있다. 따라서 성능(Performance)과 공정성(Fairness) 사이의 균형을 제공하는 방식이라고 할 수 있다.
결국 어떤 디스크 스케줄링 알고리즘이 항상 가장 좋다고 보기는 어렵다. 시스템 환경(System Environment), 요청 패턴(Request Pattern), 공정성 요구(Fairness Requirement), 성능 목표(Performance Goal)에 따라 적절한 방식을 선택하는 것이 중요하다.
디스크 스케줄링(Disk Scheduling)은 주로 HDD(Hard Disk Drive)처럼 헤드 이동이 필요한 저장장치에서 중요한 의미를 가진다. SSD(Solid State Drive)는 물리적인 헤드 이동이 없기 때문에 HDD와 같은 방식의 탐색 시간 최적화 효과는 상대적으로 작다.
정리하면, FCFS는 단순하고 공정하지만 비효율적일 수 있고, SSTF는 이동 거리를 줄이지만 기아 현상이 생길 수 있다. SCAN, C-SCAN, LOOK, C-LOOK은 헤드 이동 방향을 기준으로 요청을 처리하여 성능과 공정성의 균형을 맞추려는 방식이다.
지금까지 디스크 스케줄링(Disk Scheduling)을 통해 요청 처리 순서(Request Processing Order)를 조정하는 방법을 살펴보았다. 하지만 디스크 성능 향상(Disk Performance Improvement)은 스케줄링만으로 이루어지는 것은 아니다.
이를 보완하기 위해 다양한 보조 최적화 방법(Auxiliary Optimization Method)이 함께 사용된다.
대표적으로 디스크 요청 재정렬(Request Reordering)을 통해 헤드 이동 거리(Head Movement Distance)를 줄일 수 있다. 요청을 그대로 처리하는 것이 아니라, 더 효율적인 순서로 다시 정렬하면 탐색 시간(Seek Time)을 줄이는 데 도움이 된다.
또한 Read-Ahead 기법은 앞으로 필요할 가능성이 높은 데이터를 미리 읽어두는 방식이다. 특히 연속 접근(Sequential Access)이 많은 경우, 다음에 사용할 데이터를 미리 준비해두면 접근 성능을 높일 수 있다.
Write Buffering은 여러 쓰기 요청(Write Request)을 바로 처리하지 않고 버퍼(Buffer)에 모아두었다가 한 번에 처리하는 방식이다. 이를 통해 디스크 접근 횟수(Disk Access Count)를 줄이고, 쓰기 성능을 향상시킬 수 있다.
여기에 운영체제 캐시(OS Cache)와 저장장치 내부 캐시(Device Cache)를 함께 활용하면 전체 접근 속도(Access Speed)를 더 향상시킬 수 있다.
즉, 디스크 성능을 높이기 위해서는 스케줄링뿐만 아니라 요청 재정렬, Read-Ahead, Write Buffering, Cache와 같은 보조 최적화 방법을 함께 사용하는 것이 중요하다. 이후에는 이러한 방법들을 하나씩 살펴본다.
Read-Ahead는 순차적으로 데이터를 읽을 때 효과적이지만, 임의 접근(Random Access)이 많을 경우에는 미리 읽은 데이터가 실제로 사용되지 않아 효율이 떨어질 수 있다.
Write Buffering은 성능을 높이는 데 도움이 되지만, 데이터가 실제 디스크에 기록되기 전에 전원이 꺼지면 데이터 손실 위험이 있을 수 있다. 그래서 운영체제는 동기화(Synchronization)나 플러시(Flush) 같은 방식으로 안정성을 함께 관리한다.
요청 재정렬(Request Reordering)은 디스크 요청(Disk Request)의 처리 순서를 다시 구성하여 더 효율적으로 처리하는 방법이다.
디스크 요청을 도착한 순서 그대로 처리하는 것이 아니라, 서로 가까운 위치에 있는 요청들을 묶어서 처리하면 디스크 헤드(Disk Head)의 이동 거리를 줄일 수 있다.
이렇게 하면 헤드가 불필요하게 멀리 이동했다가 다시 돌아오는 동작을 줄일 수 있고, 그 결과 탐색 시간(Seek Time)과 전체 접근 시간(Disk Access Time)을 감소시키는 효과가 있다.
요청 재정렬은 앞에서 살펴본 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)과 함께 사용되며, 전체 디스크 처리 효율(Disk Processing Efficiency)을 높이는 데 기여한다.
요청 재정렬은 성능 향상에는 도움이 되지만, 특정 요청이 계속 뒤로 밀리지 않도록 공정성(Fairness)도 함께 고려해야 한다.
즉, 가까운 요청만 계속 우선 처리하면 일부 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있기 때문에, 성능과 공정성 사이의 균형이 중요하다.
Read-Ahead는 앞으로 필요할 것으로 예상되는 데이터를 미리 읽어 두는 방식이다. 즉, 아직 요청되지 않은 데이터라도 곧 필요할 가능성이 높다고 판단되면 미리 읽어서 캐시(Cache)에 저장해둔다.
이 방식은 특히 파일을 순차적으로 읽는 순차 접근(Sequential Access) 상황에서 효과적이다. 현재 데이터를 읽고 있다면, 그다음 데이터도 연속해서 필요할 가능성이 높기 때문이다.
미리 읽어둔 데이터가 실제로 요청되면, 다시 디스크(Disk)에 접근하지 않고 캐시에서 바로 전달할 수 있다. 이를 통해 디스크 접근 횟수(Disk Access Count)를 줄이고, 전체 읽기 성능(Read Performance)을 향상시킬 수 있다.
하지만 예측이 빗나가면 문제가 될 수 있다. 미리 읽어둔 데이터가 실제로 사용되지 않는다면 불필요한 입출력(I/O)이 발생하고, 캐시 공간(Cache Space)도 낭비될 수 있다.
따라서 Read-Ahead는 앞으로 사용할 가능성이 높은 데이터를 미리 준비하여 접근 속도를 높이는 최적화 기법이라고 이해할 수 있다.
Read-Ahead는 순차 접근(Sequential Access)에서는 효과적이지만, 랜덤 접근(Random Access)이 많은 경우에는 효율이 떨어질 수 있다.
즉, 다음에 어떤 데이터를 읽을지 예측하기 쉬운 상황에서는 성능 향상에 도움이 되지만, 접근 위치가 계속 바뀌는 경우에는 불필요한 데이터까지 읽게 될 수 있다.
Write Buffering은 쓰기 성능(Write Performance)을 높이기 위한 최적화 방법이다. 데이터를 즉시 디스크(Disk)에 기록하지 않고, 먼저 메모리 버퍼(Memory Buffer)에 저장한 뒤 나중에 한꺼번에 처리하는 방식이다.
이 방식은 여러 개의 작은 쓰기 요청(Write Request)을 모아서 처리할 수 있기 때문에 디스크 접근 횟수(Disk Access Count)를 줄이는 데 도움이 된다. 디스크에 매번 접근하는 대신 일정량의 데이터를 모아 한 번에 기록하면 전체 입출력 성능(I/O Performance)을 향상시킬 수 있다.
특히 순차적인 쓰기 작업(Sequential Write)이 많은 환경에서는 Write Buffering이 효율적으로 동작할 수 있다. 작은 쓰기 요청들을 모아 연속적으로 처리하면 디스크 접근이 더 효율적으로 이루어지기 때문이다.
하지만 버퍼에만 저장된 상태에서 시스템 장애(System Failure)나 전원 문제(Power Failure)가 발생하면, 아직 디스크에 기록되지 않은 일부 데이터가 손실될 가능성이 있다.
따라서 Write Buffering은 쓰기 성능을 높이는 데 효과적이지만, 데이터 안정성(Data Reliability)을 함께 고려해야 하는 방식이다.
Write Buffering은 성능 향상에는 도움이 되지만, 데이터가 실제 디스크에 기록되기 전까지는 손실 위험이 있다. 그래서 운영체제(Operating System)는 플러시(Flush)나 동기화(Synchronization)를 통해 버퍼에 있는 데이터를 디스크에 반영한다.
예를 들어 sync 같은 동작은 메모리 버퍼에 있는 변경 내용을 실제 저장장치에 기록하도록 하는 역할을 한다.
읽기(Read)와 쓰기(Write) 성능을 높이는 방법 외에도, 자주 사용하는 데이터를 빠르게 제공하기 위해 캐시(Cache) 방식이 함께 사용된다.
캐시는 자주 접근하는 데이터(Frequently Accessed Data)를 메모리(Memory)에 임시로 저장해두는 구조이다. 이후 같은 데이터가 다시 요청되면 디스크(Disk)에 직접 접근하지 않고, 메모리에서 빠르게 제공할 수 있다.
이 방식은 같은 데이터를 반복해서 사용하는 경우에 효과적이다. 디스크 접근 횟수(Disk Access Count)를 줄일 수 있기 때문에 입출력 대기 시간(I/O Waiting Time)을 크게 줄이는 데 도움이 된다.
또한 캐시는 Read-Ahead와 함께 사용될 수 있다. 앞으로 필요할 가능성이 높은 데이터를 미리 읽어 캐시에 저장해두면, 실제 요청이 들어왔을 때 더 빠르게 데이터를 전달할 수 있다.
캐시에는 운영체제(Operating System)가 관리하는 운영체제 캐시(OS Cache)도 있고, 디스크 장치 내부에 포함된 하드웨어 캐시(Hardware Cache)도 있다. 두 캐시가 함께 사용되면 전체 저장장치 접근 속도(Storage Access Speed)를 더 향상시킬 수 있다.
다만 캐시의 효율은 어떤 데이터를 오래 유지하고, 어떤 데이터를 교체할 것인지에 따라 달라진다. 따라서 캐시 교체 정책(Cache Replacement Policy)도 저장장치 성능을 결정하는 중요한 요소라고 할 수 있다.
캐시는 자주 사용되는 데이터를 빠르게 제공할 수 있지만, 캐시 공간(Cache Space)은 제한되어 있다. 그래서 운영체제는 LRU(Least Recently Used)와 같은 캐시 교체 정책(Cache Replacement Policy)을 사용해 어떤 데이터를 유지하고 제거할지 결정한다.
또한 쓰기 캐시(Write Cache)의 경우, 데이터가 실제 디스크에 기록되기 전에 장애가 발생하면 데이터 손실 위험이 있을 수 있으므로 안정성 관리도 함께 필요하다.
지금까지는 하나의 디스크(Disk)의 접근 성능(Access Performance)을 높이는 방법을 살펴보았다. 이번에는 여러 개의 디스크를 함께 사용하여 성능과 안정성을 높이는 RAID 구조(RAID Structure)에 대해 알아본다.
RAID(Redundant Array of Independent Disks)는 여러 개의 물리적 디스크(Physical Disk)를 묶어서 하나의 논리적인 저장장치(Logical Storage Device)처럼 사용하는 방식이다.
RAID를 사용하면 데이터 입출력(Input/Output)을 여러 디스크에 나누어 처리할 수 있다. 이를 통해 하나의 디스크만 사용할 때보다 성능 향상(Performance Improvement)을 기대할 수 있다.
또한 데이터를 여러 디스크에 분산 저장(Distributed Storage)하거나 중복 저장(Redundant Storage)함으로써, 일부 디스크에 장애(Failure)가 발생하더라도 데이터 안정성(Data Reliability)을 높일 수 있다.
즉, RAID는 저장장치의 성능 향상과 데이터 보호(Data Protection)를 함께 고려한 저장장치 구성 방식이라고 이해할 수 있다.
RAID는 목적에 따라 성능을 높이는 방식과 안정성을 높이는 방식이 다르다. 예를 들어 RAID 0은 데이터를 여러 디스크에 나누어 저장해 성능을 높이지만, 중복 저장이 없어 디스크 하나가 고장 나면 데이터 손실 위험이 크다.
반면 RAID 1은 같은 데이터를 두 개 이상의 디스크에 복제하여 안정성을 높이는 방식이다. 이후 RAID 0, RAID 1, RAID 5처럼 RAID 수준(RAID Level)에 따라 특징이 달라진다고 이해하면 좋다.
RAID(Redundant Array of Independent Disks)는 하나의 방식만 존재하는 것이 아니라, 디스크를 구성하는 방법에 따라 여러 수준(Level)으로 나뉜다.
대표적인 RAID 수준에는 RAID 0, RAID 1, RAID 2, RAID 3, RAID 4, RAID 5, RAID 6이 있다. 각 수준마다 데이터 저장 방식(Data Storage Method), 성능 향상 방식(Performance Improvement Method), 장애 대응 방식(Fault Tolerance Method)이 다르게 구성된다.
또한 RAID 0+1, RAID 1+0처럼 두 가지 RAID 방식을 결합한 조합 구조(Nested RAID)도 존재한다. 이러한 방식은 성능과 안정성을 함께 고려하기 위해 사용된다.
다만 이번 내용에서는 모든 RAID 수준을 세부적으로 다루기보다는, RAID의 기본 원리를 이해하는 데 핵심이 되는 RAID 0, RAID 1, RAID 5를 중심으로 살펴본다.
RAID 0은 성능 향상에 초점을 둔 방식이고, RAID 1은 데이터 복제(Mirroring)를 통한 안정성 향상에 초점을 둔 방식이다.
RAID 5는 데이터와 패리티(Parity)를 여러 디스크에 분산 저장하여 성능과 안정성을 함께 고려하는 방식이다. 따라서 RAID의 기본 개념을 이해할 때는 RAID 0, RAID 1, RAID 5를 중심으로 비교하면 좋다.
RAID 0은 데이터를 여러 디스크(Disk)에 나누어 저장하는 방식으로, 분산 저장(Distributed Storage) 또는 스트라이핑(Striping) 방식이라고도 한다.
그림을 보면 데이터 A, B, C, D가 각각 다른 디스크에 나누어 저장되고, 그다음 데이터 E, F, G, H도 각 디스크에 분산되어 기록되는 구조를 확인할 수 있다.
이처럼 데이터를 일정한 단위로 나누어 여러 디스크에 동시에 저장하는 방식을 스트라이핑(Striping)이라고 한다. 여러 디스크가 동시에 읽기(Read)와 쓰기(Write)에 참여할 수 있기 때문에 입출력 성능(I/O Performance)을 높일 수 있다.
또한 모든 디스크의 저장 공간을 데이터 저장에 사용할 수 있으므로 저장 공간 활용(Storage Utilization)도 효율적이다.
하지만 RAID 0은 중복 저장(Redundancy)이나 오류 복구 정보(Recovery Information)를 제공하지 않는다. 따라서 디스크 하나만 고장 나더라도 전체 데이터 복구가 어려워질 수 있다.
즉, RAID 0은 데이터 안정성(Data Reliability)보다는 성능(Performance)을 우선하는 환경에 적합한 방식이라고 이해할 수 있다.
RAID 0은 이름에 RAID가 들어가지만, 실제로는 중복성(Redundancy)이 없다. 따라서 중요한 데이터를 안전하게 보관하기 위한 방식이라기보다는, 빠른 읽기와 쓰기 성능이 필요한 경우에 사용하는 방식으로 이해하는 것이 좋다.
RAID 1은 동일한 데이터를 두 개 이상의 디스크(Disk)에 동시에 복사해서 저장하는 방식이다. 이 방식을 미러링(Mirroring)이라고도 한다.
하나의 디스크에 기록된 내용이 다른 디스크에도 그대로 저장되기 때문에, 같은 데이터가 여러 곳에 존재하게 된다. 따라서 디스크 하나에 장애(Failure)가 발생하더라도 다른 디스크에 남아 있는 데이터를 이용해 서비스를 계속할 수 있다.
RAID 1은 읽기(Read) 작업을 여러 디스크에 나누어 처리할 수 있기 때문에 읽기 성능(Read Performance)이 향상될 수 있다. 하지만 같은 데이터를 중복 저장(Redundant Storage)하기 때문에 실제 사용 가능한 저장 공간(Storage Capacity)의 효율은 낮아진다.
그림으로 보면, 왼쪽 디스크에 ABCD가 저장되면 바로 옆 디스크에도 동일한 ABCD가 그대로 복사되어 저장된다. 마찬가지로 EFGH, IJKL, MNOP도 각각 한 쌍의 디스크에 동일하게 복제된다.
즉, 두 개의 디스크가 하나의 데이터 집합(Data Set)을 함께 보관하는 구조라고 볼 수 있다. 이처럼 동일한 데이터를 동시에 저장해두기 때문에 한쪽 디스크에 문제가 생겨도 다른 디스크를 이용해 데이터를 계속 사용할 수 있다.
정리하면 RAID 1은 저장 공간 효율(Storage Efficiency)은 낮지만, 데이터 안정성(Data Reliability)이 매우 중요한 환경에 적합한 방식이다.
RAID 1은 데이터 보호(Data Protection)에 강하지만, 백업(Backup)을 완전히 대체하는 것은 아니다. 예를 들어 사용자가 실수로 파일을 삭제하거나, 악성코드로 데이터가 손상되면 복제된 디스크에도 같은 변경이 반영될 수 있다.
따라서 RAID 1은 디스크 고장에 대비하는 방식이고, 중요한 데이터는 별도의 백업도 함께 필요하다고 이해하면 좋다.
RAID 5는 패리티(Parity) 기반의 저장 방식이다. 데이터 블록(Data Block)과 패리티 정보를 여러 디스크(Disk)에 분산해서 저장하는 구조이다.
여기서 패리티(Parity)는 디스크 장애가 발생했을 때 손실된 데이터를 복구하기 위한 계산 정보라고 이해할 수 있다. 여러 디스크 중 하나에 장애(Failure)가 발생하더라도, 남아 있는 데이터와 패리티 정보를 이용해 손실된 데이터를 복구할 수 있다.
RAID 5는 읽기 작업(Read Operation)이 여러 디스크에 분산되어 수행되기 때문에 읽기 성능(Read Performance)을 높일 수 있다. 또한 패리티를 통해 장애 복구가 가능하므로 성능(Performance)과 안정성(Reliability) 사이에서 비교적 균형 잡힌 구조를 제공한다.
다만 데이터를 기록할 때는 패리티를 함께 계산하고 저장해야 한다. 따라서 쓰기 작업(Write Operation)에서는 추가적인 패리티 계산 과정이 필요하며, 이로 인해 쓰기 성능(Write Performance)이 저하될 수 있다.
RAID 5는 최소 3개의 디스크가 필요하며, 저장 공간 효율(Storage Efficiency), 읽기 성능, 장애 복구 기능을 함께 고려할 수 있어 일반적인 서버 환경(Server Environment)에서 널리 사용되는 방식이다.
그림으로 보면 각 디스크에는 데이터 블록과 패리티 블록(Parity Block)이 함께 저장된다. 이때 패리티는 특정 디스크 하나에 고정되지 않고 여러 디스크에 분산되어 배치된다.
예를 들어 첫 번째 줄에서는 마지막 디스크에 Parity 0이 저장되고, 다음 줄에서는 다른 디스크에 Parity 1이 저장되는 방식으로 패리티 위치가 바뀐다. 이렇게 패리티를 분산하면 특정 디스크 하나에 패리티 처리 부담이 집중되는 것을 줄일 수 있다.
만약 디스크 하나에 장애가 발생하더라도, 같은 줄에 남아 있는 데이터 블록들과 패리티 정보를 이용해 손실된 블록을 다시 계산할 수 있다.
정리하면 RAID 5는 데이터를 분산 저장하면서 패리티를 함께 관리하여, 저장 공간 효율, 읽기 성능, 장애 복구 기능을 모두 고려한 실용적인 RAID 방식이라고 이해할 수 있다.
RAID 5는 디스크 1개 장애까지는 복구할 수 있지만, 동시에 2개 이상의 디스크가 고장 나면 데이터 복구가 어려울 수 있다. 2개 디스크 장애까지 대비하려면 RAID 6처럼 이중 패리티(Double Parity)를 사용하는 방식이 필요하다.
또한 RAID 5는 패리티 계산 때문에 작은 쓰기 작업(Random Write)이 많은 환경에서는 성능이 떨어질 수 있다. 따라서 읽기 작업이 많고 저장 공간 효율과 안정성을 함께 고려해야 하는 환경에 적합하다.
RAID 수준(RAID Level)에 따라 성능(Performance), 안정성(Reliability), 저장 공간 효율(Storage Efficiency)이 달라진다.
RAID 0은 데이터를 여러 디스크(Disk)에 분산 저장(Striping)하기 때문에 입출력 성능(I/O Performance)이 높다는 장점이 있다. 여러 디스크가 동시에 읽기와 쓰기에 참여할 수 있기 때문이다. 하지만 중복 저장(Redundancy)이나 복구 정보(Recovery Information)가 없기 때문에, 디스크 하나에 장애가 발생하면 데이터 보호(Data Protection)를 제공하기 어렵다.
RAID 1은 동일한 데이터를 여러 디스크에 복제 저장(Mirroring)하는 방식이다. 따라서 디스크 하나에 문제가 발생하더라도 다른 디스크에 남아 있는 데이터를 이용할 수 있어 안정성이 매우 높다. 하지만 같은 데이터를 중복해서 저장해야 하므로 실제 사용할 수 있는 저장 공간의 효율은 낮아진다.
RAID 5는 데이터(Data)와 패리티(Parity)를 여러 디스크에 분산 저장하는 방식이다. 이를 통해 읽기 성능(Read Performance)과 장애 복구 기능(Fault Tolerance)을 함께 제공할 수 있다. 따라서 RAID 5는 성능과 안정성 사이에서 비교적 균형 잡힌 방식이라고 할 수 있다.
결국 어떤 RAID 수준이 가장 좋다고 단정하기는 어렵다. 성능이 중요한지, 데이터 안정성이 중요한지, 저장 공간 효율이 중요한지에 따라 적합한 RAID 수준이 달라진다. 따라서 사용 목적(Purpose)과 운영 환경(Operating Environment)에 맞게 적절한 RAID 수준을 선택하는 것이 중요하다.
RAID 0은 성능은 좋지만 안정성이 낮고, RAID 1은 안정성은 높지만 저장 공간 효율이 낮다. RAID 5는 성능, 안정성, 저장 공간 효율을 균형 있게 고려한 방식이다.
다만 RAID는 디스크 고장에 대비하는 기술이지, 백업(Backup)을 완전히 대체하는 기술은 아니다. 실수로 파일을 삭제하거나 데이터가 손상되면 RAID 구성 안에서도 문제가 그대로 반영될 수 있으므로 중요한 데이터는 별도 백업이 필요하다.
앞서 디스크(Disk)의 구조, 접근 시간(Access Time), 성능 향상 기법(Performance Optimization Method)을 살펴보았다. 이제 이러한 개념들이 실제 시스템(System)에서 어떻게 나타나는지 확인하는 실습을 진행한다.
이번 실습에서는 순차 접근(Sequential Access)과 랜덤 접근(Random Access)의 차이를 확인하고, FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First) 스케줄링을 비교한다. 또한 버퍼링(Buffering)과 캐시(Cache)가 성능에 어떤 영향을 주는지도 함께 살펴본다.
첫 번째 실습은 순차 접근과 랜덤 접근의 차이를 확인하는 내용이다. 디스크는 데이터가 저장된 위치와 접근 방식에 따라 접근 시간이 달라질 수 있다.
연속된 위치의 데이터를 차례대로 읽는 순차 접근은 헤드 이동(Head Movement)이나 위치 변경 비용이 적기 때문에 비교적 효율적으로 처리된다.
반면 떨어진 위치의 데이터를 반복해서 읽는 랜덤 접근은 헤드 이동이나 위치 변경 비용이 증가할 수 있다. 이로 인해 순차 접근보다 더 많은 시간이 걸릴 수 있다.
따라서 이번 실습에서는 접근 방식에 따라 왜 성능 차이가 발생하는지 직접 확인해본다.
순차 접근(Sequential Access)과 랜덤 접근(Random Access)의 성능 차이는 특히 HDD(Hard Disk Drive)에서 크게 나타난다. HDD는 헤드 이동과 회전 지연이 있기 때문이다.
반면 SSD(Solid State Drive)는 물리적인 헤드 이동이 없기 때문에 HDD보다 랜덤 접근 성능이 좋지만, 내부 컨트롤러(Controller)와 플래시 메모리(Flash Memory) 구조에 따라 순차 접근과 랜덤 접근 사이의 성능 차이가 완전히 사라지는 것은 아니다.
순차 접근(Sequential Access)은 현재 위치 다음의 데이터를 연속해서 계속 읽어나가는 방식이다. 반면 랜덤 접근(Random Access)은 필요한 위치로 직접 이동한 뒤 해당 데이터를 읽는 방식이다.
파일 안에서 읽기 위치를 직접 변경할 때는 lseek() 함수를 사용한다. 이번 실습에서는 lseek()를 이용해 접근 위치를 계속 바꾸면서, 위치 변경이 많아질수록 처리 시간이 증가할 수 있다는 점을 확인한다.
그림의 핵심 코드를 보면 먼저 순차 접근은 다음과 같이 이루어진다.
lseek(fd, 0, SEEK_SET);
read(fd, buf, BLOCK_SIZE);
여기서 fd는 열린 파일을 가리키는 파일 디스크립터(File Descriptor)이다. 0은 이동할 위치를 의미하고, SEEK_SET은 파일의 시작 지점(Start Point)을 기준으로 위치를 정하겠다는 의미이다.
이후 read()를 실행하면 현재 오프셋(Offset) 위치에서 BLOCK_SIZE만큼 데이터를 읽어 buf에 저장한다. 한 번 읽고 나면 파일 오프셋은 자동으로 다음 위치로 이동하므로, 반복해서 읽으면 파일을 앞에서부터 차례대로 읽는 순차 접근이 된다.
반면 랜덤 접근은 다음과 같은 방식으로 이루어진다.
offset = (rand() % 1024) * BLOCK_SIZE;
lseek(fd, offset, SEEK_SET);
read(fd, buf, BLOCK_SIZE);
이 코드는 0부터 1023 사이의 임의의 블록 번호를 선택하고, 여기에 BLOCK_SIZE를 곱해 실제 파일 안에서 이동할 위치를 결정한다. 이후 lseek()를 통해 파일 오프셋을 해당 위치로 직접 이동시키고, read()를 통해 그 위치의 데이터를 읽는다.
즉, 순차 접근은 현재 위치에서 다음 데이터를 계속 읽는 방식이고, 랜덤 접근은 lseek()를 이용해 매번 다른 위치로 이동한 뒤 읽는 방식이다.
두 방식을 같은 횟수만큼 반복해서 실행 시간을 비교하면, 접근 위치를 계속 바꾸는 랜덤 접근이 순차 접근보다 더 많은 처리 비용을 가질 수 있다는 점을 확인할 수 있다.
순차 접근은 파일의 다음 위치를 계속 읽기 때문에 운영체제(Operating System)의 Read-Ahead나 캐시(Cache) 효과를 받기 쉽다.
반면 랜덤 접근은 매번 다른 위치로 이동하기 때문에 HDD(Hard Disk Drive)에서는 헤드 이동(Head Movement)과 탐색 시간(Seek Time)의 영향이 커질 수 있다. SSD(Solid State Drive)는 물리적인 헤드 이동이 없기 때문에 랜덤 접근의 부담이 HDD보다 작지만, 순차 접근과 랜덤 접근의 성능 차이가 완전히 사라지는 것은 아니다.
이 예제는 순차 접근(Sequential Access)과 랜덤 접근(Random Access)의 실행 시간을 직접 측정하여 성능 차이를 확인하기 위한 코드이다.
먼저 make_test_file() 함수에서는 실험용 파일(Test File)을 생성한다. open() 함수에서 O_CREAT, O_TRUNC, O_WRONLY 옵션을 사용하여 파일이 없으면 새로 만들고, 기존 파일이 있으면 내용을 비운 뒤 쓰기 전용으로 연다.
그다음 여러 개의 블록 데이터(Block Data)를 반복해서 기록한다. 즉, 순차 접근과 랜덤 접근 실험에 사용할 충분한 크기의 파일을 미리 만들어두는 과정이다.
메인 함수(Main Function)에서는 이 파일을 읽기 전용(Read Only)으로 연 뒤, 순차 접근 시간과 랜덤 접근 시간을 각각 측정한다.
순차 접근은 lseek()를 사용해 파일의 시작 위치로 이동한 뒤, 반복문에서 read()만 수행하여 연속된 블록을 차례대로 읽는다. 이 경우 한 번 읽을 때마다 오프셋(Offset)이 자동으로 다음 위치로 이동하므로 파일을 앞에서부터 순서대로 읽게 된다.
반면 랜덤 접근은 rand()를 사용해 임의의 블록 위치를 정하고, lseek()로 매번 다른 위치로 이동한 뒤 read()를 수행한다. 즉, 파일 안의 여러 위치를 반복적으로 이동하면서 데이터를 읽는 방식이다.
마지막으로 clock() 함수를 이용해 순차 접근과 랜덤 접근의 실행 시간을 측정하고 출력한다.
실행 결과를 보면 순차 접근 시간은 0.001248초, 랜덤 접근 시간은 0.004913초로 측정되었다. 같은 양의 데이터를 읽더라도 순차 접근이 랜덤 접근보다 더 빠르게 나타난 것을 확인할 수 있다.
그 이유는 순차 접근은 연속된 위치를 읽기 때문에 위치 변경 비용이 거의 발생하지 않지만, 랜덤 접근은 매번 다른 위치로 이동해야 하므로 추가적인 처리 지연과 탐색 비용(Seek Cost)이 발생할 수 있기 때문이다.
따라서 이 예제는 저장장치(Storage Device)가 연속된 위치를 읽는 접근 방식에 더 유리하며, 디스크 접근 순서(Disk Access Order)가 성능에 영향을 준다는 점을 확인할 수 있는 실습이다.
실습 결과는 실행 환경에 따라 달라질 수 있다. 운영체제 캐시(OS Cache)가 작동하면 두 번째 실행부터는 디스크에서 직접 읽는 것이 아니라 메모리 캐시에서 읽을 수 있기 때문에 시간이 더 짧게 측정될 수 있다.
디스크(Disk)는 같은 요청 집합(Request Set)이 들어오더라도, 어떤 순서로 처리하느냐에 따라 접근 비용(Access Cost)이 달라질 수 있다.
즉, 요청 처리 순서(Request Processing Order)에 따라 디스크 헤드(Disk Head)의 이동 거리와 전체 처리 시간(Total Processing Time)이 달라진다. 따라서 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)은 효율적인 요청 처리 순서를 결정하기 위해 필요하다.
이번 실습에서는 대표적인 디스크 스케줄링 방식인 FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First)를 비교하여 성능 차이를 직접 확인한다.
디스크 요청(Disk Request)은 일반적으로 큐(Queue) 형태로 순차적으로 도착한다. 운영체제(Operating System)는 이 요청들을 어떤 순서로 처리할지 결정하며, 이 과정이 디스크 스케줄링(Disk Scheduling)이다.
특히 HDD(Hard Disk Drive)에서는 헤드가 이동한 거리가 길어질수록 탐색 시간(Seek Time)이 증가하고, 전체 접근 시간(Disk Access Time)에도 큰 영향을 준다.
따라서 가능한 한 헤드 이동 거리(Head Movement Distance)를 줄이는 방향으로 요청을 처리하면 전체 디스크 성능(Disk Performance)을 개선할 수 있다.
이번 시뮬레이션에서는 FCFS와 SSTF가 같은 요청 집합을 어떻게 다르게 처리하는지 살펴보고, 그 결과 총 헤드 이동 거리(Total Head Movement)가 어떻게 달라지는지 비교한다.
FCFS는 요청이 도착한 순서대로 처리하기 때문에 구현이 단순하고 공정하지만, 헤드 이동 거리가 길어질 수 있다.
SSTF는 현재 헤드 위치에서 가장 가까운 요청을 먼저 처리하므로 총 이동 거리를 줄이는 데 유리하지만, 멀리 있는 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있다.
디스크(Disk)는 같은 요청 집합(Request Set)이 들어오더라도, 어떤 순서로 처리하느냐에 따라 접근 비용(Access Cost)이 달라질 수 있다.
즉, 요청 처리 순서(Request Processing Order)에 따라 디스크 헤드(Disk Head)의 이동 거리와 전체 처리 시간(Total Processing Time)이 달라진다. 따라서 디스크 스케줄링 알고리즘(Disk Scheduling Algorithm)은 효율적인 요청 처리 순서를 결정하기 위해 필요하다.
이번 실습에서는 대표적인 디스크 스케줄링 방식인 FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First)를 비교하여 성능 차이를 직접 확인한다.
디스크 요청(Disk Request)은 일반적으로 큐(Queue) 형태로 순차적으로 도착한다. 운영체제(Operating System)는 이 요청들을 어떤 순서로 처리할지 결정하며, 이 과정이 디스크 스케줄링(Disk Scheduling)이다.
특히 HDD(Hard Disk Drive)에서는 헤드가 이동한 거리가 길어질수록 탐색 시간(Seek Time)이 증가하고, 전체 접근 시간(Disk Access Time)에도 큰 영향을 준다.
따라서 가능한 한 헤드 이동 거리(Head Movement Distance)를 줄이는 방향으로 요청을 처리하면 전체 디스크 성능(Disk Performance)을 개선할 수 있다.
이번 시뮬레이션에서는 FCFS와 SSTF가 같은 요청 집합을 어떻게 다르게 처리하는지 살펴보고, 그 결과 총 헤드 이동 거리(Total Head Movement)가 어떻게 달라지는지 비교한다.
FCFS는 요청이 도착한 순서대로 처리하기 때문에 구현이 단순하고 공정하지만, 헤드 이동 거리가 길어질 수 있다.
SSTF는 현재 헤드 위치에서 가장 가까운 요청을 먼저 처리하므로 총 이동 거리를 줄이는 데 유리하지만, 멀리 있는 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있다.
이 코드는 FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First) 스케줄링 방식의 총 헤드 이동 거리(Total Head Movement)를 계산하는 핵심 부분이다.
먼저 FCFS 코드를 살펴보면, 반복문을 통해 요청 배열(Request Array)을 앞에서부터 차례대로 처리한다. 여기서 abs(current - request[i])는 현재 헤드 위치(Current Head Position)에서 다음 요청 위치(Request Position)까지의 이동 거리를 의미한다.
이 값을 total에 계속 누적하고, 이후 current = request[i]를 통해 현재 헤드 위치를 방금 처리한 요청 위치로 변경한다. 즉, FCFS는 요청이 도착한 순서를 그대로 따라가면서 이동 거리를 차례대로 누적 계산하는 방식이다.
반면 SSTF 코드는 아직 처리하지 않은 요청들 가운데 현재 헤드 위치에서 가장 가까운 요청을 찾는 구조이다. 내부 반복문에서 각 요청과 현재 위치 사이의 거리를 계산하고, 그중 가장 작은 거리인 min을 가진 요청의 인덱스(Index)를 idx로 선택한다.
그다음 선택된 요청을 처리 완료 상태로 표시하고, 해당 이동 거리인 min을 total에 더한다. 이후 현재 위치도 선택된 요청 위치로 변경한다.
즉, SSTF는 매 단계마다 가장 가까운 요청을 선택하여 총 헤드 이동 거리를 줄이도록 동작하는 방식이다.
이 두 코드를 실행해서 결과를 비교하면, 같은 요청 집합(Request Set)이라도 처리 순서(Request Processing Order)에 따라 전체 이동 비용(Total Movement Cost)이 어떻게 달라지는지 확인할 수 있다.
또한 SSTF는 총 이동 거리를 줄이는 데 효과적이지만, 가까운 요청만 계속 선택하면 멀리 있는 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있다.
이 코드는 같은 요청 집합(Request Set)에서 FCFS(First-Come, First-Served)와 SSTF(Shortest Seek Time First) 방식의 총 헤드 이동 거리(Total Head Movement)를 비교하는 예제이다.
먼저 요청 배열(Request Array)에는 다음과 같은 디스크 요청들이 저장되어 있다.
int request[N] = {98, 183, 37, 122, 14, 124, 65, 67};
초기 헤드 위치(Initial Head Position)는 다음과 같이 53으로 설정되어 있다.
int head = 53;
FCFS 부분에서는 요청 배열을 앞에서부터 순서대로 처리한다. 현재 헤드 위치(Current Head Position)와 다음 요청 위치(Request Position)의 차이를 절댓값으로 계산하고, 그 값을 total_fcfs에 누적한다.
즉, FCFS는 요청이 도착한 순서를 그대로 따라가면서 헤드가 얼마나 이동하는지를 계산하는 방식이다.
반면 SSTF 부분에서는 아직 처리되지 않은 요청들 가운데 현재 헤드 위치에서 가장 가까운 요청을 찾는다. 내부 반복문에서 모든 후보 요청과의 거리를 비교하고, 가장 짧은 거리의 요청을 선택한다.
이 과정을 모든 요청이 처리될 때까지 반복하면서 총 이동 거리를 total_sstf에 누적한다. 마지막으로 FCFS와 SSTF의 결과를 출력하여 알고리즘에 따라 이동 비용(Movement Cost)이 어떻게 달라지는지 확인한다.
실행 결과를 보면 FCFS의 총 이동 거리는 640, SSTF의 총 이동 거리는 246으로 나타난다. 즉, SSTF가 FCFS보다 헤드 이동 거리를 크게 줄일 수 있다는 것을 확인할 수 있다.
그 이유는 FCFS는 요청이 도착한 순서를 그대로 처리하지만, SSTF는 현재 위치에서 가장 가까운 요청을 우선 처리하기 때문이다.
따라서 요청 처리 순서(Request Processing Order)는 디스크 성능(Disk Performance)에 직접적인 영향을 준다. 이 실습은 디스크 스케줄링(Disk Scheduling)이 왜 필요한지 확인할 수 있는 예제라고 할 수 있다.
또한 SSTF는 총 헤드 이동 거리를 줄이는 데 효과적이지만, 가까운 요청이 계속 들어오면 멀리 있는 요청이 오래 기다리는 기아 현상(Starvation)이 발생할 수 있다. 따라서 성능과 공정성(Fairness)을 함께 고려해야 한다.
이번 실습은 버퍼링(Buffering)이 디스크 성능(Disk Performance)에 어떤 영향을 주는지 확인하는 내용이다.
디스크 쓰기 작업(Write Operation)은 프로그램에서 write() 함수를 호출했다고 해서 항상 즉시 디스크(Disk)에 기록되는 것은 아니다. 운영체제(Operating System)는 성능 향상을 위해 데이터를 먼저 메모리 버퍼(Memory Buffer)에 저장한 뒤, 나중에 한꺼번에 디스크에 기록할 수 있다.
즉, 프로그램이 write()를 호출하는 시점과 실제 데이터가 디스크에 기록되는 시점은 서로 다를 수 있다.
이러한 버퍼링 방식은 여러 개의 작은 쓰기 요청(Write Request)을 모아서 처리할 수 있기 때문에 디스크 접근 횟수(Disk Access Count)를 줄이는 데 도움이 된다. 디스크에 매번 접근하지 않고 한 번에 처리하면 전체 입출력 성능(I/O Performance)을 향상시킬 수 있다.
이번 실습에서는 버퍼링이 디스크 접근 횟수와 전체 성능에 어떤 영향을 주는지 확인한다. 이를 통해 운영체제가 왜 데이터를 즉시 디스크에 기록하지 않고, 메모리 버퍼를 활용해 쓰기 작업을 최적화하는지 이해할 수 있다.
버퍼링(Buffering)은 성능 향상에는 도움이 되지만, 데이터가 아직 디스크에 기록되기 전에 시스템 장애(System Failure)나 전원 문제(Power Failure)가 발생하면 데이터 손실 위험이 있을 수 있다.
따라서 운영체제는 필요할 때 플러시(Flush)나 동기화(Synchronization)를 통해 버퍼에 있는 데이터를 실제 디스크에 반영한다.
이번 실습은 버퍼링(Buffering)이 디스크 성능(Disk Performance)에 어떤 영향을 주는지 확인하는 내용이다.
디스크 쓰기 작업(Write Operation)은 프로그램에서 write() 함수를 호출했다고 해서 항상 즉시 디스크(Disk)에 기록되는 것은 아니다. 운영체제(Operating System)는 성능 향상을 위해 데이터를 먼저 메모리 버퍼(Memory Buffer)에 저장한 뒤, 나중에 한꺼번에 디스크에 기록할 수 있다.
즉, 프로그램이 write()를 호출하는 시점과 실제 데이터가 디스크에 기록되는 시점은 서로 다를 수 있다.
이러한 버퍼링 방식은 여러 개의 작은 쓰기 요청(Write Request)을 모아서 처리할 수 있기 때문에 디스크 접근 횟수(Disk Access Count)를 줄이는 데 도움이 된다. 디스크에 매번 접근하지 않고 한 번에 처리하면 전체 입출력 성능(I/O Performance)을 향상시킬 수 있다.
이번 실습에서는 버퍼링이 디스크 접근 횟수와 전체 성능에 어떤 영향을 주는지 확인한다. 이를 통해 운영체제가 왜 데이터를 즉시 디스크에 기록하지 않고, 메모리 버퍼를 활용해 쓰기 작업을 최적화하는지 이해할 수 있다.
추가로 알아두면 좋은 점
버퍼링(Buffering)은 성능 향상에는 도움이 되지만, 데이터가 아직 디스크에 기록되기 전에 시스템 장애(System Failure)나 전원 문제(Power Failure)가 발생하면 데이터 손실 위험이 있을 수 있다.
따라서 운영체제는 필요할 때 플러시(Flush)나 동기화(Synchronization)를 통해 버퍼에 있는 데이터를 실제 디스크에 반영한다.
fsync()버퍼링(Buffering)은 디스크 쓰기 성능(Write Performance)을 높이기 위한 방식이다. write() 함수는 데이터를 즉시 디스크(Disk)에 기록하는 것이 아니라, 우선 커널 버퍼(Kernel Buffer)에 저장한다.
이후 운영체제(Operating System)는 일정 시점에 버퍼에 모인 데이터를 실제 디스크에 반영한다. 이렇게 여러 번의 작은 쓰기 요청(Write Request)을 모아서 처리하면 디스크 접근 횟수(Disk Access Count)를 줄일 수 있고, 전체 입출력 효율(I/O Efficiency)을 높일 수 있다.
반대로 fsync()는 버퍼에 있는 데이터를 즉시 디스크에 강제로 기록하도록 요청하는 함수이다. 즉, write()만 호출한 경우에는 데이터가 커널 버퍼에 머물 수 있지만, fsync()를 호출하면 해당 파일과 관련된 변경 내용을 실제 디스크에 반영하게 된다.
사진에 포함된 핵심 코드는 버퍼링 동작과 fsync()의 차이를 확인하기 위한 부분이다.
write(fd, buf, SIZE);
// 강제 디스크 반영
fsync(fd);
먼저 write(fd, buf, SIZE)는 파일에 데이터를 기록하라는 요청을 운영체제에 전달한다. 이 호출은 비교적 빠르게 종료될 수 있으며, 실제 디스크 기록 작업은 운영체제가 나중에 처리할 수 있다.
그다음 fsync(fd)를 호출하면 해당 파일의 버퍼 내용을 즉시 디스크에 반영하도록 요청한다. 따라서 write()만 사용한 경우와 write() 뒤에 fsync()까지 수행한 경우를 비교하면, 강제로 디스크에 저장하는 과정에서 실행 시간이 어떻게 달라지는지 확인할 수 있다.
정리하면, 버퍼링은 쓰기 요청을 모아 처리하여 성능을 높이는 방식이고, fsync()는 데이터 안정성을 위해 버퍼 내용을 실제 디스크에 강제로 기록하는 방식이다.
write()가 성공했다고 해서 데이터가 반드시 즉시 물리 디스크에 저장되었다는 뜻은 아니다. 운영체제의 버퍼에 기록된 상태일 수 있다.
반면 fsync()는 데이터 손실 위험을 줄이는 데 도움이 되지만, 실제 디스크 기록을 기다려야 하므로 실행 시간이 더 길어질 수 있다. 즉, 버퍼링은 성능을 높이고, fsync()는 안정성을 높이는 방향의 기능이라고 이해하면 좋다.
이 예제는 버퍼링(Buffering)만 사용할 때와 매번 fsync()를 사용할 때의 실행 시간을 비교하는 코드이다.
먼저 버퍼링만 사용하는 경우에는 파일을 연 뒤, 반복문 안에서 write()를 여러 번 수행한다. 이때 각 쓰기 요청(Write Request)은 운영체제(Operating System)의 커널 버퍼(Kernel Buffer)를 통해 처리된다. 따라서 write()를 호출할 때마다 실제 디스크(Disk)에 바로 기록되지 않을 수 있다.
반면 fsync()를 사용하는 경우에는 같은 방식으로 write()를 수행한 뒤, 반복적으로 fsync() 함수를 호출한다. 이는 데이터를 쓸 때마다 버퍼에 있는 내용을 실제 디스크에 강제로 반영하도록 하는 구조이다.
두 경우 모두 clock() 함수를 이용해 전체 수행 시간을 측정하고, 마지막에는 close()를 통해 파일을 닫는다. 이를 통해 버퍼링만 사용할 때와 fsync()를 매번 사용할 때 성능 차이가 어떻게 나타나는지 확인할 수 있다.
실행 결과를 보면 버퍼링만 사용하는 경우는 0.002341초, fsync()를 사용하는 경우는 0.128942초로 측정된다. 즉, fsync()를 매번 호출하면 수행 시간이 크게 증가하는 것을 확인할 수 있다.
그 이유는 버퍼링 방식은 여러 쓰기 요청을 모아서 처리할 수 있지만, fsync()는 매번 실제 디스크 기록이 완료될 때까지 기다려야 하기 때문이다.
따라서 버퍼링은 디스크 접근 횟수(Disk Access Count)를 줄여 성능 향상에 도움이 되지만, 즉시 기록을 보장하려면 그만큼 추가 비용이 발생한다.
즉, 이 실습은 쓰기 성능(Write Performance)과 데이터 안전성(Data Safety) 사이에 트레이드 오프(Trade-off)가 존재한다는 점을 보여준다.
write()는 데이터를 커널 버퍼에 기록한 뒤 빠르게 반환될 수 있지만, fsync()는 버퍼 내용을 실제 저장장치에 반영하도록 강제한다.
그래서 fsync()는 데이터 손실 위험을 줄이는 데 도움이 되지만, 성능 측면에서는 비용이 크다. 중요한 데이터는 안정성이 필요하므로 fsync()가 유용할 수 있고, 일반적인 대량 쓰기에서는 버퍼링을 활용하는 것이 더 효율적일 수 있다.
이번 실습은 캐시(Cache)가 디스크 접근 성능(Disk Access Performance)에 어떤 영향을 주는지 확인하는 내용이다.
같은 파일(File)을 반복해서 읽을 때, 매번 수행 시간이 동일하지 않을 수 있다. 그 이유는 운영체제(Operating System)가 디스크(Disk)에서 읽은 데이터를 메모리(Memory)에 캐시 형태로 저장해둘 수 있기 때문이다.
첫 번째 접근에서는 실제 디스크에서 데이터를 읽어야 하므로 시간이 더 걸릴 수 있다. 하지만 이후 같은 데이터를 다시 요청하면, 운영체제가 디스크에 다시 접근하지 않고 메모리에 저장된 캐시 데이터를 사용할 수 있다.
이렇게 캐시에서 데이터를 제공하면 디스크 접근 횟수(Disk Access Count)가 줄어들고, 전체 읽기 성능(Read Performance)이 향상될 수 있다.
따라서 이번 실습은 같은 파일을 반복해서 읽을 때 캐시가 성능에 어떤 영향을 주는지 확인하는 예제이다. 이를 통해 디스크 접근은 항상 실제 디스크에서만 이루어지는 것이 아니라, 운영체제의 캐시 구조를 통해 더 빠르게 처리될 수 있다는 점을 이해할 수 있다.
운영체제 캐시(OS Cache)는 한 번 읽은 데이터를 메모리에 보관해두었다가 같은 데이터가 다시 요청될 때 빠르게 제공한다.
다만 실습 결과는 실행 환경에 따라 달라질 수 있다. 이미 파일이 캐시에 올라와 있다면 첫 번째 실행부터 빠르게 측정될 수 있고, 시스템의 메모리 상태나 다른 작업에 따라 결과가 달라질 수 있다.
이번 실습은 캐시(Cache)가 디스크 접근 성능(Disk Access Performance)에 어떤 영향을 주는지 확인하는 내용이다.
같은 파일(File)을 반복해서 읽을 때, 매번 수행 시간이 동일하지 않을 수 있다. 그 이유는 운영체제(Operating System)가 디스크(Disk)에서 읽은 데이터를 메모리(Memory)에 캐시 형태로 저장해둘 수 있기 때문이다.
첫 번째 접근에서는 실제 디스크에서 데이터를 읽어야 하므로 시간이 더 걸릴 수 있다. 하지만 이후 같은 데이터를 다시 요청하면, 운영체제가 디스크에 다시 접근하지 않고 메모리에 저장된 캐시 데이터를 사용할 수 있다.
이렇게 캐시에서 데이터를 제공하면 디스크 접근 횟수(Disk Access Count)가 줄어들고, 전체 읽기 성능(Read Performance)이 향상될 수 있다.
따라서 이번 실습은 같은 파일을 반복해서 읽을 때 캐시가 성능에 어떤 영향을 주는지 확인하는 예제이다. 이를 통해 디스크 접근은 항상 실제 디스크에서만 이루어지는 것이 아니라, 운영체제의 캐시 구조를 통해 더 빠르게 처리될 수 있다는 점을 이해할 수 있다.
운영체제 캐시(OS Cache)는 한 번 읽은 데이터를 메모리에 보관해두었다가 같은 데이터가 다시 요청될 때 빠르게 제공한다.
다만 실습 결과는 실행 환경에 따라 달라질 수 있다. 이미 파일이 캐시에 올라와 있다면 첫 번째 실행부터 빠르게 측정될 수 있고, 시스템의 메모리 상태나 다른 작업에 따라 결과가 달라질 수 있다.
캐시(Cache)는 디스크에서 읽은 데이터를 운영체제(Operating System)가 메모리(Memory)에 임시로 저장해두는 방식이다. 이후 동일한 데이터를 다시 읽으면 디스크(Disk)에 다시 접근하지 않고, 메모리 캐시에서 바로 가져올 수 있다.
즉, 느린 저장장치(Storage Device) 대신 빠른 메모리를 활용하여 처리 시간을 줄이는 방식이다. 같은 데이터에 대한 반복 접근이 많을수록 캐시 사용 여부에 따라 성능 차이가 크게 나타날 수 있다.
사진에 포함된 코드는 동일한 파일(File)을 두 번 읽으면서 캐시 효과를 확인하기 위한 핵심 코드이다.
먼저 make_test_file(filename)을 통해 실험에 사용할 테스트 파일(Test File)을 생성한다. 충분한 크기의 파일을 만들어 실제 읽기 동작을 측정할 수 있도록 준비하는 과정이다.
그다음 첫 번째 read(fd, buf, SIZE)를 수행하면 파일의 데이터를 읽는다. 이때 데이터는 실제 디스크에서 읽혀올 수 있으며, 운영체제는 읽은 데이터를 메모리 캐시에 함께 저장할 수 있다.
이후 lseek(fd, 0, SEEK_SET)을 실행하면 파일 오프셋(Offset)을 다시 처음 위치로 이동시킨다. 즉, 같은 데이터를 다시 읽기 위해 시작 위치를 재설정하는 과정이다.
마지막으로 두 번째 read(fd, buf, SIZE)를 수행하면 동일한 데이터를 다시 읽는다. 이때 이미 데이터가 메모리 캐시에 존재한다면, 디스크에 다시 접근하지 않고 더 빠르게 처리될 수 있다.
따라서 첫 번째 읽기 시간과 두 번째 읽기 시간을 비교하면, 캐시가 디스크 접근 성능(Disk Access Performance)에 어떤 영향을 주는지 확인할 수 있다.
캐시 효과는 실행 환경에 따라 다르게 나타날 수 있다. 이미 파일이 캐시에 올라와 있으면 첫 번째 읽기부터 빠르게 측정될 수 있고, 시스템 메모리 상태에 따라 결과가 달라질 수 있다.
위 코드는 동일한 파일(File)을 두 번 읽어서 첫 번째 읽기 시간과 두 번째 읽기 시간을 비교하는 예제이다. 이를 통해 운영체제 캐시(OS Cache)가 파일 읽기 성능에 어떤 영향을 주는지 확인할 수 있다.
먼저 상수 정의 부분에서는 읽기 크기(Size), 반복 횟수(Repeat Count), 파일 크기(File Size)가 설정된다. 이후 make_test_file() 함수를 이용해 실험에 사용할 테스트 파일(Test File)을 생성한다.
make_test_file()에서는 open()으로 파일을 열고, write()를 이용해 약 2MB 크기의 데이터를 파일에 기록한다. 즉, 캐시 효과(Cache Effect)를 측정할 수 있도록 실험용 데이터를 미리 준비하는 과정이다.
그다음 main() 함수에서는 생성된 파일을 읽기 전용(Read Only)으로 연다. 이후 첫 번째 읽기 시간을 측정한다. 반복문 안에서 read()를 여러 번 수행하면서 파일 내용을 순차적으로 읽어오는데, 이 첫 번째 읽기에는 실제 디스크 접근(Disk Access)이 포함될 수 있기 때문에 상대적으로 시간이 더 걸릴 수 있다.
첫 번째 읽기가 끝난 뒤에는 lseek(fd, 0, SEEK_SET)을 사용해 파일 위치를 다시 처음으로 이동한다. 이는 동일한 파일을 처음부터 다시 읽을 수 있도록 오프셋(Offset)을 재설정하는 과정이다.
그다음 두 번째 읽기에서도 같은 방식으로 read()를 반복 수행하고 시간을 다시 측정한다. 이때 첫 번째 읽기에서 사용된 데이터가 운영체제의 메모리 캐시(Memory Cache)에 남아 있다면, 두 번째 읽기는 디스크에 다시 접근하지 않고 더 빠르게 처리될 수 있다.
마지막으로 첫 번째 읽기 시간(First Read Time)과 두 번째 읽기 시간(Second Read Time)을 출력하여 캐시 효과를 비교한다.
정리하면, 이 코드는 같은 파일을 반복해서 읽을 때 첫 번째 읽기보다 두 번째 읽기가 더 빨라질 수 있음을 확인하는 예제이다. 이는 운영체제가 한 번 읽은 데이터를 메모리에 캐시해두고, 이후 같은 데이터 요청이 들어오면 디스크 대신 캐시에서 빠르게 제공할 수 있기 때문이다.
이 실습 결과는 실행 환경에 따라 달라질 수 있다. 파일이 이미 운영체제 캐시에 올라와 있다면 첫 번째 읽기도 빠르게 측정될 수 있고, 메모리 상태나 백그라운드 작업에 따라 시간 차이가 작게 나타날 수도 있다.
또한 clock()은 프로그램이 사용한 CPU 시간(CPU Time)을 측정하는 함수이기 때문에, 실제 디스크 입출력 시간(Wall-Clock Time)을 정확히 비교하려면 환경에 따라 clock_gettime() 같은 함수를 사용하는 것이 더 적절할 수 있다.
실행 결과를 보면 첫 번째 읽기(First Read)는 0.004821초, 두 번째 읽기(Second Read)는 0.001237초로 측정되었다. 즉, 두 번째 읽기가 첫 번째 읽기보다 더 빠르게 수행된 것을 확인할 수 있다.
그 이유는 첫 번째 읽기 과정에서 사용된 데이터가 운영체제(Operating System)의 메모리 캐시(Memory Cache)에 저장되었기 때문이다. 이후 같은 데이터를 다시 읽을 때는 디스크(Disk)에 직접 접근하지 않고, 메모리에 저장된 캐시(Cache)를 통해 더 빠르게 데이터를 가져올 수 있다.
따라서 운영체제는 반복적으로 사용되는 데이터에 대해 디스크 접근 횟수(Disk Access Count)를 줄이고, 전체 입출력 성능(I/O Performance)을 개선할 수 있다.
다만 캐시 상태(Cache State), 시스템 상황(System Condition), 백그라운드 작업(Background Process)에 따라 실행 시간은 달라질 수 있다. 따라서 중요한 것은 정확한 시간 값 자체보다, 첫 번째 읽기와 두 번째 읽기 사이에서 캐시 효과가 나타날 수 있다는 점을 이해하는 것이다.
이번 실습에서는 순차 접근(Sequential Access)과 랜덤 접근(Random Access)의 차이, 디스크 스케줄링(Disk Scheduling), 버퍼링(Buffering), 캐시(Cache)의 효과가 실제 시스템에서 어떻게 나타나는지 확인하는 것이 핵심이다.
캐시 효과는 항상 같은 크기로 나타나는 것은 아니다. 이미 파일이 캐시에 올라와 있거나, 시스템 메모리 상태가 달라지면 첫 번째 읽기와 두 번째 읽기의 시간 차이가 작게 나타날 수도 있다.
이 실습을 통해 순차 접근 시간이 랜덤 접근 시간보다 더 빠르게 측정되는 것을 확인하였다. 이는 순차 접근이 연속된 데이터를 차례대로 읽는 방식이기 때문에, 랜덤 접근보다 디스크 접근 비용이 상대적으로 적기 때문이다.
디스크 스케줄링 시뮬레이션(Disk Scheduling Simulation)은 같은 디스크 요청 목록(Request Queue)을 FCFS, SSTF 같은 알고리즘으로 처리했을 때 총 헤드 이동 거리(Total Head Movement)가 얼마나 달라지는지 확인하기 위한 코드였다.
실습을 통해 순서대로 처리하는 FCFS 보다는 가까운 작업을 먼저 처리하는 SSTF의 이동거리가 더 짧았다. 이로 인해 디스크 스케줄링이 탐색 시간(Seek Time)을 줄이는 데 어떤 영향을 주는지 볼 수 있었다.
버퍼링 코드(Buffering Code)는 write()만 사용할 때와 매번 fsync()를 사용할 때의 시간을 비교해서, 버퍼링(Buffering)이 쓰기 성능(Write Performance)에 어떤 영향을 주는지 확인하는 코드였다. 즉, 디스크 성능 전체라기보다는 디스크 쓰기 성능과 안정성 사이의 트레이드오프(Trade-off)를 확인하는 실습이었다.
여러 쓰기 요청을 메모리에 모아두었다가 나중에 처리할 수 있기 때문에 버퍼링을 사용한 코드가 더 빨랐다. fsync 사용이 더 느린이유는 매번 실제 디스크 기록을 강제하기 때문에 대기 시간이 증가하기 때문이다.
캐시 코드(Cache Code)는 같은 파일을 두 번 읽었을 때 첫 번째 읽기와 두 번째 읽기 시간이 어떻게 달라지는지 비교해서, 운영체제 캐시(OS Cache)가 읽기 성능(Read Performance)에 어떤 영향을 주는지 확인하는 코드였다. 즉, 반복 읽기에서 디스크 접근 횟수(Disk Access Count)를 줄여 성능이 좋아질 수 있음을 확인하는 실습이다.
이 실습을 통해 동일한 파일을 반복해서 읽을 경우, 두 번째 읽기가 더 빠르게 수행될 수 있음을 확인하였다. 이는 운영체제가 첫 번째 읽기 데이터를 메모리 캐시에 저장해두고, 이후 같은 데이터를 다시 요청할 때 디스크 접근을 줄일 수 있기 때문이다.