DBMS34 [Redis] 설계 예시 문제 (커뮤니티 서비스의 게시글 상세 조회 API) [상황]- 커뮤니티 서비스의 게시글 상세 조회 API가 있다- DAU 10만, 읽기 비율 95% 이상- 상위 1% 게시글에 조회가 집중된다- 주요 조회 쿼리에는 필요한 DB 인덱스는 이미 적용되어 있다- 현재 모든 조회 요청이 DB로 직접 들어간다- 피크 시간대 DB CPU가 80% 이상, p95 800ms[제약]- 게시글 내용은 최대 1분 stale 허용- 비용 증가를 최소화해야 한다- 수정/삭제는 드물지만 발생한다[질문]1. Redis 캐시를 도입할 것인가? 왜 그런가?2. 어떤 데이터를 캐시할 것인가? 전체 게시글인가, 핫 게시글만인가?3. 어떤 전략(cache-aside 등)을 쓸 것인가?4. TTL은 어떻게 잡을 것인가?5. 수정/삭제 시 캐시 무효화는 어떻게 처리할 것인가? 1번 풀이: R.. 2026. 4. 11. [Redis] 캐시 전략 정리 캐시 전략은 실무에서 성능 + 비용 + 데이터 일관성을 동시에 잡는 핵심 설계 포인트!!! 캐시 전략: 데이터를 언제 캐시에 넣고, 언제 DB에서 가져오고, 언제 갱신/삭제할지에 대한 규칙캐시 전략 3가지실무에서는 사실 이게 거의 모든 케이스이다..!특히 Cache Aside 사용 비율이 압도적으로 높다그러면 바로 Cache Aside 부터 알아보자! 1. Cache Aside (Lazy Loading) ⭐⭐ ⭐⭐⭐ 거의 대부분의 경우 [장점]필요한 데이터만 캐싱구현 간단메모리 효율 good[단점]첫 요청 느림 (Cold Start)동시 요청 시 DB 부하 가능 (Cache Stampede) 어떤 상황에서 쓸까?거의 대부분 서비스게시글 조회사용자 정보 조회상품 조회따라서 그냥 캐시 기본 전략 = Ca.. 2026. 4. 11. [Redis] 분산 락으로 배치 중복 실행 막기 https://claremont.tistory.com/entry/%EC%9B%B9-%EC%A7%80%EC%8B%9D-%EB%B6%84%EC%82%B0-%EB%9D%BDDistributed-Lock%EC%9D%B4%EB%9E%80-%EB%AD%98%EA%B9%8C [웹 지식] 분산 락(Distributed Lock)이란 뭘까?분산 락이란 여러 서버(또는 인스턴스)가 동시에 같은 자원에 접근할 때, 하나만 접근하도록 제어하는 메커니즘이다 사실 단일 서버에서는 synchronized, Lock 같은 걸로 해결 가능하다. 하지만 분산claremont.tistory.com분산 락에 대한 개념을 먼저 숙지하고 오자!!! 생성형 AI 플랫폼 개발을 하며 Redis 분산 락 도입을 고민하게 되었다!상황 설명외부.. 2026. 4. 10. [데이터베이스] DB 커넥션 풀(Connection Pool)의 의미 웹 애플리케이션을 만들다 보면, 데이터베이스(DB)와의 연결이 생각보다 비싼 자원이라는 사실을 체감하게 된다.특히 트래픽이 몰릴 때 “DB 연결 에러”나 “Connection timeout” 같은 문구를 한 번쯤은 본 적 있을 것이다.이런 문제를 해결하기 위한 핵심 개념이 바로 DB 커넥션 풀(Connection Pool)이다. 일단 먼저 커넥션(Connection)이란?애플리케이션이 DB에 접근하려면, 먼저 네트워크를 통해 DB 서버와 연결(Connection)을 맺어야 한다.이 연결을 생성하는 과정은 단순히 “접속” 이상의 비용이 든다.TCP/IP 소켓 연결인증 절차 (ID/PW 확인)세션 초기화이 모든 과정이 한 번의 쿼리를 실행하기 위해 매번 일어나면, 성능은 크게 떨어진다.그래서 보통 DB 연.. 2025. 10. 13. [Redis] 초간단 설치 + 실행법 (macOS 기준) https://claremont.tistory.com/entry/Redis-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EA%B8%B0%EB%B0%98-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EC%A0%80%EC%9E%A5%EC%86%8C%EC%9D%98-%EC%8B%A4%EC%9A%A9%EC%A0%81-%EC%9D%B4%ED%95%B4 [Redis] 메모리 기반 데이터 저장소의 실용적 이해실시간 처리 시스템을 설계할 때 빠지지 않고 등장하는 기술 중 하나가 바로 Redis(레디스)이다. 나 역시 AI 면접 시스템에서 실시간 STT 처리와 병렬 분석을 구현하면서 Redis의 유용함을 깊이 체감claremont.tistory.comRedis의 개념은 위의 글에서 정리해 놨다! 본 글.. 2025. 5. 23. [Redis] 메모리 기반 데이터 저장소의 실용적 이해 실시간 처리 시스템을 설계할 때 빠지지 않고 등장하는 기술 중 하나가 바로 Redis(레디스)이다. 나 역시 AI 면접 시스템에서 실시간 STT 처리와 병렬 분석을 구현하면서 Redis의 유용함을 깊이 체감했다.(SK AXIS 프로젝트) 이 글에서는 Redis의 개념부터 실전에서 어떻게 쓰이는지까지 정리해보려 한다! ㅁRedis(Remote Dictionary Server): 메모리 기반의 키-값 데이터 저장소 Redis는 일반적인 RDBMS(MySQL, PostgreSQL 등)와는 달리, 디스크가 아니라 메모리(RAM)에 데이터를 저장하기 때문에 압도적으로 빠른 속도를 자랑한다! 또한 단순한 캐시 서버를 넘어서, 아래와 같은 다양한 구조를 지원한다.문자열(String)리스트(List)해시(Hash)셋.. 2025. 5. 22. [벡터 DB] 선택 가이드 https://claremont.tistory.com/entry/%EB%B2%A1%ED%84%B0-DB-%EC%B4%88%EB%B3%B4%EC%9E%90%EB%8F%84-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-%EB%B2%A1%ED%84%B0-DB-%EA%B0%9C%EB%85%90 [벡터 DB] 초보자도 쉽게 이해하는 벡터 DB 개념ㅇ벡터 DB(Vector DataBase): 데이터를 벡터(Vector)로 변환하여 저장하고, 이를 빠르게 검색할 수 있도록 설계된 DB주로 AI, 머신러닝, RAG(Retrieval-Augmented Generation)에서 유사한 데이터 검색에 사용된다 💡claremont.tistory.com 일단 벡터 DB.. 2025. 5. 9. [데이터베이스] SQL 튜닝 체크리스트(실전 팁) ㅁSQL 튜닝(SQL Tuning): SQL 문장의 성능을 향상시키기 위해 구조나 실행 계획을 최적화하는 작업 이는 데이터베이스 시스템에서 불필요한 리소스 소비를 줄이고, 응답 시간을 단축시키며, 전체 시스템의 처리 효율을 높이기 위한 중요한 과정이다 같은 결과를 반환하는 쿼리라도 작성 방식에 따라 성능 차이가 극명하게 나타날 수 있다. 특히 대량의 데이터를 다루는 시스템에서는 쿼리 하나가 전체 응답 시간을 좌우하기도 한다. 이에 따라, 성능을 높이기 위한 SQL 튜닝(SQL Optimization)은 매우 중요한 작업이다! 이번에는 SQL 성능을 개선하기 위해 실무에서 자주 활용되는 튜닝 체크리스트를 알아보려 한다 :) 1. SELECT * 대신 필요한 컬럼만 조회SELECT * 는 모든 컬럼을 가져.. 2025. 4. 18. [데이터베이스] 옵티마이저(Optimizer) 개념에 대해 ㅁ옵티마이저(Optimizer): SQL 쿼리를 가장 효율적으로 실행하기 위한 실행 계획(Execution Plan)을 선택하는 DBMS의 내부 컴포넌트즉, 다음과 같은 질문에 답하기 위한 내부 판단 시스템이다어떤 인덱스를 사용할까?테이블 조인은 어떤 순서로 할까?풀 테이블 스캔이 더 나을까, 인덱스 스캔이 더 나을까? (옵티마이저 종류 2가지)규칙 기반 옵티마이저(Rule-Based Optimizer, RBO)정해진 규칙에 따라 실행 계획을 선택한다. 예를 들어, 인덱스가 있으면 무조건 인덱스를 사용하는 식이다. 단순하고 예측 가능하지만, 다양한 상황에 유연하게 대응하지 못한다는 단점이 있다.비용 기반 옵티마이저(Cost-Based Optimizer, CBO)테이블의 행 수, 인덱스 유무, 통계 정보 .. 2025. 4. 18. 이전 1 2 3 4 다음