5장. 비동기 연동, 언제 어떻게 써야 할까

1. 동기 연동과 비동기 연동

동기 방식은 요청을 보낸 뒤 결과가 올 때까지 기다린 뒤 다음 작업을 진행한다. 자연스럽지만 연동이 끝날 때까지 대기해야 하므로 자원을 비효율적으로 사용하게 되고 연동 실패 시 전체 기능이 함께 실패할 위험이 있다.

반면 비동기 방식은 외부 연동의 결과를 기다리지 않고 다음 작업을 바로 진행한다.

즉각적인 반응이 가능해 사용성(UX) 측면에서 유리하며 다음 조건에 해당할 경우 비동기 전환을 고려할 수 있다.

• 약간의 지연이 있어도 문제가 없는 경우
• 실패 시 재시도가 가능한 경우
• 실패 시 나중에 수동 처리할 수 있는 경우
• 실패해도 서비스 전체에 영향이 없는 경우

이런 조건을 만족하면 동기 연동 대신 비동기 연동을 고려하여 성능과 사용자 경험을 개선할 수 있다.

 

2. 별도 스레드로 실행하기

비동기 연동을 구현하는 가장 간단한 방법은 별도 스레드를 사용하는 것이다.

단, 스레드 내부에서 발생한 예외는 호출한 측에서 바로 감지하지 못하므로, 스레드 내부에서 예외 처리 로직을 직접 구현해야 한다.

짧은 작업이거나 간단한 백그라운드 처리라면 이 방식이 유용하다.

 

3. 메시징

메시징 시스템은 두 시스템 사이에 메시지 큐(미들웨어)를 두어 서로 직접 영향을 주지 않도록 하는 구조이다.

메시지는 큐에 저장되었다가 소비자 시스템의 처리 속도에 맞춰 전달된다.

장점은 다음과 같다.

• 연동 시스템 간의 의존성이 줄어들어 장애 전파 가능성이 감소
• 처리량이 늘어날 때 확장이 용이
• 전송 속도, 순서, 내구성 등 다양한 요구사항을 충족 가능

대표적인 메시징 도구는 다음과 같다.

• Redis Pub/Sub: 구조가 단순하고 고성능
• Kafka: 초대형 트래픽 처리(초당 수십~수백만 메시지)에 적합
• RabbitMQ: 트래픽은 적지만 메시지 순서 보장이 중요한 경우

메시징에서는 메시지 유실과 중복에 대비해야 하는데 중복 메시지가 발생할 수 있는 상황은 다음과 같다.

• 생산자가 같은 메시지를 두 번 보내는 경우
• 소비자 처리 중 오류가 발생해 메시지가 다시 수신되는 경우

따라서 소비자는 중복 처리 방지 로직(idempotency)을 반드시 고려해야 한다.

메시지가 실패했을 때의 처리 전략도 필요하다.

무시, 재시도, 실패로그 기록(별도 보관)과 같은 방식들이 있다.

메시지 종류는 크게 두 가지로 나뉜다.

• 이벤트(Event): 어떤 일이 발생했음을 알리는 메시지
• 커맨드(Command): 특정 작업을 수행하라는 요청 메시지

이벤트 기반 시스템에서는 여러 저장소들 간의 데이터가 시간이 지나면서 맞춰지는 궁극적 일관성(Eventual Consistency) 개념도 중요하게 적용된다.

 

4. 트랜잭션 아웃박스 패턴

트랜잭션 아웃박스 패턴은 데이터베이스 변경과 메시지 저장을 하나의 동일한 트랜잭션에서 처리한다.

이 방식의 목적은 메시지가 유실되거나 잘못된 상태로 보내지는 것을 방지하는 것이다.

아웃박스 테이블에 메시지를 기록한 뒤 트랜잭션 커밋이 완료되면 별도의 프로세스가 이 메시지를 읽어 메시징 시스템으로 전송한다.

전송에 성공하면 상태 값을 업데이트해 재전송을 방지한다.

메시지 전송 실패 시 재처리 전략:

1. 아웃박스 테이블에 상태 컬럼을 두고 전송 성공 여부를 관리
2. 마지막으로 성공적으로 전송한 메시지 ID를 저장하여 이어서 처리

이 패턴을 적용하면 메시지가 중복 전송될 가능성을 크게 줄이고 시스템 안정성을 높일 수 있다.

 

5. 배치 전송

배치 전송은 데이터를 일정 시간 동안 모아 두었다가 한 번에 전송하는 방식이다.

주로 파일 형태로 전달하며, 파일 형식은 다음과 같이 구분된다.

1. 구분자 기반 형식: 용량이 가장 작고 단순
2. 이름-값 쌍 방식: 위치와 상관없이 어떤 값인지 명확
3. JSON 형식: 대부분의 언어에서 쉽게 변환 가능하며 구조화된 데이터 전달에 적합

배치 전송에서는 다음 요소를 함께 정의해야 한다.

• 송수신 주체
• 전송 시간
• 전송 경로 및 방식

파일 외에도 API를 이용한 배치 처리, 혹은 데이터베이스 Read-only 접근 방식도 가능하지만 보안 정책을 반드시 고려해야 한다.

배치 전송 실패 시에는 다음 처리가 필요하다.

• 일정 시간 후 재전송
• 수동 재처리 기능 제공
• 파일 또는 API를 통한 예외 데이터 재전송 기능

 

6. CDC(Change Data Capture)

CDC는 데이터베이스에서 발생한 변경 사항을 추적하여 외부 시스템에 전달하는 방식이다.

DBMS가 제공하는 변경 이벤트 기능을 활용하며, 변경된 데이터는 레코드 단위로 전달된다.

전달 방식은 다음 두 가지로 구분된다.

• 변경 내용을 그대로 전파하는 방식(1:1 전달)
• 여러 변경을 모아 가공하여 전파하는 방식(데이터 변환 포함)

CDC는 특정 작업을 실행시키는 명령보다는 "어떤 변화가 있었는지" 알리는 이벤트 메시지에 가깝다.

데이터 실시간 동기화나 로그 기반 ETL(Environment)에서 자주 활용된다.