Letscareer C Tech

Server

Client

Collaboration Tool

1. 시스템 아키텍쳐

📄요구사항

1. 성능 최적화
   • 엘라스틱 캐시를 활용해 캐싱 적용
2. 외부공격대응
   • 퍼블릭 서브넷과 프라이빗 서브넷을 구분하여 외부에서 접근할 수 있는 서비스와 그렇지 않은 서비스를 구분.
     • RDS의 경우 프라이빗 서브넷에 위치시켜 외부 접속을 막음
   • Route53과 Nginx , Certbot을 사용해 HTTPS 적용

2. ERD

3. 사용 스택

사용 기술	도입 이유
Github Actions	- 지속적인 통합/지속적인 배포 (CI/CD) 구축을 통해 효율적이고 일관된 배포 및 테스트 프로세스를 구현하고자 함. - 수동으로 배포 및 테스트를 진행하다보니 효율성이 떨어짐 - GitHub Actions vs Jenkins ⇒ 간편한 설정과 GitHub 통합을 중시하여 GitHub Actions로 결정함
Redis	- 조회 성능 향상을 위한 캐시 저장소로 활용 ⇒ key-value 인메모리 저장소로 조회가 빠름.
MySQL	관계형 데이터베이스로서의 데이터 저장 및 관리에 사용
S3	이미지 파일을 저장해 서버 부하를 줄임.
NGINX	리버스 프록시를 활용한 Https 적용
Route 53	도메인 관리 및 트래픽 라우팅에 사용하여 서비스의 가용성과 성능을 향상시키고, 서비스 배포 및 관리를 용이
EC2	서버 호스팅 및 관리에 활용하여 애플리케이션의 확장성과 유연성을 높이고, 인프라 비용을 절감
AWS Certificate Manager	HTTPS 보안 연결을 위해 SSL/TLS 인증서를 적용하여 데이터의 보안을 강화하고 신뢰성 있는 서비스를 제공
RDS	신속하고 안정적인 데이터베이스 서비스를 구축하여 데이터 관리 및 확장성을 확보하고, 서비스 가용성을 높임
QueryDSL	복잡한 동적쿼리 작성에 용이하며 개발자 친화적인 코드 작성 및 sql 에러를 컴파일 시 잡아낼 수 있다는 장점
RESTDocs	API 명세서 작성을 위해 사용

4. 부하 테스트

렛츠커리어에 들어오는 고객들은 공통적으로 프로그램 리스트 페이지를 보게됩니다.
해당 API에 대해 부하 테스트를 진행했습니다.

캐싱 적용 전

400명의 유저가 96초동안 최대 요청	96초 동안 20초마다 100명씩 인원을 증가시켜 요청을 보냄
응답 시간 최대 : 1m0s 최소 : 4.81ms 평균 : 35.03s 요청 응답률 : 30.12% 초당 처리량 (throughput) : 8.952177/s	응답 시간 최대 : 57.25s 최소 : 2.07ms 평균 : 33.28s 요청 응답률 : 59.53% 초당 처리량 (throughput) : 5.372191/s

캐싱 적용 후

400명의 유저가 96초동안 최대 요청	96초 동안 20초마다 100명씩 인원을 증가시켜 요청을 보냄
응답 시간 최대 : 99.7ms 최소 : 113µs 평균 : 6.02ms 요청 응답률 : 99.24% 초당 처리량 (throughput) : 397.264125/s	응답 시간 최대 : 2.55s 최소 : 591µs 평균 : 5.71ms 요청 응답률 : 100% 초당 처리량 (throughput) : 231.502515/s

캐싱을 적용한 뒤 초당처리량(throughput) 44.37배 증가

---

구글 리서치에 따르면 응답시간이 5s를 넘어가면 90% 이상의 유저가 이탈합니다.
응답을 받을 때 까지 5s가 걸리는지 확인하기 위해 테스트를 진행했습니다.

캐싱 적용 전

350명의 유저가 1초동안 최대 요청
checks가 5% 로 95%의 요청이 응답을 받는데 5초 이상임을 확인

캐싱 적용 후

350명의 유저가 1초동안 최대 요청
checks가 100% 로 모든 응답이 5s 이내로 들어왔음을 확인

캐싱 적용 후 모든 응답이 5s 이내로 들어왔으므로 응답이 느려 사용자 이탈이 발생할 확률 감소.

5. API 명세서

https://letmec.p-e.kr/docs/index.html