대규모 트래픽 처리를 위한 클라우드 DB 활용 (삼성/쿠팡)
※ 본 내용은 AWS Summit 2023 내용을 정리한 글입니다.
1. 목적별 데이터베이스
현대 Application은 매우 복잡하다. 사용자가 수백만명이고 볼륨이 많이 필요하다. 이로 인해 1개의 DB 운영은 매우 어렵다.
여러 용도에 맞게 DB를 선택하는 게 중요하고, 자신의 시스템에 최적화된 DB를 선택해야 한다. 이를 Cloud Native를 통해 손쉽게 해결할 수 있다.
위의 그림처럼 AWS는 다양한 DB를 제공한다.
2. 삼성의 사례
Rich Communication Service. 삼성의 차세대 메시지 플랫폼에서 하루 5천만 건의 메시지를 처리해야 하는 상황.
모놀리식 아키텍처이고, 클러스터당 1,000,000명의 사용자가 있다. 각 사업자에 대해 10~20개의 클러스트가 있다.
클러스터가 증가할수록 사용율이 늘어나 부담이 커지는 문제가 있었다. 기존 RCS1.0 애플리케이션을 클라우드로 마이그레이션하는 방식의 'Lift and shift'로 전환.
재설계/구현하여 마이크로 서비스(MSA) 단위로 변경. 하위 도메인으로 분리하였다.
기존 문제점이 데이터 의존성이였는데 stateless 상태를 위해 데이터 의존성을 분리하였다.
Shared Repository Architecture Style(공유 저장소 아키텍처)로 설계하여, 마이크로 서비스 아키텍처를 위해 데이터 의존성을 분리하였다.
그럼에도 정합성/성능 이슈가 있었다.
각각의 서비스마다 정합성/성능의 중요성이 다르기에 삼성은 도메인 성격에 따라 설계를 다르게 하는 방식을 택하게 된다.
2.1. 읽기 성능이 중요한 도메인
도메인 성격은 매우 많은 읽기와 매우 적은 쓰기의 특성을 지녔다. 이에 높은 읽기 성능 품질이 요구되었다.
이에 인메모리, 캐시가 필요했고, Aurora ElasticCache를 사용하였다. 덕분에 읽기 성능이 확 증가했지만
정합성이 어느정도 파괴되는 문제가 발생한다.
이를 엘라스틱 캐시의 Key event subscription의 event와
Data Provider Service의 Local cache를 사용해 정합성 파괴를 감소시킨다.
이로 인해 어느정도 정합성 손실을 감수할 수 있게 된다.
2.2. 정합성이 중요한 도메인
본 도메인은 Handover, Wifi 전환 등 잦은 주소 변경하는 정형 데이터이다.
서비스 성격은 메시지 누락, 오 전송에 매우 민감하다. 연결 정보 획득 성능이 메시지 송신 성능에 영향을 끼친다.
이에 강한 일관성 읽기에 강한 Dynamo DB를 사용한다. 그러나 성능 품질이 감소된다는 단점이 있었다.
위의 그림처럼 성능 품질을 위해 ElasticCache를 사용하였다.
Data Provider Service의 Elastic cache consistency lock을 사용하여 캐시임에도 정합성을 강화시켰다.
이러면 정합성과 속도를 어느정도 잡을 수 있다.
2.3. 결론
도메인, 서비스 특성을 고려한 전략을 통해
위의 엄청난 효과들을 얻어냈다. 위의 사례들을 통해 목적에 맞는 Managed Service와 도메인 특성을 반영한 전략이 결합되면 견고한 서비스를 만들어 내는 교훈을 얻을 수 있다.
3. 쿠팡의 사례
하나의 노드가 수용할 수 있는 트래픽은 한정되어 있기에 MSA를 기반하여 서비스 하였다. 그럼에도 특정 서비스에 트래픽이 엄청 증가하는 현상은 꾸준히 발생되는 상황이었다.
이런 트래픽 증가를 해결하기 위해 서비스 내의 서비스를 더 쪼갰다. 서비스를 더 세분화하여 논리적으로 분리하거나, 데이터베이스를 sharding하여 사용하는 방식을 적용했다.
3.1. 스마트 지원 서비스
쿠팡의 서비스는 점점 커지게 되고, DML, DDL, ACL 작업이 어마무시하게 증가한다. 이에 스마트 지원 서비스를 도입하게 된다.
쿠팡은 비용을 감소 시키기 위해 스마트 지원 서비스를 도입.
반복되는 요청 작업을 자동으로 수행하고, 관리자와 사용자 모두 편하게 만든다. 신뢰 가능한 서비스여야 하고, 업무를 진행함에 또다른 허들이 되어서는 안 되게 만들었다.
쿠팡은 스마트 지원 서비스를 개발하기 위해서 아래의 조건들을 신경썼다.
- 신뢰 가능한 메타 정보 제공
- 최신 서버 구성 정보 제공
- 장애에 대한 즉각적인 대응
- 예측 가능한 장애에 방어 프로세스
- 모니터링, 에러 로그
- 커뮤니케이션 최소화
- 데이터베이스 표준화
- 쉬운 서비스 가이드 문서 및 Q&A
- 에러 패턴 정리
사용자는 DML만 수행하게끔 만들고, DDL은 허용하지 않게 했다. 오직 DBA만 DDL을 작업할 수 있게 만들어 DML에만 많은 작업을 하게끔 만들었다.
근래에는 비즈니스가 많이 런칭이 되어서 DDL 요구가 높아졌고, DDL 엔지니어의 필요성이 증가하게 됐다.
위의 사진은 스마트 지원 서비스 대시보드이다.
DDL은 많은 장애가 발생한다. DDL은 장애가 발생할 확률이 크기에 한 번에 한 건만 DDL을 처리하게끔 만들었다.
위의 사진들처럼 DDL을 이상하게 작성하면 빨간 표시를 뜨게하여 올바른 설정을 만들게끔 개발했다고 한다.
유독 DDL 쪽에 장애가 많이 나기에 쿠팡측에서 많이 신경쓴 부분을 알 수 있다.
이런식으로 개발자와 고객 간극을 줄여 생산성을 극대화하였고, 탬플릿으로 최소한의 에러를 발생시키게 신경을 많이 썼다.
DB를 자동화되게 만들었으면 모니터링을 해야하고, 세션을 관리해야 한다. 위의 사진처럼 DB를 주기적으로 관리할 수 있다.
3.2. 블루/그린 서비스
쿠팡은 블루/그린 서비스로 마이그레이션 하여 가용성 확보 및 유지보수를 신경썼다.
다운타임을 30초 미만으로 만들고.
블루/그린 전략으로 서버 버전 패치, 데이터베이스 마이그레이션, 대용량 테이블 변경, 유지/보수 등이 가능하게끔 만들었다.
4. 결론
개발자는 서비스가 점점 커지고, 요구가 까다로워지는 상황 속에서 이제는 다양한 데이터베이스를 사용하여 고도로 분산된 애플리케이션을 구축해야 한다. 이로 인해 개발자는 데이터베이스를 선택 시 고려해야할 점을 생각해야 한다.
위의 사진처럼 DB를 선택 시에 워크로드, 데이터 형태, 어플리케이션 성능 요구사항, 운영 부담 등을 고려해야 한다.
출처: 2023, Amazon Web Services