참고자료
토스는 Gateway이렇게 씁니다
Gateway 패턴 변천사
#1 Monolitic Gateway방식
다른 로직에서 같은 게이트웨이 사용
웹에서 필요한 로직과 앱에서 필요한 로직이 다르지만, 게이트웨이는 모두 가지고 있어야 포워딩이 된다.
이를 해결하기 위해, Backend For Frontend 패턴이 나옴
#2 BFF 패턴 (Backend For Frontend)
관심사의 분리
web용 App용 게이트웨이를 분리.
#3 Ingress/Egress 패턴
요청방향에 맞게 분리하는 패턴.
클러스터에 들어오는 요청 처리 : Ingress Gateway
클러스터에서 나가는 요청 처리 : Egress Gateway
위 패턴들을 활용한 토스의 아키텍쳐
서비스 개발자는 Client목적에 맞는 GW를 사용하여 라우트를 추가해주고, 해당 라우트에 필요한 로직을 넣어 서비스 로의 요청을 완성한다.
mTLS : (보안)인증서 관련 요청
망분리 : 사내
SSR : 서버 사이드 렌더링 관련 요청
Egress GW 로 외부 요청 보냄
[위 아키텍쳐 구현에 토스에서 사용한 스택]
Spring cloud Gateway (Springwebflux, Reactor-Netty ) 사용
Filter 개발에 Kotlin Coroutine사용
Istio의 Ingress/Egress, Envoy필터 사용
Gateway 에서 사용되는 공통 로직의 종류
Request 처리
유저
보안
서비스 안정화
1. Request 처리
게이트웨이에서 처음으로 해줘야하는 일은 데이터 Sanitize이다.
Sanitize란? :클라이언트로부터 올바르지 않은 요청이 올 경우, 이를 지워주거나 올바른 값으로 바꿔주는 것.
(ex. 악의적인 요청이 와도 GW에서 이를 올바른 값으로 변경후 서비스로 넘긴다.)
#1 Trace ID 생성
GW는 서비스의 진입점이라서, MSA내 트랜잭션을 구분할수있는 trace ID을 부여함.
이렇게 생성된 Trace id는 각자의 서비스에서 MDC 컨텍스트에 저장되고,
로그를 남길때 이를 같이 남긴다.
그림같이 트랜잭션별 로그 구분가능
#2 하나의 트랜잭션안에 여러 서비스에서 공통으로 필요한 정보가 있는 경우
[기존방식]
모든 서비스가 공통 API 요청
[GW사용후]
GW단에서 internal Header에 필요공통정보를 넣어서 전파한다.
유저 정보
[기존방식]
유저 정보가 필요할때마다 유저정보조회API사용
[개선 후]
<넷플릭스의 Passport 구조 참고함>
유저 인증시, Passport라는 ID 토큰을 트랜잭션내로 전파함.
passport란? 사용자 기기 정보와 유저 정보를 담은 하나의 토큰이다.
-
인증 과정이 GW에 붙어있음
-
passport 토큰을 응답하면, 이를 Serialize해서 서비스에 전파한다.
보안
1. 다양한 인증방식 사용
종단간 암호화를 통해 패킷 분석의 허들을 높여 안전하게 통신한다.
암호화가 애매한 SSR요청을 위해서 JWT인증방식도 사용한다.
위 두 그림은 OAuth / JWT방식또한 인증할때 사용한다는 말.. 특별히 다른 점은 없다
2. 위변조 여부 검증
각 요청이 실제로 위변조 되지않은 토스앱에서 만들어진 요청인지도 검증한다.
요청당 아주짧은유효기간을 가진 키값 + 토스앱에서만 알수있는 정보
를 가지고 요청을 서명하고 이를 GW에 보낸다.
토큰 위변조 감지시, FDS(Fraud Detection System)를 통해 계정을 비활성화하여 사용자 보호함
FDS에 대한 추후 연구 필요
FDS는 유저 행위 분석 기반으로 다양한 룰베이스로 수상한 행동 감지한다.
감지하는 경우 GW로 정보보내, IPS로 차단. → 특정 유저 , 특정 디바이스가 특정 API를 이용하지 못하게 함
3. 인증서 mTLS 인증
Istio 에서 제공하는 mTLS flow위에 레이어를 하나 얹어 사용함
그냥 써도 되지만 코드베이스인 경우에 Auditing, 카나리배포방식사용 등에서 이점이 있다함.
4. OIDC
5. 서킷브레이킹
