서론

현재까지의 개발 내용을 정리해서 포스팅까지 완료했고, 이제 이전의 계획대로 헬스체크, SSL을 추가한 후 다중 인스턴스 테스트를 진행해 볼 예정이다. 구현 방법에 있어서 Claude와 상담과 공부를 반복하며 방법을 정할 수 있었는데, 까먹기 전에 이에 대해 포스팅해보려 한다.

핼스체크

metric들을 수집하고 저장하는 역할인 Prometheus와 이렇게 수집한 metric들을 시각화하여 보여주는 역할인 Grafana의 조합은 실무에서도 많이 사용되는 조합이다. 실무에서 자주 사용되는 툴을 공부하고 실습하는 프로젝트의 컨셉과도 맞아 해당 조합을 적용하기로 했다.
그렇다면 Prometheus가 수집하는 metric은 누가 만들어서 넘겨주느냐? Spring Actuator 라이브러리를 사용해보니, 별도의 엔드포인트 설정 없이 내부의 프로필 설정만으로도 양질의 metric을 수집하여 넘겨주는 것을 확인할 수 있었다.

(양질의 메트릭을 수집한 모습)
 
라이브러리가 수집해준 metric을 사용하면 Prometheus에도 넘겨줄 수 있고, Docker의 헬스체크에도 사용할 수 있었다.
그래서 결론적으로 백엔드의 헬스체크는 Prometheus+Grafana+Spring Actuator의 조합으로 진행하기로 했고, 프론트의 헬스체크는 Nginx+Docker 헬스체크 조합으로 진행하기로 했다.
DB의 헬스체크도 해보고싶긴 한데 그건 일단 나중에…

SSL

self-signed SSL은 서버에선 사용할 수 없고, 서버에서 사용할 수 있는 SSL을 발급받으려면 자신의 도메인이 있어야 했다.
Claude와 상담 끝에 로컬에선 mkcert, 서버에선 Duck DNS의 도메인+Let’s Encrypt의 조합으로 진행하기로 했다.
 
AWS 서버에서 고정 IP를 사용할 수 있게 해주는 Elastic IP 서비스는 프리티어로는 사용할 수 없기 때문에 서버 인스턴스를 껐다 킬 때마다 IP가 변경된다. 기존에는 이에 맞춰 이런저런 설정을 변경해야 하는 것이 매번 스트레스였다. Duck DNS는 인스턴스를 재시작할 때 스크립트를 통해 변경된 IP를 DNS에 바로 반영할 수 있다는 점이 프리티어를 유지하고 싶은 나에게는 매력적으로 느껴져서, 그리고 또한 무료 서비스라 선택하게 되었다.
 
간편하게 SSL을 발급할 수 있는 mkcert와 Let’s Encrypt를 택했고, 헬스체크 부분이 완료되는 대로 구현에 들어갈 예정이다.
기존에는 SSL과 HTTPS가 뭔지, 그리고 어느 단에서 어떻게 처리하는지를 몰랐는데 이번 기회에 공부하게 되었고, 그동안 CORS 문제 해결과 로드밸런싱을 위해, 그리고 정적 파일 서빙을 위해 사용하던 Nginx가 SSL도 전담해서 처리해줌으로써 백엔드가 비즈니스 로직에 집중하게 되는 이점도 있다는 사실을 알게 되었다.
Docker를 사용했기에 로컬에서도 Nginx를 빠르고 편하게 사용할 수 있어 이런 부분도 편하게 진행할 수 있게 되었고, 잘 구성된 인프라의 힘을 이런 곳에서 느끼게 되는 것 같다.
 
 
6월 내로 모두 구현하는 것을 목표로 해보자.