GRPC

gRPC 로드밸런싱 3가지 전략과 실전 구현 가이드

2026년 07월 29일 11 Min Read

마이크로서비스 환경에서 gRPC를 도입한 뒤, 로드밸런서 뒤에 서버 여러 대를 두었는데도 트래픽이 한쪽으로만 쏠리는 경험을 해보셨나요? REST API에서는 잘 동작하던 로드밸런서가 gRPC에서는 왜 무력해지는지 의아할 수 있습니다. 이 글에서는 gRPC 로드밸런싱이 특별한 이유를 짚어보고, 실전에서 바로 적용할 수 있는 세 가지 전략을 코드와 설정 예시 중심으로 살펴보겠습니다.

gRPC는 HTTP/2 프로토콜 위에서 동작합니다. HTTP/2는 하나의 TCP 연결 위에 수백 개의 스트림을 동시에 다중화(multiplexing)할 수 있기 때문에, 전통적인 연결 기반 부하 분산이 제대로 작동하지 않습니다. 서비스 규모가 커질수록 이 문제는 심각해지고, 적절한 로드밸런싱 전략 없이는 특정 인스턴스에만 부하가 집중되어 장애로 이어질 수 있습니다.

이 글에서는 L7 프록시 기반, 클라이언트 사이드, xDS 기반 Look-aside 세 가지 접근법을 비교하고, 각각의 구현 방법과 Kubernetes 환경에서의 실전 적용까지 다루겠습니다. 특히 2026년 현재 Kubernetes Gateway API의 GRPCRoute GA, Istio의 proxyless gRPC 지원 등 최신 동향도 함께 반영했습니다.

HTTP/2 커넥션과 gRPC 로드밸런싱의 함정

gRPC 로드밸런싱 문제를 이해하려면, 먼저 HTTP/1.1과 HTTP/2의 연결 모델이 어떻게 다른지 알아야 합니다.

HTTP/1.1의 연결 모델

HTTP/1.1에서는 각 요청-응답 쌍이 기본적으로 하나의 TCP 연결을 사용합니다. Keep-Alive가 활성화되어 있더라도 한 번에 하나의 요청만 처리하는 Head-of-Line Blocking이 존재합니다. 브라우저나 HTTP 클라이언트는 보통 도메인당 여러 개의 TCP 연결을 만들어 동시성을 확보합니다. 이렇게 TCP 연결이 자주 생성되고 해제되기 때문에, L4 로드밸런서가 새로운 연결이 들어올 때마다 라운드 로빈으로 서버를 분배하면 트래픽이 자연스럽게 고르게 퍼집니다.

HTTP/2의 연결 모델

HTTP/2는 근본적으로 다릅니다. 하나의 TCP 연결 위에 여러 개의 스트림을 동시에 열 수 있고, 각 스트림이 독립적인 요청-응답을 처리합니다. 이것이 바로 다중화(multiplexing)입니다. gRPC 클라이언트는 이 특성을 최대한 활용하여 서버당 단 하나의 장기 연결(long-lived connection)만 유지합니다. 모든 RPC 호출이 이 하나의 연결 위에서 이루어지죠.

왜 L4 로드밸런서가 실패하는가

L4(전송 계층) 로드밸런서는 TCP 연결이 생성되는 시점에만 라우팅을 결정합니다. TCP SYN 패킷이 들어오면 목적지 서버를 선택하고, 이후 그 연결의 모든 패킷은 같은 서버로 갑니다. L4 로드밸런서는 HTTP/2 프레임 내부를 이해하지 못하기 때문에, 하나의 TCP 연결 안에 100개의 gRPC 호출이 섞여 있어도 구분할 수 없습니다.

구체적인 시나리오로 살펴보겠습니다. 클라이언트 3대와 서버 3대 사이에 L4 로드밸런서가 있다고 가정합시다. 각 클라이언트가 하나씩 TCP 연결을 맺으면, 로드밸런서는 각각 다른 서버로 연결해줍니다. 여기까지는 문제가 없어 보입니다.

하지만 클라이언트 A가 초당 1,000개의 RPC를 보내고, 클라이언트 B와 C는 초당 10개씩만 보낸다면 어떨까요? A의 1,000개 RPC는 전부 서버 하나에 몰립니다. 나머지 두 서버는 초당 10개씩만 처리하며 한가한 상태입니다. 이것이 이른바 Sticky Connection 문제입니다.

더 심각한 시나리오도 있습니다. 서버를 3대에서 6대로 스케일 아웃했는데, 기존 클라이언트들의 연결은 여전히 원래 3대에만 붙어 있습니다. 새 서버 3대의 CPU 사용률은 0%입니다. 오토스케일러(HPA)가 평균 CPU를 보고 아직 부하가 높다고 판단해서 서버를 계속 늘리는 악순환에 빠질 수도 있습니다. 연결이 한번 맺어지면 끊기지 않는 한 재분배가 일어나지 않기 때문입니다.

이 문제를 해결하려면, TCP 연결 단위가 아니라 개별 gRPC 호출(HTTP/2 스트림) 단위로 부하를 분산해야 합니다. 이를 위한 세 가지 전략을 하나씩 살펴보겠습니다.

전략 1: L7 프록시 기반 gRPC 로드밸런싱

첫 번째 전략은 HTTP/2 프로토콜을 이해할 수 있는 L7(응용 계층) 프록시를 사이에 두는 것입니다. L7 프록시는 HTTP/2 프레임을 파싱할 수 있으므로, TCP 연결 단위가 아니라 개별 gRPC 호출 단위로 라우팅 결정을 내립니다.

동작 원리

L7 프록시 기반 로드밸런싱은 다음과 같이 동작합니다. 먼저 클라이언트가 프록시와 HTTP/2 연결을 맺습니다. 프록시는 백엔드 서버 풀의 각 서버와 별도의 HTTP/2 연결을 사전에 맺어둡니다. 클라이언트에서 gRPC 호출이 들어올 때마다, 프록시가 라운드 로빈이나 최소 연결(least connections) 같은 알고리즘으로 적절한 백엔드 서버를 선택하여 요청을 전달합니다. 응답은 역순으로 클라이언트에게 돌아갑니다.

즉, 클라이언트 입장에서는 프록시 하나에만 연결하면 되고, 프록시가 알아서 여러 서버에 요청을 분산하는 구조입니다. 대표적인 L7 프록시로는 Envoy, nginx(1.13.10 이상), Traefik, HAProxy(2.0 이상) 등이 있습니다.

Envoy 프록시 설정 예시

Envoy는 gRPC 로드밸런싱에 가장 널리 사용되는 프록시입니다. Istio, Ambassador 등 많은 서비스 메시와 API 게이트웨이가 Envoy를 기반으로 합니다. 아래는 gRPC 백엔드에 라운드 로빈 로드밸런싱을 적용하는 Envoy 설정 예시입니다.

static_resources:
  listeners:
  - name: grpc_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: grpc_proxy
          codec_type: AUTO
          route_config:
            name: local_route
            virtual_hosts:
            - name: grpc_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                  grpc: {}
                route:
                  cluster: grpc_backend
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
  clusters:
  - name: grpc_backend
    connect_timeout: 5s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    typed_extension_protocol_options:
      envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
        "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
        explicit_http_config:
          http2_protocol_options: {}
    load_assignment:
      cluster_name: grpc_backend
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: grpc-server-1
                port_value: 50051
        - endpoint:
            address:
              socket_address:
                address: grpc-server-2
                port_value: 50051

핵심은 http2_protocol_options를 명시하는 것입니다. 이 설정이 없으면 Envoy가 백엔드와 HTTP/1.1로 통신하려 해서 gRPC 호출이 실패합니다. STRICT_DNS 타입을 사용하면 DNS가 반환하는 모든 IP에 대해 자동으로 엔드포인트가 갱신됩니다.

nginx gRPC 프록시 설정

nginx도 1.13.10 버전부터 gRPC 프록시를 공식 지원합니다. 설정이 Envoy보다 간결합니다.

upstream grpc_servers {
    server backend1:50051;
    server backend2:50051;
    server backend3:50051;
}

server {
    listen 8080 http2;

    location / {
        grpc_pass grpc://grpc_servers;
        grpc_next_upstream error timeout;
        grpc_next_upstream_tries 2;
    }
}

다만 nginx는 Envoy에 비해 gRPC 관련 세부 설정(회로 차단, 이상치 감지, gRPC 상태 코드 기반 라우팅 등)이 제한적입니다. 단순한 로드밸런싱만 필요하다면 nginx로 충분하지만, 고급 트래픽 관리가 필요하다면 Envoy가 더 적합합니다.

L7 프록시 방식의 장단점

장점을 먼저 살펴보면, 클라이언트 코드를 전혀 수정하지 않아도 됩니다. 프록시 주소만 가리키면 끝입니다. 또한 중앙에서 라우팅 정책, TLS 종단, 관찰가능성(메트릭, 트레이싱)을 통합 관리할 수 있습니다. 언어나 프레임워크에 무관하게 동작하므로 폴리글랏 마이크로서비스 환경에서 특히 유리합니다.

반면 단점도 있습니다. 모든 트래픽이 프록시를 경유하므로 추가 네트워크 홉이 생기고 지연이 미세하게 증가합니다. 일반적으로 1밀리초 미만이지만, 지연에 극도로 민감한 시스템에서는 문제가 될 수 있습니다. 또한 프록시 자체가 단일 장애점(SPOF)이 될 수 있어 프록시의 고가용성 구성이 필수입니다. 프록시가 처리할 트래픽 규모에 맞는 CPU와 메모리 자원도 확보해야 합니다.

전략 2: 클라이언트 사이드 로드밸런싱

두 번째 전략은 클라이언트가 직접 서버 목록을 알고, 각 RPC 호출마다 어떤 서버로 보낼지 결정하는 방식입니다. 중간 프록시가 없으므로 네트워크 홉이 줄어들고 지연이 최소화됩니다.

gRPC 내장 로드밸런싱 정책

gRPC 라이브러리는 대부분 내장 로드밸런싱 정책을 제공합니다. 가장 기본적인 정책들은 다음과 같습니다.

pick_first: 리졸버가 반환한 주소 목록 중 첫 번째 사용 가능한 서버에 연결합니다. 연결이 끊어지면 다음 서버로 넘어갑니다. gRPC의 기본값입니다.
round_robin: 모든 서버에 개별 서브채널(subchannel)을 열고, RPC 호출 때마다 돌아가며 사용합니다. 가장 많이 쓰이는 정책입니다.
weighted_round_robin: 각 서버의 가중치(보통 백엔드 보고 기반)에 따라 비율을 달리하여 분배합니다. 서버 스펙이 다를 때 유용합니다.

pick_first가 기본값이라는 점에 주의해야 합니다. 별도 설정 없이 gRPC 클라이언트를 사용하면 DNS가 여러 IP를 반환하더라도 첫 번째 하나에만 연결합니다. 반드시 round_robin 이상의 정책을 명시적으로 설정해야 부하 분산이 이루어집니다.

언어별 구현 예시

Go, Python, Java 세 가지 언어에서 클라이언트 사이드 로드밸런싱을 설정하는 방법을 살펴보겠습니다.

import (
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials/insecure"
)

conn, err := grpc.NewClient(
    "dns:///my-grpc-service.default.svc.cluster.local:50051",
    grpc.WithDefaultServiceConfig(
        `{"loadBalancingConfig": [{"round_robin":{}}]}`,
    ),
    grpc.WithTransportCredentials(insecure.NewCredentials()),
)

Python

import grpc

channel = grpc.insecure_channel(
    "dns:///my-grpc-service:50051",
    options=[
        ("grpc.lb_policy_name", "round_robin"),
    ],
)

Java

ManagedChannel channel = ManagedChannelBuilder
    .forTarget("dns:///my-grpc-service:50051")
    .defaultLoadBalancingPolicy("round_robin")
    .usePlaintext()
    .build();

세 언어 모두 공통적으로 dns:/// 스킴을 사용합니다. 이 스킴은 gRPC 내장 DNS 리졸버를 명시적으로 지정하는 것으로, DNS A 레코드를 조회해서 반환된 모든 IP 주소에 대해 서브채널을 만들고 로드밸런싱 정책을 적용합니다. 슬래시가 3개인 이유는 authority 부분이 비어있기 때문입니다.

DNS 해석과 서비스 디스커버리

클라이언트 사이드 로드밸런싱에서 가장 중요한 부분은 서버 목록을 어떻게 알아내느냐, 즉 서비스 디스커버리입니다. 기본 제공되는 DNS 리졸버는 A 레코드를 조회하는 방식인데, 몇 가지 주의점이 있습니다.

첫째, DNS 캐싱 때문에 서버가 추가되거나 제거되었을 때 즉시 반영되지 않을 수 있습니다. gRPC 클라이언트의 DNS 재조회 주기(min_time_between_resolutions)를 적절히 설정하는 것이 중요합니다. 기본값은 30초입니다.

둘째, Kubernetes 환경에서는 일반 ClusterIP Service를 사용하면 DNS가 서비스의 가상 IP 하나만 반환합니다. 이 경우 round_robin을 설정해도 실제로는 하나의 IP에만 연결됩니다. 개별 Pod IP를 DNS에 노출하려면 반드시 Headless Service(clusterIP: None)를 사용해야 합니다.

DNS 외에 Consul, etcd, ZooKeeper 같은 서비스 레지스트리와 연동하려면 커스텀 Name Resolver를 구현할 수 있습니다. gRPC는 리졸버 인터페이스를 제공하므로, 어떤 서비스 디스커버리 시스템이든 연결할 수 있습니다.

클라이언트 사이드 방식의 장단점

장점으로는 중간 프록시가 없으므로 지연이 최소화됩니다. 단일 장애점도 없습니다. 각 클라이언트가 독립적으로 동작하기 때문입니다. 서버와 클라이언트 간의 직접 HTTP/2 연결로 최적의 성능을 얻을 수 있습니다.

단점으로는 모든 클라이언트 언어와 프레임워크에서 각각 로드밸런싱 설정을 해줘야 합니다. 폴리글랏 환경에서는 관리 포인트가 늘어납니다. 클라이언트가 서비스 디스커버리 로직을 직접 품어야 하므로 이른바 thick client가 됩니다. 또한 로드밸런싱 정책을 변경하려면 모든 클라이언트를 업데이트하고 재배포해야 합니다.

전략 3: xDS 기반 Look-aside 로드밸런싱

세 번째 전략은 클라이언트 사이드의 장점인 직접 연결과 중앙 관리의 장점을 결합한 하이브리드 접근법입니다. 핵심 아이디어는 간단합니다. 클라이언트가 외부의 제어 평면(control plane)에 물어봐서 최적의 서버 목록과 라우팅 정책을 받아오고, 실제 데이터 트래픽은 클라이언트에서 서버로 직접 보내는 것입니다.

xDS 프로토콜이란

xDS는 원래 Envoy 프록시의 동적 설정을 위해 설계된 프로토콜 묶음입니다. x는 다양한 디스커버리 서비스를 아우르는 와일드카드이며, 주요 구성 요소는 다음과 같습니다.

LDS (Listener Discovery Service): 리스너 설정 전달
RDS (Route Discovery Service): 라우팅 규칙 전달
CDS (Cluster Discovery Service): 클러스터(서비스 그룹) 설정 전달
EDS (Endpoint Discovery Service): 개별 엔드포인트(서버 IP/포트) 전달

gRPC 라이브러리에 xDS 클라이언트가 직접 내장되면서, Envoy 사이드카 프록시 없이도 xDS 프로토콜을 통해 서비스 메시의 혜택을 누릴 수 있게 되었습니다. 이것이 바로 프록시리스 서비스 메시(proxyless service mesh)입니다.

동작 흐름

xDS 기반 gRPC 로드밸런싱의 동작 흐름은 다음과 같습니다. 먼저 gRPC 클라이언트가 시작할 때 부트스트랩 설정에 지정된 xDS 제어 서버(예: Istio의 istiod)에 연결합니다. 제어 서버는 클라이언트에게 서비스 엔드포인트 목록, 라우팅 규칙, 부하 분산 정책 등을 gRPC 스트리밍으로 전달합니다. 서버가 스케일 아웃/인 되거나 정책이 변경되면 제어 서버가 실시간으로 업데이트를 push합니다. 클라이언트는 받은 정보를 바탕으로 적절한 서버에 직접 RPC를 보냅니다.

부트스트랩 설정 파일의 예시입니다.

{
  "xds_servers": [
    {
      "server_uri": "xds-control-plane:18000",
      "channel_creds": [{"type": "insecure"}],
      "server_features": ["xds_v3"]
    }
  ],
  "node": {
    "id": "my-client-node",
    "cluster": "my-cluster"
  }
}

Go 클라이언트에서 xDS를 사용하는 코드는 놀라울 정도로 간단합니다.

import (
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials/insecure"
    _ "google.golang.org/grpc/xds" // xDS 리졸버 사이드이펙트 임포트
)

// GRPC_XDS_BOOTSTRAP 환경변수로 부트스트랩 파일 경로 지정
conn, err := grpc.NewClient(
    "xds:///my-grpc-service",
    grpc.WithTransportCredentials(insecure.NewCredentials()),
)

dns:/// 대신 xds:/// 스킴을 사용하는 것이 유일한 코드 변경입니다. 나머지는 부트스트랩 설정과 제어 평면 인프라가 처리합니다.

Istio Proxyless 모드

Istio 1.11부터 gRPC proxyless 모드를 공식 지원합니다. Envoy 사이드카 없이 gRPC 애플리케이션이 istiod에 직접 xDS로 연결하여, 트래픽 관리와 관찰가능성 같은 서비스 메시 기능을 사용할 수 있습니다. 이 방식은 사이드카 프록시가 소비하는 CPU와 메모리를 절약하면서도 서비스 메시의 혜택을 유지할 수 있어, 리소스 효율이 중요한 환경에서 주목받고 있습니다.

Kubernetes에서 proxyless gRPC를 위한 DestinationRule 설정 예시입니다.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: grpc-service-dr
spec:
  host: my-grpc-service.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

xDS 방식의 장단점

장점으로는, 데이터 평면에 프록시가 없어 지연이 최소화됩니다. 동시에 중앙 제어 평면에서 라우팅 정책을 동적으로 변경할 수 있습니다. 카나리 배포, 회로 차단(circuit breaking), 이상치 감지(outlier detection) 같은 서비스 메시의 고급 기능을 프록시 없이 사용 가능합니다. 엔드포인트 변경이 DNS TTL과 무관하게 즉시 반영됩니다.

단점으로는, xDS 제어 평면(Istio, Traffic Director 등)을 운영해야 하므로 인프라 복잡도가 상당히 높아집니다. gRPC 라이브러리의 xDS 지원 수준이 언어마다 다릅니다. Go와 Java, C++은 지원이 성숙하지만, Python이나 Ruby는 아직 제한적입니다. 제어 평면과 데이터 평면이 분리되어 있어 문제 발생 시 디버깅 난이도가 올라갑니다.

Kubernetes에서의 gRPC 로드밸런싱 실전

Kubernetes는 gRPC 서비스를 운영하는 가장 일반적인 환경입니다. 하지만 기본 Kubernetes Service(ClusterIP)는 iptables 또는 IPVS 기반의 L4 로드밸런싱을 수행하기 때문에, 앞서 설명한 sticky connection 문제가 그대로 발생합니다. Kubernetes에서 gRPC 부하 분산을 올바르게 구현하는 세 가지 방법을 살펴보겠습니다.

방법 1: Headless Service와 클라이언트 사이드 LB

가장 간단하면서도 효과적인 방법입니다. Kubernetes Service를 Headless로 만들어 DNS가 개별 Pod IP를 반환하게 하고, gRPC 클라이언트에서 round_robin 정책을 설정합니다.

apiVersion: v1
kind: Service
metadata:
  name: my-grpc-service
spec:
  clusterIP: None
  selector:
    app: my-grpc-server
  ports:
  - port: 50051
    targetPort: 50051
    protocol: TCP

clusterIP: None이 핵심입니다. 이 설정으로 DNS 조회 시 서비스의 가상 IP 대신 개별 Pod IP가 반환됩니다. gRPC 클라이언트의 DNS 리졸버가 이 IP들을 받아서 각각에 서브채널을 열고 round_robin으로 분배합니다.

주의할 점이 있습니다. Pod가 스케일 아웃되거나 롤링 업데이트로 교체될 때, DNS 캐시 때문에 새 Pod가 즉시 인식되지 않을 수 있습니다. gRPC의 DNS 재조회 주기는 기본 30초인데, 이를 더 짧게 설정하거나 서버 측에서 MaxConnectionAge를 설정하여 주기적으로 연결을 갱신하는 것이 좋습니다.

방법 2: Gateway API의 GRPCRoute

Kubernetes 1.27부터 Gateway API에 GRPCRoute 리소스가 GA(정식)로 포함되었습니다. 이를 통해 gRPC 특화 라우팅을 선언적으로 설정할 수 있습니다.

apiVersion: gateway.networking.k8s.io/v1
kind: GRPCRoute
metadata:
  name: my-grpc-route
spec:
  parentRefs:
  - name: my-gateway
  rules:
  - matches:
    - method:
        service: mypackage.MyService
    backendRefs:
    - name: my-grpc-service
      port: 50051
      weight: 100

GRPCRoute는 gRPC 서비스와 메서드 수준의 매칭을 지원합니다. 서로 다른 gRPC 서비스를 다른 백엔드로 라우팅하거나, 트래픽 가중치를 활용한 카나리 배포도 가능합니다. 기존 Ingress보다 gRPC에 훨씬 적합한 추상화를 제공합니다.

Gateway API 구현체(Envoy Gateway, Istio, Contour 등)에 따라 지원 범위가 다를 수 있으므로, 사용 중인 구현체의 GRPCRoute 지원 수준을 확인하시기 바랍니다.

방법 3: 서비스 메시 활용

Istio나 Linkerd 같은 서비스 메시를 사용하면 별도 설정 없이 gRPC 트래픽이 L7 수준에서 자동으로 부하 분산됩니다. 사이드카 프록시가 모든 네트워크 트래픽을 투명하게 가로채므로, 애플리케이션 코드를 전혀 수정할 필요가 없습니다.

Linkerd는 Istio보다 가벼운 대안으로, gRPC를 포함한 HTTP/2 트래픽의 로드밸런싱을 잘 지원합니다. Rust로 작성된 초경량 프록시를 사이드카로 사용하기 때문에 리소스 오버헤드가 적습니다.

서비스 메시를 이미 도입했다면 gRPC 로드밸런싱이 자동으로 해결되므로 가장 편리한 방법입니다. 하지만 서비스 메시 자체의 운영 복잡도와 리소스 오버헤드를 고려해야 합니다. gRPC 로드밸런싱만을 위해 서비스 메시를 도입하는 것은 배보다 배꼽이 큰 경우가 많습니다.

실전 운영에서 꼭 알아야 할 팁

어떤 전략을 선택하든, 실전 운영에서 자주 마주치는 문제들이 있습니다. 이 섹션에서는 gRPC 로드밸런싱을 프로덕션에 적용할 때 반드시 알아야 할 실전 팁을 정리합니다.

MaxConnectionAge로 연결 재분배 유도

gRPC의 장기 연결 특성 때문에, 서버를 스케일 아웃해도 기존 연결이 새 서버로 재분배되지 않는 문제가 있습니다. 이를 해결하는 가장 실용적인 방법은 서버 측에서 MaxConnectionAge를 설정하는 것입니다. 연결이 일정 시간이 지나면 서버가 GOAWAY 프레임을 보내 클라이언트에게 재연결을 유도합니다.

// Go 서버: 30분마다 연결 갱신 유도
server := grpc.NewServer(
    grpc.KeepaliveParams(keepalive.ServerParameters{
        MaxConnectionAge:      30 * time.Minute,
        MaxConnectionAgeGrace: 10 * time.Second,
    }),
)

MaxConnectionAge는 연결이 생성된 시점부터의 최대 수명입니다. 이 시간이 지나면 서버가 GOAWAY를 보내고, MaxConnectionAgeGrace 기간 동안 진행 중인 RPC가 완료되기를 기다린 후 연결을 닫습니다. 클라이언트는 자동으로 새 연결을 맺으며, 이때 로드밸런싱이 다시 작동하여 새 서버도 트래픽을 받게 됩니다.

적절한 MaxConnectionAge 값은 환경에 따라 다르지만, 일반적으로 15분에서 1시간 사이가 권장됩니다. 너무 짧으면 재연결 오버헤드가 커지고, 너무 길면 부하 재분배가 느려집니다.

Keepalive 설정으로 좀비 연결 방지

클라이언트와 서버 양쪽에 keepalive를 적절히 설정하는 것도 중요합니다. 유휴 연결이 중간의 방화벽이나 로드밸런서에 의해 조용히 끊어지는 경우(이른바 half-open connection)를 방지합니다.

// Go 클라이언트: keepalive 설정
conn, err := grpc.NewClient(
    target,
    grpc.WithKeepaliveParams(keepalive.ClientParameters{
        Time:                10 * time.Second,
        Timeout:             3 * time.Second,
        PermitWithoutStream: true,
    }),
)

Time은 유휴 상태에서 핑을 보내는 주기, Timeout은 핑 응답 대기 시간, PermitWithoutStream은 활성 스트림이 없을 때도 핑을 보낼지 여부입니다. 클라우드 로드밸런서의 유휴 타임아웃(보통 60초 또는 그 이상)보다 짧게 설정하는 것이 핵심입니다.

Graceful 배포와 연결 드레이닝

Kubernetes에서 롤링 업데이트를 할 때, 종료되는 Pod의 기존 gRPC 연결을 안전하게 마무리하는 것이 중요합니다. Pod가 SIGTERM을 받으면 다음 순서로 처리해야 합니다.

새로운 RPC 수락을 중단합니다(서버의 GracefulStop 호출).
Kubernetes에 readiness probe 실패를 알려 새 트래픽이 오지 않게 합니다.
진행 중인 RPC가 완료될 때까지 대기합니다.
대기 시간이 terminationGracePeriodSeconds를 초과하면 강제 종료됩니다.

// Go 서버: Graceful Shutdown 예시
quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGTERM, syscall.SIGINT)

go func() {
    sig := <-quit
    log.Printf("Signal %v received, starting graceful shutdown", sig)
    server.GracefulStop() // 새 연결 거부, 기존 RPC 완료 대기
}()

server.Serve(lis)

Kubernetes의 terminationGracePeriodSeconds는 서버에서 처리하는 가장 긴 RPC의 예상 시간보다 충분히 길게 설정해야 합니다. 스트리밍 RPC가 있다면 특히 주의가 필요합니다.

gRPC 헬스체크 프로토콜 활용

gRPC는 표준 헬스체크 프로토콜(grpc.health.v1.Health)을 정의하고 있습니다. 로드밸런서나 Kubernetes가 이 프로토콜을 사용하여 서버의 상태를 정확하게 파악할 수 있습니다. HTTP 엔드포인트 기반 헬스체크보다 gRPC 네이티브 헬스체크가 더 정확한 상태를 반영합니다.

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: grpc-server
    readinessProbe:
      grpc:
        port: 50051
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      grpc:
        port: 50051
      initialDelaySeconds: 10
      periodSeconds: 20

Kubernetes 1.24부터 grpc 타입의 프로브가 GA로 지원됩니다. 별도의 HTTP 헬스체크 엔드포인트를 만들 필요 없이 gRPC 서비스의 헬스 상태를 직접 확인할 수 있습니다. 서버가 과부하 상태일 때 NOT_SERVING을 반환하면 로드밸런서가 해당 서버로의 트래픽을 자동으로 줄입니다.

3가지 전략 비교와 선택 기준

지금까지 살펴본 세 가지 전략을 한눈에 비교해 보겠습니다.

L7 프록시 기반: 구현 난이도가 낮고 클라이언트 수정이 불필요합니다. 추가 홉으로 인한 미세한 지연 증가가 있지만, 중앙 관리가 용이합니다. 이미 Envoy나 nginx를 사용 중이라면 가장 빠르게 적용할 수 있습니다.
클라이언트 사이드: 추가 인프라 없이 최소 지연을 달성할 수 있습니다. 단일 언어로 통일된 마이크로서비스 환경이나, 프록시 오버헤드를 줄여야 하는 고성능 시스템에 적합합니다. 다만 모든 클라이언트에 설정을 적용하고 관리해야 합니다.
xDS Look-aside: 직접 연결의 성능과 중앙 관리의 편의성을 모두 갖춘 가장 진보된 방식입니다. 대규모 마이크로서비스 환경에서 트래픽 관리, 카나리 배포 등 고급 기능이 필요할 때 적합합니다. 다만 xDS 인프라 운영 역량이 필요합니다.

선택 기준을 상황별로 정리하면 다음과 같습니다.

마이크로서비스가 10개 미만이고, 이미 nginx나 Envoy를 운영 중이라면 L7 프록시 방식을 추천합니다.
단일 언어(Go 또는 Java) 환경이고, 지연에 민감하며, 추가 인프라를 최소화하고 싶다면 클라이언트 사이드 방식이 좋습니다.
서비스가 수십 개 이상이고, Istio 같은 서비스 메시를 이미 도입했거나 도입 예정이라면 xDS 방식을 고려하세요.
Kubernetes 환경이라면 Headless Service와 round_robin의 조합이 가장 간단한 출발점입니다. 여기서 필요에 따라 서비스 메시나 Gateway API로 확장하면 됩니다.

실무에서는 하나의 전략만 고집하기보다, 서비스의 성격에 따라 혼합하는 경우가 많습니다. 내부 서비스 간 통신에는 클라이언트 사이드 LB를, 외부 노출 API에는 L7 프록시를 두는 식입니다. 중요한 것은 gRPC가 HTTP/2 기반이라 L4 로드밸런싱만으로는 부족하다는 사실을 인지하고, 서비스에 맞는 전략을 의식적으로 선택하는 것입니다.

gRPC 로드밸런싱은 마이크로서비스 아키텍처에서 안정적인 운영을 위한 핵심 요소입니다. HTTP/2의 연결 다중화 특성을 이해하고, 서비스 규모와 인프라 환경에 맞는 전략을 선택한다면 트래픽 쏠림 없이 안정적인 gRPC 서비스를 운영할 수 있을 것입니다. 이 글에서 다룬 설정과 코드 예시를 참고하여, 여러분의 환경에 가장 적합한 방식을 시작해 보시기 바랍니다.

🔗 함께 보면 좋은 글

Tags: