간단한 실습

사용하신 스택(BE) : Spring Boot, Spring Web, JPA, H2 Database

프론트엔드 : Node.js

Reverse Proxy : nginx

Reverse Proxy

nginx.conf에서 Reverse Proxy가 가능하도록 설정을 해주어서, 일반적인 요청은 localhost:3000으로, api/* 요청(백엔드 서버에 보내는 rest api request)은 포트 번호 8000으로 가도록 설정을 해준다.왜? CORS 처리를 위해서.

API Gateway

• 마이크로 서비스 : 여러 소규모 어플리케이션 서비스가 독립적으로 실행된다. 각 기능을 개별적으로 업데이트/배포/확장하기 좋다.
• 클라이언트-마이크로 서비스 간 직접통신 : 클라이언트에서 개별적으로 요청을 보내면 마이크로 서비스에서 또 개별적으로 우르르 답을 주는 번거로운 통신 -> 이를 해결하기 위해 사용하는게 API Gateway이다.
• 클라이언트 앱과 마이크로 서비스 사이에서 Reverse Proxy를 해준다.

이런 Multiple API 게이트웨이 패턴도 있다.

CORS

Cross-Origin Resource Sharing

다른 출처(Host)에서 접근하는 것을 막기 위한 정책

프로세스 간 통신

IPC

• 공유 메모리 : 어렵다.
• Message : 구현이 덜 어려워서 많이 사용한다.

Rest API

• Rest API는 이 중 Message를 사용함.

• Http Method를 기반으로 동작하는데, Http Method는 CRUD와 기타등등 총 8개 정도 있다. 갯수가 적다보니 커스터마이징이 어려움.

RPC(Remote Procdure Call)

• 원격 함수 호출. 클라이언트와 서버가 이벤트 방식으로 주고받는다.

• Protobuf를 통해 구현한다.

• http보다 복잡하고 low level
• 장점 : 기능이 강력함. 커스터마이징 가능, json 못 읽는 클라이언트도 가능하다. (ex. 엑스박스, 임베디드 등등) 전송 속도도 빠른 까닭에 분산 서버에서 강력함.
• 단점 : 배우기 어렵고 쓰기 어렵다.
• 이런 단점 보완하기 위하여 구글에서 grpc 제공 (웹 클라이언트에서 rpc 호출이 불가능했었는데, 브라우저에서도 grpc 호출이 가능해진다.)

트랜잭션 보장

• GRPC는 메시징 방식으로 트랜잭션도 보장해준다. - 메시지 브로드캐스팅해서 전체 싱크를 맞추는 식. 찰나에 안맞을 수는 있겠지만, 전체 싱크가 매우 중요한 작업이 아니라면 무시할만하다.
• FPS 게임 등에서는 트랜잭션 보장 뿐만이 아니라 싱크 맞추고, 한 공간에 1000명이 있어도 중대한 에러 없이 잘 동작해야하므로 RPC를 딥하게 커스터마이징해서 사용해야 한다.

Aggregator

• item 서버, bill 서버 등이 나뉘어져 있으면, 무슨 음식을 시켰는지 알아내기 위해 온갖 서버에 물어봐야 한다. 이 역할을 해주는 애가 Aggregator이다.