[프로젝트 설계] 인프라 및 애플리케이션 설계
프로젝트 시작 이전에 설계와 진행을 하면서 추가된 부분들이 있어 중간 기록을 남겨두려 한다.
우선, CI 플로우가 변경되었다.
이전에는 테스트 코드를 실행하고 성공과 실패 여부를 PR 마다 레포팅하는 식으로 진행했었다. 여기에 jacoco와 SonarCloud를 도입하면서 코드 정적 분석을 실행하고 그 결과를 출력하는 형태로 리펙토링하였다.
Jacoco와 SonarCloud를 도입한 이유는 RestDocs의 사용으로 테스트 코드 작성을 의무화하면서 테스트코드를 이용해 커버리지를 측정하고, 로직의 복잡도를 낮추기 위함이었다.
CD 워크 플로우는 main으로 코드가 push 되면, 소스 코드의 빌드 파일을 S3에 업로드하고, Codedeploy를 통해 EC2에 배포하도록 하였다.
인프라 구성도를 보면, 최초 설계와 달라진 부분들이 있다.
- CloudFront 사용
이미지 리사이징을 위해 CloudFront 서비스를 사용한다. 사용자가 게시글을 작성할 때, 이미지를 클라이언트 단에서 직접 S3에 업로드 하고 서버에 img_url만을 DTO에 담아 보낸다.
사용자가 올리는 이미지의 크기가 규정되어 있지 않고, 제각각이다 보니 클라이언트 단에서 이를 화면에 노출할 때 크기가 다른 것으로 인해 조정이 힘들어 CloudFront 서비스를 통해 이미지 크기를 리사이징한다.
- CloudWatch 사용
서버 측에서는 트랜잭션이 발생할 때마다 로깅을 한다. 트랜잭션의 성공여부와 동작 시간을 파악하기 위함으로, 로그 데이터는 S3에 적재한다.
그리고 CloudWatch로 EC2 서버의 상태를 추적하여 로드 데이터를 S3에 적재한다.
일반 사용자가 인터넷망을 통해 접속하면 인터넷 게이트웨이를 거쳐 로드밸런서를 통해 EC2에 접근하게 된다. 이때 EC2 내부에는 nginx, spring application, redis가 실행중이다.
하나의 서버에 여러 프로세스를 구동하는 이유는 비용절감이다. 프리티어 계정 기준, t2.micro 스펙으로 서버를 구성한 뒤, swap으로 가용 메모리를 늘려서 사용 중이다. 운영 환경에서 이러한 구조가 위험 요소로 작용한다는 점은 인지하고 있다. 하지만, 아직 au가 없고 한 번에 대규모 트래픽이 발생하지 않을 것이기에 필요하다면 하나씩 분리해나갈 생각이다.
트래픽은 nginx ( :80 )으로 들어와 blue ( :8081 )와 green ( :8082 )로 분산된다.
각각을 별도의 서버로 구성하지 않았기에, EC2는 public subnet으로 설정되어 있다.
이러한 환경이 보안적 측면에서 위험하다는 것은 인지하고 있다. 사용자의 유입이 발생하고, 수익 구조가 형성되면 web-was-db 형태의 3tier 구조로 확장하고 web을 제외한 서버는 각각 private subnet 으로 구성하여 외부의 접근을 제한할 것이다. 만일 외부에서 접근이 필요하다면 NAT gateway를 통해 접근할 수 있도록 구성할 예정이다.
위의 형태로 초기에 구축하는 것은 비용 발생이 크기에 구상만 한 상태이다.