안녕하세요. SpoonRadio Buisiness Platform 팀에서 Billing 도메인 관련 백엔드 업무를 담당하고 있는 Eunice(손 윤)입니다. AWS Summit Seoul 2024에 참석할 수 있는 기회가 주어졌습니다.
AWS Summit에 처음 참여라 설레는 마음으로 참가하게되었습니다. 참가 등록 데스크를 거쳐서 기조연설을 시작으로, 미리 들으려고 표시해 두었던 강연을 들으러 바쁘게 움직였습니다.
가장 인상깊었던 강연은 ‘채널톡 스타트업 기술 성장기: RDBMS에서 NoSQL로의 전환’ 이었습니다. 해당 강연의 내용을 소개해 드리고자 합니다.
- RDBS에서 NoSQL로의 마이그레이션을 하게 된 동기와 원인
- DynamoDB와 SQS의 장점과 활용 방안
배경 설명
채널코퍼레이션는 서비스 성장에 따라 트래픽 증가는 필연적으로 예전보다 더 많은 트래픽을 유발할 거라고 판단하였습니다. 간단한 대응 방법으로 RDS인스턴스 타입 스케일업(Scale-up)을 생각하였으나, 결과적으로 NoSQL을 도입하기로 합니다. 그에 따라, 아래 네 가지의 문제 해결이 필요했습니다.
- 오버 프로비저닝으로 인한 비용 비효율 문제: 스파이크 트래픽의 피크(peak) 트래픽에 맞춰 RDS 인스턴스 사이즈를 선택해야 하기 때문에 비용 비효율이 예측됨.
- 테이블 간 부하 전파 문제: 특정 테이블들의 부하가 RDS 인스턴스 전체에 영향을 끼쳐 전체 서비스에 장애를 우려함.
- NoSQL로의 오퍼레이션 대체 가능 여부: 특히 여러 채팅 방의 “안 읽은 메시지” 개수 합을 구하는 문제와 같은 특수한 작업.
- PostgreSQL에서 DynamoDB로의 데이터 마이그레이션 전략.
DynamoDB를 선택한 이유
위의 네 가지 문제 해결과 동시에 다음 세 가지 주요 이유로 DynamoDB를 선택했습니다.
- 이벤트 소싱: 데이터베이스의 변경 사항을 쉽게 다른 서비스로 이벤트 소싱할 수 있어야 함.
- AWS 서비스들과의 연동: 기존 AWS 서비스들과의 풍부한 연동.
- ACID 트랜잭션 지원: 트랜잭션 지원 필요.
이러한 요구 사항을 고려했을 때, AWS DynamoDB는 규모에 상관없이 빠르고 유연한 완전 관리형 NoSQL 데이터베이스 서비스로 적합
Spike 트래픽 처리
스파이크 트래픽 비용 비효율 문제 같은 경우에는 이전 처리량이 동일한 30분 이내에 2배에 해당하는 피크 트래픽을 동시에 수용할 수 있는 온디맨드 모드가 있고, 평소에는 내가 설정한 만큼 사용하다가 오토 스케일링에 의해서 유연하게 처리량을 조절해 주는 프로비저닝 모드가 있는데, 이 두 가지 모드 중에 적절하게 선택하여 DynamoDB를 선택한 것만으로 간단히 해결할 수 있었다고 합니다.
1. 온디맨드
온디맨드 용량 모드를 사용하는 DynamoDB 테이블은 애플리케이션의 트래픽 볼륨에 따라 자동으로 조정됩니다. 온디맨드 용량 모드의 테이블은 이전 피크 트래픽의 최대 2배 용량을 즉시 수용합니다.
2. 프로비저닝
애플리케이션 트래픽이 예측 가능한 경우트래픽이 일관되거나 점진적으로 변화하는 애플리케이션을 실행할 경우 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정합니다. Auto Scaling을 사용하여 트래픽 변경에 따라 테이블의 프로비저닝된 용량을 자동으로 조정할 수 있습니다.
온디맨드 모드의 기존 테이블은 언제든지 프로비저닝된 용량 모드로 전환할 수 있습니다. 하지만 온디맨드로의 전환을 나타내는 마지막 타임스탬프가 발생한 지 24시간이 지난 후에야 다시 온디맨드 모드로 전환할 수 있습니다.
Spike 트래픽과 SQS
채널톡은 외부로부터의 여러 서비스 요청에 대한 로그를 기록하고 있다고 합니다. 이 로그를 DynamoDB에 기록한다면, 갑자기 많은 로그 record를 추가되어 DynamoDB의 ProvisionedThroughput을 넘어서 문제가 발생이 있었습니다. 따라서, Spike 트래픽이 발생할 경우 Amazon SQS를 이용해서 서비스 요청 로그를 버퍼링하고, Amazon SQS에서 일정한 속도로 로그를 읽어서 DynamoDB나 RDS와 같은 저장소에 저장하는 아키텍처를 설계하였다고 합니다.
PostgreSQL 오페레이션을 DynamoDB로 처리 과정
이 외에도 기존 PostgreSQL을 통한 안읽음 표시 오페레이션을 DynamoDB를 통해 어떻게 처리했는 지 등에 대한 내용들 또한 공유해주었습니다.
기존에는 PostgreSQL을 사용했기 때문에 ChatBadge는 원자적 연산을 사용했고, ManagerBadge는 ChatBadge들의 합을 구하면 됐었습니다. 하지만 DynamoDB에서 기존과 같은 방식으로 구현한다면 채팅 방이 많은 사용자는 ManagerBadge를 계산하는 속도가 점점 느려질 것으로 예측하였습니다. 이 문제를 해결하기 위해 DynamoDB 트랜잭션을 통해 어떻게 핸들링하였는 지 공유해 주셨습니다.
특정 채팅 방에서 메시지가 작성되면, 작성자를 제외한 각 참여자에겐 다음과 같은 오퍼레이션이 수행됩니다.
- 참여자의 ChatBadge를 증가시키는 UpdateItem을 생성합니다.
- 참여자의 ManagerBadge를 증가시키는 UpdateItem을 생성합니다.
- 두 개의 UpdateItem 오퍼레이션을 TransactWriteItems API를 사용해 처리합니다.
이를 통해, ChatBadge들의 합은 ManagerBadge가 됨을 보장하였고, 또한, 동시에 다량의 메시지가 발생하여아래 그림에서 보시는 바와 같이 충돌이 발생했을 때는 exponential backoff retry 전략을 활용하며, DynamoDB 트랜잭션은 ClientRequestToken 파라메터를 사용하는 경우 멱등성을 지원하기 때문에 연결 시간 초과 등의 문제로 동일 요청이 여러 번 제출된 경우에도 10분 이내라면 정확하게 ChatBadge와 ManagerBadge를 관리하였습니다.
- 참여자의 ManagerBadge를 증가시키는 UpdateItem을 생성합니다.
- 두 개의 UpdateItem 오퍼레이션을 TransactWriteItems API를 사용해 처리합니다.
이를 통해, ChatBadge들의 합은 ManagerBadge가 됨을 보장하였고, 또한, 동시에 다량의 메시지가 발생하여아래 그림에서 보시는 바와 같이 충돌이 발생했을 때는 exponential backoff retry 전략을 활용하며, DynamoDB 트랜잭션은 ClientRequestToken 파라메터를 사용하는 경우 멱등성을 지원하기 때문에 연결 시간 초과 등의 문제로 동일 요청이 여러 번 제출된 경우에도 10분 이내라면 정확하게 ChatBadge와 ManagerBadge를 관리하였습니다.
마무리하며…
이번 강연은 백엔드 개발자로서 어떤 시점에 DynamoDB를 도입하는 것이 적절한지, 그리고 Spike 트래픽을 어떻게 효과적으로 처리할 수 있는지를 배울 수 있는 귀중한 시간이었습니다. 또한, PostgreSQL에서 DynamoDB로 마이그레이션 할 때 고려해야 할 여러 가지 포인트들에 대해 깊이 공감할 수 있었습니다. 강연에서 다룬 내용을 글로 모두 담기에는 한계가 있을 듯 합니다. 자세한 내용은 AWS Summit Seoul의 발표 자료와 녹화 영상을 통해 더 확인해주시면 좋을 것 같습니다!
AWS Summit 참석 후기
AWS코리아 대표 함기호님이 기조연설 때 “올해 행사는 생성형 AI를 중심으로 다양한 산업 분야와 기술 주제에 걸쳐 100개 이상의 강연과 70개 이상 고객 사례, 60개 이상의 스폰서 및 파트너가 클라우드를 통한 혁신의 노하우를 공유하는 자리가 될 것이다” 라고 말씀하신 것과 같이 이번 행사는 생성형 AI가 중심으로 꾸며져있었습니다. 이에 따라, 생성형 AI를 경험할 수 있는 여러 부스들이 마련되어 있었습니다.
첫 AWS Summit 참가인 만큼 강연 외에도 여러 부스들을 돌아다니며 재밌는 경험들을 하였습니다. 프리킥 챌린지를 위한 사진을 찍자마자 유니폼을 입힌 사진을 바로 만들어 내는 것을 경험하였고, Amazon Bedrock를 구현하여 각 연령 별 어린이를 위한 동화를 만들라고 프롬프팅되어있는 모델에 글을 쓰니 실제로 그림과 함께 동화 한 편을 뚝딱 만들어 내는 것도 실제 체험해 볼 수 있었습니다.
또한 각종 부스들을 돌아다니며, 소소하게 이벤트를 참여하고 아기자기한 굿즈들을 받아오는 재미도 AWS Summit을 즐기는 하나의 요소이지 않나 생각이 들었습니다.
꿀팀을 알려드리 자면 AWS 전문가 분들이 부스에서 대기 중 이십니다. 그동안 AWS 서비스를 사용하면서 궁금했던 점이나 논의가 필요한 부분이 있었다면 전문가 분들께 자유롭게 여쭤볼 수 있는 자리가 마련되어있습니다. 해당 부스를 이용하여 최대한 즐기시면서 유익한 정보들도 얻어가실 수 있길 추천드립니다! 또한 인기가 많은 강연의 경우 서서 듣거나, 강연 참여에 제한이 있어서 못들어 가는 경우도 있으니 늦지 않게 도착해야 입장이 가능했습니다. 이 점도 참고해 주세요!
이번 Summit을 통해 많은 것을 배우고 느낄 수 있었으며, 앞으로도 이러한 기회를 통해 지속적으로 성장해 나가고 싶습니다.
