티스토리 뷰

배경

 

저는 웹페이지도 개발하고 있지만 앱내에서 보여지는 주문, 예약관련 페이지도 개발하고 있습니다.

 

개발하고 있는 서비스는 Java 백엔드 기반으로 서비스 되고 있고 프론트엔드 배포를 위해서 백엔드도 같이 배포해야하는 문제가 있어 개선이 필요했습니다.

아무래도 프론트 개발은 수정요건이 자주 발생하고 이벤트성 개발도 있기때문에 개발, 배포과정이 비교적 짧은 경우가 많았습니다.

그런데 백엔드와 같이 배포하다보니 배포시간도 오래 걸리고 소스 관리 측면에서도 단점이 많았습니다.

 

그리고 백엔드 + 프론트서비스 2개로 구성되어 있는 모노레포 구조에서 프론트 서비스를 동시에 2개 서비스 하고 있기때문에 프론트 공통 모듈등을 잘못수정하여 배포한다거나 실수로 수정대상이 아닌 서비스를 잘못 수정하여 배포한다면 서비스에 장애를 발생시킬 수 있는 상황이라 백엔드, 프론트 2개 서비스를 각각 분리하여 3개의 서비스를 별도로 개발, 배포 가능하도록 개발환경을 구성이 필요하여 AWS amplify를 이용하여 프론트 서비스를 분리하게 되었습니다.

 

Amplify란?

 

클라우드파워 기반의 모바일, 웹앱 개발, 배포을 가능하게 하는 프레임워크 입니다.

( Repository 기반의 소스를 빌드, 배포, 테스트 가능하다고 생각하면 될 것 같다. 인증이나 백엔드 관련해서도 지원해 주지만 해당부분은 사용해보지 않아 건너뛰겠습니다. )

 

요구사항

 

1. 백엔드 서버와 프론트엔드의 분리, 별도의 개발, 배포 환경 구성

2. CDN 서비스를 통한 호스팅

3. 모니터링 가능

4. 기존 서비스 영향도 X

 

배포과정

 

docs.aws.amazon.com/ko_kr/amplify/latest/userguide/getting-started.html

간단히 필요한 부분만 설명하겠습니다. 자세한건 AWS 문서를 참조 해주세요 :)

 

1. 저장소 선택 , GitHub, GitLab등 사용하고 있는 저장소를 선택할 수 있다.

2. 레파지터리 선택

3. 빌드파일 수정 (처음에 자동으로 프로젝트를 분석하여 설정된다)

4. 배포 완료 후 

 

저장소 선택
레파지터리 선택

 

빌드파일
배포 후 이미지

기본적으로 배포는 Repository 변경을 감지하여 배포과정이 진행된다. ( AutoDeploy를 끌 수 있고 수동 배포를 위해서는 Web Hooks를 만들어 사용할 수 있다. http, curl로 호출 가능하나 본인 기준으로 http요청은 토큰을 포함하고 있었는데도 인증문제로 잘 작동되지 않았다. )

4vCpu 7GB 메모리를 제공하는 환경에서 도커 이미지를통해 빌드가 이루어진다.

빌드과정은 상단 이미지의 빌드 탭에서 로그로 확인 가능하다.

Jest등을 통해 테스트코드 실행할 수 있다. 빌드 => 테스트 => 배포로 이루어지는 워크플로우가 존재하기 때문에 적절한 테스트 코드를 작성한다면 서비스 운영시 실수를 많이 줄일 수 있다.

 

SPA서비스를 위해서는 아래 리다이렉션 설정이 필요하다.

js, css, 이미지, 폰트 등을 제외한 모든 경로는 index.html를 리턴해줘야한다. 그래야 리엑트이던 뷰던 Router를 이용하여 동작하도록 할 수 있기 때문이다. 

( docs.aws.amazon.com/ko_kr/amplify/latest/userguide/redirects.html )

리다이렉션 설정

아래 모니터링 페이지를 이용해 간단한 모니터링이 가능하다.

리퀘스트나 에러카운트에 따라 알람도 설정 가능하다.

모니터링

 

1. 저장소 선택 , GitHub, GitLab등 사용하고 있는 저장소를 선택할 수 있다.

2. 레파지터리 선택

3. 빌드파일 수정 (처음에 자동으로 프로젝트를 분석하여 설정된다)

4. 배포 완료 후 

 

Amplify로 프론트엔드 서비스 분리를 준비하면서 원했던 요구사항을 모두 충족할 수 있어서 매우 만족했습니다.

S3, Cloud Front 만으로도 충분히 서비스 가능하지만 Amplify를 통하면 서비스를 별로 관리도 용이하고 배포, 모니터링도 매우 유용해집니다. ( Amplify도 S3, Cloud Front 기반으로 동작하긴 합니다 )

비용은 빌드 과정에서 사용한 머신 사용시간 + 저장용량 + 호스팅량 == 총 사용료입니다.

 

호스팅 요금이 인스턴스의 데이터 전송요금에 비해 약간 비싸기는 하지만 인스턴스 스케일 아웃에 대한 걱정할 필요가 없으며 인스턴스 사용료도 없다는 측면에서 조금 더 효율적인 것 같습니다. 특히 인스턴스처럼 사용하지 않아도 요금을 내야하는게 아니기 때문에 트래픽이 많지 않을수록 더 좋은 것 같습니다.

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함