각 서비스에 맞는 아키텍처는 무엇일까? - 서버리스로 블로그 웹앱의 아키텍처를 설계해보자

원래는 앞서 세 가지 아키텍처를 먼저 다루고 다른 개념적인 부분들을 다시 다루려고 했는데

서버리스로 설계하는 방법도 정리하면 좋을 것 같아서

시리즈를 연장해보려고 한다!

 

#0 들어가기 앞서

여러 가지 서비스들을 정리해봤는데 이것들이 실제로 어떻게 연결되고 관리되는지도 조금 다뤄보는게 좋을 것 같아 올려본다..! 아키텍처에 관한 부분은 꼭 정답이라고 할 수는 없지만 여러 가지 사례를 통해 어떤 서비스들이 어떤 식으로 동작하는지에 대해 정리해본다면 많은 분들께도 도움이 될 것 같아 정리해보려고 한다.

+) ⚠️ 가장 기초적인 아키텍처 설계 예시이기 때문에 확장성을 고려해서 초반부터 서버리스 세팅을 할 수 있지만 일단 기초 자료로써 이 글을 다루려고 하니 실제 아키텍처 설계와 똑같이는 할 수 없다는 것을 먼저 언급하고 시작하겠다!

 

#1 사례 4️⃣) 서버리스로 호스팅 되는 블로그 웹사이트

<조건>

- 이 웹사이트는 글로벌 스케일 아웃이 가능하다.

- 보통 블로그는 작성하는 시간보다 읽는 빈도가 더 높을 것이다.

- 대부분 정적 파일로 구성되고 일부는 동적인 REST API로 구성될 것이다.

- 캐시를 적용해서 비용을 절감하고 응답 속도를 높여 좋은 UX를 제공하고 싶다.

- 블로그를 방문하는 사람에게 환영 이메일을 발송하고 싶다.

- 앞서 말했듯 서버리스로 구현하고 싶고 블로그에 업로드 되는 사진으로 썸네일이 생성되었으면 좋겠다. 

 

✳️ 초기

1) ✴️ - 전세계로 콘텐츠를 서빙하고 싶을 때

콘텐츠는 정적이고 글로벌을 대상으로 서빙해보기로 했으니 그렇게 설계를 시작해보겠다

클라이언트가 있고 우리의 콘텐츠는 S3에 저장되어 있다.

...

콘텐츠를 글로벌 대상으로 어떻게 노출시키고 어떻게 제공하면 좋을까?🧐

S3는 특정 region에 있는데 이걸 어떻게 노출시킬 수가 있냐면

전세계를 대상으로 서비스되는 CDN 서비스인 CloudFront를 이용하면 된다.

 

클라이언트는 CloudFront로 Edge Location(엣지 로케이션)과 통신을 하게 된다.

S3에게 받은 데이터를 캐시로 저장하게 되는 것!

 

그렇다면 여기에서 이 모든 작업을 안전하게 진행하려면 어떻게 할 수 있을까?

⬇️⬇️⬇️

2) ✴️ - 조금 더 안전하게 진행하고 싶을 때

이제 오리진 액세스를 제한해서 CloudFront로만 S3에 접근할 수 있게 하면 되는데

이걸 위해서 CloudFront만 인가할 수 있도록 버킷 정책(Bucket policy)를 추가한다.

(S3에 바로 접근하는 사용자는 인가를 받지 못한 상태이므로 접근이 불가하니 S3로 보호되는 구조)

...

여기에다 Public Serverless REST API는 어떻게 추가할까?

⬇️⬇️⬇️

✳️ 중반

3) ✴️ - 서버리스 REST API 추가해보기

REST HTTPS로 API Gateway와 통신하고 Gateway는 Lambda함수를 호출하고

Lambda함수는 DynamoDB에 쿼리를 날리고 읽기가 많이 발생하니

DAX를 캐시 레이어로 쓸 수도 있다.

 

+)

추가로 글로벌로 서빙할 때 region에 따라 발생하는 지연을 줄이기 위해서

DynamoDB의 글로벌 데이터베이스를 사용하는 것도 나쁘지 않는 방법같다.

 

✳️ 후반

4) ✴️ - 첫 가입자에게 환영 이메일 보내기

환영 이메일까지 보내보고 싶을 때 이런 방식으로도 가능하다는 것을 보여주고 싶다.

이걸 위해서 DynamoDB에서 변경사항을 전송하기 위해서 DynamoDB stream을 이용하고 stream은 Lambda함수를 호출한다.

여기에서의 Lambda함수는 좀 특별하게 IAM role을 부여 받아서 SES(Simple Email Service - 이메일을 발송해주는 서비스)를 사용할 수 있게 해준다.

=> 이렇게 하면 서버리스로 환영 이메일 전송 기능을 구현할 수 있고 관리할 인프라도 없고 서버리스라 확장도 잘 된다👍

 

5) ✴️ - 이미지를 업로드하면 썸네일이 생기도록 해보기

요구사항 중에 이지를 업로드하면 썸네일로 생성될 수도 있게 하고 싶다고 있었는데

그 아키텍처를 설명해보려고 한다.

클라이언트에서 S3 버킷으로 바로 업로드를 할 수도 있고 아니면 CloudFront OAI를 이용할 수도 있다.

이 방식이라면 클라이언트는 사진을 CloudFront에 업로드하고 CloudFront는 사진을 S3 버킷으로 전달하게 된다.

=> 이런 방식을 S3 Transfer Acceleration이라고 한다.

 

사진은 바로 S3에 올리거나 S3 Transfer Acceleration을 이용하거나 둘 중 하나이고 S3에 파일을 추가되면 Lambda함수를 호출할 수 있고 Lambda는 썸네일을 생성하고 썸네일을 S3 버킷에 넣는데 다른 버킷에 넣을 수도 있다.

 

+) 추가로 S3는 SQS와 SNS를 호출할 수도 있다. 이거는 오로지 선택사항인데 둘 중 원하는 작업을 하면 되고 원하는 작업대로 구성할 수 있다는걸 언급하는 것이다.

S3는 Lambda, SQS, SNS를 호출할 수도 있고 솔루션을 자유롭게 구성할 수도 있으며 서버리스로 구성할 수도 있고 글로벌하게 확장도 가능하게 할 수 있는데 원하는 방향에 따라 나중에 확장성을 고려하면서 초기설계를 진중히 고려해보는 것도 좋은 방법이다!

아키텍처 설계에 대한 정리는 이 정도이고

다음에 시간이 되면 다양한 아키텍처에 대한 설계를 더 다뤄보려고 한다😀😀