gRPC & High Performance APIs · 강의

메시지 압축 기법

gRPC 메시지에 다양한 압축 알고리즘을 적용하여 네트워크 대역폭 사용량과 지연 시간을 줄입니다.

메시지 압축 기법은(는) CoddyKit의 무료 gRPC & High Performance APIs 강의입니다. 이것은 4개 중 1번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 gRPC & High Performance APIs 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. gRPC & High Performance APIs 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Why Compress gRPC Messages?

When building high-performance APIs with gRPC, efficiently handling data transfer is crucial. Large data payloads consume significant network bandwidth and can increase latency, especially over slower connections.

Message compression helps mitigate these issues by reducing the size of data before it's sent across the network. This leads to several benefits:

Reduced Bandwidth: Less data needs to be transmitted.
Lower Latency: Smaller messages take less time to travel.
Improved Performance: Especially for services exchanging large, repetitive data.

How gRPC Handles Compression

gRPC is built on HTTP/2, which provides native support for efficient communication, including message compression. gRPC offers built-in mechanisms for both clients and servers to negotiate and apply compression algorithms.

Here's how it generally works:

The client can indicate its preferred compression algorithm (e.g., Gzip) in its request.
The server, if configured to support compression, will then compress its responses using a mutually agreed-upon algorithm.
Conversely, if the client sends a compressed request, the server will automatically decompress it if it supports that algorithm.

Common Compression Algorithms

gRPC implementations typically support several common compression algorithms. The choice of algorithm can impact the trade-off between compression ratio and CPU usage.

Gzip: This is a widely adopted and well-understood compression algorithm. It offers a good balance between compression effectiveness and processing speed, making it a common default.
Zstandard (Zstd): Developed by Facebook, Zstd is a newer algorithm known for its extremely fast compression and decompression speeds, often achieving better compression ratios than Gzip. It's becoming increasingly popular in high-performance systems.

While Zstd often outperforms Gzip, Gzip's broader compatibility across various gRPC language implementations makes it a safer default in some scenarios.

Enabling Client-Side Compression

To enable compression on the client side, you typically configure the gRPC channel or the specific stub used for making calls. This tells the gRPC runtime to compress outgoing requests using the specified algorithm and to expect compressed responses from the server.

In Java, you usually use the withCompression() method on your gRPC stub. For example, .withCompression("gzip") instructs the client to apply Gzip compression to the request payload.

Code Example: Client Compression

Let's see how to configure a gRPC client to use Gzip compression. We'll create a simple HelloRequest with a large data field to make the compression effect more apparent.

import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;
import com.coddykit.grpc.compression.GreeterGrpc;
import com.coddykit.grpc.compression.HelloRequest;
import com.coddykit.grpc.compression.HelloReply;

public class GreeterClient {
    public static void main(String[] args) throws Exception {
        ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50051)
            .usePlaintext() // For local testing, no TLS
            .build();

        // Create a blocking stub and enable Gzip compression
        GreeterGrpc.GreeterBlockingStub blockingStub = GreeterGrpc.newBlockingStub(channel)
            .withCompression("gzip"); 

        try {
            String name = "CoddyKit User";
            // Create a large, compressible data payload
            String largeData = "a".repeat(1000); // 1KB of 'a's
            HelloRequest request = HelloRequest.newBuilder()
                .setName(name)
                .setData(largeData)
                .build();

            System.out.println("Sending request with compression...");
            HelloReply response = blockingStub.sayHello(request);
            System.out.println("Received: " + response.getMessage());
        } finally {
            channel.shutdown().awaitTermination();
        }
    }
}

Enabling Server-Side Compression

For a gRPC server to effectively handle compressed requests and send compressed responses, it needs to be configured to support the desired compression algorithms. This involves registering a CompressorRegistry and a DecompressorRegistry with the server builder.

By registering these, the server automatically gains the ability to:

Decompress incoming requests: If a client sends a Gzip-compressed request, the server will decompress it before processing.
Compress outgoing responses: If the client indicates it supports compression, the server will compress its responses using an available algorithm.

Code Example: Server Compression

Here's how to set up a gRPC server in Java to enable compression support. We use NettyServerBuilder and register the default compressor and decompressor registries, which include Gzip.

import io.grpc.Server;
import io.grpc.ServerBuilder;
import io.grpc.stub.StreamObserver;
import io.grpc.netty.NettyServerBuilder;
import io.grpc.CompressorRegistry;
import io.grpc.DecompressorRegistry;

import com.coddykit.grpc.compression.GreeterGrpc;
import com.coddykit.grpc.compression.HelloRequest;
import com.coddykit.grpc.compression.HelloReply;

public class GreeterServer {
    private Server server;

    private void start() throws Exception {
        int port = 50051;
        server = NettyServerBuilder.forPort(port)
            .addService(new GreeterImpl())
            // Register default compressors (e.g., gzip)
            .compressorRegistry(CompressorRegistry.getDefaultInstance())
            // Register default decompressors (e.g., gzip)
            .decompressorRegistry(DecompressorRegistry.getDefaultInstance())
            .build()
            .start();
        System.out.println("Server started, listening on " + port);
        Runtime.getRuntime().addShutdownHook(new Thread(() -> {
            System.err.println("*** shutting down gRPC server");
            GreeterServer.this.stop();
            System.err.println("*** server shut down");
        }));
    }

    private void stop() {
        if (server != null) {
            server.shutdown();
        }
    }

    private void blockUntilShutdown() throws InterruptedException {
        if (server != null) {
            server.awaitTermination();
        }
    }

    public static void main(String[] args) throws Exception {
        final GreeterServer server = new GreeterServer();
        server.start();
        server.blockUntilShutdown();
    }

    static class GreeterImpl extends GreeterGrpc.GreeterImplBase {
        @Override
        public void sayHello(HelloRequest req, StreamObserver<HelloReply> responseObserver) {
            System.out.println(
                "Server received name: " + req.getName() + 
                ", data length: " + req.getData().length()
            );
            HelloReply reply = HelloReply.newBuilder()
                .setMessage("Hello " + req.getName())
                .build();
            responseObserver.onNext(reply);
            responseObserver.onCompleted();
        }
    }
}

Compression Levels & Thresholds

While gRPC handles the negotiation, you can often fine-tune compression behavior for optimal performance:

Compression Level: Algorithms like Gzip allow you to specify a compression level (e.g., 1-9). Higher levels achieve better compression ratios but require more CPU. Lower levels are faster but compress less. Choosing the right level depends on your system's CPU capacity and network constraints.
Compression Threshold: For very small messages, the overhead of compression (CPU time for compressing and decompressing) might outweigh the benefits of reduced network transfer. Many gRPC implementations allow setting a minimum message size threshold below which compression is not applied.

These settings help balance CPU usage against network bandwidth savings.

When to Use Compression

Message compression is a powerful optimization, but it's not always necessary or beneficial. Here are some guidelines:

Large, Repetitive Payloads: Compression is most effective for messages containing significant amounts of text, logs, or structured data (like JSON or XML within a Protobuf string field) that have high redundancy.
Limited Bandwidth: In environments with constrained network capacity or high network costs, compression can provide substantial savings.
High Latency Networks: Reducing message size can significantly improve perceived latency over slow or long-distance connections.

Avoid compressing data that is already compressed (e.g., images, videos, audio files) or very small, non-repetitive messages, as this can introduce unnecessary CPU overhead without much network benefit.

Compression Check

You've learned how gRPC handles message compression, its benefits, and how to enable it. Let's test your understanding.

Recap: Message Compression

Great job! In this lesson, we explored how to optimize gRPC service performance using message compression. Here's a quick summary:

Purpose: Message compression reduces payload size, improving bandwidth efficiency and lowering latency.
Mechanism: gRPC leverages HTTP/2 to negotiate and apply compression algorithms like Gzip and Zstandard (Zstd).
Client-Side: Clients enable compression using methods like .withCompression("gzip") on their stubs.
Server-Side: Servers support compression by registering CompressorRegistry and DecompressorRegistry with their builders.
Considerations: Balance CPU overhead against network savings, especially for small messages or already compressed data.

By judiciously applying message compression, you can significantly enhance the performance of your gRPC applications.

자주 묻는 질문

“메시지 압축 기법” 강의는 무료인가요?

네 — “메시지 압축 기법” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 gRPC & High Performance APIs 강의 전체를 잠금 해제할 수 있습니다. gRPC & High Performance APIs 강의에는 총 4개의 강의가 포함되어 있습니다.

“메시지 압축 기법”에서 뭘 배우나요?

gRPC 메시지에 다양한 압축 알고리즘을 적용하여 네트워크 대역폭 사용량과 지연 시간을 줄입니다. 브라우저에서 직접 실행하는 실습 코드로 gRPC & High Performance APIs을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

gRPC & High Performance APIs을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 gRPC & High Performance APIs은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 1번째 강의입니다.

“메시지 압축 기법” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 gRPC & High Performance APIs 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 gRPC & High Performance APIs 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← gRPC & High Performance APIs(으)로 돌아가기