본문 바로가기

전체 글142

레디스 캐시 전략 1. Cache Aside조회시 캐시 조회실패시 DB에 조회 후 캐시에 데이터를 저장 2. Read Through조회시 캐시 조회, 캐시어사이드와 비슷하지만 DB를 조회하는 주체가 다르다.캐시 어사이드는 앱이 DB를 조회하지만 리드 스로우는 캐시가 DB를 조회하여 캐시가 커넥션을 가지고 있어야한다.캐시가 장애나면 DB에 접근이 불가능하다 거의 쓰이지 않음이때 캐시는 DB의 프록시역할 3. Write Back저장시 캐시에 먼저 저장하고 캐시에 있는 데이터를 배치로 DB에 저장캐시 오류 발생시 데이터 영구 소실 4. Write Through저장시 캐시에 저장하고 DB에 즉시저장.항상 동기화 되어있다. 두번의 쓰기가 일어나 빈번한 수정이 발생하면 성능 이슈 발생가능 5. Write Around저장할 때 캐시에.. 2025. 8. 9.
레디스 기본 명령어 Set키, 값 을 저장한다127.0.0.1:6379> set jaeik:1 "jaeik good"OK127.0.0.1:6379> set jaeik:2 jaeikOK띄워쓰기가 필요하면 쌍따옴표로 막아야함 get키로 값을 반환한다127.0.0.1:6379> get jaeik:1"jaeik good"127.0.0.1:6379> get jaeik:2"jaeik" keys모든 키를 반환한다 여기선 잘못쳐서 jaeik이 아니라 jeaik도 하나 끼어들어감 ㅠ127.0.0.1:6379> keys *1) "jeaik:2"2) "jaeik:1"3) "jaeik:2"127.0.0.1:6379> del키로 키와값을 삭제한다127.0.0.1:6379> del jaeik:2(integer) 1127.0.0.1:6379> key.. 2025. 8. 9.
서버 비상시 AI 분석 실시간 메시지 전송 시스템 구현 기존에는 Scouter APM을 통해 서버를 모니터링했지만, 24시간 상시 모니터링은 현실적으로 어려웠습니다. 예외가 터졌을 때, 이를 몇 시간 후에나 인지한 경험이 있습니다. 이러한 문제에 직면하며 단순한 서버 상태 알림을 넘어, 문제의 원인과 심각성을 즉시 파악하고 대응할 수 있는 지능형 모니터링 시스템의 필요성을 느꼈습니다. 이에 저는 GPT 기반의 서버 모니터링 AI를 개발하여 모니터링 부담을 줄이고, 신속하고 정확한 문제 해결을 돕고자 했습니다. 처음에는 서버 내부 API로 GPT를 호출하려 했으나 서버가 죽으면 응답을 할 수 없고 설령 서버가 죽지 않더라도 트래픽에 요청이 느려질 가능성이 있었습니다. 서버 진단 기능이 서버 내부에 있는 것은 잘못된 설계라고 판단하여 이 문제를 해결하기 위해.. 2025. 8. 7.
아키텍처 관점에서 Repository 계층의 접근 범위에 대한 고민 (2025년 6월 15일) 2025년 6월 15일의 고민 노션에서 옮겨오고 있습니다. 고민 최근 데이터엑세스 코드를 수정하면서 레포지토리 계층에서 DTO나 인터페이스에 접근하는 것이 아키텍처에 어긋나는지 고민에 빠졌다. 일반적으론 Repository에서 바로 비즈니스 로직을 거치지않고 바로 DTO에 접근하는 것은 맞지 않다고 느껴진다. 하지만 그건 JPA의 관점이 아닌가? 마이바티스는 일반적으로 바로 DTO에 접근하는데? JPA의 더티체킹에 익숙해져서 서비스 -> 엔티티 -> 레포지토리 구조에 빠져버린건가? 특히 QueryDSL의 프로젝션 기능을 사용하면 복잡한 조회 쿼리도 깔끔하게 DTO로 매핑할 수 있는데, 이런 경우에도 아키텍처 원칙 때문에 포기해야 하나 하는 고민이 들었다. 같은 애플리케이션에서 기술에 따라 다른 패턴을 사.. 2025. 8. 7.
알림 읽음 처리에 대한 고민 (2025년 4월 29일) 2025년 4월 29일의 고민 노션에서 옮겨오고 있습니다 고민 알림을 읽을 때 마다 DB에서 update 쿼리를 요청하면 불 필요한 부하가 생긴다.불 필요한 부하라기엔 필요한 로직일 수도 있지만 알림을 읽는다는 역할의 중요성을 생각해 보았을 때 차후에 만약 사용자가 많아진다면 대안을 생각하는 것이 필요한 부분이라고 생각한다.당장은 사용자가 적어 문제가 되지 않지만 만약 사용자가 많아진다면? 스케일 아웃이나 스케일 업은 피할 수 없는 선택지가 되겠지만 그 선택을 하기전까진 대안과 최적화로 할 수 있는만큼은 기존 서버만으로 트래픽을 받고 싶다. 해결알림 읽음과 삭제 상태를 프론트의 로컬 스토리지에서 관리하고 5분마다 서버로 전송하여 DB에 반영하는 방식을 선택했다.그리고 사용자가 5분도 이용하지 않고 떠났을.. 2025. 8. 7.
게시판 유저 상호작용 부하 테스트 및 성능 개선 2025년 6월의 내용을 노션에서 가져왔습니다.내용의 정리가 필요합니다.. 어느정도 리팩토링 되었습니다. 목차 1. 서론 1.1 테스트 목적 1.2 결과 요약2. 부하 테스트 2.1 테스트 환경 및 시나리오 2.2 테스트 결과 요약3. 지표 분석 3.1 로드밸런서 3.2 CPU 분석 3.3 스왑 메모리 분석 3.4 네트워크 대역폭 분석 3.5 병목 API 식별 3.6 쿼리 호출 수 분석 3.7 API 요청당 자원 소모 분석 3.8 병목 API 상세 프로파일링 3.9 힙 메모리 분석 3.10 커넥션 분석4. 문제점 개선 4.1 문제점 요약 4.2 우선순위 상: N+1 해결 4.3 우선순위 상: 페이징 미 설정.. 2025. 8. 7.

티스토리툴바