본문 바로가기

카테고리 없음

[사이드프로젝트] 사전 준비

728x90

사이드 프로젝트를 곧 시작할 것 같아, 인프라 환경을 어떤 것을 사용하고 구축해야할 지 사전 조사를 해보았다.

내가 조사를 하면서 가장 중요하게 생각했던 것은 과하지 않을 것이었다. 물론 다양한 기술 및 도구들을 사용해보는 것은 좋은 경험이 될 것이지만, 관리 포인트와 시간도 많이 소요될 뿐더러 잘 알지 못한채로 도입하였다가, 사용자들에게 불편을 야기할 수 있었기 때문이다.

그래서 우선 기본적인 클라우드는 aws를 선택했다. 프리티어를 무료로 사용 가능하고, 레퍼런스가 많아 인프라 환경 세팅을 잘 알지 못한 나에게 좋을 것 같았다.

그래서 aws 내의 서비스들을 둘러보며 어떤 것을 사용할 수 있는지 확인하여 정했다.

  • 서버 → EC2 or ECS
  • DB → RDS
  • 로깅 → Cloud Watch
  • static & build files→ S3
  • CD → code deploy
  • CI → git action

서버는 원래 EC2를 사용하기로 마음을 먹었으나, ECS라는 서비스가 보였다. k8s와 같은 컨테이너 관리 서비스로 보이는데, 도커로 서버를 배포할 생각이었어서 이 부분이 어렵지 않다면 ECS로 할 수도 있을 것 같지만, 과한 것 같기도 하다.

DB는 RDS를 사용하여 mysql을 사용하려고 하였다. 하지만 프로젝트에서 geo, json 류의 데이터들이 포함될 것 같아서 mongoDB를 해야하나 생각했다. mysql에서도 geo, json을 모두 지원하고 있긴하여서, 성능이나 서비스 기능 리뷰를 더 해보고 괜찮으면 기존대로 mysql로 하려고 한다. (기능들을 생각했을 때, 트랜잭션을 자주 사용할 것 같았음)

로깅을 위해 보통 쓰이는 것들이 ELK인데 aws의 서비스 기반으로 구축은 가능하지만 여러개를 설정해야하고 관리하는 불편함이 있었다. aws에서는 cloud watch라는 것으로 spring boot에서 설정만 해주면 애플리케이션 로그를 바로 전송할 수 있어 편할 것 같아 Cloud Watch로 정했다.

정적 및 빌드 파일 저장은 S3를 이용할 것이다. 서비스에서 사용될 이미지와 빌드 파일들을 저정하는 용도로 사용할 예정이다. 빌드는 다른 컴포넌트를 사용안하고 git action을 사용하여 빌드하여, s3에 전송하고 해당 빌드 파일을 code deploy로 서버에 배포할 수 있다기에 한번 해볼 예정.

이미지 CDN은 과한 것 같아 추후에 필요하다고 느낄 때 도입할 것.

Github Action을 사용한 Spring boot & gradle CI/CD 구축 - 1

[AWS] Spring, Nginx, Docker로 무중단 배포하기 - 2탄

1. Java 17로 전환을 고려해야 하는 이유

728x90