비동기 프로그래밍
- 논블로킹의 서버 구성일 경우, 모든 모듈 중 가장 느린 모듈의 시간만큼만 소요됨
- e.g. 홈페이지에서 각각의 모듈로 분리하고, 광고 모듈 로그인 모듈 서로 순차적으로 호출하는 것이 아닌, 각각의 모듈을 비동기적으로 호출하면 순차적으로 호출하는 것보다 빠른 호출이 가능하다.
- 스프링의 경우 @Async 어노테이션을 통해 비동기 프로그래밍이 가능하다
- 참고 블로그를 통해 SimpleAsyncTaskExecutor와 ThreadPoolTaskExecutor과 같은 커스텀된 TaskExecutor로 관리할 수 있다는 것을 알았다.
- 다만 비동기로 처리되는 메서드에서 Exception 발생 시, 스레드만 죽기 때문에 Exception이 발생한지 확인하기 어렵다는 단점이 존재한다.
- 이를 위해, 핸들러를 작성하는 모습도 위 참고블로그에서 확인할 수 있다.
- 비동기 시에 실패했을 경우, 어디까지 돌아가서 다시 시도할 것인가를 정해야 함
- e.g. 회원가입 시, 핸드폰 인증 / 이메일 인증 / 설문조사 등의 과정에서 이메일 인증이 실패했으면 핸드폰 인증은 통과시키고, 이메일 인증부터 Retry하는 등
-
비동기 시에 이벤트 로깅이 중요하다. 디버깅이 어려움
-
가장 단순한 패턴이 싱글 프로듀서 - 싱글 컨슈머
-
가장 많이 쓰는 패턴이 싱글 프로듀서 - 멀티 컨슈머
-
컨슈머가 복잡한 로직을 사용해야 하는 경우가 많다.
-
여기서 조금 더 진화한 것이 데드레터큐, 타임투라이브 방식이다.
-
폴링 방식은 지속적으로 클라이언트에서 서버에 물어보는 방식
- 너무 많은 요청으로 서버에 부하가 가해짐
- 최근에는 잘 사용하지 않는 방식
-
이벤트 스플릿팅
- 이벤트 발생 시, 메인 로직 외의 로깅, 통계 등 처리가 필요할 시 메인로직에서 모두 다 처리하기에는 단일책임에서 벗어나게 된다.
- 때문에, 각각 서버에게 이벤트를 나눠서 전달해주는 방식
- 복잡도는 올라가지만, 성능상의 이점이 있을 경우 사용
-
EDA (Event Driven Architecture)
- 각자의 역할이 존재하기 때문에, 필연적으로 서로의 서비스들을 호출
- 서로의 역할과 책임을 나눠둔 것이 MSA이다.
- 이러한 MSA에서 서로간 호출이 너무 많아졌기 때문에 단점을 극복하기 위해 EDA 출현
- 메세지 큐 방식을 사용해 하나로 몰아두기 때문에 네트워크 부하를 줄인다.
- 중간에 모여진 이벤트 버스에서 이벤트를 빼가는 방식이기 때문에 Polyglot에 유리
- 요청이 많아질수록 성능 향상이 기대됨
- 하나가 죽는다고 다른것이 연쇄적으로 터지진 않는데 이벤트 버스(메세지 브로커)가 죽으면 큰일
- 로깅을 잘 처리 안해두면, 원인을 모를 경우가 존재한다.
-
EDP (Event Driven Programming)
- EDP는 개념일 뿐이다
- 이를 구현한 도구가 Webflux와 같은 것들이다
- 컨슈머와 프로듀서는 서로에게 의존하지 않기 때문에, 비동기적(동시) 처리가 가능하다.
- 실패했을 때는 실패한 쪽에서만 Retry 하면 된다
- 컨슈머에 부하가 걸릴 경우, 스케일 아웃이 쉽게 가능하다.
결론 : 프로듀서는 퍼블리시를 해서 이벤트를 메세지큐에 집어넣고, 컨슈머는 이를 구독해서 이벤트를 소비
2022.04.11 Daily 회고 (혹은 TIL, TIW 등등)
오늘 한 일
- Orientation 진행
- Asynchronous & Synchronous
- EDA (Event Driven Architecture)
- EDA 설계 시 고려사항 / 패턴 등 학습
느낀 점
- 동기와 비동기에 대해서 다시 정리할 수 있었고, 효율적인 EDA 구조에 대해 학습할 수 있었다.
- 이벤트를 처리하기로 약속한 컨슈머 프로듀서 개념에 대해 공감이 갔다.
- EDA에 대해 조금 더 알고싶고, 실제로 카프카와 같은 툴을 사용해보고 싶다.
현재 나의 상태
- 설계에 대해 공부해보고 잘해보고 싶은 생각이 있었는데, 코스에서 배운 내용으로 어느정도 채워질 거라는 생각이 들었다.
