이런 상황을 상상해볼까요?
갑자기 슬랙 알림이 미친듯이 오더니, 서버가 터져서 다운 직전이고,
내 API 응답시간은 10초를 넘어간다고 생각해보자. 그리고 모든 사람이 담당자인 나를 찾는다.
그렇다면 개발자인 당신은
무슨 일 부터 시작할 것인가요?
[들어가기 전]
다음 용어가 무엇인지 알고, 설명할 수 있나요?
- APM
- 필터와 인터셉터
- 캐쉬(글로벌 캐쉬, 로컬 캐쉬)와 캐쉬 전략
1. APM
저는 서버가 터진다면, *APM 을 먼저 확인할 거에요!
Application Performance Monitoring 이란?
-
성능 추적
애플리케이션의 응답 시간, 처리 속도, 트랜잭션 처리 현황 등을 실시간으로 모니터링하여 성능 저하 지점 추적 및 발견합니다. -
오류 추적
애플리케이션 내에서 발생하는 오류나 예외를 자동으로 추적하고, 이를 상세하게 기록합니다 -
트랜잭션 모니터링
사용자 요청이나 트랜잭션의 흐름을 추적하여 병목 현상이나 지연 요소를 파악합니다. -
리소스 활용도 분석
CPU, 메모리, 디스크 I/O 등 시스템 리소스의 사용량을 모니터링하여 리소스 부족이나 비효율적인 사용을 감지합니다.
다음으로, 어떤 요청이 들어오고 어떤 응답을 주고 있는지 확인할 것입니다.
근데.. 그 전에 그런 기록을 하고 있나요? 한다면, 어떤 방식으로 하실 건가요?
저라면, 비지니스 로직에 분리되어 공통적으로 처리할 수 있는 기술을 사용할 거에요!
즉, 필터를 사용할 거에요!
2. 필터와 인터셉터
저는 필터와 @Slf4j 이용하여 요청과 응답 파라미터를 로깅했습니다.
이때, 파라미터값을 로깅하기 위해서ContentCachingRequestWrapper를 사용했고, 왜 사용해야 하는지에 대해 학습했어요!
그런데, 필터와 인터셉터를 언제 써야할까요? 또, 무슨 차이가 있을까요?
자세한 내용은 필터와 인터셉터에 정리해뒀습니다!
3. 캐쉬
확인해보니, 너무나 자주 콘서트 정보 요청이 오고 있었군요!
그렇다면, 자주 쓰이는 요청은 캐싱을 이용해 DB에 요청하지 않고도 반환할 수 있습니다.
콘서트 관련 조회의 데이터가 크지 않지만, 요청이 너무 많기 때문에 Redis 이용하여 캐싱을 했습니다.
Redis와 같이 글로벌 캐싱을 택하는 이유는, 여러 서버 인스턴스가 각각의 콘서트 상태를 다르게 저장하는 정합성 문제를 최소화하기 위해서입니다.
또한, 콘서트는 많은 조회가 있기에 캐시를 먼저 확인 후 없다면 DB에 조회했습니다.
(Look Aside)
그리고 캐쉬에 먼저 좌석 점유 정보를 저장하지 않는다면, 무수히 많은 좌석 점유 요청이 DB에 도달하므로, 캐쉬에 먼저 좌석 점유 정보를 저장하는 전략을 택했습니다.
(Write Through, 단 구현 편의를 위해 동기화는 서버가 하는 방식으로 진행)
캐싱 전략은 1. Look Aside, 2. Read Through, 3. Write Behind, 4. Write Around가 있습니다.
1. Look Aside
- 캐쉬를 먼저 조회합니다. (있다면 반환).
- 캐쉬 미스시에 서버는 DB와 같은 원본 저장소(Data Store)에 조회한 뒤
- 서버는 해당 값을 캐쉬에 업데이트 합니다.
장점
- 많은 읽기에 적합
- Cache 서버 장애가 나도 괜찮음
- 반복적, 동일 쿼리를 수행하는 서비스에 적합
단점
- 캐쉬와 원본 저장소간 정합성 불일치 문제
- 캐시에 데이터가 없다면, 추가적인 시간 소모
초기 DB 데이터를 캐쉬에 넣어놓으면 성능 향상을 기대할 수 있다.
이를 Cache Warming이라 한다.
2. Read Through
- 캐쉬를 먼저 조회합니다. (있다면 반환)
- 캐쉬 미스시에 서버는 DB와 같은 원본 저장소(Data Store)에 조회
- 원본 저장소는 해당 값을 캐쉬에 업데이트 합니다.
3. Write Through
- 데이터 저장시 캐쉬에 먼저 저장
- 캐쉬는 해당 데이터를 원본 저장소에 저장
- 서버는 캐쉬에 조회
장점
- 캐쉬와 원본 저장소간 정합성 불일치 문제 해소
단점
- 저장시 2단계를 거치기에 느림
- 캐쉬에 저장된 데이터를 다시 조회하지 않는다면 리소스 낭비 (TTL로 해결)
4. Write Around
- 쓰기 요청은 DB에만 저장한다.
- 읽기 요청은 캐쉬에만 조회한다.
장점
- 매우 빠르다
단점
- 정합성 문제
참고
항해에 참가하려는 당신!
혹시 [들어가기전]의 답변이 궁금하신가요!?
글을 읽다보니 '아..! 나도 저거 알아야하는데!' 하진 않으신가요?!
여기까지 글을 읽으셨다면, 아마 항해 플러스 과정에 관심있으신 분이라고 생각합니다.
궁금한 점이 있으시다면 저에게 편하게 댓글 남겨주세요!
혹은 highestbright98@naver.com으로 메일을 남겨주셔도 굉장히 빨리 답변한답니다!
항해 플러스 백엔드에 관련해서 궁금하신점이 있다면 언제든 편하게 말씀주세요!
그리고 글이 도움됐다면, 등록하실때 제 추천인 코드 [9MPLfu] 입력하면,
20만원 할인의 혜택이 있답니다! (물론 저에게도 혜택이 있습니다! 😉)
