대규모 스트림 처리

큐를 사용해서 대규모 스트림 처리

 

1. 큐를 사용할 때

2. 큐를 사용하지 않을 때

구분해야!!!

 

동시 접속자와 tps(초당 처리되는 트랜잭션의 수)가 중요!

 

데이터 제공 및 저장에서 가장 많은 시간을 소비하는 부분은 대부분 DB임!!! ->  DB IO !!!! 중요

db에 index를 걸어놓으면 조회가 빠름...

그러나 너무 많이 걸어 놓으면, create하는데 시간이 오래 걸림 

 

읽기 요청 최적화

 

캐시 사용

 

데이터를 가져오는 법

1. db에서 필터된 데이터 가져오기

2. 레디스에서 필터된 데이터 가져오기

3. 애플리케이션 로직에서 필터링 수행

 

.... 엣지 단에서 캐싱을 처리할 수도 있음. 이렇게 되면 애플리케이션에 오기도 전에 게이트웨이에서 처리할 수 있음

 

레디스 캐시를 사용할 때 주의해야 할 점!!!!

사용자가 애플리케이션을 통해서 데이터를 요청하는 상황

redis에 먼저 갔다가 없으면 db에 요청하는 flow...

 

근데 redis의 connection timeout이 계속 발생했음 -> 중요!!! connect가 되면 특정 시간이 지나면 연결이 끊어지도록 설정을 해주어야!!!

 

암튼 ㄱㄱ

그래서 connection을(데이터를) 요청?했는데 응답을 무한정 기다려야 하는 상황이 발생

 

이유가 뭐였냐면 redis의 용량 초과!!

스프링에서는 응답 객체를 애노테이션으로 캐싱 처리를 할 수가 있어서

불필요한 데이터까지 객체에 포함되어 캐싱처리 될 수 있음. 거기다 페이징 데이터...

그래서 redis의 용량 50gb가 다 찬 것임... 

redis가 정지되어 시스템 따운!

 

그래서 모니터링이 중요하다!!!!!! -> 예를 들어 30gb가 됐을 떄 알람.. 등

그러면 50gb를 100gb로 바꾸거나, 반환되는 객체를 필요한 것만 반환하도록 바꾸거나... 

 

자자 정리

1. redis connection time out이 발생했을 떄 -> 수 많은 사용자들의 요청을 db에서 처리? -> ㄴㄴ좋지 않은 방법임. 성능 저하 등으로 db가 다운될 수 있음

 

  - 아예 빈 데이터를 반환해서 (이 떄 프론트에서 빈 데이터가 오면 String 값이 나가니까) 사용자들이 에러 상황임을 인지 못 하도록

  - 프론트 개발자와 미리 얘기해서 빈 데이터가 반환되는 경우에는 더미 데이터가 나오도록 설정..!

  - 그냥 애플리케이션 로직에서 함수에서 미리 데이터를 뽑아 놨다가 요청에 맞게 데이터를 주는 형식...? ㅇㅇ 대충 뭔말알인데 코드로 확인하면 좋을 듯...!

 

 

 

데이터 베이스 사용 최적화

데이터베이스 인덱싱

데이터베이스 샤딩

읽기 전용 데이터베이스 -> 여기서 데이터 동기화를 할 때 간극이 있을 수 있음(데이터를 업데이트 했는데, 사용자에게는 업데이트 되지 않는 상황 발생 가능)

-> 그럴 때 redis 사용.. redis의 기존 데이터를 purge 시키는 것이 아니라 업데이트를 시키는 것이 좋음. 

쿼리 최적화

 

 

쓰기 요청 최적화

비동기 처리

배치 처리

분산 처리 -> 샤딩을 쓰는 게 무조건 좋은 건 아님. 어쩔 떄는 안 좋은 성능을 낼 수 있음

따라서 설계를 잘해야 하고, 우리 시스템이 샤딩을 쓰기에 최적화 됐는지 잘 파악해야...!