TPS는 초당 처리되는 트랜잭션의 수를 나타내는 지표이다. 로그를 모니터링 할 수 있어야 한다. → 로그를 한번에 시각화 할 수 있 모니터링 가능한 도구 찾아보기!
모니터를 통해 이 시스템의 요청이 어느 정도로 일어나고 어떤 시간에 피크인지 확인하고 그 피크가 어느정도인지 알 수 있습니다. 시간별로 데이터를 나누면 그래프가 생성할 수 있습니다.(몇분 간격)
DB IO 시간이 많이 소요됨. 그러므로 캐시를 사용하는데 캐시 정책도 필요하다.
Ex) DB의 데이터 변경이 있으면 캐시도 purge 또는 update를 해줘야한다.
redis 캐시를 사용할 때, 어떤걸 주의해야 할까?
redis가 connection time out으로 시스템이 다운되었는 그 원인을 모를 경우, time out 시간을 설정해주는게 좋다.
c out 생기면 5초 지나면 연결을 끊을 수 있는 시간을 설정해야 한다.
TPS와 많은 사용자가 몰릴 때, redis에 요청하는데 connection time out 시간 설정을 안하면 무한정 대기하는 pending이 되어 응답이 안오는 상황이 발생한다.
튜터의 한 사례) redis 50GB 용량인데 캐시된 데이터가 불필요한 데이터도 포함한 paging된 데이터로 많은 동시접속 사람들로 인해 용량을 넘겨버리고 connection time out 발생하였다.
해결책으로, 모니터링을 통해 30GB 넘으면 사용자에게 alert을 보내는 작업을 했으면 조치를 취할 수 있었다. 다른 방법으론, 필요한 데이터만 적재해서 캐싱하는 방법(객체에 필요없는 데이터를 삭제하여 경량)이 있다. redis 용량을 50 → 100GB 용량을 늘려서 데이터가 꽉 차는 문제를 해결했을 것이다.
해결 방법
redis connection time out를 3-4s 설정 후, front에서 data를 전달하지 않는다.
front에서 에러상황이 생겨서 응답이 안오면 dummy data를 만들어 응답해 사용자가 문제(오류 발생)인지 모르게 하기.
사용자가 가져갈 list에서 필요한 데이터만 뽑아가는 상황이었는데, list 데이터를 함수에 내려주고 함수 안에서(application 함수 레벨에서) 데이터 추출이 동작하도록 한다. 생각보다 application 함수 동작 속도가 빠르다.
로그에서 접속량 체크 방법 구글 애널리틱스(google analytics)를 통해서 수집기를 front에 설치 및 그 데이터를 통해 얼마나 접속했는지 확인함. GA를 통해서 front에 script를 삽입하고, 그 스크립트를 사용해서 googl analytics로 데이터를 보내준다. 그 데이터를 수집해서 접속량이 얼마만큼 확인한다. 그러나 정확한 수치는 아니다. 그래서 로그만 남기면 api 요청량을 알 수 있기 때문에 로깅하는 습관이 중요하다.(dashboard에서 수치화 하는게 편하다)
