현 조직에서 어쩌다보니 gRPC 도입과 제거까지 경험을 하게 되어버렸다
내 개발자 인생에서 몇 없을 귀중한 경험이라 가볍게 적어보자한다

도입

일단 나는 신사업 팀에서 팀빌딩당시 들어가게 되었고
그때 gRPC라는 걸 처음 알게되었다.
이미 서비스하고있는 제품이있는 기업이라 이번에 새로운 사업을 하는데
공격적인 마케팅을 할거니(그때당시)
기존 서비스 되는 제품 보다 더 빨라야하고 많은 유저에 대한 대응이 있어야 한다가 요구 사항이였다

그때 당시 개발 리더님은 MSA에 server to server에 gRPC통신을 설계하셨고
백엔드 언어와 프레임워크는 주문/결제와 플랫폼서비스로 나뉘어 Java/Spring과 Node.js/NestJS 였고
나는 그중 플랫폼서비스, Node.js 쪽 담당 개발자였다.

설계

스포를 하자면 돈이 많이 들 수 밖에 없는 설계였다.
일단 신사업에 대한 투자가 많았고 기대감이 많았기때문에 가능했던 설계가 아니였나싶다.
(그래서 두번다시 없을것같다)

간단히 그리지면 서버끼리는 gRPC통신만, 서버-클라이언트는 HTTP 통신만 하는 것이다
각 도메인별로 1개의 gateway와 n개의 서비스를 가지고있고
각 서비스마다는 gRPC 통신을 gateway랑 서비스간도 gRPC,
클라이언트는 HTTP를 통신으로만 한다
여기서 말하는 클라이언트는 APP, WEB 프론트쪽을 말한다.
HTTP Alb, gRPC는 nlb를 사용하였는데
도메인 별로 각 AWS ECS 클러스터를 사용했다

문제점

경험한 그리고 전해들은 문제점 몇가지 적어보려고한다.

• proto 파일관리
  • interface와 별개로 관리되어 항상 interface와 동일하게 맞춰주어야한다
    (안그러면 프론트 개발자가 스웨거랑 왜 다르게 나와요? 라고 당신의 자리를 찾아올것이다)
  • 콜러와 콜리가 모두 proto 파일을 가지고있어야한다. 그런데 이게 관리가 쉽지않다. 레포가 다를경우에는 변경사항이 있을때마다 서로 복붙해야되는데 이게 여간 귀찮은 일이아니다.
    (이걸 개선하기 위한 좋은 글이 있는데 사용해보진 못했지만 아래 고려해야 될 점에 첨부해 놓겠다)
• grpc type
  • null이나 undefined의 경우 아예 optional 처리로 필드 자체를 제거해서 뿌린다.
  • int64 타입 등
• NestJS에서의 gRPC 지원영역
  • NestJS 에서 gRPC 지원은 굉장히 풀이 작은것같다. grpc에서 google import시 안먹히는 부분 등 작업하면서 몇번 느끼는데 결국 우리가 원하는 걸 만들기 위해서는 custom이 답이였다.
• Java/Spring 에서의 메모리릭 문제
  • 자바 개발자분들에게 gRPC를 붙였을때 고질적인 문제라고 들었다. 어떤게 원인인지는 상세히 듣지못해서 모르겠으나, 아마 gRPC 몇몇 기업들은 이 문제 때문에 gRPC 도입을 포기했다고한다

장점

그럼에도 나중에는 꼭 gRPC를 잘 활용할 수있는 조직에서 경험하고싶다.
그정도로 gRPC를 사용했을때 경험은 생각보다 대단했고 그걸 제거 하면서 느꼈다.

• 응답속도
  • 속도가 빠르다. 이건 모르고있다가 제거하면서 경험해 버렸다..
    동일한 데이터, 동일한 로직, 동일한 서버환경, gRPC 제거했을때 api 응답속도가 많으면 1.8배 정도 차이가 났다. gRPC 제거했을때, 2s인 api가 3.8s 로 늘어난셈이다.
  • 구글에서 본인들이 사용하던 기존 http 통신이 느리다고 생각하고 만든게 gRPC 라는데 왜 그랬는지 알것같다
• 서버통신 네트워크 단 분리
  • 서버 통신부는 gRPC 통신으로 네트워크 단 분리가 되어있으니 보안에 더 좋지않았을까한다.
  • gRPC의 nlb는 aws private VPC로 내부 서버만 통신가능하게 만들었으니 말이다
  • 제거하고 서버통신을 http 통신으로 변경하면서 서버간 통신은 어떻게 할건지? 서버통신용 서버를 새로 생성하는지? 인증토큰을 서버용으로 만드는지? AWS WAF로 분리할 것인지? endpoint를 넣어 ALB Role로 분리하는지? 에 대한 논의가 뜨거웠다. 아마 이런 고민 할필요없는게 gRPC 장점이 아닐까?
• 요청값과 응답값을 내맘대로
  • rpc 서비스별로 요청값과 응답값을 proto만으로 내 마음대로 필요한 값만 받고 내어주면서 조절할수있다
  • 제거시에 dto를 정의해도 serialize가 되어있지않아, 요청값을 다 받아버리고 응답값도 다 내려주는....대참사가... 제거 후 serialization를 작업했다.....

그리고 제거와 회고

어쩌다가 gRPC 문제점이 더 많았는데
gRPC 도입은 항상 신중해야한다.
개발자로써 gRPC의 장점은 정말 매력적이지만
도입부터 많은 비용과 리소스가 들어가고 제거도 그만큼 더 많이 작업이 들어간다.
이걸 몇주안에 하는건 더더욱 위험할 것이다. 그만큼 고려해야할 점이 많기때문에

항상 내가 만든 자식같은 존재를 내 손으로 지우기란 쉽지않다.
그만큼 아쉬움이 많고 내가 좀더 공부하고 더 지식이 높았다면 더 잘쓰지않았을까 라는 후회와 자책감이 밀려온다.
하지만 회사는 이윤이 목적이다 날 기다려주지않는다.
비용이 매출에 비해 많이 발생하게 되면 비용의 원인을 먼저 제거할 수 밖에 없다.
아쉬웠지만 떠나보내면서 도입과 제거 경험은 많은걸 느꼈고 탈도 많았던 귀중했던 경험이였다.
나중에 개발자들끼리 모이면 술안줏거리 정돈 되지않을까

마! 니는 gRPC 2년 운영 해봣나!

하면서 말이다

+ 추가) 당신이 도입에 고민하고 있다면?

만약 지금 이글을 읽고있는 당신이 gRPC 도입에 고민하고 있다면 고려했으면 하는 점이다

• proto 파일관리
  • 이걸 개선하기 위한 좋은 글
  • monorepo
    • 필자는 proto 파일관리는 monorepo였던 덕을 많이 봤다 (대신 다른 언어의 grpc 통신은 위 링크를 참조해라)
• 서비스를 어디까지 분리할 것인가?
  • 지금 다시 gRPC를 설계하라면 난 gateway를 도메인 단위가 아닌 BFF를 목적으로 통합 gateway로 사용할것같다.
  • 너무 많이 쪼개면 비용이 많이 나올수 밖에없다. (그만큼 서버가 늘어나는거니)
• 고도화
  • NestJS 에서는 아직 gRPC를 사용하기엔 지원 풀이 적다.
  • gRPC 서비스와 NestJS 사이에 config 부분과 node에서 proto를 읽어오는 부분을 custom하는 방법을 조금 더 찾아보았으면한다