개발새발

문제 정의게시판의 데이터가 많아질수록 DB에서 게시판을 불러오는 속도가 느려지는 상황 발생예상 원인Full Table Scan으로 인해 속도가 느려진다.인덱스 미사용으로 인한 비효율적인 검색디스크 I/O 증가 기술 선정기술설명장점Hash Index특정 값(=)에 대해 해시 테이블을 생성하여 빠르게 검색'=' 검색 속도가 빠름Full-Text Index긴 텍스트(TEXT, VARCHAR)에서 키워드 검색을 빠르게 수행특정 키워드 검색 최적화B+ Tree Index범위 검색(>, 특정 범위 검색에 효과적  B+ Tree 인덱스 선정 이유기존에 사용하고 있는 MariaDB에서 기존 테이블을 변경하지 않으면서, 범위 검색 성능을 최적화하기 위한 최적의 선택지는 B+ Tree 인덱스라고 생각하여 B+ Tree 기..

1. 문제 - DB 병목 현상 및 성능 저하모든 읽기(조회)와 쓰기(저장) 작업이 단일 데이터베이스(DB)에서 수행되면, 트래픽 증가 시 심각한 병목 현상이 발생높은 동시 요청 처리 시 DB 부하 증가, 응답 속도 지연, 트랜잭션 충돌 증가, 서비스 장애 가능성 증가캐싱(Redis)이 적용되어도, 근본적인 읽기/쓰기 처리 구조를 개선하지 않으면 한계가 존재  2. 원인 - 단일 DB 구조의 한계 및 CQRS 미적용읽기(SELECT)와 쓰기(INSERT, UPDATE, DELETE) 요청을 같은 DB에서 처리함으로써 트랜잭션 경쟁 발생읽기 트래픽(조회)이 과도할 경우, 쓰기 성능이 저하됨Redis 캐싱이 적용되더라도 DB 요청을 완전히 줄이지 못함 → 근본적인 읽기/쓰기 분리가 필요함CQRS(Command..

문제 정의데이터 조회 시 속도가 느려 서비스 성능 저하반복적으로 동일한 요청이 발생하여 서버 부하 증가불필요한 DB 트래픽으로 인해 성능 저하 및 운영 비용 상승 원인데이터베이스의 조회 시간이 길어지는 경우동일한 요청이 빈번하게 발생하지만 캐시를 활용하지 않는 경우트래픽이 급증하는 순간에도 모든 요청이 DB에 직접 접근하는 구조캐시 없이 매번 데이터를 연산하여 조회하는 구조 해결목표 설정불필요한 트래픽을 줄이고, 서버의 부하 감소빠른 처리성능(조회)을 확보하여 고객에게 더 나은 서비스경험을 제공TTL(Time To Live) 설정주요 캐싱 대상 선정 캐싱 전략을 사용하기 전 주의 사항"용도에 맞지 않는 정보나 서비스요청에 캐시를 남용하게 되면 서비스 신뢰도에 큰 문제가 생길 수 있는 위험성을 내포한다."..