| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- LV03
- Redis
- Join
- Lv.0
- LV01
- JPA
- docker
- 이것이 자바다
- LV02
- 디자인 패턴
- spring boot
- CI/CD
- CoffiesVol.02
- JMeter
- Kafka
- 프로그래머스
- Java
- 알고리즘
- AWS
- LV.02
- mysql
- 포트폴리오
- 연습문제
- 일정관리프로젝트
- 일정관리 프로젝트
- SQL
- LV0
- nginx
- 데이터 베이스
- 코테
- Today
- Total
목록2026/04 (9)
코드 저장소.
목차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..
목차 1.아키텍처 개요 2.인프라 구축 3.회고 1.아키텍처 개요 전환 배경 및 동기 기존에는 AWS Lightsail 환경에서 정해진 예산 내로 서비스를 운영하고 있었습니다. 하지만 프로젝트 규모가 커질수록 Lightsail 환경에서는 몇 가지 한계가 분명해졌습니다. 고정 비용 구조 Lightsail은 인스턴스 실행 여부와 관계없이 월 단위 고정 요금이 발생합니다. 테스트하지 않는 시간에도 비용이 계속 발생해 학습 단계에서는 부담이 되었습니다.제한적인 네트워크 제어 VPC, Subnet, 보안 그룹을 세밀하게 구성하기에는 Lightsail의 네트워크 제어 범위가 제한적이었습니다.단일 장애점(SPOF) 문제 하나의 서버에 모든 컴포넌트가 집중된 구조는 장애 발생 시 전체 서비스 중단 가능성이 높았습..