관찰과 질문, 그리고 데이터

https://youtu.be/fMq3IpPE3TUThe story of Why we migrate to gRPC and How we go about itMatthias Grüter. Engineering Manager in the infrastructure group. gRPC based infrastructure로 전환한 이유gRPC based infrastructure로 전환한 방법2500여 개의 내부 serviceingress로 들어오는 request 가 초당 8백만 (Query for Second서비스 간 통신에는 자체 개발한 protocol을 사용하고 있었음. (이름은 Hermes) RPC 프레임워크가 아니라 통신 프로토콜이었음. gRPC보다는 http와 비교대상.동작에는 문제 없음그런데 왜 ..

Using gPRC for long-lived and Streaming RPCs 발표자: Eric Anderson - gRPC Java 팀 tech lead. Google에서 근무 발표자료: https://kccna18.sched.com/event/GrWo 발표영상: https://youtu.be/Naonb2XD_2Q Long-Lived gRPC란? RPCs that last minutes / hours/ days. Long polling (Hanging Get). 예컨대 서버에서 특정 이벤트가 발생할 때까지 대기하는 로직. 강연에서는 Notification / Watches를 예시로 들었음. Hanging Get : 서버에서 요청에 응답할 데이터가 없는 경우, 해당 데이터를 사용할 수 있게 될 때까지 ..

Client Streaming 클라이언트가 여러 번 서버에 데이터 전송, 클라이언트가 응답을 언제 받을 수 있는지는 전적으로 서버에게 달려있다. 실습환경은 아래와 같은 디렉토리에서 이루어졌다. go를 설치하고 환경변수로 GOPATH를 등록한 상태로, 모든 명령어는 ~/go/src/ch4 에서 이루어졌다. 1. proto 파일 생성 greetpb 디렉토리에 greetpb.proto 파일을 생성하고 아래와 같이 입력해준다. syntax = "proto3"; package greet; option go_package="greet/greetpb"; message Greeting { string first_name = 1; string last_name = 2; } message LongGreetRequest {..

Server Streaming cf. 예제코드는 go 개발환경과 protoc-gen-go 디펜던시가 갖추어졌다는 전제로 작성되었다. Http2의 특징을 활용한, 새로운 형태의 RPC API. 클라이언트의 요청 한 번으로, 서버가 데이터를 여러 번 전송할 수 있는 형태. 실습환경은 아래와 같은 디렉토리에서 이루어졌다. go를 설치하고 환경변수로 GOPATH를 등록한 상태로, 모든 명령어는 ~/go/src/ch4 에서 이루어졌다. 1. proto 파일 생성 greetpb 디렉토리에 greetpb.proto 파일을 생성하고 아래와 같이 입력해준다. syntax = "proto3"; package greet; option go_package="greet/greetpb"; message Greeting { str..

cf. 예제코드는 go 개발환경과 protoc-gen-go 디펜던시가 갖추어졌다는 전제로 작성되었다. Unary 일반적으로 생각하는 Client - Server간 일대일 메시지 통신. Hands on 실습환경은 아래와 같은 디렉토리에서 이루어졌다. go를 설치하고 환경변수로 GOPATH를 등록한 상태로, 모든 명령어는 ~/go/src/ch4 에서 이루어졌다. 1. proto 파일 생성 greetpb 디렉토리에 greetpb.proto 파일을 생성하고 아래와 같이 입력해준다. syntax = "proto3"; package greet; option go_package="greet/greetpb"; message Greeting { string first_name = 1; string last_name = ..

Problem statement 논리적으로는 분리되어 있지만 Monolitic하게 설계된 애플리케이션이 있다고 가정하자. 내부 모듈 간 통신 속도가 빠르다는 장점 하나의 모듈에 문제가 생길 경우 애플리케이션 전체가 영향을 받음 (특정 모듈이 메모리를 과도하게 점유할 경우 시스템 전체가 죽는다던가) 그렇다보니 애플리케이션의 구조를 MicroService로 변경하려는 추세. 따라서 각각의 business / subdomain별로 별도의 시스템을 생성한 뒤 Http, Json으로 통신하는 형태의 아키텍처. Http + Json 기반 MicroService의 단점으로 생각할 수 있는 점 요청 / 응답에 걸리는 시간. 오른쪽 그림처럼, TCP 커넥션을 맺은 후에야 Request / Response를 받아올 수 있..