[우당탕탕 배포공부] 1. 배포 프로세스 결정하기 (요구 조건 파악)

Monday가 말했다. 

자아도취도 아니고 자아참수잖아 이건.
너 진짜 혼자서 너무 열심히 부끄러워하고 있다.
무슨 ‘경력이 쌓일수록 질문 못 하는 병’ 걸린 프로 자책러냐?

 

끝이 안 보이는 cs 라는 우주 안에서 '자신 없음' 이라는 감정에 황망해질때가 있다.   

하지만, 모르는데 부끄러워서 질문도 못하거나 아는 척하는 건 정말 최악이기 때문에.... (무시당할지언정, 이렇게 살지는 않으련다) 

그까이꺼 뭐...... A-Z 차근차근 하나하나 공부해보지 뭐! 시리즈! 

 

늘 그렇듯이 모르겠구요 정말 모르겠습니다

 

시리즈 순서
1. 요구조건 파악 : 배포 프로세스 결정하기 (요구사항, 다른 옵션과 비교, 선택 이유)
2. AWS EC2와 ALB 세팅
3. AWS RDS와 S3세팅
4. 과금 방지와 스프링단 설정 
5. 도커와 CI/CD로의 확장  (추후)

 

---

1. 요구사항 분석 

• 팀원들과의 사전 협의가 안 되어있는 상황에서 요금이 과하게 발생하는 것을 지양함
• 처음부터 많은 유저들이 서비스를 사용하지는 않을 것으로 파악됨
• Freetier 옵션 사용 가능함

 

2. 아키텍처 구상들 

회사에 담고 싶은 아키텍처 분께 아이디어들의 조합이 무궁무진한 배포 프로세스를 어떤 과정으로 설계해야하는지 여쭤보았다.

우선 만들고 싶은 프로세스를 목표로 잡은 후에 
구현 가능한 것들을 최대한 붙혀보고 
실현 가능성 (시간과 비용)을 고려해 하나 하나씩 빼가는 과정 

 

이 방법을 채택하여 아래와 같은 고민으로 최종 결과를 도출하였다.

 

1) 개발과 운영 서버를 분리해볼까? 

 

[아키텍처 포커싱]

• 모든 기술적 욕심이 담긴 프로세스를 구상하였다 
• 실제 운영되는 프로젝트처럼 테스트용 개발서버와 배포용 운영서버를 나누어 보안을 최대로 트래픽도 과감하게 잡았다. 
• ❓  이미지는 S3에 저장한다.

EC2에 EBS 보다 훨씬 저렴하며 (물론 프리티어를 사용하게 되면 제한적으로 무료이긴 하지만) 향후 로드밸런서로 여러개의 인스턴스를 접근할 수 있을 때 S3 버킷의 유리함을 생각하기로 했다. 

• ❓  RDS 왜 분리한다. 

물론 EC2에 DB 서버도 함께 둘 수 있지만 서버가 계속해서 운영되면 CI/CD에서 서버가 죽는 경우가 많으며, RDS 분리는 시간문제

subnet을 따로 나누진 않았다

 

보안을 위해 spring 서버를 private 영역으로 위치시켰다

 

[문제점]

🗣️“서버 분리에 대한 의견”

→ 비용 측면에서 운영 서버를 구축은 과할 수 있다는 의견

→ 아직은 QA가 본격적으로 (많은 case) 되진 않을 것으로 파악

🏁 QA가 앞으로 더 필요해진다면 개발/운영서버는 분리가 되어야한다는 의견

 

🗣️“AWS 기능 사용에 대한 의견”

→ Route53/ALB-ACM도 역시 AWS의 자원이기 때문에 과금이 됨

→ 로드 밸런서 서버 주소를 계속해서 캐싱 네트워크 접근 속도가 빠른 것은 nginx도 할 수 있음

 

 

 

2) Nginx vs ALB

[아키텍처 포커싱]

• ALB 를 사용하지 않고 nginx 를 사용한다.
• ❓ EC2 는 왜 2개로 운영을 하였나?

보안

프론트 스크립트 안에 주소, 개발자 도구 네트워크 추적 서버주소 nginx 내부 포트만 (cmd → 내부 서버 주소 노출)

→ nginx 앞단에 두면 nginx 서버 주소만 알고 있게 됨 (즉, 프록시 역할)

 

네트워크 캐싱

→ nginx 가 ALB 역할을 똑같이 됨 (서버주소를 캐싱해서 다시 요청이 왔을 때 빠르게)

EC2 t2.micro 가 2개 (1개는 프리티어, 1개는 일반)

 

 

 

[문제점]

🗣️ “ALB도 프리티어가 있다면 굳이 서버를 2개를 생성할 필요는 없지 않을까?”

 

🗣️ “하지만 EC2 2개 모두 t2.micro 로 한다면 한달에 6000원으로 저렴하게 할 수 있을 것”

→ ALB 프리티어가 EC2보다 저렴하다면, 차라리 ALB를 쓰는 게 낫지 않을까?

 

🗣️ “S3에 get 요청에 따라서 과금될 가능성이 높음”

→ CloudFront 를 두어서 캐싱하는 것이 앞으로 과금의 위험을 줄일 수 있을 것

 

🗣️ “CodeDeploy는 꼭 사용해야하나?”

→ EC2 1개, AZ도 한개이며 AutoScaling 기능이 없다면 스크립트 1개만 작성해도 무방

 

 

3) Nginx 의 사용 필요성

[아키텍처 포커싱]

• ❓ Nginx 가 하나의  EC2 안으로 

→ ALB는 분산 부하의 역할만 하기 때문에 바로 spring 으로 연결되는 것이 보안 위험성이 있을 수 있음

• ❓ GithubAction 에서는 바로 spring

→ CodeDeploy는 Multi AZ 환경에서 Target group이 여러개의 EC2를 향하고 있을 때, 매번 스크립트를 변경하는 번거로움을 덜어줌

→ 현재 우리 사이트는 EC2 1개, 단일 AZ 이므로 삭제

 

 

[문제점]

🗣️ “ALB와 Spring security 가 있다면 보안에는 크게 무리가 없다고 생각함”

💥 ALB는 freetier를 제공하지만 다중 AZ 가 있다고 함?

 

 

여전히 걸리는 ALB의 과금 여부 

[문제점]

❓ ALB는 기본적으로 과금이 되는 구조

(다중 AZ 에서 하나의 AZ 만 쓰면 돈은 더 들지 않음, 그러나 리스닝과 타겟그룹에 대한 트래픽에 따라 과금)

 

=> 그렇다면 2번으로 다시 돌아가야함 

 

 

4) 최종 결정 : ALB + EC2 (t2.micro) + Cloudfront/S3 + RDS

[아키텍처 포커싱]

❓ spring의 사양?

✅ 필요할 때 올리자

→ RDS / S3 따로 둘 것이기 때문에 t2.micro로 해도 큰 무리는 없을 거라는 판단

 

❓ ALB 과금 위험은?

✅  ALB 1개 - 프리티어가 아니기 때문에 과금 피할 수 없음 (계속해서 모니터링 예정)

 

❓ https 통신은?

✅ cors에서 처리해줄 수 있는 방법 

ALB를 놓기

매월 20달러 정도의 고정 비용은 감수해야하는 상황

그러나 ALB를 두어 확장성에도 대비할 수 있고, 이 상황에서 굳이 Nginx는 필요 없기 때문에 해당 방안을 채택

 

청구서를 모니터링 한후 nginx로 ALB를 대신할 수도 있다는 결론