[면접 대비 질문 정리]
대용량 트래픽을 처리하는 방법
1. Scale-out
서버의 물리적 확장을 한다. 이때 고려해야할 것은 업무의 배분 서버의 양이 늘었으니 서버마다 일을 할당해줘야 한다. 이를 해결하는 방법은 로드 밸런싱이다. 로드밸런싱은 남은 큐의 크기, 이미 축적된 요청들의 예상 시간을 고려해 최적의 서버로 요청들을 분배하는 것.
2. Scale-up
서버의 성능을 늘리는 것. CPU, 메모리, 기억장치 이 중 무엇이 데이터 처 속도를 규정할까? 답은 바로 기억장치.
결국 기억장치의 IO 속도가 결정짓게 된다. 기억장치의 성능을 업그레이드 하기ㅏ 위한 방법으로는 IN-MEMORY DATABASE를 사용한다. Redis
와 같은. 이를 이용해 데이터를 캐싱해 반복되는 작업을 저장한다.
ORM을 사용하면서 쿼리가 복잡해지는 경우에 어떻게 대처하는지?
1. 필요에 따라 Native Query를 작성해야할 때가 있음.
2. query 빌더를 이용해 복잡한 쿼리를 생성
3. Stored Procedure 사용
오늘은 레디스를 이용해 캐싱을 처리했다. 우선 레디스를 윈도우버전으로 설치를 했다. 그리고 redis cli를 실행시켜줬더니? 한번에 될리가 없지 ㅋㅋ 바로? 오류. 한시간정도 오류를 잡다가 에라모르겠다 재부팅 했더니 됐다 .... ㅋㅋㅋㅋㅋㅋㅋ
이놈의 노트북은 당최 한번에 되는게 없다... 아무튼 레디스 환경을 구축하고 이제 캐싱을 처리해보자! 스프링의 @Cachable 어노테이션이 있지만 이거는 내가 잘 사용하지 못했다. 그래서 그냥 CacheAlbum 엔티티를 따로 만들고, CURDReposoitory를 구현한 기본 Repository를 만들어서 Redis에 저장하는 방식을 사용했다. 그렇게 열심히 씨름을 했다. 처음 고민했던 것은 쿼리가 대문자인지, 소문자인지, 한글인지에 따라 key값이 달라진다. 따라서 value가 중복되는 현상이 일어났다. 이걸 어떻게 처리해야할까? 생각을 하다가 그냥 value가 중복되더라도, key값을 여러개 사용하는 걸로 하기로 했다. redis 환경에서는 key값으로 value를 찾을 때 contains를 사용하지 못해서 못했던 것. 그렇게 시름을 했는데 생각보다 캐싱이 잘 안먹었다. 이걸 경남님과 공유를 했더니 경남님이 간단히 풀어주셨다. 바로 String의 artist를 key값으로 하고 value값으로 AlbumRes를 List로 넣었다. CacheAlbum에는 이 두가지 필드만 존재했고, key값으로 artist, value값으로 List<AlbumRes>를 받앗다. 이렇게 하니 레디스로 캐싱 성공!
오늘 정말 아침부터 정신없이 했는데 내가 결국 구현에 실패하고, 경남님이 해주셔서 고마웠지만 조금 미안한 마음이 들었다. 그래서 캐싱도 성공했으니 이제 진짜 마지막 SpotifyAPI로 넘어가자! 였다. 결과는 성공 이제 Spotify의 Rawdata는 받을 수 있고, 이를 이용해 album들을 가져와보자. maniadb보다 속도도 월등하고, 쿼리 결과도 훨씬 좋다.
우선 오늘의 캐싱 성공한것을 보자.
응답이 무려 3.6초가 걸린다.
무려 36밀리 세컨즈 한 100배는 빨라진게 아닌가? 캐싱을 하니 속도도 월등히 빨라졌고, 더이상 외부 api를 사용하지 않아도 된다!
요즘 프로젝트에 로그를 찍고 있는데 이걸로 확인을 하는게 참 편하고 좋다.
