【레포트】서버리스 기반 데이터베이스 모델링 및 운영 노하우 알아보기 #D2C5S1 #AWSSummitKorea

안녕하세요! 임채정입니다.

오늘은 5월 10일에서 12일까지 진행한 AWS Summit Online Korea 2021의 [서버리스 기반 데이터베이스 모델링 및 운영 노하우 알아보기] 세션에 대해 소개하겠습니다

해당 세션은 크게 두 개로 나눠서 진행했습니다 1. Amazon RDS Proxy와 Amazon Aurora 활용 방법 2. Amazon DynamoDB Single Table Design 기반 서비스 구현하기

세션 개요

발표자 변규현, SW 엔지니어, 당근마켓 김선형, CTO, 티클

개요 서버리스 기반 서비스를 위한 다양한 데이터베이스 선택 옵션이 있습니다. 본 세션에서는 RDB 및 NoSQL 측면에서 서버리스 DB 활용 전략을 살펴봅니다. RDB에서 서버리스를 위한 데이터 모델링 및 Amazon RDS Proxy와 Aurora Serverless 활용 방법을 소개합니다. 티클 서비스에 적용된 Amazon DynamoDB의 유용성과 함께 Single-Table Design을 적용한 DB 모델링 및 서비스 구현 사례를 함께 알아봅니다.

레포트１ (Amazon RDS Proxy와 Amazon Aurora 활용 방법)

아젠다

• Amazon RDS Proxy
• Amazon RDS Proxy의 사용 사례s
• Amazon Aurora Serverless V1
• Amazon Aurora Serverless V1의 사용 사례
• Amazon Aurora Serverless V2

Amazon RDS Proxy

• RDS Proxy의 완전 관리형 고가용성 데이터베이스 프록시
• 데이터베이스 연결을 풀링하고 공유하여 확장성 개선
• 데이터베이스의 장애 조회 시간 최대 66%단축 / 가용성 향상
• AWS IAM 인증을 통해 보안 개선 및 중앙 집중식 자격 증명 관리

Amazon RDS Proxy의 사용 사례

• 예측할 수 없는 워크로드가 있는 경우
  • 갑작스러운 이벤트로 인해 트래픽이 증가하는 경우 Proxy가 핸들링하여 데이터베이스의 부하를 줄인다.
• 데이터베이스 연결을 자주 열고 닫는 경우
  • Proxy가 핸들링하여 데이터베이스의 부하를 줄인다.
• 연결을 유지하지만 유휴상태로 유지하는 경우
  • 유휴상태의 연결은 Proxy에서 감당하여 데이터베이스의 부하를 줄인다.
• 일시적인 오류를 통해 가용성이 필요한 경우
  • 데이터베이스가 처리할 수 없는 부하는 RDS Proxy가 짤라낸다.

Amazon Aurora Serverless V1

• Amazon Aurora 에 대한 On-demand auto scaling 지원
• 요구사항에 따라 컴퓨팅 용량을 확장, 축소하는 DB 클러스터
• 자동으로 시작 / 사용량에 맞게 컴퓨터 용량 확장 / 사용하지 않을 때는 종료
• 예측할 수 없는 워크로드에 대해 간단, 비용 효율적인 옵션을 제공
• 활성 상태일 때 데이터베이스가 소비하는 데이터베이스 스토리지, 데이터베이스 용량, I/O에 대한 요금 지불

Amazon Aurora Serverless V1의 사용 사례

• 예측할 수 없는 워크로드일 경우
  • 자주 사용하지 않는 경우
  • 처음 릴리즈하는 서비스
  • 가변적인 워크로드
  • 개발 및 테스트 데이터베이스

: 항상 사용해야 하는 경우에는 사용을 추천하지 않는다.

Amazon Aurora Serverless V2 (Preview)

• 즉시 확장 가능한 서버리스 DB클러스터를 지원하도록 설계
• 요청의 급격한 증가에 대응할 수 있도록 가볍게 설계 (Instant autoscaling)
• V1과 비교
  • V1 : DB 클러스터가 임계 값에 도달할 때마다 ACU 두 배로 확장
  • V2 : V1보다 더 점진적으로 확장

그래프 설명

• 1 : 어플리케이션 클라이언트가 데이터베이스에 쿼리 요청을 하는 개수
• 2 : 쿼리의 요청이 늘어날때마다 Aurora Serverless V2가 스케일링을 하는 모습 (30초단위로 표시)
• 결론 : V2가 트레픽에 빠르게 대응한다는 것을 알 수 있다

레포트２ (Amazon DynamoDB Design Table Design 기반 서비스 구현하기)

아젠다

• Single Table Design이란
• 모델링 과정
• 실제 모델링 사례

Single Table Design이란

• DynamoDB의 디자인 패턴 중 하나
• 테이블 수를 하나로 유지하며 인덱스 정의 등을 활용하여 다양한 엑세스 패턴을 도출하는 방법
• DynamoDB 어플리케이션은 가능한 적은 수의 테이블을 유지하는 것을 추천하고 있다.
• 조인을 지원하지 않는 no-sql에서 한번의 요청으로 원하는 데이터를 모두 가져오기 위해서 사용

모델링 과정

1. 기획안과 디자인을 참고하여 비지니스 Access Pattern 도출
2. Access Pattern을 바탕으로 모델링 도출
3. 엔지니어 피드백

실제 모델링

• Access Pattern 정리

1. 1. • 사용자가 연동한 카드 목록 불러오기
      • 사용자의 카드 모든 사용 내역 불러오기
      • 사용자의 카드별 이용 내역 불러오기

• Access Pattern을 바탕으로 모델링 도출

1. 1. • DynamoDB를 처음 생성할 시 PK와 SK를 정의해야 한다.
      • PK = Partition-Key / SK = Sort-Key
        1. PK = 사용자 / SK = 카드#카드회사 / attribute = 카드회사
        2. SK = 트랜젝션#카드회사#카드이용시간 / 추가 attribute = 카드 이용처 / 사용 금액

• 모델링 과정에서 고려한 내용

1. • DynamoDB 모델링에서는 최적의 쿼리 성능을 위해 RK의 설정이 중요하다.
   • 다양한 Access Pattern의 도출을 위해 SK 지정 시 모델이름과 데이터를 #으로 분리
   • 트랜젝션 모델의 SK에 시간 데이터를 추가하여 특정 시간 범위의 데이터를 쿼리 가능
   • Nosql에서는 적은 쿼리로 한번에 요청을 받기 위해 데이터를 중복으로 작성함

마무리

• 서버리스의 서비스는 점점 확대 되고 있다.
• 그만큼 사용자가 선택할 수 있는 데이터베이스의 선택지도 확대되었다. 관계형, No-sql, 그래프 등 어디에 활용하는 가에 따라 다양한 데이터베이스를 선택할 수 있다.
• 내가 원하는 만큼 리소스를 요구하고 그거에 대해 과금하는 클라우드 네이티브 형태로 설계 가능하며 용량을 빠르게 변경시켜도 대응 할 수 있는 서비스가 제공된다.

소감

AWS Summit에 참가하는 것은 처음이었는데 서비스와 세션를 다양하게 볼 수 있어서 좋았습니다! 세션 중에서 하나를 정해서 블로그 글을 쓰면서 세션에 나오는 서비스에 대한 공부도 되고 어떻게 사용해야 되는지 사용법도 알 수 있어서 좋았습니다. 틀린게 있으면 말해주세요!