Reliable vs Unreliable RPCs

RPC(Remote Procedure Call)는 네트워크를 통해 원격 시스템의 함수를 호출하는 기술입니다.
RPC를 사용할 때 신뢰성(Reliability)을 보장하는 방식과 그렇지 않은 방식으로 나뉘는데, 이를 Reliable RPC와 Unreliable RPC라고 합니다.

Reliable RPCs

Reliable RPC는 메시지 전송의 성공 여부를 보장하는 RPC 방식입니다.
즉, 원격 호출이 성공적으로 수행될 때까지 재전송(Retry)과 확인(Acknowledgment) 등의 메커니즘을 사용하여 신뢰성을 보장합니다.

• 특징

1. 메시지의 전송 보장(Delivery Guarantee): 최소 1회 이상 전송됨(At-Least-Once)
2. 응답을 받을 때까지 재전송(Retry) 수행
3. 네트워크 장애 시 Failover 지원 가능
4. 트랜잭션(Transactions)과 데이터 일관성 유지 가능
5. 응답을 보장하기 때문에 지연 시간이 비교적 길어질 수 있음

• 단점
  Reliable을 남용한다면 성능 저하를 야기할 수 있습니다.
  Reliable RPC를 너무 많이 사용하면 네트워크 Packet Queue(Buffer)를 채워 다른 메시지를 막아버릴 수 있습니다. 그러므로 RPC를 Reliable로 지정하는 것은 필요한 경우에 한정해야 합니다. 반드시 도달해야 하는 Event에만 사용하는 것이 좋습니다.

Reliable RPC를 사용해야 하는 경우

- 1. 금융 거래 시스템

예: 은행 송금, 온라인 결제 API
데이터 손실이 발생하면 심각한 문제가 생기므로 반드시 응답을 보장해야 함.
메시지가 중복으로 전송될 가능성이 있으므로 Idempotency(멱등성)을 고려해야 함.

- 2. 데이터 일관성이 중요한 시스템

예: 주문 시스템, 재고 관리 시스템
메시지가 반드시 한 번 이상 전송되어야 하며, 데이터 무결성이 필요함.

- 3. Failover가 필요한 서비스

예: 마이크로서비스 간의 신뢰성 있는 통신
gRPC와 같은 프레임워크를 사용하여 자동 재시도 및 장애 복구 기능을 활용.

Unreliable RPCs

Unreliable RPC는 메시지 전송의 성공 여부를 보장하지 않는 RPC 방식입니다.
즉, 메시지를 보낸 후 응답을 기다리지 않거나, 응답이 오지 않아도 재시도하지 않습니다.

• 특징

1. 빠른 응답 속도(Low Latency)
2. Best-Effort Delivery (최선의 노력으로 보냄, 실패 여부 확인 X)
3. 메시지 손실 가능성 있음
4. 대량의 요청을 처리할 때 오버헤드가 적음

• 단점
  네트워크가 해당 Packet을 Drop하면 재전송하지 않고, 순서도 보장하지 않습니다.
  그러므로 Unreliable RPC는 빈도가 높고 약간 손실되어도 이상없는 Event에 적합합니다.

Unreliable RPC를 사용해야 하는 경우

- 1. 실시간 스트리밍

예: 온라인 게임, 비디오 스트리밍
약간의 데이터 손실이 발생해도 서비스가 정상적으로 동작해야 하므로 빠른 전송이 중요함.

- 2. 로그 수집 시스템

예: ELK Stack(Elasticsearch, Logstash, Kibana), Fluentd
로그 데이터는 일부 유실되더라도 큰 문제가 되지 않으며, 빠른 처리가 중요함.

- 3. IoT 센서 데이터 전송

예: 스마트홈 기기, 공장 자동화 시스템
네트워크 상태가 불안정할 수 있기 때문에 빠르게 데이터를 보내고, 일부 손실을 허용.

비교

RPC를 사용할 때 신뢰성이 중요한지, 속도가 중요한지에 따라 선택해야 합니다.

Reliable RPC는 금융, 트랜잭션, 데이터 무결성이 중요한 경우 사용.
Unreliable RPC는 실시간 데이터 전송, 로그, 스트리밍과 같은 경우 사용.

Unreal Engine C++에서는 RPC를 별도로 지정하지 않으면 기본적으로 Unreliable로 간주됩니다. UFUNCTION 매크로에 Reliable 키워드를 추가해야 Reliable이 됩니다.

UFUNCTION(Client, Reliable)
void Client_ShowGameOver();  // Client RPC, Reliable

Best Practice

Client → Server RPC (플레이어 입력)

자주 발생하는 입력 (Unreliable)
예: 캐릭터 이동, 연속 공격
빠른 처리가 중요하고, 어차피 다음 입력이 곧 올 것이므로 손실을 허용 가능

중요한 입력 (Reliable)
예: NPC 대화 선택, 문 열기
꼭 전달되어야 하는 액션은 Reliable로 처리

Server → Client RPC (서버가 클라이언트에게 전달)

반드시 전달할 이벤트 (Reliable)
예: 게임 오버, 큰 보상 획득
중요한 알림은 클라이언트가 확실히 받아야 함

자주 발생하는 사소한 이벤트 (Unreliable)
예: 피격 소리 재생, 작은 효과
손실되더라도 문제없는 이벤트는 Unreliable로 처리해 성능 최적화

Multicast RPC (Server → 모든 클라이언트)

중요한 글로벌 이벤트 (Reliable)
예: 보스 등장 알림, 특정 이벤트 발생
모든 플레이어가 알아야 하는 중요한 이벤트는 Reliable로 보냄

자주 발생하는 효과 (Unreliable)
예: 총구 섬광, 폭발 효과
지속적으로 발생하는 그래픽 효과는 빠르게 처리하는 것이 중요

추가 개념: Property Replication

구조적으로 Unreliable과 비슷하지만, 상태 업데이트를 계속 보내므로 최신 값은 결국 전달됨.
Reliable RPC는 중요한 상태 변화에 사용하고, 지속적인 상태는 Replication으로 유지하는 것이 효율적.
너무 자주 Reliable RPC를 보내는 것은 성능 문제를 유발할 수 있음 → 필요하면 RepNotify 사용.

정리

Reliable RPC → 드물지만 중요한 이벤트 (누락 되거나 손실 되면 안돼는 정보들)
Unreliable RPC → 자주 발생하고 손실 허용 가능한 업데이트