-
[리팩토링 보고서] 서버과부하 방지를 위한 Batch 처리Back End/리팩토링 보고서 2022. 3. 5. 00:26이 포스팅은 리팩토링 될 때마다 업데이트 됩니다.
북마크 추가/변경/삭제와 같은 많은
가벼운 I/O
의 발생을 효율적으로 처리하고 싶었다.당시에는 Spring Batch 도 ServerSide Global Caching 전략도 몰랐었다.
(그저 서버에서 많은 데이터를 들고 있으면 OOM이 일어나겠지라고 생각했었다.)
그래서 생각해낸게
브라우저(React)단에서 5분간 이벤트 발생을 기록해두었다가 한번에 서버에 요청
하는 방식이었다.회고록에서도 언급했었지만, 너무 비효율적인 방식이었다. (그리고 책임회피였다..)
일단 하나의 브라우저에서 발생된 이벤트밖에 처리를 못해
모아둔 이벤트의 양이 적을 뿐더러, 여러 유저에 대한 Batch 처리를 못한다는 단점이 있었고두번째로 브라우저에게 책임을 돌렸기 때문에 브라우저가 무거워질 것이고
프론트개발자분이 할일이 늘었다는 것이다.
(만약에 누군가가 악의적으로 매크로로 5분안에 1억개의 Request를 발생시킨다면 브라우저 메모리가 터져버릴 것이다. 이를 방지하기 위해 사용자의 디스크공간에 캐싱해둔다고 해도 너무 불필요한 작업이라 생각한다.)
서버사이드 캐싱에서도 똑같이 적용되기 때문에, 이런
악의적인 공격
에 대한 방어를 꼭 해야겠다고 생각한다.
PocketMark v1.0 (현재)
Summary. 매우 비효과적 x 100
PocketMark v2.0 (예정)
PocketMark v1.0 보다 훨씬 효과적일거라 기대된다.
* 악의적인 공격에 대한 방어책도 꼭 구현하자.
728x90'Back End > 리팩토링 보고서' 카테고리의 다른 글
[리팩토링 보고서] JPA 쿼리 성능 최적화 (0) 2022.03.05 [리팩토링 보고서] 일급 컬렉션의 적용 (0) 2022.03.04 [리팩토링 보고서] API와 Repository 의존성 제거하기 (DTO-Repository 의존성 제거) (0) 2022.03.04 [리팩토링 보고서] 레이어간 의존성 개선 (0) 2022.03.04 [개발노트] PocketMark 개발노트 (0) 2022.03.03