2021.07.29

[Hae-Riri]

• 프로토콜 버퍼란?

  구조화된 데이터를 직렬화하기 위한 매커니즘으로 빠르고 작고 간단하다.

• 메시지를 바이너리 형식으로 직렬화하는 또 다른 방법이라고 보면 된다.

내부 모습. 백엔드에서 뭔일이 나나?

생성된 클래스를 보면 안에 stream으로부터 int, string을 읽어오는 부분이 있다. (직렬화가 바이트로 인코딩하고 객체로 복원하는 일련의 과정인데 그 중 객체로 복원하는 과정(디코딩)이 생성된 클래스 내부에 있다.)

• CodeInputStream.readInt32()같은 걸 쓰고 있는데, CodeInputStream은 메시지필드를 읽고 디코드 하는 역할이다.

• Person 이라는 message를 만들면 protoc로 컴파일되었을 때 Person.java가 생성된다. 얘를 통해 우리는 Person이라는 메시지 유형에 대해 클래스로 접근할 수 있다.

  • 컴파일된 파일 내부에는 아래와 같은 것들이 있다.

  • FileDescriptor : 파일에 대한 설명자

    파일의 내용에 대한 정보를 캡처함. proto파일의 이름과 그 안에서 선언된 패키지, proto3버전을 따른다는 사실을 보여주는 구문, 그 외의 추가 정보가 있음.

  • FieldDescriptor : 필드에 대한 설명자

    index(필드순서) / 번호(태그) / type(변수의 데이터 유형을 숫자로 표현. 문자열이면 9 / has_default_value : 기본값이 제공되었는지 여부 / default_value : 기본적으로 제공되는 값. 제공되지 않으면 protobuf에 각 데이터 유형마다 정의된 기본값이 있음. / label : 필드가 required, option, repeated인지 여부를 나타냄.

  • GeneratedProtocolMessageType 이라는 메타 클래스를 제공함.

  • EnumDescriptor

  • EnumValueDescriptor

  • Descriptor : 메시지에 대한 설명자

프로토콜 버퍼의 장단점

• 더 작고 빠름. 컴파일러 등의 도구를 제공함
• 바이너리 포맷이라 사람이 읽기 어렵고 데이터 포맷을 파악하려면 .proto 파일이 필요함.

몇가지 데이터 타입들 살펴보자.

• FieldDescriptor : 메시지 타입의 필드를 이야기하는 타입
• GeneratedMessageV3 : 모든 Generated된 프로토콜 메시지 클래스들은 이 - GeneratedMessageV3를 상속받는다. 대부분의 message와 builder 인터페이스를 java 리플렉션을 통해 GeneratedMessageV3가 구현한다. 사용자는 그냥 이 클래스는 무시하고 모든 generated message들이 Message 인터페이스를 직접 구현한다고 생각하면 된다.
• java reflection : 구체적인 클래스 타입을 몰라도 그 클래스의 메소드, 타입, 변수에 접근할 수 있게 해주는 자바 api. 인데.

  자바 소스코드를 작성하면 컴파일러에 의해 .java 파일이 .class 파일로 컴파일 됨. 이후 jvm이 .class 파일을 읽어들일 때 클래스로더가 메모리에 클래스를 로딩(적재)하게 된다. 이때 이 .class는 바이트 코드로 이루어져 있다. 리플렉션은 이 부분을 다루는 강력한 api로, .class 파일에 적힌 자바 바이트 코드대로 메모리에 올렸다가 리플렉션 코드에 의해 세세한 부분까지 접근이 가능하게 함.

[Hae-Riri]

코틀린

• up casting : 하위 클래스(cola)가 상위클래스화. 축소.
  • var A: Drinks = Cola() (o)
  • 콜라는 drink를 확장한건데 이걸 다시 축소판인 drink에 넣음.
• down casting : 상위 클래스가 하위클래스화. 확장
  • var A: Cola = Drinks() (에러)
  • 다운 캐스팅은 자동적으로 실행시켜주지 않음.
  • 드링크를 더 확장시킨 cola에 넣어버리면 콜라의 일부 메소드를 사용하지 못하겠지?

    as 활용.

• 전체적인 코드에 다운 캐스팅을 적용할 수 있는 방법임.
• 인스턴스 = super클래스(축소판)로 만든 인스턴스 as 다운캐스팅한 자식클래스(확장본)
• Any(모든 자료형의 슈퍼클래스)인 ReqT(축소판)가 있고, 확장판인 특정 request가 있음.
• modifed request as ReqT 를 통해 확장판->축소판으로 다운캐스팅함.
• 자식클래스를 -> 부모 클래스로 다운캐스팅!

[Hae-Riri]

gRPC Interceptor

gRPC는 client, sever 단위로 인터셉터를 구현하고 설치할 수 있는 간단한 api를 제공한다. 인터셉터는 각 rpc 호출을 중간에서 가로채는 역할을 하고, 사용자는 인터셉터를 사용해서 로깅, 인증/권한부여 등 rpc 전체를 아우르는 공용 기능을 수행할 수 있다.

• gRPC에서 인터셉터는 rpc 호출 유형에 따라 크게 두 가지로 구분할 수 있다.
  1. unary 인터셉터. unary RPC를 가로채는 애임.
  2. stream 인터셉터. stream RPC를 가로채는 애임.
  3. client, server 각각에 위 인터셉터가 있어서 총 4가지 타입이 존재함.

클라이언트 인터셉터

• UnaryClientInteceptor는 func(ctx context.Context, method string, req, reply interface{}, connection, invoker, opts, .. 와 같은 형태임.

  전처리, rpc 호출, 후처리 세 부분으로 나뉨.

  1. rpc 호출의 컨텍스트, 메소드 문자열, 전송 요청 등의 설정 정보를 전처리에 사용 가능함. 이걸 이용해 rpc 호출을 수정할 수 있음.
  2. 전처리가 끝났다면 invoker 를 호출해서 rpc 요청을 호출할 수 있음.
  3. invoker가 응답과 오류를 반환하면 이제 rpc 호출의 사후처리를 수행할 수 있음. rpc 응답시각과 에러 등을 기록할 수 있다.

• Stream Interceptor는 func(ctx context.Context, desc *StreamDesc, ClientConnection, method string, streamer, opts... 등의 형태를 가짐.
• stream 인터셉터는 전처리, stream 수행 인터셉트를 포함한다.
  1. 전처리는 unary와 비슷
  2. rpc 호출 비슷
  3. unary와는 다르게 후처리가 아닌 stream을 가로채는 일을 한다. client stream을 가져와서 wrapping으로 감싸고 해당 메소드를 오버로딩한 뒤 감싼 스트림을 사용자에게 반환함.
  4. 예를 들어 client stream을 포함한 새 구조체 wrappedStream을 정의해서 sendMsg, RecvMsg 메서드를 wrappedStream에 오버로딩해서 메시지 유형 정보와 정보를 기록하는 인터셉터가 된다.

서버 인터셉터

unary Interceptor

ServerInterceptor, ClientInteceptor

• 서버인터셉터
  • 서버사이드로 들어오는 콜을 가로챈다.
  • 로그나 모니터링, 다른 서버로 호출을 대신 해줌,
• 클라이언트 인터셉터
  • 로그 모니터링 가능
  • 메타데이터를 추가할 수 있음. 프록시가 확인하게 하기 위해서.
  • 요청과 응답을 다시 쓸 수 있음.

[Hae-Riri]

https://www.mobiinside.co.kr/2019/09/26/buzzvil-grpc/

MSA에수 중요한 건 네트워크 속도. 모놀리식 아케틱처에서 모듈 간 통신은 하나의 프로세스에서 이루어지는 반면, MSA에서는 다양한 서비스들이 다른 프로세스, 다른 호스트에서 돌아가고 있으며 각 서비스 사이 통신이 매우 빈번하게 일어난다.

protocol buffer를 사용하는 grpc는 일반적으로 http/json 요청보다 빠른 속도를 보인다. 물론 요청 한번에 엄청나게 많은 시간을 절약해주는 건 아니지만 하나의 요청에 많은 내부 요청을 사용하는 MSA를 사용하려면 네트워크 요청 시간을 조금이라도 줄이는 게 매우 중요하다.

서비스 간 통신 규약을 정하는 것도 중요하다. 서비스 사이 의존성이 낮아지면서 얻은 장점 대신, 각 서비스가 변경되면서 발생할 수 있는 문제들이 생겨나게 된다. Json을 통한 직렬화는 서비스 사이에서 쉽게 규약이 어긋나거나 실수하기 쉽고, api route 역시 변경 사항을 널리 적용하기 어렵다. 물론 잘 구성된 문서를 통해 규약을 맞추거나, swagger 같은 open api 도구를 사용할 수도 있지만, 이 역시 grpc처럼 학습 비용이 필요한 건 마찬가지다. 어차피 학습한다면 성능 더 좋은걸 학습하는게 낫지?

하나의 proto 파일로 go, python, java, swift 등 다양한 언어의 서버/클라이언트 코드를 생성할 수 있다.

grpc를 http/json으로 변환할 수도 있다. 프로토콜버퍼를 적절하게 json 형태로 선언만 해주면 하나의 grpc 서버로 두 형태 모두 대응할 수 있다. (근데 이걸 반대로 해 내는 방안에 대해서는 알아보는 중임)

[Hae-Riri]

https://ooeunz.tistory.com/130