상어코딩

gRPC Deadline · Cancellation · Context Deep Dive — 5쌍의 레이어가 동시에 서야 한다

gRPCDeadline · Cancellation · Context Deep Dive — 5쌍의 레이어가 동시에 서야한다들어가며"3초 SLA"라고 써놓고 실제 호출은 9초 뒤에 503으로 돌아온다.BANDER에서 이 현상을 처음 봤을 때, 타임아웃 설정을 잘못 읽은 줄 알고application.yml을 뒤졌다.grpc.client.deadline: 5s가 멀쩡히 있었다. 스타트업 로그에도deadline=PT5S가 찍혀 있었다. 그런데 서버 쪽ServerInterceptor에서 꺼내본 호출의 Deadline은null이었고, HTTP/2 HEADERS 프레임을 Wireshark로 덤프해보니grpc-timeout 헤더 자체가 존재하지 않았다. 선언은있는데 wire에는 아무것도 나가지 않은 상태, 전형적인 de..

gRPC Streaming Deep Dive — 4가지 모드는 왜 프로토콜이 하나인가

gRPCStreaming Deep Dive — 4가지 모드는 왜 프로토콜이 하나인가들어가며gRPC 입문서를 펼치면 거의 예외 없이 같은 네 줄이 등장한다. Unary,Server-streaming, Client-streaming, Bidirectional. 네 가지 "모드"라는표현 때문에 처음 보는 개발자는 이걸 네 개의 다른 프로토콜 내지는 네종류의 다른 커넥션처럼 읽는다. 한 줄로 바로잡자면, 네 모드는 한HTTP/2 stream 위에서 "요청 메시지가 1개냐 N개냐" × "응답 메시지가 1개냐N개냐"의 2×2 매트릭스일 뿐이다. 프로토콜은 하나고, wire 포맷도동일하고, HEADERS·DATA·trailer HEADERS라는 프레임 흐름의 대골격도 같다.달라지는 건 .proto의 stream 키워..

Protocol Buffers 내부 — wire format과 proto3의 함정

ProtocolBuffers 내부 — wire format과 proto3의 함정들어가며1편에서HTTP/2와 gRPC의 프레이밍을 봤다면, 이번에는 그 위에 실려서 흐르는 바이트자체, 즉 Protocol Buffers를 들여다본다. 많은 개발자가protobuf를 "JSON의 바이너리 버전" 정도로 이해하지만, 그 인식으로는실무에서 터지는 거의 모든 사고를 못 막는다. protobuf는 작은 JSON이아니라 컴파일 타임에 강제되는 타입 계약이고, 바이트를그려 읽지 못하면 왜 4.2 KB JSON이 900 B로 줄어드는지, 왜int32 amount = -1이 10바이트나 먹는지 설명이 안 된다.한 예시부터 박는다. 같은 Payment 메시지에amount: -1을 담아 보낸다고 해보자. int32로선언했다면 이..

gRPC 기초 — HTTP/2 위에서 RPC는 왜 다시 태어났는가

gRPC 기초 —HTTP/2 위에서 RPC는 왜 다시 태어났는가들어가며gRPC를 처음 만나면 "Google이 만든 RPC 프레임워크"로 요약되고, 그줄에서 이야기가 멈춘다. 그런데 RPC는 2000년대 초에 이미 CORBA와 SOAP로한 번 꺾였던 개념이다. 그걸 Google이 2015년에 다시 꺼내 들었고, 시장은"또 RPC냐"라고 반응하지 않고 오히려 Netflix·Square·Dropbox·Slack이줄줄이 갈아탔다. 중요한 지점은 gRPC가 REST의 대체가 아니라,REST가 풀지 못한 네 가지(계약 부재·JSON 파싱 비용·단방향·코드 수작업)를HTTP/2 위에서 다시 푼 시도라는 것이다. 이 시리즈는 그 "다시 푼방식"을 6편으로 쪼갠다. 이 글(1편)은 물리 계층 — HTTP/2 프레임, g..