Computer A에서 Computer B로 100MB의 비디오를 전송하는 경우 Segment 과정이 없다면 사용자는 100MB의 비디오가 모두 로딩된 후 비디오를 볼 수 있다. Segment 과정이 있다면 Segment라는 작은 단위로 나뉘어 비디오 일부분을 미리 볼 수 있다.
연결이 중간에 끊기는 경우 Segmentation을 하지 않으면 큰 Data가 날아가 손실률이 크다.
<!-- 해당 Collection에 대한 전체 정보 -->
GET /cources
<!-- Document의 정보 조회 -->
GET /cources/front
4.2. Create(생성) - POST
<!-- backend coach 집합에 jjyoung라는 닉네임을 가진 코치 개체 생성 -->
POST /courses/back/coaches
<!-- body에 생성할 내용을 담음 -->
body {nickname: jjyoung}
4.3. Update(수정) - PUT
<!-- frontend coach 집합 중 첫 번째 코치 닉네임을 jjyoung로 수정 -->
PUT /courses/front/coaches
<!-- 수정할 내용을 body에 담음 -->
body {id: 1, nickname: jjyoung}
4.4. Delete(삭제) - DELETE
<!-- frontend crew 집합 중 jjyoung 삭제 -->
DELETE /courses/front/crews/jjyoung
5. REST Arichtecture의 제약 조건
5.1. Client - Server
: Client가 Server에게 Request를 보내고 Server가 Client에게 Response를 보내는 구조로 Server와 Client의 역할이 분리되어있다.
Server : API 제공과 제공된 API를 이용해 비즈니스 로직을 처리하거나 저장
Client : 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 관리
5.2. Stateless(무상태성)
: Client와 Server의 통신에는 상태가 없어야하며 모든 요청은 필요한 정보를 담고 있어야 한다.
☞ Client가 두 가지 요청을 보냈을 때 두 번째 요청 시 Server는 Client의 첫 번째 요청의 내용을 모르므로 두 번째 요청시에도 필요한 모든 정보를 담고 있어야 한다.
5.3. Cache
: 일반적인 서비스에서 60 ~ 80% 가량의 Transaction이 Select와 같은 조회성 트랜잭션이며 GET은 얼마든지 호출해도 매번 같은 결과를 만들어내므로(Idempotent) 캐싱이 가능하다.
5.4. Uniform Interface
5.4.1. Identification of Resources : 자원은 유일하게 식별 가능해야하며 Resource가 하나 이상의 유일한 특정 주소인 URI로 식별되어야 한다. ☞ 아직 POST Method로만 Request를 보내기 때문에 URI나 Request Body로 어떤 동작을 할 지 알려줘야 한다.
5.4.2. Manipulation of Resources through Representation : HTTP Method로 표현(CRUD)을 담아야 한다. ☞ 안전한 Operation과 안전하지 않은 Operation 간의 강한 분리를 제공해야 한다.
5.4.4. Hypermedia As the Engine Of Application State(HATEOAS)
: Hyperlink를 통해 Application의 상태가 전이되어야 한다.
☞ HTTP Response에 다음 Action이나 관계되는 Resource에 대한 HTTP Link를 함께 Return한다.
☞ 장점 : 요청 URI가 변경되더라도 Client는 Server에서 동적으로 생성된 URI를 사용함으로써 Client는 URI 수정에 따른 코드를 변경하지 않아도 된다.
5.5. Layered System
: 계층으로 구성이 가능해야 한다.
☞ Server는 다중 계층으로 구성될 수 있으나 Client 입장에서는 계층에 상관 없이 Server만 호출하면 된다.
e.g., 순수 비즈니스 로직을 수행하는 Server, 사용자 인증, 암호화(SSL), 로드 밸런싱 등을 하는 계층을 추가하거나 PROXY, 게이트웨이 같은 중간 매체 사용 가능
5.6. Code-On-Demand(Option)
: Server가 Network를 통해 Client에 Program을 전달하면 그 Program이 Client에서 실행될 수 있어야 한다.
e.g., JavaScript를 사용해 Server에서 Program 전달하면 Client에서 동적으로 실행 가능하다.
6. Richardson Maturity Model
Glory of REST
Level 3 : Hypermedia Controls
Level 2 : HTTP Verbs
Level 1 : Resources
Level 0 : The Swamp of POX
6.1. Level 0 : The Swamp of POX
: POX(Plain Old XML)를 주고받는 단순한 RPC Style System
☞ HTTP를 RPC 기반의 원격 통신을 위한 터널링 Mechanism으로 사용된다.
충족된 제약 조건 : Server-Client, Stateless, Layered System, Manipulation of Resources through Representation
RPC(Remote Procedure Call, 원격 프로시저 호출) : 별도의 원격 제어를 위한 코딩 없이 다른 주소 공간에서 함수나 프로시저를 실행할 수 있게 하는 프로세스 간 통신 기술 (= Client가 Server에 있는 Program을 실행하기 위해 사용하는 통신 기술) ☞ RPC를 이용하면 개발자는 실행 Program이 로컬 위치에 있든 원격 위치에 있든 동일한 코드를 이용할 수 있다.
☞ Client가 Server에게 Message를 보내 Program을 실행시키고 Server에서는 그 Program의 결과를 Client에게 전송
상호 배제(Mutual Exclusion) : 여러 Process/Thread가 동시에 한 자원에 접근하지 못하도록 막는것
점유와 대기(Hold and Wait) : Process/Thread가 자원을 점유한 상태로 다른 자원을 점유하기 위해 대기하는 것
비선점(Nopreemption) : Process에서 자원을 할당 받으면 작업을 완료할 때까지 System에서 Process의 제어를 뺏을 수 없음
순환 대기(Circular Wait) : 점유와 대기를 하는 형태로 Cycle에 갇혀 빠져나갈 수 없는 상태
3. 교착 상태 해결법
: 교착 상태의 해결법으로는 교착 상태 예방, 교착 상태 회피, 교착 상태 탐지 및 복구, 교착 상태 무시가 있다.
3.1. 교착 상태 예방
: 교착 상태 필요 조건 중 하나를 거부하는 방식으로 예방하는 방법이다.
교착 상태는 발생하지 않으면 좋지만, 교착 상태가 발생하지 않는 환경을 만들어버린다면 자원을 효율적으로 사용할 수 없다.
e.g., 필요 조건 중 점유와 대기 조건을 거부해 한 Process가 자신이 필요한 자원을 모두 사용할 수 있을 때만 작업을 시작한다면 자원을 효율적으로 사용할 수 없다.
3.2. 교착 상태 회피
: 교착 상태를 인정하고 피해가는 방법으로 자원을 요청할 때마다 System의 상태를 판단하고 회피하는 전략을 사용한다.
☞ Overhead가 심하다.
e.g., 은행원 Algorithm
은행원 Algorithm : System을 안전 상태/불안전 상태(교착 상태가 발생할 가능성이 있는 경우)로 구분하고 불안전 상태일 때는 대기하고 안전 상태일 때만 자원을 빌려주는 Algorithm으로 할당한 자원 수 고정, Process 수 고정, 제한된 시간 안에 자원 반납 등의 많은 조건이 필요하다. ☞ 현실에서는 자원이 동적으로 왔다갔다해 현실적으로는 불가능한 Algorithm이다.
3.3. 교착 상태 탐지 및 복구
: 교착 상태가 발생한 것 같을 때 탐지하고 복구하는 방법으로 교착 상태가 자주 발생하는 System에서 일반적으로 사용하는 방법이다.
☞ 교착 상태 회피에 비해 Overhead가 적다.
교착 상태 탐지 : 교착 상태 존재 여부 및 교착 상태에 연관된 Process와 자원을 알아내는 전략을 사용하며 교착 상태의 4가지 필요 조건 중 순환 대기 존재 여부에 초점을 맞춰 교착 상태를 탐지한다. ☞ 탐지 Algorithm도 회피 Algorithm과 마찬가지로 Overhead가 있으므로 얼마나 자주(주기적으로, 자원 즉시 할당 여부에 따라, CPU 이용률에 따라 등) 탐지 Algorithm을 호출하는지가 관건이다. e.g., 자원 할당 그래프 소거
교착 상태 복구 : 순환 대기를 깨서 교착 상태로부터 회복하는 방식이다. e.g., 순환 대기가 깨질 때까지 Process 종료, 순환 대기에 포함된 Process 제어권 뺏고 Rollback ☞ 희생양이 될 Process는 남은 수행 시간, 자원 유형의 수 등 Systemp마다 다른 기준의 우선순위에 따라 결정된다. e.g., MySQL의 경우 Transaction Timeout시 교착상태이든 아니든 가장 작은 Transaction을 Rollback하며 Transaction의 크기는 삽입, 업데이트, 삭제된 행 수에 의해 결정된다.
Race Condition(경쟁 조건) : 여러 Process/Thread가 동시에 같은 Data를 조작할 때 타이밍이나 접근 순서에 따라 결과가 달라질 수 있는 상황
Synchronization(동기화) : 여러 Process/Thread를 동시에 실행해도 공유 Data의 일관성을 유지하는 것
Critical Section(임계 영역) : 공유 Data의 일관성을 보장하기 위해 한 번에 하나의 Precess/Thread만 진입해 실행가능한 영역
Mutual Exclusion(상호 배제) : 공유 Data의 일관성을 보장하기 위해 한 번에 하나의 Process/Thread만 진입해 실행할 수 있도록 하는 Algorithm
1. Mutual Exclusion을 보장할 수 있는 방법
: Lock을 사용한다.
// 실제 동작 Code가 아닌 개념 이해를 돕기위한 Code 입니다.
do{
acquire lock // 여러 Process/Thread가 Lock을 획득하기 위해 경합
critical section // Lock을 획득한 단 하나의 Process/Thread만이 Critical Section에 들어가 실행
release lock // Critical Section에서의 실행을 마치면 Critical Section을 빠져나오며 Lock 반환
reminder section
} while(TRUE)
Mutual Exclusion을 보장하는 상호 배제 기법으로는 Spin Lock, Mutex, Semaphore가 있다.
2. Spin Lock
: Lock을 획득할 수 있을 때까지 Lock 획득을 반복해서 시도하는 방식
☞ Lock을 획득하기 전까지 Lock이 다른 Process/Thread에 의해 선점되었는지 확인하는 것 자체가 CPU Cycle을 잡아먹는 일이기 때문에 CPU를 낭비한다.
Single Core에서는 Spin Lock으로 Lock이 반환되기를 계속 기다리더라도 Lock을 획득하기 위해서는 이미 누군가 획득한 상태인 Lock을 반환해야하는데 이는 결국 Context Switching이 필요하다. ☞ Single Core에서의 Spin Lock은 이점이 없다.
Multi Core에서는 Spin Lock으로 Lock이 반환되기를 기다리다가 Thread 1이 Lock을 반환하자마자 Thread 2가 Lock을 획득하므로 Context Switching이 일어나지 않는다.
2.1. 동작 예제
// 실제 동작 Code가 아닌 개념 이해를 돕기 위한 Code입니다.
volatile in lock = 0; // global -> 여러 Thread가 동시에 Lock에 접근 가능
// 여러 Thread가 호출할 함수
void critical(){
while(test_and_set(&lock) == 1); // 여러 Thread가 while loop를 통해 Lock을 획득하려 시도
... critical section // Lock 획득에 성공한 하나의 Thread가 Critical Section에 들어와 실행
lock = 0 // Critical Setcion에서 수행 완료 후 Lock 반환
}
// 실제 TestAndSet()의 동작 원리를 간단히 구현한 함수
// 공유되는 Lock에 대해 Lock의 원래 저장값을 반환하고 Lock 값은 1로 변경
int test_and_set(int* lockPtr){
int oldLock = *lockPtr; // 원래 가지고 있던 Lock 값 가져오기
*lockPtr = 1; // Lock 값을 1로 변경
return oldLock; // 원래 가지고 있던 Lock 값을 반환
}
2.2. 동작 과정
Thread 1이 먼저 수행된 후 Thread 2가 수행되는 경우
1. Thread 1의 test_and_set()의 반환값 = 0 (원래 Lock은 0으로 초기화 되어있었기 때문) 이므로 while loop 탈출해 Critical Section에서 작업을 수행한다.
☞ test_and_set()을 호출했으므로 Lock은 1로 변경된다.
2. Thread 2의 test_and_set()의 반환값 = 1 (1번 과정에서 Thread 1에 의해 Lock이 1로 변경되었기 때문) 이므로 while loop에 갇힌다.
☞ test_and_set()을 호출했으므로 Lock은 계속 1로 갱신된다.
3. Thread 1이 Critical Section에서 작업을 마치고 Lock을 반환한다.
☞ Lock이 0이 된다.
4. Thread 1이 Lock을 반환함과 동시에 Thread 2의 test_and_set() 반환값 = 0 (3번 과정에서 Thread 1에 의해 Lock이 0으로 변경되었기 때문) 이 되므로 while loop 탈출해 Critical Section에서 작업을 수행한다.
☞ test_and_set()을 실행했기 때문에 Lock은 1로 변경된다.
5. Thread 2가 Critical Section에서 작업을 마치고 Lock을 반환한다.
☞ Lock이 0이 된다.
∴ test_and_set()을 통해 Thread 1과 Thread 2가 Critical Section 안에서 동시에 작업을 수행할 수 없다. (= 상호 배제)
① 실행 중간에 간섭받거나 중단되지 않는다. ② 같은 Memory 영역에 대해 동시에 실행되지 않는다. ☞ 2개 이상의 Process/Thread에 의해 동시에 호출된다고 해도 CPU Level에서 알아서 먼저 하나 실행시킨 후 실행이 끝나면 이어서 다른 하나를 실행시키는 방식으로 동기화시켜 실행된다.
3. Mutex
: Lock이 다른 Process/Thread에 의해 획득된 상태라면 Lock이 반환될 때까지 Queue에서 대기하는 방식
☞ CPU Cycle을 불필요하게 낭비하는 것을 최소화한다.
3.1. 동작 예제
// 실제 동작 Code가 아닌 개념 이해를 돕기 위한 Code입니다.
Class Mutex{
int value = 1; // 이 값을 획득해야 Lock을 획득할 수 있다. (공유되는 Data)
// value를 변경할 때 Critical Section 안에서 변경하지 않으면 Race Condition이 발생할 수 있다.
int guard = 0; // Critical Section에 포함되어있는 value를 변경하기 위해 사용되는 변수
}
Mutex::lock(){
while(test_and_set(&guard)); // value 값 변경 전 guard를 획득하기 위해 여러 Process/Thread가 경합
// guard를 획득한 하나의 Process/Thread만 value 변경 Logic을 수행한다.
if (value == 0){ // 누군가 value를 이미 획득한 상태라면
현재 Thread를 Queue에 넣는다; // 작업을 잠시 멈추고 쉬고 있을테니 Lock이 풀리면 깨워달라며 Queue에 들어간다.
guard = 0; & go to sleep // Process/Thread를 Queue에 넣고 guard 변경(guard 반환)
}
else{ // value를 획득할 수 있으면
value = 0; // value 획득하고 value를 0으로 갱신(value 획득한 상태를 표시)한다.
guard = 0; // value 변경 후 guard 0으로 갱신(guard 반환)
}
Mute::unlock(){
while(test_and_set(&guard)); // value 변경 전 여러 Process/Thread가 guard를 획득하기 위해 경합
// guard를 획득한 하나의 Process/Thread만 value 변경 Logic을 수행한다.
if (Queue에 하나라도 대기 중이라면){
그 중 하나를 깨운다;
}
else{ // 대기중인 Process/Thread가 하나도 없으면
value = 1; // value를 1로 갱신(value 반환)
}
guard = 0; // value 변경 혹은 Queue에서 Process/Thread 꺼낸 후 guard 0으로 갱신(guard 반환)
}
mutex -> lock(); // 여러 Process/Thread가 Lock을 획득하기 위해 경합
... critical section // Lock을 획득한 하나의 Process/Thread가 Critical Section에 들어가 작업 수행
mutex -> unlock(); // Critical Section에서 작업을 마친 후 Lock 반환
Multi-Core 환경이고 Critical Section에서의 작업이 Context Switching보다 빨리 끝난다면 Spin Lock이 Mutex보다 더 이점이 있다.
Mutex와 Spin Lock의 Context-Switching
Mutex는 잠들고 깨는 과정(Queue에 넣고 빼는 과정)에서 Context Switching이 발생한다.
Spin Lock은 잠들고 깨는 과정(Queue에 넣고 빼는 과정)이 없기 때문에 Context Switching이 발생하지 않는다.
4. Semaphore
: Signal Mechanism을 가지는, 하나 이상의 Process/Thread가 Critical Section에 접근 가능하도록 하는 방법
4.1. 종류
Binary Semaphore(이진 세마포어) : 한 번에 1개의 Process/Thread만 Critical Section에 접근할 수 있다. ☞ Mutual Exclusion을 보장한다.
Counting Semaphore : 한 번에 value개의 Process/Thread만 Critical Section에 접근할 수 있다.
4.2. 동작 예제
// 실제 동작 Code가 아닌 개념 이해를 돕기 위한 Code입니다.
Class Semaphore{
// 한 번에 value개의 Process/Thread가 Critical Section에 접근할 수 있다.
int value = 1; // value를 획득해야 Lock을 획득할 수 있다. (공유되는 Data)
// value를 변경할 때 Critical Section 안에서 변경하지 않으면 Race Condition이 발생할 수 있다.
int guard = 0; // Critical Section에 포함되어있는 value를 변경하기 위해 사용되는 변수
}
Semaphore::wait(){
while(test_and_set(&guard)); // value 변경 전 guard를 획득하기 위해 여러 Process/Thread가 경합
// guard를 취득한 하나의 Process/Thread만 value 변경 Logic을 수행한다.
if (value == 0){ // 이미 누군가 value를 획득한 상태라면
현재 Process/Thread를 Queue에 넣는다; // Process/Thread가 일을 잠시 멈추고 쉬고 있을테니 Lock이 풀리면 깨워달라며 Queue에 들어간다.
guard = 0; & go to sleep; // Process/Thread를 Queue에 넣은 후 guard 변경(guard 반환)
}
else{ // value를 획득할 수 있다면
value -= 1; // value 획득한 후 value를 1 감소(value 획득한 상태를 표시)
guard = 0; // value 변경 후 guard 0으로 갱신(guard 반환)
}
}
Semaphore::signal(){
while(test_and_set(&guard)); // value 변경 전 guard 획득하기 위해 여러 Process/Thread가 경합
// guard를 획득한 하나의 Process/Thread만 value 변경 Logic을 수행
if (Queue 안에 하나라도 대기 중이라면){
그 중에 하나를 깨워 준비시킨다;
}
else{ // 대기중인 Process/Thread가 하나도 없으면
value += 1; // value 1 증가(value 반환)
}
guard = 0; // value 변경 혹은 Queue에서 Process/Thread 꺼낸 후 guard 0으로 갱신(guard 반환)
}
Semaphore -> wait(); // 여러 Process/Thread가 Lock을 획득하기 위해 경합
... critical section // Lock을 획득한 하나의 Process/Thread가 Critical Section에 들어가 작업 수행
semaphore -> signal(); // Critical Section에서 작업을 마친 후 Lock 반환
: 어떤 작업을 위해 실행할 수 있는 파일로 일반적으로 Application(End User가 사용할 수 있는 Software)이라고 많이 표현된다.
☞ Process를 이용해 실행시킨다.
2. 프로세스(Process)
: 컴퓨터에서 실행되고 있는 컴퓨터 프로그램으로 하나의 실행 단위가 된다.
☞ OS(Operating System)에서 실행 가능한 File을 Memory에 올리면 해당 File을 Process로 실행한다.
☞ 하나의 Application을 실행하면 최소 1개의 Process가 뜬다.
2.1. 구성 요소
Register : 명령이나 주소를 갖고 있는 CPU의 한 부분
Counter : Program 안에서 현재 어느 위치를 실행시키고 있는지 가리키는 용도로 사용
Stack : Function Call을 했을 때 Call Stack 등이 쌓이는 곳으로 지역 변수, 매개 변수, 반환값 등 일시적인 Data가 저장됨
Heap : Process가 가지고 있는 Memory 중 위쪽에 할당되어 있는 부분으로 동적으로 할당 가능한 Memory ☞ Memory Size에 제한이 없다.
Data : Static 변수, Global 변수 저장
Code : 실행 명령들을 포함하는 Code
2.2. 특징
각각 독립된 메모리 영역(Code, Data, Stack, Heap의 구조)을 할당받는다.
기본적으로 Process 당 최소 1개의 Thread를 가지고 있다.
각 Process는 별도의 주소 공간에서 실행되며, 한 프로세스는 다른 프로세스의 변수나 자료 구조에 접근할 수 없다.
한 Process가 다른 Process의 자원에 접근하려면 프로세스 간의 통신(IPC, Inter Process Communication)을 사용해야 한다. e.g., 파이프, 파일, 소켓 등을 이용한 통신 방법 이용
3. 스레드(Thread)
: Process 내에서 실행되는 여러 흐름의 단위
☞ Process는 여러 개의 Thread를 가질 수 있으며 Thread 간 자원을 공유하면서 동시에(Concurrency) 수행된다.
동시성(Concurrency) vs 병렬(Parallelism)
- 동시성(Concurrency) : 보이기에는 동시에 수행되는 것처럼 보이지만 실제로는 시간을 매우 잘게 쪼개서 CPU의 자원을 나눠서 쓰는 것 (진정한 의미의 병렬은 아님) Multi-Threading은 Concurrency에 가깝다.
- 병렬(Parallelism) : 실제로 동시에 수행되는 것 Multi-Processing은 Parallelism에 가깝다.
3.1. 특징
Thread는 Process 내에서 각각 Stack 영역만 따로 할당받고 Code, Data, Heap 영역은 공유한다.
한 Thread가 Process 자원을 변경하면, 다른 이웃 스레드(Sibling Thread)도 그 변경 결과를 즉시 볼 수 있다.
4. Thread vs Process
Process
Thread
의미
실행중인 Program
Process의 실행 단위
프로세스 종료 시간
오래 걸림
덜 걸림
생성 시간
오리 걸림
덜 걸림
Context Switching 소요 시간
오래 걸림
덜 걸림
Communication 측면에서의 효율성
떨어짐
효율적
자원 소비
더 많은 자원 소비
적은 자원 소비
메모리 공유
X
O
무게에 따른 이름
Heavy-weight Process
Light-Weight Process
전환 방식
OS의 Interface 사용
OS를 호출해 전환시킬 필요 없음
5. 멀티 태스킹(Multi Tasking)
: 한번에 여러 개의 Application을 실행시키는 것
☞ Multi-Processing과 Multi-Threading 기술이 가능해졌다고 설명할 수 있다.
Multi-Processing과 Multi-Threading
CPU의 최대 활용을 위해 프로그램의 둘 이상의 부분을 동시에 실행하는 기술 e.g., 하나의 Program 안에서 2개의 부분 동시 실행, 2개의 Program 동시 실행 등
5. 멀티 프로세스 (Multi Process)
: 하나의 응용프로그램을 여러 개의 프로세스로 구성해 각 프로세스가 하나의 작업(Task)을 처리하도록 하는 것
☞ Single Core에서 Multi Process 불가능
5.1. 장점 vs 단점
장점
단점
여러 개의 자식 Process 중 하나에 문제가 발생하면 그 자식 Process만 죽는 것 이상으로 다른 영향이 확산되지 않음
Context Switching에서의 Overhead : Context Switching 과정에서 Cache Memory 초기화 등 무거운 작업이 진행되고 많은 시간이 소모되는 등의 Overhead가 발생한다. Process는 각각의 독립된 Memory 영역을 할당받아 Process 사이에서 공유하는 Memory가 없으므로 Context Switching이 발생하면 Cache에 있는 모든 데이터 모두 리셋하고 다시 캐시 정보 불러와야 한다.
Process 사이의 어렵고 복잡한 통신 기법(IPC) : Process는 각각 독립된 Memory 영역을 할당받아 하나의 Program에 속하는 Process들 사이의 변수를 공유할 수 없다.
Context Switching (컨텍스트 전환, 작업 전환, 프로세스 전환) : 기본적으로 CPU의 자원을 Process/Thread에서 다른 Process/Thread로 전환하는 것으로 Context 전환을 통해 여러 Process가 단일 CPU를 공유할 수 있다. e.g., Process ↔ Process, Thread ↔ Thread, Process ↔ Thread ☞ Multi Tasking 운영체제의 주요 기능이다.
