| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- 연습문제
- 이것이 자바다
- 데이터 베이스
- Java
- Join
- 프로그래머스
- LV.02
- nginx
- mysql
- CI/CD
- Redis
- JPA
- 디자인 패턴
- JMeter
- LV03
- 포트폴리오
- spring boot
- 일정관리 프로젝트
- LV0
- 일정관리프로젝트
- LV01
- CoffiesVol.02
- AWS
- docker
- 알고리즘
- 코테
- LV02
- SQL
- Kafka
- Lv.0
- Today
- Total
목록분류 전체보기 (204)
코드 저장소.
목차1.이전글2.트러블 슈팅과정3.소감 1.이전글 지난 글에서는 분산 서버 환경을 구축하고, 60VU(Virtual Users) 조건에서 시스템이 중단 없이 안정적으로 로드밸런싱되며 트래픽을 소화하는 것까지 확인했습니다. 60VU 수준에서는 서버 두 대가 요청을 안정적으로 나누어 가졌고, 모니터링 지표상으로도 큰 무리가 없었습니다. 하지만 실제 운영 환경에서는 언제든 예측 범위를 벗어난 대규모 트래픽이 몰릴 수 있습니다. 제 프로젝트의 궁극적인 목표는 단순히 '돌아가는 분산 서버'를 넘어, 더 높은 고부하 상황에서도 데이터 정합성을 유지하며 버텨내는 '고가용성 인프라'를 검증하는 것이었습니다. 따라서 이번에는 한계를 더 밀어붙여, 성능 측정의 최종 목표치인 100VU 환경을 타깃으로 잡고 부하 테스트를 ..
목차1.들어가며 (이전 글에서 이어서)2.측정 과정에서의 트러블 슈팅3.회고 1.들어가며 (이전 글에서 이어서)이전 포스팅에서 30VU → 50VU 구간의 안정성을 확보했습니다. 이번 글에서는 최종 목표인 60VU → 100VU구간에서 발생한 추가 병목 지점들을 기록합니다. 총 5번의 실패를 거쳐 60VU 에러율 0.05%를 달성하기까지의 과정입니다.2.측정 과정에서의 트러블 슈팅 2-1. [1차] 60VU 테스트 실패 — DB 데드락 [현상] 60VU 테스트 시작 직후 에러율 16% 기록. 평균 응답 시간 1,105ms, 95% Line 1,868ms. 파란색 선(Average)이 우상향 곡선을 지속하다 17초 지점에서 에러 폭발했습니다. 요청 유입 속도가 처리 속도를 초과하면서 서버 내부 대기열(Q..
목차1. 왜 다시 부하 테스트를 진행했는가?2.테스트 환경 및 시나리오3.측정 과정에서의 트러블 슈팅4.회고 1. 왜 다시 부하 테스트를 진행했는가1-1. 단일 서버 테스트의 한계 및 분산 전환 배경 기존 단일 서버 환경에서 진행했던 부하 테스트를 통해 다음과 같은 구조적 한계점을 확인하고 분산 아키텍처로 전환을 결정했습니다.인프라 스펙의 한계: 단일 노드의 낮은 CPU/RAM 자원만으로는 실 서비스 수준의 트래픽을 처리하는 데 물리적인 제약이 있음.SPOF(Single Point of Failure) 발생: 서비스 서버 장애 시 전체 시스템이 중단되는 가용성 문제가 존재함.확장성 검증 부재: 트래픽 증가에 따른 스케일 아웃(Scale-out) 시, 로드밸런싱과 분산 데이터 처리 과정에서의 성능 변화를 ..
목차1.고도화 이유2.변경된 구조3.후기 1.고도화 이유지난 1편에서는 AWS LightSail 2GB VM이라는 제한된 인프라 환경에서 OpenAI API와의 연동을 위해 OpenFeign(블로킹)을 WebClient(논블로킹)로 전면 전환하는 뼈대 작업을 진행했었다. 당시 JMeter를 활용해 메인 인프라의 체력을 테스트했을 때, 일반 일정 생성(CRUD) API의 경우 동시 사용자 100명(100VU)까지 에러율 0%로 안정적으로 버텨내는 성능 방어선을 확인했었다.우리 서버 자체의 일반적인 CRUD 처리 능력은 검증을 마쳤지만, OpenAI API를 직접 타고 들어오는 AI 일정 추천/챗봇 기능을 실제 서비스 운영 환경 관점으로 들이받았을 때는 여전히 해결해야 할 두 가지 한계가 찝찝하게 만들었습니..
목차 1. Zookeeper를 걷어낸 이유?2. 마이그레이션 과정 3.회고 1. Zookeeper를 걷어낸 이유?기존의 Kafka는 분산 시스템의 특성상 클러스터의 상태를 관리할 '코디네이터'가 필수적이었습니다. "어떤 브로커가 살아있는지", "누가 리더인지", "설정 정보는 무엇인지"와 같은 핵심 메타데이터를 저장할 별도의 공간이 필요했습니다. 그 역할을 오랫동안 담당해 온 것이 바로 Zookeeper입니다. 하지만 Kafka 2.8 버전부터 KRaft(Kafka Raft)가 등장하며 이 구조는 완전히 뒤바뀌었습니다. 저는 왜 이번 프로젝트에 기존 Zookeeper 기반 구조 대신 KRaft 기반 구조를 선택했는지, 그 이유를 정리해 보았습니다. 1-1. Zookeeper 방식의 한계운영 복잡성의 증가..
목차1.공통 환경 구축: Docker & Docker Compose2.인프라 서버: Nginx & SSL 인증서(Certbot) 적용3.Docker Compose를 통한 서비스 배치4.후기 1.공통 환경 구축: Docker & Docker Compose4대의 EC2 서버에 동일한 런타임 환경을 구축하고, 외부 트래픽을 안전하게 수용하기 위한 SSL 인증서 발급 과정을 정리했습니다.# 패키지 업데이트 및 Docker/Compose 설치sudo apt-get updatesudo apt-get install -y docker.io docker-compose# 사용자 권한 부여 (sudo 없이 Docker 명령 실행 가능)sudo usermod -aG docker ubuntu# 서비스 활성화sudo system..