AWS re:Invent 2022 세션 후기 #47 – 아키텍쳐

BLOG

작성일: 2022-12-05

[STP211-R] Scaling on AWS for your first 10 million users

연사 : Chris Munns, Tech Lead/Advisor – AWS Startups, Amazon Web Services

Carole Suarez, Solutions Architect, AWS

일시: 2022.11.30 16:00 PM – 17:00 PM

장소: Level 1 North, South Pacific F, Mandalay Bay

작성자 : 메가존클라우드 Strategic Tech Center 황기욱 매니저

비즈니스 초기 AWS 인프라에서 급속한 성장에 대응할 수 있는 능력을 구축하기 위한 성공적인 패턴과 기술에 대해 설명하는 세션입니다. 확장성이 뛰어난 AWS 서비스 구현에서 입증된 패턴 설계에 이르기까지 일반적인 인프라 문제를 극복할 수 있는 아키텍처에 대한 사례를 소개했습니다.

사용자가 적은 기본적인 구조에서 10만, 100만 이용자를 수용하는 수준, 그를 뛰어넘는 대량 서비스에 이르기까지 어떻게 서비스를 확장하고 구조화 하는지 소개하고자 합니다.

“app” 에 대한 정의를 시스템 관점에서 단순화 해보면 frontend + backend + data storage 으로 분류할 수 있습니다.

사용자가 소수인 최소 서비스 아키텍쳐는 아래와 같이 presentation, business, data로 고전적으로 사용해 왔습니다.

그러나 최근에는 frontend framework의 유행에 따라 host-based와 같은 전형적인 구성은 선호되지 않고 있습니다.

modern frontend 개발방식을 사용하는 이유는 아래와 같습니다.

1) 운영비용 오버헤드 감소

2) scale/성능이 우수

3) modern frontend 기술들에 대한 적용 가능

Amplify Hosting에서는 repository에서 코드를 관리하고, build하고, deploy까지 파이프 라인으로 처리합니다.

Amplify Hosting의 장점 및 특성은 아래의 그림과 같습니다.

computing 자원으로 고전적인 host가 아닌, EC2, ECS/EKS, AWS Lambda등 다양한 선택이 가능해졌습니다.

고전적인 인스턴스 기반의 backend 구성은 여전히 유용한 방식이나 아래의 그림과 같은 disadvantage를 가지고 있습니다.

위와 같은 과제를 극복하기 위해 AWS의 managed service 사용을 권장하고 있습니다.

상기 이미지와 같이 AWS managed service를 사용하여 장점을 극대화 할 수 있습니다.

business logic API로 활용할 수 있는 3가지 옵션입니다.

AWS App Runner로 build, deploy 및 container 기반의 웹 애플리케이션을 관리 운영할 수 있고, 관리 포인트의 오버헤드를 줄여줍니다. 또한 모든 API를 지원할 뿐 아니라 유행하는 모든 랭귀지도 지원하는 최적의 managed 서비스입니다.

이렇게 만들어진 modern style의 frontend & backend 아키텍처가 위와 같습니다.

이제 데이터베이스만 결정하면 되는데 일반적으로 가장 많이 사용되고 레퍼런스도 많은 SQL 을 고려하게 됩니다.

하지만 서비스 초기부터 대량의 데이터를 관리할 필요가 있는가?의 질문에 대한 대답은 No 입니다. 다시 말해 SQL이 아닌 NoSQL도 충분한 대안이 될 수 있습니다.

그 밖에도 NoSQL 도입을 고려할 만한 요소는 아래와 같습니다.

1) 응답시간 지연이 없는 어플리케이션

2) meta-data에 기반하는 데이타 유형

3) 비관계형 데이터

4) 스키마가 필요없는 유연한 데이터

5) 입력이 빈번한 데이터

SQL 로서 Amazon Aurora는 뛰어난 성능과 관리편의성, 강력한 보안으로 빠르게 성장해 왔습니다.

ondemand 서비스로 Aurora Serverless v2를 소개합니다.

최종적으로 위의 그림과 같은 modern style 아키텍처로 구성되었습니다.

10000 user가 넘으면 어떤 문제가 발생할까요? 다양한 서비스 추가로 복잡도가 증가하고 성능은 저하될 것이며 데이터도 많이 쌓이게 됩니다.

Frontend 영역의 scalability 확장은 cloudfront를 고려해 보게 됩니다. global 서비스를 지원하고 backend 호출을 줄이고 caching 으로 응답속도를 높여줄 수 있게 됩니다.

서비스 모니터링으로는 cloudwatch, x-ray를 추천하며, Machine Learning (ML) 이 효율적으로 도움이 될 것이라 생각 됩니다.

scale 확장을 위한 튜닝포인트를 찾아낼 수 있는데, 만약 데이터 베이스 확장이 필요하다면 Aurora Severless v2:scaling 은 cpu와 memory, storage 로 서비스 운영에 영향이 없이 확장이 매우 용이합니다.

scaleup 뿐만 아니라 최대 15대까지 read replica 확장이 가능하고 multi-AZ에 안정적인 확장과 운영이 가능하게 됩니다. 또한 Amazone RDS Proxy로 scaling, failover, db access contol기능까지 제공한다.

이렇게 구성한 DB scale 확장된 모습은 위와 같습니다.

RDS 데이터 뿐 아니라 cache data가 필요한 경우, Redis나 ElastiCache가 필요합니다.

cache까지 추가된 data tier의 구성도입니다.

완성된 data tier의 확장된 아키텍처입니다.

backend api로서의 AppRunner 의 scale up은 내부적으로는 아래와 같이 ECS fargate 단위로 자원이 할당되어 scale out이 유연하게 지원됩니다. request가 없어지면 idle 상태로 자동 scale in 되어 provision한 min 사이즈 유지하여 비용을 효과적으로 절감할 수 있게 됩니다.

이제 이용자 수가 100만이 넘었다면 지금까지의 아키텍쳐로 처리가 가능할까요? App Runner도 증대할 필요가 있으며 DB에도 많은 bottleneck이 예상됩니다. 서비스 복잡도도 증가하고 미래 성장을 위해 인프라 스트럭쳐의 변경도 고민이 필요한 시기가 될 것이라 생각 됩니다.