Synchronous vs Asynchronous / Blocking vs Non-Blocking

[iamabear09]

Synchronous

어원

• [syn 같이] + [chron 시간] + [ous 형용사 ]
• 같은 연속적인 시간에 반복되는

두 개 이상의 작업

• Synchronous의미에는 같이라는 의미가 포함되어있다.
• 따라서 Synchronous, Asynchronous는 적어도 두 개의 작업이 있어야 Synchronous인지 Asynchronous 인지 얘기할 수 있다.

Synchronous 의미

• 작업을 수행하는 두 개 이상의 주체가 서로 동시에 수행하거나, 동시에 끝나거나, 끝나는 동시에 시작하는 것

Asynchronous

Asynchronous의미

• 비동기 작업은 두 주체가 서로의 시작, 종료 시간과는 관계 없이 별도의 수행 시작/종료 시간을 가지고 있을 때
• 다른 주체의 작업 결과를 조회해서 처리할 수 도 있고 처리하지 않을 수 도 있다.

작업 결과 처리X - Write 작업 작업 결과 처리O - Message queue에 작업 결과가 등록되는 경우

Synchronous & Asynchronous & Blocking & Non-Blocking 조합

💻참고자료

https://deveric.tistory.com/99

[iamabear09]

동기 & 비동기에 대한 생각 정리

Synchronouse

두 개 이상의 주체가 서로 동시에 수행하거나, 동시에 끝나거나, 끝나는 동시에 시작하는 것 즉 두 작업의 시작 종료 시간이 관련되어있다.

🙋‍♂️ 왜 동기적인 로직이 나오게 되었을까...? A가 작업을 진행하기 위해서 B의 작업 결과 필요한 경우, 동기 로직 구현이 가장 기본적인 생각이다.

동기 로직이 좋아서 동기 로직을 사용하는 것이 아니다. 과거에도 작업의 결과가 필요하지 않거나 확인할 필요가 없다면 비동기 적으로 구현했다.

🙋‍♂️ 만약 오래 걸리는 작업이 진행되는 동안 다른 작업을 한다면...? Synchronouse하다고 가정하면, B의 작업이 끝나는 순간 A는 다음 작업을 진행할 것이다.

만약 기다리는 동안 다른 작업을 하게 된다면, 해당 작업은 B의 작업이 끝나는 즉시 현재 작업을 멈추고 원래 작업을 진행해야 한다. 하지만, 그런 작업을 그렇게 중단할 거면 그냥 다른 Thread에서 온전하게 실행되도록 하는 것이 맞다.

B의 작업이 끝나는 순간 을 알기 위해서

1. CPU를 차지하고 계속 Polling 할 수 있다. (비 효율적이다.)
2. CPU를 양보하고 Blocking 되어서 Interrupt를 기다릴 수 있다.

따라서 Synchronouse & Blocking 이 일반적인 조합이다.

🙋‍♂️진행 중인 작업을 다 완료하고 B의 결과를 확인해서 기존 작업을 수행한다면...? 이것이 바로 Asynchronouse 이다. 따라서, 왜 Asynchronouse & Non-Blocking 조합이 자연스러운지 알 수 있다.

Asynchronouse

두 주체가 서로의 시작, 종료 시간과는 관계 없이 별도의 수행 시작/종료 시간을 가지고 있는 경우이다.

Asynchronouse 하다고 해서 A가 B의 작업의 결과를 신경 쓰지 않는다는 말은 아니다.

• 계속 Polling 만하면서 B의 작업이 완료되기 까지 기다린다면 → Non-Blocking Sync
• 다른 일을 하면서 중간 중간 B가 작업이 완료되었는지 한번씩 Polling 한다면 → Async

하지만, A가 B의 작업 결과를 신경쓰지 않는다면 반드시 Asynchronouse 하다. A가 B의 작업 결과를 신경쓰지 않는다면

• B는 A가 요청한 즉시 작업을 시작해도 된다.
• 하지만 B는 A가 요청한 이후 나중에 시작해도 전혀 상관이 없다.

🙋‍♂️만약 기다리는 동안 할 작업이 없다면...? 이것이 Non-blocking Sync 이다.

🙋‍♂️만약 중간에 할 일을 금방 하고 B의 작업만 기다린다면...? 이건 결과를 요청하는 시점에서 Blocking 되긴 한다.. 이것을 Async Blocking 이라고 해야 하나? 만약 B가 작업을 시작하는 시점부터 종료 시점까지 Blocking 되면 Async Blocking이 확실한데... 애매한 것 같다.

[iamabear09]

글을 적고 보니 이상한 지점 발견

다시 생각해야 하는 지점

Asynchronouse 하다고 해서 A가 B의 작업의 결과를 신경 쓰지 않는다는 말은 아니다.

• 계속 Polling 만하면서 B의 작업이 완료되기 까지 기다린다면 → Non-Blocking Sync
• 다른 일을 하면서 중간 중간 B가 작업이 완료되었는지 한번씩 Polling 한다면 → Async

🙋‍♂️만약 중간에 할 일을 금방 하고 B의 작업만 기다린다면...? 이건 결과를 요청하는 시점에서 Blocking 되긴 한다.. 이것을 Async Blocking 이라고 해야 하나? 만약 B가 작업을 시작하는 시점부터 종료 시점까지 Blocking 되면 Async Blocking이 확실한데... 애매한 것 같다.

작업의 결과가 필요한 Async에서 Polling 을 통해 다른 작업 확인하면서 진행 시

• 작업이 일찍 끝나는 경우 → Sync Non-Blocking이 되고
• 작업이 늦게 끝나는 경우 → Asyn Non-Blocking이 된다.

🙋‍♂️Async란 결과를 신경 쓰지 않는것 이라고 정의해야 하나...?

이렇게 정의하면 Sync는 결과를 신경 쓰는 것이고, 따라서 Non-Blocking Sync 로직에는

• 다른 작업을 하면서 중간중간 Polling을 통해 작업 완료를 확인하는 것
• Polling만 하면서 작업 완료를 기다리는 것 두 가지가 될 것이다.

작업의 결과를 신경쓰지 않는다면, 두 작업의 시작 및 종료 시점은 상관이 없어진다.

🙋‍♂️기존 Sync에서 Async로의 변화...? 기존 Sync로직을 작성한 이유는 작업의 결과가 있어야 다음 동작을 수행할 수 있기 때문이였는데 콜백 함수 즉, 작업의 결과로 어떤 동작을 수행해야 하는지 까지 같이 전달하면서 작업의 결과를 기다릴 필요가 없어졌다.

질문

Async란 작업의 결과를 신경 쓰지 않는 것 일까? 아니면, 두 작업의 시작 종료 시점이 상관 없는 것일까?

[iamabear09]

비동기 로직의 종류를 모아보자.

Kafka 에서 Producer가 Message를 전송하는 경우

• 작업의 결과를 신경 쓰지 않는다.
• 두 주체는 Main Thread와 Network I/O Thread 이다.

🙋‍♂️ 다른 Thread에서 작업을 시키면 Async 일까?

• 대부분 다른 Thread에서 나머지 작업을 수행하는 것 같다.
• 하지만, 다른 Thread 작업의 결과가 필요해서 기다린다면
  • Async를 "결과를 신경 쓰지 않는 것"으로 정의했을 때 → Sync Non-Blocking이 된다.
  • Async를 "시간의 불일치"로 정의했을 때 → Async Blocking이 된다.

[iamabear09]

Synchronouse programming

• 여러 작업들을 순차적으로 실행하도록 개발

Asynchronouse Programming

• 여러 작업(Task)들을 독립적으로 실행하도록 개발
• 여러 작업(Task)들이 독립적으로 실행되도록 하는 방법은 여러가지가 될 수 있다.

📌Asynchronouse Programming V1

• 하나의 Thread에서 차례차례 수행했을 동작을 다른Thread에서 독립적으로 수행 시킨다
• 다른 Thread에 작업을 시킴으로서 여러 작업들이 독립적으로 실행될 수 있다.

📌Asynchronouse Programming V2

• Task 마다 Thread를 할당한다.
• 실제로 물리적인 Thread 수가 여러 개 이고, 각각의 작업이 병렬로 실행된다면 수행 시간이 더 단축 될 수 있다.
• 하지만, Thread를 많이 생성하므로 메모리를 상대적으로 많이 차지하게 되고 Context Switching 비용이 발생하게 된다.

📌Asynchronouse Programming V3

• 햇반 데우기는 전자레인지에 넣고 기다리면 된다. 따라서, 기다리는 동안 다른 일을 할 수 있다.
  • 친구(Thread)가 해주지는 않지만, 전자레인지(I/O 컨트롤러)가 해당 일을 해준다. 따라서 다른 일을 할 수 있다.
  • I/O 작업도 CPU가 하는 것이 아닌 다른 장치가 해준다. 따라서 Non-Blocking I/O를 이용하고 다른 일을 하면 된다.
• 국 끓이기는 국에 불을 올리고 기다리면 된다. 따라서 기다리는 동안 다른 일(CPU를 사용하는 일)을 할 수 있다.
  • Thread는 아니지만, 가스레인지가 해당 일을 해준다.
  • Non-Blocking I/O 를 사용하고 기다리는 동안 다른 일(CPU를 사용하는 일)을 하면 된다.

📌Asynchronouse Programming V4

• 굳이 혼자할 필요 없다. 따라서 다른 친구(다른 Thread)와 함께 작업을 한다.
• 이때, I/O 작업은 Non-Blocking I/O를 통해 진행한다.
  • 나는 햇반을 전자레인지에 넣고 (Non-Blocking I/O) 김치를 썬다 (CPU 작업)
  • 친구도 국을 가스레인지에 올려놓고 (Non-Blocking I/O) 스팸을 굽는다 (CPU 작업)

Asynchronouse Programming != Multi-threading

Asynchronouse Programming

• 여러 작업을 동시에 실행하는 프로그래밍 방법론

Multi-threading

• Asynchronouse Programming 의 한 종류이다.

Asynchronouse Programming 을 가능하게 하는 것

Multi-Threads Multi-Threads만 있다고 하더라도 비동기 프로그래밍이 가능하다. Asynchronouse Programming V1 & V2 에서 예시를 살펴봤다.

Non-block I/O Non-block I/O만 있다고 하더라도 비동기 프로그래밍이 가능하다. Asynchronouse Programming V3 에서 예시를 살펴봤다.

Multi-Threads & Non-block I/O 하지만 Multi-Threads 와 Non-block I/O 모두 적절하게 섞는 것이 가장 효율적인 방법이 된다. Asynchronouse Programming V4 에서 예시를 살펴봤다.

I/O 관점에서 Synchronouse & Asynchronouse

case 1

Synchronouse I/O

• block I/O

Asynchronouse I/O

• non-block I/O

case2

Synchronouse I/O

• 요청자가 I/O 완료 또는 결과 까지 챙겨야 하는 경우 Asynchronouse I/O
• 완료를 noti 주거나 결과를 callback으로 처리할 수 있도록 하는 경우

I/O Multiplexing은 요청자가 결과를 직접 챙겨야 한다. 또한,

case3

Asynchronouse I/O

• Block I/O를 다른 Thread에서 실행하는 경우

백엔드 아키텍처 관점에서 Synchronouse & Asynchronouse

Synchronouse Communication

• A에서 B가 관심 있는 Event가 발생하면, B의 API call을 통해서 Event를 전달한다.
• 문제는 B의 API 동작에 문제가 발생하는 경우 해당 문제가 A 까지 전파된다.

Asynchronouse Communication

• 다른 Service의 문제가 전파되는 것을 막기 위해 Asynchronouse Communication 하는 것이 중요하다.
• 이렇게 하기 위해 Message Queue를 사용한다.

Message Queue가 도입됨으로서 API call의 결과를 기다리지 않아도 된다.

🙋‍♂️ 만약 B의 API call 호출의 결과가 필요하다면...?

1. Synchronouse Communication을 사용한다.
2. 이때도 Message Queue를 도입한다. 하지만, 이 경우 결과의 신속한 처리가 늦어질 수 있다.

참고자료

https://www.youtube.com/watch?v=EJNBLD3X2yg

[iamabear09]

I/O 종류

• network (socket)
• file
• pipe
• device (키보드 & 모니터...)

Block I/O

network socket 에서 block I/O 란..?

• read() 호출 시 recv_buffer에 데이터가 없으면 데이터가 계속 들어올 때 까지 block 된다.
• write() 호출 시 send_buffer에 데이터가 가득차 있으면 공간이 나올 때 까지 block 된다.

non-blcok I/O

block I/O와 다르게 요청에 대한 현재 상태를 즉시 리턴 한다.

1. read non-blocking system call
2. kernel 에서 데이터가 준비되지 않았으므로 -1 return
3. 바로 return 되었으므로 Thread는 다른 동작 수행 가능
4. kernel은 데이터를 준비 해 놓는다.
5. 시간이 지나고 다시 read non-blocking system call
6. 데이터 read 완료

network socket 에서 non-block I/O 란..?

• read() 호출 시 recv_buffer에 데이터가 없으면 데이터가 없다고 알려주고 read system call은 바로 종료된다.
• write() 호출 시 send_buffer에 데이터가 가득차 있으면 공간이 없다고 알려주고 write system call은 바로 종료된다.

non-block I/O에서 I/O 작업의 완료를 어떻게 확인할 것인가...?

1. 작업 완료를 계속 확인

• 완료된 시간과 완료를 확인하는 시간의 갭 으로 인해 처리 속도가 느려질 수 있다.
• 완료되었는지 반복적으로 확인을 해야 하므로 CPU가 낭비된다.

2. I/O multiplexing

관심있는 I/O 작업들을 동시에 모니터링 하고 그 중 완료된 I/O 작업을 한번에 알려준다.

여러 socket에 대해서 read system call 호출 시 Thread Blocked or Thread Run 모두 가능하다.

1. kernel은 데이터가 준비되면 thread를 깨워서 알려준다.
2. 깨어난 Thread 데이터를 차례로 읽어와서 처리하면 된다.

I/O multiplexing 종류

• select & poll
• epoll & kqueue & IOCP

epoll 동작

1. socket에 read 이벤트가 발생하면 알려 달라고 epoll에 등록한다.
2. 클라이언트가 요청 전송 (특정 socket에 read 이벤트 발생)
3. epoll은 Thread를 깨워주고 어느 소켓에 데이터가 있는지 알려준다.
4. Thread는 해당 정보를 바탕으로 해당 소켓들만 처리를 해주면 된다.
   • 이때 Thread Pool이 있다면 이러한 요청을 Thread에 할당하면 된다.

3. Callback / Signal 사용

1. aio_read non-blocking system call
2. Therad는 자신의 할 일을 한다.
3. 데이터가 완료되면 callback을 통해 처리된다.

I/O 구분의 논란...

I/O multiplexing 이 왜 Non-blocking 인가?? 이건 오히려 Sync & Non-blocking 에 가깝다, 이유1. I/O multiplexing 시 결과를 직접 요청자가 직접 챙긴다. 이유2. I/O multiplexing 시 구현에 따라서 Non-blocking 모드가 될 수 있다.

참고 자료

https://www.youtube.com/watch?v=mb-QHxVfmcs

[iamabear09]

Sync, Async, Blocking, Non-blocking

Sync, Async 판단 기준은 "내가 결과를 가만히 기다리고 있는가" 를 생각해보면 된다.

1. I/O multiplexing

• 내가 결과를 멈춰서 기다리지 않는다. → Async
• 하지만, 각각의 Socket은 Blocking I/O이다.

➡️ Async & Blocking

2. Async DB 통신

상황

• DB와 3번의 통신을 통해 값을 가져와야 한다.

구현

• 3번의 요청을 다른 Thread를 이용해 동시에 요청 → Async
• 하지만 각각의 Thread는 결국 Blocking I/O를 호출 한다.

➡️ Async & Blocking