백엔드 통신 패턴

Last updated Oct 2, 2023

• Backend
• Design patterns

• 마치 클라이언트-백엔드처럼 핑퐁 동기 통신

• 요청하고 기다렸다가 응답이 오면 그 다음 수행
• 예) RESTful API : 특정 endpoint(URL)로 GET, POST, PUT, DELETE 와 같은 http 요청을 하여 필요한 데이터를 응답값으로 받아 처리

• 단순하고 구현이 용이하여 가장 많이 사용되는 패턴
• 여러 상황에 대부분 다 적합한 편
• 확장성 : 각 요청이 개별적이기 때문에 단순하게 여러 요청을 처리하기 쉬움
• 신뢰성 : 항상 요청은 응답을 보내야 함으로, 제대로 이루어 지지 않은 경우 이를 모니터링 하기 용이함.
• 디버깅 용이성 : 응담에는 항상 상태 코드와 메세지가 내려가기 때문에 받는 쪽에서 에러 처리가 용이함.

• latency 문제 : 요청에 대해 응답이 올 때 까지 기다리기 때문에, 요청이 너무 많이 몰리는 상황에서는 latency가 길어질 수 있음.
• 장애 발생시 데이터 불일치 : 요청 처리한 후 응답 중간에 네트워크 이슈가 생기면 데이터 불일치가 생길 수 있음.
• Broadcasting 비효율 : 동일 데이터를 여러 클라이언트에 전송시 효율이 떨어진다.

• 컴포넌트 간의 비동기 통신을 위해 사용.
• 함께 작동해야하지만 디팬던시를 분리시키고자 할때 적합

• publisher와 subscriber 중간에 메세지 큐(메세지 브로커)를 사용
• 메세지를 채널(혹은 토픽)로 그룹화
• publisher : 메세지를 만들어 보내는 쪽. 메세지를 만들어 채널/토픽에 던지기만함
• subscriber : 메세지를 소비하는 쪽 . 구독하고자 하는 채널/토픽에서 메세지가 올때마다 copy를 받음
• 예 ) Apache Kafka, MQTT

• 비동기 통신 : latency 병목을 줄여 실시간 어플리케이션에 적합
• 느슨한 결합(Loose Coupling) : 컴포넌트 사이가 묶여있지 않음
• 확장성 : subscriber 제한이 따로 없고, subscriber가 구독할 수 있는 publisher의 수가 정해져 있지 않음. 계속 확장 가능
• 언어와 프로토콜이 독립적 : 언어나 환경, 플랫폼에 종속적이지 않기 때문에 크로스 플랫폼 호환성이 뛰어남
• 로드 밸런싱 ; 여러 subscriber가 특정 이벤트를 구독하는 경우, subscriber 간에 이벤트를 균등하게 배분함으로써 로그 밸런싱 기능을 제공할 수 있다.

• 시스템 오버헤드 : 단순히 pub/sub 뿐만 아니라 메세지 브로커, 채널과 subscribe 등 관리 포인트들이 늘어난다.
• 메세지 복사 : 구성 혹은 네트워크 상황에 따라 메세지가 중복 될 수 있다. 이를 해결하기 위해 중복 및 추가 처리 작업을 해야할 수도 있다.
• 확장성이 더 문제일지도 : 많은 양의 메세지와 subscriber가 생기면 그 역시 관리 대상이 됨
• 복잡한 에러 처리 : 메세지 전송 실패, subscribe 실패 등 이슈 상황에 대한 처리가 더 복잡 할 수 있음.

• 실시간 채팅이나 여러 플레이어를 위한 게임에서 지연 시간은 짧고 실시간으로 응답을 하는 기능
• 이벤트 알림 시스템
• 로깅 및 캐싱에 의존하는 분산 시스템에서

• pull-based 통신 방법으로 서버에 새로운 업데이트가 있는지 지속적으로 땡겨(polling)가는 식
• 예를 들어, 친구한테 “나한테 메세지 왔어?” “아니” (좀 있다가…) “나한테 메세지 왔어?” “아니” (좀 있다가…) “나한테 메세지 왔어?” “ㅇㅇ 여기”
• 요청-응답 패턴 과 다른점은 데이터 사용 여부와 상관 없이 정기적으로 미리 정해놓은 시간에 계속 통신

• 단순성 : 구현이 쉬우며 서버/클라이언트 간에 상태를 따로 신경쓸 필요가 없어, 복잡성을 최소화 해야하는 경우에 적합
• 호환성 : 플랫폼과 환경에 종속성이 없어 크로스 플랫폼 가능
• 주기적인 업데이트가 필요한 시나리오에 적합 : 대시보드, 날씨 앱, 리소스 모니터링 등

• latency : 미리 정해진 간격이 있기 때문에 그 시간 만큼 지연 시간 발생. 실시간 통신이 불가능
• 비효율성 : 데이터 변화가 없음에도 계속 폴링하기에 비효율적이고 불필요한 네트워크 및 서버 오버헤드를 초래할 수 있음
• 스케일링 : 너무 많은 클라이언트가 동시에 폴링하는 경우 서버의 리소스를 과다하게 사용할 수 있음.

• Short polling과 동일하게 polling 이지만 push-based 통신 방법으로, 연결을 계속 하고 있다가 서버에서 업데이트가 있는 경우 서버에서 보내주는 방식
• 예를 들어, 친구랑 전화를 연결하고 “업뎃 있으면 알려줘” (계속 전화 연결중) “옛다 업뎃.”
• 클라이언트/서버간에 실시간 혹은 실시간에 가까운 업데이트 실행을 위해 사용

• 짧은 latency : 업데이트가 있는 경우 클라이언트에 즉시 전송되기 때문에 기존 polling 방식보다 지연 시간이 딻다.
• 실시간 업데이트 : 이미 클라이언트/서버 연결이 된 상태이기 때문에 다음 폴링까지 기다리지 않고 바로 실시간 업데이트 가능

• 리소스 소모 : polling 시간동안 클라이언트 수만큼 연결을 열어 두어야 한다. 그러므로 클라이언트/서버 모두 리소스 소모가 많다.
• 여전히 존재하는 latency : short polling 보다는 짧지만 여전히 웹소켓과 같은 다른 실시간 통신보다는 latency가 존재
• 확장 어려움 : 동시에 많은 클라이언트를 처리해야하는 서버 입장에서는 리소스가 많이 드는 부담. 클라이언트가 많아질수록 효율적 관리 어려움

• 실시간 업데이트, 이벤트 중심 어플리케이션, 이벤트 알림 시스템 등

• 연결된 클라이언트에 실시간으로 업데이트를 전달.
• 클라이언트가 물어보는 것이 아닌 서버가 클라이언트에게 응답을 push
• 가장 널리 사용되는 프로토콜은 “web Socket”

• 실시간 업데이트 : 서버가 업데이트를 바로 보내줌
• latency 감소 : 업데이트가 있을 때 클라이언트에 바로 주기 때문에 지연 시간이 감소
• 효율성 : 지나친 요청(폴링, 클라이언트 요청)이 필요하지 않기 때문에 네트워크 리소스를 효율적으로 사용 가능

• 확장성 : 클라이언트 수가 늘어나게 되면, 연결을 맺고 있어야 하는 서버 입장에서는 리소스 부담
• 클라이언트 지원 : 모든 클라이언트 플랫폼이 push 기술을 지원하고 있지 않음으로 이로 인한 한계가 있을 수 있음

• 채팅, 메세징 앱, 알림 시스템, IoT 데이터 스트리밍, 온라인 게임 등

• Communication Design Patterns for Backend Development