Synchronous vs Asynchronous

들어가며

https://eelseungmin.tistory.com/28

Block I/O vs Non-Block I/O

저번주에 Block, Non-Block I/O에 대해 글을 작성했었는데 이번엔 해당 개념들과 연관이 깊은 동기, 비동기에 대해 정리해 보았다.

Synchronous와 Asynchronous는 각각 동기와 비동기로 번역되며, 작업 완료 순서의 보장 여부에 따라 두 방식을 구분하게 된다.

 

동기와 비동기

프로그래밍 관점

다음 그림을 살펴보자.

각각의 케이스를 동기와 비동기를 줄여서 s1, a1~a4로 표현하였다.

모든 작업은 같은 시작점에서 출발하고, 각각의 작업들은 A, B, C, D라는 스레드가 나누어서 작업하며 모두 독립적으로 수행될 수 있다고 가정했을 때, 방식에 따라 다음과 같은 결과를 예상해 볼 수 있다.

다음은 각 케이스에 간단한 설명을 덧붙인 것이다.

• s1: 작업 순서를 보장하기 위해 하나의 작업이 끝나야 다음 작업을 수행하므로 수행시간이 현저히 길다.
• a1: 작업 순서를 보장하지 않지만 두 스레드가 작업을 나누어 수행하므로 수행시간이 s1에 비해 큰 폭으로 줄었다.
• a2: 각 작업마다 다른 스레드를 할당한다. 수행시간이 매우 빠르지만 그만큼 많은 자원을 필요로 한다는 단점이 있다.
• a3: 하나의 스레드만 사용하되 Non-Block I/O를 조합해서 s1보다 수행시간이 훨씬 빠르다.
• a4: 멀티스레딩과 Non-Block I/O를 조합한다. a3보다 수행시간이 더욱 단축되었다.

결과적으로 a4가 가장 괜찮은 방법인 것처럼 보인다. 다만 a4의 경우 스레드가 너무 많아지면 context switching 비용이 증가하므로 적정 개수를 사용해야 하고, race condition에 대한 고려도 필요하므로 주의해야 한다.

 

아키텍처 관점

동기식 커뮤니케이션

이제 백엔드 아키텍처 관점에서 살펴보자.

다음 그림은 최근 규모가 큰 서비스에서 채택하는 MSA 구조에서 동기식 커뮤니케이션이 이루어질 경우이다. 다른 서비스로 API 요청을 보낸 뒤 정상 응답을 받아 다음 작업을 진행하는 방식인데, 해당 방법의 경우 B나 C에서 장애가 발생하고 이에 대한 대처가 되어있지 않을 경우 A나 B에도 장애가 전파될 수 있다는 단점이 있다.

 

비동기식 커뮤니케이션

다음 그림은 MSA 구조에서 비동기식 커뮤니케이션 방식을 채택할 경우이다. 해당 구조에서는 A가 작업을 하다가 B가 필요할만한 이벤트가 발생하면 B로 향하는 메시지 큐에 이벤트를 전달하기만 한다. B와 C 사이에서도 마찬가지로 동작한다. 이러한 구조로 커뮤니케이션을 하게 되면 설령 B나 C에 장애가 발생하더라도 A나 B에 장애가 전파되지 않는다는 장점이 있다.

다만 이러한 방식은 이해를 돕기 위해 극단적으로 구성한 것이고, 가령 A에서 B에서 제공하는 데이터가 필요하다고 하면 메시지 큐를 활용한 방식보다는 API 호출을 통해 데이터 전달을 수행하는 것이 빠를 것이다. 이때 장애가 전파되지 않도록 예외 처리에 신경을 써서 개발하는 것이 핵심이다.