문서 집계를 위한 재귀 타이머 및 Couchbase Server 6.6을 통한 TCO 절감

어디서 시작하나요...

IOT, 엣지 디바이스, NoSQL은 모두 최근 몇 년 동안 인기가 높아진 기술입니다. 이러한 기술을 통해 사람들은 안정성과 가용성에 대한 걱정 없이 상호작용이 많은 애플리케이션을 편안하게 만들 수 있습니다. 이러한 신기술의 자유로움과 유연성에도 불구하고 한 가지 문제점은 비용 관리입니다. 문서를 집계하고 데이터 공간을 줄이는 것은 작성량이 많은 분석 애플리케이션의 일반적인 사용 사례입니다. Couchbase 6.6은 TCO를 낮추는 데 도움이 되는 더 많은 도구를 제공합니다. 문제가 어디서 시작되었는지, 그리고 Couchbase 도구 세트를 사용하여 문제를 해결할 수 있는 방법을 살펴보겠습니다.

애플리케이션 및 상호 작용

저는 애플리케이션이 단순한 목표를 달성하기 위해 개발되던 시절을 기억합니다. 예를 들어, 쇼핑 과정을 디지털로 처리할 수 있는 소매업 애플리케이션은 사람들이 동일한 작업을 수행하기 위해 지역 소매점을 방문하지 않아도 됩니다. 미디어 스토어에서 CD나 DVD를 구매할 필요 없이 버튼 클릭 한 번으로 영화와 음악을 감상할 수 있습니다. 거의 모든 것이 디지털로 전환된 초기에는 소비자의 편의성이 크게 향상되었고 모두에게 더 많은 시간을 돌려주었으며, 한동안 이러한 변화는 우리를 행복하게 해주기에 충분했습니다. 기술적인 문제는 그 편리함에 가려져 사소한 것으로 보였기 때문입니다.

그러나 요즘에는 새로운 리테일러의 '디지털화'가 큰 이슈가 아니며, 이러한 기대치는 이미 존재하고 있으며, 소비자가 현재 중요하게 생각하는 것은 이전에는 무시되었던 사소한 부분입니다. 이전에는 사소했던 기술적 문제가 이제는 성공적인 애플리케이션의 '성패를 좌우하는 요소'가 될 것입니다. 디지털 트랜스포메이션이 기업의 일상적인 활동에 녹아들면서 이러한 애플리케이션과 시스템에 대한 기대치가 높아졌고 앞으로도 계속 높아질 것입니다.

데이터베이스

사용자 경험에 대한 높은 기대치를 충족하기 위해 소프트웨어를 개발하면서 최종 사용자와 애플리케이션 간에 더 많은 상호 작용을 제공합니다. 더 복잡한 애플리케이션은 더 많은 상호작용을 수반합니다. 이렇게 상호작용이 계속 증가하면 이를 기록하기 위해 더 많은 양의 스토리지가 필요하게 되고, 바로 여기에 데이터베이스를 활용할 수 있습니다.

애플리케이션 자체와 마찬가지로 관계형 데이터베이스가 거의 모든 시스템의 정보를 저장하는 데 완벽하게 적합했던 시절이 있었고, 이는 우리를 만족시켰습니다. 하지만 사용자 경험에 대한 기대치가 높아지기 시작하면서 기반 데이터베이스에 대한 기대치도 높아졌습니다. 시간이 지남에 따라 기하급수적으로 많은 양의 데이터를 저장하게 되었고, 관계형 데이터베이스의 결함이 드러나기 시작했습니다. 더 많은 데이터는 더 많은 저장 공간을 의미하며, 관계형 데이터베이스에 익숙하신 분들은 이것이 ++를 입력하는 것만큼 간단하지 않다는 것을 알고 계실 것입니다. 우선, 관계형 데이터베이스를 조정할 때 종종 다운타임이 발생하는데, 오늘날의 세계에서 다운타임은 더 이상 용납될 수 없습니다. 관계형 노드를 스케일 아웃하는 것은 쉽게 달성할 수 있는 일이 아니기 때문에 스케일 업으로 제한할 수밖에 없었는데, 문제는 스케일 업은 비용이 많이 들고 그 자체로도 한계가 있다는 것입니다. 또한 확장한 컴퓨팅 성능과 스토리지가 늘어날수록 성능이 선형적으로 향상될 것으로 기대할 수 있지만, 실제로는 그렇지 않습니다. 무엇보다도 강제 스키마 접근 방식은 전체 아키텍처가 경직되어 있어 기본 데이터세트를 변경하기가 어려웠습니다. 전반적으로 관계형 시스템의 TCO는 유지 관리가 불가능했으며, 기술이 점점 더 빠른 속도로 변화하는 세상에서 관계형 데이터베이스가 이러한 고도의 상호 작용 애플리케이션을 위해 대체되어야 하는 이유를 알 수 있습니다.

NoSQL 기술이라는 아이디어가 떠오르기 시작했습니다. NoSQL은 스키마가 적고 확장 가능하며 분산된 방식으로 정보를 저장하는 방식을 구현했습니다. 다운타임 없이 데이터베이스를 확장 및 축소할 수 있는 기능을 제공했습니다. 데이터 세트에 대한 제한이 없어 신속하고 유연한 개발이 가능했습니다. 이러한 데이터베이스의 전체 TCO는 훨씬 더 작고 유지 관리가 용이하여 높은 수준의 상호 작용이 필요한 애플리케이션에 적합합니다.

IOT 및 엣지 디바이스

소프트웨어 세계로의 주요 도입 중 하나는 IOT 및 엣지 디바이스의 갑작스러운 붐이었습니다. 이러한 디바이스는 일반적으로 더 작은 하드웨어와 소프트웨어의 조합으로 구성되며 기본 기술 스택의 진입점 역할을 할 수 있습니다. 이러한 디바이스의 주요한 예로는 센서를 사용하여 지속적으로 데이터를 기록하여 데이터베이스에 피드백할 수 있다는 점을 들 수 있습니다. NoSQL 데이터베이스를 사용하면 관계형 모델이 제공하기 어려운 확장성, 안정성 및 고가용성에 대한 걱정 없이 이러한 장치를 늘리고 확장할 수 있습니다. 이러한 경우 대부분 애플리케이션은 높은 수준의 쓰기 작업을 포함하며 정보는 나중에 분석됩니다.

사용 사례

이제 편안하게 확장할 수 있는 기능은 대부분의 DBA에게 안도의 한숨을 쉬게 하지만, 모두가 해결하려고 하는 공통적인 문제, 즉 비용 증가에 빠르게 부딪히게 됩니다. 가능한 한 많은 데이터를 저장할 수 있는 유연성과 자유로움은 단점도 있는데, 그 결과 이러한 클러스터의 규모가 금방 통제 불능 상태가 될 수 있습니다.

예를 들어 포뮬러 1 레이싱 팀이 경주 중에 밀리초 단위까지 통계를 기록하는 센서를 자동차에 내장하고 있다고 가정하면, 매 경기마다 수백, 수천 개의 센서를 자동차 곳곳에 설치할 수 있습니다. 개별 판독값은 적을지라도 저장되는 문서의 수는 수백만 개에 달할 것이며, 이는 제가 보수적으로 계산한 것입니다! 이 모든 데이터를 확보한 후에는 거의 실시간에 가까운 분석을 실행해야 하며, 이러한 분석 결과를 통해 팀은 레이스 내내 조정하고 개선해 나갈 수 있습니다. 위의 시나리오에서는 문제가 발생하지 않지만, 이를 지원하는 클러스터를 살펴보면 데이터의 양과 데이터베이스의 TCO가 얼마나 빠르게 통제 불능 상태가 될 수 있는지 알 수 있습니다. 그러나 이 포뮬러 1 팀의 경우 15분 후에는 밀리초 단위의 센서 판독값이 더 이상 필요하지 않고 대신 초 단위의 평균을 저장하는 대신 1시간 후에는 분 단위의 평균을 저장하는 것이 좋으며 이 프로세스는 필요한 만큼 반복할 수 있습니다.

예를 들어 여러 온도 및 압력 판독값이 포함된 문서 집합을 보면 다음과 같은 문서 집합을 얻을 수 있습니다.

데이터 집합을 줄이고 보유한 정보를 압축하기 위해 결과를 훨씬 작은 문서 배열로 집계할 수 있습니다.

카우치베이스는 버전 5.5에서 이벤트 서비스를 도입하여 애플리케이션이 자바스크립트 프로그래밍 로직을 통해 시스템의 기본 데이터에 대해 작동할 수 있도록 했습니다. 이벤트에는 타이머라는 편리한 도구가 있어 로직의 실행을 지연시킬 수 있습니다. 포뮬러 1 팀의 경우 이러한 타이머를 활용하여 이벤트 함수를 반복적으로 호출하여 특정 시간 프레임에 문서를 집계할 수 있었지만, 버전 6.6 이전에는 이 작업을 반복하기가 어려웠습니다. 많은 고객들이 Linux의 크론 작업을 활용하여 이러한 작업을 예약하고 외부 REST API 호출을 통해 이벤트 함수를 트리거하여 일정한 간격으로 실행할 수 있도록 했습니다.

카우치베이스 버전 6.6은 재귀 타이머를 도입했습니다. 사용자가 다른 타이머의 콜백 내에서 타이머를 생성할 수 있습니다. 실행 시점에 로직은 주어진 시간 프레임 내에서 문서를 집계한 다음 종료하기 전에 다른 타이머를 가동하여 일정 시간이 지난 후 프로세스를 반복합니다.

이 기능은 사소해 보이지만 재귀 프로세스를 크게 간소화하고 내부적으로 수행할 수 있는 작업을 외부 기술을 활용할 필요가 없습니다.

따라서 NoSQL 데이터베이스를 처음 사용할 때는 문서 집계에 대한 필요성을 느끼지 못할 수도 있습니다. 사용량이 많은 사용 사례를 작성하거나 전체 TCO가 증가하기 시작하여 저장하는 데이터의 양을 줄이는 데 도움이 되는 아이디어와 답을 찾고 계신다면 이 블로그 게시물과 새로운 재귀 타이머가 솔루션의 일부가 될 수 있기를 바랍니다.