[4장] 인프라를 지탱하는 기본 이론

4.1 직렬/병렬

4.1.1 직렬/병렬이란?

- CPU 제조사가 클럭(Clock) 속도를 올리는 대신에 코어 수를 늘려서 소비 전력과 발열 문제를 해결하려고 방침 전환

- 대규모 웹 서비스에서는 방대한 수의 사용자 요청을 처리해야 하므로 수많은 서버를 배치해서 병렬로 처리

- 여러 개의 물건이 일직선으로 나열되어 있는 것을 직렬, 두 줄 이상으로 나열되어 있는 것을 병렬

- 1차선 구간은 혼잡해지기 쉽고, 합류점이나 분기점에서 사고가 발생하기 쉽기 때문에 전체 흐름을 느리게 만드는 병목지점(Bottleneck)

- 해결책은 1차선 구간을 3차선으로 만드는 것...!

- 특정 기간 내에 하나의 CPU로 처리할 수 있는 양에는 한계가 있지만, 여러 개의 CPU를 배치하면 처리량을 늘릴 수 있음. 

- 다수의 CPU를 이용할 수 없는 처리일 경우 CPU 클럭 주파수를 올리면, 즉 직렬 처리 속도를 올리면 고속 처리 가능

- 병렬 처리를 할 때는 가능한 한 병렬화해서 직렬 부분을 줄이고, 어쩔 수 없이 직렬화해야 하는 경우에는 효율성을 높여야

- 병렬화에서는 분담해서 일을 진행한 것을 다시 한 곳에 모으는 데 오버헤드가 걸리기 때문에 미리 예상해서 어느 부분을 병렬화할지 파악해야.

- 직렬/병렬의 중요 사항

  - 직렬 처리로 속도를 올리는 데는 한계가 있다

  - 병렬화를 통해 속도는 빨라지지 않지만, 단위 시간당 처리량을 늘릴 수 있다

    - 병렬 처리에서는 합류점, 직렬화 구간, 분기점이 병목 지점이 되기 쉽다

    - 병렬화할 때는 일을 분담해서 처리를 한 후 다시 집약할 때 오버헤드가 걸린다. 그러므로 이 오버헤드를 감안하더라도 효과가 있을 경우에 병렬화를 한다.

4.1.2 어디에 사용되나?

웹 서버와 AP 서버에서의 병렬화

- 아래 그림은 웹 서버와 AP 서버 내부 처리를 간략화해서 표시한 것

- 웹 서버에는 다수의 이용자가 접속하기 때문에 복수의 프로세스가 분담해서 병렬 처리 진행

- 하나의 CPU 코어밖에 없는 서버에서는 아파치 프로세스를 아무리 늘려도 동시에 실행할 수 있는 것은 1프로세스 뿐

- 프로세스나 스레드 수를 조정할 때는 CPU 코어 수도 함께 고려해야 함

DB 서버에서의 병렬화

- DB 서버에서도 프로세스를 늘려서 병렬 처리를 할 수 있음

- 오라클DB에서는 클라이언트 요청을 접수하는 서버 프로세스가 클라이언트 접속 수만큼 생성됨

- 서버 프로세스에는 멀티 프로세스 모델 외에도 공유 서버형이라 불리는 하이브리드형이 있어서, 멀티 프로세스와 멀티 스레드를 모두 사용할 수 있는 것도 있음

- 데이터 파일 생성 시에 병목 현상이 발생하는 경우, 메모리에 캐시된 갱신 완료 데이터를 HDD에 기록하는 DBWR(DataBase WriteR) 프로세스 수를 늘려서 병렬화 가능

- DBWR 프로세스는 프로세스 수를 늘리는 방법 외에도 비동기 I/O를 사용해서 OS 측에서의 쓰기 처리를 병렬화하는 방법도 있음

4.1.3 정리

- 직렬/병렬의 장단점

	장점	단점
직렬	구조가 간단해서 설계나 구현 난이도가 낮음	복수의 리소스(컴퓨터나 프로세서 등)를 유용하게 이용할 수 없음
병렬	복수의 리소스(컴퓨터나 프로세서 등)를 유용하게 이용할 수 있으며, 직렬에 비해 동일 시간당 처리할 수 있는 양이 증가. 일부가 고장 나더라도 처리 계속할 수 있음	처리 분기나 합류를 위한 오버헤드가 발생. 배타적 제어 등을 고려해야 함 구조가 복잡해서 설계나 구현 난이도 높음

4.2 동기/비동기

4.2.1 동기/비동기란?

- 동기는 누군가에게 일을 부탁하고 그 일이 끝나기까지 잠자코 기다리는 것

- 비동기는 '끝나면 말해'라고 말해 두고 다른 일을 하는 것. 비동기에서는 처리를 병행해서 진행 가능

- 동기/비동기의 특징 정리

  - 동기는 다른 사람에게 일을 부탁한 후 끝날 때까지 아무것도 하지 않고 기다리기 때문에 그 사이에 다른 것을 할 수 없음. 하지만 의뢰한 것이 끝났는지 여부를 확실하게 확인 가능

  - 비동기는 끝날 때까지 기다리지 않기 때문에 병렬로 다른 일을 할 수 있음. 하지만 의뢰한 일이 끝났는지 여부를 확인하고 싶으면 별도의 방법 이용해야.

4.2.2 어디에 사용되나?

- Ajax의 A는 '비동기'의 Asynchronous.

DBMS에서 사용되는 비동기 I/O

- DBMS는 HDD 등의 저장소에 비동기로 쓰기 처리를 할 수 있으며, 이것을 비동기 I/O

- 동기 I/O에서는 I/O가 끝날 때가지 프로세스가 다음 처리를 하지 않지만, 비동기 I/O에서는 I/O가 끝나지 않아도 다음 처리 가능

- 비동기 I/O는 대량의 I/O를 효율적으로 처리해야 하는 DBMS에 적합

- 공유 메모리에 있는 다수의 데이터를 프로세스가 HDD에 기록하는 경우, 비동기 I/O라면 하나의 I/O가 끝나기까지 기다리지 않고 다음 I/O를 발행할 수 있기 떄문에 저장소 성능을 충분히 활용 가능

- 위 그림의 DBMS 프로세스와 OS 부분을 확대한 것이 아래 그림

- 비동기로 이용할 경우 쓰기가 끝났는지 확인하지 않고 다음 처리를 진행하는 것을 걱정할 수도 있으나, DBMS에서는 비동기로 I/O를 요구한 후에 I/O가 끝났는지 여부를 확인하고 있음

- 비동기 I/O로 I/O를 발행하더라도 저장소 성능 이상으로는 빨라지지 않음.

4.2.3 정리

- 동기/비동기의 장단점

	장점	단점
동기	의뢰한 처리가 끝났는지 여부를 쉽게 확인할 수 있어서 구조가 간단, 구현 난이도가 낮음	의뢰한 처리가 끝나기까지 기다려야 하기 때문에 대기 시간을 활용할 수 없음
비동기	의뢰한 처리가 진행되고 있는 동안 시간을 효율적으로 사용해서 병렬 처리 가능	의뢰한 처리가 끝났는지 확인하지 않으면 모르기 때문에 불필요한 확인 처리가 늘어남 구조가 복잡해서 구현 난이도가 높음

- 비동기 처리를 사용하는 경우의 주의점

  - 비동기로 요구한 처리가 끝나지 않은 상태에서 다음 처리를 진행해도 문제가 없는가

  - 비동기로 요구한 처리가 끝났는지 확인할 필요가 있는가

- 모든 것을 동기로 처리하면 대기 시간이 너무 길어져서 현실적인 요건을 만족하지 못하는 경우도 있기 때문에, 각각의 장단점을 고려해서 선별적으로 사용하는 것이 중요하다.

4.3 큐

4.3.1 큐란?

- 큐(Queue)는 '대기 행렬'이라고 할 수 있음.

- 큐(대기 행렬)에서 줄을 설 때는 가장 마지막에 서고, 처리는 선두부터 순서대로 한다

- 먼저 들어온 데이터가 먼저 나가는 큐 동작을 FIFO(First In First Out) 방식이라고 한다.

4.3.2 어디에 사용되나?

- 아래의 경우에서 큐의 구조가 사용된다고 할 수 있음

  - CPU 처리를 기다리고 있는 프로세스나 스레드 행렬

  - 하드 디스크 등의 저장소 읽기 처리를 기다리고 있는 I/O 요구 행렬

  - 네트워크 접속 성립을 기다리고 있는 접속 요구 행렬

웹 서버인 아파치의 내부 동작

- CPU를 기다리고 있는 프로세스 행렬을 런큐(Run-Queue)

- 런큐에 쌓인 프로세스 수를 코어 수로 나누어서 1이라면 문제가 없음...! (= 편의점에서 한 명이 계산대에서 정산 중이고 나머지는 뒤에 서 있는 상태)

- CPU에서 처리 중인 프로세스를 런큐로 인식할 것인지는 OS의 종류에 따라 달라짐

  - 리눅스에서는 CPU에서 실행 중인 프로세스도 런큐로 인식

  - OS 커널에서는 프로세스 ㅅ케줄러라는 기능이 있어서 런큐 등을 관리

- CPU 처리를 기다리고 있는 프로세스나 스레드 수는!

  - UNIX 계열의 OS일 경우 vmstat의 r열

  - Windows에서는 성능 모니터의 Processor Queue Length에서 확인 가능.

  - 이 툴들이 참조하고 있는 데이터의 실체는 OS 커널에 있음

데이터베이스의 디스크 I/O

- 데이터베이스의 디스크 I/O의 기본적인 개념은 CPU와 같으나, 프로세스나 스레드가 사용하는 대상이 CPU가 아닌 HDD인 점만 다름

서버인 오라클DB 동작. 내장 HDD의 예시

- 두 개의 서버 프로세스와 DBWR 프로세스는 왼쪽 HDD에 I/O를 실시하고 있고, LGWR 프로세스는 오른쪽 HDD에 실시

  - LGWR : LoG WRiter. Redo Log Buffer 프로세스에 있는 내용을 Redo Log 파일에 기록하는 프로세스

- HDD는 데이터가 기록되어 있는 특정 위치에 액세스해야 하기 때문에 CPU처럼 비어 있다는 이유로 다른 것 사용 불가.

- 내장 HDD의 예시는 위의 이미지와 같지만, 공유 저장소에서는 일반적으로 I/O가 발생하면 캐시에 보관하기 때문에 기록되기까지 기다리지 않아도 된다. --> 성능 고속화

4.3.3 정리

- 큐의 특징은 선두에서부터 순서대로 처리된다는 점. 여러 처리가 동시에 진행되는 경우에 자주 사용됨

- 성능 문제에서는 큐의 길이, 즉 행렬의 길이를 확인하는 것이 중요. (CPU 사용률뿐만이 아니라 런큐 길이도 함께 확인)

- 메세지 큐를 사용하면 애플리케이션 간 상호 운용성을 향상시켜서 시스템 전체 안정성 향상 가능.

4.4 배타적 제어

4.4.1 배타적 제어란?

- 배타적 제어는 '다른 것을 배제하는 제어'. 여러 사람이 공유할 때, 병렬 처리를 할 때 배타적 제어가 필요

- 배타적 제어를 하는 부분은 병목 현상이 발생하기 쉬움

- 회의를 하고 있을 때는 회의실 안내문을 '사용 중'으로, 끝나면 '공실'이라고 안내문을 표시함으로써 다른 사람들이 이용할 때 참고하도록 하는 것 또한 배타적 제어라고 할 수 있음

- 일반적으로 OS나 DBMS는 병렬 처리를 위해 배타적 제어를 사용.

- 병렬 처리 시 각 처리가 서로 관계 없이 동작하는 경우 배타적 제어가 필요 없으나, 대부분은 공유 데이터를 이용하며, 부분적으로 직렬 처리를 사용해야만 되는 경우가 있는데, 이 때 배타적 제어를 사용.

- 배타적 제어의 특징

  - 복수의 처리가 공유 자원(CPU,  메모리, 디스크 등)에 동시에 액세스(주로 갱신)하면 불일치가 발생할 수 있기 때문에 배타적 제어로 보호해 주어야 한다

  - 배타적 제어에서는 특정 처리가 공유 자원을 이용하고 있는 동안 다른 처리가 이용할 수 없게 해서 불일치가 발생하지 않도록 한다

  - 예를 들어, 3차선 도로가 1차선이 되는 부분과 같다. 3차선으로 나누어 운행하던 자동차가 1차선으로 집약되기 때문에 한 대의 자동차가 통과할 때는 다른 차선의 자동차가 들어오지 않도록 배타적 제어를 한다. 이런 부분에서는 병목 현상이 발생하기 쉬움

4.4.2 어디에 사용되나?

DBMS에 사용되는 배타적 제어

- 오라클DB에서는 여러 프로세스가 동시에 병행으로 처리를 하고 있지만, 특정 프로세스가 공유 데이터를 변경하고 있는 도중에 다른 프로세스가 해당 공유 데이터를 읽거나 공유 데이터를 동시에 변경하지 못하도록 배타적 제어 하고 있음

- DBMS의 배타적 제어에서는 매우 짧은 시간 동안만 락(Lock)을 유지하는 래치(Latch)(또는 Spin-Lock)라는 것이 있어서 CPU에서 의미가 없는 처리를 하면서 대기하는 방식이 있음. 극히 단시간의 락에서는 CPU를 회전해서 기다리는 스핀락 사용

- 슬립락(Sleep-Lock)은 비교적 장시간 락을 유지하도록 큐를 이용해서 관리하는 방식

- 단순히 스핀락처럼 계속 반복만 하는 것이 아니라 스핀해서 락을 확보하지 못하면 슬립하는 등 상황에 따라 슬립할지 스핀할지를 판단하는 어댑티브락(Adaptive-Lock) 방식도 존재

OS 커널에 사용되는 배타적 제어

OS 커널의 예시

- 리눅스 커널은 빅 커널락(Big Kernel Lock, BKL)이라 불리는, 하나의 스핀락으로 유지된다

- 커널의 BKL이 이용되는 부분에서는 처리가 직렬화되어서 동시에 하나의 CPU만 커널 코드를 실행할 수 있기 때문에 이 부분이 병목 지점이 되기 쉬움

4.4.3 정리

- 배타적 제어의 장단점

	장점	단점
배타적 제어를 사용하는 경우	공유 데이터의 일관성을 유지할 수 있음	병렬 처리가 안 됨
배타적 제어를 사용하지 않는 경우	병렬로 빠르게 처리 가능	데이터 불일치가 발생할 가능성이 있음 (동시에 공유 데이터를 변경하는 경우 등)

- 정말 필요한 곳에만 배타적 제어를 하고 병렬 처리가 가능한 부분을 늘리면 CPU를 유용하게 활용해서 속도를 높일 수 있음

4.5 상태 저장/상태 비저장

4.5.1 상태 저장/상태 비저장이란?

- 정보를 많이 가지고 있는 상태 저장(Stateful)은 세분화된 제어가 가능한 반면 구조가 복잡하다. (ssh)

- 상태 비저장(Stateless)은 고기능은 아니지만 간단하다. 일장일단이 있기 때문에 적재적소에 사용해야 한다. (http)

- '상태'를 가진다는 것은, 과거에 부여한 '정보'를 저장해서 계속 활용할 수 있다는 것을 의미. 상태를 가지고 있지 않으면 과거 정보 알 수 X

4.5.2 자세히 알아보자

- 상태를 고려하는 것을 '상태 저장', 고려하지 않는 것을 '상태 비저장'

- 상태 저장은 부여된 정보에 따라 상태가 전이됨. 과거 정보를 가져옴으로써 정보에 따른 복잡한 처리 가능하나, 시스템 복잡성이 커짐.

- 상태를 고려하지 않는 상태 비저장은 간단한 구조 덕분에 성능이나 안정성 쉽게 향상시킬 수 있으나, 과거 정보를 가져올 수 없기 때문에 복잡한 처리가 어려움. 필요한 정보는 처리할 때마다 매번 전달되어야 함

4.5.3 어디에 사용되나?

컴퓨터 내부 구조

- 컴퓨터 내에서는 거의 모든 곳에 상태 저장 사용되고 있음.

- 일반 CPU는 하나의 CPU에서 복수의 프로세스를 조금씩 처리하기 때문에 특정 시점에 진짜로 처리를 하고 있는 프로세스는 ICPU(코어)당 하나. 처리를 하지 않는 프로세스는 대기 상태로 있어야 함

- 실행 가능 상태 : 명령이나 애플리케이션을 실행하면서 프로세스가 생성, 실행되면 가장 먼저 실행 큐라 불리는 순서 대기 행렬에 줄을 섬

- 실행 상태 : 차례가 돌아오면 여기로 전이하고 애플리케이션 처리 진행. 일정량을 처리하면 CPU를 다시 열며, 이 때 프로세스는 다시 순서 행렬로 돌아가 줄을 서게 됨

- 대기 상태 : 디스크 액세스 등 I/O 대기가 발생하는 처리를 실행한 경우 이 상태로 전이됨

- 종료 : 위의 대표적인 세 가지 상태를 전이하면서 처리가 전부 끝나면 종료 상태

네트워크 통신 구조

- 브라우저가 HTTP 서버에 접속할 때는 HTTP라 불리는 상태 비저장 프로토콜을 사용함.

- HTTP는 기본적으로 상태 비저장 방식이지만, 세션(Session)이라는 개념을 사용해서 상태를 저장하기도 함

- 세션 정보는 간단히 추측할 수 없는 구조로 되어 있고, 위의 예시에서 인증을 끝낸 사용자는 통신 시에 이 세션 정보를 서버에 건넴으로써 이전 처리 상태를 유지하면서 접속할 수 있게 된다

4.5.4 정리

- 상태 저장 : 상대가 상태 전이를 의식해서 처리하며 과거 경위를 이해한 상태에서 응답을 줌. 자신의 상태를 이해하기 때문에 요청 내용 최소화 가능

- 상태 비저장 : 매번 신규 요청이 생성되는 것. 요청과 그에 대한 응답 구조가 간단함

- 적재적소에 이용할 수 있도록 검토 필요

4.6 가변 길이/고정 길이

4.6.1 가변 길이/고정 길이란?

- 미리 크기가 정해져있는 경우를 고정 길이(Fixed-Length), 정해져 있지 않은 경우를 가변 길이(Variable-Length)

- 고정 길이의 장점은 틀의 크기가 정해져 있어 원하는 것에 쉽게 액세스 할 수 있음. 대신, 남는 공간이 생기기 때문에 이 공간을 효율적으로 활용하기 어려움

- 가변 길이는 데이터를 꽉 채워서 담을 수 있기 때문에 저장 시의 데이터 크기를 절약할 수 있으나, 칸막이 위치가 정해져 있지 않기 때문에 원하는 것을 찾는 데에 고정 길이에 비해 많은 시간이 걸린다. 또한, 크기가 제각각이기 때문에 같은 영역을 계속 사용하면 재이용률이 떨어져서 한쪽에만 데이터가 편중되기 쉬움

4.6.2 어디에 사용되나?

- Windows의 NTFS 파일 시스템에서는 각종 파일을 고정 길이로 저장하고 있음

- 고정 길이를 사용하려면 어느 정도 길이가 적합한지 잘 고민해서 결정해야 함

- TCP/IP는 가변 길이 패킷으로 데이터를 처리함

- 패킷은 일회용이기 때문에 가변 길이로 데이터를 처리해도 한쪽으로 편중되지 않음

4.6.3 정리

- 가변 길이 : 데이터 크기를 매번 변경. 데이터 전체 양이 줄어들음. 효율성 추구할 때 사용

- 고정 길이 : 모두 같은 크기를 이용해서 처리. 크기가 균일해서 관리가 수월. 간단한 것을 추구할 때 사용

4.7 데이터 구조(배열과 연결 리스트)

4.7.1 데이터 구조(배열과 연결 리스트)란?

- 배열은 같은 형태의 상자를 빈틈없이 순서대로 나열한 데이터 구조. '같은 크기'의 상자를 '빈틈없이 순서대로' 나열하기 때문에 상자에 액세스하기가 쉬움. 데이터 추가 및 삭제가 느린 데이터 구조

- 연결 리스트는 상자를 선으로 연결한 형태의 데이터 구조. 다음 상자의 위치 정보를 가지고 있기 때문에 빈틈없이 나열할 필요는 없으나, 상자를 찾으려면 끝에서부터 순서대로 상자 내부를 하나씩 확인해야 함. 데이터 추가, 삭제가 빠른 데이터 구조

4.7.2 어디에 사용되나?

- 해시 테이블에는 배열과 연결 리스트가 모두 사용되고 있음

  - 배열이 차례나 색인(인덱스) 형태로 나열되어 있으며, 거기에 연결 리스트가 매달려 있는 형태.

- 처음 실행된 SQL은 파스(parse)를 거쳐 실행된 후에도 메모리에 남는다(캐시된다). 똑같은 SQL이 실행되면 메모리에 있는 것이 재사용되고, 메모리가 부족하면 실행되고 있지 않은 SQL을 해제.

- SQL은 여기저기 산재하고 있기 때문에 추가, 삭제가 빠른 연결 리스트를 사용하면 해제 처리를 빠르게 할 수 있으나, 탐색이 느리기 때문에 SQL이 실행됐을 때 재사용할 정보를 찾는 데 시간이 걸린다

- 위의 문제를 해결하기 위해 배열 구조를 사용. 해시 함수를 이용해서 SQL을 고정 길이 해시 값으로 변환하여 빠르게 탐색 가능

4.7.3 정리

- 배열과 연결 리스트의 장단점

	장점	단점
배열	N번째 요소 탐색이 빠르다	데이터 추가, 삭제가 느리다
연결 리스트	데이터 추가, 삭제가 빠르다	N번째 요소 탐색이 느리다

- 해시 테이블은 배열과 연결 리스트의 상호 장점만 조합해서 약점을 보완한 데이터 구조.

4.8 탐색 알고리즘(해시/트리 등)

4.8.1 탐색 알고리즘(해시/트리 등)이란?

- 해시나 트리는 탐색 알고리즘이 아닌 데이터 구조이나, 효율적 탐색을 위해 사용됨

- 컴퓨터 내에서의 데이터 정리 방법을 '데이터 구조', 찾는 방법을 '탐색 알고리즘'

- 필요한 때에 필요한 데이터를 빠르게 찾기 위해 데이터를 정리해 둘 필요가 있음

- 데이터를 찾을 때의 데이터 구조와 데이터 저장 방식(메모리, HDD, SSD 등) 특성에 따라 적합한 데이터 정리 방법이 달라짐

- 처리 순서에 맞추어 데이터 구조를 정리할 필요가 있기 때문에 알고리즘과 데이터 구조 자주 함께 다뤄짐

4.8.2 어디에 사용되나?

인덱스가 없는 경우

- 테이블의 모든 블록을 처음부터 순서대로 읽어나가는 것을 풀 스캔(Full Scan). 테이블 크기 커질수록 읽어야 하는 블록 수도 많아짐

인덱스가 있는 경우

- 인덱스가 있으면 최소한의 필요 블록만 읽으면 됨

- 검색이 빨라지는 대신에 데이터 추가, 갱신, 삭제 시에 테이블뿐만 아니라 인덱스 데이터도 갱신해야 함. 이 때문에 오버헤드 발생 가능

인덱스의 구조 - B트리 인덱스

- 나무처럼 뿌리 - 가지 - 잎 순서를 거쳐서 잎에 도달하면 원하는 데이터 저장 위치가 기록되어 있는 형태

- 인덱스는 읽을 블록 수를 줄이기 위한 수단이나, 인덱스를 사용하면 오히려 읽을 블록 수가 늘어날 수도 있음

- 풀 스캔을 하는 경우 1회 디스크 I/O로 가능한 한 크기의 데이터를 읽어서 I/O 횟수를 줄이려고 하지만 인덱스 스캔에서는 인덱스 블록을 읽으면서 테이블 블록을 하나씩 읽기 때문에 액세스 블록 수가 늘어남과 동시에 I/O 횟수도 늘어나서 풀 스캔에 비해 속도 느려짐

- B 트리 인덱스는 트리 구조 계층이 깊어지지 않도록 디스크 I/O를 최소한으로 제어함

해시 테이블

- 키와 값 조합으로 표를 구성한 데이터 구성. 해시 함수를 통해 해시 값으로 변환

- 해시 값은 고정 길이 데이터이기 때문에 조합 표의 데이터 구조가 간단해서 검색이 빠르다는 장점 있음

- 전문 분야에 특화되어 있다고 할 수 있음

4.8.3 정리

- 데이터 구조는 데이터를 찾는 방식이나 데이터 저장 위치의 특성을 고려해서 선택할 필요가 있음