AWS SQS, AWS MSK, AWS Kinesis, AWS RDS, AWS DynamoDB, AWS ElastiCache

이 글은 
2022년 12월 7일 ~ 2022년 12월 18일 에 원티드에서 프리온보딩 백엔드 챌린지에 참가하여 들은 강의를 정리한 것입니다.

 

 

 

---

 

AWS RDS

relational database service

 

aws를 사용하면 무조건적으로 쓸 수 밖에 없는 데이터 베이스.

db를 운영하고 관리할 수 있도록 한 편한 서비스.

Nosql을 위한 aws 서비스는 따로 있다.

 

보통 db를 운영한다고 하면, db는 보통은 서비스에서 제일 문제가 많이 일어난다고 봐도 될 정도로 관리가 까다롭다.

서버는 잘 안터짐. 서버는 쉽게 늘리고 줄일 수 있기 때문에.

 

rds는 관리하기가 까다로움. 기본적으로 ec2 처럼 오토 스케일링이 안됨. 직접적으로 운영해줘야 함.

수평적 확장, 수직적 확장이 있는데,

• 수평적 확장 : 서버가 3대가 있는데, 3대가 다 cpu 90퍼 있으면 수평적으로 늘려줌.
• 수직적 확장 : 서버의 사양을 늘려주는 개념. 코어 하나에 메모리 16기가 짜리를 쓰고 있는데, 코어 2개 짜리에 메모리 32기가로 늘리는 개념. 따로 인스턴스를 켜는게 아니라 기존에 있던 서버에 늘리는 방식.

 

rds는 수직적 확장을 염두에 두고 운영해야 한다.

 

주요기능

• 장애가 났을 때, 스냅샷을 찍어 둘 수 있는 기능. 자동백업 = 기간을 설정해서 자동으로 백업이 되게 끔. db에 있는 모든 데이터를 본 뜨겠다 = 스냅샷.
• 멀티 AZ : availability zone : db가 손상이 되면 , 한번에 망가지는 걸 방지하기 위해 여러 곳에 멀티로 동기화 시켜 놓는 것.
• cloudWatch 연동 : aws 자체 기능이라 생각하면 더욱 좋음. db 인스턴스의 모니터링. 로그.

 

 

오로라도 rds 안에 포함이 되는데, 그림에서는 일단 오로라에 대해서 배제하고 설명.

rds만 보자면,

총 5개의 db에 대해 지원한다.

1. mysql
2. postgre sql
3. mariadb
4. microsoft sql
5. oracle

 

---

AWS Aurora

aws가 자기만의 기술로 만든 새로운 형태의 db

rds가 커피라면, aurora는 T.O.P. (티오피) ㅎㅎ

 

어떻게 튜닝을 했느냐?

• 가장 눈에 보이는 점은 : ssd 드라이브 위에 구축되어 훨씬 빠르다.

r6g, 2xlarge : 많이 쓰는 인스턴스

 

• 오토 스케일링을 기본적으로 지원함 : 이용량이 많아질 때 굳. 이용자가 없으면 인스턴스를 줄이는 형식의 기능 지원.
• 서버리스 기능 지원 : 일반 rds에서는 지원하지 않는 기능.
  • serverless db : 항상 켜져있지 않은 db, 요청만 처리하고, 인스턴스는 aws측에서 관리해줌.
  • 프로덕션 db에는 이용자들이 많고, 항상 standby 되어 있는 db가 필요함. 일반 프로덕션 환경에서는 서버리스 기능 없는 아마존 오로라를 쓰고, 테스트용 db는 인스턴스 다 올려서 사용하면 많이 안쓰니까(사내에서만 쓰니까) 서버리스 오로라 디비 사용함.
  • serverless는 기본적으로 약간은 느리다. 일반 오로라 디비가 100ms면, serverless는 더 감..
  • serverless 아닌 db가 더 빠르다.

 

---

Aurora vs RDS

 

 

예를 들어, 채팅 시스템은 rds 부적합 : 싱크가 되지만 속도가 느림.

 

 

오로라는 data가 ssd에 저장되기 때문에 거의 모든게 realtime으로 보장이 되고, 대역폭(db에 쓰기 작업과 읽기 작업을 많이 하면, 어느 순간부터 대역폭에 문제가 생긴다. → 서버가 죽기도 함. 처리할 수 있는 양이 rds 에 비해 훨씬 높을 수 밖에 없다)

 

 

 

일반 db와 오로라 db의 대역폭 비교 사진.

오로라는 20만 , 그냥 mysql 은 1만

한 번에 처리할 수 있는 양이 다름.

예전에는 오로라 db를 많이 안썼지만, 요즘은 오로라 db 많이 쓰려고 한다고 함.

서버리스 기능이 원래는 베타였는데 금년부터 정식 출시가 되서 많이 사용하는 추세다.

 

 

---

 

AWS DynamoDB

NoSQL 데이터 베이스(key, value)로 이뤄져 있는.

기본적으로 serverless임.

 

따로 유지비용 없이 사용한 만큼만 지불한다.

• noSQL 특성상 인덱싱이 없으면 속도가 느려지는데 dynamoDB는 그 부분 해결해줌.

ex)

key: userName
Value: {
		Address: “”,
		Age: “”,
		Job: “”
}

보조 인덱스 지원으로 age를 다시 key, value로 지원해 줌.

 

최대 장점 : lambda(서버리스) 서버와의 궁합이 매우 좋음.

보통은 서버만 켜놓고 , 서버 → db로 가는 구조 : connection이 1개 람다는 connection이 여러개 → db 부하가 많이 걸릴 수 있음 람다가 5개면 rds와 커넥션 5개를 맺음. 람다가 200개면 rds와 커넥션 200개를 맺어야 하는데, 못맺음 dynamoDB는 http를 통해 connection을 주고 받기 때문에, connection자체가 필요없어서 영향을 안주기 때문에 서버와 궁합이 좋다고 하는 것임.

 

 

---

 

AWS Elasticache

 

redis의 개념과 좀 더 가깝다.

세션 스토어 : 인증/ 로그인 관련 된 것들을 저장함. 세션 스토어로 user 관리하는 회사들 많음.

AI ML 모델을 redis에 올려서 사용.

실시간성이 높은 작업들 : 채팅 등

 

redis = elasticache 99퍼 똑같다고 생각하면 됨.

 

 

 

---

 

Queue

인프라에서 핵심적인 역할.

kafka가 큐임. 중심적 역할.

 

대표적으로 많이 쓰이는 Queue 두 가지.

 

1. AWS SQS

Simple Queue Service

아마존에서 운영하는 kafka service

큐를 두 가지 옵션으로 분리

• 표준 대기열
  • 무제한 처리량을 가지고 있다. (한계가 없는 큐 서비스)
  • sqs의 표준 대기열은 최소한 한 번 전달한다. : 여러번 전달 될 수도 있다는 소리. 꼭 한번만 도착해야 하는 서비스(예를 들면 돈 입금)는 표준 대기열을 사용하면 안됨.
  • 최선 노력 순서 : 순서를 맞춰주진 않지만 순서를 보장하지 않음.
  • 순서가 꼭 지켜져야 하는 서비스 : 은행 : 내 잔고가 만원인데, 입금 순서가 지켜져야 할 때.
  • 사용 예시 ) 사용자 로그 찍을 때. → 순서 안지켜도 되니까.
• FIFO 대기열
  • First In First Out : 선입선출
  • 순서대로 정확히 한 번씩만 처리 됨.
  • 한 번에 처리할 수 있는 메세지가 적음.
  • 일반적 상황에서는 초당 300개 이상의 메세지가 오는 경우가 많기 때문에. 이 경우는 fifo를 사용할 수 없다.

이메일 같이 코드를 전송 또는 뉴스레터도 마찬가지로 큐에 넣고 하나씩 빼서 사용할 때. sqs 중에서도 fifo 사용. 뉴스레터 두 번 가면 안되니까.

• 장점 : Dead Letter Queue를 지원함. 람다가 죽거나, 큐에서 제대로 전달이 안되었을 때, 메세지가 보내지다 말았을 때, DLQ(Dead Letter Queue)가 다시 저장해서 다시 람다 실행해서 정상적으로 메세지가 보내질 때까지 최대 시도 횟수도 정할 수가 있음.
• 비번 찾기에서 이메일 안올 때, 람다에서 죽은 것. 정보 유실 : SQS는 메세지 하나하나에 대한 개별적 관리를 위해서 DLQ 쓰는 거 권장함

 

---

2. AWS Kinesis

데이터 하나하나의 중요도 보다, 대용량 데이터를 다룰 때 중요한 요소.

쏘카는 kafka사용.

kinesis는 kafka와 비슷한 기능을 가지고 있음.

 

• 모든 규모의 스트리밍 데이터를 비용 효율적으로 처리할 수 있음.
• 사용예시 ) 실시간 비디오 및 데이터 스트림을 손쉽게 수집, 처리, 분석
• 데이터 중에서도 유저 액션 활동들 따라다녀야 할 때 사용.

 

임의적으로 shard로 분리. 어떤 shard로 들어갈지 정할 수 있음.

shard : 한번에 엄청많은 데이터가 들어왔을 때 어떻게 효과적으로 처리할까 고민해서 나오게 된 개념.

 

SQS는 shard라는 개념 없음.

 

 

---