Skip to content

Commit

Permalink
[edit] blog modal
Browse files Browse the repository at this point in the history
  • Loading branch information
@Sniij
Sniij committed Feb 26, 2024
1 parent 088a93e commit 945b4ae
Showing 1 changed file with 73 additions and 32 deletions.
105 changes: 73 additions & 32 deletions deploy/content/blog.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -47,42 +47,83 @@ Blog
<hr style="margin: 1rem 0px 1rem 0px;">
<h3>📑 Meaning</h3>
<p style="font-family: 'Pretendard-Regular';">
현재 단락에선 백엔드와 프론트엔드 부분을 따로 나누어서 architecture를 중심으로 설명을 이어나가보겠습니다. </br></br>
현재 단락에선 백엔드와 프론트엔드 부분을 따로 나누어서 아키텍쳐 중심으로 설명을 이어나가보겠습니다. </br></br>
Back:
백엔드 어플리케이션은 이제껏 해왔던 구조로 EC2, RDS 를 기반으로 생각을 했었는데, </br>
근데 EC2에 올려서 24시간 돌릴 필요가 있을까? 람다에 올려서 필요할 때만 호출하는게 더 저렴하지 않을까 싶어서 EC2와 람다에 올릴 때의 가격을 단순비교하여 보았습니다. <br/>
- 2024.02 기준 USD 환율: 1331.18won <br/>
백엔드 어플리케이션은 이제껏 해왔던 아키텍쳐인 EC2 를 기반으로 생각을 했었는데, </br>
EC2에 올려서 24시간 돌릴 필요가 있을까? 람다에 올려서 필요할 때만 호출하는게 더 저렴하지 않을까 싶어서 EC2와 람다에 올릴 때의 가격을 단순비교하여 보았습니다. <br/> <br/>
- 2024.02 기준 USD 환율: 1331.18 won
<p style="font-family: 'Pretendard-Regular';">
1. EC2 (t4g.micro)<br/>
- 온디맨드 시간당 요금: 0.0104 USD <br/>
- 30days: 7.488 USD<br/>
* 한달 한국 원화 기준 요금: 9,967.87584won *<br/>
2. ELB (Application Load Balancer) <br/>
- 온디맨드 시간당 요금: 0.0225 USD<br/>
- 30days: 16.43 USD <br/>
* 한달 한국 원화 기준 요금: 39,935.4won *<br/>
** EC2+ELB 한달 기준 총가격: 49,903.27584won ** <br/>
1. EC2 (t4g.micro)<br/>
- 온디맨드 시간당 요금: 0.0104 USD <br/>
- 30days: 7.488 USD<br/>
* 한달 한국 원화 기준 요금: 9,967.87584 won *<br/>
2. ELB (Application Load Balancer) <br/>
- 온디맨드 시간당 요금: 0.0225 USD<br/>
- 30days: 16.43 USD <br/>
* 한달 한국 원화 기준 요금: 39,935.4 won *<br/>
** EC2+ELB 한달 기준 총가격: 약 49,903 won ** <br/><br/>
</p>
<p style="font-family: 'Pretendard-Regular';">
1. API Gateway 의 API 호출비용 계산 <br/>
- API Gateway에서 Rest API 호출 100만건당: 3.5 USD <br/>
- 월 예상 호출회수 = 10,000 사용자 X 월 100회 로그인 X 로그인시 10개 페이지뷰 = 1천만회 <br/>
* 한달 한국 원화 기준 요금: 46,591.3won * <br/>
2. API Gateway 의 데이터 전송 비용 계산 <br/>
- 호출당 평균 데이터 전송량 : 10KB <br/>
- GB 당 데이터 전송 비용 : 0.09 USD <br/>
- 예상 데이터 전송량 : 1천만회 X 10KB = 1GB <br/>
* 한달 한국 원화 기준 요금: 46,591.3won * <br/>
예상 데이터 전송비용 = 1GB X 0.09 USD / 1GB = 0.09 USD
3. Lambda 호출 비용 계산
. Lambda 100만건당 호출비용 : 0.2 USD
. 월 예상 호출회수 = 1천만회
예상 호출비용 = 1천만회 X 0.2 USD / 100만회 = 2 USD
4. Lambda 사용 비용
. 128MB Lambda 1ms 동안 사용 비용 : 0.0000000021 USD (람다 최소 사양)
. 실행건수 : 1천만회
. 평균 실행 : 시간 500 ms
예상 사용 비용 = 1천만회 X 500 ms X 0.0000000021 USD / 1 ms = 10.5 USD
1. API Gateway 의 API 호출비용 계산 <br/>
- API Gateway에서 Rest API 호출 100만건당: 3.5 USD <br/>
- 한달 예상 호출회수 = 1,000 사용자 X 월 100회 로그인 X 로그인시 10개 페이지뷰 = 1백만회 <br/>
* 한달 한국 원화 기준 요금: 4,659.13 won * <br/>
2. API Gateway 의 데이터 전송 비용 계산 <br/>
- 호출당 평균 데이터 전송량 : 10KB <br/>
- GB 당 데이터 전송 비용 : 0.09 USD <br/>
- 예상 데이터 전송량 : 1백만회 X 10KB = 0.1GB <br/>
- 예상 데이터 전송비용 = 0.1GB X 0.09 USD / 1GB = 0.009 USD <br/>
* 한달 한국 원화 기준 요금: 11.98062 won * <br/>
3. Lambda 호출 비용 계산 <br/>
- Lambda 1백만건당 호출비용 : 0.2 USD <br/>
- 한달 예상 호출회수 = 1백만회<br/>
- 예상 호출비용 = 1백만회 X 0.2 USD / 1백만회 = 0.2 USD <br/>
* 한달 한국 원화 기준 요금: 266.236 won * <br/>
4. Lambda 사용 비용 <br/>
- 128MB Lambda 1ms 동안 사용 비용 : 0.0000000021 USD (람다 최소 사양) <br/>
- 실행건수 : 1백만회 <br/>
- 평균 실행 : 시간 500 ms <br/>
- 예상 사용 비용 = 1백만회 X 500 ms X 0.0000000021 USD / 1 ms = 1.05 USD <br/>
* 한달 한국 원화 기준 요금: 1,397.739 won * <br/>
** Lambda + API Gateway 한달 기준 총가격: 약 6,335 won ** <br/><br/>
</p>
<p style="font-family: 'Pretendard-Regular';">
이렇게 단순 비교지만 개인 블로그처럼 사용자가 적은 경우에는 EC2에 어플리케이션을 띄우는 것보다 <br/>
Lambda를 통해 호출 기반으로 띄우는게 몇배나 더 저렴했습니다.<br/>
그렇기에 Lambda + API Gateway 를 이용하여 서버리스 아키텍쳐로 운용하기로 결정했습니다. <br/>
다만 Java 기반의 어플리케이션은 lambda에서 cold start 생겨 평균 실행 시간이 높아져 비용이 높아질 수 있는 이슈가 있어<br/>
초기엔 snap start 적용과 멀티 모듈을 통해 함수를 분할시킬 생각을 하였습니다. <br/>
하지만 이렇게 그럴듯한 계획은 언제나 부딪히기 마련인 것 같습니다. (눈물) <br/>
실제 제가 구성했던 아키텍쳐로 개발 후에 각각의 람다로 배포하였을 때 평균 실행 시간이 어느정도 낮아지고 존재하고, 실행건수가 줄어들지만 <br/>
오히려 평균 실행 시간의 차이가 미미하여 실행 건수가 매우 많지 않은 이상 결국 이러한 아키텍쳐가 오히려 비용이 더 드는 계산이 나오게 되어, <br/>
최종적으론 앞서 보여드린 이미지 같은 아키텍쳐로 수정하게 됐습니다.<br/>
멀티 모듈의 기준이 되는 아키텍쳐의 구성은 우아한 기술블로그 글을 참고하여 아키텍쳐를 구성했습니다. <br/>
ref: <a href="https://techblog.woowahan.com/2637/" target="_blank"> 멀티모듈 설계 이야기 with Spring, Gradle </a> <br/>
위와 같은 아키텍쳐를 구성함으로써 계층화된 모듈들이 각각의 역할과 책임이 명확하게 있고, 추후 개발의 확장성과 용이성이 증가하였고 <br/>
각 모듈에선 최소한의 의존성을 갖기 때문에 lambda에서의 실행 시간을 늦출 수 있는 효과까지 주었습니다. <br/> <br/>
이제 DB를 선택한 기준에 대해 설명드려 보겠습니다. <br/>
먼저 블로그 속 게시글은 이미지를 포함할 수 있고 글의 내용도 길어 용량이 클 수 있기 때문에 <br/>
마크다운 파일에 내용을 적고 github에 올리기로 결정했습니다. <br/>
또한 마크다운 파일은 클라이언트 content layer 라이브 러리를 통해 동적 렌더링을 할 수 있게끔 하였습니다. <br/>
이런 결정때문에 백엔드에서 domain은 게시글이 지워지고 게시글에 포함되던 조회수 그리고 댓글과 유저만 남았습니다. <br/>
이 상태에서 보았을 때 게시글에 포함되던 조회수만 어떻게 처리하면(?) <br/>
댓글과 유저에서 읽기 속도가 빠른 NoSQL DB를 사용할 수 있는 기회가 될 수 있을 것 같아, <br/>
유저는 OAuth 2를 통해 소셜 로그인만 허용하여 정보를 받아와서 저장시켜 보여주게끔 하여 수정이 필요없게 하였고, <br/>
댓글에서도 작성과 삭제만 가능하게끔 하여 수정 가능하지 않게 하였습니다. <br/>
이렇게 현재의 domain에선 NoSQL DB를 사용하기에 적합한 모델이 되어 MongoDB Atlas 를 사용하여 <br/>
제가 예상되는 범위내에선 무료로 사용할 수 있게 구성하였습니다. <br/>
다만 조회수에서는 항상 수정이 필요했기 때문에 여러가지 방법과 최대한 비용이 적게 들어가는 DB를 몰색해 보았는데, <br/>
제가 운용하는 기준에서는 Upstash의 Redis 정도만 사용해도 충분할 것 같다는 판단이 들어서 Upstash의 Redis를 선택하였습니다. <br/>
다만 조회수 domain을 또 만들어 api 를 생성하는 것보다 <br/>
클라이언트에서 redis 와 연결시켜 조회수만 올릴 수 있는 api를 만들어 운용하기로 아키텍쳐를 구성하였습니다. <br/>
</p>
<p style="font-family: 'Pretendard-Regular';">
이러한 아키텍쳐 덕분에 현재 한달 기준 최소 비용으로 따졌을 때 AWS 비용인 약 6,335원만 운영 비용이 나오게 됐습니다. <br/>
다만 이용자 수가 많아진다면, 제가 생각하지 못한 비용이 나오게 되어 예상을 넘어가게 되면 또는 더 나은 아키텍쳐가 생기면 <br/>
언제든지 아키텍쳐는 수정되어야 한다고 생각합니다. <br/>
</p>
<p style="font-family: 'Pretendard-Regular';">
Front:
</p>
</p>
</div>
Expand Down

0 comments on commit 945b4ae

Please sign in to comment.