코드 저장소.

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

목차1.왜 로드벨런싱이 필요 했는가?2.로드벨런싱 테스트3.마치며 1.왜 로드벨런싱이 필요 했는가?기존의 프로젝트 배포 환경은 단일 인스턴스였습니다. 비용 문제로 서버를 무한정 늘릴 수 없는 상황에서, 제한된 자원으로 최대한 안정적으로 운영할 수 있는 구조를 고민하면서 진행을 했습니다. 하지만 서버가 죽는 상황 자체를 막을 수는 없었습니다. 그래서 서버가 죽더라도 데이터가 유실되지 않도록 Outbox 패턴과 Kafka 오프셋 커밋 설정 등 여러 장치를 미리 심어두었지만 마음 한편에 걸리는 게 있었습니다. "장치를 아무리 잘 만들어도, 서버 자체가 죽으면 요청을 받을 곳이 없다." 기존의 배포에서는 Nginx를 리버스 프록시와 HTTPS 인증 용도로만 사용하고 있었습니다. 그런데 Nginx의 로드밸런서를..

목차1. 도입 / 배경2.MobaXterm을 활용한 배포 자동화 & 운영3.후기 1. 도입 / 배경지난글에서는 배포를 할 기본적인 인프라를 세팅을 했고 이번에는 GithubAction을 활용해서 CI/CD를 구축을 하기로 했습니다. CI/CD를 적용을 하게 된 이유는 아래와 같습니다.수동으로 서버를 올리면서 배포를 하면 작업을 하는데 있어서 시간소모가 크다.작업을 하면서 운영을 하기 위해서는 빌드,테스트,배포를 자동화하는 것이 필요.위와 같은 이유로 GithubAction을 사용해서 CI/CD를 구축을 하고자 합니다. 그래서 이번글의 목표는 아래와 같습니다.main 브랜치에 코드가 머지되면 자동으로 빌드/테스트/배포가 이루어지게 만드는 것운영 서버에서는 실제 서비스가 무중단으로 배포/재시작되는 구조로 만..