<aside> 💻
결과 도출 프로세스
목표 ⬅️ 구현 가능한 것들을 최대로 붙혀보고 ⬅️ 실현 가능한 조건을 생각해 제외
</aside>

우선순위

1차 리뷰
AWS 자원을 많이 잡아먹는 ver.1 프로세스


문제점
🗣️“서버 분리에 대한 의견”
→ 비용 측면에서 운영 서버를 구축은 과할 수 있다는 의견
→ 아직은 QA가 본격적으로 (많은 case) 되진 않을 것으로 파악
🏁 QA가 앞으로 더 필요해진다면 개발/운영서버는 분리가 되어야한다는 의견
🗣️“AWS 기능 사용에 대한 의견”
→ Route53/ALB-ACM도 역시 AWS의 자원이기 때문에 과금이 됨
→ 로드 밸런서 서버 주소를 계속해서 캐싱 네트워크 접근 속도가 빠른 것은 nginx도 할 수 있음
2차 리뷰 (EC2 인스턴스 vs ALB)
ALB 를 사용할 수 없다면 EC2 인스턴스 2개

❓ EC2 는 왜 2개로 운영을 하였나?
보안
프론트 스크립트 안에 주소, 개발자 도구 네트워크 추적 서버주소 nginx 내부 포트만 (cmd → 내부 서버 주소 노출)
→ nginx 앞단에 두면 nginx 서버 주소만 알고 있게 됨 (즉, 프록시 역할)
네트워크 캐싱
→ nginx 가 ALB 역할을 똑같이 됨 (서버주소를 캐싱해서 다시 요청이 왔을 때 빠르게)
❓ RDS는 왜 분리하였나?
🟢 아키텍처 포커싱
→ 앞으로의 확장 가능성 (≠ 대규모 트래픽용 아키)
→ 관점의 확실한 구분 = nginx의 역할: 로드 밸런서 + SSL 종료 + 라우팅 제어
문제점
🗣️ “ALB도 프리티어가 있다면 굳이 서버를 2개를 생성할 필요는 없지 않을까?”
🗣️ “하지만 EC2 2개 모두 t2.micro 로 한다면 한달에 6000원으로 저렴하게 할 수 있을 것”
→ ALB 프리티어가 EC2보다 저렴하다면, 차라리 ALB를 쓰는 게 낫지 않을까?
🗣️ “S3에 get 요청에 따라서 과금될 가능성이 높음”
→ CloudFront 를 두어서 캐싱하는 것이 앞으로 과금의 위험을 줄일 수 있을 것
🗣️ “CodeDeploy는 꼭 사용해야하나?”
→ EC2 1개, AZ도 한개이며 AutoScaling 기능이 없다면 스크립트 1개만 작성해도 무방
3차 리뷰 (Nginx)
nginx를 같은 EC2에 넣어봄

❓ Nginx는 왜 추가되었나
→ ALB는 분산 부하의 역할만 하기 때문에 바로 spring 으로 연결되는 것이 보안 위험성이 있을 수 있음
❓ GithubAction 에서는 바로 spring
→ CodeDeploy는 Multi AZ 환경에서 Target group이 여러개의 EC2를 향하고 있을 때, 매번 스크립트를 변경하는 번거로움을 덜어줌
→ 현재 우리 사이트는 EC2 1개, 단일 AZ 이므로 삭제
🟢 아키텍처 포커싱
→ 확장 가능성을 열어두되,
→ 다른 서비스에서 제공하는 기능을 중복 사용하지 않는 것이 좋겠다는 판단
b. 문제점
🗣️ “ALB와 Spring security 가 있다면 보안에는 크게 무리가 없다고 생각함”
💥 ALB는 freetier를 제공하지만 다중 AZ 가 있다고 함?
4차 리뷰 ( )*
EC2 2개

❓ ALB는 기본이 다중 AZ 로 설정
→ 과금의 위험성 ㅎㄷㄷ…. 단일 az…………
❓ spring을 또다른 t2.micro ⇒ t2.micro의 비용만 ?