Shopfit 프로젝트 시스템 아키텍처

진동선·2023년 11월 19일
CI/CD
0

Shopfit CI/CD

목록 보기
1/1

기존의 프로젝트 배포 환경은 네이버클라우드 였지만, 무료 바우처 한도 초과의 사유로 AWS를 이용해 재배포 하였다.

우선, 시스템 아키텍처 요약을 살펴보자

시스템 아키텍처 요약

1. 백엔드:

  • 기술 스택: Spring Boot
  • 배포: AWS Elastic Beanstalk
  • 환경: Docker 컨테이너화된 환경에서 빌드 및 실행
  • 특징: 확장성과 관리의 용이성을 위해 Elastic Beanstalk를 사용하여 배포, Docker 컨테이너로 일관성 있는 환경 구축

2. 프론트엔드:

  • 기술 스택: React
  • 저장소: Amazon S3
  • 콘텐츠 전송: AWS CloudFront를 통해 전 세계적으로 빠른 콘텐츠 전송을 제공
  • 특징: S3에서 호스팅되는 정적 파일을 CloudFront CDN을 통해 효율적으로 제공하여 사용자 경험 최적화

3. CI/CD 파이프라인:

  • 도구: GitHub Actions
  • 자동화: 코드 push or pull reaquest 시 자동 빌드 및 배포 구현
  • 특징: 지속적인 통합 및 배포를 위해 GitHub Actions를 활용하여 코드 변경 사항을 신속하게 반영

4. 통신:

  • 프록시 서버: Nginx
  • 역할: 백엔드와 프론트엔드 간의 요청 라우팅 및 부하 분산 관리
  • 특징: 안정적인 통신 및 네트워크 효율성 향상을 위해 Nginx 프록시 서버 사용

5. Database:

  • 기술 스택: MySQL
  • 저장소: RDS
  • 특징: DB 관리 작업의 복잡성을 줄이고, 효율적인 운영 및 스케일링을 보장함


처음 배포 프로세스를 설계 할 당시 백엔드 프론트엔드를 같은 인스턴스에 배포를 할 계획이었다. AWS 프리티어의 특성상 인스턴스의 갯수가 1개라는 제약이 있어, 그당시에는 당연히 한 인스턴스에 자원을 분배하여 배포를 해야 한다고 생각했었다. 물론, 단일인스턴스 배포가 설정도 간단하고 난이도는 더 쉬운 편이기도 한 점도 있었다.

그렇다면 왜? Elastic Beanstalk와 s3, cloudfront를 이용해 백엔드와 프론트를 분리하여 배포하였나

백엔드 프론트엔드 분리의 이점

  1. 확장성
  • 백엔드와 프론트엔드를 독립적으로 확장할 수 있으므로 트래픽 증가에 효과적으로 대응할 수 있고, 이는 성능 향상에 기여한다.

  1. 리소스 경쟁
  • 단일 인스턴스 배포의 경우 CPU, 메모리 등의 리소스가 공유되기 때문에 리소스 경쟁이 발생할 수 있고, 이는 성능 저하를 초래할 수 있다.

  1. 서비스 전문화
  • 각 서비스(Elastic Beanstalk, S3, cloudfront)는 특화된 최적화를 제공하기 때문에 어플리케이션의 전체적인 성능이 향상된다.

  1. 비용
  • 프리티어의 경우 단일 인스턴스까지 무료이다. 이뜻은 인스턴스 한대의 운용만 무료라는 것은 아니다. Database, Storage, Serverless, Container 등 여러 카테고리의 서비스들도 12개월간 한정적인 자원 범위에서 무료이다. 그렇기에 성능 향상 대비 추가적인 비용은 일체 없다.



왜? 프론트엔드를 S3와 Cloudfront에 배포하였나

S3의 특징:

  1. 비용 효율성
  • 앞서 설명한대로, S3또한 별개로 5G의 저장용량까지는 무료이다. 또한, S3는 사용한 만큼만 비용을 지불하는 서비스로, 데이터 저장 비용이 매우 경제적이다.
  1. 내구성
  • S3는 99.999999999%의 내구성을 제공하므로, 데이터 손실 위험이 극히 낮다.
  1. 정적 웹 호스팅
  • 웹사이트 호스팅에 최적화되어 있으며, 별도의 웹 서버 없이도 웹사이트를 쉽게 배포할 수 있다.
    이는 Serverless 방식으로, 비용 효율 측면에도 영향을 준다.

CloudFront의 특징:

CloudFront는 전 세계의 정적/동적 웹 콘텐츠, 비디오 등을 대규모로 안전하게 전송할 수 있는 콘텐츠 전송 네트워크(CDN) 서비스이다.
S3에 저장된 정적 웹사이트 또한 CloudFront를 사용하여 전송할 수 있다.

  1. 콘텐츠 캐싱
  • 자주 요청되는 콘텐츠를 엣지 로케이션에 캐싱하여 로딩 시간을 줄인다.
  1. 엣지 로케이션
  • 전 세계에 분산된 엣지 로케이션을 통해 사용자에게 콘텐츠를 빠르게 전달한다.
    이는 전 세계 어디에서나 사용자에게 낮은 지연 시간으로 콘텐츠를 제공할 수 있게 해준다.


    S3를 이용한 콘텐츠 전송

    CloudFront를 이용한 콘텐츠 전송


여기서 의문이 들 수도 있다.
굳이 CloudFront를 사용하지 않고, S3의 정적 웹사이트 호스팅 서비스를 사용해서 프론트를 배포 할 수도 있지 않나?


타겟이 글로벌한 서비스가 아닌 이상, CloudFront의 사용은 오버 엔지니어링이 될 수도 있는건 사실이다.
트래픽의 발생이 국내 한정인 서비스의 경우 전세계의 Edge Location을 사용 할 일이 없으므로, 비용 측면에서도 S3의 정적 웹사이트 호스팅 방식보다 비효율 적일 수 있다.


하지만, CloudFront의 데이터를 캐싱하는 특징은 반복적인 데이터 요청에 대해 더 빠른 응답을 제공할 수 있게 해준다. 이는 성능 향상, 서버 부하 감소 등의 장점이 있다. 또한, 나는 학습이 목표이므로 좀 더 많은 기술을 접해 보는 것이 목표인 것도 이유 중 하나이다.



결과

결론적으로 Elastic Beanstalk, S3, CloudFront를 사용한 배포 방식은 프리티어의 제한적인 리소스 내에서 성능이나 비용의 효율성을 아주 많이 끌어 올렸다.
AWS 프리티어의 t3.micro 혹은 t2.micro 인스턴스에 백엔드와 프론트엔드를 모두 배포한 경우의 글들을 보면, 어플리케이션이 버벅거리는 현상이 많다는 후기가 아주 많다.


하지만 우리 프로젝트의 경우 버벅거림은 전혀 없고 속도가 아주 빠르다.


그밖에도 Github Actions를 활용한 자동화된 워크플로우 구축, Docker container로 어떤 환경에서든 동일하게 작동하도록 일관성있는 환경 구축 그리고, 프론트엔드의 사용자 요청을 백엔드로 라우팅 해주는 Nginx 리버스 프록시를 구축하였다.



아쉬운 점

1. Load Balancing

  • 프록시 서버는 만들어 놓고, 로드 밸런서는 적용을 못해 본 것이 아쉽다. AWS 프리티어의 특성상 인스턴스는 1개밖에 못만들어 로드 밸런서 적용이 불가능 한 것이 원인이다.

2. Jenkins

  • Jenkins 역시 별도의 서버가 필요하여 우리는 Github Actions를 채택하였다.
    복잡한 워크플로우나 다양한 VCS(버전 관리 시스템) 환경을 필요로 하는 대규모 프로젝트의 경우 Jenkins가 적합 할 수 있겠지만, Github중심의 프로젝트인 Shopfit의 경우는 Github Actions가 더 적합한 도구이다.
    별도의 서버가 필요없어 비용도 절약 할 수 있고, 별도의 인스턴스를 관리할 필요도 없어 카카오엔터프라이즈 에서도 최근에 Github Actions로 CI환경을 교체하였다고 한다.
    하지만 학습이 목표이기 때문에, 더욱 복잡한 설정을 해야하는 Jenkins를 사용해 보지 못한 것은 여전히 아쉽다.

3. 부하 테스트

  • 본인이 구축한 서버의 성능을 확인해 볼 가장 확실한 방법은 역시 부하 테스트를 해보는 것이라고 생각한다. Artillery를 활용하여 로드밸런서 적용 전 후의 성능 차이를 확인 해 보려했지만, 제한적인 리소스의 한계로 시도 해 보진 못했다.

















profile
진동선
Second brain

0개의 댓글