AWS/개인 프로젝트
블럭식스 프로젝트 AWS 구성도
쓱은감자
2024. 3. 8. 14:11
반응형
✨개요
사이드 프로젝트인 블럭식스 어플 제작을 하면서 구축한 AWS 구성도이다. 이번에 구성하면서 가장 중점적으로 생각한 부분은 모니터링과 알람이다. 이전에는 따로 모니터링을 구성하지 않고 API 서버만 올려서 사용해왔다. API 서버만 동작하다 보니 문제가 발생해도 사용자가 인지해야 수정하고 해결이 가능했다. 그래서 이번에는 해당 부분을 강화할 수 있도록 구성하였다.
✍️전체 AWS 구성도

🧩상세 구성
- API Server - 어플과 소통하는 REST API를 처리하는 서버
- Mysql - AWS의 RDS를 사용해 DB 활용
- 프로메테우스 - 기본적인 API 서버 모니터링 / CPU, Memory, Disk, Node exporter 모니터링
- 자빅스 - API 서버에서 실행 중인 FastAPI와 Nginx 로그 모니터링
- 젠킨스 - API서버의 FastAPI 배포
- 그라파나 - 프로메테우스와 자빅스에서 수집한 데이터를 볼 수 있는 대시보드
😔아쉬운 점
이번 프로젝트를 하면서 AWS 인프라 구성 시 아쉬웠던 부분은 아래 4가지이다.
1. 2개의 VPC 이용
- 모니터링 서버와 실제 구동 서버끼리 내부 통신이면 가능한데 기존에 생성한 서버를 활용한다고 vpc를 따로 구성하게 되어 불필요한 리소스가 사용되었다.
2. 퍼블릭 서브넷 이용
- DB와 모니터링 서버는 외부에서 접근이 불필요한 서버인데 프라이빗 서브넷이 아닌 퍼블릭 서브넷에 만들어 사용하였다.
3. 불필요한 모니터링
- “로그를 모니터링해서 활용하면 좋겠다”라는 막연한 생각으로 로그 모니터링을 위해 자빅스를 사용했다. 하지만 기본적인 구동만 모니터링하고 문제가 발생하면 어짜피 서버에 들어가 로그를 모니터링하여 필요없는 자빅스와 로그 데이터만 쌓였다.
4. 수동 배포
- 원래 목적은 젠킨스를 이용해 github에 코드가 push되면 자동으로 서버에 배포되게 할 생각이였는데 github push를 체크가 안되어 수동으로 배포하였다.
👍결론
다음 프로젝트 시 해당 아쉬웠던 부분에 대해 해결하기 위해 AWS 전체 리소스를 밀고 다시 VPC 하나부터 다시 시작할 생각이다. 작은 서비스인데 프로젝트마다 VPC가 필요한가란 생각이 들었고 관리도 더 편리할 것으로 생각된다. 또한 모니터링은 일단 프로메테우스를 더 깊게 공부하여 프로메테우스로만 서비스와 서버 상태만 모니터링할 생각이다. 추가로 넣을 것은 도커나 쿠버네티스를 공부해 활용할 생각이다.
추가로 보안도 할 수 있으면 추가…
반응형