실전 프로젝트 2주 차를 진행 중이다. 실전 프로젝트 최종 발표는 5월 7일이다. 한 달 남짓 남은 시점에서 어떤 것이 진행됐는지, 추후 어떤 걸 진행할 것 인지 정리해보려고 한다.
✔️ 기술 선택 이유 정리
CI/CD - Github Actions vs Jenkins
- Jenkins와 비교하면 Github Actions는 별도의 CI 서버가 필요 없다. Github의 호스팅 서버를 이용하여 프로젝트 빌드가 이뤄진다. 별도의 CI 서버를 관리하는 부담이 줄어드는 장점이 있다. 또한 사용 중인 Github에서 사용할 수 있는 접근성의 장점이 존재하여 Github Actions로 진행하게 되었다.
모니터링 - Prometheus + Grafana
- Spring boot 프로젝트의 actuator 를 활성화하여 다양한 메트릭 정보를 얻을 수 있다. 프로메테우스로 해당 메트릭들을 수집할 수 있다. 하지만 프로메테우스로 전체 서버의 메트릭을 한눈에 보기는 힘들다.
- 해당 문제를 Grafana를 이용하여 다양한 메트릭 정보를 한눈에 볼 수 있게 시각화 한다. 누군가 이미 만들어둔 대시보드를 활용하면 손쉽게 모니터링 대시보드를 구성할 수 있어서 선택하게 되었다.
Docker
- 도커는 우리의 애플리케이션을 컨테이너로 패키징 해준다. 애플리케이션에 필요한 종속성, 환경설정의 일관성을 유지해줄 수 있다. 이 때문에 어느 환경에서도 일관성 있는 개발을 할 수 있어서 선택하게 되었다.
AWS
- AWS는 우리 대용량 트래픽 프로젝트에 걸맞게 필요에 따라 컴퓨팅 리소스를 신속하게 확장하고 축소가 가능하다. 예측 불가능한 트래픽 및 용량에 대응할 수 있기 때문에 선택하게 되었다.
✔️ 모니터링 서버 구축
부하 테스트를 진행하면서 서버의 상황을 한 눈에 볼 수 있는 모니터링 툴이 필요했다. 우리 팀이 정한 툴은 Prometheus + Grafana 이다. 우리 팀이 고민했던 점은, 모니터링 EC2 서버를 분리할지? 아니면 Spring boot 프로젝트가 실행되는 EC2에 함께 구축할지 였다.
아래 블로그에서 우리 고민에 대한 해답을 얻을 수 있었다. 모니터링 서버와 Spring boot 프로젝트가 함께 구축되어있으면 서비스에 필요한 리소스를 모니터링 툴이 잡아먹어서 성능 저하의 원인이 될 것 같았다. 그래서 모니터링 구축용 EC2를 따로 하나 더 만들게 되었다.
하지만 그만큼 EC2를 하나 더 관리해야 하기 때문에 비용적인 측면에서는 단점이라고 볼 수 있겠다.
❌ 프로메테우스 메트릭 수집 관련 트러블 슈팅
프로메테우스에서 우리 서비스 프로젝트의 메트릭을 수집해 갈 수 있도록 하기 위해 아래와 같은 의존성을 추가하였다.
// Monitoring
implementation 'org.springframework.boot:spring-boot-starter-actuator'
implementation 'io.micrometer:micrometer-registry-prometheus'
우리의 서비스 메트릭들을 프로메테우스가 수집할 수 있게 설정하고 /actuator/prometheus 엔드 포인트 수집을 할 수 있게 설정했다. 하지만 프로메테우스가 우리의 Spring boot 메트릭을 수집하지 못 하고 있었다.
원인
우리의 프로젝트는 Spring Security를 기반으로 인증/인가를 진행한다. 프로메테우스가 /actuator/prometheus 엔드 포인트를 접근하려고 할 때, 스프링 시큐리티에 의해 막히고있던 상황.
해결
프로메테우스가 메트릭을 수집해 갈 수 있도록 Spring Security에서 /actuator 엔드포인트의 접근을 허용해 주도록 수정하였다.
.requestMatchers("/actuator/**").permitAll() // 프로메테우스 메트릭 수집
보완점
하지만 엔드 포인트를 열어버리면 웹 상에서 누구나 우리의 메트릭 정보에 접근할 수 있게 된다. 포트 변경, 엔드 포인트 설정 변경, 접근 권한 관련 설정이 필요해보임.
추후 고려 사항들
수강신청에 트래픽이 몰릴 때, 동시성 문제가 발생할 수 있다. 동시성 제어의 다양한 방법과 적용을 통해 동시성 문제를 해결하는 방법을 적용시켜야 할 것 같다.
Jmeter를 활용한 부하 테스트로 Grafana에서 어떤 리소스를 참고하면 좋을지 더 찾아봐야겠다. 서비스에 부하가 심해지면 슬랙에 알림이 오게 하는 등 알림 설정 또한 적용시키면 좋을 것 같다.