Tech Log 🛠️

메모리 계층 구조 

메모리는 다음과 같이 계층 구조로 구성되어있다. 일반적으로 상위 계층으로 갈수록 속도는 빨라지는 대신 가격은 비싸진다.

속도가 빠른 캐시나 레지스터에 모든 프로세스를 저장해놓으면 좋겠지만 그러지 못하는 이유가 경제성 때문이다.

따라서 느린 저장장치에 데이터를 저장해놓고 빠른 장치는 필요할 때마다 데이터를 불러와서 처리하는데, 메모리와 CPU 사이의 속도 차이가 너무 크기 때문에 중간에 레지스터 계층과 캐시 계층을 두어서 관리한다.

캐시

위에서 말했던 것처럼 캐시는 필요한 데이터를 보관하는 임시 저장소이자 병목 현상을 줄이기 위한 메모리이다.

캐시를 통해 CPU의 연산 속도와 메모리 접근 속도의 차이를 완화할 수 있다.

계층적 캐시 메모리

메모리 구조가 그랬던 것 처럼 캐시 메모리 또한 캐시를 계층적으로 관리한다.

일반적으로 L1, L2 캐시는 CPU 코어 내부에 위치하며 L3는 CPU가 아닌 메인보드에 위치한다.

참조 지역성의 원리

필요한 데이터가 캐시에 있는 경우를 캐시 히트라고 하고 없는 경우를 캐시 미스라고 한다. 당연히 캐시 히트가 많이 일어나는 것이 좋은 건데, 적중률을 높이기 위해 지역성의 원리가 사용된다.

*캐시 히트는 CPU 내부 버스를 사용하고 캐시 미스는 시스템 버스를 사용한다. (당연히 CPU 내부 버스가 더 빠르다!)

지역성은 두가지로 구분된다. 예시 코드와 함께 보면 이해가 쉽다.

List<Integer> list = new ArrayList<>();

for(int i=0;i<10;i++) {
	list.add(i);
}

시간 지역성

- CPU는 최근에 사용했던 메모리 공간에 다시 접근하는 경향이 있다.

- 예시 코드에서 변수 i에 대해서 계속해서 접근이 이루어지고 있다.

참조 지역성

- CPU는 최근에 사용했던 메모리 공간 근처를 접근하는 경향이 있다.

- 예시 코드에서 list 공간에 계속해서 접근하고 있다.

캐시 매핑

캐시 메모리는 매우 작고 주 메모리를 크기 때문에 캐시를 어떻게 매핑하느냐가 매우 중요하다. 또한 CPU에서 캐시를 탐색할 때 효율적으로 탐색을 할 수 있어야한다.

직접 매핑

- 메모리가 1~100이 있고 캐시가 1~10이 있다면 1:1~10 , 2: 11:~20 .. 같은 방식으로 저장한다.

- 구현이 간단하고 처리가 빠르지만 충돌(스와핑)이 잦다.

연관 매핑

- 순서와 블록 상관없이 자유롭게 매핑을 할 수 있다.

- 충돌은 덜 일어나지만 모든 블록을 탐색해야하므로 속도가 상대적으로 느리다.

집합 연관 매핑

- 직접 매핑과 연관 매핑의 절충안이다.

- 정해진 장소(직접 매핑) 내에 어느 장소에나(연관 매핑) 매핑이 가능하다.

- 직접 매핑에 비해 저장이 빠르고 연관 매핑보다 검색이 빠르다. 

캐시와 레지스터의 차이

레지스터는 CPU 내에서 연산을 처리하기 위해 데이터를 저장하는 메모리이며, 캐시는 메인 메모리와 CPU 간의 속도 차이를 극복하기 위한 메모리이다.

레지스터는 CPU 내부에 위치해 있으며 캐시는 CPU와는 별도로 존재한다. 

CISC란?

CISC(Complex Instruction Set Computer)란 많은 수의 다양하고 중복되는 명령어 집합이다.

*명령어 집합:CPU가 이해할 수 있는 명령어들의 모음

사용자가 이해할 수 있는(고급 언어) 하나에 각기 다른 기계 명령어를 대입 시킴으로써 명령어수가 많고 가변 길이를 가진다.

명령어 수가 많고 상대적으로 적은 수의 명령어로도 프로그램을 실행할 수 있다. (메모리 사용이 적다.)

CISC의 명령이의 길이가 고정되어 있지 않은 이유는 각각의 명령어가 프로세싱 성능을 극대화하도 록 설계되었기 때문이다.

하지만 명령어의 수가 많다고 하더라고 실제로는 쓰이는 명령어들만 주로 쓰이고 명령어를 사용해서 메모리 파이프라이닝이 불리하다는 단점이 있다. 또한 상대적으로 많은 전력을 소모한다.

특징

1. 강력한 기능을 수행하는 다양한 명령어들이 있다.

2. 상대적으로 메모리를 적게 소비한다.

4. 가변 길이 명령어를 사용한다.

5. 명령어가 실행되는 데 하나 이상의 클럭 주기를 가진다.

6. 다양한 주소 지정 방식을 사용한다.

7. 컴파일 과정이 쉽고 호한성이 좋다.

단점

1. 명령어 실행 시간이 파이프라인을 만들기에 불리하다.

2. 상대적으로 많은 전력을 소비한다.

RISC란?

RISC(Reduced Instruction Set Computer)란 축소된 명령어의 집합이다.

CISC와는 여러 차이점이 있는데 대표적으로 명령어의 수가 100개 미만으로 줄어들었다. 인식 가능한 명령어의 수를 줄임으로써 속도를 향상시키지만 프로그램을 실행 시키는데 더 많은 명령어가 필요하다.

RISC는 신속한 프로세싱을 달성하기 위한 파이프라인 프로세싱의 일환으로서 고정길이 명령어를 사용하며,CISC와 달리 클럭 주기당 하나의 명령어를 실행한다. 단일 사이클의 명령어를 실행함으로써 명령어 실행 과정을 파이프라인으로 구현할 수 있다. 

특징

1. 모든 데이터 처리는 레지스터에서 수행되며 load-store 구조를 사용하여 메모리 접근을 최소화하였다.

2. 단순한 고정 길이 방식의 명령어를 사용한다.

3. 적은 주소 지정 방식을 사용한다.

단점 

1. 컴파일러의 최적화 과정이 복잡하다.

2. 명령어가 고정되어 있어서 코드 효율이 낮다.

3. 파이프라인 해저드에 대한 조치가 필요하다.

결론

둘 다 장단점을 보유하고 있어서 어느 쪽이 성능 면에서 우세하다고 볼 수는 없다. 

또한 오늘날의 몇몇 CISC MCU는 RISC의 장점을 일 부 공유하고 있으며, 몇몇 RISC MCU는 CISC의 장점 을 일부 공유하고 있기 때문에 각자의 상황에 맞는 선택이 필요하다.

커널이란?

커널이란 운영체제 내부에서 자원들을 관리하고 추상화 해준다. 이 덕분에 사용자는 내부 하드웨어에 직접 접근하지 않고도 간편하게 프로그램을 실행할 수 있다. 여기서 자원은 CPU, 메모리 , 입출력 장치 같은 것들을 나타낸다.

또한 커널은 자원을 관리하기 위한 여러 관리자들이 있다.

1. 테스트 관리자 : 물리적 자원인 CPU를 추상 자원인 테스크로 제공한다.
2. 메모리 관리자 : 물리적 자원인 메모리를 추상 자원인 페이지나 세그먼트로 제공한다.
3. 파일 시스템 관리자 : 물리적 자원인 디스크를 추상 자원인 파일로 제공한다.
4. 네트워크 관리자 : 물리적 자원인 네트워크 장치를 추상 자원인 소켓으로 제공한다.
5. 디바이스 드라이버 관리자 : 각종 외부 장치(프린터, GPU 등)에 대한 접근을 제공한다.

커널의 동작 방식

커널은 Memory Resident 한 프로그램이다. 일반적으로 프로그램들은 디스크에 상주해있는데, 커널은 메모리에서 여러 명령들을 처리한다. 

하지만 커널은 사용자의 명령을 직접적으로 받지 않고 쉘이란 프로그램을 통해서 명령을 전달받는다. 즉 쉘을 통해서 커널에게 명령을 내릴 수 있는 것이다.

쉘의 역할

프로그램들이 언제 메모리에 로딩되고 해제되는지 관리해주는 프로그램이다. 여러 프로그램들의 메모리를 관리해주며 커널의 중간다리 역할을 수행하기도 한다.

일반적으로 운영체제가 부팅되면 Memory Resident한 특성을 가지는 커널이 먼저 메모리에 올라온다.

그 후 유저가 터미널을 실행하면 쉘이 메모리에 올라오고 유저가 입력한 커맨드에 맞는 잡(job)을 메모리에 올린다.

이런 과정으로 유저는 프로그램을 내부적인 구조를 신경쓰지 않고 실행시킬 수 있는 것이다.

하지만 이런 리눅스 환경은 신경써야 할 점이 하나 있다. 바로 멀티유저 시스템이라는 점이다.

윈도우는 개인pc용 운영체제여서 보안에 대한 부담이 리눅스에 비해 적을 수 있지만, 여러 사용자가 이용하는 리눅스는 보안을 특별히 더 신경써야한다.

만약 유저A가 유저B의 파일에 맘대로 접근할 수 있다면 어떨까? 이는 심각한 문제를 초래할 수 있다. 

따라서 운영체제는 커널모드와 유저모드를 나누어서 입출력 작업 같이 자원에 접근하는 일들은 커널에서 담당하도록 하였다.

이때 커널에게 해당 작업을 요청하는 것을 시스템 콜이라고 한다.

유저 모드에서 시스템 콜이나 인터럽트가 발생하게 되면 커널 모드로 진입한다.

시스템 콜의 종류는 다음과 같은 역할들을 수행한다.

프로세스/스레드 관련 처리

파일 I/O 관련 처리

소켓 관련 처리

디바이스 관련 처리

프로세스 통신 관련 처리

물론 모든 커맨드에 대해서 시스템 콜이 커널로 명령을 전달해주면 이는 무용지물일 것이다. 그래서 해당 명령이 적합한 명령인지를 판단하는 바이너리 비트를 CPU에 두는데, 이를 mode bit라고 한다. 1이면 커널모드 0이면 유저모드라고 알려져있다.

커널모드에서는 모든 자원에 대한 접근이 가능한데 이때 I/O 같은 작업들을 수행하고 시스템 콜의 리턴값으로 해당 작업에 대한 결과를 받는다. 그리고 해당 작업이 종료되면 다시 유저모드로 돌아가서 프로그램을 실행한다. 이 작업이 한번만 진행되는 건 아니고 프로그램이 실행되면서 수없이 커널모드와 유저모드를 왔다갔다한다.

인터럽트란

앞서 인터럽트가 발생하였을 때 커널 모드로 진입한다고 하였다. 이 때 인터럽트는 무엇이고 왜 발생할까? 

인터럽트는 시스템에서 발생한 다양한 종류의 이벤트 혹은 그런 이벤트들이 발생했을 때 알려주는 메커니즘이다.

인터럽트들이 발생하면 CPU에서는 인터럽트 처리를 위해 커널 모드로 진입한다.

하드웨어 혹은 프로그램이 인터럽트 라인에 인터럽트를 세팅하면 인터럽트가 발생한다. 이때 인터럽트 벡터를 통해 인터럽트 서비스 루틴을 실행해서 인터럽트를 처리한다.

인터럽트 벡터

인터럽트 서비스 루틴(핸들러)의 주소를 담고 있는 테이블

인터럽트 서비스 루틴

실제 인터럽트를 처리하기 위한 루틴

참고로 프로그램 레벨에서 발생하는 인터럽트는 트랩이라고 불리며 하드웨어 인터럽트보다 우선 순위가 높다.

외부 인터럽트

전원에 문제가 생겼을 때

I/O 작업이 완료되었을 때

타이머 시간이 끝났을 때

내부 인터럽트

0으로 나눴을 때

잘못된 메모리 공간에 접근을 시도할 때

소프트웨어 인터럽트

프로그램 처리 중 명령의 요청에 의해 발생하는 데, 대표적으로 SVC에 의한 call이 있다.

인터럽트는 다음과 같은 우선 순위를 가진다.

1. 전원 이상(Power fail)
2. 기계 착오(Machine Check)
3. 외부 신호(External)
4. 입출력(I/O)
5. 명령어 잘못
6. 프로그램 검사(Program Check)
7. SVC(SuperVisor Call)

시스템 콜 & 인터럽트의 동작 과정(예시)

싱글 코어 환경에서 쓰레드1(t1)과 쓰레드2(t2)가 있다고 가정해보자

t1에서 file read 요청이 들어왔다.

이때 file read에 해당하는 시스템 콜이 호출되며 기존 t1의 상태를 저장하고 커널 모드로 진입한다.

커널모드에 진입한 t1은 해당 file이 read 가능한 상태가 될때까지 waiting 하게 되며 다시 유저 모드로 진입 후 t2가 실행되게 된다.

t1에서 요청한 file이 read 요청을 처리할 준비가 되었다.

이때는 아까와 다르게 시스템 콜이 아닌 인터럽트가 호출된다. 다시 CPU는 t2의 상태를 저장하고 t1을 waiting에서 ready(runnable)로 상태를 바꾼다. 그런 다음 유저모드로 진입 후에 t2를 실행한다.

모종의 이유로 t2의 CPU 점유가 중단되는 일이 생길 것이다.

CPU는 다시 커널 모드로 진입 후에 t2를 ready 상태로 바꾼다. 이제는 t1을 실행 상태로 바꾸고 작업들을 처리하면 된다.

하지만 사용자는 직접적으로 시스템 콜을 호출할 일이 없는데 이는 하이(high) 레벨 언어가 시스템 콜을 호출할 수 있도록 래핑(wrapping)을 통해 제공하기 때문이다. 대표적으로 스레드를 start 할 때 native 코드를 통해서 JNI(Java Native Interface)가 해당 운영체제에 맞는 시스템 콜을 호출해준다.

private native void start0();

가상메모리란?

프로그램을 시작하기 위해서는 프로그램이 메모리에 올라와야 하는데, 모든 프로그램을 올리기에는 메모리의 용량이 턱 없이 부족하다. 이때 필요한 것이 가상 메모리이다. 

가상 메모리는 컴퓨터가 이용 가능한 메모리 자원들을 추상화하는 것이라고 하는데, 이게 무슨 말일까?

CPU는 프로세스를 실행할 때 논리 주소(logical memory)를 바라본다.

이때 실제로 메모리에 있는 지 없는 지 상관없이, 가상 메모리를 통해서 논리 주소를 모두 프로세스에게 할당하여준다. 

이렇게 해주면 CPU 입장에서는 "모든 프로세스들이 메모리에 올라와 있네?" 라는 착각을 하게 되고 이를 메모리의 추상화라고 볼 수 있다.

(실제 메모리에 있는 없든 CPU 입장에선 알 필요 없다.)

가상 메모리가 필요한 이유

가상 메모리의 핵심은 프로세스의 일부분만 메모리에 올릴 수 있다는 것이다.

기존에는 프로세스를 실행시키기 위해서 메모리에 프로세스 전체를 올려야했다. 하지만 이러한 방식은 메모리의 용량이 부족하거나 다른 프로세스가 실행될 경우 빈번하게 스왑(swap) 요청이 반복된다는 문제가 있었으며, 메모리의 비효율성을 초래했다.

그렇기 때문에 가상 메모리에서는 요구페이징 기법을 사용하여 가상 메모리 공간을 페이지로 나누고 꼭 필요한 페이지들만 물리 메모리에 가져온다.

요구 페이징 기법이란

모든 프로세스를 메모리에 올려놓으면 메모리 관리가 힘들어지고 응답 시간이 느려진다는 단점이 있었다.

요구 페이징 기법은 이런 문제를 해결하기 위해 나온 것인데, 요구되는 프로세스의 일부만 메모리에 적재함으로써 기존 문제들을 완화시킬 수 있다.

만약 가상 메모리에서 4번 페이지를 요청했는데 page fault가 발생한 경우를 살펴보자.

현재 4번 페이지의 유효비트는 1(invalid)이다. 그렇다면 스왑 영역에서 가져와야하는데 이때 스와핑이 발생한다.

일단, 임의로 4번에 있는 페이지를 스왑 영역으로 방출(스왑 아웃)한다. 그러면 유효비트는 1에서 0이 되고 스왑 영역 내의 주소(6)가 들어가게 된다.

그 다음 스왑 영역의 1번에 해당하는 프로세스(E)가 물리메모리의 3번 프레임으로 올라가고 유효 비트는 1에서 0으로 바뀐다.

이처럼 유효비트가 1(메모리에 없음)일때는 주소 필드에 프레임 번호가 들어가고 0(메모리에 있음)일때는 메모리 주소가 들어간다.

그리고 예시에서는 임의로 페이지를 방출했지만, 실제로는 페이지가 꽉 찼을 경우 지역성을 고려해서 페이징 알고리즘을 설계한다.

가상 메모리의 동작 방식

필요성을 알았다면 기본적인 동작 방식을 다뤄보려고한다.

먼저 처음에는 CPU가 프로세스 요청을 하는 것부터 시작한다.

이때 바로 페이지 테이블로 가는 것이 아닌 캐싱 계층인 TLB를 방문한다. -> 여기에도 없으면 페이지 테이블로 간다.

하지만 물리 메모리 자체에 적제가 되어있지 않다면 페이지 폴트 현상이 발생한다.

메모리에 없는 프로세스마저 논리 주소를 할당하기 때문에 이 현상은 불가피하다. 

중요한 것은 페이지 폴트가 일어난 다음인데, 바로 스와핑을 통해 페이지 폴트를 대처할 수 있다.

스와핑이란 메모리에 없는 프로세스를 바로 디스크의 스왑 영역에서 가져옴으로써 빨리 메모리에 적재시키는 것이다.

스와핑이 자주 일어난다는 것은 좋은 현상이 아니다. 대표적인 문제가 *스레싱이다.

스와핑이 동시 다발적으로 발생하면 CPU 처리의 공백이 발생한다.

근데 운영체제는 이를 CPU가 놀고있다고 인식하고 더 많은 프로세스를 메모리에 올리는데 이러한 악순환의 반복으로 성능이 떨어지게된다.

스레싱 : 페이지 부재율(Page fault)이 증가하여 CPU 이용율이 급격하게 떨어지는 현상

스레싱 현상의 대표적인 해결법으로는 PFF(page fault frequency)를 사용하여 페이지 폴트의 상한선과 하한선을 정해줌으로써 최소한의 페이지 프레임 할당을 보장해주는 방식이 있다.

이 방식을 통해 페이지 폴트 빈도를 계산하여 페이지 폴트가 상한선보다 높으면 더 많은 프레임을 할당해주고 낮으면 할당한 프레임을 회수해줄 수 있다.

아니면 작업 집합 모델(Working Set)을 만들어서 가장 최근에 참조된 페이지들을 집합으로 관리할 수 있다.

이는 최근에 참조된 프레임들이 이후에도 또 참조될 것이라는 지역성에 기반한다.

가상 메모리의 장단점

장점

메모리 관리를 효율적으로 할 수 있다.

기존에는 프로세스 전체가 올라와야 했다면 페이지 테이블을 통해 꼭 필요한 페이지만 메모리에 올릴 수 있다.

또한 램+스왑 영역을 통해 비교적 넓은 영역에 메모리를 저장할 수 있어서 메모리 충돌 위험이 적고 메모리 관리가 비교적 단순해진다.

단점

페이지 폴트 현상이 빈번할 시 스레싱으로 인한 성능 저하가 발생하는 데 이를 완화하기 위한 추가 작업이 필요하다. ex) 페이징 알고리즘

결론

가상 메모리를 사용함으로써 꼭 필요한 프로세스들만 페이지 단위로 메모리에 올릴 수 있으며, 이를 통해 효과적으로 메모리를 관리할 수 있다.

CPU 입장에서는 이런 메모리의 추상화를 통해 모든 프로세스들을 자유롭게 요청할 수 있고 만약 메모리에 없더라도 스왑을 통해 바로 요청할 수 있다.

하지만 잦은 페이지 폴트로 인한 스레싱을 방지하기 위해 어떤 프로세스를 올리고 내릴 지에 대한 추가적인 페이징 알고리즘이 필요하다.

연속 메모리 할당이란

프로세스에 연속적으로 메모리를 할당하는 것이다. 매 시점 프로그램의 크기에 맞게 동적으로 메모리를 할당한다.

연속 메모리 할당의 종류로는 고정 분할 방식과 가변 분할 방식이 있다.

연속 메모리 할당의 원리

연속 메모리 할당에서는 메모리를 여러 분할로 나누어서 프로세스를 할당한다.

프로세스들을 할당할 때 적재될 공간을 찾아야하는데 이를 구현한 방법이 대표적으로 3가지가 있다.

 
최초 적합
메모리를 탐색하다가 프로세스를 적재할 수 있는 공간(hole)이 나오면 그 자리에 바로 배치하는 것이다.
 
최적 적합
빈 자리가 있다고 무조건 적재하는 것이 아니라 적재 가능한 가장 작은 공간에 프로세스를 할당한다.
 
최악 적합
촤적 적합과는 반대로 적재할 수 있는 가장 큰 공간에 프로세스를 적재하는 것이다.
 

연속 메모리 할당으로 인한 문제점

근데 문제는 위처럼 빈 공간에 메모리를 할당하는 것은 그렇게 효율적인 방법이 아니다.
그 이유는 외부 단편화, 내부 단편화 때문인데 두 개의 문제가 꽤 치명적이다.

먼저 고정 분할 방식에서 생기는 문제점은 외부 단편화 , 내부 단편화가 있다.

고정 분할 방식은 분할의 크기보다 프로세스의 크기가 커서 실행되지 못하는 문제가 발생하는데 이를 외부 단편화 라고한다.

또한 프로세스에 비해 큰 분할에 적재될 경우 해당 분할의 남은 메모리가 낭비되는 내부 단편화 문제도 발생한다. 이는 하나의 분할에는 하나의 프로세스만 들어가야 하기때문에 발생하는 문제이다.

이처럼 고정 분할 방식은 메모리를 고정시켜 놓고 시작하기 때문에 가변 분할 방식에 비해 융통성이 떨어진다.

하지만 가변 분할 방식도 문제가 없는 것은 아니다. 가변 분할 방식도 외부 단편화 문제를 가지고 있다.
메모리에 빈 공간이 20MB , 30MB가 있더라도 50MB는 할당이 불가능하다. 이 두개의 메모리는 나뉘어져 있기 때문이다.
이렇게 메모리가 할당되면서 생기는 애매하게 작은 빈공간들은 계륵같은 존재여서 결국엔 빈공간으로 남게 된다. 이 문제를 외부 단편화라고 한다.
 

 
단순한 해결 방법으로는 메모리 압축 방식이 있다. 하지만 이 방법은 좀 비효율적이다.
메모리를 압축하면서 오버헤드를 피할 수 없으며 그리고 메모리를 어떻게 압축할건지에 대한 효율적인 설계도 부담해야하기 때문에
현대에는 페이징이 대표적으로 사용되고 있다.
 

대표적인 해결 방법 - 페이징

지금까지 연속 메모리 할당은 여러 문제가 있다는 것을 살펴보았다.
그래서 운영체제가 선택한 방법은 가상 메모리를 이용한 페이징인데 페이징에 집중해서 알아볼 것이다.
https://cb036133.tistory.com/175

 
페이징은 근원적인 문제를 해결한다.
결국 외부 단편화가 발생하는 이유는 프로세스의 크기가 모두 달라서인데 그렇다면 프로세스의 크기를 일정하게 자르고 필요한 부분만 할당한다면 어떨까?
이렇게하면 낭비되는 메모리도 줄일수 있고 크기 큰 프로세스도 일정 부분만 올려서 실행시킬 수 있다.
 
이렇게 일정한 크기로 자른 단위를 페이지라고하며 메인 메모리에서는 프레임이라고 한다.
그리고 안쓰는 페이지들은 다시 스왑 영역으로 swap out 시킬 수 있다. 즉 모든 메모리가 메모리에 적재되어 있을 필요가 없다.
 
근데 페이지는 연속 메모리 할당과는 다르게 불연속적으로 할당된다. 그렇기 때문에 CPU는 페이지 테이블을 이용하여 페이지와 테이블을 매핑시킨다.(약간 네트워크의 라우팅 테이블과 같은 역할이다)
프로세스마다 있는 페이지 테이블을 이용해서 순차적으로 프레임에 접근할 수 있으며 CPU는 불연속 적으로 할당되었다는 것을 고려할 필요가 없다.

근데 프로세스마다 테이블이 있다면 CPU는 어떻게 이 테이블을 찾아갈 수 있는 걸까? 이 역할을 하는게 PTBR이다.

하지만 페이지 테이블이 따로 있다면 불필요하게 메모리에 두번 접근하게 된다. (페이지 테이블 1번 + 페이지 참조 1번)

따라서 TLB를 통해 페이지 테이블의 일부를 가져와서 저장하는 캐시이다. 이를 통해 불필요한 메모리 접근을 줄일 수 있다.
 
페이징 방식이 좋다고 한들 계속 스왑을 하게 되면 성능적으로 떨어질 수 밖에 없다. 이제 관건은 어떤 프로세스를 메모리에 올리느냐인데, 이것을 고민한 결과들이 페이지 교체 알고리즘이다.
 
페이지 교체 알고리즘의 종류
 
오프라인 알고리즘(LFD)
가장 먼 미래에 참조되는 페이지와 현재 할당하는 페이지를 바꾸는 것이다.
오프라인 알고리즘은 가장 이상적인 알고리즘이지만 실현 가능성이 거의 없다. 유저의 미래 행동을 예측할 수 없기 때문이다.
하지만 현재 페이지 테이블에서 나올 수 있는 성능의 이상적인 척도(상한선)를 제공해준다. 
 
직관적으로 생각하면 가장 나중에 사용되는 페이지를 버린다고 볼 수 있다.

FIFO
먼저 온 페이지를 가장 먼저 교체한다.

특이하게도 FIFO의 경우 페이지의 수를 늘리게 되면 페이지 폴트가 더 자주 발생한다.(벨레이디의 모순)

 
LRU
참조가 가장 오래돤 페이지를 바꾼다. 이 방식을 구현하기 위해서는 각 페이지마다 카운터와 스택을 두어야한다.
 

LFU
가장 참조 횟수가 적은 페이지를 교체한다.

NUR (클럭 알고리즘)
0과 1을 가진 비트를 두고 시계 방향으로 돌면서 0을 찾은 순간 프로세스를 교체하는 것이다. 여기서 0은 참조되지 않았다는 뜻이다.

하지만 참조 시점이 가장 오래되었다는 것을 보장하지는 않는다. 프로세스를 교체하면 해당 부분은 1로 바꾼다.

1. 데드락이란?

데드락이란 두개 이상의 프로세스 혹은 스레드가 서로가 가진 리소스를 기다리는 상태이다.

이런 상태가 발생하면 서로가 원하는 자원을 얻지 못해서 처리 상태가 마비되는 현상이 발생한다.

멀티 프로세스/스레드 환경 , 레이스 컨디션 환경에서 발생하며 여러 조건이 복합적으로 작용해서 데드락이 발생한다.

2. 데드락이 발생하는 이유

앞서 데드락은 여러 조건이 복합적으로 작용해야한다고 하였다. 그 조건은 크게 4가지가 있다.

1. 상호배제(Mutual Exclusion)

레이스 컨디션 환경에서 공유 자원들을 공유해서 사용할 수 없기 때문에 발생한다.

예를 들어, 차량들이 차선들을 공유해서 사용하게 된다면 이는 곧 교통사고로 이루어진다.

이 조건은 당연히 보장되어야되는 것이다.

2. 점유 대기 (Hold and Wait)

프로세스가 이미 하나 이상의 리소스를 취득한 상태에서 다른 프로세스가 사용하고 있는 리소스를 추가로 기다리는 것이다.

점유(Hold)한 상태로 다른 리소스를 대기(wait) 한다는 개념이다.

차량이 1차선을 점유하고 있는 상황에서 2차선까지 점유해야한다면, 그 동안은 다른 차량들이 1차선을 점유하지 못할 것이다.

하지만 어떤 차량이 꼭 1차선에 가야한다면 이는 곧 처리가 마비되는 데드락을 유발할 수 있다.

3. 비선점

다른 프로세스나 스레드나 CPU 자원을 임의로 가져올 수 있다. 즉 현재 자원(리소스)을 점유하고 있는 자만이 리소스를 반환할 수 있다.

2차선에 있는 차량이 1차선에 있는 차량을 억지로 끌어내려서 점유할 수 없는 것과 같은 개념이다.

4. 순환 대기

말 그대로 서로가 서로의 자원을 기다리고 있는 것이다.

이 4가지 조건이 충족되어야 데드락이 발생한다고 할 수 있다!

3. 데드락 해결 전략

데드락 방지

4가지 조건으로 인해 데드락이 발생한다면, 역발상으로 4가지 상황이 충족되지 않게 시스템을 디자인하는 것이다.

첫번째로 리소스를 공유 가능하게 하는 방법이 있다.

하지만 이 방법은 애초에 현실 가능성이 없다. 왜냐하면 레이스 컨디션 환경에서 자원을 공유한다는 거는 매우 위험하기 때문이다.

또한 IO 관련 리소스들은 애초에 동시에 실행될 수가 없기 때문에 현실 가능성이 없다고 할 수 있다.

두번째로는 점유 대기 상태를 만들지 않는 것이다.

자원을 점유한 상태에서 다른 자원을 대기하면서 문제가 되는 것이라면, 애초에 모든 자원을 점유한 상태에서만 실행하게끔 하여서

해당 상태를 만들지 않으면 된다. 즉 "hold(점유)한 채로 wait(대기)하지마!" 방식의 해결 방법이다.

세번째는 대기 상태에서 자원을 양보하도록 하는 것이다.

만약 어떤 프로세스가 자원을 점유한 상태에서 다른 자원을 기다리고 있는 상태라면, 현재 점유하고 있는 자원을 다른 프로세스에게 양보할 수 있다.

이는 락을 자발적으로 반환하는 모니터 방식과 유사하다.

https://cb036133.tistory.com/178

네번째는 모든 리소스에 순서체계를 부여해서 오름차순으로 리소스를 요청하는 것이다.

만약 4번 리소스를 점유했다면 다음 리소스는 4번 리소스보다 큰 리소스를 점유해야한다.

이렇게 함으로써 순환 참조를 없앨 수 있다.

데드락 회피

데드락이 발생할 것 같은 상황 자체를 회피하는 것이다. 이를 위한 대표적인 알고리즘으로 은행원 알고리즘이 있다.

은행원 알고리즘이란, 총 자원의 양과 현재 할당한 자원의 양을 기준으로 안정 또는 불안정 상태로 나누고 안정 상태를 유지하도록 자원을 할당하는 알고리즘이다.

안정 상태: 데드락이 발생하지 않았고 프로세스의 최대 자원 요구량을 운영체제가 충족시킬 수 있는 상태

데드락 감지와 복구

우선 데드락을 허용해주고 데드락이 발생한다면 복구한다.

복구 전략은 크게 2가지이다.

먼저 데드락이 걸린 프로세스들을 종료시키는 것이다.

이때 프로세스들을 하나씩 종료시키거나, 모두 한꺼번에 종료시킬 수도 있지만 이 방법은 최후의 방법이다. 

이렇게 강제 종료를 하게 되면 그동안의 진행 상황을 잃게 되는 리스크를 감내해야 하기 때문이다.

그리고 다른 방법은 일시적으로 선점을 허용해주는 것이다.

이렇게 함으로써 꽁꽁 묶여있던 프로세스/스레드 들이 그나마 진행될 수 있다.

데드락 무시

말 그대로 데드락이 일어나던 말건 신경 안쓰는 것이다. 꽤 많은 운영체제에서 해당 방식을 사용하고 있다.

왜냐하면 데드락은 매우 드물게 일어나기 때문에 이를 처리하는 비용이 더 크기 때문이다.

사실 현실에서도 컴퓨터가 멈추면 대부분의 사용자들은 껐다 킨다.

모니터란?

모니터는 스레드가 mutex를 보장할 수 있도록 하는 동기화 메커니즘이다.

조건에 따라서 스레드를 waiting 상태로 전환시키는데 이를 cooperation이라고 한다.

mutex - 락을 가지고 있는 스레드만이 임계 영역에 들어갈 수 있고 메소드를 실행할 수 있다.

모니터의 작동 방식

모니터는 크게 두가지의 구성 요소로 이루어져 있다.

뮤텍스

mutual exclusion을 보장하는 장치이다. 락을 가지지 못한 스레드는 뮤텍스에서 관리하는 엔트리 큐에 들어간다.

condition variable

wating queue를 이용해 조건이 충족되지 않은 스레드들이 대기 상태로 머물 수 있도록한다.

만약 스레드의 조건이 충족되었을 경우 스레드를 깨우는 작업이 필요한데 이러한 메커니즘으로 인해 3개의 동작(상태)를 가진다.

1. wait - 스레드가 자신을 cv(condition variable)의 waiting 큐에 넣고 대기(wait) 상태로 전환한다.

2. signal - wating 큐에서 대기 중인 스레드 중 하나를 깨운다. 

3. broadcast - wating 큐에서 대기 중인 모든 스레드를 깨운다.

모니터에는 두 개의 큐가 존재한다.

엔트리 큐 - 임계영역 (critical section)에 진입을 기다리는 큐 -> 뮤텍스가 관리한다.

waiting 큐 - 조건이 충족되길 기다리는 큐 -> cv가 관리한다.

signal and continue

시그널을 주고 기존 스레드가 중단되지 않는다.

signal and wait

시그널을 주고 기존 스레드는 대기 상태에 들어가며 다시 락을 얻으면 깨어난다.

자바에서의 모니터

모든 자바 객체는 기본적으로 내부에 모니터를 하나씩 가지고 있다.

그리고 이것은 synchronized 키워드를 통해서 사용할 수 있다.

*자바의 모니터는 cv를 하나만 가진다.

그리고 자바의 모니터도 세가지 상태가 있는데, 용어만 살짝 다를 뿐 기능은 같다.

스케줄링이란?

CPU 버스트*를 고려하여 운영체제가 공정하고 합리적으로 CPU 자원을 분배하는 것이다.

CPU 버스트: CPU를 사용하는 구간

스케줄링을 사용하는 이유

스케줄링의 주요 목적은 멀티 프로그래밍 환경에서 CPU의 유휴(idle) 시간을 최소화하여 CPU의 이용률을 최대하하는 것에 있다.

물론 아무 프로세스나 랜덤으로 넣어서는 안되고 프로세스들의 여러 조건들을 고려해서 어떤 것부터 처리할 지 결정한다.

한가지 예를 들어보자

입출력 작업이 많은 프로세스와 CPU 사용이 많은 프로세스가 있다. 이 둘 중 어떤 것을 먼저 처리해야 될까?

이 경우 일반적으로 입출력 작업이 우선 순위를 가진다. 

왜냐하면, 입출력 작업을 먼저 빨리 끝마친 뒤에 CPU 사용이 많은 프로세스에게 많은 CPU 자원을 할당해줄 수 있기 때문이다.

CPU 스케줄링은 이처럼 중요성과 우선 순위를 고려해서 프로세스들에게 자원을 할당해준다.

만약 무조건 먼저 요청한 순서대로 처리한다면, 당장 급한 프로세스가 실행되지 않고 별로 급하지 않은 프로세스들만 실행될 수 있다.

이는 곧 전체 성능의 저하를 초래하기 때문에 적절한 스케줄링 규칙은 필수로 요구된다.

스케줄링 동작 방식

앞에서 스케줄링을 시에 CPU 버스트를 고려하여서 우선 순위를 책정한다고 하였다.

이러한 우선 순위 정보들은 PCB 라는 곳에 저장되어 있는데, CPU 입장에서 PCB를 일일이 뒤져서 스케줄링을 하는 것은 여간 번거로운 일이 아닐 것이다.

따라서 이때 사용하는 것이 스케줄링 큐인데 이 큐를 이용하여서 프로세스들의 대기열을 관리할 수 있다.

스케줄링 큐는 대표적으로 두가지가 있다.

- 준비큐(ready queue)

메인 메모리에 상주하면서 CPU를 할당받아서 실행될 준비가 된 프로세스 집합이다. 즉, 스케줄러에게 선택되어 CPU에 올라가기를 기다리는 프로세스들의 집합이다.

- 대기큐(wait,device queue)

입출력 작업이 필요하지만 지금 당장 CPU를 사용하지 않는 장치들이 대기하고 있는 프로세스들의 집합이다.

예를 들어 프로세스가 디스크에 입출력 요청을 했다고 가정했을 시에 디스크는 여러 요청을 처리하느라 지연이 발생할 수 있다.

이때 CPU를 사용하지도 않는 프로세스가 CPU 자원을 받는 것은 비효율 적이기 때문에 대기큐로 빠지게 된다.

이렇게 큐에 프로세스들이 쌓이는 것을 알았다면 어떻게 프로세스를 선점하는 지를 알아보자

그 전에 스케줄링 디스패처의 구조를 알 필요가 있다.

대게 스케줄러와 디스패처를 같은 범주로 묶어서 말한다. 하지만 둘의 역할은 명확한 차이가 있다.

프로세스의 상태 변화로 인해 프로세스가 비어있게 되면 어느 프로세스를 CPU로 가져올지에 대한 작업이 이루어진다.

이 과정은 스케줄러가 담당한다.

스케줄러는 앞에서 배웠던 준비 큐에서 우선 순위에 따라 프로세스를 선택하고 실행한다.

디스패처는 이렇게 선택된 프로세스가 실제로 CPU에서 실행될 수 있도록한다.

선택 된 프로세스로 컨텍스트 스위칭을 해주며 이 작업을 위해 커널모드로 진입했다가 다시 프로세스 실행을 위해 유저 모드로 전환한다.

그리고 새로운 프로세스의 마지막 작업 상태를 불러오고 적절한 위치로 이동시켜준다.

그렇다면 "어떻게 CPU를 선점할 것인가?" 에 대한 고민이 필요한데 크게 선점형 , 비선점형 방식이 있다.

비선점형

실행 상태에서 프로세스의 자발적인 상태 변경으로 인한 스케줄링이 일어나는 것을 말한다.

1. IO request : 발생 시

2. terminate 발생 시 : 실행하던 프로세스가 끝났을 경우

비선점형 방식은 상호 협력적(다른 프로세스를 위해 양보하는 경우)이라는 장점이 있는 반면에 느린 응답 시간*이라는 단점이 있다.

모든 프로세스를 공정하게 처리한다.

Response time(응답 시간): ready 큐에 들어와서 처음으로 CPU(최초로)를 얻기까지 걸린 시간

선점형

프로세스가 끝나지 않았음에도 운영체제가 개입할 수 있다.

1. interrupt 발생 시 : 외부에서 인터럽트가 들어온 경우

2. IO request : 발생 시

3. time-out 발생 시 : time slicing (시분할) 에 의해, 주어진 시간이 끝났을 경우

4. wake-up 발생 시 : 대기 큐에 있는 프로세스들을 준비 큐에 옮길때

5. terminate 발생 시 : 실행하던 프로세스가 끝났을 경우

기본적으로 비선점형에서 하는 방식을 모두 사용하지만 운영체제가 적극적으로 스케줄링에 개입한다.

이로 인해 데이터 일관성 문제가 발생하기도 한다. -> 이것을 방지하기 위해 뮤텍스 , 세마포어 기술 적용

외부 인터럽트를 허용한다! 하지만 잦은 컨텍스트 스위칭으로 인해 오버헤드가 발생할 수 있다.

또한 우선 순위로 프로세스를 처리하기 때문에 우선 순위가 낮은 프로세스들은 CPU를 할당받지 못할 수 있다. (기아 현상)

이제 마지막으로 스케줄러가 어떤 알고리즘으로 큐에서 가져오는 지 알아보자

여러가지가 있지만 대표적으로 7가지만 추려보았다.

스케줄링 알고리즘

- FCFS

준비큐에 먼저 도착한 순서대로 처리한다.

프로세스들이 기다리는 시간이 매우 길어질 수 있다.

Convoy effect 현상이 발생할 수 있다. 

 Convoy effect: 실행 시간이 긴 프로세스로 인해 뒤에 있는 프로세스들의 대기시간이 길어지는 현상

- SJF(Shortest job first)

프로세스의 CPU 버스트가 가장 짧은 순서대로 실행한다.

CPU 사용시간이 긴 프로세스는 나중에 , 짧은 프로세스는 먼저!

기존적으로 비선점 형으로 구현된다.

- SRTF

SJF + Round Robin

남은 CPU 버스트가 가장 짧은 순서대로 실행한다.

time slice만큼 cpu를 이용하되, 남은 작업 시간이 가장 적은 프로세스부터 실행

- priority

우선 순위가 높은 프로세스부터 실행

우선 순위가 같다면 FCFS로 처리

starvation(기아) 현상이 발생할 수 있음 (우선 순위가 낮은 프로세스는 실행 무기한 지연)

-> 에이징 기법으로 해당 문제를 완화할 수 있음

- Round-Robin

FCFS + 타임 슬라이스

time slice로 나눠진 CPU time을 번갈아가며 실행

정해진 시간이 끝났음에도 프로세스가 완료되지 않았다면 다시 큐의 맨 뒤에 삽입한다.

Round Robin에서 time slice의 크기가 너무 크다면 fcfs에서 발생하는 문제가 그대로 나타나고,

반대로 너무 작아져버리면 context switching으로 인한 CPU의 오버헤드가 발생한다.

따라서 적절한 time slice의 크기를 필연적으로 고려해야한다.

- multilevel-queue

우선 순위별로 준비큐를 여러개 사용하는 방식

프로세스 유형별로 그룹화해서 큐별로 다른 스케줄링 알고리즘을 적용할 수 있다.

queue 간의 이동이 불가능하고 기아 현상이 발생할 수 있다.

- multilevel-feedback-queue

queue 간의 이동이 가능한 multilevel-queue 스케줄링 방식

정해진 time slice 안에 프로세스를 완료하지 못했으면 우선 순위가 낮은 큐로 이동한다.

-> 다른 프로세스의 우선 순위가 상대적으로 높아짐

에이징 기법도 적용 가능하다.

CPU 스케줄링의 가장 일반적인 형태이다!

결론

운영체제는 멀티프로세스 환경에서 CPU의 이용률을 최대화하기 위해 여러 스케줄링 방식을 사용한다.

만일 적합하지 못한 방식을 사용한다면 프로세스가 무기한 지연되는 기아(starvation) 현상이나 응답 시간의 지연을 초래할 수 있다.

따라서 CPU 선점 방식에서부터 알고리즘 까지, 상황에 맞게 적당한 방식을 고르는 것이 중요하다.

💡 운영체제란 무엇인가?

- 운영체제란 유저의 편의를 위해 컴퓨터의 자원들을 대신 관리해주는 시스템 소프트웨어이다.

- 여기서 자원은 메모리 , CPU 그리고 I/O 디바이스들이 있다.

- 운영체제를 사용함으로써 유저는 동작원리를 알지 못해도 PC를 활용할 수 있다.

(ex. 윈도우 , 리눅스 , 유닉스)

💡 프로세스와 스레드에 대해 설명해주세요.

- 프로세스는 운영체제로부터 작업을 할당받는 작업의 단위이며 , 스레드는 그 자원을 이용하는 실행의 단위이다.

- 프래세스 내에 스레드는 여러개가 생성될 수 있으며 최소 한 개 이상을 가져야한다.

💡 멀티 스레드의 장점 및 단점은 무엇인가?

- 스레드는 서로 메모리를 공유하기 때문에 프로세스보다 가볍다는 특징이 있다.

- 이는 통신 비용 감소 및 시스템 자원의 효율적인 사용으로 이어진다.

- 또한 컨텍스트 스위치를 비용이 멀티 프로세스에 비해 줄어든다.

- 하지만 자원을 공유한다는 특성은 곧 여러 단점을 낳는다.

- 대표적으로 동기화의 문제인데, 여러 스레드가 한 자원에 접근하는 경우 의도치 않은 여러 문제가 생길 수 있다.

- 그리고 스레드 하나가 종료 되면 해당 자원을 공유하는 다른 스레드들에게도 영향을 미치기 때문에 안정성 문제도 발생한다.

- 따라서 멀티 스레드의 에러 처리 및 동기화 처리를 필수적이라고 볼 수 있다.

💡 멀티 프로세스 대신 멀티 스레드를 사용하는 이유

- 멀티 스레드만의 장점은 자원을 서로 공유함으로써 스레드간 통신 비용이 감소하고 자원을 효율적으로 쓴다는 것이다.

- 따라서 스레드 간 데이터 공유가 빈번하거나, 컨텍스트 스위칭이 자주 일어나는 경우 멀티 스레드를 사용하는 것이 적합하다.

- 하지만 프로그램이 메모리가 공유되서는 안되며 동기화 문제에 취약한 경우 멀티 스레드 보단 멀티 프로세스를 사용해야한다.

💡 스레드에 스택을 독립적으로 할당하는 이유?

- 스레드에게 최소한의 독립적인 실행을 보장해주기 위해서이다.

- 함수 호출을 위한 여러 정보를 담고 있는 스택을 할당해줌으로써 이를 보장해줄 수 있다.

💡 PC레지스터를 스레드마다 독립적으로 할당하는 이유?

- 스레드의 레지스터는 "마지막 상태"를 의미한다.

- 예를 들어 스레드가 동작하다가 스케줄링에 의해 CPU 점유권이 넘어가게 된다면 스레드는 마지막 상태를 저장하고 종료된다.

- 이 상태가 저장되는 곳이 PC 레지스터이다.

💡 자바 스레드란?

- 기존 스레드 개념과 동일하게 JVM 프로세스 내에서 관리되어 지는 실행 단위이다. 

- 처음 프로세스를 시작하면 main 함수에서 스레드 하나가 만들어지는데, 필요에 따라 멀티 스레드 환경을 구현할 수 있다.

- 단 이 경우 메인 스레드가 종료되어도 실행되고 있는 스레드가 있다면 프로세스가 종료되지 않는다.

💡 Thread-safe가 뭐에요?
- 멀티 스레스 환경에서 여러 스레드가 동시에 자원에 접근할 때 실행 결과에 영향을 주지 않는 것을 "스레드 세이프" 하다고 한다.

- 즉 레이스 컨디션 환경에서 동기화를 통해 데이터의 일관성을 유지하는 것이다.

Mutual exclusion (상호 배제)

- 락을 사용해 공유 자원에 동시 접근을 제한하는 방법이다.

- 대표적으로 스핀 오프 , 뮤텍스 , 세마포어가 있다.

Atomic operation (원자 연산)

- 공유 자원에 접근할 때 원자 연산 혹은 원자적으로 접근한다. 

*원자적이란 모두 성공하던지 아니면 모두 실패하는 지를 보장해주는 것을 말한다.

Thread-local storage (쓰레드 지역 저장소)

- 공유 상태를 피할 수 없을 때 각각의 스레드에서만 접근 가능한 저장소들을 사용함으로써 동시 접근을 막는 방법이다.

- 전역 변수의 사용을 막음으로써 만들 수 있다.

Re-entrancy (재진입성)

- 스레드가 병렬적으로 실행되더라도 실행 결과에 영향을 미치지 않는 것을 보장해주는 것이다.

- 모든 재진입 함수는 스레드-안전하지만, 모든 스레드 함수가 재진입이 가능한 것은 아니다.

💡 세마포어와 뮤텍스를 설명해주세요.

- 뮤텍스는 공유 자원에 대해 하나의 프로세스나 스레드가 락을 가지고 다른 락은 슬립 상태로 대기하는 방법이다.

- 세마포어는 공유 자원에 접근하는 프로세스나 스레드의 수를 제한하는 방식이다. 

- 세마포어의 제한을 1로 둠으로써 뮤텍스 환경을 어느정도 구현할 수는 있지만 뮤텍스는 락을 가진 자만이 락을 해제할 수 있다는 점에서 차이가 있다.

트랜잭션이란 ?

소프트웨어 세계에서의 트랜잭션을 살펴보기 앞서서 실생활에서 흔히 있는 이야기를 예로 들어보려고 한다.

만약 친구가 당신에게 자신의 계좌에 20만원을 보내주려고 한다.

이 경우 작업의 단위는 어떻게 될까?

자세히 파해치면 더 많은 단위가 있을 수 있겠지만 크게 두 가지로 볼 수 있을 것이다.

1. 친구 A의 계좌에서 20만원을 뺀다.

2. 친구 B의 계좌에 20만원을 추가한다.

이 상황에서 발생할 수 있는 문제들은 여러가지가 있는데 대표적으로 4가지만 알아보자

만약, 송금 도중 A의 계좌에는 돈이 빠졌는데 B의 계좌에 돈이 그대로라면?

만약, A의 계좌에 돈이 부족한 상태인데 송금이 되었다면?

만약, 송금 도중 친구C가 송금을 보내서 서로의 데이터가 엇갈린다면?

만약, 송금을 잘 마쳤음에도 데이터가 날아가 버린다면..?

그렇다면 친구가 보내준다고 했던 20만원은 증발해버린 것이고 이는 곧 대형 사고로 이어진다.

이런 현상을 방지하기 위해 사용하는 것이 트랜잭션이다.

트랜잭션은 위에서 말한 작업 단위들을 묶음으로 인해 일부만 성공해서 DB에 반영되는 일이 없도록 도와준다.

즉 데이터베이스의 상태를 변화시키기 해서 수행하는 논리적인 작업의 단위이다.

그리고 트랜잭션의 성질이 위에서 말한 여러 문제상황들을 방지해준다.

트랜잭션의 성질

위에서 말한 4가지 문제들은 트랜잭션의 성질에 정의되어 있다.

그리고 이 성질들을 ACID 라고 부른다.

A : Atomicity (원자성)

C : Consistency (일관성)

I : Isolation (독립성)

D : Durability (지속성)

앞선 사례들을 하나씩 보면서 각각 어떤 성질과 대비되는 지 살펴보자 !

만약, 송금 도중 A의 계좌에는 돈이 빠졌는데 B의 계좌에 돈이 그대로라면?

이 예시는 원자성(Atomicity)을 지키지 못한 것이다.

하나의 작업이 성공하고 하나의 작업이 실패했는데 결과가 DB에 반영된 것이다.

원자성은 지킨다는 것은 모든 작업이 모두 성공하거나 아니면 모두 실패해야한다.

만약, A의 계좌에 돈이 부족한 상태인데 송금이 되었다면?

이 예시는 일관성(Consistency)을 지키지 못한 것이다.

DB에는 잔액은 마이너스가 될 수 없다는 제약이 있음에도 이를 어긴 채 송금을 진행한 것이다.

일관성을 지킨다는 것은 트랜잭션 이전,이후에도 데이터베이스의 제약이나 규칙을 만족한다는 것이다.

만약, 송금 도중 친구C가 송금을 보내서 서로의 데이터가 엇갈린다면?

이 예시는 독립성(Isolation)을 지키지 못한 것이다.

친구C와의 트랜잭션이 동시에 실행됨으로써 영향을 미친것이다.

(친구C가 보낸 돈에 더해지지 않고 기존 금액에 더해짐으로써 잔액이 그대로)

독립성을 지키기 위해서는 트랜잭션들이 동시에 실행될 때에도 혼자 실행되는 것처럼 동작해야한다.

만약, 송금을 잘 마쳤음에도 데이터가 날아가 버린다면..?

이 예시는 지속성(Durability)을 지키지 못한것이다.

당연한 말이지만 저장된 데이터는 영구적으로 DB에 남아있어야한다.

영구성을 지키기 위해서는 DB에 문제가 발생하더라도 커밋된 트랜잭션이 DB에 남아있어야한다.

여기까지가 트랜잭션의 ACID 성질이다.

이렇듯이 트랜잭션은 ACID 성질을 유지해줌으로써 데이터의 정합성을 지켜준다.

🧐 정합성이 뭐지?

데이터 정합성은 데이터가 서로 모순 없이 일관되게 일치해야 함을 의미한다 !

믿을 수 있는 데이터를 위해선 정합성이 보장되어야한다.

지금까지 트랜잭션의 역할과 ACID 성질에 대해 알아보았다 !

이제 트랜잭션이 뭔지 감이 오는가?

트랜잭션은 알겠는데 ... 격리 수준은 뭐지?

트랜잭션은 데이터의 정합성을 지켜줄 수 있는 좋은 장치이다.

하지만 트랜잭션끼리 접촉하다 보면 여러 문제가 발생할 수 있다.

대표적으로 크게 3가지 문제가 있는데

1. dirty read

2. non repeatable read

3. phantom read

하나하나 알아보자 !

고려해봐야 할 문제점들

위에서 언급한 3가지의 이상 현상들을 하나씩 알아보면서 격리레벨이 왜 필요한 지 생각해보자 !

아래에서 설명하는 상황들은 모두 트랜잭션 A,B가 하나의 데이터 베이스에 접근하고 가정한다.

dirty read

쉽게 말해서 , 커밋되지 않은 변화를 읽는 것이다.

트랜잭션 A와 B가 각각 다른 데이터에 접근해서 데이터베이스를 변화시키는 상황을 생각해보자

트랜잭션 A는 x를 변화시키고 , 트랜잭션 B는 y를 변화시킨다.

어떤 문제가 발생할까?

뭔가 이상하지 않은가?

x에 더한 y의 값 10은 더 이상 유효하지 않은 값이다.

즉, 위에서 말했다시피 커밋되지 않은 변화를 읽어서 문제가 생긴것이다.

non repeatable read

같은 데이터를 조회했을 때 값이 다르게 나오는 것이다.

트랜잭션 A가 x의 값을 처음 읽었을 때는 50이었다.

그 사이에 트랜잭션 B가 x의 값을 10으로 변경했고 , 다시 트랜잭션 A가 x를 읽었을 때는 x의 값은 10이 나온다.

값은 x라는 데이터의 값을 조회했지만 조회할때마다 값이 다르게 나오는 것이다.

이는 곧 isolation 관점에서 바람직하지 못하다.

🧐isolation 위에서 배웠는데 .. !

여러 개의 트랜잭션들이 동시에 수행될 때, 각 트랜젝션은 고립(격리)되어 있어 연속으로 실행된 것과 동일한 결과를 나타낸다.

phantom read

없던 데이터가 생기는 것이다.

이 상황도 마찬가지로 똑같은 조건으로 데이터를 검색했는 데 결과가 다르게 나온다.

이 역시 isolation 원칙에 위배된다고 할 수 있다.

지금까지 소개한 3가지가 대표적으로 나타나는 문제점들이다.

🧐 아 그럼 해결책은 간단하네요 ! 다 막아버리면 되는 거죠?

물론 극도의 안정적인 환경을 위해서라면 그렇게 할 수도 있지만 이는 좋은 방법이 아니다.

코로나 거리두기 단계를 떠올려보자

사실 코로나 확진자가 안나오게 하는 방법은 어떻게 보면 매우 간단할 수 있다.

아무것도 하지 못하게하면 코로나 확진자는 안나왔을 것이다.

근데 현실은 다르다.

거리두기 단계에 따라서 허용되는 것이 있고 금지되는 것들을 정해놓았다.

왜일까?

너무나 당연한 얘기이지만, 모든 것을 금지시켜 버리면 사회는 돌아가지 않기 때문이다.

그래서 단계에 따라 준수사항들을 조정함으로써 관리했던 것이다.

트랜잭션에도 비슷한 개념이 적용된다.

격리레벨이 올라갈 수록 안정성은 높아지지만 데이터 처리량이 저하된다.

그리고 이것에 대해 정해놓은 표준 SQL 기준을 알아보려고 한다.

SQL 표준 격리 레벨

SQL 표준에서는 위에서 말한 문제들을 어디까지 허용할 지 구분하는 격리레벨을 지정하였다.

Read uncommitted

Read uncommitted 레벨은 커밋되지 않은 변화도 다른 트랜잭션이 읽을 수 있다.

아래 예시를 보자, 트랜잭션1이 새로운 데이터를 넣고 커밋을 하지 않은 상태이지만 트랜잭션2는 이것을 읽을 수 있다.

사실상 격리가 아예 없는 거나 마찬가지이므로 최소한 Read committed 이상 레벨의 사용을 권장한다.

Read uncommitted 레벨에서 발생할 수 있는 문제점

- 이 레벨에서는 많은 문제들이 발생할 수 있지만 대표적으로 Dirty Read 에 대해 다뤄보고자 한다.

위에서 dirty read는 커밋되지 않은 변화를 읽음으로써 나타나는 문제라고 하였는데 Read uncommitted 에서 그 문제가 그대로 발생한다.

트랜잭션 B는 데이터베이스로 부터 Y를 읽기로 하였다.

하지만 B가 데이터를 읽는 도중 트랜잭션A가 Y의 데이터를 변경하였고 B는 격리레벨 특성상 커밋되지 않은 데이터를 읽게 되었다.

하지만 A가 변경한 데이터가 커밋되지 않고 롤백된다면 어떻게 될까?

트랜잭션B가 읽은 Y의 데이터는 더 이상 유효한 값이 아니게 된다.

이 현상을 dirty read 라고 부른다.

즉, 트랜잭션에서 처리한 작업이 완료되지 않았음에도 불구하고 다른 트랜잭션에서 볼 수 있게 되는 현상이다.

Read committed

Read committed 단계에서는 커밋된 데이터만 읽기 때문에 dirty read 와 같은 현상은 발생하지 않는다.

어떻게 이것을 구현할 수 있었을까?

바로 undo 영역을 따로 만들어줌으로써 백업된 데이터만을 가져오기 때문이다.

밑에 그림을 보면 트랜잭션1에서 데이터를 변경하기 전에 테이블을 백업한다.

그리고 테이블에 변경된 데이터가 반영된다.

트랜잭션2에서는 undo 영역에서 데이터를 가져오기 때문에 이전에 커밋된 데이터만 볼 수 있는 것이다 !

Read committed 발생할 수 있는 문제점

- 이 레벨에서는 non repeatable read 문제가 발생한다.

무엇이 문제일까? 다시 예시를 보자

트랜잭션B가 Y를 두번 조회한다고 가정하자

첫번째로 조회했을 때는 Y가 50이 나왔지만 두번째로 조회했을 땐 70이 나왔다.

얼핏 생각하면 크게 문제될게 없어보이는 데 , 이는 ACID 속성 중 독립성에 어긋난다.

🧐 독립성 벌써 몇번째야 ..

동시에 여러 개의 트랜잭션들이 수행될 때, 각 트랜젝션은 고립(격리)되어 있어 연속으로 실행된 것과 동일한 결과를 나타낸다.

Repeatable read

어떻게 하면 트랜잭션 내에서 특정 행을 조회할 때 마다 항상 같은 데이터를 나오도록 할 수 있을까?

Repeatable read 에서는 이를 트랜잭션 ID 를 통해 해결한다.

이렇게 부여된 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게 된다.

그리고 undo 로그가 많아지면 데이터베이스의 성능이 떨어질 수 있기때문에 DB엔진에서는 불필요한 undo 로그를 주기적으로 삭제한다.

Repeable read에서 발생할 수 있는 문제점

- 이 레벨에서는 phantom read 라는 문제가 발생할 수 있다.

예시를 살펴보자

맨처음 데이터행을 조회했을 때 1개가 나왔지만 나중에 한번 더 조회했을 때 하나가 추가된 2가 나왔다.

이는 undo 테이블에 쓰기 잠금을 할 수 없기 때문에 발생하는데 결국 현재 데이터의 값을 가져오게 된다.

(innoDB에서는 팬텀 리드가 발생하지 않는다고 한다!)

Serializable

특정 트랜잭션이 사용중이면 다른 트랜잭션은 일체 접근할 수 없다.

데이터의 안정성(정합성)은 높으나 처리량은 떨어진다.

발생할 수 있는 문제점

- 없음

다시 표로 정리해보자

이처럼 격리 단계에 따라 허용하는 오류들이 정해져있다.

각각의 용도에 맞게 적절하게 격리 레벨을 지정하는 것이 중요하다.

결론

데이터의 정합성을 보장해주기 위해서 트랜잭션을 사용해야한다.

하지만 트랜잭션끼리 동시에 실행되다 보면 여러 문제들이 발생하는 데

SQL 표준에서 이를 어디까지 허용할 것인지에 대한 격리 단계를 지정해놓았다.

각자 상황에 따라 적절한 격리 단계를 선택해야한다.

참고 자료

[MySQL] - 트랜잭션의 격리 수준(Isolation level)

트랜잭션 격리 수준

[데이터베이스] 트랜잭션의 ACID 성질 - 하나몬

트랜잭션의 격리 수준(isolation Level)이란?

https://www.youtube.com/watch?v=bLLarZTrebU&t=397s

https://www.youtube.com/watch?v=sLJ8ypeHGlM&t=144s