삼성 스마트싱스가 서버리스와 플링크 택한 이유

삼성전자 스마트싱스 서버개발그룹 인터뷰

“삼성전자 스마트싱스는 구글, 아마존, 애플 등과 견주는 세계적인 IoT 플랫폼이며, 올해를 기점으로 더욱 큰 성장을 기대하는 플랫폼이다. 실시간으로 스마트싱스 플랫폼에 들어오는 트래픽이 급증할 것으로 예상되는 가운데, 부서장 입장에서 개발 자원이 새로운 기능 개발과 창의적 업무에 투입되지 못하고, 장애 대응과 운영 업무에 지속적으로 들어가는 상황을 해결해야 했다."

삼성전자 스마트싱스 서버개발그룹의 이제원 그룹장은 최근 본지와 인터뷰에서 스마트싱스의 실시간 데이터 분석 플랫폼을 아마존웹서비스(AWS)의 서버리스형 데이터 분석서비스인 ‘아마존 키네시스 데이터 애널리틱스’로 이전한 이유를 이같이 설명했다.

스마트싱스는 삼성전자의 IoT 플랫폼이다. 스마트홈 게이트웨이, 애플리케이션, IoT 디바이스 등을 개발하는 스타트업으로 시작해 2014년 삼성전자에 인수됐다. 현재 스마트싱스는 TV, 에어컨, 냉장고, 세탁기, 에어드레서 등 삼성전자의 가전제품과 갤럭시 스마트폰, 태블릿, 스마트태그, 웨어러블 등을 망라해 연결하고 있다.

삼성 스마트싱스 서버개발그룹 전상기 개발자(왼쪽부터), 정동환 개발자, 이제원 그룹장, 이장결 개발자, 고성준 개발자

스마트싱스 데이터 분석 플랫폼은 기기의 시작, 멈춤 등의 동작을 담은 사용기록, 사용자 알림 내역, 사용량 통계, 분석 및 추천 등의 역할을 하고 있다. 2만여종, 9천600만개 이상의 기기에서 생성된 실시간 데이터가 스마트싱스 데이터 분석 플랫폼으로 들어온다. 삼성전자에 따르면, 초당 400메가바이트, 시간당 1.4테라바이트, 하루 33TB의 빅데이터를 처리하고 있다.

지난달 열린 AWS서밋코리아2022에서 삼성전자 스마트싱스 서버개발그룹은 ‘고통으로부터 해방, 분석 플랫폼 현대화’란 주제로 관련 사례를 발표했었다. 이 내용에 의하면, 기존 스마트싱스 데이터 분석 플랫폼은 아마존 EC2 인스턴스에 하둡 클러스터를 구축하고 실시간 인입 데이터 처리에 아파치 스파크를 활용했다. 파일시스템은 HDFS, 데이터베이스는 HBASE, 자원관리는 YARN, 분산코디네이터는 주키퍼 등으로 이뤄졌고, 운영은 테라폼과 앤서블로 일정부분 자동화했다. 오픈소스 기반 플랫폼이었던 탓에 관리 부담이 클 수밖에 없는 구조였다.

하드웨어, 소프트웨어 유지 관리와 연산 자원 및 스토리지 용량 할당, 분산처리, 장애 대응 등 인프라 고려 사항도 많았다. 하둡 클러스터의 불안정성이 운영 부담을 크게 높이는데다, 실시간 스트리밍 데이터를 소규모 배치로 처리하도는 스파크의 기능적 제약은 갈수록 늘어나는 스마트싱스 트래픽 처리에 한계를 드러냈다. 서버개발그룹의 개발팀에겐 고통의 시간이었다. 무엇보다 장애대응 ‘온콜’에 많은 시간을 할애 해야 했다고 한다. 운영중인 50개 스파크 앱의 온콜 수는 월간 평균으로 앱 지연 대응 131회, 비정상 종료 앱 수동 복구 28회, 하둡 클러스터 수동 복구처리 13회 등이었다. 매번 새로운 이슈가 발생해 기능 개발 업무 지연이 빈번했다고 한다.

이장결 개발자는 두가지 문제가 있었다고 설명했다.

이장결: 기존 EC2 기반 하둡은 단일 클러스터에 스파크나 HBASE 등 여러 요소를 설치하고 있었다. 문제 하나는 HBASE와 스파크가 동일 노드에 있어서, HBASE 특정노드가 CPU를 점유하면 스파크 앱에도 영향을 주는 것이었다. 데이터를 처리하지 못하거나 지연되거는 등의 추가 장애 발생도 있었다. 두번째로 스파크 앱이 오토스케일링 되지 않는다는 것이었다. 스마트싱스는 이벤트 양이 일정하지 않은데 특정 시점에 버스트 트래픽이 오기도 하고, 새로 배포하거나 기존 장애로 스파크 앱을 중단했다가 다시 시작하면 그간 쌓인 이벤트를 처리하는데 처리 속도가 따라가지 못하는 경우도 발생했다. 결국 리소스 부족으로 볼 수 있는데, 오토스케일링 힘든 구조이다보니 조치를 위한 매뉴얼 작업이 필요하게 된다. 매일 돌아가면서 온콜 담당자를 지정해 이슈대응 체계를 운영했다. 최악의 경우 담당자가 하루종일 온콜만 하기도 했다. 큰 장애가 몇번 있었는데 일주일 밤샘 작업을 하기도 했다.

이런 상황이 스마트싱스 데이터 분석 플랫폼의 현대화를 고민하게 만들었다. 특히 삼성전자를 비롯해 구글, 애플, 아마존 등 스마트홈 주요 사업자 모두 참여하는 표준 IoT 프로토콜 '매터' 기반 제품이 올해부터 본격적으로 시장에 출시될 예정이라 실시간 데이터 처리 부담의 급증이 확실히 예고돼 있었다.

이제원: 부서장 입장에서 개발 리소스가 어디에 투입되느냐는 매우 중요하다. 새로운 기능을 개발하고 창의적인 일을 하는데 투자해야 할 리소스가 온콜 대응과 수작업에 지속적으로 들어가는게 안타까웠다. 새로운 클라우드 솔루션을 결정할 때 미치는 요소는 비용도 중요하고, 리소스도 중요하다. 온콜 대응 상황을 보니 비용측면에서 약간의 차이 혹은 오히려 더 들더라도 리소스를 줄일 수 있으면 선택해도 되겠다고 느낄 정도로 힘든 대응을 해왔다.

현 스마트홈 시장은 제조사별로 파편화돼 있다. 기기 정보를 주고 받는 데이터 처리 형식이 다 다르다. 스마트싱스는 삼성전자 제품만 쓸 수 있다. 구글 네스트, 아마존 알렉사, 애플 홈킷 등도 각 회사의 제품만 사용할 수 있다. 작년 본격적으로 논의된 '매터(Matter)'는 이런 파편화를 해결하고 플랫폼과 디바이스 간 호환성을 표준화하기 위해 나온 결과물이다. 올해 스마트홈 제조사들이 매터 기반 제품을 출시할 예정이다. 이렇게 되면 스마트싱스에 구글 네스트나 아마존 알렉사 제품을 연결할 수 있게 된다.

이제원: 스마트싱스 플랫폼은 국내서 1등이고, 적지 않은 사용자 기반과 트래픽을 가진 거대한 시스템이. 올해 허브에 소물을 붙이는 표준 프로토콜인 매터가 본격적으로 도입되면, 특정 밴더에 맞추는 대신 매터 프로토콜만 맞춰 개발하고 호환되는 허브에 그냥 붙이는 형태가 된다. 각 플랫폼 에코 확장 측면에서 자기가 잘하는 서비스 개발에 집중하면 되는 세상이 올 것. 스마트홈이란 관점에서 보면, 엄청난 기회가 될 수 있게 된다.

이런 상황에서 새로 구축된 스마트싱스 데이터 분석 플랫폼은 ‘아파치 스파크’ 대신 ‘아파치 플링크’를 사용한다. 플링크는 AWS의 서버리스 솔루션인 ‘아마존 KDA’에 올라가므로 플랫폼의 하부 인프라 설계와 운영 부담을 해소할 수 있다.

스마트씽스 데이터 분석 플랫폼의 데이터 처리 파이프라인에 대해 고성준 개발자는 실시간 처리에 초점을 맞췄다고 했다.

고성준: 홈 IOT 기기에서 발생하는 데이터를 어떻게 스마트싱스서 안정적이고 빠르게 가공할지 초점을 맞춰 구성했다. 실시간으로 시스템 데이터를 처리하는 부분이다. 보통 분석 플랫폼은 하루치를 모아서 배치로 가공해서 인사이트 뽑는 형태로 구성하는데, 스마트싱스는 초당으로 가공해 사용자에게 데이터를 가공해 빠르게 가시화하는 것이다. 서밋에서 발표했듯 플링크온KDA를 활용해 여러 앱을 전환하고 있다. 앱 간의 데이터 전송 시 안정화를 위해 카프카 메시징 솔루션을 사용한다. 전체적으로 보면 카프카와 플링크 등의 앱을 조합해 가공한다. 몇단계를 거쳐 가공된 데이터는 HBASE와 아마존 S3 등에 저장한다. 스마트싱스 엡에서 볼 수 있는게 기기 동작 기록이다. 앱에서 알림을 보내서 사용자에게 알림내역을 보게 하는데 목적에 맞게 데이터를 분리하거나 시간대별로 합쳐 보여주거나 하는 애플리케이션이 중간 중간에 들어가서 여섯 일곱단계 거치면 결과물이 나오는 형식이다.

분석 플랫폼 현대화 방안을 결정할 때 아파치 스파크를 유지할 수도 있었다. 아마존 EMR 기반 스파크 구성을 선택했다면, 기존 스파크 애플리케이션 50여개를 플링크로 재개발하지 않아도 됐을 것이다. 그럼에도 스마트싱스 서버개발그룹은 아마존 KDA와 플링크를 결정했다. 이에 정동환 개발자는 스트리밍 데이터 처리 면에서 플링크의 성능과 비용이 스파크보다 우월했다고 설명했다.

정동환: 초기에 데이터 픞랫폼을 비교 할 때 대용량 이벤트를 처리하는 여러 후보를 두고 검토했다. 사전조사에서 기존의 스파크와 플링크를 봤는데, 플링크는 스파크 대비 API와 문서는 적었다. 하지만, 스트리밍에서 스파크는 배치성이고, 플링크는 스트리밍에 초점을 둔다. 아파치 플링크가 스트리밍에서 성능이 더 좋고 비용도 적다고 결론내렸다. 기존 스마트싱스의 경우 데이터 플랫폼에서 쓰는 처리가 배치라 해봐야 최대 1시간 인터벌이 많았고, 대부분 스트리밍에 집중돼 있다. 추가적으로, 이벤트가 낮에 많고, 저녁에 적은 식의 양상이어서 스케일인아웃이 잘 되는 프레임워크가 필요했다. 스파크는 자체 다이나믹 얼로케이션은 불안정하다. 플링크는 패러렐리즘을 이용해서 쉽게 스케일인아웃 된다.

이제원 그룹장은 스마트싱스 자체가 실시간 이벤트 처리에 특화됐다는 점에서 검토했다고 강조했다. 사용자에게 기기 동작에 대한 즉각적인 정보를 알려줘야 하기 때문이다.

이제원: IoT는 기기에서 올라오는 기기 이벤트 처리가 가장 중요하다. 스마트싱스가 지속적으로 소화하는 이벤트 양이 있을 때 동일 이벤트를 기존 스파크 비용 대비 새 솔루션으로 갈아타려 할 때 여러 요소 중에 비용도 중요한 요소였다. 그 측면에서 갭과 이득을 살펴봤다.

스마트싱스의 기존 데이터 분석 플랫폼이 하둡 클러스터였는데, 호튼웍스의 HDP 기반이었던 점도 현대화 작업에 영향을 줬다.

정동환: 스마트싱스 초기인 4~5년 전엔 지금보다 선택의 폭이 좁았을 것이다. 당시엔 적절했던 게 시간 지나면서 더 진화해야 했는데, 진화를 하긴 했지만, 지속적 사용에 무리가 있었다. 아키텍처를 바꾸고, 현대화를 결정해야 하는 니즈가 강했고, 그에 맞춰서 하둡클러스터를 내재화하고 더 나아가 기존 스파크 기반 이벤트 프로세싱을 플링크로 가는 방향으로 전환했던 것이다. 지금도 스파크가 나쁘지 않지만, 우리 상황에 맞지 않을 뿐이다. 성능과 비용 측면에서 볼 때 플링크가 지금의 스마트싱스에 더 적합하다고 판단한 것이다.

서버개발그룹은 50여개의 스파크 기반 애플리케이션을 플링크로 전환해야 했다. 모든 걸 전환하기에 앞서 테스트가 필요했다. 6개 애플리케이션을 선정해 플링크로 개발했고 먼저 아마존 KDA에 올렸다. 고성준 개발자는 성능 테스트에 많은 공을 들였다고 설명했다.

고성준: 스파크에 비해 플링크로 가면서 기존 스파크서 구현한 코드를 플링크로 구현하는 작업도 필요했고, CI/CD, 모니터링, 성능테스트 등이 필요했다. 그중에서 성능 테스트가 가장 신경쓰였다.아마존 KDA로 처음 결정했을 당시 사전조사로 어느정도 성능을 낼거라 보기만 했지 예측은 불가능했다. 클라이언트로 구현해서 프로덕션과 유사하게 돌렸을 때 비용이나 성능에 의문이 있었다. 플링크는 처음이어서 애플리케이션 구현과 설정에 따라 성능이 다르게 나오고, 튜닝이 중요한 요소였다. 실제 프로덕션 갈 때 장애 안 생기는게 목적이었고, 로드 테스트 하며 유동적 트래픽에 대해 AWS서 제공하는 오토스케일링을 쓰다가 빠르지 않아서, 개선하려고 커스텀 오토스케일링을 만들어 트래픽에 유동적으로 대응하게 적용해서 성능을 올렸다. 지금도 추가로 마이그레이션 진행하는데 거기서도 로드테스트는 계속해서 진행하고 있다. 장애 시 복구 자동화도 되고, 사용자 증가로 이벤트가 많아졌을 때 증설과 튜닝 등에 필요한 시간과 노력이 줄었다.

먼저 현대화된 6가지 애플리케이션은 어떤 식으로 정했을까. 이장결 개발자는 최대한 다양한 기능을 검증하는데 초점을 둬 선택했다고 설명했다.

이장결: 각 애플리케이션이 어떤 것인가보다 최대한 다양한 기능을 검증하는게 목적이었다. 다양한 커넥터를 사용하는 것에서 성능에 주안점을 두고 선정했다. 결론적으로 최대한 다양한 커넥터와 복잡한 로직을 가져서 성능에 민감한 애플리케이션을 우선순위로 두고 선정했다. 데이터 소스의 카프카와 아마존 키네시스, 싱크는 카프카와 HBASE, S3, 다이나모DB 등으로 전달해야 하므로 다양한 커넥터를 쓰고 있다. 아파치 플링크의 커넥터가 기존 스파크로 하던 모든 기능 요구를 만족할지 알 수 없어서 가능한 사용하는 모든 커넥터를 여섯개 앱에 들어가게 했다. 이 과정을 통해서 S3 커넥터에서 크로스리전 설정 같은게 안된다는 걸 사전에 미리 파악할 수 있었다. 커넥터 별로 성능 고려가 필요한데, 이벤트 처리 방식 자체가 달라서 스파크로 간단하게 동작하던 싱크 작업이 플링크에서 병목 발생할 거라 예상하기도 해 다양한 커넥터를 선정해서 성능을 확인하는 목적으로 선정했다.

이제원: 새로 만드느게 아니라 기존 구조를 개선하는 것이어서 비용, 성능, 운영용이성이란 세 기준에 문제가 없다는 걸 확인해야 갈 수 있었다. 세가지 어떻게 확인할거냐를 전체 애플리케이션 중에 확인해야 하기에 가장 다양한 유즈케이스를 포함하는 대표를 골라 POC를 진행했다.

서버리스 환경을 운영한 후 비용은 어떻게 변했을까. 전상기 개발자는 직접 비교는 어렵다는 전제에서 설명했다.

전상기: 기존 EC2 기반 스파크로 동작하는거와 서버리스 환경에서 동작하는 것의 비용을 직접 비교하긴 어렵다. 대략적으로 보면, EC2 사용량 비용과 KDA 비용에서 조금 감소했다. 과거 세이빙 플랜을 적극 활용해서 할인받았던 금액이랑 비교하면 비용이 증가하는 부분도 있다. 키네시스는  리저브 인스턴스(RI) 같은 정책이 없어서 사용량에 따라 비용 증가 여지가 있다. 그럼에도 온콜이 많이 없어지고 추가 프로세스를 매뉴얼하게 운영하는게 줄었기 때문에 훨씬 유의미한 결과라 생각한다. KDA도 오토스케일링 최적화를 하고 있어서 지속적 모니터링으로 추가적인 비용 감소도 할 수 있을 것이라 본다.

삼성전자 스마트싱스 서버개발그룹 정동환 개발자(왼쪽부터), 이제원 그룹장, 고성준 개발자, 전상기 개발자, 이장결 개발자

많은 기업이 하둡 클러스터로 일찌감치 데이터 분석 플랫폼을 구축했고, 이제 대부분 현대화를 고민하고 있다. 타 기업의 데이터 플랫폼 담당자에게 스마트싱스 개발자는 어떤 조언을 하고 싶을까. 고성준 개발자는 몇가지 고려 사항을 제시했다.

고성준: 서버리스는 직접 관리하는 자원이 없어 EC2 로드 모니터링에서 자유로워지기는 한다. 그러나 서버리스는 서버 있을 때에 비해 상세한 컨피규레이션 튜닝이나, 성능 향상을 위한 오토스케일링 전략 구사나 적용이 불가능하다. 서버리스에서 지원하는 그대로를 따라가야 하는 측면이 있다. 그 때문에 고민했던게 플링크온 KPU는 유닛당 CPU 코어 하나에 메모리가 4GB로  정해져 있다는 것이다. 더 큰 파워가 필요하면 KPU를 못쓴다. 그럴 땐 애플리케이션 하나에 구성된 소프트웨어 요소를 나눠서 여러개로 쪼개 구성하거나, 병렬처리를 잘 해서 그 안에서 앱이 동작하게 하는게 필요하다. 또 하나로, 모든 서버에서 동작하는 앱은 모니터링을 잘 해야 하는데 기본적으로 제공되는 AWS 클라우드워치의 모니터링 매트릭만 쓸 수 있다. 플링크 자체에서 지원되는 디버깅 매트릭이 많은데 활용할 수 없다. 그런 제약이 있어 추가로 뽑거나 하면 결국 새로 추가한 메트릭 때문에 비용이 추가발생 할 수 있다는 것을 감안해야 한다. 마지막으로, 로그도 기본적으로 클라우드와치로 쌓게 돼 있다는 것이다. 우린 AWS에서 제공하는 적제시스템 말고 추가 시스템을 쓰고 있어서 다른 앱과 연동해 해야 하는 부분 때문에 로그를 이중으로 쌓아야 할 수도 있다. 앱 개발하다보면 파일을 구성하게 되는데 최대 512MB까지만 된다. 애플리케이션을 원래 40여종을 하나의 잡에 모아놓고 쉽고 빠르게 배포하게 개발했는데 그 제한을 피하기 위해 여러 카테고리로 나눠 앱을 구성했다.

앞으로 계획은 어떤지 물었다. 기존에 운영하던 하둡 클러스터는 KDA 마이그레이션 완료 후 모두 폐기되는 것인지 궁금했다.

고성준: 기존 하둡 기반 솔루션에서 스파크 요소는 다 삭제할 예정이고, HBASE는 그대로 사용한다. 하둡 클러스터를 완전히 없애진 않고 쓸 예정이다. 하둡클러스터 자체 운영으로 여러가지 경험을 많이 했다. 하둡 자체가 어떻게 동작하는지, 스파크나 HBASE 기반 요소의 동작이 어떻게 되는지 배울 수 있었다. 이런 지식을 기반으로 플링크 쓸 때도 내부 동작이 어떻게 하는지 잘 알고, 데이터 생성이 어떤지 잘 알고, 다음 오퍼레이션이 어떤지 잘 알게 됐다. 노하우를 잘 쌓았기 때문에 앞으로도 잘 쓸 수 있지 않을까 생각한다. 더 적은 비용으로 쓰게 될거라 예측하고 자신감 있어 KDA 시스템을 선택했다.

스마트싱스 서버개발그룹은 마이크로서비스 아키텍처를 활용하고 있다. 프로그래밍 언어와 프레임워크 종속은 없다고 이제원 그룹장은 강조했다. JVM 기반 언어를 가장 많이 쓰며, 언어로 코틀린을 활발히 활용하고 있다고 한다.