먼저 SmartThings Data Platform이란 무엇인지 살펴보겠습니다. SmartThings Cloud는 수억 대의 기기에서 발생하는 기기 상태 변경 이벤트를 처리하며, SmartThings Data Platform은 이러한 이벤트를 가공하여 SmartThings의 다양한 서비스를 제공합니다. 대표적으로 아래와 같은 서비스가 있습니다.

그림 1. SmartThings Data Platform을 활용하는 대표적인 서비스

통계 정보 가공 시스템은 SmartThings Data Platform의 일부분으로, 기기 상태 값의 시간 구간별 발생 빈도, 합계, 평균값 등을 실시간으로 계산합니다. 이 시스템은 고성능 데이터 처리 엔진을 사용하여 대규모 데이터의 실시간 처리가 가능하며, 이를 통해 사용자는 최신 기기 상태 정보를 언제든지 확인할 수 있습니다. 계산된 데이터는 즉시 데이터베이스에 저장되고 SmartThings 앱에서 조회할 수 있도록 준비됩니다.

그림 2. 통계 정보 가공 시스템의 구조

기존에는 통계 정보 가공 시스템에서 대용량의 정보를 저장 및 검색하기 위한 데이터베이스 솔루션으로 HBase를 사용했습니다. 일반적으로 분산시스템에서 대부분의 데이터베이스 솔루션은 CAP 이론상 CP(Consistency & Partition tolerance) 또는 AP(Availability & Partition tolerance) 속성을 갖는데, HBase는 CP 속성을 갖고 있습니다. CAP 이론에 대한 자세한 설명은 아래 링크에서 확인하시기 바랍니다.

- https://en.wikipedia.org/wiki/CAP_theorem

SmartThings의 규모가 커지면서 consistency를 일부 희생하면서 availability를 강화할 수 있는 마이크로서비스 아키텍처를 도입하게 되었습니다. 더불어 eventual consistency를 플랫폼의 정책으로 삼았고요.

통계 정보 가공 시스템 역시 플랫폼의 변화에 발맞춰 AP 속성의 데이터베이스 솔루션으로 교체하기로 결정했습니다. 솔루션 구조상 strong consistency를 보장하기 위해 일부 availability를 희생하는 HBase는 더 이상 사용할 수 없었기 때문이죠.

그림 3. HBase의 Architecture

새로운 데이터베이스 솔루션을 선택하기 위해 다음과 같은 몇 가지 원칙을 정하고 고려했습니다.

- 데이터 요청에 원활하게 응답할 수 있는 높은 가용성(availability)

- 지속적인 트래픽 증가에 대처할 수 있는 확장성(scalability)

- 백업 및 복구의 용이성

- 필요시 암호화 가능

- 디스크 용량의 지속적인 증가를 막기 위한 TTL(Time To Live) 지원

아래는 이러한 원칙을 토대로 데이터베이스 솔루션을 비교한 결과입니다.

표 1. 데이터베이스 솔루션 비교

비교 결과에 따라 CAP 이론상 CP 속성을 갖는 DocumentDB는 가용성 문제로 우선 제외했고, 데이터 병합을 DB에서 기본적으로 지원하는 Aurora(PostgreSQL)를 새로운 데이터베이스로 선정하여 PoC(Proof of Concept)를 진행하기로 결정했습니다.

Aurora(PostgreSQL)를 실제로 적용하기 위해서는 “데이터를 시간 구간별로 병합하는 기능”과 “일정 시간이 지나면 데이터를 삭제하는 기능(TTL)”이 필요했습니다. Aurora(PostgreSQL)의 경우 관계형 DB이기 때문에 데이터 병합 기능에 대한 테스트는 건너뛰고 TTL 기능이 제대로 동작하는지 확인했죠.

PostgreSQL은 “pg_partman”이라는 extension을 통해 partition을 생성할 수 있는 기능을 지원합니다. partition은 아래 예시와 같이 interval 구간과 retention 기간을 설정하여 생성할 수 있습니다.

또한 “pg_cron”이라는 extension을 통해 자동으로 partition을 생성할 수 있습니다. 이러한 extension에 대한 자세한 설명은 아래 링크에서 확인하실 수 있습니다.

- https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md

- https://github.com/citusdata/pg_cron/blob/main/README.md

통계 정보 가공 시스템은 Kafka를 통해 전달되는 데이터를 Apache Flink application을 통해 실시간으로 가공합니다. 따라서 Kafka의 특정 topic에 데이터를 충분히 채운 후 가공된 데이터를 HBase에 적재하는 application과 Aurora(PostgreSQL)에 적재하는 application을 동시에 실행하여 어떤 성능을 보이는지 consumer group lag max metric을 통해 확인했는데요. 성능 테스트는 다양한 시나리오와 부하 조건에서 수행되었으며, 이는 데이터베이스의 가용성과 처리 능력을 평가하는 데 중요한 역할을 했습니다.

그림 4. Kafka consumer group lag max metric

그림 4에서 파란색은 HBase application, 주황색은 Aurora(PostgreSQL) application의 metric으로 Aurora(PostgreSQL)가 더 나은 성능을 보이는 것을 확인할 수 있습니다.

기능/성능 확인 PoC를 통과한 Aurora(PostgreSQL)는 통계 정보 가공 시스템의 데이터베이스로 최종 선정되어 운영 환경에 적용되었습니다. 언급된 PoC 케이스 외에 다른 확인 작업도 수행했지만 지면 제약상 생략했습니다.

SmartThings의 수많은 마이크로서비스에서는 각각의 요구에 맞게 서로 다른 데이터베이스를 사용하고 있으며, 필요할 때 새로운 데이터베이스 솔루션을 도입하거나 기존 데이터베이스를 개선하고 있습니다. 이러한 데이터베이스 전환 과정은 SmartThings의 지속적인 성장과 혁신을 가능하게 합니다. 이때마다 적절한 평가 원칙과 테스트 방안을 수립해 진행하고, 매번 더 나은 결과를 만들어 나가기 위해 노력하고 있습니다. 이번 기회에 조금이나마 SmartThings의 개발 방식을 소개할 수 있게 되어 기쁘게 생각합니다. 앞으로도 SmartThings는 데이터베이스 솔루션을 지속적으로 평가하고 최적화하여 최고의 사용자 경험을 제공할 것입니다.

Device Platform Center, SmartThings 서버개발그룹의 고성준이었습니다. 감사합니다.