졸업 프로젝트로 이전에 진행하던 프로젝트의 아키텍처 개선 및 서버리스 기반으로 개선하고자 한다.
때문에 정리 할 겸 해당 게시물을 작성해본다.

단시간내에 설계를 해야하기 때문에 제일 중점적으로 참고한 자료는 석찬님의
https://www.youtube.com/watch?v=RkB1OtJR1ag

해당 영상 정리는 다음과 같다.

영상 정리

애플리케이션 배포 방식의 변화

과거)
과거 에는 온프레미스 기반 데이터 센터에서 mvc 구조의 프레임워크를 통해 프론트/백을 함께 만들어 클라이언트에 제공함.

최근에는 클라이언트에서 직접 구동하는 싱글 페이지 앱 기반의 프레임워크들이 인기를 끌면서 백엔드는 API 를 통해 JSON 을 생성해줌

클라우드 환경에서 풀스택 앱을 빠르게 개발할 수 있게 된것도 큰 변화중에 하나이다.

서버리스 기반 천만 사용자 아키텍쳐 (2023년)

처음부터 서버리스 컴퓨팅과 데이터베이스를 활용해서 가용성과 확장성을 별로 염려하지 않는 천만 사용자 아키텍처를 구성할 수 가 있다.

서버리스란? : 관리, 운영할 서버가 없다는 뜻으로 그 일의 대부분을 AWS가 담당하는것을 의미한다.

Users: >1

기존 방식

다만 이 방법은 인스턴스 중지시 모든 기능이 중지된다는 위험이 있다.

계란을 한바구니에 담지마라.

서버리스 기반을 이용한 방식

애플리케이션 구성 요소인 프론트, 백엔드, 데이터 스토어를 서버리스 기반으로 분산하여 배치한다.

Why ?

• 인프라 관리 부담없이 확장성 및 성능제공
• 영역별 개발 오버헤드 크게 감소
• 최신 개발 프레임워크와 통합 용이
• 일관된 개발자 경험기능 제공

서버리스 - 프론트엔드

• Amazon S3
  aws 에서 웹 호스팅을 하려고 할 때 가장 널리 알려진 S3 의 정적 웹 호스팅을 활용한다.

• AWS Amplify Hosting
  | 풀스택 앱을 만들기 위한 가장 빠른 방법
  정적 웹 호스팅과 아울러 글로벌, 자동 소스 변경 탐지 및 배포 기능등 다양한 기능 제공

Amplify Hosting - 싱글 페이지 앱(SPA) 배포

전 세계 410개가 넘는 콘텐츠 배포 지점을 가진 AWS Cloudfront 라는 CDN을 이용한다.
앱이 배포되면, 자동 생성된 HTTPS 기반 도메인으로 바로 서비스가 가능하고,
CI/CD 도 가능하다.
프론트 엔드 프레임워크에 따라 자동 감지된 빌드파일에 따라 자동 배포가 된다.
여튼 많은 기능이 있다. 일단 상세 구현방법이 필요한게 아니니 넘어간다.

서버리스 - 백엔드

(기존에 이용한 것)

EC2, 컨테이너 기반 배포 ECS/EKS , LB 를 사용해왔다.

(서버리스)

애플리케이션과 배포에만 집중할 수 있는

• Fargate : 서버리스 컨테이너
• AppRunner : Fargate를 기반으로 컨테이너 배포, 운영까지 손쉽게 해주는 서비스
• Lambda : 프로그램 코드만 실행할 때 구동된다.

AppRunner

App Runner 는 기존의 Fargate 작업을 넘어 LB , ECS 를 기반으로 만들어져 있기 때문에 이모든 기능들을 AWS 가 관리해준다.

제공방식

DB 는 어떤것을 택해야 할까?

• SQL
  ex) Aurora , RDS

• NoSQL
  ex ) DynamoDB, DocumentDB, Keyspaces

• Aurora Serverless

최종 USERS >1 아키텍처

USERS > 10000

해결해야 할 문제

이전 아키텍처는 확장성 및 고가용성이 확보된 아키텍처이나, 사용자 증가에 따른 한계가 존재한다.

WHY?

• 제품의 다양한 요구사항에 따른 애플리케이션 복잡성 증가
• 하나의 제품 영역에서 성능 문제가 생길 때 함께 문제가 생길 수 있다.
• db 테이블 크기/인덱스 증가로 인한 데이터베이스 쿼리 속도 저하

해결방법)

1. Amplify Hosting 성능 튜닝
2. App Runner 인스턴스 숫자 및 크기 조정

3. 애플리케이션 성능 모니터링

• CloudWatch
• X-Ray

4. Aurora Serverless v2 : 성능 튜닝

• 확장/축소 방식 ( 스케일 업 방식으로 cpu/메모리 자동 추가)

• Amazon Devops Guru for RDS 를 통해 DB 성능/운영 문제 탐지와 진단가능
  - CPU,I/O, SQL 질의등 DB 부하와 운영을 AI 가 판단하고 관리

• RDB 의 한계는 RDS Proxy 로도 해결 가능하다. ( DB 앞단에서 부하 처리 )

DB 병목 문제 해결 )

Users > 1,000,000

해결해야 할 문제

• 앱 복잡성/기능 증가로 인해 복잡한 비즈니스 로직이 지속적으로 추가됨
• 여러 팀이 개발 , 운영함에따라 서비스 개발 및 배포 속도가 느려짐
• 단일 서비스에서 App Runner 가 지원할 수 있는것보다 많은 확장 필요
• 여전히 RDB 에서 write/read 병목 현상 발생

해결방법?

MSA 를 도입한다.
규모가 커짐에 따라 MSA 로 리팩토링 하는것이 모든 계층에서 장기적 관점에 좋다.

• 큰 덩어리의 서비스를 잘 정의된 API 를 통해 통신하는 소규모의 독립적인 서비스로 구성
• 소규모 팀을 통해 각 서비스를 소유하여, 자율적인 개발 스택 선택 및 빠른 배포
• 의존성이 낮은 기능부터 차례로 제거

스트랭귤러 디자인 패턴

• 전체시스템은 정상적으로 돌아가면, 점진적으로 msa 기반으로 코드와 api 를 분리

서비스별 백엔드 분리

Amazon API GW

• 개발자가 api 를 손쉽게 생성, 게시, 유지관리, 모니터링 및 보안 유지할 수 있도록 하는 완전관리형 서비스
• 실시간 양방향 통신이 가능하도록 하느나 RESTful API 및 Websocker API 지원

AWS Lambda

• 간단한 프로그램 코드만으로 필요한 이벤트에 따라 코드를 실행할 수 있는 이벤트 중심 서버리스 컴퓨팅 서비스

• 동기화에서 비동기로 이동 및 큐, 토픽, 버스 및 스트림을 활용하여 이벤트 기반 아키텍처 구축
  

• 서비스별 DB 분리도 가능
  

서버리스 기반 천만 사용자 아키텍처

나의 프로젝트 아키텍쳐 개선

기존 아키텍처

서버리스로 변경해본 아키텍처

• 분리를 해야한다. 어떻게?
  내가 진행한 프로젝트는 여러 상황을 가정하지는 않고, 구매 api 만을 제작했었기에, 여러 상황을 가정해야한다.
  - 다양한 올리브영 제품 카탈로그를 저장하고, (runner), /view, documentDB
  - 구매하기(fargate), /buy , RDB Aurora Serverless
  - 현재 가격 정보를 볼 수 있게(lambda), /price , DynamoDB

근데, app runner 는 그렇게 기능이 많은데 카탈로그 저장 하나로만 괜찮을까 싶긴 하다.

사실 서버리스로 개선했다기보다 그냥 서버리스 아키텍처를 임의로 설계한거나 다름없긴 하다. ( 급하게 하다보니 당위성이나 필요성을 판단하지 못함)
추후에 조금 더 세밀한 부분을 신경써서 all 서버리스로 재설계 해야할 필요성을 느낀다.