스포카에서 일하면서 부쩍 마이크로서비스 단위로 배포하여 제품을 구현하는 일이 많아졌습니다. 그러다보니 같은 파이썬 프로세스 안에서는 간단하게 파이썬 함수 호출로 해결할 수 있던 것들도 항상 RPC를 위한 외부 인터페이스를 구현해야 하고, 또 호출하는 쪽에서도 그것을 사용하기 위한 코드가 많이 필요했습니다. 그 뿐만 아니라 장애 내성을 항상 고려하여, 상대 서비스가 죽어도 어떻게든 failover하도록 구현하는 것도 필요합니다. 그러다보니 하나의 모놀리틱 서비스로 구현할 때에 비해서 필요한 코드가 훨씬 많아질 뿐더러, 서비스 사이에서 비슷한 코드가 공유되지 않은 채 복제되는 현상도 나타났습니다.
이를 극복하기 위해 기존의 Thrift나 Cap’n Proto와 같은 RPC 프레임워크 도입도 했으나, 결과적으로 스포카의 비즈니스 패턴과는 잘 부합하지 않는다는 교훈을 얻었습니다. 이를 바탕으로 스포카 내에서 쓰기에 알맞은 RPC 프레임워크를 만들게 되었습니다.
본 발표에서는 크게 3가지 경험을 공유하고 싶습니다.
기존 범용 RPC 프레임워크가 제공하는 기능들과, 제공하지 않는 기능들에 대해서, 그리고 실제 적용했을 때의 어려웠던 점을 공유합니다.
스포카가 다루는 비즈니스 특성이 어떻게 범용 RPC 프레임워크와 잘 맞지 않게 되었는지, 그 결과 새로 만들게 된 RPC 프레임워크가 특징적으로 고려해야 했던 설계가 무엇이었는지 공유합니다.
실제로 RPC 프레임워크를 구현하다보면 마주하게 됐던 미처 생각하지 못했던 어려움에 대해서도 공유합니다.