- 서버가 모든 디자인 로직을 정의하고 클라이언트 에게 전달
- 클라이언트는 전달받은 디자인을 출력만 함
- 서버 개발자의 부하가 높아질수 있으니 적절하게 사용
- BFF?!
- ZUUL(스택) → MSA에서의 공통적인 서비스 및 라우팅, 프로토콜 처리 담당
- 클라이언트 별 다른 게이트웨이를 구성해서 관심사 분리 및 최적화 장점
- In Gateway, Out Gateway를 별도로 구축 하면 더욱 목적에 특화된 기능 처리 가능
- 개발 스택
- 스프링 클라우드 게이트웨이 (네티)
- 코틀린 - 코루틴
- Istio → API등을 활용해 MSA간 통신을 연결해주는 인프라 계층 오픈소스
- 특정 클라이언트가 트래픽 을 유발한다면 이를 차단 해줄수 있는 룰 이 필요하다
- 특정 값이 들어오면 게이트웨이가 올바른 값으로 직렬화 해주고 추적용 아이디를 부여해 트랜젝션 처리
- 공통적으로 필요한 값도 게이트웨이에서 주입
- Passport기능을 정의해 유저 정보가 필요할 경우 트랜젝션 요청을 보내는것이 아닌 캐싱 처리하여 트랜젝션 횟수 감소 시킴
- 인증 처리는 클라이언트와 게이트웨이 사이에서 모두 처리함 → 서비스 에선 편리한 개발 가능
- Gateway관리 → 스프링 클라우드에선 YAML파일을 이용해 관리 할 수 있다
- 배포는 개발시 1분 단위로 설정을 업데이트 하고 라이브 에선 카나리 배포방식으로 접근
- APM Pinpoint로 관측 플랫폼 구현
- 동기방식은 요청이 오래 서버에 남기에 비동기 방식으로 구현
- 최적화된 비동기를 구현하기위해 코틀린의 코루틴을 주로 사용함
- Pinpoint는 코틀린 코루틴을 지원하지 않음 → 플러그인 제작 결정
- 코틀린으로 코드를 작성 → 바이트 파일로 컴파일
- 바이트 파일을 자바 코드로 디컴파일
- 변환부 확인 및 수정
- 코루틴에 Job 속성을 추가해 서로 체이닝 하고 한 코루틴이 서로 다른 코루틴을 관리 할수 있게 한다 → 코루틴 그룹1(코루틴, 코루틴, 코루틴)
-
최우선 목표: 낮은 레이턴시, 빠른 리커버리
-
아키텍처
스크린샷 2023-06-08 오후 3.41.34.png
-
수신부에서 데이터를 모두 전달하기엔 많은 부하가 발생함 이를 해결하고자 메세지 브로커를 수신부 - MQ - 처리부 방식으로 구현 이로써 수신부의 데이터는 한번만 전달 되면 됨
-
하지만 아이러니 하게도 MQ를 사용하면 지연시간이 늘어남
-
그래서 MQ의 선택이 중요한데 kafka(지연시간 15ms)가 아닌 Redis Pub/Sub(지연시간 3ms) 사용
-
하지만 처리부가 느리면 결국 데이터는 지연 될수 밖에 없음
-
처리부 에서도 수신하는 부분과 비즈니스로직은 별도의 구조로 분리 되어야 함 → 블락킹을 막기 위해서
-
그러나 쓰레드를 사용하면 순서가 바뀔수 있어 문제가 생길수 있고 이벤트 루프를 사용하면 직렬화를 해야 하기때문에 대용량 트래픽이 발생하면 문제가됨 그래서 선택한 방법은 또다시 pub/sub을 사용함 즉 연결점을 redis로 직접 연결 했기 때문에 직렬화 해줄 필요가 없어짐
-
배치, DB저장 등의 무거운 작업은 별도의 이벤트 루프를 만들어 처리
- pinpoint는 분산 처리를 추적하는 툴
- 특정 서비스가 어느 부분에서 병목인지 추적 할수 있다
- 핀포인트 - 안티 패턴 파악하기
- JFR 분석 자동화 하기 → 자바 힙 분석 관리인듯
- jemalloc으로 네이티브 메모리 사용량 추적 가능
- async-Profiler 로 CPU사용량 체크 가능
- 대표적으로 ES의 사용량 체크 및 분산 처리시의 사용량을 체크해 어느 부분이 병목인가 확인 가능