Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
Tags
- redis
- cache
- Spring
- DI
- 열 속성
- equals
- 생성자 주입
- 조합
- docker
- jpa
- 필드 주입
- 테스트 코드
- stream
- DDL
- hashcode
- select_type
- static
- jwt
- 인덱스
- AOP
- 바이너리 카운팅
- lambda
- Test
- KEVISS
- java
- StringBuilder
- MSA
- SQL
- VUE
- 재정의
Archives
- Today
- Total
백엔드 개발자 블로그
Gateway 본문
[참고](https://toss.tech/article/slash23-server)
토스에서는 Gateway를 어떻게 사용하고 있는지 살펴보자
Gateway란?
- 등장배경 : 공통 로직을 모든 서버에 적용하고 배포하는 것은 큰일임 그래서 개발됨
- ex) 유저 정보, 보안 정책, 모니터링,
- 역할
- 라우팅
- 필터 작동
- 공통 로직 처리
- 개발 방법
- Spring Cloud Gateway를 사용하여 구성하고 개발
- 결과
- 외부에 노출되는 엔드포인트에 대해 중앙 집중식으로 관리할 수 있도록 도와줌
- 트래픽 모니터링, 속도 제한, 요청 및 응답을 요구사항에 맞게 수정
- MSA를 보다 쉽게 확장, 모니터링 할 수 있도록 함
공통 로직처리
Request 전처리, 후처리
Sanitize : Client로부터 올바르지 않은 요청이 올 경우 지우거나 바꿔줌
유저 Passport
토큰에 디바이스 정보, 유저 정보 담아서 유저 API 중복 호출 방지
보안과 안정성
종단간 암호화
- 과정
- 앱에서 암호화 키로 요청 바디를 암호화 -> Gateway에서 복호화해서 서비스에 전달
- 결과
- 복호화 과정에서 인증/인가 로직이 처리되고, 복호화 된 데이터와 유저 정보를 서비스로 넘겨주게 되므로 서비스에서는 편하고 안전하게 사용자의 요청을 처리할 수 있게 됨
Dynamic Security
요청 위변조 확인
- 서명 값 -> 토스 앱 요청?, 중복?, 유효기간? -> 위변조 방지 -> 발견되면 FDS를 통해 계정 비활성화
인증서를 이용한 인증/인가
- 사용
- 외부 회사나 내부 개발자의 서비스 호울을 위해 클라이언트 인증서를 이용한 mTLS API 호출도 지원
- Gateway 인증/인가를 사용하는 이유
- Isito만 이용하여 인증/인가 처리도 가능하지만, Isito의 matching rule보다 자유도도 높고, Auditing 등의 로직을 처리할 수 있으며, 카나리배포의 이점을 누릴 수 있어서 사용
- 과정
- Edge에서 Isito는 Client 인증서의 CA 유효성 확인
- 해당 인증서를 헤더에 실어서 모든 트래픽을 Gateway에 전달
- 받은 인증서를 복호화하여 X.509 extensions 중 Subject Alternative Name을 화용하여 인증서로부터 사용자 정보 얻음
- 사용자 정보와 도착지 호스트 및 요청 경로르 활용하여 각 요청에 대한 인증/인가 및 Auditing 처리
Circuit breaker
- 등장 배경
- 서비스에서 응답 지연이 발생 -> 의존하는 수많은 서비스들에게 응답 지연이 전파됨 -> 시스템 자원 점유 -> 모든 시스템 먹통
- 결과
- 응답 지연을 유발하는 서비스에게 요청을 더 이상 보내지 않고 빠르게 실패하게 하여 부하를 겪고 있는 서비스 회복 도움, 응답지연 확산 막음
- Gateway Circuit breaker 사용하는 이유
- Isito를 활용하면 호스트 단위로 쉽게 빠르게 전체 적용이 가능하면 애플리케이션의 개발 주기와 독립적으로 관리될 수 있지만, 호스트 단위로만 설정이 가능하며, 룰에도 한계가 있음
- 그래서 Gateway 서킷 브레이킹을 적용하여 호스트나 Route 단위 혹은 기능단위로 정교하게 서킷 브레이킹 걸고 있음
모니터링
로깅
오든 요청, 응답의 Route id와 method, URI, 상태 코드등을 Elasticsearch에 남기고 있음
메트릭
- 실사용
- Prometheus로 시스템 메트릭과 애플리케이션 메트릭를 수집
- Node Exporter를 통해 시스템 메트릭 수집
- Spring Actuator를 통해 애플리케이션 메트릭
- Grafana를 통해 시각화하고 슬랙으로 알림을 보냄
- Prometheus로 시스템 메트릭과 애플리케이션 메트릭를 수집
- 종류
- 시스템 메트릭
- CPU, memory, 네트워크 RX, TX 트래픽 -> 애플리케이션 수정 사항이 시스템에 주는 영향을 1차로 파악가능, 문제가 생기는 경우 원인 파악에 활용
- 애플리케이션 메트릭
- JVM thread block 상황이나 세대별 메모리 할당을 파악하고 full GC 발생 여부 확인
- Gateway 메트릭
- API Path별 Route 메트릭을 확인
- 시스템 메트릭
'테크 블로그 리뷰' 카테고리의 다른 글
대용량 트래픽 처리 전략 (0) | 2024.02.07 |
---|---|
MSA로 전환2 (0) | 2024.02.07 |
헬스 체크 (0) | 2024.01.07 |
대규모 로그 처리 by Elasticsearch 클러스터 (1) | 2024.01.07 |
MSA로 전환1 (1) | 2024.01.07 |