Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 |
Tags
- LV.02
- 데이터 베이스
- Join
- LV03
- 알고리즘
- docker
- 디자인 패턴
- JMeter
- CoffiesVol.02
- Lv.0
- SQL
- CI/CD
- 일정관리프로젝트
- spring boot
- Kafka
- LV01
- 연습문제
- Java
- 프로그래머스
- 포트폴리오
- mysql
- LV0
- Redis
- 코테
- 일정관리 프로젝트
- nginx
- LV02
- AWS
- 이것이 자바다
- JPA
Archives
- Today
- Total
목록2026/04/28 (1)
코드 저장소.
목차1. 왜 다시 부하 테스트를 진행했는가?2.테스트 환경 및 시나리오3.측정 과정에서의 트러블 슈팅4.회고 1. 왜 다시 부하 테스트를 진행했는가1-1. 단일 서버 테스트의 한계 및 분산 전환 배경 기존 단일 서버 환경에서 진행했던 부하 테스트를 통해 다음과 같은 구조적 한계점을 확인하고 분산 아키텍처로 전환을 결정했습니다.인프라 스펙의 한계: 단일 노드의 낮은 CPU/RAM 자원만으로는 실 서비스 수준의 트래픽을 처리하는 데 물리적인 제약이 있음.SPOF(Single Point of Failure) 발생: 서비스 서버 장애 시 전체 시스템이 중단되는 가용성 문제가 존재함.확장성 검증 부재: 트래픽 증가에 따른 스케일 아웃(Scale-out) 시, 로드밸런싱과 분산 데이터 처리 과정에서의 성능 변화를 ..
포폴/일정관리 프로젝트
2026. 4. 28. 23:33