사용자수에 따른 AWS 아키텍처 설계하기

AWS의 Scalable한 서비스들을 효율적으로 사용하기 위해서는,

사용자수에 맞추어서 아키텍처를 효율적으로 설계할 필요가 있는데요.

늘어나는 사용자수에 따라서 어떻게 설계해야 할지 정리해 보도록 하겠습니다.

 

다만 여기서 정리하는 아키텍처는 절대적인 정답이 아니므로,

서비스의 특징에 따라서 변경해서 설계해야 겠지요.

 

1. 100명 이상의 사용자

아주 초기의 아키텍처가 되겠네요.

100~999명 정도의 사용자를 가지고 있다면, 아래 정도의 솔루션이면 될 것 같은데요.

아직까지는 웹앱이 들어가 있는 EC2서버와 RDS가 있으면 충분합니다.

서버가 한 대이므로, 아래 이미지와 같이 Elastic IP를 이용한 고정 IP주소와 Route53을 연결해 주어도 되고,

단순한 App Server라면, IP주소로 연결해도 문제가 될 것은 없습니다.

 

다만, 향후 IP주소를 유연하게 변경하기 위해서는,

되도록 Name서버를 통해 도메인 네임으로 접속되는 것이 좋으므로,

앞단에 Route53을 두는 것이 좋습니다.

 

 

 

1-1. EC2 Instance 서버의 선택

보통 스타트업에서 작은 규모로 앱을 론칭해 본다고 하면,

T2.medium 혹은 C5.Large 타입 정도의 2CPU에 4GB Ram용량의 CPU를 사용하게 될 것 같은데요.

 

성향에 따라 다르겠지만, T2 타입의 경우, 높은 CPU 사용률이 필요한 경우 시간당 5센트가 추가적으로 붙게 되는데요.

사용하는 Web프레임워크의 처리 특성에 따라서 특정 Event에 CPU점유율이 급하게 올라가는 일이 발생할 수 있으므로,

이에 대한 주의가 필요한 부분이 있습니다.

 

비용부담이 없다면, 같은 범용이면서 T2.medium과 가격차이가 크지 않은 A1.Large(2Cpu, 4GB Ram)

나 좀 더 사양이 좋은 M4.Large(2Cpu, 4GB Ram), M5.Large(2Cpu, 8GB Ram) 그리고

컴퓨팅에 최적화된 C5.Large(2Cpu, 4GB Ram)등이 있으니,

EC2의 사양에 대해서 알아보고 비용을 생각하면서 결정하는 것이 좋을 것 같습니다.

 

EC2의 타입에 관한 구체적인 사항에 대해서는 아래 공식문서를 참조해 주세요.

https://aws.amazon.com/ko/ec2/instance-types/

 

1-2. DB 서버의 선택

A. AWS의 RDS 또는 DynomoDB

RDS를 선택할 때, 서버를 선택하게 되는데요.

보통 Free Tier로 사용해 보는 서버가 t2.micro(1Cpu, 1GB Ram)인데요.

위에서 언급한 EC2정도의 사양과 비슷하게 선택한다고 가정할 때,

Aurora MySQL Compatible로 선택한다면,

EC2와 비슷한 정도의 db.r5.large(2CPU, 16GB Ram) 사양정도면 될 것 같습니다.

r5.large가 211달러 정도가 한달금액으로 나오므로

비슷한 a1.Large(2Cpu, 4GB Ram)인 EC2가 40달러 정도이므로 거의 5배 정도가 나오네요.

물론 비싼 금액 만큼 백업 기능 및 Replication등 많은 기능을 제공해 주기 때문에 사용하는 것이긴 하지만 말이지요.

 

참고로, 사용하던 관성 때문에, RDS에서 MySQL을 많이 선택을 하게 되는데요.

Aurora DB가 MySQL과 호환되면서도 MySQL보다 5배 많은 처리량(AWS의 홍보 사이트 기준)

을 보여준다고 하니,

 

유료사용시에는 괜찮은 선택이 될 것 같습니다.

다만, 처음 사양을 선택할 때 너무 걱정할 필요는 없을 것 같습니다.

재부팅이 필요하기는 하지만, 언제든 변경할 수 있는 것이니까요.

 

 

B. EC2에 직접 DB사용 또는 다른 서비스 사용

또한 RDS가 아니라, EC2에 DB를 직접 설치하고, 백업등도 직접하는 방식도 있을 것 같습니다.

경량서비스의 경우, M4.Large서버 1대 정도의 사양으로도 EC2에 WebServer에 MySQL까지 돌렸다는 글도 보았는데요.

하지만 데이터베이스를 관리하는 것은 정말로 중요하면서도 어려운 일이구요.

이것을 AWS에 지불하는 비용으로 관리한다고 생각하면 훨씬 저렴하므로,

RDS를 구매해서 AWS서비스를 이용하는 것이 시간을 사는 것이라고 할 수 있을 것 같아요.

 

또한 DynamoDB라는 AWS의 NoSQL서버도 사용대상이 될 수 있는데요.

이런 NoSQL서비스의 경우 사용량당 요금이 청구되는 것은 좋은 것 같지만,

반대로 얼마나 나오게 될지 예상할 수 없어서,

사용자가 접속한 만큼 돈을 벌지 못하는 서비스라면, 고민이 조금 되게 됩니다.

연간 데이터 사용량이 몇TB정도가 되었을 때 고려해 봐도 될 것 같습니다.

 

B. MongoDB 등 다른 DB서비스

MongoDB Atlas같은 서비스를 이용할 수도 있는데요.

접속 IP를 Whitelist처리할 수도 있긴 하지만, 어쨌든 DB에 외부 Endpoint가 생겨야만 하는 것 이 어서,

보안적인 부분에 대해서는 고려를 해 봐야할 것 같습니다.

 

1-3. CloudWatch

규모가 작을수록 모니터링은 필수입니다.

수시로 CloudWatch를 통해서 로그들을 확인해 주고, 알람도 맞춰주어야 합니다.

AWS라는 것이 서비스당 하나의 서버를 배분하는 것이 아니라,

VM으로서 나누어 사용하는 것이기 때문에,

같이 사용되는 다른 사용자가 어떤 문제를 일으키고 있는지 모를 일이기 때문입니다.

물론 그런 경우는 많지 않겠지만 말이지요.

 

2. 1000명이상의 사용자에 대한 아키텍처

사용자가 1,000 ~ 9,999명 정도가 되면, 이제는 부하 분산을 생각할 때 인데요.

Route53과 부하를 분산해주는 ELB를 앞단에 둡니다.

ELB에 EC2인스턴스를 등록하는 것에는 고정ip가 필요하지 않으므로,

ElasticIP도 필요하지 않습니다.

 

물론, Elastic IP와 ELB를 연결해서,

마찬가지로 고정된 IP주소를 통해 App Server를 운영할 수도 있습니다.

다만, 위에서 언급한 것 처럼, 고정된 IP주소를 사용함으로서,

유연하게 내부 IP주소를 변경하기 힘들다는 단점이 있을 수 있습니다.

어쨌던 App Server는 사용자가 직접 URL을 입력하지는 않으므로,

이런 방법을 쓸 수도 있기는 하겠습니다.

Route53이 Query수 100만번당 과금하기는 하지만, 비용이 아에 없는 것은 아니기 때문이지요.

 

이제 이정도 사용자가 되었다면,

만약을 대비해서 아래의 이미지의 우측 하단의 StandBy 상태의 인스턴스처럼,

Multi-zone옵션을 사용해서 하나의 존에 있는 RDB서버에 문제가 있으면, 다른존의 서버를 사용할 수 있도록 해 주는 것도 생각해 볼 수 있습니다.

대신 비용이 추가된다는 사실을 잊으면 않되겠지요.

 

 

 

3. 10,000명 이상의 사용자에 대비한 Architecture

3-1. RDS서버의 Replication

크게 달라진 것은 없습니다. 다만, EC2 Instance들이 많이 늘어난 것 뿐이지요.

한가지 중요하게 추가된 것은 DB서버를 운영하는데 있어서,

Replication을 구현한 것 인데요.

쓰기 전용서버와 읽기 전용 서버를 구분하고,

AWS의 RDS를 사용하면 쓸 수 있는 Real Replica기능을 붙여서,

Master와 Slave서버를 통해 Scale되도록 해 줍니다.

 

 

3-2. Static 애셋의 부하 분산

Static한 애셋을 저장하는데 유용한 S3를 활용해서 부하를 더 분산시킬 수 있습니다.

여기에 Cloud  Front를 이용해서,

아예 Static한 애셋이 Route53을 경유해서 바로 Cloud Front -> S3로 향할 수 있도록 설계해 줍니다.

CloudFront는 CloudFlare와 같은 Amazon의 CDN서비스인데요.

유저와 가까운 지역의 서버에게 데이터를 전달하게 함으로서, 속도와 효율을 높이는 것 이지요.

 

 

 

3-3. Elastic Cache의 사용

Redis를 지원하는 AWS의 Elasticache를 이용하면 더욱 부하를 분산할 수 있는데요.

이 서비스는 메모리에 Cache를 저장했다가 사용자에게 전송하므로,

빠르게 처리를 해 줄수 있습니다.

사용자의 세션이나 상태등에 대해서, Elastic Cache를 사용해서 부하를 분산해 주거나,

No-SQL인 DynamoDB로도 부하를 분산시킬 수 있습니다.

사용자가 많아질수록 캐쉬가 매우 중요해 지는 것 이지요.

 

이 이상의 사용자수에 따른 아키텍처가 필요한 정도라면,

서버 혹은 AWS 담당 엔지니어들이 필요할 것 같은데요.

 

100명 유저의 작은 규모로 개발을 시작해서,

향후 어떤 아키텍처로 이동해 갈 것인지의 큰 그림을 생각하는데는,

이 글에서 다루는 정도까지만 알아도 충분할 것 같습니다.

 

4. DDOS 공격등 유효하지 않은 트래픽에 대한 팁

4-1. 노출되는 EndPoint 최소화

Back End서버들이 subnet에 노출되지 않도록 하는등

노출되는 엔드 포인트들을 최소화 해야 하는데요.

 

4-2. CDN서비스 도입

위에서 다루었던 CloudFront같은 CDN서비스를 좀 더 일찍 적용시키고,

Origin서버의 URL이나 IP를 숨기도록 해 줍니다.

물론 비용이 추가적으로 발생하는 부분이 있다는 것이 단점이겠지요.

굳이 합리화 시키자면, 보안 담당자를 구인하는 것보다는,

AWS서비스를 돈주고 사서 Deploy시킬 수 있다는 것이겠네요.

 

 

4-3. 정상적인 사용패턴 파악

평상시의 정상적 사용자의 트래픽 패턴에 대해서 파악해 놓고,

비정상적 트래픽 발생시에 이에 대응할 수 있도록 해야 합니다.

대응할 수 없는 수준의 문제가 발생할 것을 대비해서,

AWS의 Support에 대해서 미리 알아놓고,

문제가 생길 때, 빠르게 연락하도록 해야합니다.

 

4-4. AWS의 VPC서비스를 사용한 사설망의 구성

Amazon Virtual Private Cloud를 이용해서 사설망을 구축할 수 있는데요.

비용이 서비스에서 감당할 수 있는 정도라면,

보안을 위해 이런 서비스도 생각해 볼 수 있을 것 같습니다.

 

5. 정리

이상으로 사용자수에 따른 AWS아키텍처에 대해서 정리해 보았습니다.

참고로, 아키텍처를 그려보기 위한 툴들이나 사용할 아이콘들을 AWS에서 제공해 주고 있는데요.

아래 사이트에서 참고할 수 있습니다.

https://aws.amazon.com/ko/architecture/icons/

 

더 좋은 정보가 있다면, 이 글을 통해서 업데이트 하도록 하겠습니다.