서버-서버 간 통신할 때는 주로 어떤 방식을 쓰나요?

Question

이런식으로 이루어져 있는 서버들이 있다고 가정해보면(각 서버는 TCP통신을 사용합니다.)만약 서버1에서 서버2의 정보가 필요하다하면 보통 어떤 방식을 사용하는게 일반적인가요?만약 TCP방식을 사용한다 하면 커넥션을 쏘는(?)쪽과 받는 쪽의 기준은 어떻게 정하나요?

Clickin · Answer

제일 무난한건 아무래도 Rest API겠죠gRPC를 쓰는 경우는 정말 속도가 중요한 경우일테고요만약 보안이나 기타 사유로 자체적인 정의를 써야한다면 Spring Webflux의 Custom Codec이 많이 도움될겁니다.TCP 소켓 통신을 쓰는건 성능에 비해서 에러 처리 난이도 및 개발공수가 많이 들어서 요새는 별로 못본 듯 합니다.

Constant · Answer

위엣분이 말씀하신게 맞고 보통 순서는동기 방식의 Http 통신 -> 메시지큐 or Reactive 기반의 비동기 통신 -> gRPC 기반의 비동기 바이너리 형식으로 발전해나갑니다.

준호 · Answer

위와 같은 구조라고 하면 저라면 구지 통신으로 데이터를 주고 받지않고 서버들이 모두 접근할 수 있는 저장소(DB)를 추가 설치하고 거기 모두 데이터를 저장하게 해서 각 서버에서 필요한 데이터는 DB를 통해 접근하겠습니다.

장독깨기 · Answer

목적에 따라 좀 다릅니다.어떤 목적이든 직접 소켓 열어서 통신하는건 다 가능합니다만, 일 많아 집니다.기준은 정보를 요청하는 쪽이 클라이언트가 되고, 연결을 요청합니다.정보를 제공하는 쪽이 서버가 되고 연결 대기 합니다.기존 레거시 시스템이 있고, 이 시스템이 소켓만 지원하고, 변경할 수 없는 상황 외에는 잘 사용하지 않습니다.서버1에서 필요 시 서버2의 정보를 원하면 api 가 제일 무난하고 간단합니다.서버2의 상태를 실시간으로 서버1,서버3에서 알아야 한다면 메시지큐 같은 걸 이용하는게 유용합니다.각각의 서버 상태를 모니터링하고 환경을 동기화 해야 하는 등의 경우, 주키퍼 같은걸 이용하면 편리하게 처리 할 수 있습니다.뭐 암튼 어쩔 수 없는 상황이 아니라면 직접 소켓 열어서 통신하는건 피하는게 좋습니다. 일 많아져요. 부득이 직접 소켓 열어서 할 경우, 네티가 유명한거 같은데요(전 해보진 않았습니다만),이런 프레임웍을 이용하는게 일을 좀 줄이는데 도움이 될 것 입니다. :)

yeori · Answer

통신의 맥락이 없어서 뭐라고 얘기할 수가 없습니다.

mirheeoj · Answer

날소켓은 지금 시점에선 고려하실 이유가 없어 보이고.현재 구현된 클라이언트-서버간 통신방법을 그대로 이용하시는게 당장 구현에는 가장 편하겠죠. 서버접속인지의 여부는 따로 검증할 방법이 있어야 하지만요. 위 내용을 제외하면 일반적인 노드간 통신 방법을 결정할때와 동일한 기준으로 선택하시면 됩니다. 상황에 따라 달라질 부분이 많으니 여러 자료를 읽어보시고 결정하시면 좋습니다. https://memphis.dev/blog/grpc-vs-message-broker/https://dev.to/hypedvibe_7/what-is-the-purpose-of-using-grpc-and-rabbitmq-in-microservices-c4i#comment-1d43https://stackoverflow.com/questions/63418503/does-grpc-vs-nats-or-kafka-make-any-sense/63420930#63420930

초무쿤 · Answer

꼭 TCP 소켓통신을 해야되는 이유가 없다면gRPC로 하는게 맞겠죵. (근데 저같으면 미친 성능을 요구하지 통신이 아닌 이상 그냥 REST API로 할거 같네요...)

인성 절구로 빻음 · Answer

편하게 익숙한 방법으로 한다면 http로 하시는게 좋겠지만 http로 하시는건 오버헤드가 큰 편입니다.grpc를 사용하시는것을 추천드립니다단, 통신하는 두 서버 applicaion이 서로 다른 회사의 소유물이라면 http 통신이 맞겠습니다.

서버-서버 간 통신할 때는 주로 어떤 방식을 쓰나요?

8개의 답변

Q&A 목록