코드 저장소.

목차1. 왜 다시 부하 테스트를 진행했는가?2.테스트 환경 및 시나리오3.측정 과정에서의 트러블 슈팅4.회고 1. 왜 다시 부하 테스트를 진행했는가1-1. 단일 서버 테스트의 한계 및 분산 전환 배경 기존 단일 서버 환경에서 진행했던 부하 테스트를 통해 다음과 같은 구조적 한계점을 확인하고 분산 아키텍처로 전환을 결정했습니다.인프라 스펙의 한계: 단일 노드의 낮은 CPU/RAM 자원만으로는 실 서비스 수준의 트래픽을 처리하는 데 물리적인 제약이 있음.SPOF(Single Point of Failure) 발생: 서비스 서버 장애 시 전체 시스템이 중단되는 가용성 문제가 존재함.확장성 검증 부재: 트래픽 증가에 따른 스케일 아웃(Scale-out) 시, 로드밸런싱과 분산 데이터 처리 과정에서의 성능 변화를 ..

목차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) 문제 하나의 서버에 모든 컴포넌트가 집중된 구조는 장애 발생 시 전체 서비스 중단 가능성이 높았습..

게시판 만들기(블로그)목차1.만들게 된 이유2.개요3. 목표4.DB ERD5.프로젝트 아키텍처6.api 문서7.구현 및 트러블 슈팅내용8.회고 1.만들게 된 이유JPA를 배우게 되어서 공부하고 적용을 하기 위해서 간단하게 블로그를 만들어보고 추가적으로 새로운 기술을 적용하기 위해서 만들게 된 프로젝트입니다.2.개요프로젝트명: jpapractice개발 인원: 1인개발 기간: 2022.09.12~2023.08.20주요기능 게시판 - crud 기능, 페이징,검색, 조회수,파일 업로드/다운로드,게시글 좋아요, 해시태그, 실시간 알림사용자-  회원가입 , 로그인 및 로그아웃 , 회원 수정 ,회원 탈퇴, 아이디 중복처리, 회원 검색댓글 - 댓글 목록, 댓글 작성, 댓글 삭제관리자 - 게시글 관리, 댓글 관리, 방문..