백엔드 챌린지 1회차
scaling을 고려한 서비스 아키텍처
Agenda
1.
2.
3.
4.
5.
6.
7.
좋은 아키텍처란?
Monolithic server
RDS scaling
EC2 scaling
Cache
CDN
Serverless
좋은 아키텍처란?
1.
서비스 운영 방식에 적합한 아키텍처
a.
b.
2.
개발자가 생각하기에 “이거 무조건 해야돼요"
사용자가 서비스를 사용하는데 bottleneck이 발생하지 않는 아키텍처
일반적인 케이스 소개
a.
b.
c.
엔지니어링 관점에서 이런 것들을 고려해야 서비스를 안정적으로 운영할 수 있음
케이스에 따라 그렇지 않은 경우도 많음
초기단계에서 굳이 auto scaling을 해야하는지
서버가 하나일 때
-
api.server.com으로 요청을 보낸다면?
api.server.com
1.2.3.4
1.2.3.4
read / write / update
data
response
DNS
AWS용어로 보자면?
-
api.server.com으로 요청을 보낸다면?
api.server.com
1.2.3.4
Route 53
1.2.3.4
response
read / write / update
data
EC2
Route53
1.
DNS 서비스
a.
도메인 구입 및 관리
Route53
1.
DNS 서비스
a.
도메인 구입 및 관리
도메인 Routing Policy
1.
2.
3.
4.
5.
6.
NS - 네임서버
SOA - Start of Authority
TXT - text
A - Address
CNAME - Canonical Name
MX - Mail Exchange
scaling을 고려한 데이터베이스 선택
1.
서비스를 처음 만들 때
a.
b.
c.
d.
2.
관계형 데이터베이스로 많이 시작
역사(?) 가 좀 더 오래되기도 했고
많은 시니어들이 대부분 관계형 데이터베이스에 (최적화)경험이 더 많음
무료
그런데 서비스 규모가 커진다면?
a.
b.
c.
Join이 많이 발생하면 관계형데이터베이스는 느려짐
데이터양이 많아지면 더 느려짐
이런 경우 NoSQL 도입을 고려하게 됨
i. AWS는 대부분 DynamoDB
ii. 물론 서비스 특성에 따라 NoSQL로 시작할 수도 있음
iii. Meta의 `Thread`
scale up vs scale out.
장단점을 비교하자면?
scale up vs scale out
1.
비용 비교
scale up vs scale out
1.
large vs xlarge
RDS Scale Out - READ Replica
1.
2.
READ 만 가능한 복제본을 만드는 것
서버로 동시에 여러 클라이언트가 요청을 보내면
a.
b.
3.
서버는 여러 데이터베이스에 READ query를 날릴 수 있음
요청이 몰려서 데이터베이스가 느려지거나 터지는 것을 방지할 수 있음
Write는 replicate 하지 않음
a.
b.
c.
Write가 여러 instance에서 발생하면 데이터 복제가 복잡해짐
write는 하나만 할 수 있고, read는 복제된 데이터를 여러곳에서 가져올 수 있도록
Multi-Write를 바탕으로 구현된 데이터베이스도 있음
i. 서비스 특성에 따라 다름
RDS Scale Out - READ Replica
write
read
replicate
read
read
RDS Scale Out - Connection Pooling
1.
2.
connection을 미리 여러개 생성해두고 활용하는 방식
AWS RDS Proxy 사용 가능
a.
b.
c.
3.
Idle timeout,
Max connection
Subnet
connection pool은 AWS RDS보다 어플리케이션 단에서 처리하는 것이 일반적
a.
b.
비용문제
개발자가 코드로 관리하는 편이 유리한 것 같음
DynamoDB Scale out
1.
2.
3.
Partition key를 활용한 자동 partitioning
걱정할게 없음
Serverless - 비용 매우 저렴
a.
b.
개인프로젝트는 가급적 DynamoDB 추천
취준할 때 개인프로젝트 RDS 썼다가 서버비용 11만원…
scaling을 고려한 서버 선택
1.
EC2도 RDS와 유사하게 scale up / out 가능
a.
b.
2.
Scale up 은 RDS와 유사하게 더 큰 사이즈의 인스턴스를 선택
Scale out은 Load Balancer가 필요
Load Balancer
a.
b.
단어 그대로 load를 balance하는 역할
클라이언트는 로드밸런서로 요청을 보내고, 로드밸런서가 요청을 서버로 분산
Load Balancer
EC2
ELB
EC2
EC2
Route 53
Load Balancer
1.
2.
3.
4.
load를 분산하는 역할
EC2 instance health check
SSL 인증서 적용
High availability
ALB, NLB
1.
2.
3.
4.
CLB도 있는데 이제 안씀
ALB - HTTP, HTTPS, WebSocket
NLB - TCP, TLS, UDP
EC2는 주로 ALB와 같이 사용됨
write
Load Balancer
ELB
read
Route 53
replicate
EC2
Load Balancer
ELB
DynamoDB
Route 53
Cache
1.
Database Cache
a.
b.
2.
하지만 cache를 사용하는 것도 비용
a.
b.
c.
3.
Read가 빈번한 경우 cache에 저장
데이터베이스까지 가지 않고 데이터를 가져올 수 있음
i. 속도에서 이점이 있다
Cache instance 비용
개발 유지보수 비용
latency를 줄이는것이 서비스 운영에 얼마나 중요한지를 고려해야함
업데이트 주기도 고려해야함
a.
b.
c.
DB는 업데이트 됐는데, Cache는 예전 데이터를 가지고 있다면?
Expiration 정책을 활용하거나, sync를 자주 해줘야함
하지만 이것은 서비스 운영 방식에 따라 다름
AWS Cache
1.
2.
ElasticCache
AWS DynamoDB Accelerator
a.
3.
DynamoDB에 붙어서 READ 10배 빠름
CloudFront - CDN
Cache
write
ELB
Route 53
read
Elastic Cache
CDN
1.
Content Delivery Network
a.
b.
static한 것들 빠르게 가져올 수 있도록
주로 이미지나 영상 이런것들
Amplify
CloudFront
AWS CloudFront
1.
다른 서비스들과 다르게 region이 Global
a.
2.
Edge Location활용
a.
b.
3.
Route53도 Global
AWS 자체적으로 데이터를 여러군데 흩뿌려둠
여러 data center에 caching해서 latency를 줄임
S3 연동 시 bucket policy 변경
a.
b.
CloudFront에서 접근할 수 있도록 설정해주어야 CDN활용 가능
CloudFront 생성 시 S3 연결하면, 복사할 수 있는 policy 제공
CloudFront
write
ELB
Route 53
read
Elastic Cache
그렇다면 보안은?
1.
Stateful
a.
b.
2.
상태를 기억하는 것
과거에 어떤 클라이언트가 요청을 보냈는지
Stateless
a.
b.
c.
d.
각각의 요청이 분리됨
모든 서버가 모든 클라이언트의 요청을 처리할 수 있음
로드밸런서 오버헤드 감소
Latency 감소
개인적으로 선호하는 방식
MSA가 아니라면 이렇게 해보세요
(사실 MSA도 가능)
Serverless?
1.
2.
서버가 없음 - AWS가 관리하기 때문에
Lambda 를 사용함
a.
b.
3.
4.
Application 서버 전체를 람다와 연결 가능
또는 간단한 기능 한두개 정도만 연결 가능
AWS가 자동으로 scaling
사용한 만큼만 비용 지불 - 저렴
Serverless
lambda
Route 53
Serverless
API Gateway
Route 53
lambda
DynamoDB