![]()
1. 부하 테스트1-1. 부하 테스트란 ?부하 테스트 (Load Test)시스템이 일정 수준 이상의 트래픽이나 사용자 요청을 처리할 수 있는지 확인하는 테스트주로 웹 서비스, API 서버, 데이터베이스 등에서 성능 한계나 병목 구간을 찾기 위해 사용함 1-1-1. 주요 부하 테스트 유형Load Test : 점진적으로 부하 증가 → 시스템 성능 측정Stress Test : 정상 한계를 넘는 부하를 가함 → 시스템 안정성 확인Spike Test : 짧은 시간에 급격한 부하를 가함Soak Test : 장시간 일정 부하를 가함 → 시스템의 메모리 누수, 성능 저하 여부 확인 1-2. 테스트 진행 이유2025.05.16 - [DevOps/Monitoring] - [DevOps/Monitoring] AWS EC2에..
![]()
1. 모니터링 시스템1-1. 사용 이유단순한 로그만으로는 운영 상태를 파악하는데 한계가 있음서비스의 성능, 상태, 오류 등 실시간 정보 파악 및 대응 가능특히 운영 환경 (Production)에서는 메트릭 기반 모니터링이 필수임 1-2. 구성 요소메트릭 수집기 (Collector) : 애플리케이션으로부터 CPU 사용량, 요청 수, 에러 수 등 다양한 지표 수집ex) Prometheus, Telegraf, StatsD 등저장소 (Time-Series DB) : 수집된 데이터를 시계열로 저장ex) Prometheus 내장 TSDB, InfluxDB 등시각화 도구 (Dashboard) : 데이터를 그래프, 차트 등으로 시각화 ⇒ 직관적인 분석 가능하게 함ex) Grafana, Kibana 등알림 시스템 (Al..
![]()
1. 문제 상황 파악프로젝트에 쿠폰을 보유하지 않은 회원 목록에 대해 이메일 전송 기능을 구현함샘플 유저 데이터 20개를 삽입 후 이메일 전송 기능을 테스트했을 때 시간이 꽤 걸리는 것을 확인 ⇒ 실제 소요 시간을 찍어보기로 함 1-1. 전송 시간 측정 결과구현한 api는 이메일 주소 1개에 대해 이메일을 전송하는 기능을 가짐따라서 api 호출만의 소요 시간으로는 여러개 이메일 전송에 걸리는 시간을 측정하기 어려울 것이라 판단⇒ 현재 FE에서 비동기적으로 api를 호출하므로 총 시간을 브라우저의 콘솔에 출력해보기로 함더보기FE 코드 일부 // 이메일 전송 함수 일부try { await Promise.all(selectedEmails.map(async (email, index) => { ..
![]()
1. Mongo DBNoSQL 데이터베이스, 문서 지향 데이터베이스NoSQL : ‘Not Only SQL’RDBMS와는 데이터 저장 방식이 다름스키마가 고정되지 않아, 다양한 형태의 데이터 저장 가능구조화되지 않은 데이터나 반정형 데이터 (JSON, XML 등) 효과적 처리 가능데이터를 JSON과 유사한 BSON (바이너리 JSON) 형식으로 저장유연한 데이터 모델링 가능, 스키마가 변경되더라도 적응이 쉬움 1-1. Mongo DB 사용 이유 및 장점유연한 스키마위에 언급했듯이 스키마가 고정되어 있지 않아, 데이터 구조 변경이 쉬움데이터를 여러 서버에 분산 저장 가능 ⇒ 데이터 증가에 유연한 대응 가능성능대량 데이터 읽고 쓰기가 빠름인덱스 및 샤딩 (sharding) 을 통해 쿼리 성능 최적화 가능복잡한..
![]()
1. 문제 상황 파악프로젝트에 STOMP를 통해 1:1 채팅 기능을 구현함페이지네이션 적용해 무한 스크롤까지 구현된 상황 채팅 전송위의 그림과 같은 순서를 가지며 매번 채팅을 전송할 때마다 DB에 접근함채팅 조회⇒ 다수의 사람이 채팅을 전송 및 조회할 때 모든 요청이 DB에 접근하게 된다면 과부하가 발생하거나 성능이 저하될 것이라고 판단해 성능 개선하려고 함 2. 해결 방법 및 현재 상황에 적용일반적인 방법 혹은 채팅 아키텍처가 아니지만 프로젝트 진행 도중 조금이라도 성능 개선할 수 없을까하는 생각에 도입함 2-1. 캐싱(caching)자주 사용되는 데이터를 임시 저장소 ( = 캐시, cache)에 저장해 동일한 요청이 들어왔을 때 더 빠른 응답이 가능하게 하는 기술캐시일반적으로 메모리에 위치함 (대표적..
![]()
1. 문제 상황 파악프론트엔드에서 무한 스크롤 기능을 추가함에 따라 백엔드에서 채팅 조회 시 페이지네이션을 적용함약 1000~2000개의 채팅 추가 후 확인 시 조금씩 느려짐을 확인함 데이터가 많아지면 느려지는 문제를 확인해보기 위해 아래의 과정대로 1,000,000개의 데이터를 삽입하고 테스트를 진행함1. 채팅 메시지 테이블에 1,000,000개의 샘플 데이터를 삽입2. 가장 마지막 20개의 채팅 조회⇒ 백만개의 데이터 (생성일 기준 내림차순) 중 가장 마지막에 해당하는 20개를 조회할 때 2.08초가 소요됨3. 그렇다면 데이터가 1억, 10억개 ... 등 더 많이 존재한다면 조회 시간이 기하급수적으로 늘어날 것이라고 판단해 성능 개선하려고 함 2. 문제 원인 파악2-1. 기존의 페이지네이션 기법off..
