Tag Archives: RPC

gRPC 적용기 with JPA,Spring

gRPC

RPC기술인데 시리얼라이징 기능은 protocol buffer을 사용하고
gRPC는 strema 서버동작에 집중되어 있다.
아쉬운점은 protocol buffer에서의 아쉬운점 그대로다.
protocol buffer에 너무 의존적이 된다.
restful/json/bson/xml처럼 프로토콜만 맞추면 뭘 써도 되는 그런 라이브러리와는 다르다.

protocol buffer의존성에서 좀 벗어나서 thrift를 사용할 수 있게 변경하려는 것 같은데
다른것들도 적용이 되려나 모르겠다.

JPA와의 궁합

매핑지옥이 시작된다.
API가 실행될 때 마다 리플렉션을 사용하기는 싫고
몇몇 해결방안으로 제시된 것들을 보면

  • jpa를 xml로 생성한다는데… protocol buffer로 생성된 클래스에 xml로 생성된 코드를 오버랩핑한다는건가? 잘 이해가 안가고 솔루션이 제시된것도 아니라서 패쓰
  • .proto 파일이 아닌 어노테이션을 기반으로 protocol buffer의 객체를 사용할 수 있게 해준다는 것 같은데… 괜찮은 솔루션같은데 공식 라이브러리가 아니라 개인프로젝트가 아닌곳에 적용하긴 겁난다
    https://github.com/BAData/protobuf-converter

같이 쓰기 썩 좋지는 않다. 매핑노가다나 리플렉션 매핑을 좀 이용해야할 것 같다.

Spring과의 궁합

없다. 그냥 별도라고 봐야할 것 같다.
현재 SpringBoot를 이용하고 있는데 아직 별로 나온게 없어 보인다.

알수없는 오류

컴파일러 플러그인을 다운받는데 백신이 exe파일을 자꾸 지워버린다.
exe어쩌고 하면서 실행이 안될때 확인하자

결론은

아직 완전히 적용한것은 아니지만..

쓸만하긴한데 생태계가 완벽하지 않아서 신경쓸게 좀 많다.

MessageQueue를 이용한 비동기 RPC방식보다 나은지 잘 모르겠다.
아직 고민만 해보고 테스트는 못해봐서… 아예 안쓸지도 모르겠다.

RPC vs RESTful API

개요

약간 고민하게 되는데 생각보다 간단한 결론은

RPC는 내부 프로토콜로 사용 – 인프라 내부가 아닌 내부 서비스간의 통신.
APP의 API로도 사용가능.

REST API는 외부공개용.

끝.

요약

RPC

내부 서비스간 통신

RESTful

외부 공개용

ex)ample

ModileApp은 외부에 있지만 내부 서비스이다. API와 RPC통신
외주사가 회사 내부망에 설치한 GIS솔루션은 내부 서비스가 아니다. RESTful 방식사용

MSA의 시대, 다시 주목받을 RPC

RPC : Remote Process Call 진영은

몇년째 딱 대표적인 기술이 떠오르지 않고 고만고만하게 유지되고 있다.

개인적으로 RPC가 더 편하다고 생각하는데, RestAPI가 너무 대세가 되서 인기를 잃어버려 아쉽다.

아니 먼 RestAPI 데이터를 브라우저로 봐서 뭐한다고?!?~!

지금당장 기억나는것은 이정도….

Thrift
Avro
gRPC
ProtocolBuffer
BSon

완전 RPC라고 하기는 좀 그런 시리얼라이징 기술도 넓게 보면 RPC아닐까…
아니 그냥 RPC인가? 그냥 다 포함시켰다.

아직까지는 연동 API 제공 한다고 하면 당연하다는 듯이 RestAPI를 제공한다.

API는 다양한 문제점을 가지고 있고 기술적으로 열등하기 때문에 점점 사용률이 낮아질거라고 본다.

표준기술로 사랑받아왔던 RestAPI의 문제점들

  • 무거운 http api만드는데 http를 돌리는데 코스트낭비가
  • 너무 자유로운 설계 json을 ?params=%XX%XX 형태로 받는 경우도 있고
  • http1 프로토콜에서 낭비되는 네트워크 리소스 http2로 사용하면 좀 더 낫긴하겠지만..

웹기반 기술에서는 계속 사용되겠지만 MicroService가 등장하며 내부 네트워크 부하가 더 심해지는판에.. 이걸 계속써야할까?

아니

여태까지는 아키텍처/UX까지 Request후 Response를 기다리는 형태로 설계가 되었으니 RestAPI를 써도 불편한줄을 몰랐다

async환경으로 변화는… 패러다임의 변화다. 설계까지 변경된다.

변화의 조짐은 보인다.

요즘 유행하는 기술 트렌드를 보면

MSA, Async, Functional Programming

이정도… 그리고 이런 트렌드가 지속/확대 된다고 봐도 될 것 같다.

왜냐? 작은조직의 효율적 개발, 클라우드환경, 늘어나는 네트워크 트래픽 등등의 상화을 봤을때 방향성이 그쪽을 향하고 있으니까…

새로운 트렌드는

MicroService사이의 통신을 위한 가벼운 프로토콜 + MQ(MessageQueue) 클러스터를 이용한 내부 통신채널 일원화 + Functional Programming을 통한 Async방식 개발

이 될 것이고

MQ를 이용한 Async프로그래밍을 도와주는 프레임워크이 등장하면서 RPC 사용이 활발해질 것이다.

이직후에 프레임워크 만들면서 쓸만해보이면 공개나 해볼까…

객체지향의 기본 구조 .. to_string — from_string …..되면 좋겠다.

toString의 구현… 객체지향 언어에는 보통 다 존재하는 이 메서드…

사람이 인지할 수 있는것은 어떤 패턴… 그림으로는 의미를 나타내기 힘들기 때문에 toImage보다는 toString를 사용하는 것 같다.
객체지향 언어에서는 struct(구조체)의 역할을 대신하기도 하니까.. 데이터를 담고있는 객체의 toString의 역할은 더욱 중요하다. 객체의 중요한 데이터를 모두 뽑아내 보여주는 역할….

사람이 뭔가를 인식하는 것은 결국에는 문자열이기 때문에… 디버깅시에도 중요하게 사용된다.

toString를 사용하는 경우는 보통 두가지다.
1. 객체내의 중요 데이터를 보여주는 역할
2. 객체내의 모든 데이터를 보여주는 역할…

1번은 보통… 데이터 출력시에 사용되고… 일반적으로 이 구현을 사용한다.
2번은 이클립스나 롬복을 이용해 자동으로 생성된 코드일 경우….

fromString의 구현을 위해서는 1번과 2번을 구분할 필요가 있다.
1번은 완성되지 않은 형태의 데이터를 출력하게 되고 2번은 객체 복원을 위한 객체스트링이 된다.
2번은 직렬화랑 비슷한 개념이 될까…? (같은건가? 직려로하 그 자체인가? 개념이 좀 부족한듯..차후 추가변경) 현재 객체 생성 및 구현시에 막무가내로 사용되고 있는 toString포멧의 표준화가 좀 필요할 것 같다. json형태의 출력이라던가….

이 부분에 대한 표준이 잘 잡히게 되면 언어간 제한없이 더 쉽게 RPC콜이 가능해질 것 같다.
아니면 그냥 이것들을 구현해놓고 상속해서 사용하게 하면… 간단하게 RPC를 만들 수 있지 않을까… 뭐 그렇다고 이걸 만들 시간은 없고 이미 RPC프레임워크들이 많아서 그냥 갖다쓸거지만