gRPC vs REST

1. RPC(Remote Procedure Call)란?

• 정의: 원격 프로시저 호출. 네트워크로 연결된 다른 서버의 함수/메서드를 마치 로컬 환경의 함수처럼 직접 호출하는 기술
• 특징: 개발자가 소켓 통신, 직렬화/역직렬화 같은 하위 네트워크 계층을 직접 다루지 않고도 원격 메서드를 실행할 수 있도록 추상화 제공

2. REST vs gRPC 핵심 개념

REST (Representational State Transfer)

• 웹의 표준 아키텍처 스타일로, 자원(Resource) 중심의 통신 방식
• URI로 자원을 명시하고, HTTP 메서드(GET, POST, PUT, DELETE)를 통해 행위를 정의
• 데이터 포맷으로 주로 사람이 읽기 쉬운 JSON을 사용
• 브라우저 호환성이 뛰어나고 직관적이지만, 텍스트 기반 직렬화/역직렬화 오버헤드가 발생하며 기본적으로 단방향(Request-Response) 통신 위주

gRPC (Google Remote Procedure Call)

• 구글이 개발한 고성능 오픈소스 RPC 프레임워크로, 동작(Action/Procedure) 중심의 통신 방식
• 전송 계층으로 HTTP/2를 채택하여 멀티플렉싱(Multiplexing), 헤더 압축 지원
• 데이터 직렬화에 바이너리 포맷인 Protocol Buffers(Protobuf)를 사용하여 페이로드 크기가 작고 속도가 빠름
• IDL(.proto 파일)을 기반으로 다양한 언어의 통신 코드(Stub/Skeleton)를 자동 생성해 엄격한 타입 안정성(Type-safe) 제공
• 단항(Unary) RPC뿐만 아니라 양방향 스트리밍(Bidirectional Streaming) 지원

3. 핵심 비교 요약

4. 언제 어떤 기술을 선택해야 할까?

• REST API를 권장하는 경우:

  • 공개 API(Public API), 웹 프론트엔드-백엔드 간 통신처럼 범용적인 클라이언트 호환성이 필요할 때
  • 인프라 설정이 간단하고, 표준 브라우저 환경에서 직접 호출해야 할 때
  • 캐싱(HTTP Caching)을 적극적으로 활용해야 하는 정적/준정적 리소스 중심 서비스

• gRPC를 권장하는 경우:

  • MSA(마이크로서비스 아키텍처) 환경에서 내부 서비스 간의 고성능·저지연 통신이 필수적일 때
  • 대용량 데이터 전송이나 실시간 스트리밍(양방향 데이터 동기화)이 필요할 때
  • Polyglot(다양한 개발 언어 사용) 환경에서 엄격한 스키마 공유와 타입 안정성을 유지하고 싶을 때

References

• gRPC Official Documentation
• AWS: What's the Difference Between gRPC and REST APIs?
• GeeksforGeeks: Remote Procedure Call (RPC) in Operating System

발단

• 데이터베이스 인스턴스를 띄워두고 rabbitmq 3개를 한 서버에 밀어넣어 사용중이었음
• 그런데 계속 커넥션이 끊기는 것 같아, 분산 처리를 위해 각 서버에 띄우려고 했음
• 그러다 보니, 집 ip 내부의 private ip에 있는 노드와 클라우드 위의 컨테이너를 어떻게 서로 하나의 클러스터로 묶을지 고민하게 됨

방법

• tailscale 이라는 vpn 서비스를 통해 각 서버들을 하나의 가상 네트워크로 묶어버림
• 이렇게 되면 가상 ip 가 발급되고, 같은 vpn 내부의 노드끼리는 찾아갈 수 있음
  • 외부에서 해당 ip 로는 당연히 못 찾아감

• 따라서 가상 네트워크로 묶을 모든 노드에 하나씩 설치하고 아래 방식으로 하나씩 인증해 묶으면 됨

curl -fsSL https://tailscale.com/install.sh | sh

• 설치 완료 후 tailscale up 하면 브라우저로 인증 후 하나의 계정 아래에서 묶어 사용할 수 있게 됨

  sudo tailscale up

• 가상 ip를 찾는 방

  • 100.xxx.xxx.xx 처럼 나옴

sudo tailscale status

포트 오픈

• vpn 내부에서만 통신 가능하게 적용
  • public ip 혹은 포트포워딩이 필요 없음
  • NAT을 우회해 암호화 터널을 통과하기 때문

# Tailscale 인터페이스(tailscale0)를 통한 모든 접속 허용

sudo ufw allow in on tailscale0

• rabbitmq 포트 설정

컨테이너 설정

# 클라우드 서버 (rabbitmq-1) docker-compose.yml
services:
  rabbitmq-1:
    image: rabbitmq:3.13.3-management
    container_name: rabbitmq-1
    hostname: rabbitmq-1
    restart: always
    environment:
      - RABBITMQ_ERLANG_COOKIE=rabbitmqCookie
      - RABBITMQ_DEFAULT_USER=dong
      - RABBITMQ_DEFAULT_PASS=dong
    ports:
      - 15672:15672
      - 5672:5672
      - 4369:4369
      - 25672:25672
    extra_hosts:
      - "rabbitmq-2:192.168.0.11"
      - "rabbitmq-3:192.168.0.12"


# 개인 서버 2 (rabbitmq-3) docker-compose.yml
services:
  rabbitmq-2:
    image: rabbitmq:3.13.3-management
    container_name: rabbitmq-2
    hostname: rabbitmq-2
    restart: always
    environment:
      - RABBITMQ_ERLANG_COOKIE=rabbitmqCookie
      - RABBITMQ_DEFAULT_USER=dong
      - RABBITMQ_DEFAULT_PASS=dong
    ports:
      - 5672:5672
      - 4369:4369
      - 25672:25672
    extra_hosts:
      - "rabbitmq-1:192.168.0.10"
      - "rabbitmq-3:192.168.0.12"

클러스터 조인

docker exec -it rabbitmq-2 rabbitmqctl stop_app
docker exec -it rabbitmq-2 rabbitmqctl join_cluster rabbit@rabbitmq-1
docker exec -it rabbitmq-2 rabbitmqctl start_app

docker exec -it rabbitmq-3 rabbitmqctl stop_app
docker exec -it rabbitmq-3 rabbitmqctl join_cluster rabbit@rabbitmq-1
docker exec -it rabbitmq-3 rabbitmqctl start_app

• 상태확인

docker exec -it rabbitmq-1 rabbitmqctl cluster_status

Graceful Shutdown

• 취소 가능한 컨텍스트 생성
  • 컨텍스트와 취소 함수가 리턴됨
  • 종료 시그널 감지 시 취소 함수 실행

ctx, cancel := context.WithCancel(context.Background()) defer cancel()

신호 감지

• ctrl + c -> 운영체제에서 취소 신호(interrupt 신호)를 프로세스로 넘겨줌
• signal.Notify는 신호를 감지하면 받아서 sigChan 이라는 채널로 넘겨줌

sigChan := make(chan os.Signal, 1) 
signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)

신호 감지 고루틴

• 신호가 들어올때까지 sig := <- sigChan은 기다림
  • Buffered Channel 로 생각하면 될듯
• 취소 신호(interrupt 신호)를 감지하면 signal.Notify로 sigchan 채널에 취소 신호를 넘김
• sigChan 채널의 값을 sig 변수에 채널을 담고, 해당 블록은 해제됨
• 로그를 찍은 후 컨텍스트 취소 메서드를 실행

go func() { 
    sig := <-sigChan 
    log.Printf("Received signal %s, shutting down...", sig) 
    cancel() 
}()

컨텍스트 완료 대기

• 컨텍스트 취소 함수 (cancel())가 실행되기 전까지 대기 (블록)
• 신호 감지 고루틴을 통해 취소 함수가 실행되면 대기중인 context의 채널이 닫힘
  • 이렇게 되면 해당 context를 사용중인 모든 함수들에 취소 신호가 전파됨
• 컨텍스트가 취소되면 ctx.Done() 이 실행됨

<-ctx.Done()

완성본

• 전체 코드와 흐름은 아래와 같다.
• 취소 신호를 받아 컨텍스가 취소되기 전까지 실행할 함수를 넣어주면 된다.
  • 실행할 함수에도 취소 가능한 context(ctx) 를 넘겨줘서, Graceful 하게 고루틴을 종료시킬 수 있음

func main() {
    // 취소 가능한 context 생성
    ctx, cancel := context.WithCancel(context.Background())

    defer cancel() // 종료 취소 보장

    // 신호 채널 생성
    sigChan := make(chan os.Signal, 1)

    // 취소 신호 감지 시 채널에 넘겨주는 용도
    signal.Notify(sigChan, syscall.SIGINT, syscall.SIGTERM)

    go func() {
        sig := <-sigChan // 신호가 들어올 때 까지 대기. 신호가 들어오면 해제됨
        log.Printf("Received signal %s, shutting down...", sig)
        cancel() // context 취소 함수 실행
    }()

    // 실행할 함수
    lib.Download(ctx, url, fileName)

    <-ctx.Done()

    // 종료 로그 등, 종료
}