Kafka Zero Copy: 데이터 전송 효율을 극대화하다

최근 데이터 스트리밍 시장에서 Kafka의 인기가 높아짐에 따라, 그 내부 기술에 대한 관심도 커지고 있습니다. 오늘은 Kafka의 핵심 성능 최적화 기법 중 하나인 Zero Copy에 대해 이야기해보고자 합니다.

Zero Copy, 그게 뭐야?

우리가 보통 데이터를 전송할 때는 CPU가 여러 번 데이터를 복사하는 과정을 거치게 됩니다. 이 과정은 특히 대용량 데이터를 처리할 때 큰 부담이 될 수 있죠. Zero Copy는 이런 복사 과정을 최소화하여, 데이터를 직접 네트워크나 디스크로 전송하는 기술입니다. 이렇게 하면 CPU의 부담이 줄어들고, 전체적인 시스템 성능이 향상됩니다.

Kafka에서 Zero Copy가 어떻게 활용될까?

Kafka는 대용량의 메시지를 빠르게 처리해야 하는 특성이 있습니다. 그래서 Kafka는 디스크에 저장된 데이터를 클라이언트에게 전송할 때, 커널의 sendfile 시스템 콜을 이용해 데이터를 복사하지 않고 바로 전송합니다. 이러한 접근 방식 덕분에 Kafka는 CPU 사용을 크게 줄이고, 데이터 처리량을 극대화할 수 있었습니다.

Kafka Zero Copy (sendfile 사용) 방식

       +----------+
       |   Disk   |
       +----------+
            │
            │  sendfile (커널 내 직접 전송)
            ▼
   +---------------------+
   |  Kernel (sendfile)  |
   +---------------------+
            │
            ▼
       +-----------+
       |  Network  |
       +-----------+

이 방식에서는 데이터가 디스크에서 바로 커널 내부의 네트워크 스택으로 전송되므로, 사용자 공간으로의 불필요한 데이터 복사가 발생하지 않습니다.

Zero Copy 미사용 방식 (일반적인 데이터 전송 절차)

       +----------+
       |   Disk   |
       +----------+
            │
            │  데이터 읽기
            ▼
       +--------------+
       |  User Space  |  (버퍼에 복사)
       +--------------+
            │
            │  데이터 쓰기
            ▼
   +--------------+
   | Kernel Space |  (또 한 번 복사)
   +--------------+
            │
            ▼
       +-----------+
       |  Network  |
       +-----------+

이 경우, 데이터는 디스크에서 먼저 사용자 공간으로 복사되고, 다시 커널 공간으로 복사되어 네트워크로 전송되므로 불필요한 메모리 복사 오버헤드가 발생하게 됩니다.

왜 Zero Copy가 중요한가?

• 빠른 처리 속도: 데이터 복사 오버헤드를 줄여, 많은 양의 데이터를 신속하게 처리할 수 있습니다.
• 짧은 응답 시간: 데이터 전송 과정에서 불필요한 지연이 없어, 실시간 처리에 유리합니다.
• 효율적인 시스템 운영: CPU 리소스를 효율적으로 사용하여 다른 작업에도 충분한 자원을 할당할 수 있습니다.

HTTP란 무엇이며, 어떤 특징을 가지는가?

HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트와 서버 간 데이터를 주고받는 프로토콜로, 기본적으로 비연결형(Connectionless), 무상태(Stateless) 방식으로 동작합니다.

• HTTP 1.1: Keep-Alive 기능으로 다중 요청 가능
• HTTP 2: 멀티플렉싱(Multiplexing) 지원, 헤더 압축
• HTTP 3: UDP 기반의 QUIC 프로토콜을 사용하여 속도 개선

Trie를 이용한 접두사 검색 (Autocomplete 기능 구현)

import java.util.*;

class TrieNode {
    TrieNode[] children;
    boolean isEndOfWord;

    public TrieNode() {
        children = new TrieNode[26]; // 알파벳 소문자 기준
        isEndOfWord = false;
    }
}

class Trie {
    private TrieNode root;

    public Trie() {
        root = new TrieNode();
    }

    public void insert(String word) {
        TrieNode node = root;
        for (char c : word.toCharArray()) {
            int index = c - 'a';
            if (node.children[index] == null) {
                node.children[index] = new TrieNode();
            }
            node = node.children[index];
        }
        node.isEndOfWord = true;
    }

    public List<String> getWordsWithPrefix(String prefix) {
        List<String> result = new ArrayList<>();
        TrieNode node = root;
        for (char c : prefix.toCharArray()) {
            int index = c - 'a';
            if (node.children[index] == null) {
                return result;
            }
            node = node.children[index];
        }
        findWords(node, new StringBuilder(prefix), result);
        return result;
    }

    private void findWords(TrieNode node, StringBuilder prefix, List<String> result) {
        if (node.isEndOfWord) {
            result.add(prefix.toString());
        }
        for (char c = 'a'; c <= 'z'; c++) {
            int index = c - 'a';
            if (node.children[index] != null) {
                prefix.append(c);
                findWords(node.children[index], prefix, result);
                prefix.deleteCharAt(prefix.length() - 1);
            }
        }
    }
}

Kafka vs RabbitMQ – 어떤 메시지 시스템이 내 서비스에 적합할까?

메시지 브로커와 이벤트 스트리밍 플랫폼은 분산 시스템의 핵심 요소로 자리 잡고 있습니다. RabbitMQ와 Kafka는 시장에서 많이 사용되는 두 가지 솔루션으로, 서로 다른 설계 철학과 강점을 가지고 있습니다. 이 글에서는 두 시스템의 주요 특징과 차이점을 비교해 보겠습니다.

1. 아키텍처와 기본 개념

RabbitMQ

• 메시지 큐 기반: RabbitMQ는 AMQP(Advanced Message Queuing Protocol)를 기반으로 동작하며, 생산자(producer)가 메시지를 보내면, 브로커가 이를 큐에 저장하고 소비자(consumer)가 메시지를 받아 처리하는 구조입니다.
• 라우팅과 토폴로지: 다양한 교환기(exchange)와 큐(queue)를 사용해 복잡한 라우팅 로직을 구성할 수 있습니다. 토픽, 라우팅 키, 헤더 등 다양한 라우팅 방식을 지원합니다.
• Push 모델: RabbitMQ는 기본적으로 생산자가 메시지를 큐에 넣으면, 브로커가 이를 소비자에게 푸시(push)하는 형태로 전달합니다.

Kafka

• 로그 기반의 분산 스트리밍 플랫폼: Kafka는 메시지를 지속적 로그에 기록하는 방식으로, 데이터를 토픽(topic)에 저장하고, 각 토픽은 여러 파티션(partition)으로 나뉩니다.
• Pull 모델: 소비자는 필요한 시점에 데이터를 요청(pull)하는 방식으로 메시지를 가져옵니다. 이로 인해 소비자 측에서 처리 속도에 맞게 데이터를 읽어들일 수 있습니다.
• 높은 처리량과 확장성: 분산 환경에서 수평 확장이 용이하며, 대규모 스트리밍 데이터를 처리하는 데 최적화되어 있습니다.

2. 성능 및 확장성

RabbitMQ

• 낮은 지연 시간: 일반적으로 작은 메시지 단위의 처리에서는 매우 빠른 응답 속도를 보입니다.
• 유연한 확장: 클러스터 구성이 가능하지만, 수평 확장 측면에서는 Kafka만큼 강력하지는 않습니다.
• 메시지 보증: 메시지의 신뢰성과 순서를 보장하기 위한 다양한 옵션(예, 메시지 영속성, ACK 처리 등)을 제공합니다.

Kafka

• 높은 처리량: 초당 수백만 건의 메시지 처리도 가능하며, 대용량 로그와 스트리밍 데이터 처리에 특화되어 있습니다.
• 수평 확장성: 클러스터를 구성해 브로커 수를 늘리면 처리량이 비례하여 증가합니다.
• 내결함성: 메시지가 디스크에 기록되고, 파티션별 복제(replicas) 설정을 통해 데이터 손실에 대비할 수 있습니다.

3. 데이터 일관성과 내구성

RabbitMQ

• 메시지 영속성: 디스크에 메시지를 저장함으로써 서버 장애 시에도 데이터를 복원할 수 있습니다. 단, 설정에 따라 성능과 내구성 간의 trade-off가 발생할 수 있습니다.
• ACK 기반 전송: 소비자가 메시지를 확실하게 처리했음을 ACK 신호로 알려야 하므로, 중복 처리나 메시지 손실을 최소화할 수 있습니다.

Kafka

• 로그 보존 정책: Kafka는 메시지를 오랜 기간 보관할 수 있으며, 소비자가 언제든지 특정 오프셋(offset)부터 데이터를 읽을 수 있습니다.
• 내구성과 복제: 각 파티션에 대해 다수의 복제본을 관리하여, 일부 노드에 장애가 발생해도 데이터 일관성을 유지할 수 있습니다.
• 최종 일관성: 소비자들이 데이터를 개별적으로 관리하기 때문에, 완벽한 실시간 순서를 보장하기보다는 최종적으로 일관된 상태를 유지하는 데 중점을 둡니다.

4. 사용 사례와 선택 기준

RabbitMQ가 적합한 경우

• 복잡한 라우팅 로직: 다양한 라우팅 규칙과 큐를 이용해 메시지를 분배해야 할 때.
• 즉각적인 알림 및 작업 분배: 작업 큐나 이벤트 알림 시스템에서 낮은 지연 시간을 필요로 할 때.
• 소규모에서 중규모 시스템: 규모가 크지 않은 환경에서 복잡한 메시지 전송 패턴을 구현할 때.

Kafka가 적합한 경우

• 대규모 데이터 스트리밍: 로그 수집, 실시간 데이터 처리, 분석 등에 있어 대량의 데이터를 빠르게 처리할 때.
• 내구성 및 확장성: 데이터의 내구성을 유지하면서, 시스템 확장을 통해 높은 처리량을 필요로 할 때.
• 분산 처리 및 이벤트 소싱: 마이크로서비스 아키텍처에서 이벤트 소싱, 스트림 처리 패턴을 구현할 때.

5. 결론

RabbitMQ와 Kafka는 각각의 장점이 뚜렷하며, 시스템의 요구 사항에 따라 선택해야 합니다.

• RabbitMQ는 복잡한 메시지 라우팅과 낮은 지연 시간의 처리가 필요할 때 유리하며, 전통적인 메시지 큐 패턴에 익숙한 환경에서 강점을 보입니다.
• Kafka는 높은 처리량, 확장성, 그리고 로그 기반 데이터 저장이 핵심인 환경에 적합하며, 실시간 분석과 스트리밍 데이터 처리에서 우수한 성능을 발휘합니다.

서비스의 규모, 메시지 처리 패턴, 데이터 내구성 요구 사항 등을 고려하여 두 시스템 중 적합한 솔루션을 선택하면, 보다 안정적이고 효율적인 메시징 인프라를 구축할 수 있습니다.

대규모 서비스의 데이터 폭발과 처리 전략

현대의 초대형 플랫폼은 수억 건, 때로는 수십억 건에 이르는 레코드와 수백 기가바이트에서 테라바이트 단위의 데이터를 다룹니다. 단순한 웹 애플리케이션과는 달리, 대규모 서비스는 데이터의 양뿐 아니라 실시간 처리, 정합성, 확장성 등 여러 측면에서 극복해야 할 도전 과제가 산적해 있습니다. 이번 글에서는 대규모 데이터 환경의 규모를 재조명하고, 그에 따른 시스템 성능 최적화 및 처리 전략에 대해 알아보겠습니다.

1. 대규모 데이터 규모, 상상을 초월하는 데이터 양

일반적인 웹 서비스가 수 기가바이트 단위의 데이터를 다루는 것과 달리, 초대형 서비스에서는 데이터 규모가 훨씬 큽니다. 예를 들어볼 수 있는 가상의 데이터 규모는 다음과 같습니다:

• entry 테이블: 8천만 건 이상 → 50GB ~ 100GB
• bookmark 테이블: 2억 건 이상 → 150GB 이상
• tag 테이블: 1억 건 이상 → 80GB ~ 100GB
• HTML 데이터: 압축 저장 시 1TB 이상, 일부 서비스에서는 10TB를 넘기도 함

더 나아가, Google, Facebook, Amazon과 같은 글로벌 플랫폼은 페타바이트(PB) 단위의 데이터를 처리하며, 데이터 레이크(data lake)나 분산 파일 시스템(HDFS, Amazon S3 등)을 활용해 저장 및 분석하고 있습니다.

2. 대규모 데이터베이스의 쿼리 처리와 병목 현상

이처럼 방대한 데이터를 다루다 보면, 단순한 쿼리 하나에도 상당한 부하가 발생합니다.

• 인덱스가 제대로 활용되지 않으면 단 한 건의 데이터를 찾는 데 수백 초가 걸릴 수 있습니다.
• 실제로 수십억 건의 레코드를 대상으로 한 단순 조회도 디스크 I/O, 네트워크 대역폭, CPU 처리 등 다양한 병목 구간 때문에 예기치 못한 지연을 발생시킵니다.

특히, 분산 시스템에서는 노드 간 데이터 일관성과 네트워크 지연 등도 고려해야 하므로 쿼리 최적화 및 인덱스 설계가 더욱 중요해집니다.

3. 메모리와 디스크, 그 속도의 괴리

대규모 데이터 처리의 핵심 문제 중 하나는 메모리와 디스크 사이의 속도 차이입니다.

(1) 메모리 vs. 디스크

• 메모리: 전기 신호 기반으로 데이터 접근 속도가 마이크로초(10^-6초) 단위로 매우 빠릅니다.
• 디스크: HDD의 경우 기계적인 헤드 이동과 원반 회전으로 인해 밀리초(10^-3초) 단위의 지연이 발생하며, SSD 역시 버스 및 컨트롤러의 한계로 메모리보다는 느립니다.

(2) 전송 속도 차이

• 실제 벤치마크에서는 메모리 전송 속도가 7.3GB/초에 달하는 반면, 디스크는 약 855MB/초 정도로 10배 이상의 차이가 발생합니다.
• 이런 차이는 대규모 데이터베이스에서 캐싱과 인메모리 데이터 처리의 필요성을 더욱 부각시킵니다.

4. 대규모 데이터 처리 전략과 최신 기술

대규모 데이터를 효과적으로 관리하기 위해선 단일 서버가 아닌 분산 시스템을 도입하는 것이 필수적입니다. 다음과 같은 전략들이 주로 활용됩니다.

인덱스 최적화와 쿼리 튜닝

• 인덱스 설계: 올바른 컬럼에 인덱스를 설정하면, 수십 기가바이트 또는 테라바이트 규모의 데이터에서도 원하는 정보를 빠르게 검색할 수 있습니다.
• 쿼리 최적화: 불필요한 전체 스캔을 피하고, 조건절을 최적화하여 데이터 접근 시간을 줄입니다.

분산 처리 및 샤딩(Sharding)

• 수평 확장: 데이터를 여러 서버에 분산 저장함으로써 하나의 서버에 과부하가 걸리지 않도록 합니다.
• 샤딩: 데이터를 일정 기준에 따라 여러 파티션으로 나누어, 각각의 샤드에서 독립적으로 쿼리를 처리하게 함으로써 전체 성능을 향상시킵니다.
• 분산 데이터베이스: Google의 Bigtable, Apache Cassandra, Amazon DynamoDB 등 분산형 데이터베이스는 데이터 일관성과 가용성을 유지하면서 수십 테라바이트 이상의 데이터를 효율적으로 관리합니다.

캐싱과 인메모리 처리

• 캐싱 계층: Redis, Memcached와 같은 인메모리 캐시는 자주 조회되는 데이터를 디스크 접근 없이 빠르게 제공하여 전체 시스템의 응답 속도를 높입니다.
• 데이터 레이크 및 분석 시스템: Apache Hadoop, Apache Spark 같은 프레임워크는 대용량 데이터에 대해 병렬 처리 및 실시간 분석을 가능하게 합니다.

하드웨어 혁신과 클라우드 인프라

• SSD 및 NVMe 드라이브: 최신 SSD나 NVMe 기반 스토리지는 전통적인 HDD보다 훨씬 빠른 데이터 접근 속도를 제공하며, 대규모 데이터 처리의 병목을 완화합니다.
• 클라우드 기반 솔루션: Amazon Web Services, Google Cloud Platform, Microsoft Azure 등은 확장성 높은 분산 스토리지와 컴퓨팅 자원을 제공하여, 데이터 규모가 커질수록 유연하게 대응할 수 있게 합니다.

5. 트러블슈팅과 지속적인 최적화

대규모 데이터 환경에서는 예상치 못한 문제들이 빈번하게 발생합니다. 이러한 문제를 해결하기 위해선 다음과 같은 접근 방식이 필요합니다.

• 모니터링과 로깅: 실시간 모니터링 도구를 활용하여 성능 병목과 장애를 조기에 감지합니다.
• 자동화된 스케일링: 시스템 부하에 따라 서버를 자동으로 추가하거나 축소하는 오토스케일링 기술이 중요합니다.
• 테스트와 피드백 루프: 실제 운영 환경과 유사한 테스트 환경을 마련해 다양한 시나리오를 검증하고, 시행착오를 통해 최적의 설정을 도출합니다.
• 전문가 네트워크와 커뮤니티: 다양한 사례와 최신 기술 정보를 공유하며, 문제 발생 시 빠른 해결책을 모색할 수 있는 네트워크가 큰 도움이 됩니다.

결론

대규모 서비스에서는 데이터의 양이 수십 기가바이트에서 테라바이트, 나아가 페타바이트 단위로 확장될 수 있으며, 이로 인해 발생하는 다양한 성능 및 정합성 문제를 해결하기 위한 기술과 전략이 필수적입니다.

• 메모리와 디스크의 속도 차이는 캐싱과 인메모리 데이터 처리의 필요성을 강조하며,
• 분산 처리와 샤딩은 단일 서버의 한계를 극복하는 핵심 전략입니다.
• 최신 클라우드 인프라와 하드웨어 혁신은 이러한 전략들을 현실화하는 데 큰 역할을 합니다.

대규모 데이터를 효율적으로 관리하기 위해선 단순한 쿼리 최적화뿐 아니라, 시스템 아키텍처 전반에 걸친 전략 수립과 지속적인 모니터링, 그리고 경험을 통한 문제 해결 능력이 요구됩니다. 여러분의 서비스가 더욱 빠르고 안정적으로 성장할 수 있도록, 이번 글에서 소개한 다양한 기술과 방법론을 참고하여 최적의 데이터 처리 환경을 구축해 보시기 바랍니다.

MySQL 트랜잭션 격리 수준, 그 차이와 특징 한눈에 보기

데이터베이스를 운영하다 보면 여러 트랜잭션이 동시에 실행될 때, 데이터 정합성과 동시성 제어를 위해 격리 수준이 중요해집니다. MySQL은 다양한 격리 수준을 제공하여 각 상황에 맞게 데이터의 일관성을 보장하는데요. 오늘은 SERIALIZABLE, REPEATABLE READ, READ COMMITTED, READ UNCOMMITTED 네 가지 격리 수준의 특징과 장단점을 살펴보겠습니다.

1. SERIALIZABLE – 가장 엄격한 격리, 하지만 속도는 느리다

SERIALIZABLE은 이름 그대로 모든 트랜잭션을 순차적으로 실행하는 것처럼 동작합니다.

• 특징:
  • 여러 트랜잭션이 동일한 레코드에 동시에 접근하는 것을 원천 차단하여, 데이터 부정합(불일치)이 발생하지 않습니다.
  • 순차적으로 처리되므로 동시 작업의 성능은 크게 저하됩니다.
• 잠금 방식:
  • SELECT FOR SHARE 또는 SELECT FOR UPDATE를 사용하면 대상 레코드에 읽기 또는 쓰기 잠금을 걸지만, 보통 순수 SELECT는 잠금 없이 실행됩니다.
  • 단, SERIALIZABLE 수준에서는 순수 SELECT에도 넥스트 키 락을 걸어, 다른 트랜잭션이 해당 데이터를 수정하지 못하도록 합니다.

안전성은 최고지만, 동시성 요구가 높은 시스템에서는 사용하기 어려운 격리 수준입니다.

2. REPEATABLE READ – 한 번 읽은 데이터는 변하지 않는다

REPEATABLE READ는 MySQL의 기본 격리 수준으로, 트랜잭션 내에서 같은 데이터를 여러 번 읽어도 결과가 일관되게 유지됩니다.

• MVCC (다중 버전 동시성 제어):
  • 트랜잭션이 시작되면 고유 번호가 부여되고, 데이터 변경 전의 상태를 언두 로그에 백업합니다.
  • 이를 기반으로 트랜잭션은 자신이 시작되기 전의 커밋된 데이터만 조회하므로, 중간에 다른 트랜잭션이 데이터를 변경해도 처음 읽은 데이터가 그대로 유지됩니다.
• 유령 읽기(Phantom Read):
  • 기존 레코드의 일관성은 보장되지만, 트랜잭션 실행 중 다른 트랜잭션이 새 레코드를 추가하면 조회 결과에 변화가 생길 수 있습니다.
  • MySQL은 갭 락(gap lock)을 사용해, SELECT FOR UPDATE 같은 잠금이 걸린 경우 유령 읽기를 방지합니다.

즉, REPEATABLE READ는 한 번 읽은 데이터의 일관성을 보장하는 대신, 새 레코드의 추가로 인한 변화는 완벽히 막지 못할 수 있습니다.

3. READ COMMITTED – 커밋된 데이터만 보여준다

READ COMMITTED는 이름 그대로, 오직 커밋된 데이터만 읽어들이는 격리 수준입니다.

• 주요 특징:
  • 다른 트랜잭션의 변경 사항이 커밋되기 전에는 보이지 않으므로, Dirty Read(오손 읽기) 문제를 방지합니다.
  • 단, 한 트랜잭션 내에서 여러 번 SELECT을 실행하면, 중간에 다른 트랜잭션이 데이터를 변경해 커밋된 경우 이전과 다른 결과가 나타날 수 있습니다.
    → 이는 Non-Repeatable Read(반복 불가능 읽기)나 유령 읽기(Phantom Read) 현상으로 이어질 수 있습니다.
• 사용 시 고려사항:
  • READ COMMITTED는 트랜잭션 없이 실행되는 SELECT와 트랜잭션 내에서 실행되는 SELECT 간의 결과 차이가 거의 없기 때문에, 단순 조회 작업에서는 일관된 커밋 데이터를 볼 수 있습니다.
  • 다만, 동일 트랜잭션 내에서 데이터가 변경될 가능성이 있으므로, 절대적인 일관성이 필요한 경우라면 REPEATABLE READ나 SERIALIZABLE 같은 수준을 고려해야 합니다.

READ COMMITTED는 많은 DBMS에서 기본적으로 채택하는 격리 수준으로, 안전성과 성능의 균형을 맞춘 선택지라고 할 수 있습니다.

4. READ UNCOMMITTED – 가장 낮은 격리, 위험한 선택

READ UNCOMMITTED는 아직 커밋되지 않은 데이터까지 읽어들일 수 있는 격리 수준입니다.

• 특징 및 위험성:
  • Dirty Read 현상이 발생하여, 다른 트랜잭션의 변경 사항이 커밋 전에 조회될 수 있습니다.
  • 만약 해당 트랜잭션이 롤백된다면, 이미 읽어들인 데이터와 실제 데이터 사이에 불일치가 생겨 시스템에 심각한 문제가 발생할 수 있습니다.

이러한 이유로 READ UNCOMMITTED는 데이터 정합성 측면에서 매우 취약하여, 실무에서는 거의 사용되지 않는 격리 수준입니다.

결론

각 격리 수준은 데이터 정합성을 유지하는 방식과 성능에 있어 서로 다른 트레이드오프를 가지고 있습니다.

• SERIALIZABLE은 최고의 안전성을 보장하지만, 동시성이 크게 떨어집니다.
• REPEATABLE READ는 트랜잭션 내에서 읽은 데이터의 일관성을 유지해주지만, 새 레코드의 추가로 인한 변화는 완전히 막지 못할 수 있습니다.
• READ COMMITTED는 오직 커밋된 데이터만 읽어 Dirty Read를 방지하면서도, 다소 유연한 데이터 조회를 가능하게 합니다.
• READ UNCOMMITTED는 성능은 좋을 수 있으나, 데이터 정합성에 치명적인 위험을 내포하고 있습니다.

시스템의 요구 사항과 데이터의 중요도에 따라 적절한 격리 수준을 선택하는 것이 MySQL을 효율적으로 운영하는 핵심입니다.

DB에서 사용하는 정렬 알고리즘

데이터베이스 시스템은 일반적인 프로그래밍 언어에서 사용하는 정렬 알고리즘 외에도, 대규모 데이터셋과 디스크 I/O를 고려한 최적화된 정렬 방식을 사용합니다.

알고리즘/기법 설명 사용 시점

gRPC란?

gRPC는 Google에서 개발한 고성능, 오픈소스 RPC(Remote Procedure Call) 프레임워크입니다. 프로토콜 버퍼(Protocol Buffers)를 직렬화 형식으로 사용하며, HTTP/2 기반으로 동작합니다.

이를 통해 다중 언어 지원, 양방향 스트리밍, 효율적인 데이터 직렬화와 같은 강력한 기능을 제공합니다. 마이크로서비스 간 통신에 자주 사용됩니다.